Date:	Sat, 18 Jul 2009 16:48:16 +0200
From:	wixor <wixorpeek@...il.com>
To:	mingo@...hat.com
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: APIC broken on VIA VN896

Hi,

I'm having terrible problems with interrupts on VN896. The machine is
uniprocessor (celeron m) laptop. Tests are done without Xorg (booting
to console).

Let's first try to boot without apic (noapic, nolapic or even
completly compile out apic support). Doesn't work - says "IRQ11:
nobody cared" upon bringing up wlan interface (ath5k driver). Quick
lookup in /proc/interrupts reveals that this interrupt fired 100000
(hundred thousand) times. Wlan stops working or at least behaves
strangely (and unusuable). No, wifi doesn't occupy irq11 - usb does,
and wifi has irq10, along with sound card and sata (which work).
Anyway, dmesg tells me to boot with irqpoll. I do, and wifi works
smoothly (no problems). Great.

Now let's try with apic. No IRQ problems so far, no irqpoll needed.
But launching powertop reveals two hundred thousand (200000) wakeups
per second (pretty accurate, isn't such round value suspicious?). I
could "solve" this by setting processor.max_cstate=1, but hey, C1 is
not great sleep state for a laptop (otoh acpi reports only c1 and c2).
Upon further investigation I discover that if I put lapic_timer_c2_ok
on command line, I no longer need to limit cstates. Awesome.

Wait.... crap! After a while wakeup count skyrockets back to 200000.
Now, how long exactly does it take? A cute, round value of 5 minutes,
each time exactly. This reminds me something... something called
watchdog. So I enable nmi_watchdog. Using io-apic it tells me it can't
switch to high-resolution mode and reports a hundred nmi interrupts
per second. Using lapic, first it runs smoothly, but when wakeup count
goes up, the same hundres nmis per sec appear. Yet dmesg remains
silent.

The most interesting part: when those thousands of wakeup come up,
kernel sometimes (and after some time) hangs. Nothing works, not even
keyboard, but it gives no signs of panic or anything either.

Now, all of the above was tested on 2.6.29. With 2.6.30.1 results are
very similar, only that powertop reports spending around 19 million
seconds in c2 during 45 second period. Someone's really close to the
light speed here. Kernel options versus wakeups count behavior remains
the same though.

This hardware is pile of shit, I had numerous strange and bizzare
problems with it: Have ever your hard-drive went read-only? mine could
be read any way you could think of, but any attempt to write anything
lead to halted communication with sata controller. at service they
told me it was hdd failure. I did some hands-on examination of
identical machine (same model, propably same series) and it had one
interesting difference - acpi fan regulation actually worked; mine
acpi would start the fan at full speed and never change its setting
any more. Well, i compared acpi tables and they were bit-to-bit
identical. I had to tweak my DSDT to make this "work". Moreover, DSDT
table mentions some "HPET" device that kernel doesn't see. I guess
acpi claims its address to be 0xfed04000, but I can force-enable hpet
(with existing kernel routines) at 0xfed00000 and it seems to work.
What's even more interesting, I can also force-enable hpet at claimed
address 0xfed04000 and it works too (i didn't notice any difference at
least).

Now, I'm attaching you kernel config, 2.6.30.1 dmesg and 2.6.29 dmesg
with apic=debug. I hope you can sort those things out. Thanks for your
time.

--
wixor

View attachment "config.txt" of type "text/plain" (56458 bytes)

View attachment "dmesg-2.6.29.txt" of type "text/plain" (32759 bytes)

View attachment "dmesg-2.6.30.1.txt" of type "text/plain" (25005 bytes)

Powered by blists - more mailing lists