John Bradford | 1 Jan 01:01 2004

(unknown)

Happy new year :-)

John.
Matthew Mastracci | 1 Jan 01:12 2004

Removable USB device contents cached after removal?

I've been working on getting my USB Atech 9-in-1 card reader working 
with Linux.  Everything mounts, unmounts and reads fine, but I'm getting 
a strange situation where the contents of the card seem to be buffered 
after the media has been removed from the card reader.

The strange thing is that this only happens when the card itself has 
been mounted, but it does *not* happen if the card is inserted and 
removed without mounting.

I'm running kernel 2.6.0-1.107 from arjanv's RedHat builds.

Here are the steps I use to reproduce it:

Working case (never mounted)

1.  Insert card into reader.
2.  dd if=/dev/sdd1 count=1024 bs=1 | hexdump
	- results in correct filesystem dump
3.  Remove card from reader.
4.  cat /dev/sdd1 results in "No medium found"

Non-working case:

1.  Insert card into reader.
2.  Mount card as directory somewhere in root filesystem, list contents 
of card
3.  dd if=/dev/sdd1 count=1024 bs=1024 | hexdump
	- results in correct filesystem dump
4.  Remove card from reader.
5.  dd if=/dev/sdd1 count=1024 bs=1024 | hexdump
(Continue reading)

Andries Brouwer | 1 Jan 01:15 2004
Picon
Picon

Re: udev and devfs - The final word

On Wed, Dec 31, 2003 at 03:19:22PM -0500, Rob Love wrote:

> We can get to the point where we don't even need the explicit concept of
> device numbers, but just "any old unique value" to use as a cookie.  The
> kernel can pull that number from anywhere, and notify user-space via
> udev ala hotplug.

My plan has been to essentially use a hashed disk serial number
for this "any old unique value". The problem is that "any old"
is easy enough, but "unique" is more difficult.
Naming devices is very difficult, but in some important cases,
like SCSI or IDE disks, that would work and give a stable name.

The kernel must not invent consecutive numbers - that does not
lead to stable names. Setting this up correctly is nontrivial.

Rob Love | 1 Jan 01:31 2004

Re: udev and devfs - The final word

On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:

> My plan has been to essentially use a hashed disk serial number
> for this "any old unique value". The problem is that "any old"
> is easy enough, but "unique" is more difficult.
> Naming devices is very difficult, but in some important cases,
> like SCSI or IDE disks, that would work and give a stable name.

Yup.

> The kernel must not invent consecutive numbers - that does not
> lead to stable names. Setting this up correctly is nontrivial.

This is definitely an interesting problem space.

I agree wrt just inventing consecutive numbers.  If there was a nice way
to trivially generate a random and unique number from some
device-inherent information, that would be nice.

	Rob Love

Petri Koistinen | 1 Jan 01:39 2004
Picon
Picon

Re: [PATCH][2.6] Remove warning in ftape

Hi!

On Wed, 31 Dec 2003, Chris Heath wrote:

> Here's a trivial patch that removes an unused-variable warning in ftape.

Submit trivial patches here also:
http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/

Otherwise small patches might get lost in the flood.

Petri
Helge Hafting | 1 Jan 02:18 2004
Picon
Picon

Re: udev and devfs - The final word

On Tue, Dec 30, 2003 at 04:29:42PM -0800, Greg KH wrote:
> 
>  2) We are (well, were) running out of major and minor numbers for
>     devices.

