UDB MS Reader stalls/crashes system [HEADSUP!!! USB MFC committed..]

[Dmitry Morozovsky]

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 ***
------------------------------------------------------------------------