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 stigge@sulfurcell.de