Re: mdconfig/umount Fatal trap 12

2001-06-18 Thread Poul-Henning Kamp

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
>   

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



Re: mdconfig/umount Fatal trap 12

2001-06-18 Thread Sheldon Hearn



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


:-)

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

2001-06-17 Thread Dima Dorfman

Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Dima Dorfman writes:
> >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.

Right.  I agree with your assessment in the thread I mentioned above.
My apologies if I made it sound derogatory.

> 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.

Regards,

Dima Dorfman
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mdconfig/umount Fatal trap 12

2001-06-17 Thread Poul-Henning Kamp

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



Re: mdconfig/umount Fatal trap 12

2001-06-17 Thread Dima Dorfman

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



mdconfig/umount Fatal trap 12

2001-06-17 Thread Jens Schweikhardt

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