[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd shutdown problems

From: Justus Winter
Subject: Re: Hurd shutdown problems
Date: Mon, 08 Aug 2016 10:13:50 +0200
User-agent: Notmuch/0.22+51~gcc1a6d2 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)

"Brent W. Baccala" <cosine@freesoft.org> writes:

> On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter <justus@gnupg.org> wrote:
>> To prevent filesystem damage, try the following.  Break into the kernel
>> debugger, and kill the auth server using:
>> !task_terminate($task5)
>> Then continue using "c", and /hurd/startup should cleanly shutdown the
>> system.
> The problem seems to be caused by a failure to swapoff the swap space.
> Since I've started paying attention to the swap space usage, I've always
> been able to cleanly shutdown if no swap is in use.  Once, when a small
> amount of swap was in use (7 MB), I was able to shutdown cleanly.  After a
> decent sized compile, however, with 100 MB or so of swap in use, I always
> get this:
> Deactivating swap...swapoff: /dev/hd0s5: 177152k swap space
> swapoff: /dev/hd0s5: (os/kern) failure
> failed.
> Unmounting weak filesystems...umount: /etc/mtab: Warning: duplicate entry
> for device /dev/hd0s1 (/dev/cons)
> done.
> mount: cannot remount /: Device or resource busy
> Will now halt.
> Now everything stops.

Interesting.  There is a utility in the Hurd tree called 'vmallocate'
that can be used to allocate and dirty large amounts of memory to
trigger such issues.  Unfortunately it isn't shipped with Debian iirc.

> What happens if I now try Justus's advice?
> Stopped    at  0x810000be:    leave
> Kernel Page fault trap, eip 0x81029b4e
> Caught Page fault (14),    code = 0, pc = 81029b4e

Well, your system seems to be in a bad shape when entering the debugger,
a kernel fault occurred.  You cannot reasonably expect anything at this

But yes, it fails from time to time, usually when it fails I see the
kernel rebooting as soon as I call the task_terminate function.  I guess
it is because one can break into the debugger when the system is at an
inconsistent state by chance.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]