usb-storage bug in 2.6.12-rc3

usb-storage bug in 2.6.12-rc3

[David Zeuthen]

(please keep me Cc'ed, I'm not subscribed to linux-usb-devel)

Hi,

it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
any invasive patches in that area) has changed behavior wrt hotplug
event ordering. In [1], I've attached the debug output from
linux-hotplug. Here are the interesting bits:

 728 usb                     path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2

 729 scsi_host               path=/class/scsi_host/host9                         
                      physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9

 730 usb (interface)         path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0

 731 scsi                    path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0

 732 block                   path=/block/sda
                      physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0

 733 block                   path=/block/sda1
                      physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0

 734 scsi_device             path=/class/scsi_device/9:0:0:0
                      physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0

The change I'm seeing from earlier kernels (recent I believe) is that
the hotplug events for scsi_host comes before the one for the USB
interface. Earlier behavior was a lot more sane as the PHYSDEVPATH for
scsi_host references the path that the USB interface gives. Now, for
event 729, we're referencing this path 

 /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9

but we haven't got the hotplug event for 

 /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0

yet since we only get that in event 730.

Can anyone confirm that this is a bug? It sure breaks hal, and probably
other user space software, in pretty marvelous ways as user space needs
to process the hotplug events in order without waiting for future
events.

Thank you,
David 

[1] :

