Re: [linux-usb-devel] RE: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze

Mauro Carvalho Chehab wrote: > Alan, > Em Seg, 2006-03-20 às 23:09 +0100, thomas schorpp escreveu: > >>Alan Stern wrote: >> >>>On Wed, 15 Mar 2006, Ballentine, Casey wrote: > > >>what DMA problem? ive always used via chipsets with usb. now the 8237. > > >>the via pci-busmaster dma hangs the s

Re: [linux-usb-devel] RE: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze

Alan, Em Seg, 2006-03-20 às 23:09 +0100, thomas schorpp escreveu: > Alan Stern wrote: > > On Wed, 15 Mar 2006, Ballentine, Casey wrote: > what DMA problem? ive always used via chipsets with usb. now the 8237. > the via pci-busmaster dma hangs the system? No. it is PCI to PCI transfers ocurring w

Re: [linux-usb-devel] RE: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze

Alan Stern wrote: > On Wed, 15 Mar 2006, Ballentine, Casey wrote: > > >>Mauro, >> >>I would bet we could add the vt8235 to the list of broken chipsets >>as well, if it's not already there. My company has completely >>disabled DMA in the 2.6.13.4 kernel we're running on an >>EPIA PD-1 boar

Re: [linux-usb-devel] RE: [usb-storage] Re: [v4l-dvb-maintainer] 2.6.16-rc: saa7134 + u sb-storage = freeze

On Wed, 15 Mar 2006, Ballentine, Casey wrote: > Mauro, > > I would bet we could add the vt8235 to the list of broken chipsets > as well, if it's not already there. My company has completely > disabled DMA in the 2.6.13.4 kernel we're running on an > EPIA PD-1 board due to lockupslike thes

Re: [linux-usb-devel] Re: [usb-storage] PATCH: devices which don't process PREVENT-ALLOW MEDIUM REMOVAL

On Mon, 31 Jan 2005, Phil Dibowitz wrote: > It's been argued to me that there are bad cases where the same > productId, VendorId, and bdcDevice number have been given to two > different, but very similar devices that act differently. There are indeed, and in such cases comments are very helpful.

Re: [linux-usb-devel] Re: [usb-storage] PATCH: devices which don't process PREVENT-ALLOW MEDIUM REMOVAL

Alan Stern wrote: Yes. I removed the comment not because it was wrong, but because it was redundant. You can tell just by reading the entry that the subclass override must be necessary -- if it weren't needed it would say US_SC_DEVICE instead. (How can you tell? Because the Protocol entry has b

Re: [linux-usb-devel] Re: usb-storage since at least 2.6.3: destroys partitions on hdd

> There have been reports from other people about USB mass storage devices > corrupting data. In general nobody has been able to find a cause. Some mass storage devices (mp3 players, mobile phones, ...) have buggy filesystem implementations which cause corruption when the devices is accessed fr

Re: [linux-usb-devel] Re: usb-storage since at least 2.6.3: destroys partitions on hdd

On Sun, 23 Jan 2005, Andries Brouwer wrote: > I asked: You report that you get I/O errors with Linux kernels 2.6.3-2.6.9. > Are there kernels that work? > > Thomas replied: > > > Yes it works fine with all 2.4 kernels > > but I'm not sure if it did ever with a 2.6 kernel. > > I have this problem

Re: [linux-usb-devel] Re: [usb-storage] PATCH: delayed device scanning

On Mon, Sep 27, 2004 at 09:34:04AM -0700, Matthew Dharm wrote: > Lots of work? Tragic. But that's what you get when you're the > unusual_devs.h guy. Handle it as you see best, but the goal is to make > unusual_devs.h as small as possible. Woah there buddy! I'm okay with the work... I don't reca

Re: [linux-usb-devel] Re: [usb-storage] PATCH: delayed device scanning

On Mon, Sep 27, 2004 at 05:15:37PM -0700, Phil Dibowitz wrote: > On Mon, Sep 27, 2004 at 03:34:06PM -0700, Matthew Dharm wrote: > > I'm hesitant to "minimize" this much. > > > > I want a value that will help many of the FIX_INQUIRY devices we have. I > > want to cut down on people having to add e

Re: [linux-usb-devel] Re: [usb-storage] PATCH: delayed device scanning

