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.'
> >
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 Cont
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.
> > 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
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 sti
> 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
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_ti
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: 0x1d52
> > 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
> 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:
> > - 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
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 controll
> 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 hav
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 probe
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 Aladdi
> 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
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)
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
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)
mi
19 matches
Mail list logo
