I forgot to mention, just like Bug 85821 playing with modprobe -r and modprobe
on usb-storage and related modules after this kernel oops either results in
usb-storage getting stuck in "Intializing" or a kernel panic.  I am not yet able
to save the kernel panic dump.

Hmm, I have been somewhat mistaken in this report.  This particular USB keychain
seems to be unusable/unstable on any Linux kernel.

Some of my analysis was confused by the "usb-uhci.c: interrupt, status 3, frame#
1980" problem that happens periodically with any usb-storage device that I test.
 That event seems to cause the problem in Bug 85821.

I tested this keychain with uhci.o instead of usb-uhci.o and it still fails,
although the "usb-uhci.c: interrupt, status 3, frame# 1980" no longer appears in
dmesg periodically (more about these uhci.o test results in Bug 85821).

Please look at Bug 85821 before this one.  I am suspecting that this USB
keychain is different in some way that even kernel-2.4.21-pre5 cannot handle
properly.  I have tested two identical keychains so I don't think it is a single
defective unit.    Who are the upstream contributors of usb-storage, they may
have some debugging ideas when dealing with unknown new devices?

The act of simply plugging this keychain into my laptop causing the kernel to
become unstable.  Unloading usb-storage usually works, but inserting the module
again even with the keychain unplugged either gets stuck at "Initializing", or
kernel OOPS or panic.  The only way to use any other USB storage device after
this device has been plugged in is to reboot.

Tested again in kernel-2.4.20-6.  Behavior is almost the same as described
above.  I was able to make the kernel OOPS with the following procedure:
1. Plug in the usb keychain
2. wait about 30 seconds for two usb-storage devices to show up in /proc/scsi/
(which is incorrect)
3. /dev/sda is inoperative like described earlier in this report.
4. modprobe -r usb-storage, first usb-storage directory disappears from
/proc/scsi, but second remains.
5. Attempt to cd into remaining /proc/scsi/usb-storage-1, bash shell crashes and
this kernel OOPS occurs.

Unable to handle kernel paging request at virtual address e0967010
 printing eip:
c0165663
*pde = 0258f067
*pte = 00000000
Oops: 0002
nls_iso8859-1 nls_cp437 sd_mod vfat fat visor usbserial via82cxxx_audio uart401
ac97_codec sound soundcore parport_pc lp parport iptable_filter ip_tables auto
CPU:    0
EIP:    0060:[<c0165663>]    Not tainted
EFLAGS: 00210286
 
EIP is at proc_get_inode [kernel] 0x9b (2.4.20-6)
eax: e0967000   ebx: d9804240   ecx: 00000001   edx: cb964418
esi: cb964380   edi: d9804299   ebp: c9dbe0c0   esp: c2bade6c
ds: 0068   es: 0068   ss: 0068
Process bash (pid: 6104, stackpage=c2bad000)
Stack: c25a5800 000011e2 00000000 00000000 000011e2 c9dbe12d c0167597 c25a5800
       000011e2 d9804240 d9804240 ffffffea 00000000 fffffff4 cb964bec cb964b80
       c9dbe0c0 c014e937 cb964b80 c9dbe0c0 00000000 dfede00d fffffdee c2badf48
Call Trace:   [<c0167597>] proc_lookup [kernel] 0xd7 (0xc2bade84))
[<c014e937>] real_lookup [kernel] 0xc3 (0xc2badeb0))
[<c014ee8f>] link_path_walk [kernel] 0x40f (0xc2badecc))
[<c014f339>] path_lookup [kernel] 0x3d (0xc2badf0c))
[<c014f5d1>] __user_walk [kernel] 0x49 (0xc2badf1c))
[<c016763d>] proc_readdir [kernel] 0x9d (0xc2badf24))
[<c014b0bb>] vfs_stat [kernel] 0x1f (0xc2badf38))
[<c015303d>] vfs_readdir [kernel] 0x9d (0xc2badf54))
[<c014b6ff>] sys_stat64 [kernel] 0x1b (0xc2badf70))
[<c0144ac5>] fput [kernel] 0xd5 (0xc2badf7c))
[<c014319d>] filp_close [kernel] 0x4d (0xc2badf98))
[<c014321e>] sys_close [kernel] 0x4e (0xc2badfb0))
[<c01093b3>] system_call [kernel] 0x33 (0xc2badfc0))
 
 
Code: ff 40 10 8b 43 24 83 48 14 18 8b 43 18 85 c0 74 06 89 86 8c