On Mon, Sep 27, 2004 at 03:34:06PM -0700, Matthew Dharm wrote: > On Mon, Sep 27, 2004 at 11:01:32AM -0700, Phil Dibowitz wrote: > > On Mon, Sep 27, 2004 at 09:34:04AM -0700, Matthew Dharm wrote: > > > Lots of work? Tragic. But that's what you get when you're the > > > unusual_devs.h guy. Handle

Re: [linux-usb-devel] Re: [usb-storage] PATCH: delayed device scanning

On Mon, Sep 27, 2004 at 11:01:32AM -0700, Phil Dibowitz wrote: > On Mon, Sep 27, 2004 at 09:34:04AM -0700, Matthew Dharm wrote: > > Lots of work? Tragic. But that's what you get when you're the > > unusual_devs.h guy. Handle it as you see best, but the goal is to make > > unusual_devs.h as small

Re: [linux-usb-devel] Re: [usb-storage] PATCH: Lexar Jumpshot CF reader

On Fri, Jun 18, 2004 at 11:29:28AM -0400, Alan Stern wrote: > On Thu, 17 Jun 2004, Pete Zaitcev wrote: > > > So, would it be all right to send the appended patch to Marcelo? > > > > -- Pete > > I think so, although I'm not sure if 2.4 includes the corresponding > corrections in the other subdri

Re: [linux-usb-devel] Re: [usb-storage] PATCH: Lexar Jumpshot CF reader

On Thu, 17 Jun 2004, Pete Zaitcev wrote: > So, would it be all right to send the appended patch to Marcelo? > > -- Pete I think so, although I'm not sure if 2.4 includes the corresponding corrections in the other subdrivers. But note that the users who reported the problem originally said tha

Re: [linux-usb-devel] Re: [usb-storage] Malfunctioning USB stick

Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Donnerstag, 13. Mai 2004 20:09 schrieb Alan Stern: > > On Thu, 13 May 2004, Oliver Neukum wrote: > > > > > Hi, > > > > > > this stick is acting up. > > > I just mounted it and got (no disconnection physically): > > > > It looks like some sort of I/O

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

On Fri, May 07, 2004 at 09:49:35AM -0700, David Brownell wrote: > [EMAIL PROTECTED] wrote: > >David Brownell wrote: > > > >>Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set, > >>usbcore would reject urbs with -EAGAIN ... from all contexts, > >>including the many that can't acqui

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

[EMAIL PROTECTED] wrote: David Brownell wrote: Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set, usbcore would reject urbs with -EAGAIN ... from all contexts, including the many that can't acquire semaphores! Going back a bit--what context were you thinking of that wouldn'

RE: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

David Brownell wrote: > > Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set, > usbcore would reject urbs with -EAGAIN ... from all contexts, > including the many that can't acquire semaphores! > Going back a bit--what context were you thinking of that wouldn't be able to gra

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

[EMAIL PROTECTED] wrote: But wouldn't a bit flag require continuous retries on the part of whomever gets the -EAGAIN when they try to submit an URB? And, if so, wouldn't that leave open the possibility of them missing the window when the BUSY bit isn't set (unless they retry in a very tight loop,

RE: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

David Brownell wrote: >>> Wouldn't a plain old atomic "BUSY" bitflag work better? If it's >>> set, usbcore would reject urbs with -EAGAIN ... from all >>> contexts, including the many that can't acquire semaphores! >> >> >> I thought (and I might be confused with other OSes here) that there >> w

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

Wouldn't a plain old atomic "BUSY" bitflag work better? If it's set, usbcore would reject urbs with -EAGAIN ... from all contexts, including the many that can't acquire semaphores! I thought (and I might be confused with other OSes here) that there was a way to attempt to acquire a semaphore fro

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_featuredoesn'th appen when get_descriptor on pipe

> My guess is that if people actually tried, > they could find this bug on many other > devices. usb-storage makes it easy because > the time window during which the bug can be > triggered (ie. from CBW to CSW, which includes > the media-access time) is kinda large. Indeed, media-access may incl

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

On Wed, May 05, 2004 at 11:36:00AM -0700, David Brownell wrote: > Matthew Dharm wrote: > >On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote: > > >>I hereby invite comments from other USB developers... > >> > >>We are discussing the possibility of adding a semaphore to struct > >>usb_devic

Re: [linux-usb-devel] Re: [usb-storage] Re: Clear_feature doesn't happen when get_descriptor on pipe

