From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 02:10:22 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2402116A4B3; Sat, 27 Sep 2003 02:10:22 -0700 (PDT) Received: from gatekeeper.ttfn.com (12-235-40-48.client.attbi.com [12.235.40.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6038444028; Sat, 27 Sep 2003 02:10:20 -0700 (PDT) (envelope-from davet@ttfn.com) Received: from ttfn.com (neko.ttfn.com [192.168.0.41]) by gatekeeper.ttfn.com (Postfix) with ESMTP id 0C7F01C29C; Sat, 27 Sep 2003 02:10:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ttfn.com (8.12.9/8.12.9) with ESMTP id h8R9AJcZ055840; Sat, 27 Sep 2003 02:10:19 -0700 (PDT) (envelope-from davet@ttfn.com) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Wesley Morgan In-Reply-To: Message from Wesley Morgan <20030926093535.A96532@volatile.chemikals.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Sep 2003 02:10:18 -0700 Message-ID: <55839.1064653818@localhost> From: Dave Truesdell cc: current@freebsd.org Subject: Re: yep, umass still broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2003 09:10:22 -0000 -- 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.