NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/44504: kernel panics when dding some block sizes to USB flash drives at sd0



>Number:         44504
>Category:       kern
>Synopsis:       kernel panics when dding some block sizes to USB flash drives 
>at sd0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 02 22:00:01 +0000 2011
>Originator:     Taylor R Campbell <campbell+netbsd%mumble.net@localhost>
>Release:        NetBSD 5.1_STABLE
>Organization:
>Environment:
System: NetBSD smalltalk.local 5.1_STABLE NetBSD 5.1_STABLE (RIADEBUG) #0: Tue 
Feb 1 20:28:45 UTC 2011 
root%smalltalk.local@localhost:/home/riastradh/netbsd/5/obj/sys/arch/i386/compile/RIADEBUG
 i386
Architecture: i386
Machine: i386
>Description:

        In multi-user mode on a kernel with DIAGNOSTIC and a few other
        options enabled, I can reliably make the kernel panic by dding
        what appear to be blocks of certain sizes to sd0d, where sd0 is
        some USB flash drive.  I haven't been able to reproduce it in
        single-user mode, and I haven't been able to reproduce it in
        HEAD.

        dmesg output for one of the flash drives I tested:

umass0 at uhub3 port 3 configuration 1 interface 0
umass0: Corsair Flash Voyager, rev 2.00/11.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Corsair, Flash Voyager, 1100> disk removable
sd0: 1936 MB, 3936 cyl, 16 head, 63 sec, 512 bytes/sect x 3964928 sectors

        Kernel configuration:

include "arch/i386/conf/GENERIC"
options         DIAGNOSTIC      # expensive kernel consistency checks
options         DEBUG           # expensive debugging checks/support
options         LOCKDEBUG       # debug locks
makeoptions     DEBUG="-g"      # compile full symbol table
options         FFS_EI          # FFS Endian Independent support
options         APPLE_UFS       # Apple UFS support in FFS

        Panic message:

panic: kernel diagnostic assertion "LIST_EMPTY(&vp->v_dirtyblkhd)" failed: file 
"/home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c", line 895
Begin traceback...
uvm_fault(0xcaa5d27c, 0, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c05ce021 cs 8 eflags 10246 cr2 37f ilevel 0
panic: trap
Faulted in mid-traceback; aborting...
dumping to dev 0,1 offset 1049975
dump succeeded

        Stack trace from gdb:

% gdb ./netbsd.gdb
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
(gdb) target kvm /var/crash/netbsd.5.core
#0  0xc05d2f52 in cpu_reboot (howto=260, bootstr=0x0)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/machdep.c:924
924                     dumpsys();
(gdb) bt
#0  0xc05d2f52 in cpu_reboot (howto=260, bootstr=0x0)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/machdep.c:924
#1  0xc0502c90 in panic (fmt=0xc0ae24c3 "trap")
    at /home/riastradh/netbsd/5/src/sys/kern/subr_prf.c:253
#2  0xc05d5f07 in trap (frame=0xcc0ee9b4)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/trap.c:368
#3  0xc010ccd7 in calltrap ()
#4  0xc05ce021 in db_read_bytes (addr=895, size=4, 
    data=0xcc0eea24 "\024�\016�\004")
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/db_memrw.c:91
#5  0xc01b9147 in db_get_value (addr=895, size=4, is_signed=false)
    at /home/riastradh/netbsd/5/src/sys/ddb/db_access.c:62
#6  0xc05ce8a4 in db_stack_trace_print (addr=-871437548, have_addr=true, 
    count=65535, modif=0xc0b1a1fc "", pr=0xc0502a70 <printf>)
    at /home/riastradh/netbsd/5/src/sys/arch/i386/i386/db_trace.c:485
#7  0xc0502c65 in panic (
    fmt=0xc0b27c74 "kernel %sassertion \"%s\" failed: file \"%s\", line %d")
    at /home/riastradh/netbsd/5/src/sys/kern/subr_prf.c:242
#8  0xc086dd89 in __kernassert (t=0xc0a85161 "diagnostic ", 
    f=0xc0ad6cfc "/home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c", l=895, 
    e=0xc0ad650d "LIST_EMPTY(&vp->v_dirtyblkhd)")
    at /home/riastradh/netbsd/5/src/sys/lib/libkern/__assert.c:50
#9  0xc0545571 in vinvalbuf (vp=0xcbe6f230, flags=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    cred=0xcc304480, l=0xcc19e780, catch=false, slptimeo=0)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_subr.c:895
#10 0xc055edcd in spec_close (v=0xcc0eebd8)
    at /home/riastradh/netbsd/5/src/sys/miscfs/specfs/spec_vnops.c:935
#11 0xc05578dc in VOP_CLOSE (vp=0xcbe6f230, fflag=3, cred=0xcc304480)
    at /home/riastradh/netbsd/5/src/sys/kern/vnode_if.c:314
#12 0xc054f87e in vn_close (vp=0xcbe6f230, flags=3, cred=0xcc304480)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_vnops.c:352
#13 0xc054f8c2 in vn_closefile (fp=0xcc305c00)
    at /home/riastradh/netbsd/5/src/sys/kern/vfs_vnops.c:782
#14 0xc04bbd3d in closef (fp=0xcc305c00)
    at /home/riastradh/netbsd/5/src/sys/kern/kern_descrip.c:755
#15 0xc04bbf01 in fd_close (fd=4)
    at /home/riastradh/netbsd/5/src/sys/kern/kern_descrip.c:646
#16 0xc05d57c8 in syscall (frame=0xcc0eed48)
    at /home/riastradh/netbsd/5/src/sys/sys/syscallvar.h:49
#17 0xc010058e in syscall1 ()

>How-To-Repeat:

        Plug in a USB flash drive; assume it attaches at sd0.  The
        following all trigger the panic for me:

                # dd if=/dev/zero of=/dev/sd0d bs=123 count=1
                # dd if=/dev/zero of=/dev/sd0d bs=511 count=1
                # dd if=/dev/zero of=/dev/sd0d bs=512 count=1
                # dd if=/dev/zero of=/dev/sd0d bs=1k count=1
                # dd if=/dev/zero of=/dev/sd0d bs=2k count=1

        If F is a file whose size is not an even multiple of 4k, then

                # dd if=F of=/dev/sd0d

        also triggers the panic.

        A block size of 4k does not seem to trigger it; nor does using
        rsd0d.  Specifying a block size that is not a multiple of 512
        with rsd0d fails with EINVAL, but a block size of 512 works,
        even though 512 on sd0d triggers the panic.

>Fix:

        Yes, please!



Home | Main Index | Thread Index | Old Index