Matthew Dharm wrote: On Wed, May 05, 2004 at 12:23:35PM -0400, Alan Stern wrote: I hereby invite comments from other USB developers... We are discussing the possibility of adding a semaphore to struct usb_device. This semaphore would be acquired by usbfs (and maybe other parts of usbcore too) be

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

> > > So everybody who does not want to know how integers are > > > represented on the current architecture writes > > > start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24); > > > And it just works. > > > > Really, ... > > I have been arguing that casts are bad ... Thanks for the hint. Somet

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

On Maw, 2004-01-13 at 12:35, Paulo Marques wrote: > 1 - we can let the kernel trap and correct all unaligned accesses. This way > applications (and the kernel itself) would run slower but with no other problems. > > 2 - we can let the kernel just "count" unaligned accesses and let developers > c

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

Pete Zaitcev wrote: On Mon, 12 Jan 2004 22:04:16 +0100 (MET) [EMAIL PROTECTED] wrote: > So everybody who does not want to know how integers are represented > on the current architecture writes > start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24); > And it just works. Real

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

On Mon, 12 Jan 2004 22:04:16 +0100 (MET) [EMAIL PROTECTED] wrote: > > So everybody who does not want to know how integers are represented > > on the current architecture writes > > start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24); > > And it just works. > > Really,

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

On Mon, 12 Jan 2004 [EMAIL PROTECTED] wrote: > [did you write be32 by mistake?] Alas, yes! How embarrassing... :-( Alan Stern --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

Am Montag, 12. Januar 2004 20:31 schrieb [EMAIL PROTECTED]: > | Let me tell you - I have programmed for twenty years without > | knowing the meaning of little-endian and big-endian. Yes, > | they had something to do with the order of bytes in an integer, > | but there are many stran

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

> So everybody who does not want to know how integers are represented > on the current architecture writes > start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24); > And it just works. Really, do you think your statement is better, clearer, or less error-prone than t

Re: [linux-usb-devel] Re: [usb-storage] PATCH: fix mode-sense handling for 10-byte commands

On Mon, 12 Jan 2004 [EMAIL PROTECTED] wrote: > Let me give another example. > When reading DOS-type partition tables, one encounters four bytes > that give the start of a partition. Least significant byte first. > > So everybody who does not want to know how integers are represented > on the curr

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Fri, Oct 03, 2003 at 10:05:52AM -0500, James Bottomley wrote: > Well, the patch isn't quite correct because if it's not going to probe > the cache it should set up a write through cache (or disabled cache) as > the default. Alan's original patch is included in my patch. > Patrick's patch > >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

There haven't been any replies to my suggestion from a week ago http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2 for a way to resolve the mode-sense page 8 problem. One way or another, I wish somebody would do _something_ about this, particularly before 2.6.0-final comes out.

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Fri, 2003-10-03 at 09:18, Alan Stern wrote: > There haven't been any replies to my suggestion from a week ago > > http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2 > > for a way to resolve the mode-sense page 8 problem. One way or another, I > wish somebody would do _something

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Wed, 24 Sep 2003, Linus Torvalds wrote: > Ok. I committed my version as "better than what is there now", but clearly > it's not good enough. > > So we should really add code to sd_read_cache_type() to default to > write-through for USB devices. The question is, what kind of flag do we > want

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Wed, 24 Sep 2003, Ruud Linders wrote: > > > > Is this different from a plain kernel _without_ the patch? > > No difference. Ok. I committed my version as "better than what is there now", but clearly it's not good enough. So we should really add code to sd_read_cache_type() to default to wr

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Linus Torvalds wrote: On Tue, 23 Sep 2003, Ruud Linders wrote: I tried the patch but it doesn't work for me using an USB-2 Memory stick "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded). After a 3 minute time-out I get "SCSI device sda: drive cache: write through" and the device

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Tue, 2003-09-23 at 10:23, Alan Stern wrote: > Is there any way to notify the system that you are about to unplug a > drive? It seems to me that the best approach is to flush the cache on an > unmount. People naturally assume that it's safe to unplug a device once > it has been unmounted, a

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

From [EMAIL PROTECTED] Tue Sep 23 16:05:21 2003 > Also "conservative mode" sounds like a flag that describes some > way of being broken. > > On the other hand "hot-pluggable" describes a positive asset, > and if we can conclude from that that it is unnecessary to ask

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

