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