On Thu, 12 Feb 2004, Chris Rankin wrote: > [Linux 2.6.2, dual Xeon (Northwood), Hyperthreaded, 1 > GB RAM, compiled with gcc version 3.2.3 20030422 (Red > Hat Linux 3.2.3-6)] > > Hi, > > Somebody lent me a "dodgy" 512 MB SD Card, to see if I > could read it under Linux. (It was known to fail under > W2K.) Anyway, I plugged it into my USB 2.0 memory card > reader, loaded the sd_mod driver, and waited... > > The SCSI disk device was recognized, but the > filesystem never became available and the light on the > reader device stayed lit. Eventually I unplugged the > USB device in an attempt to unblock the process - it > didn't work. Similarly trying to disable hotplugging. > I soon realised that I would need to reboot and so I > pressed SysRq-T in order to get a trace. (Attached.) > > I have enabled NMI, but never received an NMI oops. > > It looks as if the scsi_eh_2 process has deadlocked > somehow. The circumstances are certainly exceptional, > but I would hope that Linux would be robust enough to > handle these errors.
It's clear from your log that some sort of error occurred while the system was trying to access your memory card. You can get more information about the problem (if you want it) by turning on usb-storage debugging in your kernel's configuration. It wouldn't hurt to turn on USB debugging too. The lock-up you observed happened during error recovery, in the bus_reset() function in the usb-storage driver. I don't really understand your stack trace, since it says: Feb 12 21:08:37 volcano kernel: scsi_eh_2 D 00000001 0 17094 1 17330 17093 (L-TLB) Feb 12 21:08:37 volcano kernel: dafc9ed0 00000046 c1a1bc80 00000001 0000000f 00000000 00000000 00000001 Feb 12 21:08:37 volcano kernel: dafc9e98 dafc9e98 f7c88020 00000000 00000000 c1a1bc80 000054d4 4a57e0ab Feb 12 21:08:37 volcano kernel: 000272a9 f679e080 f679e248 f89a598c f679e080 dafc9edc dafc9fa0 c01a2b7a Feb 12 21:08:37 volcano kernel: Call Trace: Feb 12 21:08:37 volcano kernel: [<c01a2b7a>] rwsem_down_read_failed+0x82/0x125 Feb 12 21:08:37 volcano kernel: [<f898fb4a>] .text.lock.hub+0xec/0x10a [usbcore] Feb 12 21:08:37 volcano kernel: [<f8d6f2d8>] bus_reset+0xcf/0xd3 [usb_storage] The address on the stack is only 4 bytes away from the end of bus_reset(), which doesn't make any sense. The bus_reset() procedure (which involves doing a USB port reset) has always been a bit iffy, especially when it occurs during initial probing as it did here. More information would be useful for tracking down the exact problem. Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