Apr 27 15:41:22 daxter kernel: usb 3-2: new full speed USB device using uhci_hcd and address 11
Apr 27 15:41:22 daxter kernel: scsi9 : SCSI emulation for USB Mass Storage devices
Apr 27 15:41:22 daxter default.hotplug[16525]: arguments (usb) env (SUBSYSTEM=usb OLDPWD=/ DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MANAGED_EVENT=1 UDEVD_EVENT=1 SHLVL=1 HOME=/ PHYSDEVDRIVER=usb DEBUG=yes PHYSDEVBUS=usb SEQNUMr8 _=/bin/env)
Apr 27 15:41:22 daxter default.hotplug[16525]: invoke /etc/hotplug/usb.agent ()
Apr 27 15:41:22 daxter default.hotplug[16536]: arguments (scsi_host) env (PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9 SUBSYSTEM=scsi_host OLDPWD=/ DEVPATH=/class/scsi_host/host9 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MANAGED_EVENT=1 UDEVD_EVENT=1 SHLVL=1 HOME=/ DEBUG=yes SEQNUMr9 _=/bin/env)
Apr 27 15:41:22 daxter default.hotplug[16536]: no runnable /etc/hotplug/scsi_host.agent is installed
Apr 27 15:41:22 daxter default.hotplug[16544]: arguments (usb) env (SUBSYSTEM=usb OLDPWD=/ DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d MODALIAS=usb:v066Fp8000dl0001dh0001dc00dsc00dp00ic08isc06ip50 PWD=/etc/hotplug UDEV_LOG=3 MANAGED_EVENT=1 UDEVD_EVENT=1 SHLVL=1 HOME=/ DEVICE=/proc/bus/usb/003/011 PHYSDEVDRIVER=usb-storage INTERFACE=8/6/80 PRODUCTff/8000/1 TYPE=0/0/0 DEBUG=yes PHYSDEVBUS=usb SEQNUMs0 _=/bin/env)
Apr 27 15:41:22 daxter default.hotplug[16544]: invoke /etc/hotplug/usb.agent ()
Apr 27 15:41:24 daxter usb.agent[16544]: Setup usb-storage usb-storage for USB product 66f/8000/1
Apr 27 15:41:27 daxter kernel:   Vendor:           Model: JetFlash          Rev: 0001
Apr 27 15:41:27 daxter kernel:   Type:   Direct-Access                      ANSI SCSI revision: 04
Apr 27 15:41:27 daxter kernel: SCSI device sda: 251903 512-byte hdwr sectors (129 MB)
Apr 27 15:41:27 daxter kernel: sda: Write Protect is off
Apr 27 15:41:27 daxter kernel: sda: assuming drive cache: write through
Apr 27 15:41:27 daxter kernel: SCSI device sda: 251903 512-byte hdwr sectors (129 MB)
Apr 27 15:41:27 daxter kernel: sda: Write Protect is off
Apr 27 15:41:27 daxter kernel: sda: assuming drive cache: write through
Apr 27 15:41:27 daxter kernel:  sda: sda1
Apr 27 15:41:27 daxter kernel: Attached scsi removable disk sda at scsi9, channel 0, id 0, lun 0
Apr 27 15:41:27 daxter default.hotplug[16585]: arguments (scsi) env (SUBSYSTEM=scsi OLDPWD=/ DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MANAGED_EVENT=1 UDEVD_EVENT=1 SHLVL=1 HOME=/ PHYSDEVDRIVER=sd DEBUG=yes PHYSDEVBUS=scsi SEQNUMs3 _=/bin/env)
Apr 27 15:41:27 daxter default.hotplug[16595]: arguments (block) env (PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0 SUBSYSTEM=block OLDPWD=/ DEVPATH=/block/sda MINOR=0 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MAJOR=8 MANAGED_EVENT=1 UDEVD_EVENT=1 DEVNAME=/dev/sda SHLVL=1 HOME=/ PHYSDEVDRIVER=sd DEBUG=yes PHYSDEVBUS=scsi SEQNUMs1 _=/bin/env)
Apr 27 15:41:27 daxter default.hotplug[16595]: no runnable /etc/hotplug/block.agent is installed
Apr 27 15:41:27 daxter default.hotplug[16585]: invoke /etc/hotplug/scsi.agent ()
Apr 27 15:41:27 daxter scsi.agent[16585]: disk at /devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0
Apr 27 15:41:28 daxter default.hotplug[16617]: arguments (block) env (PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0 SUBSYSTEM=block OLDPWD=/ DEVPATH=/block/sda/sda1 MINOR=1 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MAJOR=8 MANAGED_EVENT=1 UDEVD_EVENT=1 DEVNAME=/dev/sda1 SHLVL=1 HOME=/ PHYSDEVDRIVER=sd DEBUG=yes PHYSDEVBUS=scsi SEQNUMs2 _=/bin/env)
Apr 27 15:41:28 daxter default.hotplug[16617]: no runnable /etc/hotplug/block.agent is installed
Apr 27 15:41:28 daxter default.hotplug[16610]: arguments (scsi_device) env (PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9/target9:0:0/9:0:0:0 SUBSYSTEM=scsi_device OLDPWD=/ DEVPATH=/class/scsi_device/9:0:0:0 PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION­d PWD=/etc/hotplug UDEV_LOG=3 MANAGED_EVENT=1 UDEVD_EVENT=1 SHLVL=1 HOME=/ PHYSDEVDRIVER=sd DEBUG=yes PHYSDEVBUS=scsi SEQNUMs4 _=/bin/env)
Apr 27 15:41:28 daxter default.hotplug[16610]: no runnable /etc/hotplug/scsi_device.agent is installed





-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Alan Stern]

On Wed, 27 Apr 2005, David Zeuthen wrote:

> Hi,
> 
> it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
> kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
> any invasive patches in that area) has changed behavior wrt hotplug
> event ordering. In [1], I've attached the debug output from
> linux-hotplug. Here are the interesting bits:
> 
>  728 usb                     path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2
> 
>  729 scsi_host               path=/class/scsi_host/host9                         
>                       physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9
> 
>  730 usb (interface)         path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0

David's right.  Why did kobject_hotplug() move out of kobject_add() and
into its callers sometime after 2.6.11?  In particular the invocation in 
device_add() is in the wrong place; it needs to come before 
bus_add_device() starts probing for drivers.  Otherwise, as David points 
out, when the drivers start registering child devices from their probe 
methods, the hotplug events for those child devices will appear before the 
event for the parent.

Alan Stern



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Patrick Mansfield]

On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:

