kern/63621: USB MemoryStick Reader stalls/crashes system

[Dmitry Morozovsky]

>Number:         63621
>Category:       kern
>Synopsis:       USB MemoryStick Reader stalls/crashes system
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 01 14:50:14 PST 2004
>Closed-Date:
>Last-Modified:
>Originator:     Dmitry Morozovsky
>Release:        FreeBSD 4-STABLE i386
>Organization:
Cronyx Plus LLC (RiNet ISP)
>Environment:
System: FreeBSD 4-STABLE, before and after julians@'s MFC of -current USB code at 2004-02-29;
same behaviour with 4.9-R

PII BX system; kernel is GENERIC trimmed a bit; behaviour with GENERIC is the same)

>Description:

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.

Bug is 100% reproducible with how-to-repeat procedure; however, it is
_sometimes_ possible to have successful `dd if=/dev/da0 of=/dev/null bs=64k' at
full USB 1.1 speed (about 1 MB/sec)

>How-To-Repeat:

attach the device mentioned (creates da0)
mount -t msdos /dev/da0 /mnt
cp -r /mnt /var/tmp/mnt (or rsync -a /mnt /var/tmp/mnt, or similar)
[watch for SCB read error in cosole logs]
detach device
umount -f /dos
reattach device
mount /dos
[access /dos]

>Fix:

None known unfortunately.
>Release-Note:
>Audit-Trail:
>Unformatted: