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


... 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

Reply via email to