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>] [day] [month] [year] [list]
Date:	Thu, 9 Aug 2007 03:23:02 -0400
From:	"Richard Harman" <richard.harman@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	richard.harman@...il.com
Subject: IO-APIC/ACPI/SMP problems on HP Pavilion DV6000 series laptop (2.6.22.1, from Fedora 7)

(I'm not subscribed to lkml, please CC me in your replies)

Anyone have an HP Pavilion DV6000 series laptop (mine's a dv6408nr to
be exact) that successfully brings up both cores of its AMD Turion 64
X2 TL-56 and is stable?  I get the feeling that there's a problem with
the APIC, or ACPI or even both.

Generally, the system locks up just before it should print "Brought up 2 CPUs".

The Windows vista that came with it somehow brings the system up using
the APIC, and msinfo32 shows it "seeing" >150 IRQs numbered as high as
190 (and two that are such a high number it can only be wrong), with
only 16 IRQs really in use.

Booting with 'noapic' results in the system bringing up both cores,
but IRQ7 getting disabled later with "nobody cares".  Using irqpoll
causes the system to be excessively slow.

I've run through the various kernel command line params in
Documentation/{kernel-paramaters.txt,x86_64/boot_options.txt} and not
any of the pci/apic/acpi options individually seem to bring the system
into full working order.  The APIC timer related options result in the
SATA controller going nuts, some result in 'APIC error on CPU0:
40(40)' to be printed on every key-down/key-up event.  Most result in
the system locking up hard between 40 seconds to 2 minutes after
booting if the system boots at all.  The ERR: line in /proc/interrupts
is >1, many times 80 or higher and grows over time.

Booting maxcpus=1 results in the APIC being happy (/proc/interrupts
has all the IRQs managed by the APIC), and there aren't more than one
ERR: interrupts.


Any thoughts?

Thanks in advance,
Richard
-
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