Re: [linux-usb-devel] Fw: [BUG] USB Storage OOPS and a D state process in 2.6.10

[Srihari Vijayaraghavan <harisri@internode.on.net>]

[-- Attachment #1: Type: text/plain, Size: 4297 bytes --]

On Monday 10 January 2005 04:32, Alan Stern wrote:
> If you're unable to trigger the bug, you can try turning the debug
> configuration option back off and using that patch I sent earlier.  It
> wouldn't hurt to use that patch even with the debugging messages...

I have disabled the USB storage debug option. Your patch unfortunately did not 
apply cleanly, so I did it manually, and here is the correct patch:
--- test/drivers/usb/storage/scsiglue.c.orig 2005-01-10 18:31:36.453932344 
+1100
+++ test/drivers/usb/storage/scsiglue.c 2005-01-10 18:37:57.329030528 +1100
@@ -268,9 +268,15 @@
 /* This is always called with scsi_lock(srb->host) held */
 static int bus_reset(struct scsi_cmnd *srb)
 {
- struct us_data *us = (struct us_data *)srb->device->host->hostdata[0];
+ struct us_data *us;
  int result, rc;
 
+ printk(KERN_INFO "In bus_reset, srb: %p\n", srb);
+ printk("  device: %p\n", srb->device);
+ printk("  host: %p\n", srb->device->host);
+ printk("  hostdata: %p\n", (void *) srb->device->host->hostdata[0]);
+
+ us = (struct us_data *)srb->device->host->hostdata[0];
  US_DEBUGP("%s called\n", __FUNCTION__);
 
  scsi_unlock(srb->device->host);


I am unable to trigger the bug, despite my sincere efforts. But I have managed 
to push "hald" process in to D state.
Jan 10 21:06:41 desktop kernel: hald          D 000001003776d938     0  3367      
1          3429  3357 (NOTLB)
Jan 10 21:06:41 desktop kernel: 000001003776d898 0000000000000002 
000000732b17d078 000001003f771650
Jan 10 21:06:41 desktop kernel:        00000000000007fd 000001003fed2070 
0000010037d71640 0000010038e3d000
Jan 10 21:06:41 desktop kernel:        000001002b17d078 000001003776d938
Jan 10 21:06:41 desktop kernel: Call 
Trace:<ffffffff802c11eb>{wait_for_completion+139} 
<ffffffff8012dc20>{default_wake_function+0}
Jan 10 21:06:41 desktop kernel:        
<ffffffff8012dc20>{default_wake_function+0} 
<ffffffffa0004f7b>{:scsi_mod:scsi_wait_req+91}
Jan 10 21:06:41 desktop kernel:        
<ffffffffa0000038>{:scsi_mod:scsi_allocate_request+56}
Jan 10 21:06:41 desktop kernel:        
<ffffffffa023a33c>{:sr_mod:sr_do_ioctl+156} 
<ffffffffa023a654>{:sr_mod:sr_audio_ioctl+372}
Jan 10 21:06:41 desktop kernel:        
<ffffffffa0004fac>{:scsi_mod:scsi_wait_req+140} 
<ffffffff8023f71e>{cdrom_count_tracks+222}
Jan 10 21:06:41 desktop kernel:        <ffffffff8023f9a0>{cdrom_open+448} 
<ffffffffa00471f4>{:ext3:ext3_get_block_handle+228}
Jan 10 21:06:41 desktop kernel:        <ffffffff8014ef4e>{find_get_page+14} 
<ffffffff8016ce4c>{__find_get_block_slow+220}
Jan 10 21:06:41 desktop kernel:        
<ffffffff8016d519>{__find_get_block+377} <ffffffff8016f87f>{__getblk+31}
Jan 10 21:06:41 desktop kernel:        <ffffffff801af4ba>{avc_has_perm+90} 
<ffffffff801af4ba>{avc_has_perm+90}
Jan 10 21:06:41 desktop kernel:        <ffffffff801af4ba>{avc_has_perm+90} 
<ffffffff801b02b4>{task_has_capability+100}
Jan 10 21:06:41 desktop kernel:        <ffffffff801c2992>{kobject_get+18} 
<ffffffff801c2992>{kobject_get+18}
Jan 10 21:06:41 desktop kernel:        
<ffffffffa0239730>{:sr_mod:sr_block_open+176} <ffffffff8017286a>{do_open+170}
Jan 10 21:06:41 desktop kernel:        <ffffffff80172c5f>{blkdev_open+47} 
<ffffffff8016aa36>{dentry_open+230}
Jan 10 21:06:41 desktop kernel:        <ffffffff8016ab7e>{filp_open+62} 
<ffffffff8016abc7>{get_unused_fd+55}
Jan 10 21:06:41 desktop kernel:        <ffffffff8016ad4c>{sys_open+76} 
<ffffffff8010e1da>{system_call+126}
Jan 10 21:06:41 desktop kernel:


Please refer to the attachment for the complete kernel log.

I think I understand the problem (conceptually I guess):
1. Connect the USB DVD-RW drive
2. USB Storage says: "usb-storage: device found at nnn" and "usb-storage: 
waiting for device to settle before scanning"
3. And then it waits for 5+ seconds
4. Then it initialises the peripheral and then says: "Vendor: PIONEER   Model: 
DVD-RW  DVR-107D  Rev: 1.13 ..." and "usb-storage: device scan complete"

I think if I unplug the device precisely the same moment when it initialises 
(step 4), and by time that routine completes kernel is really unhappy (D 
state process,  Badness in scsi_device_set_state at 
drivers/scsi/scsi_lib.c:1717, and/or oops) to discover that the drive is not 
there anymore :-).

I do not know what else to do.

Thank you.
Hari

[-- Attachment #2: kernel.log.bz2 --]
[-- Type: application/x-bzip2, Size: 6591 bytes --]