> David's right.  Why did kobject_hotplug() move out of kobject_add() and
> into its callers sometime after 2.6.11?  In particular the invocation in 
> device_add() is in the wrong place; it needs to come before 
> bus_add_device() starts probing for drivers.  Otherwise, as David points 
> out, when the drivers start registering child devices from their probe 
> methods, the hotplug events for those child devices will appear before the 
> event for the parent.
> 
> Alan Stern

But bus_add_device() calls device_add_attrs() to create attrs, if you call
it after the hotplug, the user space hotplug event shows up before the
sysfs attrs are created (if the driver is using the bus->dev_attrs field).

I'd like to see device_add() split into two pieces, one component that
initializes the struct device, and another to call the hotplug and the bus
probe.

And as Kay S. suggested, a new device_register() that is the functional
equivalent of today's device_add().

For scsi, we can't easily use the dev_attrs, so this would allow
attributes to be in place prior to the hotplug event (of the block
device): device_add(), create a bunch of classes and attrs, then
device_ready() [or wtf you want to name it].

PS: I haven't had time to generate patches :-(

-- Patrick Mansfield


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Kay Sievers]

On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> 
> > David's right.  Why did kobject_hotplug() move out of kobject_add() and
> > into its callers sometime after 2.6.11?  In particular the invocation in 
> > device_add() is in the wrong place; it needs to come before 
> > bus_add_device() starts probing for drivers.  Otherwise, as David points 
> > out, when the drivers start registering child devices from their probe 
> > methods, the hotplug events for those child devices will appear before the 
> > event for the parent.

Yes, that's bad, sorry, while I've moved the hotplug event generation to this
point to get saner sysfs timing I didn't realized this.

> But bus_add_device() calls device_add_attrs() to create attrs, if you call
> it after the hotplug, the user space hotplug event shows up before the
> sysfs attrs are created (if the driver is using the bus->dev_attrs field).

Right, it would be nice if the sysfs-attributes are ready before the event is
fired. This saves us all the sleep and stat loops in userspace.

> I'd like to see device_add() split into two pieces, one component that
> initializes the struct device, and another to call the hotplug and the bus
> probe.
> 
> And as Kay S. suggested, a new device_register() that is the functional
> equivalent of today's device_add().

I still like that and I can do the patch to split device_add so SCSI can
add the device but fire the hotplug event after the device is fully registered.

Greg, ok if I prepare a patch to look at or don't you like the split?

Otherwise it don't see how this can be fixed and we need to move the hotplug
event in core.c up where it was before and stick with the old sysfs
timing.

Thanks,
Kay


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Greg KH]

On Thu, Apr 28, 2005 at 02:47:23AM +0200, Kay Sievers wrote:
> On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> > On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> > 
> > > David's right.  Why did kobject_hotplug() move out of kobject_add() and
> > > into its callers sometime after 2.6.11?  In particular the invocation in 
> > > device_add() is in the wrong place; it needs to come before 
> > > bus_add_device() starts probing for drivers.  Otherwise, as David points 
> > > out, when the drivers start registering child devices from their probe 
> > > methods, the hotplug events for those child devices will appear before the 
> > > event for the parent.
> 
> Yes, that's bad, sorry, while I've moved the hotplug event generation to this
> point to get saner sysfs timing I didn't realized this.
> 
> > But bus_add_device() calls device_add_attrs() to create attrs, if you call
> > it after the hotplug, the user space hotplug event shows up before the
> > sysfs attrs are created (if the driver is using the bus->dev_attrs field).
> 
> Right, it would be nice if the sysfs-attributes are ready before the event is
> fired. This saves us all the sleep and stat loops in userspace.
> 
> > I'd like to see device_add() split into two pieces, one component that
> > initializes the struct device, and another to call the hotplug and the bus
> > probe.
> > 
> > And as Kay S. suggested, a new device_register() that is the functional
> > equivalent of today's device_add().
> 
> I still like that and I can do the patch to split device_add so SCSI can
> add the device but fire the hotplug event after the device is fully registered.
> 
> Greg, ok if I prepare a patch to look at or don't you like the split?

