[powerstation-owners] building SLOF with gcc 4.3

Benjamin Herrenschmidt benh at kernel.crashing.org
Sun Dec 7 15:45:00 MST 2008


On Sun, 2008-12-07 at 22:48 +0100, Adrian Reber wrote:
> +               /* For some reason we need this eieio here. With newer compilers
> +                * the bios emulator hangs if we do not wait a certain time at
> +                * this point. It does not need to be an eieio but it seems it
> +                * wastes enough time to keep us going. This is completely not
> +                * understood. */
> +               eieio();
>                 DEBUG_PRINTF_IO("%s(%04x) Device I/O --> %08x\n", __FUNCTION__,
>                                 addr, rval);
>                 return rval;
> 
> If anybody knows a better way to fix the hang in the bios emulator
> I would be happy to fix it the right way and not just wait for
> some unknown reason.

Interesting. I have not noticed this problem when running the emulator
outside of SLOF (I hacked up a userspace variant for my own needs).

However, there are a few things to consider. First newer gcc's are much
more aggressive at re-ordering things, it might be that you lack some
kind of compiler barrier here. Also, I don't know if your read_io
contains an eieio already but you need to ensure there is no write
combining and unless you are mapped non-cacheable -and- guarded, you
need the eieio (and you need it even with I+G in some circumstances).

So it could just be that you lack a necessary barrier here.

However, I noticed something else with the emulator. On the X1650, if I
let the BIOS access the legacy VGA registers, it blows up with a machine
check. I've tracked that down to a bug in the ATI BIOS itself that tries
to access some legacy MDA register (3b5 etc...) that aren't implemented
by the card :-) Nice heh ! On x86, such master aborts are just silently
ignored. I added a hack to the emulator to catch the sigbus and recover.

Cheers,
Ben.




More information about the powerstation-owners mailing list