Re: DMA mapping on SCSI device?
Luben Tuikov wrote: --- On Mon, 1/28/08, Robert Hancock <[EMAIL PROTECTED]> wrote: The trick is that if an ATAPI device is connected, we (as far as I'm aware) can't use ADMA mode, so we have to switch that port into legacy mode. Can you double check this with the HW architect of the HW DMA engine of the ASIC? Will do so. However, previous statements from NVIDIA fairly clearly indicate that this is the case. This means it's only capable of 32-bit DMA. However the other port on the controller may be connected to a hard drive and therefore still capable of 64-bit DMA. If this is indeed the case as you've presented it here, it sounds like a HW shortcoming. I cannot see how the device type (or protocol) dictate how the DMA engine operates. They live in two different domains. Well, there is an indirect link. The ADMA interface (which supports 64-bit DMA) cannot be used to issue ATAPI commands, so if an ATAPI device is connected we have to go to legacy mode, which supports only 32-bit DMA. I'm not sure why ADMA mode doesn't support ATAPI. The only reason I can think of is that there's issues since ATAPI commands can potentially be of unpredictable transfer size. The "real" ADMA spec that the NVIDIA implementation is loosely based on does have some special "ignore excess" controls that don't seem to be in the NVIDIA version (or at least not to the knowledge I have on this hardware). And yes, it is a rather unfortunate hardware shortcoming (presuming that it is entirely true). The ideal solution would be to do mapping against a different struct device for each port, so that we could maintain the proper DMA mask for each of them at all times. However I'm not sure if that's possible. The thought of using the SCSI struct device for DMA mapping was brought up at one point.. any thoughts on that? The reason for this is that the object that a struct scsi_dev represents has nothing to do with HW DMA engines. It looks like your current solution is correct and x86_64's blk_queue_bounce_limit needs work. Luben - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock
Hi, >Also, md raid10 seems to have the same problem. >I will test raid10 applying this patch as well. Sorry for the late response. I had a trouble with reproducing the problem, but it turns out that the 2.6.24 kernel needs the latest (possibly testing) version of systemtap-0.6.1-1 to run systemtap for the fault injection tool. I've reproduced the stall on both raid1 and raid10 using 2.6.24. Also I've tested the patch applied to 2.6.24 and confirmed that it will fix the stall problem for both cases. K.Tanaka wrote: > Hi, > > Thank you for the patch. > I have applied the patch to 2.6.23.14 and it works well. > > - In case of 2.6.23.14, the problem is reproduced. > - In case of 2.6.23.14 with this patch, raid1 works well so far. > The fault injection script continues to run, and it doesn't deadlock. > I will keep it running for a while. > > Also, md raid10 seems to have the same problem. > I will test raid10 applying this patch as well. > > > Neil Brown wrote: >> On Tuesday January 15, [EMAIL PROTECTED] wrote: >>> This message describes the details about md-RAID1 issue found by >>> testing the md RAID1 using the SCSI fault injection framework. >>> >>> Abstract: >>> Both the error handler for md RAID1 and write access request to the md RAID1 >>> use raid1d kernel thread. The nr_pending flag could cause a race condition >>> in raid1d, results in a raid1d deadlock. >> Thanks for finding and reporting this. >> >> I believe the following patch should fix the deadlock. >> >> If you are able to repeat your test and confirm this I would >> appreciate it. >> >> Thanks, >> NeilBrown >> >> >> >> Fix deadlock in md/raid1 when handling a read error. >> >> When handling a read error, we freeze the array to stop any other >> IO while attempting to over-write with correct data. >> -- - Kenichi TANAKA| Open Source Software Platform Development Division | Computers Software Operations Unit, NEC Corporation | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
FUJITA Tomonori wrote: On Tue, 29 Jan 2008 13:31:52 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > . . STGT read SCST read.STGT read SCST read. > . . performance performance . performance performance . > . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, MB/s) (1 MB, MB/s) . > . iSER (8 Gb/s network) . 250N/A . 360 N/A . > . SRP (8 Gb/s network) . N/A421 . N/A 683 . > On the comparable figures, which only seem to be IPoIB they're showing a > 13-18% variance, aren't they? Which isn't an incredible difference. Maybe I'm all wet, but I think iSER vs. SRP should be roughly comparable. The exact formatting of various messages etc. is different but the data path using RDMA is pretty much identical. So the big difference between STGT iSER and SCST SRP hints at some big difference in the efficiency of the two implementations. iSER has parameters to limit the maximum size of RDMA (it needs to repeat RDMA with a poor configuration)? Anyway, here's the results from Robin Humble: iSER to 7G ramfs, x86_64, centos4.6, 2.6.22 kernels, git tgtd, initiator end booted with mem=512M, target with 8G ram direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct Both Robin (iser/stgt) and Bart (scst/srp) using ramfs Robin's numbers come from DDR IB HCAs Bart's numbers come from SDR IB HCAs: Results with /dev/ram0 configured as backing store on the target (buffered I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 250 48 349 781 SCST + SRP411 66 659 746 Results with /dev/ram0 configured as backing store on the target (direct I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 7.9 9.8 589 647 SCST + SRP 12.3 9.7 811 794 http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg13514.html Here are my numbers with DDR IB HCAs, SCST/SRP 5G /dev/ram0 block_io mode, RHEL5 2.6.18-8.el5 direct i/o dd write/read 1100/895 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct buffered i/o dd write/read 950/770 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 dd of=/dev/null if=/dev/sdc bs=1M count=5000 So when using DDR IB hcas: stgt/iser scst/srp direct I/O 800/751 1100/895 buffered I/O 1109/350950/770 -vu http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg13502.html I think that STGT is pretty fast with the fast backing storage. I don't think that there is the notable perfornace difference between kernel-space and user-space SRP (or ISER) implementations about moving data between hosts. IB is expected to enable user-space applications to move data between hosts quickly (if not, what can IB provide us?). I think that the question is how fast user-space applications can do I/Os ccompared with I/Os in kernel space. STGT is eager for the advent of good asynchronous I/O and event notification interfances. One more possible optimization for STGT is zero-copy data transfer. STGT uses pre-registered buffers and move data between page cache and thsse buffers, and then does RDMA transfer. If we implement own caching mechanism to use pre-registered buffers directly with (AIO and O_DIRECT), then STGT can move data without data copies. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Scst-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/scst-devel - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Integration of SCST in the mainstream Linux kernel
On Tue, 29 Jan 2008 13:31:52 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > . . STGT read SCST read.STGT read > SCST read. > > . . performance performance . performance > performance . > > . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, > MB/s) (1 MB, MB/s) . > > . iSER (8 Gb/s network) . 250N/A . 360 > N/A . > > . SRP (8 Gb/s network) . N/A421 . N/A > 683 . > > > On the comparable figures, which only seem to be IPoIB they're showing a > > 13-18% variance, aren't they? Which isn't an incredible difference. > > Maybe I'm all wet, but I think iSER vs. SRP should be roughly > comparable. The exact formatting of various messages etc. is > different but the data path using RDMA is pretty much identical. So > the big difference between STGT iSER and SCST SRP hints at some big > difference in the efficiency of the two implementations. iSER has parameters to limit the maximum size of RDMA (it needs to repeat RDMA with a poor configuration)? Anyway, here's the results from Robin Humble: iSER to 7G ramfs, x86_64, centos4.6, 2.6.22 kernels, git tgtd, initiator end booted with mem=512M, target with 8G ram direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg13502.html I think that STGT is pretty fast with the fast backing storage. I don't think that there is the notable perfornace difference between kernel-space and user-space SRP (or ISER) implementations about moving data between hosts. IB is expected to enable user-space applications to move data between hosts quickly (if not, what can IB provide us?). I think that the question is how fast user-space applications can do I/Os ccompared with I/Os in kernel space. STGT is eager for the advent of good asynchronous I/O and event notification interfances. One more possible optimization for STGT is zero-copy data transfer. STGT uses pre-registered buffers and move data between page cache and thsse buffers, and then does RDMA transfer. If we implement own caching mechanism to use pre-registered buffers directly with (AIO and O_DIRECT), then STGT can move data without data copies. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA mapping on SCSI device?
--- On Mon, 1/28/08, Andi Kleen <[EMAIL PROTECTED]> wrote: > > The ideal solution would be to do mapping against a > different struct > > device for each port, so that we could maintain the > proper DMA mask for > > each of them at all times. However I'm not sure if > that's possible. > > I cannot imagine why it should be that difficult. The PCI > subsystem > could over a pci_clone_device() or similar function. For > all complicated > purposes (sysfs etc) the original device could be used, so > it would > be hopefully not that difficult. > > The alternative would be to add a new family of PCI mapping > functions that take an explicit mask. Disadvantage would be > changing > all architectures, but on the other hand the interface > could be phase > in one by one (and nF4 primarily only works on x86 anyways) > > I suspect the later would be a little cleaner, although > they don't > make much difference. Yes, I guess, that's certainly doable. The current PCI abstraction is clean: HW DMA engine(s) implementation is a property of the PCI function. Marrying different behaviour of the HW DMA engine of the ASIC depending on the SCSI end device at the PCI device abstraction doesn't sound good. (An extreme design is a single DMA engine servicing the ASIC.) Although, the effect that Rob wants could be cleanly implemented at a higher level, pci_map_sg() and such, or fixing blk_queue_bounce_limit() in x86_64 to that effect. Luben - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA mapping on SCSI device?
--- On Mon, 1/28/08, Robert Hancock <[EMAIL PROTECTED]> wrote: > The trick is that if an ATAPI device is connected, we (as > far as I'm > aware) can't use ADMA mode, so we have to switch that > port into legacy > mode. Can you double check this with the HW architect of the HW DMA engine of the ASIC? > This means it's only capable of 32-bit DMA. > However the other port > on the controller may be connected to a hard drive and > therefore still > capable of 64-bit DMA. If this is indeed the case as you've presented it here, it sounds like a HW shortcoming. I cannot see how the device type (or protocol) dictate how the DMA engine operates. They live in two different domains. > The ideal solution would be to do mapping against a > different struct > device for each port, so that we could maintain the proper > DMA mask for > each of them at all times. However I'm not sure if > that's possible. The > thought of using the SCSI struct device for DMA mapping was > brought up > at one point.. any thoughts on that? The reason for this is that the object that a struct scsi_dev represents has nothing to do with HW DMA engines. It looks like your current solution is correct and x86_64's blk_queue_bounce_limit needs work. Luben - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Integration of SCST in the mainstream Linux kernel
> . . STGT read SCST read.STGT read > SCST read. > . . performance performance . performance > performance . > . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, MB/s) > (1 MB, MB/s) . > . iSER (8 Gb/s network) . 250N/A . 360 > N/A . > . SRP (8 Gb/s network) . N/A421 . N/A > 683 . > On the comparable figures, which only seem to be IPoIB they're showing a > 13-18% variance, aren't they? Which isn't an incredible difference. Maybe I'm all wet, but I think iSER vs. SRP should be roughly comparable. The exact formatting of various messages etc. is different but the data path using RDMA is pretty much identical. So the big difference between STGT iSER and SCST SRP hints at some big difference in the efficiency of the two implementations. - R. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Integration of SCST in the mainstream Linux kernel
On Wed, 2008-01-23 at 15:22 +0100, Bart Van Assche wrote: > As you probably know there is a trend in enterprise computing towards > networked storage. This is illustrated by the emergence during the > past few years of standards like SRP (SCSI RDMA Protocol), iSCSI > (Internet SCSI) and iSER (iSCSI Extensions for RDMA). Two different > pieces of software are necessary to make networked storage possible: > initiator software and target software. As far as I know there exist > three different SCSI target implementations for Linux: > - The iSCSI Enterprise Target Daemon (IETD, > http://iscsitarget.sourceforge.net/); > - The Linux SCSI Target Framework (STGT, http://stgt.berlios.de/); > - The Generic SCSI Target Middle Level for Linux project (SCST, > http://scst.sourceforge.net/). > Since I was wondering which SCSI target software would be best suited > for an InfiniBand network, I started evaluating the STGT and SCST SCSI > target implementations. Apparently the performance difference between > STGT and SCST is small on 100 Mbit/s and 1 Gbit/s Ethernet networks, > but the SCST target software outperforms the STGT software on an > InfiniBand network. See also the following thread for the details: > http://sourceforge.net/mailarchive/forum.php?thread_name=e2e108260801170127w2937b2afg9bef324efa945e43%40mail.gmail.com&forum_name=scst-devel. That doesn't seem to pull up a thread. However, I assume it's these figures: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB, MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 .77 89 . . IPoIB(8 Gb/s network) . 163185 . 201 239 . . iSER (8 Gb/s network) . 250N/A . 360 N/A . . SRP (8 Gb/s network) . N/A421 . N/A 683 . . On the comparable figures, which only seem to be IPoIB they're showing a 13-18% variance, aren't they? Which isn't an incredible difference. > About the design of the SCST software: while one of the goals of the > STGT project was to keep the in-kernel code minimal, the SCST project > implements the whole SCSI target in kernel space. SCST is implemented > as a set of new kernel modules, only minimal changes to the existing > kernel are necessary before the SCST kernel modules can be used. This > is the same approach that will be followed in the very near future in > the OpenSolaris kernel (see also > http://opensolaris.org/os/project/comstar/). More information about > the design of SCST can be found here: > http://scst.sourceforge.net/doc/scst_pg.html. > > My impression is that both the STGT and SCST projects are well > designed, well maintained and have a considerable user base. According > to the SCST maintainer (Vladislav Bolkhovitin), SCST is superior to > STGT with respect to features, performance, maturity, stability, and > number of existing target drivers. Unfortunately the SCST kernel code > lives outside the kernel tree, which makes SCST harder to use than > STGT. > > As an SCST user, I would like to see the SCST kernel code integrated > in the mainstream kernel because of its excellent performance on an > InfiniBand network. Since the SCST project comprises about 14 KLOC, > reviewing the SCST code will take considerable time. Who will do this > reviewing work ? And with regard to the comments made by the > reviewers: Vladislav, do you have the time to carry out the > modifications requested by the reviewers ? I expect a.o. that > reviewers will ask to move SCST's configuration pseudofiles from > procfs to sysfs. The two target architectures perform essentially identical functions, so there's only really room for one in the kernel. Right at the moment, it's STGT. Problems in STGT come from the user<->kernel boundary which can be mitigated in a variety of ways. The fact that the figures are pretty much comparable on non IB networks shows this. I really need a whole lot more evidence than at worst a 20% performance difference on IB to pull one implementation out and replace it with another. Particularly as there's no real evidence that STGT can't be tweaked to recover the 20% even on IB. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 22:24 +0200, James Bottomley <[EMAIL PROTECTED]> wrote: > On Tue, 2008-01-29 at 21:06 +0100, Jens Axboe wrote: >>> I will ... but it will cause an explosion in the bidirectional tree >>> again. I think the bidi updates also fix this. However, give me time >>> to rebase and verify. >> OK thanks, just wanted to make sure that we didn't both expect each >> other to handle it :-) > > Yes, confirm that; I think this is already fixed in scsi-misc-2.6. > Could you pull from > > master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > > and verify with your device? > > Thanks, > > James > > I still don't see these changes, I wanted to check, make sure... Are there mirrors on the way to here? James I would like to remind you that one small piece is missing from the bidi tree, as I saw it from here, it's the few patches from scsi-pending. Mainly arm will break which is a grate loss. I'm going home now, I'll review all the patches tomorrow and compare to what I have, to make sure nothing was forgotten. What a waste of a day I pulled from Linus this morning apparently minutes before the merge, and chased a none existent bug in my tree. Sigh Bye Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9844] CONFIG_SCSI_MULTI_LUN hangs a camera HARD
http://bugzilla.kernel.org/show_bug.cgi?id=9844 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Component|Other |USB Product|SCSI Drivers|Drivers -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 22:13 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > 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. Yes in this patchset I have taken your sg branch at the time, and rebased it ontop of scsi_data_buffer patch. Because I felt that it is more natural for this patch to come after the scsi total cleanup that is scsi_data_buffer. Then the extraction to sg_table is simple and trivial. What I meant to point out with this patch is that all the exact same places that are touched there should be fixed when moving to sg_table. Look at it. It is a revised version of your patch. > >> 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? > I mean the patches that where in sg branch of the linux-block tree, But I see that it is now to late, and that they are in Linus already James the most simple is to submit the scsi_data_buff patch that fixes all these places. If not do you want that I send in fixes? Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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, 2008-01-29 at 21:06 +0100, Jens Axboe wrote: > > I will ... but it will cause an explosion in the bidirectional tree > > again. I think the bidi updates also fix this. However, give me time > > to rebase and verify. > > OK thanks, just wanted to make sure that we didn't both expect each > other to handle it :-) Yes, confirm that; I think this is already fixed in scsi-misc-2.6. Could you pull from master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git and verify with your device? Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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
>> > 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 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 Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 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_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. > > > > > > > > ok here goes, this saves and restores the sg table correctly. it also > > > > fixes the usb bug for me. > > > > > > > > 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 s
Re: [BUG] 2.6.24-git usb reset problems
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_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.
> > >
> > > ok here goes, this saves and restores the sg table correctly. it also
> > > fixes the usb bug for me.
> > >
> > > 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) {
> > >
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.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.
> >
> > ok here goes, this saves and restores the sg table correctly. it also
> > fixes the usb bug for me.
> >
> > 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);
> > -
Re: [BUG] 2.6.24-git usb reset problems
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.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.
>
> ok here goes, this saves and restores the sg table correctly. it also
> fixes the usb bug for me.
>
> 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;
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
> > > > 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.
ok here goes, this saves and restores the sg table correctly. it also
fixes the usb bug for me.
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);
- scm
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29, 2008 at 08:15:04PM +0100, 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 :-) MODE_SENSE has nothing to do with it. A short MODE_SENSE response is perfectly valid, and the log shows it was handled correctly and subsequent commands worked just fine. It's not until the TUR fails that we get the problem. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver P: Nine more messages in admin.policy. M: I know, I'm typing as fast as I can! -- Pitr and Mike User Friendly, 11/27/97 pgpffGBLDboVw.pgp Description: PGP signature
[Bug 9844] New: CONFIG_SCSI_MULTI_LUN hangs a camera HARD
http://bugzilla.kernel.org/show_bug.cgi?id=9844 Summary: CONFIG_SCSI_MULTI_LUN hangs a camera HARD Product: SCSI Drivers Version: 2.5 KernelVersion: 2.6.24 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've tried posting this on lkml usig two different domain addresses, but none got through... (too many capital letters in the subject?) Ah, well, here's the text: I am in need of setting CONFIG_SCSI_MULTI_LUN=y to access an SD(HC) slot on (iAudio) COWON D2 flash player, but doing so hangs my Nikon CoolPix 5600 _hard_ when connecting that to an USB slot for picture downloading. It is in fact so hard hung that the batteries must be removed to even turn the camera off. Bought the D2 last week, so don't know of a working kernel. Messages from working/non-working scenarios - not very useful. Holler if you want me to turn on debugging etc: _Working - # CONFIG_SCSI_MULTI_LUN is not set_ Jan 27 19:55:42 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 19:55:43 sleipner kernel: Clocksource tsc unstable (delta = -65041374 ns) Jan 27 19:57:25 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 19:57:26 sleipner kernel: usb 2-2: configuration #1 chosen from 1 choice Jan 27 19:57:26 sleipner kernel: Initializing USB Mass Storage driver... Jan 27 19:57:26 sleipner kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 27 19:57:26 sleipner kernel: usbcore: registered new interface driver usb-storage Jan 27 19:57:26 sleipner kernel: USB Mass Storage support registered. Jan 27 19:57:31 sleipner kernel: scsi 0:0:0:0: Direct-Access NIKONNIKON DSC E5600 1.00 PQ: 0 ANSI: 2 Jan 27 19:57:31 sleipner kernel: Driver 'sd' needs updating - please use bus_type methods Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] 1984000 512-byte hardware sectors (1016 MB) Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] 1984000 512-byte hardware sectors (1016 MB) Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Write Protect is off Jan 27 19:57:31 sleipner kernel: sda: sda1 Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Jan 27 19:57:31 sleipner kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 _Not working - CONFIG_SCSI_MULTI_LUN=y_ Jan 27 20:17:13 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 20:17:14 sleipner kernel: Clocksource tsc unstable (delta = -90855698 ns) Jan 27 20:19:06 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 20:19:27 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 3 Jan 27 20:19:57 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 4 Jan 27 20:20:07 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 5 That was really strange ---^ with all the usages. Nothing at all happens except for the camera dying. Forgot to check in kern.log, but an additional kernel with CONFIG_USB_DEVICE_CLASS=y at least finds the camera after ca 20 seconds, but can't really use it - and it's dead to the world: (This is from kern.log) Jan 27 20:27:54 sleipner kernel: Time: acpi_pm clocksource has been installed. Jan 27 20:27:55 sleipner kernel: Clocksource tsc unstable (delta = -86237258 ns) Jan 27 20:28:04 sleipner kernel: ath0: no IPv6 routers present Jan 27 20:29:23 sleipner kernel: usb 2-2: new full speed USB device using uhci_hcd and address 2 Jan 27 20:29:23 sleipner kernel: usb 2-2: configuration #1 chosen from 1 choice Jan 27 20:29:23 sleipner kernel: Initializing USB Mass Storage driver... Jan 27 20:29:23 sleipner kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 27 20:29:23 sleipner kernel: usbcore: registered new interface driver usb-storage Jan 27 20:29:23 sleipner kernel: USB Mass Storage support registered. Jan 27 20:29:23 sleipner kernel: usb-storage: device found at 2 Jan 27 20:29:23 sleipner kernel: usb-storage: waiting for device to settle before scanning Jan 27 20:29:41 sleipner kernel: usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd kio_kamera rqt 33 rq 102 len 0 ret -110 Jan 27 20:30:13 sleipner last message repeated 2 times -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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, 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 James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 21:17 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
>>> Your new code does
>>>
>>> int partial; <- stack uninitialised
>>> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>>
>>> If the function doesn't touch partial, as it doesn't in the error legs,
>>> resid now gets set with rubbish.
>>>
>>> Actually, my code is still wrong .. we have to set it to
>>> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
>>> left untouched.
>>>
I have such a device and I get one reset but then every thing works nice.
This is with debug on. I'll try to make it fail.
>>> James
>>>
>>>
>> Sorry I still don't see it.
>>
>> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>>
>> but sb_stor_bulk_transfer_sg does the:
>> int partial; <- stack uninitialised
>> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>>
>> and then unconditionally sets *residual = length_left;
>> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
>
> This is really programming 101. This:
>
> static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
> int pipe,
> struct scatterlist *sg, int num_sg, unsigned int length,
> unsigned int *act_len)
> {
> int result;
>
> /* don't submit s-g requests during abort/disconnect processing */
> if (us->flags & ABORTING_OR_DISCONNECTING)
> return USB_STOR_XFER_ERROR;
>
> The return USB_STOR_XFER_ERROR; is called an error leg. It returns
> without updating *act_len thus leaving &partial uninitialised.
>
> James
>
Yes you are right this is a bug, but it is a bug that was there before.
perhaps the stack is just different now then what it used to be.
Jens could you please try that:
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..b18a5e6 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- unsigned int partial;
+ unsigned int partial = 0;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
&partial);
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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, 2008-01-29 at 20:58 +0200, Boaz Harrosh wrote:
> > Your new code does
> >
> > int partial; <- stack uninitialised
> > sb_stor_bulk_transfer_sglist(..., &partial, ...);
> > scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >
> > If the function doesn't touch partial, as it doesn't in the error legs,
> > resid now gets set with rubbish.
> >
> > Actually, my code is still wrong .. we have to set it to
> > scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> > left untouched.
> >
> >> I have such a device and I get one reset but then every thing works nice.
> >> This is with debug on. I'll try to make it fail.
> >
> > James
> >
> >
> Sorry I still don't see it.
>
> original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>
> but sb_stor_bulk_transfer_sg does the:
> int partial; <- stack uninitialised
> sb_stor_bulk_transfer_sglist(..., &partial, ...);
>
> and then unconditionally sets *residual = length_left;
> I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
This is really programming 101. This:
static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned
int pipe,
struct scatterlist *sg, int num_sg, unsigned int length,
unsigned int *act_len)
{
int result;
/* don't submit s-g requests during abort/disconnect processing */
if (us->flags & ABORTING_OR_DISCONNECTING)
return USB_STOR_XFER_ERROR;
The return USB_STOR_XFER_ERROR; is called an error leg. It returns
without updating *act_len thus leaving &partial uninitialised.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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 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. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 pgpv4xHNKnTsh.pgp Description: PGP signature
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008 at 20:39 +0200, Jens Axboe <[EMAIL PROTECTED]> 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. > > usb-storage: Command MODE_SENSE (6 bytes) > usb-storage: 1a 00 3f 00 c0 00 > usb-storage: Bulk Command S 0x43425355 T 0x4 L 192 F 128 Trg 0 LUN 0 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 192 bytes, 1 entries > usb-storage: Status code -121; transferred 4/192 > usb-storage: -- short read transfer > usb-storage: Bulk data transfer result 0x1 > usb-storage: Attempting to get CSW... I get something similar but better: usb-storage: Command MODE_SENSE (6 bytes) usb-storage: 1a 00 3f 00 c0 00 usb-storage: Bulk Command S 0x43425355 T 0x6 L 192 F 128 Trg 0 LUN 0 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 192 bytes, 1 entries usb-storage: Status code -121; transferred 36/192 usb-storage: -- short read transfer usb-storage: Bulk data transfer result 0x1 usb-storage: Attempting to get CSW... So I get 36 bytes, then code goes on into one reset, and every thing is then fine. Could you put us out of our mesery and revert that patch: [SCSI] usb: transport - convert to accessors and !use_sg code path removal (6d416e6173394defda5933e419e805b696681b7e) to make sure this is it. I hate to do this to you, but I cannot reproduce the failure down here. If it works please send a log with the debugs on perhaps we can compare. You will need to configure out the CONFIG_USB_STORAG_* they will not compile you should have only have CONFIG_USB_STORAGE & CONFIG_USB_STORAGE_DEBUG. it should support your HW. Thanks Jens Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 20:48 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
>> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]>
>> wrote:
>>> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> us_data *us, unsigned int pipe,
> * Common used function. Transfer a complete command
> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> */
> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> - struct scsi_cmnd* srb)
> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb, unsigned length)
> {
> unsigned int partial;
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> - scsi_sg_count(srb), scsi_bufflen(srb),
> + scsi_sg_count(srb), length,
> &partial);
>
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> return result;
> }
>
> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb)
> +{
> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> +}
> +
I don't like this patch very much. Why add another layer of
indirection when the two subroutines do hardly any work? Leave
usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
and scsi_set_resid().
BTW, the standard coding style calls for a blank line after the list of
local variables at the start of a function or block.
>>> There's another bug in the transport.c conversion in that the residuals
>>> are updated with bogus data in several error cases, since
>>> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
>>> is actually sent.
>>>
>>> I'm not sure if this is is the solution to the problem at hand, but it
>>> definitely fixes another bug in the code.
>>>
>>> James
>>>
>>> diff --git a/drivers/usb/storage/transport.c
>>> b/drivers/usb/storage/transport.c
>>> index d9f4912..bab0858 100644
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
>>> *us, unsigned int pipe,
>>> int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> struct scsi_cmnd* srb)
>>> {
>>> - unsigned int partial;
>>> + unsigned int partial = scsi_get_resid(srb);
>>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>> scsi_sg_count(srb), scsi_bufflen(srb),
>>> &partial);
>>>
>>>
>>> -
>> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
>> doing
>> which was the one called before.
>
> Um, yes it was. The original code did this
>
> sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
>
> Which was at liberty not to touch resid, which it chose not to do in the
> error legs.
>
> Your new code does
>
> int partial; <- stack uninitialised
> sb_stor_bulk_transfer_sglist(..., &partial, ...);
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>
> If the function doesn't touch partial, as it doesn't in the error legs,
> resid now gets set with rubbish.
>
> Actually, my code is still wrong .. we have to set it to
> scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
> left untouched.
>
>> I have such a device and I get one reset but then every thing works nice.
>> This is with debug on. I'll try to make it fail.
>
> James
>
>
Sorry I still don't see it.
original code did sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
but sb_stor_bulk_transfer_sg does the:
int partial; <- stack uninitialised
sb_stor_bulk_transfer_sglist(..., &partial, ...);
and then unconditionally sets *residual = length_left;
I do not see an "error legs" case in sb_stor_bulk_transfer_sg().
I have just cut and pasted the !use_sg from sb_stor_bulk_transfer_sg names
and all
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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, 2008-01-29 at 20:27 +0200, Boaz Harrosh wrote:
> On Tue, Jan 29 2008 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> >> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
> >>
> >>> --- a/drivers/usb/storage/transport.c
> >>> +++ b/drivers/usb/storage/transport.c
> >>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> >>> us_data *us, unsigned int pipe,
> >>> * Common used function. Transfer a complete command
> >>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> >>> */
> >>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> - struct scsi_cmnd* srb)
> >>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> >>> + struct scsi_cmnd* srb, unsigned length)
> >>> {
> >>> unsigned int partial;
> >>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> >>> - scsi_sg_count(srb), scsi_bufflen(srb),
> >>> + scsi_sg_count(srb), length,
> >>> &partial);
> >>>
> >>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> >>> return result;
> >>> }
> >>>
> >>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> >>> + struct scsi_cmnd* srb)
> >>> +{
> >>> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> >>> +}
> >>> +
> >> I don't like this patch very much. Why add another layer of
> >> indirection when the two subroutines do hardly any work? Leave
> >> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> >> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> >> and scsi_set_resid().
> >>
> >> BTW, the standard coding style calls for a blank line after the list of
> >> local variables at the start of a function or block.
> >
> > There's another bug in the transport.c conversion in that the residuals
> > are updated with bogus data in several error cases, since
> > usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> > is actually sent.
> >
> > I'm not sure if this is is the solution to the problem at hand, but it
> > definitely fixes another bug in the code.
> >
> > James
> >
> > diff --git a/drivers/usb/storage/transport.c
> > b/drivers/usb/storage/transport.c
> > index d9f4912..bab0858 100644
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> > *us, unsigned int pipe,
> > int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > struct scsi_cmnd* srb)
> > {
> > - unsigned int partial;
> > + unsigned int partial = scsi_get_resid(srb);
> > int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> > scsi_sg_count(srb), scsi_bufflen(srb),
> > &partial);
> >
> >
> > -
> But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
> doing
> which was the one called before.
Um, yes it was. The original code did this
sb_stor_bulk_transfer_sg(..., &srp->resid, ...)
Which was at liberty not to touch resid, which it chose not to do in the
error legs.
Your new code does
int partial; <- stack uninitialised
sb_stor_bulk_transfer_sglist(..., &partial, ...);
scsi_set_resid(srb, scsi_bufflen(srb) - partial);
If the function doesn't touch partial, as it doesn't in the error legs,
resid now gets set with rubbish.
Actually, my code is still wrong .. we have to set it to
scsi_bufflen(srb) - scsi_resid(srb) so that it comes back the same if
left untouched.
> I have such a device and I get one reset but then every thing works nice.
> This is with debug on. I'll try to make it fail.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 18:34 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
>> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>>
>>> --- a/drivers/usb/storage/transport.c
>>> +++ b/drivers/usb/storage/transport.c
>>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
>>> us_data *us, unsigned int pipe,
>>> * Common used function. Transfer a complete command
>>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>>> */
>>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> - struct scsi_cmnd* srb)
>>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>>> + struct scsi_cmnd* srb, unsigned length)
>>> {
>>> unsigned int partial;
>>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>>> - scsi_sg_count(srb), scsi_bufflen(srb),
>>> + scsi_sg_count(srb), length,
>>> &partial);
>>>
>>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>>> return result;
>>> }
>>>
>>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>>> + struct scsi_cmnd* srb)
>>> +{
>>> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>>> +}
>>> +
>> I don't like this patch very much. Why add another layer of
>> indirection when the two subroutines do hardly any work? Leave
>> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
>> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
>> and scsi_set_resid().
>>
>> BTW, the standard coding style calls for a blank line after the list of
>> local variables at the start of a function or block.
>
> There's another bug in the transport.c conversion in that the residuals
> are updated with bogus data in several error cases, since
> usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
> is actually sent.
>
> I'm not sure if this is is the solution to the problem at hand, but it
> definitely fixes another bug in the code.
>
> James
>
> diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
> index d9f4912..bab0858 100644
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> *us, unsigned int pipe,
> int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> struct scsi_cmnd* srb)
> {
> - unsigned int partial;
> + unsigned int partial = scsi_get_resid(srb);
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> scsi_sg_count(srb), scsi_bufflen(srb),
> &partial);
>
>
> -
But then this is weird because it is not what usb_stor_bulk_transfer_sg() is
doing
which was the one called before.
I have such a device and I get one reset but then every thing works nice.
This is with debug on. I'll try to make it fail.
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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
Am Dienstag, 29. Januar 2008 16:50:35 schrieb Boaz Harrosh: > On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote: > I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help. > I have a device here that uses the same trasport/protocol I'll > try to reproduce the failure here. This is the most common combination of transport and protocol. If it were broken in a larger number of cases, we'd hear more reports. You'll probably need the debug output to figure out what's wrong. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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, 2008-01-29 at 10:36 -0500, Alan Stern wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>
> > --- a/drivers/usb/storage/transport.c
> > +++ b/drivers/usb/storage/transport.c
> > @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
> > us_data *us, unsigned int pipe,
> > * Common used function. Transfer a complete command
> > * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> > */
> > -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > - struct scsi_cmnd* srb)
> > +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> > + struct scsi_cmnd* srb, unsigned length)
> > {
> > unsigned int partial;
> > int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> > - scsi_sg_count(srb), scsi_bufflen(srb),
> > + scsi_sg_count(srb), length,
> > &partial);
> >
> > scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> > return result;
> > }
> >
> > +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> > + struct scsi_cmnd* srb)
> > +{
> > + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> > +}
> > +
>
> I don't like this patch very much. Why add another layer of
> indirection when the two subroutines do hardly any work? Leave
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> and scsi_set_resid().
>
> BTW, the standard coding style calls for a blank line after the list of
> local variables at the start of a function or block.
There's another bug in the transport.c conversion in that the residuals
are updated with bogus data in several error cases, since
usb_stor_bulk_transfer_sglist() only sets the actual length if the urb
is actually sent.
I'm not sure if this is is the solution to the problem at hand, but it
definitely fixes another bug in the code.
James
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..bab0858 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -465,7 +465,7 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
struct scsi_cmnd* srb)
{
- unsigned int partial;
+ unsigned int partial = scsi_get_resid(srb);
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
scsi_sg_count(srb), scsi_bufflen(srb),
&partial);
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aic7xxx - ahc_done check SCB_ACTIVE for tagged transactions
Hannes Reinecke wrote:
David Milburn wrote:
Hannes,
Does ahc_done need to check the SCB_ACTIVE flag only if the SCB
is not in the untagged queue before panic?
If the driver is in error recovery, you may end panic'ing
on a TUR that is in the untagged queue.
Attempting to queue an ABORT message
CDB: 0x0 0x0 0x0 0x0 0x0 0x0
SCB 3 done'd twice
This patch is included in Adaptec's 6.3.11 driver on their
website.
Thank you,
David
--- scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c.abort
+++ scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1658,9 +1658,12 @@ ahc_done(struct ahc_softc *ahc, struct s
untagged_q = &(ahc->untagged_queues[target_offset]);
TAILQ_REMOVE(untagged_q, scb, links.tqe);
BUG_ON(!TAILQ_EMPTY(untagged_q));
- }
-
- if ((scb->flags & SCB_ACTIVE) == 0) {
+ } else if ((scb->flags & SCB_ACTIVE) == 0) {
+ /*
+* Transactions aborted from the untagged queue may
+* not have been dispatched to the controller, so
+* only check the SCB_ACTIVE flag for tagged transactions.
+*/
printf("SCB %d done'd twice\n", scb->hscb->tag);
ahc_dump_card_state(ahc);
panic("Stopping for safety");
Yes, this looks correct. The SCB_ACTIVE flag is reset when doing an
ahc_scb_free()
at the very end of ahc_done(). And seeing that we are re-using scbs for error
recovery
we might indeed end up with an scb with SCB_ACTIVE is set.
But I'll do some more investigation.
Do you have any setup to exercise this?
Hannes,
I don't have a hands on setup, but, I verified the fix
by providing a rhel4 test kernel to prevent the panic
above.
James committed to scsi-misc-2.6.git
cddb3e38076639aacf2182e4b164e45ee8bbe6d8
Thanks,
David
Cheers,
Hannes
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 17:36 +0200, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Jan 2008, Boaz Harrosh wrote:
>
>> --- a/drivers/usb/storage/transport.c
>> +++ b/drivers/usb/storage/transport.c
>> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct
>> us_data *us, unsigned int pipe,
>> * Common used function. Transfer a complete command
>> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
>> */
>> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> - struct scsi_cmnd* srb)
>> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
>> + struct scsi_cmnd* srb, unsigned length)
>> {
>> unsigned int partial;
>> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
>> - scsi_sg_count(srb), scsi_bufflen(srb),
>> + scsi_sg_count(srb), length,
>>&partial);
>>
>> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
>> return result;
>> }
>>
>> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
>> +struct scsi_cmnd* srb)
>> +{
>> +return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
>> +}
>> +
>
> I don't like this patch very much. Why add another layer of
> indirection when the two subroutines do hardly any work? Leave
> usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
> as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
> and scsi_set_resid().
>
> BTW, the standard coding style calls for a blank line after the list of
> local variables at the start of a function or block.
>
> Alan Stern
>
> -
Me neither, it's not a proper patch just a shut to try and find the reported
bug. I will submit a proper bug later.
Thanks for the review, you are right on all accounts
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 16:31 +0200, Oliver Neukum <[EMAIL PROTECTED]> 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. > > Regards > Oliver > - I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help. I have a device here that uses the same trasport/protocol I'll try to reproduce the failure here. Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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, 29 Jan 2008, Boaz Harrosh wrote:
> --- a/drivers/usb/storage/transport.c
> +++ b/drivers/usb/storage/transport.c
> @@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
> *us, unsigned int pipe,
> * Common used function. Transfer a complete command
> * via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
> */
> -int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> - struct scsi_cmnd* srb)
> +int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb, unsigned length)
> {
> unsigned int partial;
> int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
> - scsi_sg_count(srb), scsi_bufflen(srb),
> + scsi_sg_count(srb), length,
> &partial);
>
> scsi_set_resid(srb, scsi_bufflen(srb) - partial);
> return result;
> }
>
> +int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
> + struct scsi_cmnd* srb)
> +{
> + return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
> +}
> +
I don't like this patch very much. Why add another layer of
indirection when the two subroutines do hardly any work? Leave
usb_stor_bulk_srb() the way it was, and add usb_stor_bulk_srb_length()
as a separate routine that simply calls usb_stor_bulk_transfer_sglist()
and scsi_set_resid().
BTW, the standard coding style calls for a blank line after the list of
local variables at the start of a function or block.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA mapping on SCSI device?
On Tue, 2008-01-29 at 05:28 +0100, Andi Kleen wrote:
> > The ideal solution would be to do mapping against a different struct
> > device for each port, so that we could maintain the proper DMA mask for
> > each of them at all times. However I'm not sure if that's possible.
>
> I cannot imagine why it should be that difficult. The PCI subsystem
> could over a pci_clone_device() or similar function. For all complicated
> purposes (sysfs etc) the original device could be used, so it would
> be hopefully not that difficult.
I know it works for parisc ... all we care about for DMA mapping is the
mask in the actual device and the location of the iommu. For the
latter, we just go up device->parent until we find it, so as long as
manufactured devices are properly parented we have no problems with
mapping them.
The concern matthew has is this code in asm-generic/dma-mapping.h:
static inline void *
dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t
*dma_handle,
gfp_t flag)
{
BUG_ON(dev->bus != &pci_bus_type);
return pci_alloc_consistent(to_pci_dev(dev), size, dma_handle);
}
The manufactured devices wouldn't be PCI devices (otherwise they'd show
up in PCI and cause all sorts of confusion), so any architectures which
haven't converted to using the dma_ functions internally will BUG here.
However, a quick audit shows that to be just m68k, v850 and sparc (not
sparc64), so they're probably none the driver cares about.
> The alternative would be to add a new family of PCI mapping
> functions that take an explicit mask. Disadvantage would be changing
> all architectures, but on the other hand the interface could be phase
> in one by one (and nF4 primarily only works on x86 anyways)
I suppose it would allow us to clean dma_mask and dma_coherent_mask out
of the device structures ... on the other hand, the mask isn't simply
what the device wants, it's also what the platform allows you to set, so
it would have to be stored somewhere anyway.
> I suspect the later would be a little cleaner, although they don't
> make much difference.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aic7xxx - ahc_done check SCB_ACTIVE for tagged transactions
David Milburn wrote:
> Hannes,
>
> Does ahc_done need to check the SCB_ACTIVE flag only if the SCB
> is not in the untagged queue before panic?
>
> If the driver is in error recovery, you may end panic'ing
> on a TUR that is in the untagged queue.
>
> Attempting to queue an ABORT message
> CDB: 0x0 0x0 0x0 0x0 0x0 0x0
> SCB 3 done'd twice
>
> This patch is included in Adaptec's 6.3.11 driver on their
> website.
>
> Thank you,
> David
>
> --- scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c.abort
> +++ scsi-misc-2.6.git/drivers/scsi/aic7xxx/aic7xxx_osm.c
> @@ -1658,9 +1658,12 @@ ahc_done(struct ahc_softc *ahc, struct s
> untagged_q = &(ahc->untagged_queues[target_offset]);
> TAILQ_REMOVE(untagged_q, scb, links.tqe);
> BUG_ON(!TAILQ_EMPTY(untagged_q));
> - }
> -
> - if ((scb->flags & SCB_ACTIVE) == 0) {
> + } else if ((scb->flags & SCB_ACTIVE) == 0) {
> + /*
> + * Transactions aborted from the untagged queue may
> + * not have been dispatched to the controller, so
> + * only check the SCB_ACTIVE flag for tagged transactions.
> + */
> printf("SCB %d done'd twice\n", scb->hscb->tag);
> ahc_dump_card_state(ahc);
> panic("Stopping for safety");
>
Yes, this looks correct. The SCB_ACTIVE flag is reset when doing an
ahc_scb_free()
at the very end of ahc_done(). And seeing that we are re-using scbs for error
recovery
we might indeed end up with an scb with SCB_ACTIVE is set.
But I'll do some more investigation.
Do you have any setup to exercise this?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 02:15:15PM +0200, 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. > > Matthew, Greg, Is there a way to extract from messages the usb storage > transport > used? I'm guessing it is freecom do to the fact that I find a bug there. The freecom transport is exceptionally rare these days. It's primary user was a device made by a company that went out of business. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Way to go, lava boy. -- Stef to Greg User Friendly, 3/26/1998 pgpeBHHebaraJ.pgp Description: PGP signature
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-scsi" 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
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. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 16:11 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote: > 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' > Sorry for the other noise. Thanks I'll have a look. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 at 16:06 +0200, Boaz Harrosh <[EMAIL PROTECTED]> 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.
>
>From inspection of code it should be in /proc/scsi somewhere look for:
SPRINTF(" Protocol: %s\n", us->protocol_name);
SPRINTF("Transport: %s\n", us->transport_name);
(it's proc_info() in drivers/usb/storage/scsiglue.c)
Thanks
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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 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. Thanks for testing Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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
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.
Matthew, Greg, Is there a way to extract from messages the usb storage transport
used? I'm guessing it is freecom do to the fact that I find a bug there.
Thanks
Boaz
---
drivers/usb/storage/freecom.c |4 ++--
drivers/usb/storage/transport.c | 12 +---
drivers/usb/storage/transport.h |3 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
index f5a4e8d..8d77603 100644
--- a/drivers/usb/storage/freecom.c
+++ b/drivers/usb/storage/freecom.c
@@ -132,7 +132,7 @@ freecom_readdata (struct scsi_cmnd *srb, struct us_data *us,
/* Now transfer all of our blocks. */
US_DEBUGP("Start of read\n");
- result = usb_stor_bulk_srb(us, ipipe, srb);
+ result = usb_stor_bulk_srb_length(us, ipipe, srb, count);
US_DEBUGP("freecom_readdata done!\n");
if (result > USB_STOR_XFER_SHORT)
@@ -165,7 +165,7 @@ freecom_writedata (struct scsi_cmnd *srb, struct us_data
*us,
/* Now transfer all of our blocks. */
US_DEBUGP("Start of write\n");
- result = usb_stor_bulk_srb(us, opipe, srb);
+ result = usb_stor_bulk_srb_length(us, opipe, srb, count);
US_DEBUGP("freecom_writedata done!\n");
if (result > USB_STOR_XFER_SHORT)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index d9f4912..5072235 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -462,18 +462,24 @@ static int usb_stor_bulk_transfer_sglist(struct us_data
*us, unsigned int pipe,
* Common used function. Transfer a complete command
* via usb_stor_bulk_transfer_sglist() above. Set cmnd resid
*/
-int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
- struct scsi_cmnd* srb)
+int usb_stor_bulk_srb_length(struct us_data* us, unsigned int pipe,
+ struct scsi_cmnd* srb, unsigned length)
{
unsigned int partial;
int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),
- scsi_sg_count(srb), scsi_bufflen(srb),
+ scsi_sg_count(srb), length,
&partial);
scsi_set_resid(srb, scsi_bufflen(srb) - partial);
return result;
}
+int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,
+ struct scsi_cmnd* srb)
+{
+ return usb_stor_bulk_srb_length(us, pipe, srb, scsi_bufflen(srb));
+}
+
/*
* Transfer an entire SCSI command's worth of data payload over the bulk
* pipe.
diff --git a/drivers/usb/storage/transport.h b/drivers/usb/storage/transport.h
index ada7c2f..03e395d 100644
--- a/drivers/usb/storage/transport.h
+++ b/drivers/usb/storage/transport.h
@@ -139,8 +139,9 @@ extern int usb_stor_bulk_transfer_buf(s
Re: [PATCH 1/1][] Test opcode, not definition in type_check(), drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
Roel Kluin wrote: > drivers/scsi/aic7xxx_old/sequencer.h:130:#define AIC_OP_JZ 0xf > -- > Test opcode, not definition > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> > --- > diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y > b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y > index 6066998..702e2db 100644 > --- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y > +++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y > @@ -1837,7 +1837,7 @@ type_check(symbol_t *symbol, expression_t *expression, > int opcode) > int and_op; > > and_op = FALSE; > - if (opcode == AIC_OP_AND || opcode == AIC_OP_JNZ || AIC_OP_JZ) > + if (opcode == AIC_OP_AND || opcode == AIC_OP_JNZ || opcode == AIC_OP_JZ) > and_op = TRUE; > > /* Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aic79xx: fix sense_buffer access bug
FUJITA Tomonori wrote: > Ah, I overlooked more LLDs... > > = > From: FUJITA Tomonori <[EMAIL PROTECTED]> > Subject: [PATCH] aic79xx: fix sense_buffer access bug > > The commit de25deb18016f66dcdede165d07654559bb332bc changed > scsi_cmnd.sense_buffer from a static array to a dynamically allocated > buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] aic7xxx: fix warnings with CONFIG_PM disabled
FUJITA Tomonori wrote: > CC [M] drivers/scsi/aic7xxx/aic7xxx_osm_pci.o > drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:148: warning: > 'ahc_linux_pci_dev_suspend' defined but not used > drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:166: warning: > 'ahc_linux_pci_dev_resume' defined but not used > > This moves aic7xxx_pci_driver struct, removes some forward declarations, > and adds some ifdef CONFIG_PM. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] aic79xx: fix warnings with CONFIG_PM disabled
FUJITA Tomonori wrote: > CC [M] drivers/scsi/aic7xxx/aic79xx_osm_pci.o > drivers/scsi/aic7xxx/aic79xx_osm_pci.c:101: warning: > 'ahd_linux_pci_dev_suspend' defined but not used > drivers/scsi/aic7xxx/aic79xx_osm_pci.c:121: warning: > 'ahd_linux_pci_dev_resume' defined but not used > > This moves aic79xx_pci_driver struct, removes some forward > declarations, and adds some ifdef CONFIG_PM. > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
