[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1403102122310.18573@ionos.tec.linutronix.de>
Date: Mon, 10 Mar 2014 21:50:24 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Paul Bolle <pebolle@...cali.nl>
cc: Jerome Oufella <jerome.oufella@...oirfairelinux.com>,
Julian Wollrath <jwollrath@....de>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RESEND] Fast TSC calibration fails with v3.14-rc1 and later
On Mon, 10 Mar 2014, Paul Bolle wrote:
> Thomas Gleixner schreef op ma 10-03-2014 om 19:57 [+0100]:
> > On Mon, 10 Mar 2014, Paul Bolle wrote:
> > >
> > > Or is there a way to handle the "SMI nonsense" (whatever that may be)?
> >
> > No, there is none. That's "value add" from the BIOS/board manufacturer
> > which utilizes the System Management Interrupt and steals CPU time
> > from the OS.
>
> So could you please consider downgrading this message?
>
> Yes, this will make regressions less visible, although I'm unsure we're
> actually seeing a regression here. But I think that this is better than
> scaring people about a situation they can't easily do something about,
> if at all. Especially since fast TSC calibration failures, apparently,
> can be worked around.
If something works fine from version X up to v3.13 and then suddenly
fails, then we can safely ignore it because there is a work around or
fallback? And just shrug and say: Oh, it's not a regression.
Dammit no. We want to know WHY!
I'm not going to downgrade that message for a simple reason.
A lot of people including me spent quite some precious time to work
around the brainwreckage of
- those who invented the concept of unreliable hardware (TSC) in the
first place
- the BIOS/board manufacturers who add crap to their BIOSes which
renders it even more unusable. Yes, even the slow calibration fails
due to that.
And now you whine because we tell loudly, that the hardware/BIOS is
crap?
You're barking up the wrong tree:
Go and tell your hardware supplier!
But sure, it's simpler to submit a patch which makes that issue less
visible just because you don't like the verbosity of those who made it
work for YOU in the first place.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists