Sent from my mobile phone
On 03.11.2010, at 09:56, Ward Vandewege <w...@gnu.org> wrote:
> On Tue, Nov 02, 2010 at 11:20:43PM +0100, Uwe Hermann wrote:
>> I don't object to the patch, and we should probably fix this in all
>> other southbridges, I think the same problem applies there.
>>
>> But: the die() call itself also does a printk(), so that'll still hang
>> if the error path is chosen (at that point it probably doesn't matter
>> much, though, as we die anyway).
>
> Right, I think it does not matter. If the die happens when printk is already
> functional, great, if not it will hang there which is fine.
>
>> I also agree that die() should have a POST code, preferrably something
>> easy to remember. It already has a commented-out "//post_code(0xff);".
>> Not sure why it's disabled, but I think it should be something other
>> than 0xff, that's a bit too "special" for my taste.
>>
>> We have "0xee: Not supposed to get here" as per documentation/POSTCODES,
>> so maybe we can use 0xdd ("d" as in die), if that's not already used
>> elsewhere.
>
> So, thinking about this a little more, I'm not sure adding a post code to
> 'die' is a good idea. The problem with doing that is that it would clobber
> any previous post codes, which might be a better indicator for what's going
> wrong.
>
> Perhaps a good way to deal with fatal runtime error conditions would be
>
> a) set a unique post code
> b) call die
>
> in the assumption that die does not clobber the post code.
>
We could add a post code to the parameters of the die() function.
> What do you think?
>
> Thanks,
> Ward.
>
> --
> Ward Vandewege <w...@fsf.org>
> Free Software Foundation - Senior Systems Administrator
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