I tried the patch but it doesn't work for me using an USB-2 Memory stick "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded). After a 3 minute time-out I get "SCSI device sda: drive cache: write through" and the device starts working just fine. Unloading the ehci_hcd module doesn't

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Tue, 23 Sep 2003, Ruud Linders wrote: > > I tried the patch but it doesn't work for me using an USB-2 Memory stick > "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded). > > After a 3 minute time-out I get > "SCSI device sda: drive cache: write through" > and the device starts

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote: > > No, the design goal of "hot-pluggable" is that it indicates that > the device can disappear any moment. Nothing at all about SCSI > compliance. You're talking past each other. Server people think that "hot-pluggable" means "I will tell the system

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On 23 Sep 2003, James Bottomley wrote: > On Tue, 2003-09-23 at 09:37, [EMAIL PROTECTED] wrote: > > > Pulling out a device while it is actively reading or writing > > will probably break something. But if a device is hot-pluggable > > it should be OK to pull it out when it has been inactive for >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Tue, 2003-09-23 at 09:37, [EMAIL PROTECTED] wrote: > No, the design goal of "hot-pluggable" is that it indicates that > the device can disappear any moment. Nothing at all about SCSI > compliance. Actually, then, these are two issues...hotplug is being worked on separately at the moment. I tho

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 2003-09-22 at 14:56, [EMAIL PROTECTED] wrote: > I have seen proposals around here for flags that are far too specific > (like "do not ask for mode page 8"). If we go to that level of detail > then we'll soon have fifty flags. > Black lists, and flags that describe various ways of being brok

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

