"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
signature.asc
Description: PGP signature