On 21.04.2004 17:39, Patrick Mansfield wrote:

On Wed, Apr 21, 2004 at 12:54:36PM -0700, Aleksey Nogin wrote:

However, is still only works when connected directly. If connected through a hub, when I start copying files, after transferring in the range of 100-500KB, the system thinks that the hub was disconnected, data transfer gets stuck, then it thinks that the mouse (that is attached to the hub) is disconnected, then it thinks that the mouse is back, then everything becomes stuck. If I turn the camera off at this point, it results in a kernel oops...


Where's the oops?

Here is what I saw I time during my experimentations with unusual_devs.h:


Apr 19 23:04:21 kernel: usb 1-1.3: USB disconnect, address 9
Apr 19 23:04:29 kernel: scsi: Device offlined - not ready after error recovery: host 4 channel 0 id 0 lun 0
Apr 19 23:04:29 kernel: sd 4:0:0:0: Illegal state transition cancel->offline
Apr 19 23:04:29 kernel: Badness in scsi_device_set_state at drivers/scsi/scsi_lib.c:1640
Apr 19 23:04:29 kernel: Call Trace:
Apr 19 23:04:29 kernel: [<e0ab6703>] scsi_device_set_state+0xb4/0xbf [scsi_mod]
Apr 19 23:04:29 kernel: [<e0ab3ab7>] scsi_eh_offline_sdevs+0x49/0x62 [scsi_mod]
Apr 19 23:04:29 kernel: [<e0ab419f>] scsi_unjam_host+0x24c/0x25d [scsi_mod]
Apr 19 23:04:29 kernel: [<e0ab4406>] scsi_error_handler+0x256/0x2ad [scsi_mod]
Apr 19 23:04:29 kernel: [<e0ab41b0>] scsi_error_handler+0x0/0x2ad [scsi_mod]
Apr 19 23:04:29 kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb


Followed by

Apr 19 23:04:47 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000110
Apr 19 23:04:47 kernel: printing eip:
Apr 19 23:04:47 kernel: e0ab2316
Apr 19 23:04:47 kernel: *pde = 0445d067
Apr 19 23:04:47 kernel: Oops: 0000 [#1]
Apr 19 23:04:47 kernel: CPU: 0
Apr 19 23:04:47 kernel: EIP: 0060:[<e0ab2316>] Not tainted
Apr 19 23:04:47 kernel: EFLAGS: 00210282 (2.6.5-1.327custom)
Apr 19 23:04:47 kernel: EIP is at scsi_block_when_processing_errors+0x8/0xa7 [scsi_mod]
Apr 19 23:04:47 kernel: eax: dbd05000 ebx: dbd05000 ecx: 00000000 edx: c1a5c200
Apr 19 23:04:47 kernel: esi: d0972540 edi: d80e9300 ebp: c1a5c200 esp: c40c8f04
Apr 19 23:04:47 kernel: ds: 007b es: 007b ss: 0068
Apr 19 23:04:47 kernel: Process umount (pid: 7116, threadinfo=c40c8000 task=c6cf1360)
Apr 19 23:04:47 kernel: Stack: 00000000 00000000 00000000 00000000 00000000 d80e9300 d80e9300 d80e9300
Apr 19 23:04:47 kernel: dbd05000 e0e21621 00000001 d80e9300 c0167a01 d80e9368 00000000 e0e24380
Apr 19 23:04:47 kernel: d80e9300 d80e9080 c1a5c200 c0167a9a d80e90e8 00000000 db8d7840 db8d7800
Apr 19 23:04:47 kernel: Call Trace:
Apr 19 23:04:47 kernel: [<e0e21621>] sd_release+0x4c/0x65 [sd_mod]
Apr 19 23:04:47 kernel: [<c0167a01>] blkdev_put+0x111/0x25a
Apr 19 23:04:47 kernel: [<c0167a9a>] blkdev_put+0x1aa/0x25a
Apr 19 23:04:47 kernel: [<c0163f32>] deactivate_super+0xc4/0x1e8
Apr 19 23:04:47 kernel: [<c017fc12>] sys_umount+0x5d/0x64
Apr 19 23:04:47 kernel: [<c0150162>] unmap_vma_list+0xe/0x17
Apr 19 23:04:47 kernel: [<c015068a>] do_munmap+0x1dc/0x1e6
Apr 19 23:04:47 kernel: [<c017fc24>] sys_oldumount+0xb/0xe
Apr 19 23:04:47 kernel: [<c02e8d3b>] syscall_call+0x7/0xb
Apr 19 23:04:47 kernel:
Apr 19 23:04:47 kernel: Code: 8b 81 10 01 00 00 a8 08 74 61 b8 00 f0 ff ff 89 e2 21 e0 8b


This sounds like a badness John sent to me about a USB
cdrom device that gets an error, and when it is later removed hits a
WARN_ON in scsi_device_set_state.

Here's the back trace:

sr 7:0:0:0: Illegal state transition offline->cancel
Badness in scsi_device_set_state at drivers/scsi/scsi_lib.c:1640
Call Trace:
 [<c02b20e5>] scsi_device_set_state+0xbe/0x10b
 [<c02ac93b>] scsi_device_cancel+0x29/0xf4
 [<c02acad5>] scsi_device_cancel_cb+0x0/0x1c
 [<c0238dd7>] device_for_each_child+0x3e/0x6e
 [<c02acb27>] scsi_host_cancel+0x36/0xab
 [<c02acad5>] scsi_device_cancel_cb+0x0/0x1c
 [<c0344af1>] usb_buffer_free+0x45/0x47
 [<c02acbb7>] scsi_remove_host+0x1b/0x5c
 [<c0360bf1>] storage_disconnect+0x39/0x49
 [<c0343b64>] usb_unbind_interface+0x7a/0x7c
 [<c0239b46>] device_release_driver+0x64/0x66
 [<c0239c6d>] bus_remove_device+0x56/0x98
 [<c0238d40>] device_del+0x5f/0x95
 [<c0238d89>] device_unregister+0x13/0x23
 [<c03495f5>] usb_disable_device+0x71/0xac
 [<c0344451>] usb_disconnect+0x9c/0xe9
 [<c0346482>] hub_port_connect_change+0x282/0x287
 [<c0345e39>] hub_port_status+0x45/0xb0
 [<c03467a9>] hub_events+0x322/0x36e
 [<c0346826>] hub_thread+0x31/0xd1
 [<c0111f86>] default_wake_function+0x0/0x12
 [<c03467f5>] hub_thread+0x0/0xd1
 [<c0102209>] kernel_thread_helper+0x5/0xb

Another time when I was testing the scsi_scan patch, I saw a one with the hub_thread in it, but the machine became completely unresponsive before I got a chance to capture it.


--
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: [EMAIL PROTECTED] (office), [EMAIL PROTECTED] (personal)
Office: Jorgensen 70, tel: (626) 395-2907


------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to