From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 00:32:19 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 5A84016A4C1 for ; Sat, 13 Sep 2003 00:32:19 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACCB43FBF for ; Sat, 13 Sep 2003 00:32:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h8D7aGbi009417; Sat, 13 Sep 2003 03:36:17 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h8D7W3GP068038; Sat, 13 Sep 2003 00:32:03 -0700 (PDT) (envelope-from jmg) Date: Sat, 13 Sep 2003 00:32:03 -0700 From: John-Mark Gurney To: Barney Wolff Message-ID: <20030913073203.GU39788@funkthat.com> Mail-Followup-To: Barney Wolff , freebsd-current@freebsd.org References: <20030907064510.GA702@libertysurf.fr> <20030907073246.GD39788@funkthat.com> <20030907174649.GA4378@pit.databus.com> <20030907175524.GG39788@funkthat.com> <20030907194830.GA6420@pit.databus.com> <20030907203908.GI39788@funkthat.com> <20030912195256.GA69944@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030912195256.GA69944@pit.databus.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: usb flashkey disk copy error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2003 07:32:19 -0000 Barney Wolff wrote this message on Fri, Sep 12, 2003 at 15:52 -0400: > Patch below had some problems. Needed #ifdef USB_DEBUG around the > ref to ohcidebug to compile, and either BROKEN_OHCI added to the > list of valid options or (as I did) kludged to 1. Worse, trying > to mount_msdosfs my camera caused an instant panic: "Length went > negative: -4096". If that's not enough info, I imagine I can > recreate the panic. Yeh, I ran across this when testing on a system. But you can ignore this patch. With this patch applied the USB device would stop working even after I fixed the #ifdef and -4096 problems.. (btw, I never "intended" for the patch to compile w/o USB_DEBUG, but since the modules don't inherit the kernel config's make files, it breaks).. > Just to restate my particular problem, I get the wrong data on read > of an existing file from the memory stick on the camera. I have > not dared to try writing to it since reads don't work. Ok, I have a system that I'm going to be looking at tomorrow that has a similar issue. Could you file an add in to kern/54982 that includes the dmesg output of your usb messages (ohci/uhci/umass/etc.) I tried using my 128meg CF in the same reader/machine that was having problems reading, and it worked. So it looks like reads are broken for only some devices, not all. :( > On Sun, Sep 07, 2003 at 01:39:08PM -0700, John-Mark Gurney wrote: > > Barney Wolff wrote this message on Sun, Sep 07, 2003 at 15:48 -0400: > > > I can't do more detailed diagnosis right now, but could in a few days. > > > > When you get a chance (or anyone else who has this problem), try the > > attached patch, and add options BROKEN_OHCI to your kernel config file. > > Please set hw.usb.ohci.debug=1, and send me the dmesg output of the > > writes. (When you copy the data to the media.) > > > > Hmmm. I just thought of something. Now is the data corrupt still correupt > > on another system? What I mean is did the data get written properly, but > > just isn't being read back from the media correctly. Unless you are > > coping a file larger than memory size, the cmp just pulls it from memory, > > not from the media. The umount/mount forces a flush of the cache, and so > > attempts to read from the media. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."