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

> On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter <jus...@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
point.

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.

Cheers,
Justus

Attachment: signature.asc
Description: PGP signature

Reply via email to