From owner-freebsd-stable@FreeBSD.ORG Mon Mar 1 13:44:04 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 801CC16A4CE for ; Mon, 1 Mar 2004 13:44:04 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C5E243D53 for ; Mon, 1 Mar 2004 13:44:04 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004030121440301400o4mqae>; Mon, 1 Mar 2004 21:44:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA62972; Mon, 1 Mar 2004 13:44:02 -0800 (PST) Date: Mon, 1 Mar 2004 13:44:01 -0800 (PST) From: Julian Elischer To: Dmitry Morozovsky In-Reply-To: <20040302001403.N39203@woozle.rinet.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: stable@freebsd.org Subject: Re: UDB MS Reader stalls/crashes system [HEADSUP!!! USB MFC committed..] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2004 21:44:04 -0000 Thanks.. I plan on looking at as many USB bugs I can find in the next month or so.. pleas ensure you have filed a PR for this.. julian On Tue, 2 Mar 2004, Dmitry Morozovsky wrote: > On Sun, 29 Feb 2004, Julian Elischer wrote: > > JE> The USB code in RELENG_4 has been updated to match that in -current. > JE> Please test any USB devices that are critical to you BEFORE we release > JE> 4.10 :-) > > This bug report is not related to your commit, as system behaviour is the same > before and after your MFC. Anyway, here it is (I suppose actual bug is > somewhare in VM-cache code, see below) > > With cheap MemoryStick Reader identified as > > Controller /dev/usb0: > addr 1: low speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 > port 1 addr 2: low speed, power 100 mA, config 1, USB MS Card Reader.(0x7722), vendor 0x0416(0x0416), rev 1.00 > > Mar 2 00:04:35 revamp /kernel: Creating DISK da0 > Mar 2 00:04:35 revamp /kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 > Mar 2 00:04:35 revamp /kernel: pass0: Removable Direct Access SCSI-0 device > Mar 2 00:04:35 revamp /kernel: pass0: Serial Number > Mar 2 00:04:35 revamp /kernel: pass0: 150KB/s transfers > Mar 2 00:04:35 revamp /kernel: Mounting root from ufs:/dev/ad0s1a > Mar 2 00:04:35 revamp /kernel: da0 at umass-sim0 bus 0 target 0 lun 0 > Mar 2 00:04:35 revamp /kernel: da0: Removable Direct Access SCSI-0 device > Mar 2 00:04:35 revamp /kernel: da0: Serial Number > Mar 2 00:04:35 revamp /kernel: da0: 150KB/s transfers > Mar 2 00:04:35 revamp /kernel: da0: 30MB (63424 512 byte sectors: 64H 32S/T 30C) > > after mounting msdos slice and any long read req operation like > `cp -r /dos /smth' or `rsync -av /dos /smth' after approx 1M of transferred > data reads stall, after a while kernel reports something (sorry, have no logs > handy) like 'SCB read error'. Process stalls in 'D' state. Removing, umount > -f'ing, reinsertinf and reaccessing device leads to crash with the following > (very strange to me) crashdump: > > > IdlePTD at physical address 0x0032c000 > initial pcb at physical address 0x002585a0 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x98 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc015738e > stack pointer = 0x10:0xccaa2e70 > frame pointer = 0x10:0xc5ecb330 > 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 = 8 (syncer) > interrupt mask = none > trap number = 12 > panic: page fault > > syncing disks... 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > giving up on 1 buffers > Uptime: 1d23h42m17s > > dumping to dev #ad/0x20001, offset 524288 > dump ata0: resetting devices .. ata0: mask=03 ostat0=50 ostat2=00 > ad0: ATAPI 00 00 > ata0-slave: ATAPI 00 00 > ata0: mask=03 stat0=50 stat1=00 > ad0: ATA 01 a5 > ata0: devices=01 > ad0: success setting PIO4 on generic chip > done > 256 255 ... > [snip] > 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 dumpsys () at /lh/src.stable/sys/kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) bt > #0 dumpsys () at /lh/src.stable/sys/kern/kern_shutdown.c:487 > #1 0xc0c0f114 in ?? () > Cannot access memory at address 0x1. > > What other into can I provide to further track this error? > > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ >