Project

General

Profile

Actions

Bug #353

closed

Kernel panic on reboot with latest (16-Oct-2006) Devel iso

Added by arachnist about 18 years ago. Updated almost 18 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

After installation of dragonfly in vmware i got the following kernel
panic on reboot
http://img175.imageshack.us/img175/143/whoopslp8.jpg
Additionally, when i entered 'call dumpsys' it returned '0xc1d3dc00'
I chose default options in the installer except for swap size (changed
from 2GB to 512MB) and keymap (changed to us.dvorak).
vmware-server version: 1.0.1.29996-r4
--
jid:
gg: 7988510
irc: ar/arachnist @ ircnet/efnet/freenode

Actions #1

Updated by dillon about 18 years ago

:After installation of dragonfly in vmware i got the following kernel
:panic on reboot
:http://img175.imageshack.us/img175/143/whoopslp8.jpg
:Additionally, when i entered 'call dumpsys' it returned '0xc1d3dc00'
:I chose default options in the installer except for swap size (changed
:from 2GB to 512MB) and keymap (changed to us.dvorak).
:vmware-server version: 1.0.1.29996-r4
:--
:jid:
:gg: 7988510
:irc: ar/arachnist @ ircnet/efnet/freenode

I think it's trying to write out a core file for a seg-faulted user
process after it has dismounted /, which is too late in the reboot
sequence. The question is: is that the init process, the process
that called 'reboot', or something else? A 'ps' from the DDB prompt
might give us a hint.
Call dumpsys never works right.  If dumps are enabled, just typing
'panic' from the DDB prompt and hitting return twice should be enough.
-Matt
Matthew Dillon
<>
Actions #2

Updated by arachnist about 18 years ago

The bug seems to be repeatable and i've simply selected the reboot
option from the installer. Here's the "ps" output:
http://img109.imageshack.us/img109/8341/whoops2ow5.jpg
http://img112.imageshack.us/img112/2792/whoops3go7.jpg
http://img112.imageshack.us/img112/8143/whoops4jf6.jpg
--
jid:
gg: 7988510
irc: ar/arachnist @ ircnet/efnet/freenode

Actions #3

Updated by dillon about 18 years ago

:Robert Sebastian Gerus <> added the comment:
:
:The bug seems to be repeatable and i've simply selected the reboot
:option from the installer. Here's the "ps" output:
:http://img109.imageshack.us/img109/8341/whoops2ow5.jpg
:http://img112.imageshack.us/img112/2792/whoops3go7.jpg
:http://img112.imageshack.us/img112/8143/whoops4jf6.jpg
:--
:jid:
:gg: 7988510
:irc: ar/arachnist @ ircnet/efnet/freenode

Ooooh... I'll bet it's the MFS mount.  If you unmount the MFS mounts
before rebooting, then reboot, does that fix the problem?
-Matt
Matthew Dillon
&lt;&gt;
Actions #4

Updated by arachnist about 18 years ago

I unmounted everything except for /dev (device busy) after exiting the
installer, and the bug showed-up again. Is there any way to make csh,
getty and stuff stop using /dev?
--
jid:
gg: 7988510
irc: ar/arachnist @ ircnet/efnet/freenode

Actions #5

Updated by dillon about 18 years ago

:Robert Sebastian Gerus <> added the comment:
:
:I unmounted everything except for /dev (device busy) after exiting the
:installer, and the bug showed-up again. Is there any way to make csh,
:getty and stuff stop using /dev?
:--
:jid:
:gg: 7988510
:irc: ar/arachnist @ ircnet/efnet/freenode

I will try to reproduce it.  The crash only occurs when you are rebooting
from the installer, right ?
Recent code commits have tightened up the handling of filesystem mount
points. This particular panic is exposing a bug that has probably
existed for a long time.
-Matt
Actions #6

Updated by arachnist about 18 years ago

Happens always after installation. It doesn't matter if i reboot
directly from the installer, or from csh as root

Actions #7

Updated by arachnist about 18 years ago

It doesn't seem to happen anymore, at least outside of vmware.
--
jid:
gg: 7988510
irc: ar/arachnist @ ircnet/efnet/freenode

Actions

Also available in: Atom PDF