Let's see what the patch looks like :)

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-storage bug in 2.6.12-rc3

[Kay Sievers]

On Wed, 2005-04-27 at 16:21 -0400, David Zeuthen wrote:
> it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
> kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
> any invasive patches in that area) has changed behavior wrt hotplug
> event ordering. In [1], I've attached the debug output from
> linux-hotplug. Here are the interesting bits:

>  729 scsi_host               path=/class/scsi_host/host9                         
>                       physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9
> 
>  730 usb (interface)         path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0

Btw: This happens only if the modules are already loaded. If the device
causes the module-load everything looks sane. That must be the reason
I've never seen HAL failing with this. :)

== add device first time =941 /devices/pci0000:00/0000:00:1d.1/usb3/3-1
942 /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
943 /module/usb_storage
944 /bus/usb/drivers/usb-storage
945 /class/scsi_host/host0

== reconnect device =959 /devices/pci0000:00/0000:00:1d.1/usb3/3-1
960 /class/scsi_host/host1
961 /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0

I will look at the issue tonight.

Thanks,
Kay



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-storage bug in 2.6.12-rc3

[E. Oltmanns]

Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, 2005-04-27 at 16:21 -0400, David Zeuthen wrote:
>> it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
>> kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
>> any invasive patches in that area) has changed behavior wrt hotplug
>> event ordering. In [1], I've attached the debug output from
>> linux-hotplug. Here are the interesting bits:
>
>>  729 scsi_host               path=/class/scsi_host/host9                         
>>                       physdevpath=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0/host9
>> 
>>  730 usb (interface)         path=/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0
>
> Btw: This happens only if the modules are already loaded. If the device
> causes the module-load everything looks sane. That must be the reason
> I've never seen HAL failing with this. :)

May I remind you that I've recently reported a problem on this list
which I suspect to be caused by timing problems similar to those discussed
here. In my case though, the problem occurred only when the module
usb-storage had to be loaded during hotplug event processing. You can
find the details of my problem in the Mail Message-ID:
<87br82sg0y.fsf@denkblock.local> with the subject
Once more udev/hotplug and usb-storage devices

If you tell me how to produce these listings as you provided them in
your mail, I can try to generate something useful to analyse my problem.
>
> == add device first time => 941 /devices/pci0000:00/0000:00:1d.1/usb3/3-1
> 942 /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
> 943 /module/usb_storage
> 944 /bus/usb/drivers/usb-storage
> 945 /class/scsi_host/host0
>
> == reconnect device => 959 /devices/pci0000:00/0000:00:1d.1/usb3/3-1
> 960 /class/scsi_host/host1
> 961 /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
>

Thank you very much,

Elias


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-storage bug in 2.6.12-rc3

[Patrick Mansfield]

On Thu, Apr 28, 2005 at 02:35:33PM +0100, E. Oltmanns wrote:

> If you tell me how to produce these listings as you provided them in
> your mail, I can try to generate something useful to analyse my problem.

Use an executable script under hotplug.d, like this:

[elm3b79 patman]$ cat /etc/hotplug.d/default/00-log.hotplug
#!/bin/sh

echo "$SEQNUM $ACTION $DEVPATH" >> /tmp/hotplug_d.log


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb-storage bug in 2.6.12-rc3

[E. Oltmanns]

Patrick Mansfield <patmans@us.ibm.com> wrote:
> On Thu, Apr 28, 2005 at 02:35:33PM +0100, E. Oltmanns wrote:
>
>> If you tell me how to produce these listings as you provided them in
>> your mail, I can try to generate something useful to analyse my problem.
>
> Use an executable script under hotplug.d, like this:
>
> [elm3b79 patman]$ cat /etc/hotplug.d/default/00-log.hotplug
> #!/bin/sh
>
> echo "$SEQNUM $ACTION $DEVPATH" >> /tmp/hotplug_d.log
>