This keychain is still inoperative on kernel-2.4.20-9.  I don't see kernel
oopses anymore, but it seems unable to recognize that /dev/sda is a disk.

I have very similar problems so I add it as a comment to this bug instead of
opening a new bug.

I use kernel-2.4.20-9 on RedHat 9. My PC is an IBM ThinkPad T30. It uses the
usb-uhci module.

The device is an Olympus Camedia C-220 Zoom camera. It used to work with kernel
2.8 on RedHat 8 with the kernel patch from this page:
http://home.earthlink.net/~ebrombaugh/d150.html. Looking at the kernel source,
this patch seem to be included in RedHat's 2.4.20 kernel.

This is what happens when I connect the camera:

May  3 13:39:27 zion kernel: hub.c: new USB device 00:1d.1-2, assigned address 2
May  3 13:39:27 zion kernel: usb.c: USB device 2 (vend/prod 0x7b4/0x102) is not
claimed by any active driver.
May  3 13:39:31 zion /etc/hotplug/usb.agent: Setup usb-storage for USB product
7b4/102/1054
May  3 13:39:32 zion kernel: Initializing USB Mass Storage driver...
May  3 13:39:32 zion kernel: usb.c: registered new driver usb-storage
May  3 13:39:32 zion kernel: usb-uhci.c: interrupt, status 2, frame# 843
May  3 13:39:32 zion kernel: scsi1 : SCSI emulation for USB Mass Storage devices
May  3 13:39:38 zion su(pam_unix)[5276]: session opened for user root by
david(uid=500)
May  3 13:39:56 zion kernel: usb.c: USB disconnect on device 00:1d.1-2 address 2
May  3 13:39:57 zion kernel: hub.c: new USB device 00:1d.1-2, assigned address 3
May  3 13:39:57 zion devlabel: devlabel service started/restarted
May  3 13:39:58 zion devlabel: The symlink /dev/cruzer -> /dev/sda1 is being
ignored in /etc/sysconfig/devlabel because the correct device cannot be found.
May  3 13:40:01 zion kernel: usb-uhci.c: interrupt, status 3, frame# 1299
May  3 13:40:01 zion kernel: scsi: device set offline - not ready or command
retry failed after bus reset: host 1 channel 0 id 0 lun 0
May  3 13:40:01 zion kernel: USB Mass Storage support registered.
May  3 13:40:01 zion kernel: scsi2 : SCSI emulation for USB Mass Storage devices
May  3 13:40:02 zion devlabel: devlabel service started/restarted
May  3 13:40:02 zion devlabel: The symlink /dev/cruzer -> /dev/sda1 is being
ignored in /etc/sysconfig/devlabel because the correct device cannot be found.

This is just the same thing to show that it is reproducible:

