From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 20 16:12:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE27E16A4CE for ; Wed, 20 Oct 2004 16:12:57 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-160-253.dclient.hispeed.ch [80.219.160.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED64043D49 for ; Wed, 20 Oct 2004 16:12:53 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:a0fd:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i9KGCmi05230 verified NO) for ; Wed, 20 Oct 2004 18:12:51 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i9KGClg05229; Wed, 20 Oct 2004 18:12:47 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 20 Oct 2004 18:12:47 +0200 (CEST) Message-Id: <200410201612.i9KGClg05229@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Thu, 21 Oct 2004 12:20:41 +0000 Subject: USB OHCI problems... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:12:57 -0000 Apologies for this posting, as so far as I know it's a known issue that the USB OHCI code has some problems, or perhaps that there have been code commits in the last weeks so this is no longer a problem... Anyway, under FreeBSD-4 with kernel modules built 10.August from source that I believe is based on FreeBSD-5-current of that era, I'm seeing corruption of data read from umass devices attached to an OHCI controller card. Use of a UHCI controller card instead seems mostly free of problems. In comparison, I accessed the data with NetBSD-current of similar vintage, and in the files copied with the identical hardware, the data is intact. The point at which the corruption begins is at some multiple of 16384 bytes into the file. The corruption is not consistent, as it is less likely to occur when the machine is somewhat idle, and as the below shows, also occurs at different points into the same file. I haven't looked to see for how long this corruption is present (it's more than a few hundred bytes, at least) or how the file appears after this, or whether this corruption follows any particular pattern of the rest of the file. The below is `cmp' output under my FreeBSD, compared against the files previously downloaded with NetBSD (and verified that all the images are intact). /cdrom/dcim/100dscim/pict0681.jpg pict0681.jpg differ: char 524289, line 2284 /cdrom/dcim/100dscim/pict0683.jpg pict0683.jpg differ: char 507905, line 2116 /cdrom/dcim/100dscim/pict0684.jpg pict0684.jpg differ: char 1163265, line 3323 /cdrom/dcim/100dscim/pict0685.jpg pict0685.jpg differ: char 294913, line 1402 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 393217, line 1716 /cdrom/dcim/100dscim/pict0687.jpg pict0687.jpg differ: char 753665, line 2606 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 983041, line 3648 This is just a sample -- note that the last line is the same file that I had previously `cmp'ed two lines above. In fairness, the files copied from NetBSD were done with the machine mostly idle, so I don't know if NetBSD suffers the same if I were pounding the machine. If this issue hasn't been handled, perhaps the fact that NetBSD doesn't seem to have problems might give someone some ideas as to where the problem might lie. As usual, apologies for the untimeliness of this, as well as my lack of detailed testing with fresh -current or with code fresher than two months ago. thanks barry bouwsma