Bug 158598

Created attachment 114743 [details]
Fragments of lshal output relevant for "USB-FDU"

Is this still happening with latest Rawhide?

Yes, it does in the situation described.

The difference is that now after a boot with a device already attached
I can see it with 'lsusb -v' as:

Bus 004 Device 002: ID 054c:002c Sony Corp.
.....
  iManufacturer           1 Sony
  iProduct                2 USB Floppy Drive
....

OTOH in 'lshal' output I can also see

  info.product = 'USB Floppy Drive'  (string)
  usb_device.product = 'USB Floppy Drive'  (string)
  info.vendor = 'Sony Corp.'  (string)
  usb_device.vendor = 'Sony Corp.'  (string)

but with
usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:10.3/usb4/4-1'
which does not look right.  "Bus 004 Device 001: ID 0000:0000" is,
accordingly to lsusb "bDeviceClass            9 Hub".  Still
'cat /sys/devices/pci0000:00/0000:00:10.3/usb4/4-1/idProduct' says 002c
so maybe this is ok?

There are also no traces of this particular device in dmesg
and a corresponding icon does not show up in "Computer" window.

That could be a problem if one has some USB device permanently
atached - like an USB hard disk, for example.

I just tested this morning with several USB devices and they all work for me. 

Are all the relevant drivers loaded on your system? What's the output of
'lsmod'? Is it the rawhide kernel?

First things first. :-)  Yes, this is a rawhide kernel.  At this
moment 2.6.18-1.2726.fc6.

I re-checked with two USB devices I have handy.  One
is "SanDisk Cruzer USB Flash Drive" and another a USB floppy drive
from Sony which shows up now as described in a comment #3. A behaviour
in this two cases is different.

When booting cold with "SanDisk" already plugged in I see
"USB Mass Storage support registered" before all startup scripts
begin to run.  Once logged on a deskop I have a device icon there.
It took a really long while to get a content after I double-clicked
on that icon, and I do not have anything in logs which would indicate
a reason, but that window eventually filled up.

OTOH when I boot with a USB floppy attached then "USB Mass Storage"
message is missing and there is no device icon either on a desktop
or in "Computer" window.  Now, after repluging that piece of a hardware
usb_storage module is at last loaded, plus fat and vfat modules while
mounting and nothing else, and I see in logs:

Initializing USB Mass Storage driver...
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
  Vendor: SONY      Model: USB-FDU           Rev: 5.01
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdd: 1440 512-byte hdwr sectors (1 MB)

If a physical access to USB sockets is somewhat convenient that is not
that big deal, apart of wear-and-tear on a socket/plug, but a convenient
access is far from beeing always the case (and you may want to use those
not that convenient locations for USB devices which are "fixed").  I am
afraid that I do not have a USB hard disk to check what will happen on
a cold boot but if that does something like this floppy that would be
nasty.

I run in the past into a similar issue with USB scanners.  I guess
that this will bug #144444.  The current handling mechanism did change
but this is not the point.  I would know how to hack a machine
which "forgets" something like that floppy but I am not so sure if
this would be the case with an "average" user.

Alright, so this looks like an issue with modules not being loaded, yes? If so,
please file a bug against udev (please add me as Cc) or, perhaps better,
reassign this bug (and add me as Cc too please).

Re taking long time for window to be filled, that sounds more like either a
kernel  driver problem or a Nautilus problem. USB is sometimes pretty wonky
unfortunately :-(

Btw, does the right thing happen on cold boot if you just do 'modprobe usb-storage'?

> Alright, so this looks like an issue with modules not being loaded.

Indeed.  Although a device is probed; a control light goes up for
a moment during boot.

> please file a bug against udev

Are you convinced that this is the culprit?  When I filed the original
report nearly a year and half ago then udev was not really in the
picture hence I have doubts.

If you are indeed sure that this is a udev problem then you can
reassign this bug as well a I can; or maybe even better. :-)

> Btw, does the right thing happen on cold boot if you just do
> 'modprobe usb-storage'?

If I will put 'modprobe usb-storage' in /etc/rc.d/rc.local then
after a cold boot with an USB floppy attached everything is fine;
which is not surprising at all.  Likely the only downside is
that some memory is used for an unneded module if nothing was
plugged.  That is one possibility I had in mind when I said that
I know how to hack that setup to behave.

Yea, this is definitely an udev problem as udev is responsible for loading the
right kernel modules when it trawls the device tree in sysfs. Reassigning.

Ok, here is the problem:
kernel starts, libusual wants to load usb-storage, but initrd does not contain
it. Later on in the game udev triggers the uevents, but usb-storage has no
modaliases, so usb-storage will not be loaded.

Pete, can I trigger the libusual.probe function from user space, or can you add
modaliases to usb-storage?

I found
http://www.redhat.com/archives/fedora-devel-list/2005-December/msg00545.html ,
which basically means this problem is around now for one year!!!

I know about the libusual and it's very serious, but there's no way
that a bug in #150xxx series would refer to the same thing. The initial
report refers to 2.6.11 and libusual did not exist back then.

Do not dup this into bug 203496 or other, for all we know David found
a perfect timing to ask for more info, when the libusual problem masked
the original issue.

This is from comment #9 by Harald:
> libusual wants to load usb-storage, but initrd does not contain it.

It is true that usb-storage in not a part of initrd; but clearly I
miss something here.  With two USB devices I tried in one case a required
usb-storage was loaded anyway and media mounted.  Apparently this
is always succesful with everything which David has on hands.  So what
is different here?  Configuration files for udev?  I did not dive into
that in a hope that for somebody a reason will be obvious.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Not the case with the current rawhide.  When trying to unmount
though, via an icon menu, from a USB floppy drive which was present
while booting I got "application is using volume" (or something 
to the similar meaning) alert and a floppy stayed mounted.  Still
the second attempt to unmount worked.