May  4 16:45:38 zion kernel: hub.c: new USB device 00:1d.1-2, assigned address 2
May  4 16:45:38 zion kernel: usb.c: USB device 2 (vend/prod 0x7b4/0x102) is not
claimed by any active driver.
May  4 16:45:41 zion /etc/hotplug/usb.agent: Setup usb-storage for USB product
7b4/102/1054
May  4 16:45:41 zion kernel: Initializing USB Mass Storage driver...
May  4 16:45:41 zion kernel: usb.c: registered new driver usb-storage
May  4 16:45:42 zion kernel: usb-uhci.c: interrupt, status 2, frame# 150
May  4 16:45:43 zion kernel: usb_control/bulk_msg: timeout
May  4 16:45:43 zion kernel: scsi1 : SCSI emulation for USB Mass Storage devices
May  4 16:46:07 zion kernel: usb.c: USB disconnect on device 00:1d.1-2 address 2
May  4 16:46:07 zion kernel: hub.c: new USB device 00:1d.1-2, assigned address 3
May  4 16:46:07 zion devlabel: devlabel service started/restarted
May  4 16:46:08 zion devlabel: The symlink /dev/cruzer -> /dev/sda1 is being
ignored in /etc/sysconfig/devlabel because the correct device cannot be found.
May  4 16:46:12 zion kernel: usb-uhci.c: interrupt, status 3, frame# 1616
May  4 16:46:12 zion kernel: scsi: device set offline - not ready or command
retry failed after bus reset: host 1 channel 0 id 0 lun 0
May  4 16:46:12 zion kernel: USB Mass Storage support registered.
May  4 16:46:12 zion devlabel: devlabel service started/restarted
May  4 16:46:13 zion kernel: usb_control/bulk_msg: timeout
May  4 16:46:13 zion kernel: scsi2 : SCSI emulation for USB Mass Storage devices
May  4 16:46:13 zion devlabel: The symlink /dev/cruzer -> /dev/sda1 is being
ignored in /etc/sysconfig/devlabel because the correct device cannot be found.

After this, nothing happens. I can unload usb-storage but if I load it again it
gets stuck in "(initializing)" according to lsmod. In order to use usb-storage
again I have to reboot. (I have a SanDisk Cruzer that uses usb-storage and works
perfectly.)

Correction of my post above: 

The patch I refer to is not included in RedHat's Linux kernel.

My camera works when I apply this patched to the usb-storage module, but fails
as described above without the patch.

The patch changes the handling of the USB-storage signature, so maybe this
keychain also provides the wrong signature?

No, David, don't mix it. Warren's problem is an oops due to usb-storage
being fooled by a kinky device.

BTW, I fixed the signature in the recent errata (-18.[789] I believe).
Please, direct your attention to bug 72604. I think you may safely drop
from cc list of this bug.

Warren, did you have a chance to try 2.4.20-13 yet?

Also... if that fails, I'd like to see the dmesg from it, working.
The "normal" dmesg you posted was from an affected kernel,
only started without the keychain. That's useless for comparison.

Running kernel-2.4.20-18.9... no kernel oopses but still broken behavior.

hub.c: new USB device 00:07.2-2, assigned address 32
usb.c: USB device 32 (vend/prod 0xed1/0x6660) is not claimed by any active driver.
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi1 : SCSI emulation for USB Mass Storage devices
usb-uhci.c: interrupt, status 3, frame# 2028
(These are happening maybe every 30 seconds)
usb-uhci.c: interrupt, status 3, frame# 628
usb-uhci.c: interrupt, status 3, frame# 876
usb-uhci.c: interrupt, status 3, frame# 1716
(This happened maybe a minute later)
usb.c: USB disconnect on device 00:07.2-2 address 32
hub.c: new USB device 00:07.2-2, assigned address 33
usb-uhci.c: interrupt, status 3, frame# 60
scsi: device set offline - not ready or command retry failed after bus reset:
host 1 channel 0 id 0 lun 0
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 32
USB Mass Storage support registered.
scsi2 : SCSI emulation for USB Mass Storage devices
resize_dma_pool: unknown device type -1
usb-uhci.c: interrupt, status 3, frame# 1276
usb-uhci.c: interrupt, status 3, frame# 1044
usb-uhci.c: interrupt, status 3, frame# 2004
usb-uhci.c: interrupt, status 3, frame# 308
usb-uhci.c: interrupt, status 3, frame# 500
usb-uhci.c: interrupt, status 3, frame# 1924

[root@laptop scsi]# pwd
/proc/scsi
[root@laptop scsi]# find
.
./usb-storage-1
./usb-storage-1/2
./usb-storage-0
./usb-storage-0/1
./sg
./sg/version
./sg/host_strs
./sg/host_hdr
./sg/hosts
./sg/device_strs
./sg/device_hdr
./sg/devices
./sg/debug
./sg/def_reserved_size
./sg/allow_dio
./ide-scsi
./ide-scsi/0
./scsi
[root@laptop scsi]# cat usb-storage-0/1
   Host scsi1: usb-storage
       Vendor: USB
      Product: Solid state disk
