Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Feb 2008 00:20:58 +0100
From:      Rafal Jaworowski <raj@semihalf.com>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        Marcel Moolenaar <marcel@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 135517 for review
Message-ID:  <47B76FDA.7070008@semihalf.com>
In-Reply-To: <EDF429F2-E803-4FA7-A387-3A53D15A21F2@mac.com>
References:  <200802162141.m1GLfgkj048217@repoman.freebsd.org> <47B75EB3.2020001@semihalf.com> <504560A3-EABB-4896-8B3E-C7FC89F31EFB@mac.com> <47B76A8E.5060607@semihalf.com> <EDF429F2-E803-4FA7-A387-3A53D15A21F2@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote:
>>>>>
>>>>>    Save U-Boot's registers at startup and restore them when
>>>>>    performing a syscall. This way we don't have to compile
>>>>>    code specially to avoid using those registers. Otherwise
>>>>>    we have to encode knowledge of those registers in at least
>>>>>    4 makefiles and introduce a build knob to enable it all.
>>>>>    This does not allow us to build everything with a single
>>>>>    build world.
>>>>>
>>>>
>>>> Hi Marcel,
>>>>
>>>> I'm not quite sure this is sufficient... I already had a similar
>>>> save/restore
>>>> in place, but there is some general problem with U-Boot that leads to
>>>> hangs
>>>> (experienced):
>>>
>>> Interesting, I didn't see any such problems with 1.3.2-rc1.
>>>
>>
>> Chances are it might not surface, depending on the regs usage pattern,
>> compiler etc., for example a -O0 build would usually hide this issue,
>> but in
>> principle those regs are not exception/interrupt safe.
> 
> Agreed. I didn't see it at -O2, BTW.
> 

When I was looking at this it also did not always pop up (with -O2 too),
although typically when loader(8) was executed and left idle for some time it
would hang sooner or later.

> We can disable interrupts when not running in U-Boot, right?
> The impact should be marginal...
> 

Yes, this could be worked around like this, but with degraded functionality:
all timer-related calls from the API would not make sense, and things like
autoboot count down will not work. Even worse, the [polled] networking might
not work at all if decrementer was shut, as we'd not be able to time out while
waiting on the packet, status registers' change and so on. I think this issue
needs some further investigation and proper resolution.

Rafal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B76FDA.7070008>