Thank you for the tip. However, the output seems to be the same
regardless whether the error occurs or not. The only difference being,
of course, that udev removes the devices in the event of that error
before the usb stick has physically been removed. May be it's really
hal that interferes rather badly in this particular case. It's just
hard to track it down.

Thanks anyway,

Elias


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id\x105hix
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Roman Kagan]

On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> 
> > David's right.  Why did kobject_hotplug() move out of kobject_add() and
> > into its callers sometime after 2.6.11?  In particular the invocation in 
> > device_add() is in the wrong place; it needs to come before 
> > bus_add_device() starts probing for drivers.  Otherwise, as David points 
> > out, when the drivers start registering child devices from their probe 
> > methods, the hotplug events for those child devices will appear before the 
> > event for the parent.
> 
> But bus_add_device() calls device_add_attrs() to create attrs, if you call
> it after the hotplug, the user space hotplug event shows up before the
> sysfs attrs are created (if the driver is using the bus->dev_attrs field).

Do I get it right that at hotplug time the attributes do already exist,
but it is the sysfs files which don't?  It's certainly true for USB, I'm
much less acquainted with other subsystems.

Then, instead of trying to make sure the attributes are available via
sysfs at hotplug time, we can use another means to pass them to hotplug:
we can add a routine, which, when called from the .hotplug function
and given pointers to struct attribute and struct device, would add
environment variable

SYSFS_attrName=attrValue

using attribute's .name and .show, to the list of env variables exported
to the hotplug callout.  This would allow udev or whatever is called to
get most relevant attributes via environment, if available, otherwise to
poke in sysfs and wait until they show up.

Sorry but I can't illustrate it with a patch at the moment as I'm
leaving for four days off, maybe I'll be able to do it when I'm back.

Cheers,
  Roman.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[David Brownell]

On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> 
> ... instead of trying to make sure the attributes are available via
> sysfs at hotplug time, we can use another means to pass them to hotplug:
> we can add a routine, which, when called from the .hotplug function
> and given pointers to struct attribute and struct device, would add
> environment variable
> 
> SYSFS_attrName=attrValue

Color me amused.  That was the original way to pass information
to hotplug agents ... back then (2.4.0.test10 or so), there was
usually no other way to export the relevant data.

I'd rather just guarantee that the sysfs device were fully
constructed (attributes and all) before the driver binding and
hotplug stages of enumeration started.  That's been a problem
all along, and that's what those recent changes were supposed
to be addressing.

- Dave


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Oliver Neukum]

Am Freitag, 29. April 2005 21:28 schrieb David Brownell:
> On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > 
> > ... instead of trying to make sure the attributes are available via
> > sysfs at hotplug time, we can use another means to pass them to hotplug:
> > we can add a routine, which, when called from the .hotplug function
> > and given pointers to struct attribute and struct device, would add
> > environment variable
> > 
> > SYSFS_attrName=attrValue
> 
> Color me amused.  That was the original way to pass information
> to hotplug agents ... back then (2.4.0.test10 or so), there was
> usually no other way to export the relevant data.

Does that mean it was a bad idea? At least it makes sure that
there are less race conditions.

> I'd rather just guarantee that the sysfs device were fully
> constructed (attributes and all) before the driver binding and
> hotplug stages of enumeration started.  That's been a problem
> all along, and that's what those recent changes were supposed
> to be addressing.

Even if you can make sure they had been set up before the script
started, how do you make sure they are still around?

	Regards
		Oliver


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Greg KH]

