Hi,
Just to wrap the story up: I checked the source code. The offending
"oops" comes from a line 390 in hpet.c, which is the WARN_ON_ONCE call
below:
<kernel code>
/*
* We need to read back the CMP register to make sure that
* what we wrote hit the chip before we compare it to the
* counter.
*/
WARN_ON_ONCE((u32)hpet_readl(HPET_Tn_CMP(timer)) != cnt);
</kernel code>
(there are two hpet.c in the kernel tree, but I won't be fussy)
In a more recent kernel the most dramatic change is this module was that
the comment was changed to:
/*
* We need to read back the CMP register on certain HPET
* implementations (ATI chipsets) which seem to delay the
* transfer of the compare register into the internal compare
* logic. With small deltas this might actually be too late as
* the counter could already be higher than the compare value
* at that point and we would wait for the next hpet interrupt
* forever. We found out that reading the CMP register back
* forces the transfer so we can rely on the comparison with
* the counter register below. If the read back from the
* compare register does not match the value we programmed
* then we might have a real hardware problem. We can not do
* much about it here, but at least alert the user/admin with
* a prominent warning.
This looks like the driver failed on some sanity check. Not happy with
it, but I saw no smoke.
Since the CONFIG_BUG flag is set on my kernel configuration (don't think
I was aware of that issue until now) that kicked off an oops.
This code is obviously responsible for the High Precision Event Timer on
my machine. See http://en.wikipedia.org/wiki/High_Precision_Event_Timer
So the bottom line is that my super precise timer will not work in the
near future, but the most likely reason for a filesystem crash is
between chair and keyboard. That's a comforting thought. ;)
Eli
--
Web: http://www.billauer.co.il
_______________________________________________
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
