lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 06 May 2007 11:23:26 +0200
From:	Rafał Bilski <rafalbilski@...eria.pl>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	Wander Winkelhorst <w.winkelhorst@...il.com>,
	David Johnson <dj@...id-web.co.uk>,
	linux-kernel@...r.kernel.org, cpufreq@...ts.linux.org.uk
Subject: Re: cpufreq longhaul locks up

> <6>No local APIC present or hardware disabled
> <7>mapped APIC to ffffd000 (011ea000)
> <5>Local APIC not detected. Using dummy APIC emulation.
I/O APIC is very bad thing with Longhaul, but You don't have 
local APIC, so it shouldn't be used.
> <6>ACPI: Using PIC for interrupt routing
Looks like it isn't.
> <4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled.
> <4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21)
> <4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22)
> <4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled.
This is pointing to I/O APIC, but I don't see later that 
such high interrupts are used. And if I/O APIC would be in 
use You would have lockup in the moment of transition.

I was suspecting:
> One of the 2.6.21 regressions was Guilherme's problem seeing his box
> lock up when the system detected an unstable TSC and dropped back to
> using the HPET.
> 
> In digging deeper, we found the HPET is not actually incrementing on
> this system. And in fact, the reason why this issue just cropped up was
> because of Thomas's clocksource watchdog code was comparing the TSC to
> the HPET (which wasn't moving) and thought the TSC was broken.
because I know that VT8237 has HPET built in. But I don't see any lines 
starting with "hpet: enabled" or something similar. But I don't know 
what to search for. I didn't have contact with HPET earlier.
It is very similar and Your problem with ondemand is starting right 
after
> May  3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 
> ns)
I don't see such message as long as "performance" governor is used. 

Anyway adding "hpet=disable" at boot should confirm for sure that it 
isn't it. And I think that John already ruled this out by 
clocksource=acpi_pm.

Sorry 
Rafał

----------------------------------------------------------------------- Linda jako gospodyni domowa - zobacz!!!
>>> http://link.interia.pl/f1a79

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