UDB MS Reader stalls/crashes system [HEADSUP!!! USB MFC
committed..]
Julian Elischer
julian at elischer.org
Mon Mar 1 13:44:04 PST 2004
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 <kern.crit> revamp /kernel: Creating DISK da0
> Mar 2 00:04:35 <kern.crit> revamp /kernel: pass0 at umass-sim0 bus 0 target 0 lun 0
> Mar 2 00:04:35 <kern.crit> revamp /kernel: pass0: <General USB Disk Drive 1.00> Removable Direct Access SCSI-0 device
> Mar 2 00:04:35 <kern.crit> revamp /kernel: pass0: Serial Number
> Mar 2 00:04:35 <kern.crit> revamp /kernel: pass0: 150KB/s transfers
> Mar 2 00:04:35 <kern.crit> revamp /kernel: Mounting root from ufs:/dev/ad0s1a
> Mar 2 00:04:35 <kern.crit> revamp /kernel: da0 at umass-sim0 bus 0 target 0 lun 0
> Mar 2 00:04:35 <kern.crit> revamp /kernel: da0: <General USB Disk Drive 1.00> Removable Direct Access SCSI-0 device
> Mar 2 00:04:35 <kern.crit> revamp /kernel: da0: Serial Number
> Mar 2 00:04:35 <kern.crit> revamp /kernel: da0: 150KB/s transfers
> Mar 2 00:04:35 <kern.crit> 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 at rinet.ru ***
> ------------------------------------------------------------------------
>
More information about the freebsd-stable
mailing list