From owner-freebsd-stable@FreeBSD.ORG Mon Mar 1 13:26:50 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 E318716A4F1 for ; Mon, 1 Mar 2004 13:26:49 -0800 (PST) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40C4143D1F for ; Mon, 1 Mar 2004 13:26:49 -0800 (PST) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.10/8.12.10) with ESMTP id i21LQhcj039379; Tue, 2 Mar 2004 00:26:43 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 2 Mar 2004 00:26:43 +0300 (MSK) From: Dmitry Morozovsky To: Julian Elischer In-Reply-To: Message-ID: <20040302001403.N39203@woozle.rinet.ru> References: X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: stable@freebsd.org Subject: 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:26:50 -0000 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 *** ------------------------------------------------------------------------