Serial Number: None
     Protocol: Transparent SCSI
    Transport: Bulk
         GUID: 0ed166600000000000000000
     Attached: Yes
[root@laptop scsi]# cat usb-storage-1/2
[root@laptop scsi]#
[root@laptop scsi]# fdisk /dev/sda
 
Unable to open /dev/sda
[root@laptop scsi]# fdisk /dev/sdb
 
Unable to open /dev/sdb
[root@laptop scsi]# cat scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: MATSHITA Model: UJDA710          Rev: 1.50
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor:          Model:                  Rev:
  Type:   <NULL>                ANSI SCSI revision: ffffffff

[root@laptop root]# modprobe -r usb-storage
[root@laptop scsi]# ls usb-
(hit tab here, bash segfaulted and the below kernel oops occured)
(Open another terminal...) 
[root@laptop root]# cd /proc/scsi/
[root@laptop scsi]# ls
(Gets stuck here forever...)
kill -9 fails to kill this ls process.

Unable to handle kernel paging request at virtual address e098a010
 printing eip:
c0166e3b
*pde = 0258f067
*pte = 00000000
Oops: 0002
sd_mod sr_mod sg via82cxxx_audio uart401 ac97_codec sound soundcore parport_pc
lp parport autofs ds yenta_socket pcmcia_core 8139too mii ipt_REJECT iptable_fi
CPU:    0
EIP:    0060:[<c0166e3b>]    Not tainted
EFLAGS: 00010286
 
EIP is at proc_get_inode [kernel] 0x9b (2.4.20-18.9)
eax: e098a000   ebx: d9ac51c0   ecx: 00000001   edx: 00000000
esi: d5dad3c0   edi: d9ac5219   ebp: d5a690c0   esp: df7cbe6c
ds: 0068   es: 0068   ss: 0068
Process bash (pid: 705, stackpage=df7cb000)
Stack: c25a5800 000011e8 00000000 00000000 000011e8 d5a6912d c0168e92 c25a5800
       000011e8 d9ac51c0 d9ac51c0 ffffffea 00000000 fffffff4 d25aed6c d25aed00
       d5a690c0 c014f857 d25aed00 d5a690c0 00000000 dfede00d fffffdee df7cbf48
Call Trace:   [<c0168e92>] proc_lookup [kernel] 0xd2 (0xdf7cbe84))
[<c014f857>] real_lookup [kernel] 0xc7 (0xdf7cbeb0))
[<c014fda9>] link_path_walk [kernel] 0x3f9 (0xdf7cbecc))
[<c0150249>] path_lookup [kernel] 0x39 (0xdf7cbf0c))
[<c01504d9>] __user_walk [kernel] 0x49 (0xdf7cbf1c))
[<c0168f32>] proc_readdir [kernel] 0x92 (0xdf7cbf24))
[<c014beff>] vfs_stat [kernel] 0x1f (0xdf7cbf38))
[<c015401d>] vfs_readdir [kernel] 0x9d (0xdf7cbf54))
[<c014c55b>] sys_stat64 [kernel] 0x1b (0xdf7cbf70))
[<c0145795>] fput [kernel] 0xd5 (0xdf7cbf7c))
[<c0143e2d>] filp_close [kernel] 0x4d (0xdf7cbf98))
[<c0143eae>] sys_close [kernel] 0x4e (0xdf7cbfb0))
[<c010939f>] system_call [kernel] 0x33 (0xdf7cbfc0))
 
 
Code: ff 40 10 8b 43 24 83 48 14 18 8b 43 18 85 c0 74 06 89 86 8c

Warren, please do this:
- Log in
- Make sure that klogd runs with -x flag
- Connect the keychain
- Run  echo 1 > /proc/sys/kernel/sysrq
- Hit <Alt><SysRq>T  (lots of console output)
- DO NOT do modprobe -r or anything that oopses it
- Attach /var/log/messages and /proc/bus/usb/devices
  (Please do not drop it in the comments box!)
