>>> On 06.08.12 at 14:52, Matthew Garrett <mj...@srcf.ucam.org> wrote: > On Mon, Aug 06, 2012 at 07:44:34AM +0100, Jan Beulich wrote: > >> In any case, without having seen _how_ things break I don't >> think a decision should be taken if/how to address this >> (apparent) regression. > > Machines that previously worked no longer work. That's a pretty strong > argument in favour of reverting until we can identify a workaround.
Yes, one can view it that way. But then again things should have been the way they are now from the beginning - it appears rather questionable how someone would have come up with the strange idea to stick some #ifdef CONFIG_X86_32 in there, and not even bother to comment this hackery. Hence my position is that this really very likely should have never worked on the box in question, it was merely one bug hiding another. But of course all this is guesswork without knowing the technical details of the observed crash. Plus I'm pretty convinced that once the change gets reverted, the code will remain that way for another couple of years (and quite likely whatever UEFI implementation it is that we have the problem with here will too), as then there's no incentive for anyone to get this done properly (until the then very sad day where some EFI system shows up that, being legacy free, _really_ doesn't have a CMOS RTC anymore - with the change at hand I merely tried to be proactive). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
