Date: Sat, 27 Sep 2003 02:10:18 -0700 From: Dave Truesdell <davet@ttfn.com> To: Wesley Morgan <morganw@chemikals.org> Cc: current@freebsd.org Subject: Re: yep, umass still broken Message-ID: <55839.1064653818@localhost> In-Reply-To: Message from Wesley Morgan <morganw@chemikals.org> <20030926093535.A96532@volatile.chemikals.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55839.1064653818>