From owner-freebsd-current@FreeBSD.ORG Sat Jul 3 19:23:51 2004 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 C7D9516A4CE; Sat, 3 Jul 2004 19:23:51 +0000 (GMT) Received: from gravy.kishka.net (pcp04097789pcs.neave01.pa.comcast.net [68.81.192.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4188F43D31; Sat, 3 Jul 2004 19:23:51 +0000 (GMT) (envelope-from bryan@kishka.net) Received: from gravy.kishka.net (gravy.kishka.net [192.168.1.2]) by gravy.kishka.net (8.12.11/8.12.11) with ESMTP id i63JNoba006106; Sat, 3 Jul 2004 15:23:50 -0400 (EDT) (envelope-from bryan@kishka.net) Date: Sat, 3 Jul 2004 15:23:50 -0400 (EDT) From: Bryan Liesner To: Lukas Ertl In-Reply-To: <20040703190659.N63131@leelou.in.tern> Message-ID: <20040703143045.M6031@gravy.kishka.net> References: <20040626115242.X570@gravy.kishka.net> <20040628190253.U658@korben.in.tern> <20040703190659.N63131@leelou.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Bryan Liesner cc: freebsd-current@freebsd.org cc: sos@freebsd.org Subject: Re: Panic: EHCI and umass 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, 03 Jul 2004 19:23:51 -0000 On Sat, 3 Jul 2004, Lukas Ertl wrote: > On Mon, 28 Jun 2004, Bryan Liesner wrote: > >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x53425355 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc051c117 >> stack pointer = 0x10:0xd4294ab0 >> frame pointer = 0x10:0xd4294ad0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 20 (irq10: pcm0 ehci0) >> kernel: type 12 trap, code=0 > > Since I've now gotten hold of a large USB2 disk, I tried to reproduce this > but successfully dumped 4GB of data, until I hit the msdosfs filesize limit. > Thank you for your efforts. I was getting around to sending this info back to the list, but I was up late last night and am only starting to wake up. It seems to actually be an ATA problem of sorts. Here's what I found: I have (had) in my box a Maxtor UltraDMA 133 controller, which is actually a relabeled Promise PDC20269 UDMA133 controller. Attached to that is a Maxtor 6L060J3 60GB disk. I was playing around and found that if I used atacontrol to drop it down to WDMA2, the dump completed without a problem, but slowly. Doing simple speed tests on my Maxtor HD, like dd if=/dev/zero of=blahblah, I found that when set up as UDMA133, the throughput was only about 20MB/s. I dropped it down to UDMA100, and the throughput increased. At UDMA66, the throughput was even better and came out to be about 40MB/s !!!!! I removed the Maxtor/Promise card and attached my hard drive to the VIA 8233 UDMA100 controller on my motherboard, and retried my simple throughput test, which levels off at about 40MB/s. The bottom line is, EHCI is and was just fine and dumps are now working fine. ATA was screwed up for me until I changed the controller. But the question remains - Is the Promise card I have damaged, braindead, not well supported, in conflict with what's on the motherboard, or is there another issue going on here that is difficult to find or detect? During the course of this trouble, and for that matter, before the trouble started, I saw no complaints from the ATA driver about anything going wrong. I had poor ATA performance going on here for quite a while. The EHCI commit seems to have brought out the worst of it. Thanks again, and I hope you didn't pull too much of your hair out :) I have to search through the archives, but another guy had a similar issue after the EHCI update. I wonder what his ATA configuration was. And what is yours, if you're using ATA?