The idea is to see where the hotplug thread is stuck. If I can fix
that I can fix the oops (although not the device). Next, with right
numbers, we may be able to look at working around protocol violations.

This USB storage device seems to be working fine in Arjan's
kernel-2.6.0-0.test2.1.29.

Linux laptop 2.6.0-0.test2.1.29 #1 Sun Aug 3 17:23:16 EDT 2003 i686 athlon i386
GNU/Linux

[root@laptop scsi]# pwd
/proc/scsi
[root@laptop scsi]# cat scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: MATSHITA Model: UJDA710          Rev: 1.50
  Type:   CD-ROM                           ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: USB      Model: Solid state disk Rev: 0100
  Type:   Direct-Access                    ANSI SCSI revision: 02
[root@laptop scsi]# cat usb-storage/2
   Host scsi2: usb-storage
       Vendor: USB
      Product: Solid state disk
Serial Number: None
     Protocol: Transparent SCSI
    Transport: Bulk
       Quirks: FIX_INQUIRY
[root@laptop scsi]# find
.
./usb-storage
./usb-storage/2
./usb-storage
./usb-storage/2
./device_info
./scsi

Except for the extra directories within /proc/scsi of the same name that occur
after moving usb-storage module and inserting it again.  Arjan is that bug serious?

Testing Severn 2.4 kernel using Pete's suggested procedure next.

Created attachment 93474 [details]
2.4.21-20.1.2024.2.1.nptl /var/log/messages from Comment #10

Created attachment 93475 [details]
2.4.21-20.1.2024.2.1.nptl /proc/bus/usb/devices from Comment #10

Perfect, thanks for stopping all those extra processes.
The trace still overflows, but only by a fraction.

I did not expect hotplug to exit properly though. The problem
needs some more thinking.

Asking Warren to test an unusual_devs.h patchlet with the "short INQUIRY" quirk.

I am happy to report success with your kernel patch with
2.4.21-20.1.2024.2.1.nptl.  Tested doing various read/write operations,
mounting, unmounting, loading module, unloading module, and mkfs across the
entire device.

May I ask:
1) What does the INQUIRY quirk mode do?
2) Is this acceptable for submission to Marcelo?

Thanks!

Created attachment 93526 [details]
Candidate fix

Apparently, a number of controllers accept only 36 bytes of INQUIRY,
no more, no less. If anything else is asked, their microcode crashes
(and then you see the "usb-uhci.c: interrupt, status 3, frame# NNN").

Forgot to mention, this has to go through Greg Kroah upstream.
Marcelo will not take it over Greg's head.

Did Greg Kroah accept this patch?  (Just cleaning up My Bugs.)

You mean, Matt Dharm? No, he waited until PR_DEVICE/SC_DEVICE came
about, then got this:

/* Submitted by Antoine Mairesse <antoine.mairesse> */
UNUSUAL_DEV( 0x0ed1, 0x6660, 0x0100, 0x0300,
 		"USB",
 		"Solid state disk",
 		US_SC_DEVICE, US_PR_DEVICE, NULL,
 		US_FL_FIX_INQUIRY ),

Warren, does Fedora work?

Arjan's kernel-2.6.0-0.test9.1.90 seems to work perfectly, but there
are severe problems with FC1's kernel-2.4.22-1.2115.nptl.  Upon
plugging it seems to appear in /proc/scsi twice as usb-storage-0 and
usb-storage-1, appear briefly in /proc/scsi/scsi, but disappear soon
after.  The following is in dmesg.

Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi0 : SCSI emulation for USB Mass Storage devices
usb.c: USB disconnect on device 00:07.2-2 address 6
hub.c: new USB device 00:07.2-2, assigned address 7
Unable to handle kernel NULL pointer dereference at virtual address
00000024
 printing eip:
