Bug #1016
closedmount_cd9660 crashes the kernel
0%
Description
DragonFly 1.13-DEVELOPMENT #1: Mon May 19 23:26:51 CEST 2008 crashes on a simple
mount_cd9660 /dev/cd0 /mnt/cdrom.
The last commit in this kernel is:
http://repo.or.cz/w/dragonfly.git?a=commit;h=a13a97e518b44d453d9329dbb0909b27c730803d
Here is the error message:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02d3e15
stack pointer = 0x10:0xca3ed6c8
frame pointer = 0x10:0xca3ed744
code segment = base 0x0, limet 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = intercept enabled, resume, IOPL = 0
current process = 7660 (mount_cd9660)
current thread = pri 10
kernel: type 12 trap, code 0
Stopped at dsioctl+0x39: movl 0x8(%esi),%ebx
db> trace
dsioctl(snip) at dsioctl+0x39
cdcheckmedia(snip) at cdcheckmedia+0x246
cdopen(snip) at cdopen+0xd0
dev_dopen(snip) at dev_dopen+0x2f
diskopen(snip) at diskopen+0x7d
dev_dopen(snip) at dev_dopen+0x2f
spec_open(snip) at spec_open+0x18b
spec_vnoperate(snip) at spec_vnoperate+0x11
ufs_vnoperatespec(snip) at ufs_vnoperatespec+0x11
vop_open(snip) at vop_open+0x32
vn_open(snip) at vn_open+0x326
kern_open(snip) at kern_open+0x84
sys_open(snip) at sys_open+0x32
syscall2(snip) at syscall2+0x1ec
Xint0x80_syscall() at Xint0x80_syscall+0x36
I was only able to write it down to a piece of paper, hopefully i did not make
any typo. Also i was lazy to add the memory addresses too for the functions, let
me know if you miss them or anything else.
One more thing: using /dev/acd0 works fine.
Updated by dillon over 16 years ago
:New submission from VOROSKOI Andras <voroskoi@gmail.com>:
:
:DragonFly 1.13-DEVELOPMENT #1: Mon May 19 23:26:51 CEST 2008 crashes on a s=
:imple
:mount_cd9660 /dev/cd0 /mnt/cdrom.
:
:The last commit in this kernel is:
:http://repo.or.cz/w/dragonfly.git?a=3Dcommit;h=3Da13a97e518b44d453d9329dbb0=
:909b27c730803d
:
:Here is the error message:
:
:Fatal trap 12: page fault while in kernel mode
:fault virtual address =3D 0x8
:fault code =3D supervisor read, page not present
:instruction pointer =3D 0x8:0xc02d3e15
:stack pointer =3D 0x10:0xca3ed6c8
:frame pointer =3D 0x10:0xca3ed744
:code segment =3D base 0x0, limet 0xfffff, type 0x1b
: =3D DPL 0, pres 1, def32 1, gran 1
:processor eflags =3D intercept enabled, resume, IOPL =3D 0
:current process =3D 7660 (mount_cd9660)
:current thread =3D pri 10
:
:kernel: type 12 trap, code 0
:Stopped at dsioctl+0x39: movl 0x8(%esi),%ebx
:db> trace
:dsioctl(snip) at dsioctl+0x39
:cdcheckmedia(snip) at cdcheckmedia+0x246
:cdopen(snip) at cdopen+0xd0
:dev_dopen(snip) at dev_dopen+0x2f
:diskopen(snip) at diskopen+0x7d
:...
:sys_open(snip) at sys_open+0x32
:syscall2(snip) at syscall2+0x1ec
:Xint0x80_syscall() at Xint0x80_syscall+0x36
:
:I was only able to write it down to a piece of paper, hopefully i did not m=
:ake
:any typo. Also i was lazy to add the memory addresses too for the functions=
:, let
:me know if you miss them or anything else.
:
:One more thing: using /dev/acd0 works fine.
That's excellent information. I haven't been able to reproduce the
problem, though, I seem to be able to mount from /dev/cd0 ok. I have
some suspicions, though, considering where it is panicing.
What kind of CD did you have in the drive? A DragonFly CD or something
else? Did you perform any other actions prior to doing the
mount_cd9660? Such as mounting it (or trying to mount it) via some
other path?
Can you reproduce the problem and perhaps get a kernel core dump?
-Matt
Updated by voroskoi over 16 years ago
No, i can crash it right after logging in.
It's a simple data cd with some mp3, but i can reproduce it with my
dfly-1.12.2 cd too. (Both cd is rewritable.)
Yes, it's always reproductable. You can find the core dump here:
http://frugalware.org/~voroskoi/dfly/dfly-mount_cd9660-coredump.tar.bz2
Updated by wa1ter over 16 years ago
...
Hi Andras. I can't help you with your crash but the 'repo.org.cz' caught my attention.
Simon, are you updating that git repository regularly now? If so I'll start using it
myself.
Updated by dillon over 16 years ago
The crash dump is really helpful. I have reproduced it. What is
happening is that cdcheckmedia() is being called before the slice
table is getting set up. I think adding some simple conditionals to
those dsioctl()'s will solve the problem.
I should have a fix for the mount_cd9660 issue committed today.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by dillon over 16 years ago
More precisely, the commit on the 18th updating the CAM code is setting
CD_FLAG_OPEN early, causing dsioctl() to improperly be called before the
slice table has been installed.
-Matt
Matthew Dillon
<dillon@backplane.com>