devfs tried to fix this one by _getting rid_ of those numbers.
Seriously - what are they needed for?  
(Yes, I know why they're needed with /dev on ext2)
Opening a device in devfs went straight to the device from the
inode - no extra lookup of "device numbers"
Numbers were provided mostly for backward compatibility - they
weren't used for the main task of accessing devices.

udev has many other advantages of course, too bad we still
have to carry those numbers around.

Helge Hafting

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Stuart Longland | 1 Jan 02:05 2004

Re: spam abuse


donna wrote:
| hi i recieved the following unsolicited email from what appears to be your
| address
|

Yes, we heard about it too -- some smartarse is sending Yahoo greeting
cards, making out that their email address is
linux-kernel <at> vger.kernel.org.  Wasn't our doing I'm afraid -- you may
have to take this up with Yahoo, they should be able to assist you.  (I
can't as I'm just a subscriber to the linux-kernel mailinglist)

--
+-------------------------------------------------------------+
| Stuart Longland           stuartl at longlandclan.hopto.org |
| Brisbane Mesh Node: 719             http://stuartl.cjb.net/ |
| I haven't lost my mind - it's backed up on a tape somewhere |
| Atomic Linux Project    <--->    http://atomicl.berlios.de/ |
+-------------------------------------------------------------+
Tyler Hall | 1 Jan 02:12 2004
Picon

device classes in sysfs

Has there ever been any discussion about classifying devices according 
to their function, and providing an interface (say with libsysfs) for 
user apps to enumerate a particular class? The new udev project _does_ 
provide the nice feature of persistent naming of a given device that can 
change positions on a bus (like 2 USB printers that change USB ports), 
but what about hunting for devices that provide the same function that 
can exist on any bus (like 1 parallel port printer and 1 USB printer)?

_After_ devices are configured and assigned names, users can depend on 
udev and friends to provide the same name to their devices. But _before_ 
the devices are initially configured, users (rather, writers of user 
apps) have to pull some special hacks to scan buses or dig deep into 
/proc to find what devices provide some target function (like printing).

I see /sys/class, but that seems more defined as "hardware architecture" 
class rather than "function" class.

Any opinions?

Tyler

Matthew Mastracci | 1 Jan 02:36 2004

Removable USB device contents cached after removal? [Part 2]

Just as a note in regards to my previous post: I'm mostly looking for a 
way to determine that the device was improperly mounted and use this 
information to display an error.  I know it's not a good idea to be 
removing mounted devices without a umount first.  :)

To investigate further, as an experiment, I tried the same thing with 
fd0.  It turns out that the floppy driver is able to detect the media 
change and doesn't return any cached data when accessing the raw device. 
  Accessing the memory device's raw device rather than the partition 
device (ie: sdd vs. sdd1) also detected the change.

Here's an example:

[root <at> matt mnt]# mount floppy
[root <at> matt mnt]# dd if=/dev/fd0 of=/dev/null count=10 bs=1024
10+0 records in
10+0 records out
     (manually ejecting floppy while still mounted)
[root <at> matt mnt]# dd if=/dev/fd0 of=/dev/null count=10 bs=1024
dd: opening `/dev/fd0': No such device or address
[root <at> matt mnt]# umount floppy/
[root <at> matt mnt]# cat /dev/fd0
cat: /dev/fd0: No such device or address

And the memory device as a comparison:

[root <at> matt mnt]# mount /dev/sdd1
[root <at> matt mnt]# dd if=/dev/sdd1 of=/dev/null count=10 bs=1024
10+0 records in
10+0 records out
(Continue reading)

Thomas Molina | 1 Jan 02:27 2004

Re: 2.6.0 performance problems

On Wed, 31 Dec 2003, Roger Luethi wrote:

> For the systematic testing, I used "qsbench -p 4 -m 96" on a 256 MB
> machine. This allowed the kernel to achieve high performance with
> unfairness -- that's what 2.4 does: One process dominates all others
> and finishes very early, taking away most of the memory pressure.
> The spike for qsbench in 2.5.39 remains if only one process is forked
> (-p1 -m 384), though.
> 
> I asked for the bk export numbers with 2.5.39 because I'm curious how
> close to qsbench the behavior really is.

2.5.39 won't compile for me "out of the box".  I thought it might have 
been the toolset, but I was running RH8 and it has gcc 3.2.  Was there a 
big change between 3.2 and 3.3.2 in Fedora Core 1?  The reason I ask is 
that I also can't get NISTNet to compile on Fedora Core 1 or RHEL WS 3.  
It looks like incompatible libraries.

Gmane