Re: yep, umass still broken

What motherboards are you using with the OHCI controller?

John-Mark Gurney (jmg_at_) and I kicked this around at bsdcon but couldn't
reproduce it.  If its a common board or chipset we can probably get it and
work on the issue.  The zeroed block showed up in 8KB boundaries in the
instance we saw, which is asupicious since most OHCI controllers have a
DMA limitation of 1 page crossing.

I have a ppro with Intel OHCI which I haven't tested yet.

On Sat, 27 Sep 2003, Dave Truesdell wrote:

> -- 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.
>
>
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org