Timekeeping hosed by factor 3, high lapic[01] interrupt rates

From: Jens Schweikhardt (schweikh_at_schweikhardt.net)
Date: 05/16/05

  • Next message: Balgansuren.B: "RE: Re: Supermicro superserver 5013S-i" 
    Date: Mon, 16 May 2005 13:34:20 +0200
To: freebsd-current@freebsd.org

    hello, world\n

    the timekeeping on my CURRENT system as of May 15 is very strange. The
    time as reported by date(1) increases too slow by a factor of 3. Things
    with second intervals like sleep 1, tail -f, iostat 1, changing folders
    in mutt all go slower by a factor of 3.

    The system bios date however is correct, and a kernel as of March does
    not have this problem, so it's clearly the kernel or some other software
    problem. I have investigated a bit and found the interrupt rates for the
    lapic[01] being three times the value on the broken kernel (about 2kHz
    vs 6kHz),

    schweikh@hal9000:~ $ vmstat -i # Good kernel
    interrupt total rate
    irq1: atkbd0 250 0
    irq3: sio1 2 0
    irq4: sio0 2 0
    irq12: psm0 9079 25
    irq13: npx0 1 0
    irq14: ata0 84 0
    irq15: ata1 77 0
    irq18: em0 1091 3
    irq24: ahd0 9112 25
    irq25: ahc0 16 0
    lapic0: timer 722947 1997 <-- ~6057 on a bad system
    irq0: clk 361525 998
    lapic1: timer 708251 1956 <-- dito
    Total 1812437 5006 <-- greater than 12000

    Maybe this gives someone a clue what goes on?

    System is a supermicro P4SCT, 3GHz P4. Dmesg and kernel config upon request.

    Regards,

            Jens 

    -- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Balgansuren.B: "RE: Re: Supermicro superserver 5013S-i"

    Relevant Pages

    • Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races
      ... freezing processes that have voluntarily scheduled? ... On the first run I forgot to remove the mutex_lockfrom the /proc/kallsyms read path and the freezer was unable to freeze the "cat" process that was waiting for the same mutex that the freezer process was holding:P ... kernel: Stopping user space processes timed out after 20 seconds: ... Strange, kseriod not stopped ...
      (Linux-Kernel)
    • Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races
      ... the /proc/kallsyms read path and the freezer was unable to freeze the ... kernel: Stopping user space processes timed out after 20 seconds (1 ... Strange, kseriod not stopped ... kernel: Strange, kbluetoothd not stopped ...
      (Linux-Kernel)
    • Re: [PATCH RESEND 2/2] Fix some kallsyms_lookup() vs rmmod races
      ... the /proc/kallsyms read path and the freezer was unable to freeze the ... kernel: Stopping user space processes timed out after 20 seconds (1 ... Strange, kseriod not stopped ... kernel: Strange, pdflush not stopped ...
      (Linux-Kernel)
    • Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates
      ... > the timekeeping on my CURRENT system as of May 15 is very strange. ... > in mutt all go slower by a factor of 3. ... so it's clearly the kernel or some other software ...
      (freebsd-current)
    • BUGS!?
      ... "commctrl.dll" when kernel debugger is enabled. ... This happens because buggy CEMON performs a strange ... The exception is actually caused by the "memcpy" from the ...
      (microsoft.public.windowsce.platbuilder)