Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > Er. Interesting. Doing some reading up on the M1533, I notice that the > power management component isn't actually listed here: > > > ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 > > hdr=0x00 > > vendor = 'Acer Labs Inc.' > > device = 'ALI M5237 USB Host Controller' > > class= serial bus > > subclass = USB > > isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 > > hdr=0x00 > > vendor = 'Acer Labs Inc.' > > device = 'M1533 PCI South Bridge' > > class= bridge > > subclass = PCI-ISA > > atapci0@pci0:15:0:class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 > > hdr=0x00 > > vendor = 'Acer Labs Inc.' > > device = 'M1543 Southbridge EIDE Controller' > > class= mass storage > > subclass = ATA > > There should be a device at pci0:3:0, something like: > > none0@pci0:3:0: class=0x?? card=0x chip=0x710110b9 rev=0x?? > hdr=0x00 > vendor = 'Acer Labs Inc.' > device = 'M7101 PCI PMU Power Management Controller' > ... > > Check that you have ACPI/power management turned on in your BIOS setup; > that's typically responsible for enabling/disabling this device... One page in the BIOS setup is dedicated for Power Management (standard AWARD BIOS 4.51). Power Management is set to "Enable" Second option is "PM control by APM" I tried both option (Yes/No), but no difference. Most other options are set to Disable (HDD power down, Wake Up events, etc.) Maybe this is an early revision of the chipset. The board is from mid 1998. I try to find an unused disk drive and install Windows on it to run the ACPI validation test suite. But this will take some time - you may expect results at the end of this week. The installed BIOS version was specificially released to allow a Windows 2000 ACPI mode installation. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Er. Interesting. Doing some reading up on the M1533, I notice that the power management component isn't actually listed here: > ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 > hdr=0x00 > vendor = 'Acer Labs Inc.' > device = 'ALI M5237 USB Host Controller' > class= serial bus > subclass = USB > isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 > hdr=0x00 > vendor = 'Acer Labs Inc.' > device = 'M1533 PCI South Bridge' > class= bridge > subclass = PCI-ISA > atapci0@pci0:15:0:class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 > hdr=0x00 > vendor = 'Acer Labs Inc.' > device = 'M1543 Southbridge EIDE Controller' > class= mass storage > subclass = ATA There should be a device at pci0:3:0, something like: none0@pci0:3:0: class=0x?? card=0x chip=0x710110b9 rev=0x?? hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M7101 PCI PMU Power Management Controller' ... Check that you have ACPI/power management turned on in your BIOS setup; that's typically responsible for enabling/disabling this device... 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
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > > > Ok. I'm going to revert to the "safe" read code in a few minutes. > > > > > > Can you update and let me know if you're still wildly off? I'm having a > > > hard time believing that your timer is really running at double pace, but > > > I guess anything is possible. If it still does, I'll add some code to > > > check it with the TSC. > > > > Hmm, just did the update > > unset debug.acpi.disable="timer" > > but the error is still there. > > Meaning no offense, but I read a lot of mail. Can you please keep your > problem reports specific? > > (ie. which bloody error?) > > Thanks. No problem, Tried -CURRENT (from yesterday), esp. src/sys/dev/acpica/acpi_timer.c,v 1.9 If I boot without debug.acpi.disable="timer" clock and rtc interrupts run at half the normal rate (50 clock/64 rtc instead of 100/128) with all the usual results: - System time (via gettimeofday()) runs at double rate - Tons of calcru: negative time of ... - Even more of microuptime() went backwards - negative running time of some processes if cpu bound processes are run at the same time. I have to set set debug.acpi.disable="timer" during bootup to get normal running clock interrupts. > > Maybe I'm just having a buggy ACPI implementation (remember, BIOS is from > > '99) > > Could be, though we're talking hardware here. It's possible that we'll > just have to blacklist your timer. 8( Can you give me the ALi chip > number(s) again, and I'll go look for datasheets... Ok, output of "pciconf -lv" attached. System board: GigaByte GA-5AX with latest BIOS (F3 released Dec, 15 1999) Daniel agp0@pci0:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1541 Aladdin V AGPset Host Bridge' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01 vendor = 'Acer Labs Inc.' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none0@pci0:8:0: class=0x04 card=0x chip=0x0002121a rev=0x02 hdr=0x00 vendor = '3dfx Interactive Inc' device = 'Voodoo2 Voodoo 2 3D Accelerator' class= multimedia subclass = video sym0@pci0:9:0: class=0x01 card=0x chip=0x00041000 rev=0x04 hdr=0x00 vendor = 'LSI Logic' device = '53C815 Fast SCSI' class= mass storage subclass = SCSI rl0@pci0:10:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet fxp0@pci0:11:0: class=0x02 card=0x00098086 chip=0x12298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none1@pci1:0:0: class=0x03 card=0x001c105d chip=0x493d105d rev=0x00 hdr=0x00 vendor = 'Number Nine Visual Technology' device = 'T2R Revolution 3D' class= display subclass = VGA
Re: ACPI: Clock problems in -current
> > Ok. I'm going to revert to the "safe" read code in a few minutes. > > > > Can you update and let me know if you're still wildly off? I'm having a > > hard time believing that your timer is really running at double pace, but > > I guess anything is possible. If it still does, I'll add some code to > > check it with the TSC. > > Hmm, just did the update > unset debug.acpi.disable="timer" > but the error is still there. Meaning no offense, but I read a lot of mail. Can you please keep your problem reports specific? (ie. which bloody error?) Thanks. > Maybe I'm just having a buggy ACPI implementation (remember, BIOS is from > '99) Could be, though we're talking hardware here. It's possible that we'll just have to blacklist your timer. 8( Can you give me the ALi chip number(s) again, and I'll go look for datasheets... 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
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > > I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages > > after defining debug.acpi.timer_test), the Off/2 error still persist. > > Ok. I'm going to revert to the "safe" read code in a few minutes. > > Can you update and let me know if you're still wildly off? I'm having a > hard time believing that your timer is really running at double pace, but > I guess anything is possible. If it still does, I'll add some code to > check it with the TSC. Hmm, just did the update unset debug.acpi.disable="timer" but the error is still there. Maybe I'm just having a buggy ACPI implementation (remember, BIOS is from '99) -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
> I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages > after defining debug.acpi.timer_test), the Off/2 error still persist. Ok. I'm going to revert to the "safe" read code in a few minutes. Can you update and let me know if you're still wildly off? I'm having a hard time believing that your timer is really running at double pace, but I guess anything is possible. If it still does, I'll add some code to check it with the TSC. -- ... 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
Re: ACPI: Clock problems in -current
Daniel Rock schrieb: > > Mike Smith schrieb: > > > acpi0: on motherboard > > > acpi0: power button is handled as a fixed feature programming model. > > > acpi_timer0: timer test in progress, reboot to quit. > > > acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e > > > acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea > > > > Excellent. I'll try to get something sorted out about this tonight. > > > > How long does it take before it prints the first message there? > > The messages are printed out almost immediately, but only if I don't set > any of CLK_USE_*_CALIBRATION in my configuration. There will be only one > step backwards (the longest time waiting was ~ 1 minute. In the case of > CLK_USE_*_CALIBRATION defined I waited 10 minutes but got no output). I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages after defining debug.acpi.timer_test), the Off/2 error still persist. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > acpi0: on motherboard > > acpi0: power button is handled as a fixed feature programming model. > > acpi_timer0: timer test in progress, reboot to quit. > > acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e > > acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea > > Excellent. I'll try to get something sorted out about this tonight. > > How long does it take before it prints the first message there? The messages are printed out almost immediately, but only if I don't set any of CLK_USE_*_CALIBRATION in my configuration. There will be only one step backwards (the longest time waiting was ~ 1 minute. In the case of CLK_USE_*_CALIBRATION defined I waited 10 minutes but got no output). -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
> > From [EMAIL PROTECTED] Tue Jul 31 12:15:25 2001 > > > > set debug.acpi.timer_test="yes" > > > > at the loader prompt and boot? Ideally, you'll get a message "timer is > > not monotonic", followed by some numbers. If this is the case, then I > > need to get "smarter" with the ACPI timer probe. > > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > acpi_timer0: timer test in progress, reboot to quit. > acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e > acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea Excellent. I'll try to get something sorted out about this tonight. How long does it take before it prints the first message there? 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
Re: ACPI: Clock problems in -current
> From [EMAIL PROTECTED] Tue Jul 31 12:15:25 2001 > > set debug.acpi.timer_test="yes" > > at the loader prompt and boot? Ideally, you'll get a message "timer is > not monotonic", followed by some numbers. If this is the case, then I > need to get "smarter" with the ACPI timer probe. acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_timer0: timer test in progress, reboot to quit. acpi_timer0: timer is not monotonic: 0x1d52ab49,0x1d52ab4f,0x1d52ab4e acpi_timer0: timer is not monotonic: 0x1d52ab4f,0x1d52ab4e,0x1d5b89ea -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
> > - What power management hardware your system has: look at the output of > >pciconf -lv for a "power management controller", eg: > > > This machine has no separate controller. Attached is the complete output > of "pciconf -lv" That's OK; I can probably safely assume it's the M1533 device. > > - which timecounter is in use on your system, eg: > > > > mass# sysctl kern.timecounter.hardware > > kern.timecounter.hardware: ACPI > > During the Off/2 errors this variable contained "ACPI" Ok, so far so good. > > - whether you are seeing any "*time went backwards" console messages. > > Tons of, even with negative CPU-Usage times. Ok, I think we have the enemy in sight. Can you please say: set debug.acpi.timer_test="yes" at the loader prompt and boot? Ideally, you'll get a message "timer is not monotonic", followed by some numbers. If this is the case, then I need to get "smarter" with the ACPI timer probe. Thanks! -- ... 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
Re: ACPI: Clock problems in -current
Mike Smith schrieb: [...] > Unfortunately, I can't reproduce the problem here - the new timer seems > to be working just fine. Can anyone seeing this please let me know: > > - What power management hardware your system has: look at the output of >pciconf -lv for a "power management controller", eg: > This machine has no separate controller. Attached is the complete output of "pciconf -lv" > > - which timecounter is in use on your system, eg: > > mass# sysctl kern.timecounter.hardware > kern.timecounter.hardware: ACPI During the Off/2 errors this variable contained "ACPI" > - whether you are seeing any "*time went backwards" console messages. Tons of, even with negative CPU-Usage times. Interesting enough, a "sleep 10" sleeps 10 real seconds: % date; sleep 10; date Mo 30 Jul 2001 19:27:07 CEST [...10 seconds delay...] Mo 30 Jul 2001 19:27:27 CEST -- Daniel agp0@pci0:0:0: class=0x06 card=0x154110b9 chip=0x154110b9 rev=0x04 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1541 Aladdin V AGPset Host Bridge' class= bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00e0 chip=0x524310b9 rev=0x04 hdr=0x01 vendor = 'Acer Labs Inc.' device = 'ALI M1541 PCI to AGP Bridge' class= bridge subclass = PCI-PCI ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'ALI M5237 USB Host Controller' class= serial bus subclass = USB isab0@pci0:7:0: class=0x060100 card=0x chip=0x153310b9 rev=0xc3 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1533 PCI South Bridge' class= bridge subclass = PCI-ISA none0@pci0:8:0: class=0x04 card=0x chip=0x0002121a rev=0x02 hdr=0x00 vendor = '3dfx Interactive Inc' device = 'Voodoo2 Voodoo 2 3D Accelerator' class= multimedia subclass = video sym0@pci0:9:0: class=0x01 card=0x chip=0x00041000 rev=0x04 hdr=0x00 vendor = 'LSI Logic' device = '53C815 Fast SCSI' class= mass storage subclass = SCSI rl0@pci0:10:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/8130) Fast Ethernet Adapter' class= network subclass = ethernet fxp0@pci0:11:0: class=0x02 card=0x00098086 chip=0x12298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class= network subclass = ethernet atapci0@pci0:15:0: class=0x0101fa card=0x chip=0x522910b9 rev=0xc1 hdr=0x00 vendor = 'Acer Labs Inc.' device = 'M1543 Southbridge EIDE Controller' class= mass storage subclass = ATA none1@pci1:0:0: class=0x03 card=0x001c105d chip=0x493d105d rev=0x00 hdr=0x00 vendor = 'Number Nine Visual Technology' device = 'T2R Revolution 3D' class= display subclass = VGA
Re: ACPI: Clock problems in -current
> On Sat, 28 Jul 2001, Mike Smith wrote: > > > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > > and then booting with -v (without the timer disabled). This might be > > instructive (I don't know for certain that it'll calibrate the ACPI > > timer, since it may not have been probed yet). > > It won't. CLK_CALIBRATION_LOOP only iterates calibration of the i8254 > and TSC timers relative to the RTC. None of the clock calibration stuff > is very useful. All the clock frequencies depend on the temperature, > so their values at boot time are only slightly more related to their > values at run time than their values at a random time. Average values > are probably better than boot time values. Understsood, however the current problem reports indicate an off-by-2x problem, which the calibration loops would deal with just fine. Unfortunately, I can't reproduce the problem here - the new timer seems to be working just fine. Can anyone seeing this please let me know: - What power management hardware your system has: look at the output of pciconf -lv for a "power management controller", eg: none0@pci0:7:3: class=0x068000 card=0x chip=0x71138086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82371AB PIIX4 Power Management Controller' class= bridge subclass = PCI-unknown - which timecounter is in use on your system, eg: mass# sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI - whether you are seeing any "*time went backwards" console messages. Thanks. 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
Re: ACPI: Clock problems in -current
On Sat, 28 Jul 2001, Mike Smith wrote: > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > and then booting with -v (without the timer disabled). This might be > instructive (I don't know for certain that it'll calibrate the ACPI > timer, since it may not have been probed yet). It won't. CLK_CALIBRATION_LOOP only iterates calibration of the i8254 and TSC timers relative to the RTC. None of the clock calibration stuff is very useful. All the clock frequencies depend on the temperature, so their values at boot time are only slightly more related to their values at run time than their values at a random time. Average values are probably better than boot time values. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz > > Hrm. Drat. > > You're running on an K6, and ACPI is working for you? I'm impressed; I > guess this is a fairly new motherboard? No, it is an at least 3 years old GigaByte GA-5AX (Ali Aladdin V). Even the BIOS is from December 1999. -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
> Mike Smith schrieb: > > > > Say > > > > set debug.acpi.disable="timer" > > > > in the bootloader and see if you still get this. I've already got one > > report of system time going twice as fast as it should; I'm unsure what's > > going on here (I don't grok the timecounter code as well as I should, I > > think)... > > This helps. Ok. I'll go look at it again. > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Hrm. Drat. You're running on an K6, and ACPI is working for you? I'm impressed; I guess this is a fairly new motherboard? -- ... 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
Re: ACPI: Clock problems in -current
Mike Smith schrieb: > > Say > > set debug.acpi.disable="timer" > > in the bootloader and see if you still get this. I've already got one > report of system time going twice as fast as it should; I'm unsure what's > going on here (I don't grok the timecounter code as well as I should, I > think)... This helps. > > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > and then booting with -v (without the timer disabled). This might be > instructive (I don't know for certain that it'll calibrate the ACPI > timer, since it may not have been probed yet). Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300685043 Hz, i8254 clock: 1193195 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Timecounter "i8254" frequency 1193190 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI: Clock problems in -current
Say set debug.acpi.disable="timer" in the bootloader and see if you still get this. I've already got one report of system time going twice as fast as it should; I'm unsure what's going on here (I don't grok the timecounter code as well as I should, I think)... You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). Thanks! > Hi, > > just noticed with a -current from yesterday (today's -current has the > same problem). > > After bootup I will see tons of > calcru: negative time of -953757 usec for pid 636 (make) > calcru: negative time of -820616 usec for pid 636 (make) > microuptime() went backwards (1969.4485199 -> 1969.552693) > microuptime() went backwards (1969.4485199 -> 1969.690311) > messages, together with processes with a negative CPU usage time. > > Something is going wrong during setting clock interrupts. > A "vmstat -i" shows (among other interrupts): > clk irq079496 49 > rtc irq8 101753 63 > which is about half the rate it should be. > > The latest working kernel I was booting before was from Jul, 13th > > If I disable ACPI in the kernel the interrupt rate is back to normal. > > ACPI related boot messages: > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_cpu0: on acpi0 > acpi_button0: on acpi0 > acpi_pcib0: on acpi0 > pci0: on acpi_pcib0 > acpi_cpu0: set speed to 100.0% > acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% > > Mainboard is a GigaByte GA-5AX with F3 BIOS. > > > I will provide further configuration information if needed. > > > -- > Daniel > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- ... 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