e095d0e2
*pde = 10d61067
*pte = 00000000
Oops: 0000
usb-storage sd_mod vfat fat parport_pc lp parport autofs ds
yenta_socket pcmcia_core iptable_filter ip_tables 8139too mii floppy
sg sr_mod ide-scsi ide-cd cdr
CPU:    0
EIP:    0060:[<e095d0e2>]    Not tainted
EFLAGS: 00010246
 
EIP is at sg_open [sg] 0x62 (2.4.22-1.2115.nptl)
eax: 00000000   ebx: 00000800   ecx: ffffffed   edx: df1d1c00
esi: dec346c0   edi: fffffff0   ebp: 00000000   esp: d0f1ff00
ds: 0068   es: 0068   ss: 0068
Process updfstab (pid: 6740, stackpage=d0f1f000)
Stack: 00000000 c0144849 e095d000 deb5f640 dd0f4005 00000003 0028b1dc
df65c740
       d0f1ff84 dd0f4000 00000000 00000000 d0f28340 deb708c0 dfeb2380
c01449ae
       deb708c0 d0f28340 d0f28340 deb708c0 ffffffe9 c0143063 deb708c0
d0f28340
Call Trace:   [<c0144849>] get_chrfops [kernel] 0xd9 (0xd0f1ff04)
[<c01449ae>] chrdev_open [kernel] 0x5e (0xd0f1ff3c)
[<c0143063>] dentry_open [kernel] 0xd3 (0xd0f1ff54)
[<c0142f87>] filp_open [kernel] 0x67 (0xd0f1ff70)
[<c0143323>] sys_open [kernel] 0x53 (0xd0f1ffa8)
[<c01099df>] system_call [kernel] 0x33 (0xd0f1ffc0)
 
 
Code: 8b 40 24 8b 40 04 85 c0 74 14 ff 40 10 8b 06 8b 40 10 8b 40
 <4>usb-uhci.c: interrupt, status 3, frame# 573
scsi: device set offline - not ready or command retry failed after bus
reset: host 0 channel 0 id 0 lun 0
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 6
USB Mass Storage support registered.
scsi2 : SCSI emulation for USB Mass Storage devices
Unable to handle kernel NULL pointer dereference at virtual address
00000024
 printing eip:
e095d0e2
*pde = 14e5d067
*pte = 00000000
Oops: 0000
usb-storage sd_mod vfat fat parport_pc lp parport autofs ds
yenta_socket pcmcia_core iptable_filter ip_tables 8139too mii floppy
sg sr_mod ide-scsi ide-cd cdr
CPU:    0
EIP:    0060:[<e095d0e2>]    Not tainted
EFLAGS: 00010246
 
EIP is at sg_open [sg] 0x62 (2.4.22-1.2115.nptl)
eax: 00000000   ebx: 00000800   ecx: ffffffed   edx: df1d1c00
esi: dec346c0   edi: fffffff0   ebp: 00000000   esp: d5189f00
ds: 0068   es: 0068   ss: 0068
Process updfstab (pid: 6743, stackpage=d5189000)
Stack: 00000000 c0144849 e095d000 deb5f640 dffbc005 00000003 0028b1dc
df65c740
       d5189f84 dffbc000 00000000 00000000 d4cd8cc0 deb708c0 dfeb2380
c01449ae
       deb708c0 d4cd8cc0 d4cd8cc0 deb708c0 ffffffe9 c0143063 deb708c0
d4cd8cc0
Call Trace:   [<c0144849>] get_chrfops [kernel] 0xd9 (0xd5189f04)
[<c01449ae>] chrdev_open [kernel] 0x5e (0xd5189f3c)
[<c0143063>] dentry_open [kernel] 0xd3 (0xd5189f54)
[<c0142f87>] filp_open [kernel] 0x67 (0xd5189f70)
[<c0143323>] sys_open [kernel] 0x53 (0xd5189fa8)
[<c01099df>] system_call [kernel] 0x33 (0xd5189fc0)
 
 
Code: 8b 40 24 8b 40 04 85 c0 74 14 ff 40 10 8b 06 8b 40 10 8b 40

Warren, did 2.4.22-1.2140 work?

Also, current Fedora has "DEVICE" accessors for unusual_devs.h.

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/