Re: mdconfig/umount Fatal trap 12
On Sun, 17 Jun 2001 11:46:57 MST, Dima Dorfman wrote: If people think this is too much of a panic(8) implementation we can hide this behaviour behind a -JUSTDOIT! option. This is easy to do; just add an -f option to mdconfig (which can be converted into an MD_FORCE flag or something) which means bypass as many sanity checks as possible. I'll do the work if it's desired. Yuk. Can't we just keep consistency, so that this happens: $ umount /dev/md0 umount: unmount of /dev/md0 failed: Device busy $ umount -f /dev/md0 panic :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig/umount Fatal trap 12
In message [EMAIL PROTECTED], Sheldon Hearn writes: On Sun, 17 Jun 2001 11:46:57 MST, Dima Dorfman wrote: If people think this is too much of a panic(8) implementation we can hide this behaviour behind a -JUSTDOIT! option. This is easy to do; just add an -f option to mdconfig (which can be converted into an MD_FORCE flag or something) which means bypass as many sanity checks as possible. I'll do the work if it's desired. Yuk. Can't we just keep consistency, so that this happens: $ umount /dev/md0 umount: unmount of /dev/md0 failed: Device busy $ umount -f /dev/md0 panic Please check your details before replying. It is not mount which should yell, it is mdconfig -d. Besides -f is already a -file option to mdconfig, so a better option letter needs to be found. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mdconfig/umount Fatal trap 12
hello, world\n with a system cvsupped June 6th I can reliably reproduce a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x22 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b67e2 stack pointer = 0x10:0xc8f7aea0 frame pointer = 0x10:0xc8f7aea8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 832 (umount) panic: from debugger panic: from debugger Uptime: 10m3s dumping to dev da2s1b, offset 352280 when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig/umount Fatal trap 12
Jens Schweikhardt [EMAIL PROTECTED] writes: hello, world\n with a system cvsupped June 6th I can reliably reproduce a [panic] when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Been there, done that. Got the patches and long thread(s) to prove it ;-). See message ID [EMAIL PROTECTED] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig/umount Fatal trap 12
In message [EMAIL PROTECTED], Dima Dorfman write s: Jens Schweikhardt [EMAIL PROTECTED] writes: hello, world\n with a system cvsupped June 6th I can reliably reproduce a [panic] when I try to unmount a deleted mdconfig device. Here's the recipe: # file iso is a Freebsd 4.3 Wind River CD image made with # dd if=/dev/cd0c of=file.iso bs=2048 mdconfig -a -t vnode -f file.iso mount -t cd9660 /dev/md0 /mnt/freebsd-cd mdconfig -d -u md0 umount /dev/md0 I'm not sure if this is the right fix but what about having the mdconfig -d fail with EBUSY in case someone tries to delete a mounted md device? Been there, done that. Got the patches and long thread(s) to prove it ;-). See message ID [EMAIL PROTECTED] The idea here is that md(4) should be able to simulate a media which disappears with no warning so that people can debug problems related to (too) dynamic media transitions. If people think this is too much of a panic(8) implementation we can hide this behaviour behind a -JUSTDOIT! option. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