On Fri, Apr 29, 2005 at 10:23:36PM +0400, Roman Kagan wrote:
> On Wed, Apr 27, 2005 at 04:14:08PM -0700, Patrick Mansfield wrote:
> > On Wed, Apr 27, 2005 at 05:21:10PM -0400, Alan Stern wrote:
> > 
> > > David's right.  Why did kobject_hotplug() move out of kobject_add() and
> > > into its callers sometime after 2.6.11?  In particular the invocation in 
> > > device_add() is in the wrong place; it needs to come before 
> > > bus_add_device() starts probing for drivers.  Otherwise, as David points 
> > > out, when the drivers start registering child devices from their probe 
> > > methods, the hotplug events for those child devices will appear before the 
> > > event for the parent.
> > 
> > But bus_add_device() calls device_add_attrs() to create attrs, if you call
> > it after the hotplug, the user space hotplug event shows up before the
> > sysfs attrs are created (if the driver is using the bus->dev_attrs field).
> 
> Do I get it right that at hotplug time the attributes do already exist,
> but it is the sysfs files which don't?  It's certainly true for USB, I'm
> much less acquainted with other subsystems.
> 
> Then, instead of trying to make sure the attributes are available via
> sysfs at hotplug time, we can use another means to pass them to hotplug:
> we can add a routine, which, when called from the .hotplug function
> and given pointers to struct attribute and struct device, would add
> environment variable
> 
> SYSFS_attrName=attrValue
> 
> using attribute's .name and .show, to the list of env variables exported
> to the hotplug callout.  This would allow udev or whatever is called to
> get most relevant attributes via environment, if available, otherwise to
> poke in sysfs and wait until they show up.
> 
> Sorry but I can't illustrate it with a patch at the moment as I'm
> leaving for four days off, maybe I'll be able to do it when I'm back.

You mean the current kevent_uevent() call with the action of
KOBJ_CHANGE?  :)

That would work too, for apps that listen to kevent messages.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Greg KH]

On Fri, Apr 29, 2005 at 09:35:52PM +0200, Oliver Neukum wrote:
> Am Freitag, 29. April 2005 21:28 schrieb David Brownell:
> > On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > > 
> > > ... instead of trying to make sure the attributes are available via
> > > sysfs at hotplug time, we can use another means to pass them to hotplug:
> > > we can add a routine, which, when called from the .hotplug function
> > > and given pointers to struct attribute and struct device, would add
> > > environment variable
> > > 
> > > SYSFS_attrName=attrValue
> > 
> > Color me amused.  That was the original way to pass information
> > to hotplug agents ... back then (2.4.0.test10 or so), there was
> > usually no other way to export the relevant data.
> 
> Does that mean it was a bad idea? At least it makes sure that
> there are less race conditions.
> 
> > I'd rather just guarantee that the sysfs device were fully
> > constructed (attributes and all) before the driver binding and
> > hotplug stages of enumeration started.  That's been a problem
> > all along, and that's what those recent changes were supposed
> > to be addressing.
> 
> Even if you can make sure they had been set up before the script
> started, how do you make sure they are still around?

You can't guarantee that they will not have been removed, but by at
least saying that "the attributes will be created before you will be
called", you let userspace go a lot faster :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Oliver Neukum]

Am Freitag, 29. April 2005 22:01 schrieb Greg KH:
> > > I'd rather just guarantee that the sysfs device were fully
> > > constructed (attributes and all) before the driver binding and
> > > hotplug stages of enumeration started.  That's been a problem
> > > all along, and that's what those recent changes were supposed
> > > to be addressing.
> > 
> > Even if you can make sure they had been set up before the script
> > started, how do you make sure they are still around?
> 
> You can't guarantee that they will not have been removed, but by at
> least saying that "the attributes will be created before you will be
> called", you let userspace go a lot faster :)

That is true, but it doesn't explain what a layer of indirection will buy
you. If you have all the data ready by the time you send a message,
you might as well send a message that includes all data available.

	Regards
		Oliver
 


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[David Brownell]

On Friday 29 April 2005 12:35 pm, Oliver Neukum wrote:
> Am Freitag, 29. April 2005 21:28 schrieb David Brownell:
> > On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > > 
> > > ... add environment variable ...
> > 
> > Color me amused.  That was the original way to pass information
> > to hotplug agents ... back then (2.4.0.test10 or so), there was
> > usually no other way to export the relevant data.
> 
> Does that mean it was a bad idea? At least it makes sure that
> there are less race conditions.

It was an adequate-but-insufficient-in-general idea.  As I recall
observing at the time.

