On 03/15/2017 16:11, Joshua Kinard wrote:
> I've reported in the past that turning on CONFIG_DEBUG_LOCK_ALLOC produces a
> kernel that can't boot on several SGI platforms. It turns out that using
> arcload (Stan's bootloader originally written for IP30), I can get some
> debugging out on why. I am still puzzled, but maybe this information can be
> interpreted by someone else into something meaningful?
> All addresses printed out of arcload are physical address.
> ARCS Memory Map as printed by some debugging I added to the arcload binary:
> 0x00000000 - 0x00001000 ExceptionBlock
> 0x00001000 - 0x00002000 SystemParameterBlock
> 0x00002000 - 0x00004000 FirmwarePermanent
> 0x20004000 - 0x20f00000 FreeMemory***
> 0x20f00000 - 0x21000000 FirmwareTemporary
> 0x21000000 - 0x5fff0000 FreeMemory
> 0x5fff0000 - 0x5ffff000 LoadedProgram
> 0x5ffff000 - 0x60000000 FreeMemory
> 0x60000000 - 0xa0000000 FirmwarePermanent
So it turns out I can get away, on Octane at least, by changing the load
address from 0x20004000 to an arbitrary value in the other FreeMemory segment
from 0x21000000 - 0x5fff0000. Specifically, using 0x21004000 appears to work
without any ill effects.
The 0x20004000 value is the address used by IRIX to load (with symon, it
becomes 0x200800000 instead). I'll have to try this on the IP27 later on as
well. On Octane, CONFIG_DEBUG_LOCK_ALLOC didn't toss up any major locking
issues yet. Probably need to hammer the disks with bonnie++ or such. At least
I can get back to the BRIDGE/PCI mess now...
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic