Re: yep, umass still broken

-- Your message was:   (from "Wesley Morgan")
On Fri, 26 Sep 2003, Brian Fundakowski Feldman wrote:

> I can get fdisk to read the MBR, but when I try mdir, I get this trace back
> (of course, no crash dump because those haven't worked for me in a year):
> trap 0xc
> memcpy()
> ohci_softintr()
> usb_schedsoftintr()
> ohci_intr1()
> ohci_intr()
> ithread_loop()
>
> Anyone have any clued?  I'll include my dmesg, of course.

It was unbroken for a while, but has been broken for at least a month
(seem my earlier post about it). The umass driver has been a constant
source of frustation for me and suffers from constant breakage and
neglect.

-- End of Message

You may not want to blame the umass driver.  I've been doing a little 
experimenting trying to get a handle on what's going on.  Luckily I have two 
machines sitting side-by-side, one with OHCI and one with UHCI.  Many of the 
UMASS devices I have fail with 5.1-CURRENT on the OHCI machine but work just 
fine on the UHCI system.

Here's the note I sent as a followup to kern/54982:
  I am encountering this problem as well.  What I've seen so far is this:
 
  1. The corruption does not occur with all UMASS devices.  For example, I 
  see data corruption with a Creative Labs MUVO (128M) and NEXDISK (256M) 
  devices, but not with an Easydisc (128M) device.
 
  2. I've only seen the corruption with OHCI based controllers.  When I 
  connect the same device to a UHCI based machine, built from an identical 
  copy of the source tree, I see no corruption.
 
  3. The pattern of corruption is decidely non-random.  If you view the 
  file as a series of 4K blocks numbered 0 to N, the corruption I've seen 
  follows the following pattern:
     (B == a zero filled 4k block)
 
  Original: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 ...
  Corrupt:  0  3  2  B  4  7  6  B  8 11 10  B 12 15 14  B ...
 
  I can provide logs of a file copy done on both the OHCI and UHCI based 
  systems done with hw.usb.debug=3 hw.usb.uhci.debug=6 hw.usb.ohci.debug=6 
  and hw.usb.umass.debug=4294901760 if you wish.  They are far too long to 
  attach here.
 
  This test was last run on 5.1-CURRENT cvsup'd on Sep 17th 2003.

I'm presently updating both machines to -CURRENT cvsup'd this afternoon.

I haven't gotten to the point where I understand the interactions between 
umass, ohci/uhci and cam well enough to even hazzard a guess about where the 
corruption is occuring.