I've made a couple of minor changes to the ACPI code:
- Fixed (hopefully) PCI interrupt routing, thanks to [EMAIL PROTECTED]
who was able to actually test (and correct) my code.
- Changed the way ACPI timers are treated to be more pessimistic. It
looks like we can't assume that the average ACPI timer is properly
implemented. This is a pain; a "good" timer takes about 350 cycles to
read on my PIII/500 laptop, wheras the "safe" read takes about 1050
cycles. (~700ns vs. 2us respectively). The code will still optimise
if a known-good timer is detected.
To test your ACPI timer, first check to see which one you have. Look
at the output of 'pciconf -lv'. If you have an Intel chipset, chances
are that we already know about it, and the code will do the right
thing. For example:
none0@pci0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82371AB PIIX4 Power Management Controller'
class = bridge
subclass = PCI-unknown
This is the PIIX4M, (rev=0x03), known to be reliable.
If you have a non-Intel chipset and you want to try it out, say
set debug.acpi.timer_test="yes"
at the loader prompt, then boot. If your timer has problems, you
should see messages like:
acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea
being displayed at random intervals. If after several minutes you do
not see any of these messages, please send me the output of
'pciconf -lv' and I'll see whether we can safely detect your ACPI
timer.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
