This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 158598 - hal misses a USB device already present during a boot
hal misses a USB device already present during a boot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-23 16:37 EDT by Michal Jaegermann
Modified: 2008-08-02 19:40 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 11:58:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fragments of lshal output relevant for "USB-FDU" (6.28 KB, text/plain)
2005-05-23 16:37 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2005-05-23 16:37:30 EDT
Description of problem:

With 2.6.11-1.1340_FC4 kernel hal indeed handles USB devices plugged
and replugged after a boot.  But if such device was already connected
when computer was booting it is not precisely ignored but it is not
handled either.  In a case of a USB floppy ejecting and putting back
a diskette does not have any effect either.

The device used in this test shows up in 'lsusb'.  In dmesg it looks
like that:

  Vendor: SONY      Model: USB-FDU           Rev: 5.01
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdb: 1440 512-byte hdwr sectors (1 MB)
sdb: Write Protect is on
sdb: Mode Sense: 00 46 1e 80
sdb: assuming drive cache: write through
SCSI device sdb: 1440 512-byte hdwr sectors (1 MB)
sdb: Write Protect is on
sdb: Mode Sense: 00 46 1e 80
sdb: assuming drive cache: write through
 sdb: unknown partition table
Attached scsi removable disk sdb at scsi2, channel 0, id 0, lun 0
usb-storage: device scan complete

Even hal is aware and it knows now "storage.bus = 'usb'"  Relevant fragments
of an output from 'lshal' are attached.  Only hal is not doing with this
device anything until that thing is unplugged and plugged back.  Booting with
or without a diskette in a drive does not make any difference.

Version-Release number of selected component (if applicable):
hal-0.5.2-1

How reproducible:
always
Comment 1 Michal Jaegermann 2005-05-23 16:37:30 EDT
Created attachment 114743 [details]
Fragments of lshal output relevant for "USB-FDU"
Comment 2 David Zeuthen 2006-09-28 19:47:13 EDT
Is this still happening with latest Rawhide?
Comment 3 Michal Jaegermann 2006-09-28 20:21:01 EDT
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.
Comment 4 David Zeuthen 2006-10-03 16:21:19 EDT
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?
Comment 5 Michal Jaegermann 2006-10-03 18:05:19 EDT
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.
Comment 6 David Zeuthen 2006-10-03 18:26:53 EDT
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'?
Comment 7 Michal Jaegermann 2006-10-03 19:45:24 EDT
> 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.
Comment 8 David Zeuthen 2006-10-05 14:19:59 EDT
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.
Comment 9 Harald Hoyer 2006-10-06 05:54:41 EDT
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!!!
Comment 10 Pete Zaitcev 2006-10-06 10:06:23 EDT
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.
Comment 11 Michal Jaegermann 2006-10-06 13:01:43 EDT
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.
Comment 12 Bug Zapper 2008-04-03 12:11:03 EDT
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.
Comment 13 Michal Jaegermann 2008-04-04 11:58:18 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.