Re: [RFC] aio: remove retry and cancel
On 2012-10-16 19:15, Benjamin LaHaise wrote: > On Tue, Oct 16, 2012 at 10:00:54AM -0700, Zach Brown wrote: >>> Not all IOs will complete within a bounded amount of time. Think of things >>> like pipes, network send/receive, even the USB gadget code. >> >> Yes, I know. That's the theoretical position. >> >> But reality doesn't match that view. People aren't using it. If the > > But that's an issue of the lack of support for the functionality. The > kernel doesn't implement the functionality for 99.99% of file descriptors, > so of course it's not going to be used. If, as we were chatting about, > other uses can be made possible by using a thread pool or some as yet > undecided approach, it will be required. > > Let's address the lack of support issue before deprecating required parts > of the API. Or make the case to rip everything out. Come on, this has been the case for, what, 10 years? Or for however long that we've had this aio interface. I'd be happy just bypassing the cancel, in fact I did just that to actually make aio scale to any extent at all. But using the lack of a support as an argument to keep that interface is just a non-starter to begin with. It's clearly NEVER goint to get done. >> usb gadget code can do without then the actual users of aio can be made >> a wee bit faster without having to build cancel code without users to >> hammer on it. > > Gadget cannot. The code has no control over when a request completes. > Think of things like talking to a USB serial port or keyboard directly. > Afaik it is getting used for USB direct access in a number of cases, which > goes to show that if the functionality is implemented, people will use it. IMHO, just bypassing the cancel bits for things that don't implement it (that is, anything but usb gadget) is trivial. It's part of the lots of low hanging fruit in aio. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Mon, Jan 28 2008, Greg KH wrote: > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > > Hi, > > > > Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > > connecting my cf usb storage device yields and endless stream of: > > > > Initializing USB Mass Storage driver... > > scsi6 : SCSI emulation for USB Mass Storage devices > > usb-storage: device found at 2 > > usb-storage: waiting for device to settle before scanning > > usbcore: registered new interface driver usb-storage > > USB Mass Storage support registered. > > scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > > ANSI: 0 > > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > > sd 6:0:0:0: [sdb] Write Protect is off > > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > > sd 6:0:0:0: [sdb] Assuming drive cache: write through > > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > > sd 6:0:0:0: [sdb] Write Protect is off > > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > > sd 6:0:0:0: [sdb] Assuming drive cache: write through > > sdb: sdb1 > > sd 6:0:0:0: [sdb] Attached SCSI removable disk > > sd 6:0:0:0: Attached scsi generic sg1 type 0 > > scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > > ANSI: 0 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > [...] > > > > until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > > I'm attaching boot messages and my .config. > > That's a bit wierd, as we haven't added any USB patches to the -git tree > yet after 2.6.24 :) > > Could this be caused by some scsi changes perhaps? Heh, I guess it could! I'll double check, I reproduced it with two distinct boots before posting. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > >> Greg KH wrote: > >>> On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > >>>> Hi, > >>>> > >>>> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > >>>> connecting my cf usb storage device yields and endless stream of: > >>>> > >>>> Initializing USB Mass Storage driver... > >>>> scsi6 : SCSI emulation for USB Mass Storage devices > >>>> usb-storage: device found at 2 > >>>> usb-storage: waiting for device to settle before scanning > >>>> usbcore: registered new interface driver usb-storage > >>>> USB Mass Storage support registered. > >>>> scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >>>> ANSI: 0 > >>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >>>> sd 6:0:0:0: [sdb] Write Protect is off > >>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >>>> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >>>> sd 6:0:0:0: [sdb] Write Protect is off > >>>> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >>>> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >>>> sdb: sdb1 > >>>> sd 6:0:0:0: [sdb] Attached SCSI removable disk > >>>> sd 6:0:0:0: Attached scsi generic sg1 type 0 > >>>> scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >>>> ANSI: 0 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>> [...] > >>>> > >>>> until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > >>>> I'm attaching boot messages and my .config. > >>> That's a bit wierd, as we haven't added any USB patches to the -git tree > >>> yet after 2.6.24 :) > >>> > >>> Could this be caused by some scsi changes perhaps? > >>> > >>> thanks, > >>> > >>> greg k-h > >>> - > >> Yes it is ;) > >> > >> Jens could you test the patch below? if it works I'll submit a proper > >> patch. Please forgive me for the bug. > > > > No difference, still just a lot of resets. > > > Where you able to figure out which usb storage transport is used? > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport() > functions. I'm not sure if these get stored in sysfs perhaps. This will > pinpoint better where to look. Let me research a bit. Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and transport is 'Bulk' -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: > Greg KH wrote: > > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > >> Hi, > >> > >> Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > >> connecting my cf usb storage device yields and endless stream of: > >> > >> Initializing USB Mass Storage driver... > >> scsi6 : SCSI emulation for USB Mass Storage devices > >> usb-storage: device found at 2 > >> usb-storage: waiting for device to settle before scanning > >> usbcore: registered new interface driver usb-storage > >> USB Mass Storage support registered. > >> scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > >> sd 6:0:0:0: [sdb] Write Protect is off > >> sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > >> sd 6:0:0:0: [sdb] Assuming drive cache: write through > >> sdb: sdb1 > >> sd 6:0:0:0: [sdb] Attached SCSI removable disk > >> sd 6:0:0:0: Attached scsi generic sg1 type 0 > >> scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > >> ANSI: 0 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >> [...] > >> > >> until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > >> I'm attaching boot messages and my .config. > > > > That's a bit wierd, as we haven't added any USB patches to the -git tree > > yet after 2.6.24 :) > > > > Could this be caused by some scsi changes perhaps? > > > > thanks, > > > > greg k-h > > - > Yes it is ;) > > Jens could you test the patch below? if it works I'll submit a proper > patch. Please forgive me for the bug. No difference, still just a lot of resets. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Oliver Neukum wrote: > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > >> Greg KH wrote: > > > > > No difference, still just a lot of resets. > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and get_transport() > > > functions. I'm not sure if these get stored in sysfs perhaps. This will > > > pinpoint better where to look. Let me research a bit. > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and > > transport is 'Bulk' > > You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG > That should tell the reason for the resets. Sure, I'll do that. Will post the results tonight. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Jens Axboe wrote: > On Tue, Jan 29 2008, Matthew Dharm wrote: > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > PROTECTED]> wrote: > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > get_transport() > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > This will > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > > > > > > and > > > > > > transport is 'Bulk' > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > CONFIG_STORAGE_DEBUG > > > > > That should tell the reason for the resets. > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > messages. > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > 4 of 192 bytes. > > > > No, that's not the problem. This is the problem: > > It's where the problem starts, otherwise there would not be a need to > sense :-) > > > > usb-storage: *** thread awakened. > > > usb-storage: Command TEST_UNIT_READY (6 bytes) > > > usb-storage: 00 00 00 00 00 00 > > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > usb-storage: Status code 0; transferred 31/31 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk command transfer result=0 > > > usb-storage: Attempting to get CSW... > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > > > usb-storage: Status code 0; transferred 13/13 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk status result = 0 > > > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > > > usb-storage: -- transport indicates command failure > > > usb-storage: Issuing auto-REQUEST_SENSE > > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > usb-storage: Status code 0; transferred 31/31 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk command transfer result=0 > > > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > > > usb-storage: usb_sg_init returned -22 > > > usb-storage: Bulk data transfer result 0x4 > > > usb-storage: -- auto-sense failure > > > usb-storage: storage_pre_reset > > > ehci_hcd :00:1d.7: port 1 high speed > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > CONNECT > > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > > ehci_hcd :00:1d.7: port 1 high speed > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > CONNECT > > > usb-storage: storage_post_reset > > > usb-storage: usb_reset_composite_device returns 0 > > > usb-storage: scsi cmd done, result=0x7 > > > usb-storage: *** thread sleeping. > > > > For some reason, usb_sg_init is boned during auto-sense. > > My guess would be that sg == NULL, hence the -EINVAL. Yep, trace below: WARNING: at drivers/usb/storage/transport.c:426 usb_stor_bulk_transfer_sglist() Pid: 12536, comm: usb-storage Not tainted 2.6.24 #74 [<7810541a>] show_trace_log_lvl+0x1a/0x30 [<78105e82>] show_trace+0x12/0x20 [<7810689c>] dump_stack+0x6c/0x80 [] usb_stor_bulk_transfer_sglist+0x14e/0x160 [usb_storage] [] usb_stor_bulk_srb_length+0x30/0x50 [usb_storage] [] usb_stor_bulk_srb+0x12/0x20 [usb_storage] [] usb_stor_Bulk_transport+0x190/0x3d0 [usb_storage] [] usb_stor_invoke_transport+0x1b6/0x320 [usb_storage] [] usb_stor_transparent_scsi_command+0x8/0x10 [usb_storage] [] usb_stor_control_thread+0x143/0x2c0 [usb_storage] [<7813bc02>] kthread+0x42/0x70 [<78104fab>] kernel_thread_helper+0x7/0x1c === usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries, sg usb-storage: usb_sg_init returned -22 -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Matthew Dharm wrote: > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> > > > > > > wrote: > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > >> Greg KH wrote: > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > get_transport() > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. This > > > > > > will > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and > > > > > transport is 'Bulk' > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > CONFIG_STORAGE_DEBUG > > > > That should tell the reason for the resets. > > > > > > Sure, I'll do that. Will post the results tonight. > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > in the device, waited 10 seconds or so and pulled it out. These are the > > messages. > > > > It all looks good until the MODE_SENSE command, where it only transfers > > 4 of 192 bytes. > > No, that's not the problem. This is the problem: It's where the problem starts, otherwise there would not be a need to sense :-) > > usb-storage: *** thread awakened. > > usb-storage: Command TEST_UNIT_READY (6 bytes) > > usb-storage: 00 00 00 00 00 00 > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > usb-storage: Status code 0; transferred 31/31 > > usb-storage: -- transfer complete > > usb-storage: Bulk command transfer result=0 > > usb-storage: Attempting to get CSW... > > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > > usb-storage: Status code 0; transferred 13/13 > > usb-storage: -- transfer complete > > usb-storage: Bulk status result = 0 > > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > > usb-storage: -- transport indicates command failure > > usb-storage: Issuing auto-REQUEST_SENSE > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > usb-storage: Status code 0; transferred 31/31 > > usb-storage: -- transfer complete > > usb-storage: Bulk command transfer result=0 > > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > > usb-storage: usb_sg_init returned -22 > > usb-storage: Bulk data transfer result 0x4 > > usb-storage: -- auto-sense failure > > usb-storage: storage_pre_reset > > ehci_hcd :00:1d.7: port 1 high speed > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > CONNECT > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > ehci_hcd :00:1d.7: port 1 high speed > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > CONNECT > > usb-storage: storage_post_reset > > usb-storage: usb_reset_composite_device returns 0 > > usb-storage: scsi cmd done, result=0x7 > > usb-storage: *** thread sleeping. > > For some reason, usb_sg_init is boned during auto-sense. My guess would be that sg == NULL, hence the -EINVAL. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: > >> > > Ok this is not in Linus tree is it? Hence I did not have that failure. > > > > Boaz > > > > > > actually James bidi tree has a fix for this in the scsi_data_buffer patch. > > what you sent is not enough there are other places. look at this patch I > sent to the list. > > http://www.spinics.net/lists/linux-scsi/msg21938.html Hard to compare, since its on different bases. > Could we take the 2 SG patches and submit them through the scsi > bidi tree? It is much more natural to have them in one tree as one > patchset then try coordinate with git-merge. Actually if you look at it, > the biggest change is to SCSI. So I think it is more natural this way What 2 sg patches do you mean? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, James Bottomley wrote: > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > PROTECTED]> wrote: > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is used? > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > get_transport() > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > This will > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > > > > > > and > > > > > > transport is 'Bulk' > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > CONFIG_STORAGE_DEBUG > > > > > That should tell the reason for the resets. > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > messages. > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > 4 of 192 bytes. > > > > No, that's not the problem. This is the problem: > > > > > usb-storage: *** thread awakened. > > > usb-storage: Command TEST_UNIT_READY (6 bytes) > > > usb-storage: 00 00 00 00 00 00 > > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > usb-storage: Status code 0; transferred 31/31 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk command transfer result=0 > > > usb-storage: Attempting to get CSW... > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > > > usb-storage: Status code 0; transferred 13/13 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk status result = 0 > > > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > > > usb-storage: -- transport indicates command failure > > > usb-storage: Issuing auto-REQUEST_SENSE > > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > usb-storage: Status code 0; transferred 31/31 > > > usb-storage: -- transfer complete > > > usb-storage: Bulk command transfer result=0 > > > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > > > usb-storage: usb_sg_init returned -22 > > > usb-storage: Bulk data transfer result 0x4 > > > usb-storage: -- auto-sense failure > > > usb-storage: storage_pre_reset > > > ehci_hcd :00:1d.7: port 1 high speed > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > CONNECT > > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > > ehci_hcd :00:1d.7: port 1 high speed > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > CONNECT > > > usb-storage: storage_post_reset > > > usb-storage: usb_reset_composite_device returns 0 > > > usb-storage: scsi cmd done, result=0x7 > > > usb-storage: *** thread sleeping. > > > > For some reason, usb_sg_init is boned during auto-sense. > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense > code ... that was also an update in 2.6.24 yeah, already found the bug - it's assuming ->request_buffer holds the sglist, oops. Preparing a fix. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Jens Axboe wrote: > On Tue, Jan 29 2008, James Bottomley wrote: > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > > > On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > > On Tue, Jan 29 2008, Oliver Neukum wrote: > > > > > > Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > > On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > > > > > > PROTECTED]> wrote: > > > > > > > > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > > > > > > >> Greg KH wrote: > > > > > > > > > > > > > > > No difference, still just a lot of resets. > > > > > > > > > > > > > > > > > Where you able to figure out which usb storage transport is > > > > > > > > used? > > > > > > > > > > > > > > > > in drivers/usb/storage/usb.c you have get_protocol() and > > > > > > > > get_transport() > > > > > > > > functions. I'm not sure if these get stored in sysfs perhaps. > > > > > > > > This will > > > > > > > > pinpoint better where to look. Let me research a bit. > > > > > > > > > > > > > > Did the quick'n easy and dumped it. Protocol is 'Transparent > > > > > > > SCSI' and > > > > > > > transport is 'Bulk' > > > > > > > > > > > > You can recompile your kernel with CONFIG_USB_DEBUG and > > > > > > CONFIG_STORAGE_DEBUG > > > > > > That should tell the reason for the resets. > > > > > > > > > > Sure, I'll do that. Will post the results tonight. > > > > > > > > OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > > > > in the device, waited 10 seconds or so and pulled it out. These are the > > > > messages. > > > > > > > > It all looks good until the MODE_SENSE command, where it only transfers > > > > 4 of 192 bytes. > > > > > > No, that's not the problem. This is the problem: > > > > > > > usb-storage: *** thread awakened. > > > > usb-storage: Command TEST_UNIT_READY (6 bytes) > > > > usb-storage: 00 00 00 00 00 00 > > > > usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > > usb-storage: Status code 0; transferred 31/31 > > > > usb-storage: -- transfer complete > > > > usb-storage: Bulk command transfer result=0 > > > > usb-storage: Attempting to get CSW... > > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > > > > usb-storage: Status code 0; transferred 13/13 > > > > usb-storage: -- transfer complete > > > > usb-storage: Bulk status result = 0 > > > > usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > > > > usb-storage: -- transport indicates command failure > > > > usb-storage: Issuing auto-REQUEST_SENSE > > > > usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > > > > usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > > usb-storage: Status code 0; transferred 31/31 > > > > usb-storage: -- transfer complete > > > > usb-storage: Bulk command transfer result=0 > > > > usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > > > > usb-storage: usb_sg_init returned -22 > > > > usb-storage: Bulk data transfer result 0x4 > > > > usb-storage: -- auto-sense failure > > > > usb-storage: storage_pre_reset > > > > ehci_hcd :00:1d.7: port 1 high speed > > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > > CONNECT > > > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > > > ehci_hcd :00:1d.7: port 1 high speed > > > > ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > > > > CONNECT > > > > usb-storage: storage_post_reset > > > > usb-storage: usb_reset_composite_device returns 0 > > >
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 29 2008, Jens Axboe wrote: > >> On Tue, Jan 29 2008, James Bottomley wrote: > >>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > >>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > >>>>> On Tue, Jan 29 2008, Jens Axboe wrote: > >>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote: > >>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > >>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote: > >>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL PROTECTED]> > >>>>>>>>> wrote: > >>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote: > >>>>>>>>>>> Greg KH wrote: > >>>>>>> > >>>>>>>>>> No difference, still just a lot of resets. > >>>>>>>>>> > >>>>>>>>> Where you able to figure out which usb storage transport is used? > >>>>>>>>> > >>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and > >>>>>>>>> get_transport() > >>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. This > >>>>>>>>> will > >>>>>>>>> pinpoint better where to look. Let me research a bit. > >>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' > >>>>>>>> and > >>>>>>>> transport is 'Bulk' > >>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and > >>>>>>> CONFIG_STORAGE_DEBUG > >>>>>>> That should tell the reason for the resets. > >>>>>> Sure, I'll do that. Will post the results tonight. > >>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged > >>>>> in the device, waited 10 seconds or so and pulled it out. These are the > >>>>> messages. > >>>>> > >>>>> It all looks good until the MODE_SENSE command, where it only transfers > >>>>> 4 of 192 bytes. > >>>> No, that's not the problem. This is the problem: > >>>> > >>>>> usb-storage: *** thread awakened. > >>>>> usb-storage: Command TEST_UNIT_READY (6 bytes) > >>>>> usb-storage: 00 00 00 00 00 00 > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 > >>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > >>>>> usb-storage: Status code 0; transferred 31/31 > >>>>> usb-storage: -- transfer complete > >>>>> usb-storage: Bulk command transfer result=0 > >>>>> usb-storage: Attempting to get CSW... > >>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > >>>>> usb-storage: Status code 0; transferred 13/13 > >>>>> usb-storage: -- transfer complete > >>>>> usb-storage: Bulk status result = 0 > >>>>> usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > >>>>> usb-storage: -- transport indicates command failure > >>>>> usb-storage: Issuing auto-REQUEST_SENSE > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 > >>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > >>>>> usb-storage: Status code 0; transferred 31/31 > >>>>> usb-storage: -- transfer complete > >>>>> usb-storage: Bulk command transfer result=0 > >>>>> usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries > >>>>> usb-storage: usb_sg_init returned -22 > >>>>> usb-storage: Bulk data transfer result 0x4 > >>>>> usb-storage: -- auto-sense failure > >>>>> usb-storage: storage_pre_reset > >>>>> ehci_hcd :00:1d.7: port 1 high speed > >>>>> ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE > >>>>> CONNECT > >>>>> usb 5-1: reset high speed USB device using ehci_hcd and address 2 > >>>>> ehci_hcd :00:1d
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, James Bottomley wrote: > On Tue, 2008-01-29 at 21:03 +0100, Jens Axboe wrote: > > On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > >> On Tue, Jan 29 2008, James Bottomley wrote: > > > >>> On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > > > >>>> On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: > > > >>>>> On Tue, Jan 29 2008, Jens Axboe wrote: > > > >>>>>> On Tue, Jan 29 2008, Oliver Neukum wrote: > > > >>>>>>> Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: > > > >>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > >>>>>>>>> On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe <[EMAIL > > > >>>>>>>>> PROTECTED]> wrote: > > > >>>>>>>>>> On Tue, Jan 29 2008, Boaz Harrosh wrote: > > > >>>>>>>>>>> Greg KH wrote: > > > >>>>>>> > > > >>>>>>>>>> No difference, still just a lot of resets. > > > >>>>>>>>>> > > > >>>>>>>>> Where you able to figure out which usb storage transport is > > > >>>>>>>>> used? > > > >>>>>>>>> > > > >>>>>>>>> in drivers/usb/storage/usb.c you have get_protocol() and > > > >>>>>>>>> get_transport() > > > >>>>>>>>> functions. I'm not sure if these get stored in sysfs perhaps. > > > >>>>>>>>> This will > > > >>>>>>>>> pinpoint better where to look. Let me research a bit. > > > >>>>>>>> Did the quick'n easy and dumped it. Protocol is 'Transparent > > > >>>>>>>> SCSI' and > > > >>>>>>>> transport is 'Bulk' > > > >>>>>>> You can recompile your kernel with CONFIG_USB_DEBUG and > > > >>>>>>> CONFIG_STORAGE_DEBUG > > > >>>>>>> That should tell the reason for the resets. > > > >>>>>> Sure, I'll do that. Will post the results tonight. > > > >>>>> OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. > > > >>>>> Plugged > > > >>>>> in the device, waited 10 seconds or so and pulled it out. These are > > > >>>>> the > > > >>>>> messages. > > > >>>>> > > > >>>>> It all looks good until the MODE_SENSE command, where it only > > > >>>>> transfers > > > >>>>> 4 of 192 bytes. > > > >>>> No, that's not the problem. This is the problem: > > > >>>> > > > >>>>> usb-storage: *** thread awakened. > > > >>>>> usb-storage: Command TEST_UNIT_READY (6 bytes) > > > >>>>> usb-storage: 00 00 00 00 00 00 > > > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL > > > >>>>> 6 > > > >>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes > > > >>>>> usb-storage: Status code 0; transferred 31/31 > > > >>>>> usb-storage: -- transfer complete > > > >>>>> usb-storage: Bulk command transfer result=0 > > > >>>>> usb-storage: Attempting to get CSW... > > > >>>>> usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes > > > >>>>> usb-storage: Status code 0; transferred 13/13 > > > >>>>> usb-storage: -- transfer complete > > > >>>>> usb-storage: Bulk status result = 0 > > > >>>>> usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 > > > >>>>> usb-storage: -- transport indicates command failure > > > >>>>> usb-storage: Issuing auto-REQUEST_SENSE > > > >>>>> usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 > > > >>>>> CL 6 > > > >>>>> usb-storage: usb_stor_bulk_transfer
Re: [BUG] 2.6.24-git usb reset problems
On Wed, Jan 30 2008, Geert Uytterhoeven wrote:
> On Tue, 29 Jan 2008, Jens Axboe wrote:
> > On Tue, Jan 29 2008, Jens Axboe wrote:
> > > On Tue, Jan 29 2008, James Bottomley wrote:
> > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
> > > > > For some reason, usb_sg_init is boned during auto-sense.
> > > >
> > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
> > > > code ... that was also an update in 2.6.24
> > >
> > > yeah, already found the bug - it's assuming ->request_buffer holds the
> > > sglist, oops. Preparing a fix.
> >
> > ok here goes, this saves and restores the sg table correctly. it also
> > fixes the usb bug for me.
>
> I can confirm this patch fixes the errors I was seeing with current
> linux-2.6.git for the USB memory card readers in a Dell TFT connected
> to a PS3.
James, we need a fix for this pushed asap. So either we should merge the
below now, or push the bidi patchset that also fixes this. It all
depends on when you want to merge the bidi patches...
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 547e85a..12770ef 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
> > scsi_eh_save *ses,
> > ses->use_sg = scmd->use_sg;
> > ses->resid = scmd->resid;
> > ses->result = scmd->result;
> > + memcpy(&ses->sense_sgl, &scmd->sg_table, sizeof(ses->sense_sgl));
> >
> > if (sense_bytes) {
> > scmd->request_bufflen = min_t(unsigned,
> >SCSI_SENSE_BUFFERSIZE, sense_bytes);
> > sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
> >scmd->request_bufflen);
> > - scmd->request_buffer = &ses->sense_sgl;
> > + scmd->sg_table.sgl = &ses->sense_sgl;
> > + scmd->sg_table.nents = scmd->sg_table.orig_nents = 1;
> > scmd->sc_data_direction = DMA_FROM_DEVICE;
> > scmd->use_sg = 1;
> > memset(scmd->cmnd, 0, sizeof(scmd->cmnd));
> > @@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd,
> > struct scsi_eh_save *ses)
> > scmd->request_bufflen = ses->bufflen;
> > scmd->request_buffer = ses->buffer;
> > scmd->use_sg = ses->use_sg;
> > + memcpy(&scmd->sg_table, &ses->sg_table, sizeof(scmd->sg_table));
> > scmd->resid = ses->resid;
> > scmd->result = ses->result;
> > }
> > diff --git a/include/scsi/scsi_eh.h b/include/scsi/scsi_eh.h
> > index d21b891..d43dc83 100644
> > --- a/include/scsi/scsi_eh.h
> > +++ b/include/scsi/scsi_eh.h
> > @@ -75,6 +75,7 @@ struct scsi_eh_save {
> >
> > void *buffer;
> > unsigned bufflen;
> > + struct sg_table sg_table;
> > unsigned short use_sg;
> > int resid;
> >
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Wed, Jan 30 2008, James Bottomley wrote: > On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote: > > On Wed, Jan 30 2008, Geert Uytterhoeven wrote: > > > On Tue, 29 Jan 2008, Jens Axboe wrote: > > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > > On Tue, Jan 29 2008, James Bottomley wrote: > > > > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > > > > > > > For some reason, usb_sg_init is boned during auto-sense. > > > > > > > > > > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense > > > > > > code ... that was also an update in 2.6.24 > > > > > > > > > > yeah, already found the bug - it's assuming ->request_buffer holds the > > > > > sglist, oops. Preparing a fix. > > > > > > > > ok here goes, this saves and restores the sg table correctly. it also > > > > fixes the usb bug for me. > > > > > > I can confirm this patch fixes the errors I was seeing with current > > > linux-2.6.git for the USB memory card readers in a Dell TFT connected > > > to a PS3. > > > > James, we need a fix for this pushed asap. So either we should merge the > > below now, or push the bidi patchset that also fixes this. It all > > depends on when you want to merge the bidi patches... > > The SCSI patch set (including the bidirectional pieces) is waiting in > scsi-misc ... just for forms sake, could you confirm that it actually > fixes the problem and I'll push it. Certainly, I'll give it a spin tonight. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Wed, Jan 30 2008, Jens Axboe wrote: > On Wed, Jan 30 2008, James Bottomley wrote: > > On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote: > > > On Wed, Jan 30 2008, Geert Uytterhoeven wrote: > > > > On Tue, 29 Jan 2008, Jens Axboe wrote: > > > > > On Tue, Jan 29 2008, Jens Axboe wrote: > > > > > > On Tue, Jan 29 2008, James Bottomley wrote: > > > > > > > On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: > > > > > > > > For some reason, usb_sg_init is boned during auto-sense. > > > > > > > > > > > > > > OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense > > > > > > > code ... that was also an update in 2.6.24 > > > > > > > > > > > > yeah, already found the bug - it's assuming ->request_buffer holds > > > > > > the > > > > > > sglist, oops. Preparing a fix. > > > > > > > > > > ok here goes, this saves and restores the sg table correctly. it also > > > > > fixes the usb bug for me. > > > > > > > > I can confirm this patch fixes the errors I was seeing with current > > > > linux-2.6.git for the USB memory card readers in a Dell TFT connected > > > > to a PS3. > > > > > > James, we need a fix for this pushed asap. So either we should merge the > > > below now, or push the bidi patchset that also fixes this. It all > > > depends on when you want to merge the bidi patches... > > > > The SCSI patch set (including the bidirectional pieces) is waiting in > > scsi-misc ... just for forms sake, could you confirm that it actually > > fixes the problem and I'll push it. > > Certainly, I'll give it a spin tonight. Confirmed, pulling your scsi-misc branch into current -git makes the problem go away as well. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Convert target drivers to use sbitmap
On 5/15/18 10:00 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> The sbitmap and the percpu_ida perform essentially the same task,
> allocating tags for commands. Since the sbitmap is more used than
> the percpu_ida, convert the percpu_ida users to the sbitmap API.
It should also be the same performance as percpu_ida in light use, and
performs much better at > 50% utilization of the tag space. I think
that's better justification than "more used than".
> diff --git a/drivers/target/iscsi/iscsi_target_util.c
> b/drivers/target/iscsi/iscsi_target_util.c
> index 4435bf374d2d..28bcffae609f 100644
> --- a/drivers/target/iscsi/iscsi_target_util.c
> +++ b/drivers/target/iscsi/iscsi_target_util.c
> @@ -17,7 +17,7 @@
>
> **/
>
> #include
> -#include
> +#include
> #include /* ipv6_addr_equal() */
> #include
> #include
> @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
> spin_unlock_bh(&cmd->r2t_lock);
> }
>
> +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
> +{
> + int tag = -1;
> + DEFINE_WAIT(wait);
> + struct sbq_wait_state *ws;
> +
> + if (state == TASK_RUNNING)
> + return tag;
> +
> + ws = &se_sess->sess_tag_pool.ws[0];
> + for (;;) {
> + prepare_to_wait_exclusive(&ws->wait, &wait, state);
> + if (signal_pending_state(state, current))
> + break;
> + schedule();
> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
> + }
> +
> + finish_wait(&ws->wait, &wait);
> + return tag;
> +}
Seems like that should be:
ws = &se_sess->sess_tag_pool.ws[0];
for (;;) {
prepare_to_wait_exclusive(&ws->wait, &wait, state);
if (signal_pending_state(state, current))
break;
tag = sbitmap_queue_get(&se_sess->sess_tag_pool, cpup);
if (tag != -1)
break;
schedule();
}
finish_wait(&ws->wait, &wait);
return tag;
> /*
> * May be called from software interrupt (timer) context for allocating
> * iSCSI NopINs.
> @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
> *conn, int state)
> {
> struct iscsi_cmd *cmd;
> struct se_session *se_sess = conn->sess->se_sess;
> - int size, tag;
> + int size, tag, cpu;
>
> - tag = percpu_ida_alloc(&se_sess->sess_tag_pool, state);
> + tag = sbitmap_queue_get(&se_sess->sess_tag_pool, &cpu);
> + if (tag < 0)
> + tag = iscsit_wait_for_tag(se_sess, state, &cpu);
> if (tag < 0)
> return NULL;
Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.
sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.
Rest looks fine to me.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Convert target drivers to use sbitmap
On 5/15/18 10:11 AM, Jens Axboe wrote: > On 5/15/18 10:00 AM, Matthew Wilcox wrote: >> From: Matthew Wilcox >> >> The sbitmap and the percpu_ida perform essentially the same task, >> allocating tags for commands. Since the sbitmap is more used than >> the percpu_ida, convert the percpu_ida users to the sbitmap API. > > It should also be the same performance as percpu_ida in light use, and > performs much better at > 50% utilization of the tag space. I think > that's better justification than "more used than". Had to search long and hard for the perf numbers I did for percpu_ida on higher utilization, but here it is: https://lkml.org/lkml/2014/4/22/553 -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
