Horms schrieb:
Is there any chance that any of the interested parties could test
a) 2.4.12 from unstable and b) an unpatched kernel from kernel.org?
I'll try an unpatched kernel on an affected machine within the next 10 days.
Are you sure there is an 2.4.12 in unstable?
Sorry I ment 2.6.12, its at ftp://ftp.debian.org/debian/pool/main/l/linux-2.6/
What worked so far is a self-compiled Debian patched 2.6.11 with
ACPI_SLEEP and X86_UP_IOAPIC disabled, but the precompiled 2.6.11-2-686
didn't. What also worked (on one of the machines, the others are in
production-use, I can't test very much there) is the precompiled
2.6.12-1-686 with kernel-option "noapic", and without that, the clock
went crazy again - which is a) from above. (!) These were my tests so
far -- I'll try a vanilla 2.6.12.3 within the next days (b from above).
What's special to this kernel? I also tried kernel-image-2.4.27-2-686
from sarge, where the problem seemed to be gone - but some of the
affected systems where somehow instable using this kernel (random
lockups within 3-6 days).
There is nothing particularly special about 2.6.12, I just think it
would be good to check if it has been fixed upstream.
It's not.
For me (with kernel 2.6), disabling ACPI_SLEEP and X86_UP_IOAPIC worked
(no BIOS update, no comment-out in pci_link.c). Maybe one of them would
have been enough, but there wasn't enough time to test this..
Ok, strange that worked but passing kernel boot parameters didn't,
or am I thinking about a different big?
I didn't pass any of the mentioned parameters before. (!) Seems noapic
is enough here (as being equivalent to disabling X86_UP_IOAPIC?).
Martin
--
SULFURCELL Solartechnik GmbH
Martin Stigge
Barbara-McClintock-Str. 11
12489 Berlin
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
