Messages in this thread |  | | Date | Thu, 8 Nov 2001 09:32:30 +1100 (EST) | From | Neale Banks <> | Subject | Re: VIA 686 timer bugfix incomplete |
| |
On Wed, 7 Nov 2001, Vojtech Pavlik wrote:
[...] > On Wed, Nov 07, 2001 at 08:48:00PM +0100, Jonas Diemer wrote: [...] > > well, just use the option described above. that way, ppl that need the fix can > > choose to use it (at a cost of performance), others simply don't need checking. > > > > -jonas > > > > PS: CC me in your answers plz, I am not subscribed to the list. > > The VIA bug isn't a problem: The fix doesn't cause performance problems > to people unaffected by the bug, it just prints an annoying message to > people who see it triggered by bug #2 (Neptune). [snip]
Maybe not performance problems, but my tired-but-otherwise-reliable AcerNote-950C (which definitely does not have a VIA686a - it's a Pentium) doesn't seem to like this VIA686a fix (but only sometimes {:-( ).
Prior to 2.2.19, on going to sleep due to low battery, I could reliably wake it up. with 2.2.19 (being where this fix entered 2.2) this isn't the case - sometimes I just get the "probable bug" message, sometimes also a diag re hda (sorry, can't quote right now) and on one occasion serious file system corruption (OK, maybe it was a co-incidence, or maybe not).
Yes, I probably have a bug in the timer department, but I strongly suspect that the fix for the 686a is not appropriate for my chipset.
If the current VIA686a "probable bug" fix is going to remain as default, then I for one would like to see a knob to disable it.
For 2.2, I'm happy to have a go at making and alpha-testing a patch for a kernel command-line switch to disable this - but I'd very much like to hear from the custodians of consistency in such matters as to an appropriate/best attribute=value to use for this. Some sugestions:
chips=novia686a via_hacks=no686a via_hacks=none timer=no686a
Regards, Neale.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |