Bug #533

A new panic on HEAD

Added by elekktretterr over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hey everyone,

I accidentally tried to mount a fat32 partition over a directory where
ntfs was mounted, and Ive got a panic. I tried making a core dump but
/var/crash is empty. Ive set dumpon /dev/ad4s1b (swap) and change the
sysctl and it said it was dumping but as I said /var/crash is empty.

Could you try to reproduce it on your box? What am i doing wrong the dumps?

Thank you,

Petr

History

#1 Updated by corecode over 7 years ago

i guess this is related to <http://bugs.dragonflybsd.org/issue512&gt;. possibly all mounts over a mountpoint panic the box.

cheers
simon

#2 Updated by elekktretterr over 7 years ago

Indeed it is probably the same (i remember lockmgr in the trace and
couple of other points)

Thanks,
Petr

#3 Updated by dillon over 7 years ago

:Petr Janda wrote:
:> I accidentally tried to mount a fat32 partition over a directory where =
:
:> ntfs was mounted, and Ive got a panic. I tried making a core dump but=20
:> /var/crash is empty. Ive set dumpon /dev/ad4s1b (swap) and change the=20
:> sysctl and it said it was dumping but as I said /var/crash is empty.
:
:i guess this is related to <http://bugs.dragonflybsd.org/issue512&gt;. poss=
:ibly all mounts over a mountpoint panic the box.
:
:cheers
: simon

I'll try to track this down after I get back this afternoon, before
I branch the tree. But if someone else tracks it down first, please
commit!

-Matt

#4 Updated by dillon over 7 years ago

:Hey everyone,
:
:I accidentally tried to mount a fat32 partition over a directory where
:ntfs was mounted, and Ive got a panic. I tried making a core dump but
:/var/crash is empty. Ive set dumpon /dev/ad4s1b (swap) and change the
:sysctl and it said it was dumping but as I said /var/crash is empty.
:
:Could you try to reproduce it on your box? What am i doing wrong the dumps?
:
:Thank you,
:
:Petr

Try it with rev 1.112 of kern/vfs_syscalls.c, just now committed, and
tell us if that fixed it.

-Matt
Matthew Dillon
<>

#5 Updated by elekktretterr over 7 years ago

Im confirming that the bug is fixed.

Great work Matt,

Thanks!

Petr

Also available in: Atom PDF