FreeBSD 6.1 Tor issues (Once More, with Feeling)

[Robert Watson]

On Thu, 29 Jun 2006, Fabian Keil wrote:

> I wish I could. The machine died before I read your message.
>
> I was logged in on the serial console running tail -f /var/log/messages. 
> Last messages were:
>
> Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4275000(2048) val=a020c0de @ 0xc4275000
> Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4055800(2048) val=a020c0de @ 0xc4055800
> Jun 29 00:42:20 tor kernel: Memory modified after free 0xc4ca0000(2048) val=a020c0de @ 0xc4ca0000
> Jun 29 00:42:20 tor kernel: Memory modified after free 0xc39ef000(2048) val=a020c0de @ 0xc39ef000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc4bd7000(2048) val=a020c0de @ 0xc4bd7000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3c8a000(2048) val=a020c0de @ 0xc3c8a000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc33bd000(2048) val=a020c0de @ 0xc33bd000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3f1d000(2048) val=a020c0de @ 0xc3f1d000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc45dc800(2048) val=a020c0de @ 0xc45dc800
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc429e000(2048) val=a020c0de @ 0xc429e000
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3aef800(2048) val=a020c0de @ 0xc3aef800
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc432a000(2048) val=a020c0de @ 0xc432a000
> Jun 29 00:42:24 tor kernel: ad0: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=34263674
> Jun 29 00:42:24 tor kernel: Memory modified after free 0xc3dff800(2048) val=a020c0d
>
> Ctrl+Alt+ESC didn't trigger any reaction, so I caused a reset through the 
> ISP's webinterface. Now the system appears to be hosed, at least FreeBSD 
> never reaches the login:
>
> PXELINUX 3.11 2005-09-02  Copyright (C) 1994-2005 H. Peter Anvin
> Booting from local disk...
>
> 1   Linux
> 2   FreeBSD
> 3   FreeBSD
>
> Default: 2
>
> [nothing]
>
> Probably something which would be easy to resolve with keyboard access and a 
> screen, but I think I'm forced to use the "RecoveryManager". Unfortunately 
> "recovery" means reinstalling the preconfigured GNU/Linux which I than can 
> replace with FreeBSD again. If there ever was a core dump it will be gone, 
> and so will be kernel.debug.
>
> On the bright side you can chose the OS to go with. Should I use Current to 
> see if the problem still exists?

The ATA error above is a bit distressing, as is the fact that it won't boot. 
Is "[nothing]" normally the FreeBSD boot loader rather than nothing?  I would 
suggest running some hardware diagnostics to make sure we're dealing with 
reliable hardware before continuing so that we're not chasing both hardware 
and software problems, since you can't reliably debug software problems in the 
presence of hardware failures.

Robert N M Watson
Computer Laboratory
University of Cambridge