devfs related panic

Alex Hornung ahornung at gmail.com
Thu Jul 7 22:23:48 PDT 2011


Hi,

I've recently made some rather potentially unstable changes to devfs
(the change of subname to -> related removal functions). Could you
please enable devfs debug to 7 and get the output when the disk is
unplugged?

I'll have a look into the crash on the weekend, thanks for the report.

Cheers,
Alex


On 08/07/11 06:00, Sepherosa Ziehau wrote:
> Hi all,
> 
> #12 0xffffffff802e8a1f in dssetmask (dev=0xffffffe085418f50,
> mode=<value optimized out>, flags=<value optimized out>,
>     sspp=<value optimized out>, info=<value optimized out>) at
> /usr/src/sys/sys/diskslice.h:349
> #13 dsopen (dev=0xffffffe085418f50, mode=<value optimized out>,
> flags=<value optimized out>, sspp=<value optimized out>,
>     info=<value optimized out>) at /usr/src/sys/kern/subr_diskslice.c:741
> #14 0xffffffff802e45ff in diskopen (ap=0xffffffe0ba9c3798) at
> /usr/src/sys/kern/subr_disk.c:956
> #15 0xffffffff802a3e1c in dev_dopen (dev=0xffffffe085418f50,
> oflags=8192, devtype=195, cred=0x1f) at
> /usr/src/sys/kern/kern_device.c:151
> #16 0xffffffff803e9c02 in devfs_spec_open (ap=0xffffffe0ba9c3838) at
> /usr/src/sys/vfs/devfs/devfs_vnops.c:919
> #17 0xffffffff8033c61c in vop_open (ops=0xffffffe0ad0d2e00,
> vp=0xffffffe0bb1d6c48, mode=1, cred=0xffffffe0ae317868,
> fp=0xffffffe08518ad58)
>     at /usr/src/sys/kern/vfs_vopops.c:289
> #18 0xffffffff80339ec6 in vn_open (nd=0xffffffe0ba9c3a98, fp=<value
> optimized out>, fmode=1, cmode=<value optimized out>)
>     at /usr/src/sys/kern/vfs_vnops.c:284
> #19 0xffffffff80336c5d in kern_open (nd=0xffffffe0ba9c3a98,
> oflags=<value optimized out>, mode=<value optimized out>,
>     res=<value optimized out>) at /usr/src/sys/kern/vfs_syscalls.c:1836
> #20 0xffffffff80336eb6 in sys_open (uap=0xffffffe0ba9c3b58) at
> /usr/src/sys/kern/vfs_syscalls.c:1946
> #21 0xffffffff8048f652 in syscall2 (frame=0xffffffe0ba9c3c08) at
> /usr/src/sys/platform/pc64/x86_64/trap.c:1188
> #22 0xffffffff80487c1f in Xfast_syscall () at
> /usr/src/sys/platform/pc64/x86_64/exception.S:320
> 
> core dump is uploaded to sephe at leaf:crash/vmcore0.tbz
> 
> It happened after following stuffs were done by my friend:
> - a sata disk was plugged into the esata port, and the disk was detected as da1
> - dd if=/dev/zero of=/dev/da1, something like that
> - unplug the sata disk
> - after a short while, another sata disk was plugged in the same esata port
> - this time no message showed about anything related to /dev/da1
> - run the above dd command again, panic
> 
> Best Regards,
> sephe
> 






More information about the Bugs mailing list