From [EMAIL PROTECTED] Mon Sep 22 21:29:06 2003 On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote: > if (sdkp->media_present) { > sd_read_capacity(sdkp, disk->disk_name, sreq, buffer); > if (sdp->removable) >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote: > I have seen proposals around here for flags that are far too specific > (like "do not ask for mode page 8"). If we go to that level of detail > then we'll soon have fifty flags. > Black lists, and flags that describe various ways of being broken > are

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 09:56:38PM +0200, [EMAIL PROTECTED] wrote: > A scsi device declares its level of scsi compliance. > Most USB storage devices are not very scsi compliant at all, > and report 0 there. Not exactly. The reporting of 0, 1, 2, or something random in that field appears to be com

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On 22 Sep 2003, James Bottomley wrote: > > I think we could try 4 bytes for this (even to avoid wide residue > problems) and see how it goes. How about just trusting the size (and as far as I can tell from the SCSI specs, the size is the size _without_ the header and block descriptors), and ca

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote: > if (sdkp->media_present) { > sd_read_capacity(sdkp, disk->disk_name, sreq, buffer); > if (sdp->removable) > sd_read_write_protect_flag(sdkp, disk->disk_name, >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Linus Torvalds wrote: > Yes. Additional testing (making the code just increase the size of the > transfer until it fails) shows that a size of 63 still works, but a size > of 64 bytes fails. > > Actually - with a 64-byte transfer, we appear to get the 64 bytes ok, but > th

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Christoph Hellwig wrote: > If we want drivers to mess with blist flags that's the more general > solution, yes. But the blist flags really are a target thing and > I'd prefer to keep host drivers a bit away from this. Of course > this doesn't really work for the usb case whe

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

> Basically, Andries Brouwer's strategy of making sd.c more conservative has > been a very successful one in the past. Why not continue on that? % I would be interested in hearing what Andries has to say. ... % The variety of ways in which these things fail is truly amazing. Yes. We have just se

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Llu, 2003-09-22 at 17:09, Linus Torvalds wrote: > - page len=1538 (pretty obviously crap) > - header len=8 (correct) > - block descriptor len=0 (correct) 1538 smells like they forgot to clear the top byte --- This sf.net email is sponsor

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, David Brownell wrote: > > Again, this case worked fine with the sd.c changes, so it does seem to be > > all related to "big" transfers out of the mode page. > > Or at any rate, "big enough" to confuse the device. Yes. Additional testing (making the code just increase the si

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 2003-09-22 at 12:41, Linus Torvalds wrote: > Ok, thanks. In particular, it seems to be pointless to read anything past > byte 20 - nothing past there is even defined. > > What's the general sense of things - for a random SCSI device with bugs > (and they all have _some_ sort of bugs, let

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Linus Torvalds wrote: On Mon, 22 Sep 2003, David Brownell wrote: In this case, because it's not "EHCI + USB 2.0 hub", it's still using the OHCI companion controller. So that wasn't a new case. Ok. Here's the broken case with an added usb-2 hub in between. It is indeed a bit different. Yes. In

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Patrick Mansfield wrote: > On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote: > > > > (Btw, where are the different mode sense pages documented?) > > The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs > are also online at www.t10.org (.ORG

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, David Brownell wrote: > > In this case, because it's not "EHCI + USB 2.0 hub", it's still using > the OHCI companion controller. So that wasn't a new case. Ok. Here's the broken case with an added usb-2 hub in between. It is indeed a bit different. Again, this case worked

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote: > > (Btw, where are the different mode sense pages documented?) > The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs are also online at www.t10.org (.ORG!). For block (applies to some USB mass storage) speci

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 09:44:04AM -0700, Patrick Mansfield wrote: > The current code allows us to set or clear a given bit, but not both. So > if we set them in slave_alloc, they can't be cleared without adding > other flags or code. If we want drivers to mess with blist flags that's the more gen

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Martin Diehl wrote: Unfortunately I don't see an easy way to check the sourced packed size on the wire - except using a bus analyzer of course. Right. There are not-easy ways to do this, involving tricked out host controller drivers usable only to debug things like this, but I wouldn't want to g

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Linus Torvalds wrote: On Mon, 22 Sep 2003, David Brownell wrote: Linus Torvalds wrote: Interesting data-point: the device is a happy EHCI camper, and is totally able to read codepage 8 on EHCI. However, if I put it behind a USB-1 hub on the EHCI port, I see the same problems I saw with OHCI. Can

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, David Brownell wrote: > > So it is somehow related to USB-1 vs USB-2. I don't understand why the > > device would make a difference for something like mode page 8, but it > > looks like it transfers data fine for _small_ mode page requests under > > USB-1, and under USB-2 i

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 05:37:32PM +0100, Christoph Hellwig wrote: > > What I meant is not adding a blist flags member at all but rather > setting skip_ms_page_8 and skip_ms_page_3f from ->slave_alloc. > > But I probably missed something obvious :) The current code allows us to set or clear a gi

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Linus Torvalds wrote: > > [ Andries added to the cc ] > > On Mon, 22 Sep 2003, Patrick Mansfield wrote: > > > > I can modify the patch for that. > > How about just making the sd.c layer more robust? That has worked well in > the past, and it seems wrong to have to add mor

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote: > Interestingly, my original patch was a lot like you describe. It can be > found in > > http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2 Yupp, that's what I meant. Much less complicated :) -

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 08:49:30AM -0700, Patrick Mansfield wrote: > On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote: > > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote: > > > Patch looks mostly fine to me, but please all flags should be unsigned instead > > > o

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, David Brownell wrote: > > Linus Torvalds wrote: > > Interesting data-point: the device is a happy EHCI camper, and is > > totally able to read codepage 8 on EHCI. > > > > However, if I put it behind a USB-1 hub on the EHCI port, I see the > > same problems I saw with OHCI. >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Patrick Mansfield wrote: > On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote: > > > I don't care which version of the patch gets accepted, so long as > > _something_ is done. Patrick, what do you think? > > I would rather we can modify the flags for any broken devi

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Linus Torvalds wrote: On Mon, 22 Sep 2003, Alan Stern wrote: This problem has been cropping up with many, many USB storage devices. Interesting data-point: the device is a happy EHCI camper, and is totally able to read codepage 8 on EHCI. However, if I put it behind a USB-1 hub on the EHCI p

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

[ Andries added to the cc ] On Mon, 22 Sep 2003, Patrick Mansfield wrote: > > I can modify the patch for that. How about just making the sd.c layer more robust? That has worked well in the past, and it seems wrong to have to add more and more flags. In particular, while hunting down the usb-1

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote: > Interestingly, my original patch was a lot like you describe. It can be > found in > > http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2 > > Patrick Mansfield later beefed it up to the version you were looking at. >

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Christoph Hellwig wrote: > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote: > > Patch looks mostly fine to me, but please all flags should be unsigned instead > > of signed and scsi_devinfo.h needs some inclusion guards. > > Actually I think it could be made

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote: > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote: > > Patch looks mostly fine to me, but please all flags should be unsigned instead > > of signed and scsi_devinfo.h needs some inclusion guards. > > Actually I th

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, 22 Sep 2003, Alan Stern wrote: > > This problem has been cropping up with many, many USB storage devices. Interesting data-point: the device is a happy EHCI camper, and is totally able to read codepage 8 on EHCI. However, if I put it behind a USB-1 hub on the EHCI port, I see the same

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote: > Patch looks mostly fine to me, but please all flags should be unsigned instead > of signed and scsi_devinfo.h needs some inclusion guards. Actually I think it could be made much simpler by killing the per-template bflags and just

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

This problem has been cropping up with many, many USB storage devices. They just don't handle MODE-SENSE page 8 correctly. Some devices are okay with a 128-byte transfer and others aren't. Some are okay with a 64-byte transfer and others aren't. Some are okay transferring the actual size of th

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Mon, Sep 22, 2003 at 10:25:28AM -0400, Alan Stern wrote: > http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507&w=2 > > At the moment, this MODE-SENSE page 8 is probably the most severe > outstanding problem with the usb-storage driver. I'm all in favor of the > patch being adopted (

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

On Sun, Sep 21, 2003 at 08:00:07PM -0700, David Brownell wrote: > Matthew Dharm wrote: > > There's more to analyize, but on first inspection that babble looks bad. > > > > We submitted a single URB with a 128 byte buffer. We received 64 bytes. I > > don't think a babble is actually possible here

Re: [linux-usb-devel] Re: USB storage problems on OHCI..

Matthew Dharm wrote: There's more to analyize, but on first inspection that babble looks bad. We submitted a single URB with a 128 byte buffer. We received 64 bytes. I don't think a babble is actually possible here It's possible if the last packet received was bigger than the endpoint's maxp

SOLUTION, but why ? [Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1]

time a new kernel is released ? Thanks Mitch Original Message Subject: Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1 Date: Tue, 12 Aug 2003 19:05:12 +0100 From: David Brownell <[EMAIL PROTECTED]> To: linux-usb-devel <[EMAIL PROTECTED]> ...[ snip sni

Re: [linux-usb-devel] Re: [usb-storage] usb-key without partitionsand 2.6.0-test3

On Tue, 26 Aug 2003, Uberto Barbini wrote: > >> I'm a bit tired of blind suggestions, so I'll be grateful if someone gives > >> me any hint on how usb-storage is supposed to work and I'm glad to do some > >> debug on c code if necessary. > > BU> Trying configuring usb-storage debugging on, and po

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

* David Brownell <[EMAIL PROTECTED]>: > > - temp = readl (&ehci->regs->command) & 0x0fff; > > + temp = readl (&ehci->regs->command) & 0x00ff; > > > > And know what? It fixed my problem, drive works fine with dump at > > 10500 kB/s. > > And with the 0x0aff -- does it still work? No: Aug

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

Fridtjof Busse wrote: * Alan Stern <[EMAIL PROTECTED]>: I mentioned it on LKML, you probably didn't get it, sorry: nforce2 with ehci, some reported he doesn't have this problem with ohci (but I really don't want to do backups over USB 1.1). I'm not sure if you also got the error forwarded: "host_r

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

Fridtjof Busse wrote: * David Brownell <[EMAIL PROTECTED]>: Aug 11 07:49:05 artus kernel: hub.c: port 2, portstatus 503, change 10, 480 Mb/s Aug 11 07:49:05 artus kernel: hub.c: new USB device 00:02.2-2, assigned address 4 Aug 11 07:49:05 artus kernel: usb.c: kmalloc IF deeb3400, numif 1 Aug 11 07

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

On Sun, 10 Aug 2003, Fridtjof Busse wrote: > > > - dmesg output including all EHCI messages, with the usb code > > compiled with CONFIG_USB_DEBUG. The most important bits > > will be any problems it reports, near when the scsi layer > > gets unhappy. > > According to Alan, the out

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

* David Brownell <[EMAIL PROTECTED]>: > > Aug 11 07:49:05 artus kernel: hub.c: port 2, portstatus 503, change > > 10, 480 Mb/s > > Aug 11 07:49:05 artus kernel: hub.c: new USB device 00:02.2-2, > > assigned address 4 > > Aug 11 07:49:05 artus kernel: usb.c: kmalloc IF deeb3400, numif 1 > > Aug 11 0

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

Fridtjof Busse wrote: Aug 11 07:49:05 artus kernel: hub.c: port 2, portstatus 503, change 10, 480 Mb/s Aug 11 07:49:05 artus kernel: hub.c: new USB device 00:02.2-2, assigned address 4 Aug 11 07:49:05 artus kernel: usb.c: kmalloc IF deeb3400, numif 1 Aug 11 07:49:05 artus kernel: usb.c: new devic

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

That report wasn't very helpful. I recommend reviewing the "How do I report a bug?" FAQ at www.linux-usb.org next time, and for now forward: Sorry for that, someone on usb-users told me he already reported the bug, so I basically wanted to say "Hey, got the same problem". Well, "reported" to wh

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

* David Brownell <[EMAIL PROTECTED]>: > > Drive is connected to "PCI device 10de:0068 (nVidia Corporation)" > > Doesn't look like it. There was no storage device in what you sent. OK, today I'm much more awake... So here's plain -rc2: interrupts: 3: 4 XT-PIC ehci_hcd 10:

Re: [linux-usb-devel] Re: [usb-storage] Re: Linux 2.4.22-rc1

* David Brownell <[EMAIL PROTECTED]>: > >>> >>>&w=2> > > That report wasn't very helpful. I recommend reviewing the > "How do I report a bug?" FAQ at www.linux-usb.org next time, > and for now forward: Sorry for that, someone on

Re: [linux-usb-devel] Re: usb-storage fails to detect all luns after 2.4.19

Hoi! On Wed, Feb 26, 2003 at 10:03:41AM -0500, Alan Stern wrote: > On Wed, 26 Feb 2003, Oliver Graf wrote: > > On Thu, Feb 20, 2003 at 10:30:37PM +0100, Oliver Graf wrote: > > > I tried to find the parts that changed between the version, but it seems > > > not to be rooted in usb-storage. > > > >

Re: [linux-usb-devel] Re: usb-storage fails to detect all luns after 2.4.19

That could be the problem... I've also been meaning to take a look at the clear_halt code in 2.4.xx -- there was a 2.5 bug where we couldn't clear endpoint halts because of a change in the core logic. Matt On Wed, Feb 26, 2003 at 10:03:41AM -0500, Alan Stern wrote: > On Wed, 26 Feb 2003, Oliver

Re: [linux-usb-devel] Re: usb-storage fails to detect all luns after2.4.19

On Wed, 26 Feb 2003, Oliver Graf wrote: > Hi! > > On Thu, Feb 20, 2003 at 10:30:37PM +0100, Oliver Graf wrote: > > The problem: a multi device usb card reader is correctly detected with > > its four subdevices with kernel 2.4.19(-acX). But any patch after this > > fails to detect the subdevices.

Re: [linux-usb-devel] Re: [usb-storage] Re: PATCH: usb-storage: comments, cleanup

That's everything. Of course, I'm waiting on the SCSI folks to make this all bulletproof. Nothing like a bus where everything is hotplug to shake out the hotplug problems in other places. :) Matt On Mon, Feb 03, 2003 at 05:12:09PM -0800, Greg KH wrote: > On Mon, Feb 03, 2003 at 05:04:41PM -0800

Re: [linux-usb-devel] Re: [usb-storage] Re: PATCH: usb-storage: comments, cleanup

On Mon, Feb 03, 2003 at 05:04:41PM -0800, Matthew Dharm wrote: > I presume that this means that you'll be applying my latest patches and > forwarding on to Linus? Yup, I've added all the past ones from you to my "send to Linus tree" and the other two you just sent me. I think I have everything fr

Re: [linux-usb-devel] Re: [usb-storage] Re: PATCH: usb-storage: comments, cleanup

I presume that this means that you'll be applying my latest patches and forwarding on to Linus? Matt On Mon, Feb 03, 2003 at 03:45:30PM -0800, Greg KH wrote: > On Sun, Feb 02, 2003 at 03:12:28PM -0800, Matthew Dharm wrote: > > Greg, here's the patch to fix this. This makes usb-storage work again

Re: [linux-usb-devel] Re: [usb-storage] Re: PATCH: usb-storage: comments, cleanup

On Sun, Feb 02, 2003 at 03:12:28PM -0800, Matthew Dharm wrote: > Greg, here's the patch to fix this. This makes usb-storage work again. > > Please apply. Yeah, thanks for tracking this down, now usb-storage works for me! Applied, greg k-h -

  1   2   3   >