Date: Sun, 17 Feb 2008 01:01:02 +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: <47B7793E.2020803@semihalf.com> In-Reply-To: <19353798-6A4C-4360-B08B-51D0D2719B28@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> <47B76FDA.7070008@semihalf.com> <19353798-6A4C-4360-B08B-51D0D2719B28@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. > > We always call into U-Boot when we're waiting, so interrupts should be > enabled when it's important. This is the case when we wait for time to > pass, a key press or a network packet. In all those cases we shouldn't > be running for extensive amounts of time with interrupts disabled, so > we shouldn't lose too much precision, keys or packets. > Well, the point is we would need to run with interrupts disabled during all loader's code paths, so that interrups could be allowed only for the duration of the syscall; not sure how this would serve. Anyway, let me know your findings. > I'll play with this and see if that statement is true... > >From the other end: I'll take a look at U-Boot exceptions handlers macros for the prologue/epilogue and try to fix this down there. It shouldn't be difficult, but propagating the changes to their main line code will take time... Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B7793E.2020803>