Insufficient since there's actually no limit to the amount of
information that might be needed to fully process a given hotplug
event, and since most of that information wasn't needed only at
hotplug time either.  Ergo my comment that making sysfs do
the right thing is a better approach...



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[David Zeuthen]

On Fri, 2005-04-29 at 22:16 +0200, Oliver Neukum wrote:
> Am Freitag, 29. April 2005 22:01 schrieb Greg KH:
> > > > I'd rather just guarantee that the sysfs device were fully
> > > > constructed (attributes and all) before the driver binding and
> > > > hotplug stages of enumeration started.  That's been a problem
> > > > all along, and that's what those recent changes were supposed
> > > > to be addressing.
> > > 
> > > Even if you can make sure they had been set up before the script
> > > started, how do you make sure they are still around?
> > 
> > You can't guarantee that they will not have been removed, but by at
> > least saying that "the attributes will be created before you will be
> > called", you let userspace go a lot faster :)
> 
> That is true, but it doesn't explain what a layer of indirection will buy
> you. If you have all the data ready by the time you send a message,
> you might as well send a message that includes all data available.
> 

But it's already in sysfs since that information is needed for coldplug
scenarios. By extension, the hotplug environment should be minimal and
only contain ACTION, DEVPATH, PHYSDEVPATH etc.

David




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Roman Kagan]

On Fri, Apr 29, 2005 at 12:28:30PM -0700, David Brownell wrote:
> On Friday 29 April 2005 11:23 am, Roman Kagan wrote:
> > 
> > ... instead of trying to make sure the attributes are available via
> > sysfs at hotplug time, we can use another means to pass them to hotplug:
> > we can add a routine, which, when called from the .hotplug function
> > and given pointers to struct attribute and struct device, would add
> > environment variable
> > 
> > SYSFS_attrName=attrValue
> 
> Color me amused.  That was the original way to pass information
> to hotplug agents ... back then (2.4.0.test10 or so), there was
> usually no other way to export the relevant data.
> 
> I'd rather just guarantee that the sysfs device were fully
> constructed (attributes and all) before the driver binding and
> hotplug stages of enumeration started.

I must have been unclear in what I was proposing.

I don't suggest to use the technique of 2.4 age to create a set of
environment variables in each .hotplug method, not related to the sysfs
attributes, like usb $PRODUCT, $TYPE, $INTERFACE which are quite
different from the names in sysfs, although they are supposed to convey
the same information.

Rather, _in_addition_ to exporting the attribute values in
sysfs_dir/attrName, one can export (a subset of) them as SYSFS_attrName
environment variables, using _sysfs_ facilities - .show methods - to
generate their values.

Although redundant to some extent, it will be free from lifetime issues,
while requiring very little and absolutely generic extra code.  And the
userspace will be very easy to adjust too, e.g.:

const char *get_attr_val(const char *attr_name)
{
	char var_name[ENVNAME_MAX];
	const char *attr_val;
	snprintf(var_name, ENVNAME_MAX, "SYSFS_%s", attr_name);
	
	if ((attr_val = getenv(var_name)))
		return attr_val;
	else
		return get_attr_val_from_sysfs(attr_name);
}

It'd also save 3 syscalls (open/read/close) per attribute most of the
time.

Cheers,
  Roman.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[David Zeuthen]

Hey,

On Wed, 2005-04-27 at 21:34 -0700, Greg KH wrote:
> > Greg, ok if I prepare a patch to look at or don't you like the split?
> 
> Let's see what the patch looks like :)
> 

Did anything happen on this issue? Is there a patch yet? :-)

Thanks,
Dave




-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] usb-storage bug in 2.6.12-rc3

[Greg KH]

On Wed, May 18, 2005 at 10:19:41AM -0400, David Zeuthen wrote:
> 
> Hey,
> 
> On Wed, 2005-04-27 at 21:34 -0700, Greg KH wrote:
> > > Greg, ok if I prepare a patch to look at or don't you like the split?
> > 
> > Let's see what the patch looks like :)
> 
> Did anything happen on this issue? Is there a patch yet? :-)

I don't think so, sorry.

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel