I just gave 2.5.26 a whirl. The first thing I noticed was
that the hotplug system didn't run the script for my usb
modem...
kernel: usb.c: USB disconnect on device 2
kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by any active driver.
/etc/hotplug/usb.agent: ... no modules for USB product 6b9/4061/0
however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only difference
is the change in kernel)...
All the best,
Duncan.
On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> I just gave 2.5.26 a whirl. The first thing I noticed was
> that the hotplug system didn't run the script for my usb
> modem...
>
> kernel: usb.c: USB disconnect on device 2
> kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by any active driver.
> /etc/hotplug/usb.agent: ... no modules for USB product 6b9/4061/0
>
> however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only difference
> is the change in kernel)...
But that message is from the hotplug agent, right?
What kind of script used to get run, and how was it run (i.e. on network
interface registration, etc.)
thanks,
greg k-h
On Thursday 18 July 2002 20:36, Greg KH wrote:
> On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> > I just gave 2.5.26 a whirl. The first thing I noticed was
> > that the hotplug system didn't run the script for my usb
> > modem...
> >
> > kernel: usb.c: USB disconnect on device 2
> > kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> > kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by
> > any active driver. /etc/hotplug/usb.agent: ... no modules for USB product
> > 6b9/4061/0
> >
> > however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only
> > difference is the change in kernel)...
>
> But that message is from the hotplug agent, right?
Yup, which normally (using the product id etc) works out that it needs
to run "the script for my usb modem".
> What kind of script used to get run, and how was it run (i.e. on network
> interface registration, etc.)
It was run by the hotplug system - it uploads firmware then launches the
internet connection. The hotplug script knows to run it by looking up the
vendor/product id in a list. Doesn't info get passed to the hotplut script via
environment variables? Maybe they are not getting set up right...
I'm leaving now for one month so I'm afraid it will be a while until I'll
next be able to look at this...
Ciao,
Duncan.
On Thursday 18 July 2002 20:36, Greg KH wrote:
> On Thu, Jul 18, 2002 at 09:50:42AM +0200, Duncan Sands wrote:
> > I just gave 2.5.26 a whirl. The first thing I noticed was
> > that the hotplug system didn't run the script for my usb
> > modem...
> >
> > kernel: usb.c: USB disconnect on device 2
> > kernel: hub.c: new USB device 00:0b.0-2, assigned address 4
> > kernel: usb.c: USB device 4 (vend/prod 0x6b9/0x4061) is not claimed by
> > any active driver. /etc/hotplug/usb.agent: ... no modules for USB product
> > 6b9/4061/0
> >
> > however this works just fine with 2.4.19-rc1 and 2.5.24 (i.e. only
> > difference is the change in kernel)...
>
> But that message is from the hotplug agent, right?
>
> What kind of script used to get run, and how was it run (i.e. on network
> interface registration, etc.)
>
> thanks,
>
> greg k-h
OK, I've worked out what was wrong (patch below): /proc/bus/usb was
being unmounted by the hotplug/usb.rc script. After loading a HCD, usb.rc
executes the following lines:
if [ -d /proc/bus/usb ]; then
# If we see there are no busses, we "failed" and
# can report so even if we're partially nonmodular.
COUNT=`ls /proc/bus/usb | wc -l`
if [ $COUNT -le 2 ]; then
umount /proc/bus/usb
rmmod usbcore >/dev/null 2>&1
return 1
fi
In the 2.4 kernels, /proc/bus/usb contains at least
001 devices drivers
i.e. at least three entries. However sometime during
the 2.5 kernel series the drivers file went away. So
now there are only two entries and usb.rc unmounts
/proc/bus/usb.
A simple fix is to change the test to [ $COUNT -lt 2 ];
Duncan.
--- hotplug/usb.rc.orig 2002-09-15 23:29:14.000000000 +0200
+++ hotplug/usb.rc 2002-09-15 23:29:39.000000000 +0200
@@ -149,7 +149,7 @@
# If we see there are no busses, we "failed" and
# can report so even if we're partially nonmodular.
COUNT=`ls /proc/bus/usb | wc -l`
- if [ $COUNT -le 2 ]; then
+ if [ $COUNT -lt 2 ]; then
umount /proc/bus/usb
rmmod usbcore >/dev/null 2>&1
return 1
On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
>
> A simple fix is to change the test to [ $COUNT -lt 2 ];
Good catch, yes the drivers file disappeared, and until now, almost no
one noticed it :)
I'll go apply this patch.
Thanks again for finding this.
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 18 Sep 2002 16:52, Greg KH wrote:
> On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
> > A simple fix is to change the test to [ $COUNT -lt 2 ];
>
> Good catch, yes the drivers file disappeared, and until now, almost no
> one noticed it :)
I assume that /proc/bus/usb/drivers went to driverfs. Everyone likes the new
guy :)
I'd like the file back. We have a lot of debugging advice that asks people to
send that particular file to us, and it is very useful. Even if you update
the few places that you can find, then you will still have a lot of confusion
(well, if you have 2.4, then send this, and if you have 2.6, send this, and
if that doesn't exist, and you're on 2.4, mount this filesystem, else mount
this filesystem). Ugly, and increases the support workload.
A symlink will do, assuming both filesystems are mounted. If we only have
usbfs, I still want the data.
Please fix this before 2.6.
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9iCgnW6pHgIdAuOMRAgRcAJ9+i0ksw2S4qS8wvA+SD5prjA4IEwCcCulE
APZsrWY1WlNoY42cG8pXUTI=
=GNYM
-----END PGP SIGNATURE-----
On Wed, Sep 18, 2002 at 05:15:50PM +1000, Brad Hards wrote:
> On Wed, 18 Sep 2002 16:52, Greg KH wrote:
> > On Sun, Sep 15, 2002 at 11:53:41PM +0200, Duncan Sands wrote:
> > > A simple fix is to change the test to [ $COUNT -lt 2 ];
> >
> > Good catch, yes the drivers file disappeared, and until now, almost no
> > one noticed it :)
> I assume that /proc/bus/usb/drivers went to driverfs. Everyone likes the new
> guy:)
The functionality went there, not the actual file. The file is obsolete
now :)
> I'd like the file back. We have a lot of debugging advice that asks people to
> send that particular file to us, and it is very useful. Even if you update
> the few places that you can find, then you will still have a lot of confusion
> (well, if you have 2.4, then send this, and if you have 2.6, send this, and
> if that doesn't exist, and you're on 2.4, mount this filesystem, else mount
> this filesystem). Ugly, and increases the support workload.
>
> A symlink will do, assuming both filesystems are mounted. If we only have
> usbfs, I still want the data.
'ls <wherever_you_mounted_driverfs>/bus/usb/drivers' will now show you
all of the registered USB drivers. As for what the minor numbers are
for the drivers that happened to use the USB major number, I'm working
on that.
> Please fix this before 2.6.
Sorry, but I'm not going to put the file back. I understand your
concerns. We should have some kind of program (lsdev like) that shows
the system information present at that moment in time. It will be able
to provide what the /proc/bus/usb/drivers file showed in the past.
thanks,
greg k-h
On Wednesday 18 September 2002 18:55, Greg KH wrote:
> Sorry, but I'm not going to put the file back. I understand your
> concerns. We should have some kind of program (lsdev like) that shows
> the system information present at that moment in time. It will be able
> to provide what the /proc/bus/usb/drivers file showed in the past.
How about calling it /proc/bus/usb/drivers?
--
Daniel
On Thursday 19 September 2002 09:37, Daniel Phillips wrote:
> On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > Sorry, but I'm not going to put the file back. I understand your
> > concerns. We should have some kind of program (lsdev like) that shows
> > the system information present at that moment in time. It will be able
> > to provide what the /proc/bus/usb/drivers file showed in the past.
>
> How about calling it /proc/bus/usb/drivers?
Never mind, /usr/sbin/lsusb or whatever is the obvious model. Still,
it's interesting to think about a proc stub that just calls a user
space program.
--
Daniel
On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > Sorry, but I'm not going to put the file back. I understand your
> > concerns. We should have some kind of program (lsdev like) that shows
> > the system information present at that moment in time. It will be able
> > to provide what the /proc/bus/usb/drivers file showed in the past.
>
> How about calling it /proc/bus/usb/drivers?
Please go back and read what I wrote above what you snipped out and then
explain how this would be possible.
greg k-h
On Thursday 19 September 2002 09:48, Greg KH wrote:
> On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> > On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > > Sorry, but I'm not going to put the file back. I understand your
> > > concerns. We should have some kind of program (lsdev like) that shows
> > > the system information present at that moment in time. It will be able
> > > to provide what the /proc/bus/usb/drivers file showed in the past.
> >
> > How about calling it /proc/bus/usb/drivers?
>
> Please go back and read what I wrote above what you snipped out and then
> explain how this would be possible.
I don't get it. What's the problem? Not that I'm advocating that proc have
functionality that can be done perfectly well in user space, but I fail to
see why you couldn't do it in proc if you wanted to.
--
Daniel
On Thu, Sep 19, 2002 at 09:55:57AM +0200, Daniel Phillips wrote:
> On Thursday 19 September 2002 09:48, Greg KH wrote:
> > On Thu, Sep 19, 2002 at 09:37:07AM +0200, Daniel Phillips wrote:
> > > On Wednesday 18 September 2002 18:55, Greg KH wrote:
> > > > Sorry, but I'm not going to put the file back. I understand your
> > > > concerns. We should have some kind of program (lsdev like) that shows
> > > > the system information present at that moment in time. It will be able
> > > > to provide what the /proc/bus/usb/drivers file showed in the past.
> > >
> > > How about calling it /proc/bus/usb/drivers?
> >
> > Please go back and read what I wrote above what you snipped out and then
> > explain how this would be possible.
>
> I don't get it. What's the problem? Not that I'm advocating that proc have
> functionality that can be done perfectly well in user space, but I fail to
> see why you couldn't do it in proc if you wanted to.
First of all, /proc/bus/usb/* is not a proc filesystem, usbfs is mounted
in that location :)
The main reason is this information is no longer available to the USB
core. It isn't keeping a list of registered drivers anymore, only the
driver core is. So there's no way that usbfs can get to that
information. As the info is available in driverfs, duplication of it in
usbfs would be bloat.
thanks,
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 20 Sep 2002 02:49, Greg KH wrote:
> The main reason is this information is no longer available to the USB
> core. It isn't keeping a list of registered drivers anymore, only the
> driver core is. So there's no way that usbfs can get to that
> information. As the info is available in driverfs, duplication of it in
> usbfs would be bloat.
This doesn't follow. driverfs != driver core, just as usbfs != USB core.
I wasn't joking about putting back the /proc/bus/usb/drivers file. This is
really going to hurt us in 2.6.
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9ijn3W6pHgIdAuOMRAmU+AKCFhvEl2SmXYiYpOQk6CDWrpZhpSACgwh3p
nczKbUd5dYb1V2Ycbk2/eRE=
=RLuK
-----END PGP SIGNATURE-----
On Fri, Sep 20, 2002 at 06:56:23AM +1000, Brad Hards wrote:
> On Fri, 20 Sep 2002 02:49, Greg KH wrote:
> > The main reason is this information is no longer available to the USB
> > core. It isn't keeping a list of registered drivers anymore, only the
> > driver core is. So there's no way that usbfs can get to that
> > information. As the info is available in driverfs, duplication of it in
> > usbfs would be bloat.
> This doesn't follow. driverfs != driver core, just as usbfs != USB core.
I agree. But the info is now in the driver core, it's not present in
the USB core at all anymore. So since drverfs exports what's in the
driver core, that info shows up there. usbfs doesn't have access to
this info, so it can't display it.
> I wasn't joking about putting back the /proc/bus/usb/drivers file. This is
> really going to hurt us in 2.6.
Is this file _really_ used? All it did was show the USB drivers
registered. Even so, that same information is now present in driverfs,
I haven't taken away anything, just moved it. Lots of things are
starting to move to driverfs, this isn't the first, and will not be the
last.
thanks,
greg k-h