LinuxLists.cc - 2.6.27-rc8+ - first impressions

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> Hi,
>
> Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> 64 laptop that is normally runs with Fedora distribution kernel.
> Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> speed, fans are constantly on, everything seems sluggish.
>
> Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> somewhere in tty_init.

Is that an HP box, by chance?

Rafael

2008-10-05 19:07:21

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > Hi,
> >
> > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > 64 laptop that is normally runs with Fedora distribution kernel.
> > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > speed, fans are constantly on, everything seems sluggish.
> >
> > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > somewhere in tty_init.
>
> Is that an HP box, by chance?
>

Yeah, HP nx6115.

--
Dmitry

2008-10-05 19:11:44

by Arjan van de Ven

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, 5 Oct 2008 14:36:25 -0400
Dmitry Torokhov <[email protected]> wrote:

> Hi,
>
> Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> 64 laptop that is normally runs with Fedora distribution kernel.
> Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> speed, fans are constantly on, everything seems sluggish.
>
> Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> somewhere in tty_init.

hpet=force is a "the kernel thinks it's not wise to use, but you think
better"... don't do that ;(

--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org

2008-10-05 19:15:24

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > Hi,
> > >
> > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > speed, fans are constantly on, everything seems sluggish.
> > >
> > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > somewhere in tty_init.
> >
> > Is that an HP box, by chance?
> >
>
> Yeah, HP nx6115.

Oh well.

Please send me the output of dmidecode from it.

Thanks,
Rafael

2008-10-05 19:27:51

by Thomas Gleixner

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, 5 Oct 2008, Rafael J. Wysocki wrote:
> On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > Hi,
> > > >
> > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > speed, fans are constantly on, everything seems sluggish.
> > > >
> > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > somewhere in tty_init.
> > >
> > > Is that an HP box, by chance?
> > >
> >
> > Yeah, HP nx6115.
>
> Oh well.
>
> Please send me the output of dmidecode from it.

Please send me bootlog (output of dmesg) and output of "cat /proc/timer_list"

Thanks,

tglx

2008-10-05 21:20:57

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, Oct 05, 2008 at 09:19:13PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > Hi,
> > > >
> > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > speed, fans are constantly on, everything seems sluggish.
> > > >
> > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > somewhere in tty_init.
> > >
> > > Is that an HP box, by chance?
> > >
> >
> > Yeah, HP nx6115.
>
> Oh well.
>
> Please send me the output of dmidecode from it.
>

Here you go:

# dmidecode 2.9
SMBIOS 2.3 present.
23 structures occupying 972 bytes.
Table at 0x000FC68F.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: Hewlett-Packard
Version: 68DTT Ver. F.0D
Release Date: 11/22/2005
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 KB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported

Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Compaq nx6115 (PZ886UA#ABA)
Version: F.0D
Serial Number: CND6080M6F
UUID: B58EC937-7FA3-DA11-15A0-66990C033D29
Wake-up Type: Power Switch

Handle 0x0040, DMI type 126, 4 bytes
Inactive

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 308E
Version: KBC Version 45.25
Serial Number: Not Specified

Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Hewlett-Packard
Type: Notebook
Lock: Not Present
Version: Not Specified
Serial Number: CND6080M6F
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: External Interface Enabled

Handle 0x0041, DMI type 126, 4 bytes
Inactive

Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: U10
Type: Central Processor
Family: Pentium M
Manufacturer: AMD(R)
ID: 42 0F 02 00 FF FB 8B 07
Signature: Type 0, Family 15, Model 36, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
Version: AMD Turion(tm) 64 Mobile ML-30
Voltage: 1.1 V
External Clock: 200 MHz
Max Speed: 1600 MHz
Current Speed: 1600 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 KB
Maximum Size: 128 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: 4-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: External
Installed Size: 1024 KB
Maximum Size: 1024 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: None
System Type: Unified
Associativity: 4-way Set-associative

Handle 0x0007, DMI type 9, 13 bytes
System Slot Information
Designation: PC CARD-Slot 0
Type: 32-bit PC Card (PCMCIA)
Current Usage: Available
Length: Short
ID: Adapter 0, Socket 0
Characteristics:
5.0 V is provided
3.3 V is provided
PC Card-16 is supported
Cardbus is supported
PME signal is supported

Handle 0x0008, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: 128

Handle 0x0009, DMI type 11, 5 bytes
OEM Strings
String 1: http://www.hp.com

Handle 0x000A, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 2 GB
Error Information Handle: No Error
Number Of Devices: 2

Handle 0x000B, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #1
Bank Locator: Not Specified
Type: DDR
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)
Manufacturer: 7FA8000000000000
Serial Number: 00000000
Asset Tag: Not Specified
Part Number:

Handle 0x000C, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #2
Bank Locator: Not Specified
Type: DDR
Type Detail: Synchronous
Speed: 333 MHz (3.0 ns)
Manufacturer: CE00000000000000
Serial Number: 02077132
Asset Tag: Not Specified
Part Number: M4 70L6524CU0-CB3

Handle 0x000D, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Array Handle: 0x000A
Partition Width: 0

Handle 0x000E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0001FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x000B
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 1

Handle 0x000F, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00020000000
Ending Address: 0x0003FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x000C
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 2

Handle 0x0010, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected

Handle 0x0085, DMI type 133, 34 bytes
OEM-specific Type
Header and Data:
85 22 85 00 01 A0 0F D9 02 D7 02 02 00 68 00 1C
00 7B 30 00 00 30 2A 02 E0 40 00 00 31 10 07 10
44 10
Strings:
00159 12/16/2005
HP

Handle 0x0086, DMI type 134, 34 bytes
OEM-specific Type
Header and Data:
86 22 86 00 01 A0 0F D6 0B 30 0B 02 00 13 01 1C
00 2D 3F 00 00 40 38 02 E0 40 CE 0F CF 0F CA 0F
C6 0F
Strings:
46335 11/04/2005
HP

Handle 0x0011, DMI type 144, 26 bytes
OEM-specific Type
Header and Data:
90 1A 11 00 90 00 41 00 FC 00 67 00 96 00 DE 01
00 00 00 00 01 00 CD 01 00 00

Handle 0x0012, DMI type 127, 4 bytes
End Of Table

--
Dmitry

2008-10-05 21:40:54

by Parag Warudkar

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, Oct 5, 2008 at 5:18 PM, Dmitry Torokhov
<[email protected]> wrote:

> Vendor: Hewlett-Packard
> Version: 68DTT Ver. F.0D
> Release Date: 11/22/2005

Not sure if the HPET related things are better in the latest release
of the 6915 BIOS - which is F12 [*].
But may be worth trying?

[*'] http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=in&prodTypeId=321957&prodSeriesId=471752&swItem=ob-59364-1&prodNameId=471755&swEnvOID=1093&swLang=8&taskId=135&mode=4&idx=2

Parag

2008-10-05 22:25:52

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> On Sun, Oct 05, 2008 at 09:19:13PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > > Hi,
> > > > >
> > > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > > speed, fans are constantly on, everything seems sluggish.
> > > > >
> > > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > > somewhere in tty_init.
> > > >
> > > > Is that an HP box, by chance?
> > > >
> > >
> > > Yeah, HP nx6115.
> >
> > Oh well.
> >
> > Please send me the output of dmidecode from it.
> >
>
> Here you go:

Thanks.

Please see if the appended patch helps.

Rafael

Not-yet-signed-off-by: Rafael J. Wysocki <[email protected]>
---
arch/x86/kernel/acpi/boot.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -1605,6 +1605,14 @@ static struct dmi_system_id __initdata a
*/
{
.callback = dmi_ignore_irq0_timer_override,
+ .ident = "HP nx6115 laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6115"),
+ },
+ },
+ {
+ .callback = dmi_ignore_irq0_timer_override,
.ident = "HP NX6125 laptop",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
@@ -1619,6 +1627,14 @@ static struct dmi_system_id __initdata a
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
},
},
+ {
+ .callback = dmi_ignore_irq0_timer_override,
+ .ident = "HP 6715b laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 6715b"),
+ },
+ },
{}
};

2008-10-06 06:23:18

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Mon, Oct 06, 2008 at 12:29:42AM +0200, Rafael J. Wysocki wrote:
> On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > On Sun, Oct 05, 2008 at 09:19:13PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > > > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > > > speed, fans are constantly on, everything seems sluggish.
> > > > > >
> > > > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > > > somewhere in tty_init.
> > > > >
> > > > > Is that an HP box, by chance?
> > > > >
> > > >
> > > > Yeah, HP nx6115.
> > >
> > > Oh well.
> > >
> > > Please send me the output of dmidecode from it.
> > >
> >
> > Here you go:
>
> Thanks.
>
> Please see if the appended patch helps.
>

Yep, works great, everything is zappy, hdparm reports 30Mb/s and fan is
off. Thanks a lot!

Although I wonder why this blacklist is needed now, earlier kernels were
able to cope with this condition.

--
Dmitry

2008-10-06 06:28:54

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Sun, Oct 05, 2008 at 12:10:46PM -0700, Arjan van de Ven wrote:
> On Sun, 5 Oct 2008 14:36:25 -0400
> Dmitry Torokhov <[email protected]> wrote:
>
> > Hi,
> >
> > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > 64 laptop that is normally runs with Fedora distribution kernel.
> > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > speed, fans are constantly on, everything seems sluggish.
> >
> > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > somewhere in tty_init.
>
> hpet=force is a "the kernel thinks it's not wise to use, but you think
> better"... don't do that ;(
>

That is not how I parse dmesg:

[ 0.077927] HPET not enabled in BIOS. You might try hpet=force boot
option

Here kernel recommends to try and enable it. If we generally don't recommed
using 'force' I'd suggest removing the 2nd sentence from the message.

--
Dmitry

2008-10-06 09:55:34

[permalink] [raw]

Subject: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Monday, 6 of October 2008, Dmitry Torokhov wrote:
> On Mon, Oct 06, 2008 at 12:29:42AM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > On Sun, Oct 05, 2008 at 09:19:13PM +0200, Rafael J. Wysocki wrote:
> > > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > > On Sun, Oct 05, 2008 at 08:59:49PM +0200, Rafael J. Wysocki wrote:
> > > > > > On Sunday, 5 of October 2008, Dmitry Torokhov wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > > > > speed, fans are constantly on, everything seems sluggish.
> > > > > > >
> > > > > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > > > > somewhere in tty_init.
> > > > > >
> > > > > > Is that an HP box, by chance?
> > > > > >
> > > > >
> > > > > Yeah, HP nx6115.
> > > >
> > > > Oh well.
> > > >
> > > > Please send me the output of dmidecode from it.
> > > >
> > >
> > > Here you go:
> >
> > Thanks.
> >
> > Please see if the appended patch helps.
> >
>
> Yep, works great, everything is zappy, hdparm reports 30Mb/s and fan is
> off. Thanks a lot!

OK, thanks for the confirmation. Below is a changelogged version for
inclusion.

> Although I wonder why this blacklist is needed now, earlier kernels were
> able to cope with this condition.

Please see the changelog. :-)

Thanks,
Rafael

---
From: Rafael J. Wysocki <[email protected]>

x86 ACPI: Blacklist two HP machines with buggy BIOSes

There is a bug in the BIOSes of some HP boxes with AMD Turions which
connects IO-APIC pins with ACPI thermal trip points in such a way
that if the state of the IO-APIC is not as expected by the (buggy)
BIOS, the thermal trip points are set to insanely low values
(usually all of them become 16 degrees Celsius). As a result,
thermal throttling kicks in and knock the system down to its shoes.

Unfortunately some of the recent IO-APIC changes made the bug show
up. To prevent this from happening, blacklist machines that are
known to be affected (nx6115 and 6715b in this particular case).

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11516 listed as
a regression from 2.6.26.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Tested-by: Dmitry Torokhov <[email protected]>
Tested-by: Jason Vas Dias <[email protected]>
---
arch/x86/kernel/acpi/boot.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

Index: linux-2.6/arch/x86/kernel/acpi/boot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -1605,6 +1605,14 @@ static struct dmi_system_id __initdata a
*/
{
.callback = dmi_ignore_irq0_timer_override,
+ .ident = "HP nx6115 laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6115"),
+ },
+ },
+ {
+ .callback = dmi_ignore_irq0_timer_override,
.ident = "HP NX6125 laptop",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
@@ -1619,6 +1627,14 @@ static struct dmi_system_id __initdata a
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
},
},
+ {
+ .callback = dmi_ignore_irq0_timer_override,
+ .ident = "HP 6715b laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq 6715b"),
+ },
+ },
{}
};

2008-10-06 14:55:29

by Linus Torvalds

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Mon, 6 Oct 2008, Rafael J. Wysocki wrote:
>
> Unfortunately some of the recent IO-APIC changes made the bug show
> up. To prevent this from happening, blacklist machines that are
> known to be affected (nx6115 and 6715b in this particular case).

Can you point to exactly _which_ recent change made it show up? I'd really
like to know. _What_ was it that made us suddenly need this quirk when it
wasn't necessary before? I'd like to understand the root cause here.

And how did you even start looking at that strange ACPI override?

Linus

2008-10-06 15:01:25

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

* Linus Torvalds <[email protected]> wrote:

> On Mon, 6 Oct 2008, Rafael J. Wysocki wrote:
> >
> > Unfortunately some of the recent IO-APIC changes made the bug show
> > up. To prevent this from happening, blacklist machines that are
> > known to be affected (nx6115 and 6715b in this particular case).
>
> Can you point to exactly _which_ recent change made it show up? I'd
> really like to know. _What_ was it that made us suddenly need this
> quirk when it wasn't necessary before? I'd like to understand the root
> cause here.
>
> And how did you even start looking at that strange ACPI override?

i think it was caused by this stream of IO-APIC changes:

49a66a0: x86: I/O APIC: Always report how the timer has been set up
17c4469: x86: I/O APIC: Include <asm/i8259.h> required by some code
593f4a7: x86: APIC: remove apic_write_around(); use alternatives
ce8b06b: x86: I/O APIC: remove an IRQ2-mask hack
af17478: x86: I/O APIC: Never configure IRQ2
c88ac1d: x86: L-APIC: Always fully configure IRQ0
1baea6e: x86: L-APIC: Set IRQ0 as edge-triggered

Rafael/Maciej, which of these is causing it? ce8b06b ("x86: I/O APIC:
remove an IRQ2-mask hack")?

Current theory is that this specific flavor of BIOS on HP / AMD / Turion
laptops (no other type is known to be affected at the moment) somehow
detects the IO-APIC masking patterns and uses an SMI quirk to change the
ACPI thermal trip point to very low settings, and thus confusing cpufreq
to (correctly) go into a very slow frequency.

Activating the quirk works this around. Should we perhaps default to
this 'quirk' enabled by default?

Ingo

2008-10-06 17:11:19

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Monday, 6 of October 2008, Linus Torvalds wrote:
>
> On Mon, 6 Oct 2008, Rafael J. Wysocki wrote:
> >
> > Unfortunately some of the recent IO-APIC changes made the bug show
> > up. To prevent this from happening, blacklist machines that are
> > known to be affected (nx6115 and 6715b in this particular case).
>
> Can you point to exactly _which_ recent change made it show up? I'd really
> like to know. _What_ was it that made us suddenly need this quirk when it
> wasn't necessary before? I'd like to understand the root cause here.

On my box it was caused by:

commit 691874fa96d6349a8b60f8ea9c2bae52ece79941
Author: Maciej W. Rozycki <[email protected]>
Date: Tue May 27 21:19:51 2008 +0100

x86: I/O APIC: timer through 8259A second-chance

Signed-off-by: Maciej W. Rozycki <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

and the whole story is described in this (huge) thread:
http://marc.info/?l=linux-kernel&m=121358440508410&w=4

> And how did you even start looking at that strange ACPI override?

Well, Matthew Garrett told us about that happening on the nx6125:

http://marc.info/?l=linux-kernel&m=121396307411930&w=4

and then Maciej analysed the breakage on the basis of a DSDT from the nx6325:

http://marc.info/?l=linux-kernel&m=121401068718826&w=4

As far as the Dmitry's and Jason's boxes are concerned, I recognized the
symptoms and asked them to verify that the blacklisting helped.

It appears that the buggy BIOS code has been copy-pasted to the entire range of
machines, for no good reason.

Thanks,
Rafael

2008-10-06 17:13:18

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Monday, 6 of October 2008, Ingo Molnar wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > On Mon, 6 Oct 2008, Rafael J. Wysocki wrote:
> > >
> > > Unfortunately some of the recent IO-APIC changes made the bug show
> > > up. To prevent this from happening, blacklist machines that are
> > > known to be affected (nx6115 and 6715b in this particular case).
> >
> > Can you point to exactly _which_ recent change made it show up? I'd
> > really like to know. _What_ was it that made us suddenly need this
> > quirk when it wasn't necessary before? I'd like to understand the root
> > cause here.
> >
> > And how did you even start looking at that strange ACPI override?
>
> i think it was caused by this stream of IO-APIC changes:
>
> 49a66a0: x86: I/O APIC: Always report how the timer has been set up
> 17c4469: x86: I/O APIC: Include <asm/i8259.h> required by some code
> 593f4a7: x86: APIC: remove apic_write_around(); use alternatives
> ce8b06b: x86: I/O APIC: remove an IRQ2-mask hack
> af17478: x86: I/O APIC: Never configure IRQ2
> c88ac1d: x86: L-APIC: Always fully configure IRQ0
> 1baea6e: x86: L-APIC: Set IRQ0 as edge-triggered
>
> Rafael/Maciej, which of these is causing it? ce8b06b ("x86: I/O APIC:
> remove an IRQ2-mask hack")?

As I wrote to Linus, on my machine it was

commit 691874fa96d6349a8b60f8ea9c2bae52ece79941
Author: Maciej W. Rozycki <[email protected]>
Date: Tue May 27 21:19:51 2008 +0100

x86: I/O APIC: timer through 8259A second-chance

> Current theory is that this specific flavor of BIOS on HP / AMD / Turion
> laptops (no other type is known to be affected at the moment) somehow
> detects the IO-APIC masking patterns and uses an SMI quirk to change the
> ACPI thermal trip point to very low settings, and thus confusing cpufreq
> to (correctly) go into a very slow frequency.
>
> Activating the quirk works this around. Should we perhaps default to
> this 'quirk' enabled by default?

Well, I don't know.

Thanks,
Rafael

2008-10-06 17:55:47

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

* Maciej W. Rozycki <[email protected]> wrote:

> On Mon, 6 Oct 2008, Ingo Molnar wrote:
>
> > i think it was caused by this stream of IO-APIC changes:
> >
> > 49a66a0: x86: I/O APIC: Always report how the timer has been set up
> > 17c4469: x86: I/O APIC: Include <asm/i8259.h> required by some code
> > 593f4a7: x86: APIC: remove apic_write_around(); use alternatives
> > ce8b06b: x86: I/O APIC: remove an IRQ2-mask hack
> > af17478: x86: I/O APIC: Never configure IRQ2
> > c88ac1d: x86: L-APIC: Always fully configure IRQ0
> > 1baea6e: x86: L-APIC: Set IRQ0 as edge-triggered
> >
> > Rafael/Maciej, which of these is causing it? ce8b06b ("x86: I/O APIC:
> > remove an IRQ2-mask hack")?
>
> None of the above. This:
>
> 691874f: x86: I/O APIC: timer through 8259A second-chance
>
> This change has fixed a problem with the timer for a lot of systems
> and permitted the removal of a bunch of horrible hacks we used to have
> in our I/O-APIC/timer code, including a command-line override
> parameter, needed so that some systems would boot at all.
>
> This single instance of a piece of some HP gear being twisted beyond
> belief is IMO a minor annoyance and price to pay compared to the gain.
> Please note that apart from the DSDT being buggy on this machine, it
> has an incorrect IRQ 0 override in the ACPI table pointing to the pin
> #2 of the I/O APIC, which is in fact routed to the output of the
> master 8259A. Additionally the pin #0 of the I/O APIC which is indeed
> routed to the output of the 8254 does not receive any interrupts,
> presumably because of some misconfiguration during BIOS
> initialisation. So in fact this machine suffers from three
> configuration problems at once of which all add up to the end result
> we can observe.

okay. Perhaps we can find some better DMI filter for affected
HP+AMD+Turion laptops - how futile that might be. No chance to have some
automated non-DMI check?

Ingo

2008-10-06 18:21:31

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Mon, 6 Oct 2008, Rafael J. Wysocki wrote:

> It appears that the buggy BIOS code has been copy-pasted to the entire range of
> machines, for no good reason.

The DSDT is specific to the chipset -- the ATI/AMD SB400 southbridge in
this case -- there is no need to change it for any changes in the
surrounding hardware components.

Maciej

2008-10-06 18:21:44

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Mon, 6 Oct 2008, Ingo Molnar wrote:

> i think it was caused by this stream of IO-APIC changes:
>
> 49a66a0: x86: I/O APIC: Always report how the timer has been set up
> 17c4469: x86: I/O APIC: Include <asm/i8259.h> required by some code
> 593f4a7: x86: APIC: remove apic_write_around(); use alternatives
> ce8b06b: x86: I/O APIC: remove an IRQ2-mask hack
> af17478: x86: I/O APIC: Never configure IRQ2
> c88ac1d: x86: L-APIC: Always fully configure IRQ0
> 1baea6e: x86: L-APIC: Set IRQ0 as edge-triggered
>
> Rafael/Maciej, which of these is causing it? ce8b06b ("x86: I/O APIC:
> remove an IRQ2-mask hack")?

None of the above. This:

691874f: x86: I/O APIC: timer through 8259A second-chance

This change has fixed a problem with the timer for a lot of systems and
permitted the removal of a bunch of horrible hacks we used to have in our
I/O-APIC/timer code, including a command-line override parameter, needed
so that some systems would boot at all.

This single instance of a piece of some HP gear being twisted beyond
belief is IMO a minor annoyance and price to pay compared to the gain.
Please note that apart from the DSDT being buggy on this machine, it has
an incorrect IRQ 0 override in the ACPI table pointing to the pin #2 of
the I/O APIC, which is in fact routed to the output of the master 8259A.
Additionally the pin #0 of the I/O APIC which is indeed routed to the
output of the 8254 does not receive any interrupts, presumably because of
some misconfiguration during BIOS initialisation. So in fact this machine
suffers from three configuration problems at once of which all add up to
the end result we can observe.

> Current theory is that this specific flavor of BIOS on HP / AMD / Turion
> laptops (no other type is known to be affected at the moment) somehow
> detects the IO-APIC masking patterns and uses an SMI quirk to change the
> ACPI thermal trip point to very low settings, and thus confusing cpufreq
> to (correctly) go into a very slow frequency.

It is not just theory. I did actually analyse the AML code coming from
the broken DSDT and found the responsible snippets. See:
http://lkml.org/lkml/2008/6/20/442 for a reference. No SMI is involved
here -- this is native ACPI operation -- Linux calls these snippets
explicitly as required by the ACPI spec for various actions.

> Activating the quirk works this around. Should we perhaps default to
> this 'quirk' enabled by default?

It will break many if not most of the systems out there which have the
PIT (rather than the master 8259A) wired to the pin #2 of the I/O APIC
and correctly reported as such with an ACPI IRQ override.

Maciej

2008-10-06 19:54:25

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Mon, Oct 06, 2008 at 02:28:39AM -0400, Dmitry Torokhov wrote:
> On Sun, Oct 05, 2008 at 12:10:46PM -0700, Arjan van de Ven wrote:
> > On Sun, 5 Oct 2008 14:36:25 -0400
> > Dmitry Torokhov <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > speed, fans are constantly on, everything seems sluggish.
> > >
> > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > somewhere in tty_init.
> >
> > hpet=force is a "the kernel thinks it's not wise to use, but you think
> > better"... don't do that ;(
> >
>
> That is not how I parse dmesg:
>
> [ 0.077927] HPET not enabled in BIOS. You might try hpet=force boot
> option
>
> Here kernel recommends to try and enable it. If we generally don't recommed
> using 'force' I'd suggest removing the 2nd sentence from the message.

FYI.
Commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3 of tip/master is
needed to really enable hpet on SB400. I guess that patch should go
upstream asap -- and probably it's a good idea to add a check for timer
interrupt routing as well which could solve the issues on HP nx6xxx
laptops.

Regards,

Andreas

2008-10-06 20:59:48

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

"Maciej W. Rozycki" <[email protected]> writes:
>
> This single instance of a piece of some HP gear being twisted beyond
> belief is IMO a minor annoyance and price to pay compared to the gain.
> Please note that apart from the DSDT being buggy on this machine, it has
> an incorrect IRQ 0 override in the ACPI table pointing to the pin #2 of
> the I/O APIC, which is in fact routed to the output of the master 8259A.
> Additionally the pin #0 of the I/O APIC which is indeed routed to the
> output of the 8254 does not receive any interrupts, presumably because of
> some misconfiguration during BIOS initialisation.

The real reason is actually a workaround in the BIOS for problems
in the older Linux code that caused duplicated timer interrupts. The
old Linux would fall into "enable both IO-APIC and 8259" fallback mode
and the resulted in duplicated timer events, which made everything unhappy.
They instead configured the northbridge in a way that one of the inputs
is ignored.

You won't be able to DMI list it, that workaround is widely used
in lots of different systems.

-andi

2008-10-06 21:39:42

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Mon, 6 Oct 2008, Andi Kleen wrote:

> The real reason is actually a workaround in the BIOS for problems
> in the older Linux code that caused duplicated timer interrupts. The
> old Linux would fall into "enable both IO-APIC and 8259" fallback mode
> and the resulted in duplicated timer events, which made everything unhappy.
> They instead configured the northbridge in a way that one of the inputs
> is ignored.

Hmm, working around Linux problems in the BIOS is a new and truly odd
concept to me. It's not that we are unresponsive or do not take
responsibility for our bugs, is it?

> You won't be able to DMI list it, that workaround is widely used
> in lots of different systems.

Well, perhaps, but the thermal trip point phenomenon seems unique to this
family of systems. The other aspects of the problem do not really matter
anymore as we seem to have addressed them robustly enough now.

Maciej

2008-10-06 22:12:28

[permalink] [raw]

Subject: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

On Mon, Oct 06, 2008 at 10:39:25PM +0100, Maciej W. Rozycki wrote:
> On Mon, 6 Oct 2008, Andi Kleen wrote:
>
> > The real reason is actually a workaround in the BIOS for problems
> > in the older Linux code that caused duplicated timer interrupts. The
> > old Linux would fall into "enable both IO-APIC and 8259" fallback mode
> > and the resulted in duplicated timer events, which made everything unhappy.
> > They instead configured the northbridge in a way that one of the inputs
> > is ignored.
>
> Hmm, working around Linux problems in the BIOS is a new and truly odd
> concept to me. It's not that we are unresponsive or do not take
> responsibility for our bugs, is it?

So, let's work around BIOS bugs in Linux then ...

Following patch is almost untested -- especially I didn't get my
hands on one of the HP Laptops with broken DSDT.

Regards,

Andreas

--

On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
but the SB450 chipset is configured such that timer interrupts goe to
INT0 of IOAPIC.

Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
timer override.

Signed-off-by: Andreas Herrmann <[email protected]>
---
arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 4353cf5..6b839b1 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -95,6 +95,52 @@ static void __init nvidia_bugs(int num, int slot, int func)

}

+static u32 ati_ixp4x0_rev(int num, int slot, int func)
+{
+ u32 d;
+ u8 b;
+
+ b = read_pci_config_byte(num, slot, func, 0xac);
+ b &= ~(1<<5);
+ write_pci_config_byte(num, slot, func, 0xac, b);
+
+ d = read_pci_config(num, slot, func, 0x70);
+ d |= 1<<8;
+ write_pci_config(num, slot, func, 0x70, d);
+
+ d = read_pci_config(num, slot, func, 0x8);
+ d &= 0xff;
+ return d;
+}
+
+static void __init ati_bugs(int num, int slot, int func)
+{
+#if defined(CONFIG_ACPI) && defined (CONFIG_X86_IO_APIC)
+ u32 d;
+ u8 b;
+
+ if (acpi_use_timer_override)
+ return;
+
+ d = ati_ixp4x0_rev(num, slot, func);
+ if (d < 0x82)
+ acpi_skip_timer_override = 1;
+ else {
+ /* check for IRQ0 interrupt swap */
+ outb(0x72, 0xcd6); b = inb(0xcd7);
+ if (!(b & 0x2))
+ acpi_skip_timer_override = 1;
+ }
+
+ if (acpi_skip_timer_override) {
+ printk(KERN_INFO "SB4X0 revision 0x%x\n", d);
+ printk(KERN_INFO "Ignoring ACPI timer override.\n");
+ printk(KERN_INFO "If you got timer trouble "
+ "try acpi_use_timer_override\n");
+ }
+#endif
+}
+
#define QFLAG_APPLY_ONCE 0x1
#define QFLAG_APPLIED 0x2
#define QFLAG_DONE (QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -114,6 +160,8 @@ static struct chipset early_qrk[] __initdata = {
PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS,
+ PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
{}
};

--
1.6.0.2

2008-10-06 23:04:16

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

2008-10-07 01:35:20

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Tue, 7 Oct 2008, Andi Kleen wrote:

> > Hmm, working around Linux problems in the BIOS is a new and truly odd
> > concept to me.
>
> Except perhaps for the cheapest consumer parts and many laptops Linux is
> definitely on the radar now for many BIOS developers.

That's not my point.

> > It's not that we are unresponsive or do not take
> > responsibility for our bugs, is it?
>
> These workarounds are not for mainline kernels but for specific
> distribution releases (as in "fixes SLES/RHEL x.y" instead of
> "fixes 2.6.xy")

I am happy to fix any bugs I introduced myself (as much as one can be
happy about mistakes once they have discovered they made them that is) and
certainly have a look into other Linux bugs by request of any vendor of a
Linux distribution made on behalf of a hardware manufacturer.

OTOH I do not feel responsible even a little bit for someone else's bugs
like those of BIOS developers. Though I will certainly consider providing
them with any assistance needed to get things related to Linux resolved in
a best possible way if they ask nicely.

> Even when the distributors update their kernels the old releases
> do not go away are still used and the workarounds get in.

It is not unreasonable to require a version of a distribution that is
current at the time a piece of hardware has been released. Hardware
vendors only support certain versions of certain operating systems if any
at all and Linux makes no difference here. Except from the bureaucracy
needed, or actually the lack of, to get something we have done wrong
rectified. The community may support anything beyond that of course, like
running Linux 1.2.13 on that brand new server.

> > Well, perhaps, but the thermal trip point phenomenon seems unique to this
> > family of systems. The other aspects of the problem do not really matter
> > anymore as we seem to have addressed them robustly enough now.
>
> When you need DMI entries you clearly haven't.

You can't just break a piece of hardware randomly (setting the thermal
trip points based on an interrupt mask of an I/O APIC input is certainly
beyond the ACPI spec), hide its documentation and still demand it to be
supported correctly, possibly hurting all the other good equipment.
Sorry -- you have to draw a line somewhere. Others seem to agree as
otherwise we wouldn't have DMI matching in the first place. The same
applies to PCI quirks. And command line arguments to activate workarounds
are worse yet, but we do have them too. We wouldn't need any of these if
all the hardware was built to the relevant specs.

Maciej

2008-10-07 03:42:17

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

* Andreas Herrmann <[email protected]> wrote:

> So, let's work around BIOS bugs in Linux then ...
>
> Following patch is almost untested -- especially I didn't get my hands
> on one of the HP Laptops with broken DSDT.
[...]
> On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
> but the SB450 chipset is configured such that timer interrupts goe to
> INT0 of IOAPIC.
>
> Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
> timer override.
>
> Signed-off-by: Andreas Herrmann <[email protected]>
>
> ---
> arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 48 insertions(+), 0 deletions(-)

very nice, thanks Andreas! Applied to tip/x86/quirks. This PCI ID based
quirk should be more complete than DMI matches.

Ingo

2008-10-07 03:42:53

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Mon, Oct 06, 2008 at 09:53:50PM +0200, Andreas Herrmann wrote:
> On Mon, Oct 06, 2008 at 02:28:39AM -0400, Dmitry Torokhov wrote:
> > On Sun, Oct 05, 2008 at 12:10:46PM -0700, Arjan van de Ven wrote:
> > > On Sun, 5 Oct 2008 14:36:25 -0400
> > > Dmitry Torokhov <[email protected]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > speed, fans are constantly on, everything seems sluggish.
> > > >
> > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > somewhere in tty_init.
> > >
> > > hpet=force is a "the kernel thinks it's not wise to use, but you think
> > > better"... don't do that ;(
> > >
> >
> > That is not how I parse dmesg:
> >
> > [ 0.077927] HPET not enabled in BIOS. You might try hpet=force boot
> > option
> >
> > Here kernel recommends to try and enable it. If we generally don't recommed
> > using 'force' I'd suggest removing the 2nd sentence from the message.
>
> FYI.
> Commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3 of tip/master is
> needed to really enable hpet on SB400. I guess that patch should go
> upstream asap -- and probably it's a good idea to add a check for timer
> interrupt routing as well which could solve the issues on HP nx6xxx
> laptops.
>

Having trouble locating this one. Could you please send me a patch so I
can try it here? Thanks!

--
Dmitry

2008-10-07 03:51:46

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

On Tue, Oct 07, 2008 at 05:41:32AM +0200, Ingo Molnar wrote:
>
> * Andreas Herrmann <[email protected]> wrote:
>
> > So, let's work around BIOS bugs in Linux then ...
> >
> > Following patch is almost untested -- especially I didn't get my hands
> > on one of the HP Laptops with broken DSDT.
> [...]
> > On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
> > but the SB450 chipset is configured such that timer interrupts goe to
> > INT0 of IOAPIC.
> >
> > Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
> > timer override.
> >
> > Signed-off-by: Andreas Herrmann <[email protected]>
> >
> > ---
> > arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 48 insertions(+), 0 deletions(-)
>
> very nice, thanks Andreas! Applied to tip/x86/quirks. This PCI ID based
> quirk should be more complete than DMI matches.
>

You may add 'Tested by: Dmitry Torokhov <[email protected]> on nx6115'
It works fine here with Andreas patch applied and with Rafael's patch
dropped.

Thanks Andreas!

--
Dmitry

2008-10-07 04:43:12

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

* Maciej W. Rozycki <[email protected]> wrote:

> > > Well, perhaps, but the thermal trip point phenomenon seems unique
> > > to this family of systems. The other aspects of the problem do
> > > not really matter anymore as we seem to have addressed them
> > > robustly enough now.
> >
> > When you need DMI entries you clearly haven't.
>
> You can't just break a piece of hardware randomly (setting the
> thermal trip points based on an interrupt mask of an I/O APIC input is
> certainly beyond the ACPI spec), hide its documentation and still
> demand it to be supported correctly, possibly hurting all the other
> good equipment. Sorry -- you have to draw a line somewhere. [...]

agreed. This is a clear example of a complex and hard to track down BIOS
bug - and even in this case we go out on a limb working it around.

The first approach to such problems is usually a DMI pattern based fix -
they happen when we dont know the full scope of a particular problem yet
but have a rough idea and want to react to bugs quickly.

PCI ID based quirks are preferred much more in the long run: DMI pattern
matching does not scale as the DMI space is human-visible and hence
changes frequently not for technical/hw-environment but for
perception/PR reasons, hence it is far less reliable programmatically
than the PCI ID space.

But PCI ID methods, while more intelligent, they lag behind a bit and
depend on good cooperation with hw makers. As long as DMI pattern
matches end up turning into PCI ID based approaches, like here, i'm not
complaining as a maintainer ;)

Thanks Maciej for your excellent in-depth analysis of this issue, and
for your many fixes in this area of code - you squashed many difficult,
long-standing bugs in this space.

Ingo

2008-10-07 04:58:29

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

* Dmitry Torokhov <[email protected]> wrote:

> On Tue, Oct 07, 2008 at 05:41:32AM +0200, Ingo Molnar wrote:
> >
> > * Andreas Herrmann <[email protected]> wrote:
> >
> > > So, let's work around BIOS bugs in Linux then ...
> > >
> > > Following patch is almost untested -- especially I didn't get my hands
> > > on one of the HP Laptops with broken DSDT.
> > [...]
> > > On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
> > > but the SB450 chipset is configured such that timer interrupts goe to
> > > INT0 of IOAPIC.
> > >
> > > Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
> > > timer override.
> > >
> > > Signed-off-by: Andreas Herrmann <[email protected]>
> > >
> > > ---
> > > arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
> > > 1 files changed, 48 insertions(+), 0 deletions(-)
> >
> > very nice, thanks Andreas! Applied to tip/x86/quirks. This PCI ID based
> > quirk should be more complete than DMI matches.
> >
>
> You may add 'Tested by: Dmitry Torokhov <[email protected]> on nx6115'
> It works fine here with Andreas patch applied and with Rafael's patch
> dropped.
>
> Thanks Andreas!

ok, added your Tested-by to the changelog, thanks.

I also applied the patch below to deprioritize the DMI quirks for this
problem (without actually removing them, yet). Could you please check
whether latest tip/master:

http://people.redhat.com/mingo/tip.git/README

boots fine out of box and that the WARN() does not trigger?

Ingo

--------------->
>From 8d89adf44cf750e49691ba5b744b2ad77a05e997 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Tue, 7 Oct 2008 06:47:52 +0200
Subject: [PATCH] x86: SB450: deprioritize DMI quirks

This PCI ID based quick should be a full solution for the IRQ0 override
related slowdown problem on SB450 based systems:

33fb0e4: x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

Emit a warning in those cases where the DMI quirk triggers but
the PCI ID based quirk didnt.

If this warning does not trigger then we can phase out the DMI quirks.

Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/acpi/boot.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index c102af8..096102d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1421,8 +1421,16 @@ static int __init force_acpi_ht(const struct dmi_system_id *d)
*/
static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
{
- pr_notice("%s detected: Ignoring BIOS IRQ0 pin2 override\n", d->ident);
- acpi_skip_timer_override = 1;
+ /*
+ * The ati_ixp4x0_rev() early PCI quirk should have set
+ * the acpi_skip_timer_override flag already:
+ */
+ if (!acpi_skip_timer_override) {
+ WARN(1, KERN_ERR "ati_ixp4x0 quirk not complete.\n");
+ pr_notice("%s detected: Ignoring BIOS IRQ0 pin2 override\n",
+ d->ident);
+ acpi_skip_timer_override = 1;
+ }
return 0;
}

2008-10-07 05:32:18

by Andi Kleen

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Tue, Oct 07, 2008 at 02:35:01AM +0100, Maciej W. Rozycki wrote:
>
> > > It's not that we are unresponsive or do not take
> > > responsibility for our bugs, is it?
> >
> > These workarounds are not for mainline kernels but for specific
> > distribution releases (as in "fixes SLES/RHEL x.y" instead of
> > "fixes 2.6.xy")
>
> I am happy to fix any bugs I introduced myself (as much as one can be
> happy about mistakes once they have discovered they made them that is) and
> certainly have a look into other Linux bugs by request of any vendor of a
> Linux distribution made on behalf of a hardware manufacturer.
>
> OTOH I do not feel responsible even a little bit for someone else's bugs
> like those of BIOS developers. Though I will certainly consider providing
> them with any assistance needed to get things related to Linux resolved in
> a best possible way if they ask nicely.

To be honest I think you have a unrealistic approach to this.
That is not how it works.

For the BIOS developers OS are like some piece of random hardware
ot a OS developer. If something doesn't work and if they care
they will add a workaround. Just as the OS developer adds a workaround
for the hardware issue. And yes workarounds are typically not pretty.
And sometimes the workaround come later back to bite someone That is what
happened here. But they still have to support the old releases if they
worked before, otherwise they got a regression too.

Using a PCI ID quirk to disable the workaround is a reasonable
approach, although it has its issues too.

Also calling the workaround a BIOS bug is just unfair in this case. It really
isn't.

> > > Well, perhaps, but the thermal trip point phenomenon seems unique to this
> > > family of systems. The other aspects of the problem do not really matter
> > > anymore as we seem to have addressed them robustly enough now.
> >
> > When you need DMI entries you clearly haven't.
>
> You can't just break a piece of hardware randomly (setting the thermal
> trip points based on an interrupt mask of an I/O APIC input is certainly
> beyond the ACPI spec), hide its documentation and still demand it to be
> supported correctly, possibly hurting all the other good equipment.
> Sorry -- you have to draw a line somewhere. Others seem to agree as

Well you can blame everyone else, but it doesn't change the fact that
if systems who worked before don't work anymore you've caused regressions.
Which seems to be the case here.

-Andi
--
[email protected]

2008-10-07 09:12:14

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

>On Mon, Oct 06, 2008 at 11:42:35PM -0400, Dmitry Torokhov wrote:
> On Mon, Oct 06, 2008 at 09:53:50PM +0200, Andreas Herrmann wrote:
> > On Mon, Oct 06, 2008 at 02:28:39AM -0400, Dmitry Torokhov wrote:
> > > On Sun, Oct 05, 2008 at 12:10:46PM -0700, Arjan van de Ven wrote:
> > > > On Sun, 5 Oct 2008 14:36:25 -0400
> > > > Dmitry Torokhov <[email protected]> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Lats night I loaded 2.6.27-rc8-tip for the first time on my AMD Turion
> > > > > 64 laptop that is normally runs with Fedora distribution kernel.
> > > > > Compared to 2.6.25 the thing is broken - hdparm reports about 3MB/sec
> > > > > speed, fans are constantly on, everything seems sluggish.
> > > > >
> > > > > Booting with hpet=force (HPET is disabled in BIOS) hangs the box
> > > > > somewhere in tty_init.
> > > >
> > > > hpet=force is a "the kernel thinks it's not wise to use, but you think
> > > > better"... don't do that ;(
> > > >
> > >
> > > That is not how I parse dmesg:
> > >
> > > [ 0.077927] HPET not enabled in BIOS. You might try hpet=force boot
> > > option
> > >
> > > Here kernel recommends to try and enable it. If we generally don't recommed
> > > using 'force' I'd suggest removing the 2nd sentence from the message.
> >
> > FYI.
> > Commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3 of tip/master is
> > needed to really enable hpet on SB400. I guess that patch should go
> > upstream asap -- and probably it's a good idea to add a check for timer
> > interrupt routing as well which could solve the issues on HP nx6xxx
> > laptops.
> >
>
> Having trouble locating this one. Could you please send me a patch so I
> can try it here? Thanks!

Here it is.

commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3
Author: Andreas Herrmann <[email protected]>
Date: Fri Sep 5 18:33:26 2008 +0200

x86: hpet: modify IXP400 quirk to enable interrupts

The current quirk is incomplete. Some more chipset fiddling has to be
done to enable HPET interrupts. This patch aims to do this. From my
tests it seems to work faultlessly.

But the official statement is that HPET is not supported on SB4X0.

Users will still have to use hpet=force to enable it.

Use it at your own risk.

Signed-off-by: Andreas Herrmann <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index d138588..f6a11b9 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -354,9 +354,27 @@ static void ati_force_hpet_resume(void)
printk(KERN_DEBUG "Force enabled HPET at resume\n");
}

+static u32 ati_ixp4x0_rev(struct pci_dev *dev)
+{
+ u32 d;
+ u8 b;
+
+ pci_read_config_byte(dev, 0xac, &b);
+ b &= ~(1<<5);
+ pci_write_config_byte(dev, 0xac, b);
+ pci_read_config_dword(dev, 0x70, &d);
+ d |= 1<<8;
+ pci_write_config_dword(dev, 0x70, d);
+ pci_read_config_dword(dev, 0x8, &d);
+ d &= 0xff;
+ dev_printk(KERN_DEBUG, &dev->dev, "SB4X0 revision 0x%x\n", d);
+ return d;
+}
+
static void ati_force_enable_hpet(struct pci_dev *dev)
{
- u32 uninitialized_var(val);
+ u32 d, val;
+ u8 b;

if (hpet_address || force_hpet_address)
return;
@@ -366,14 +384,33 @@ static void ati_force_enable_hpet(struct pci_dev *dev)
return;
}

+ d = ati_ixp4x0_rev(dev);
+ if (d < 0x82)
+ return;
+
+ /* base address */
pci_write_config_dword(dev, 0x14, 0xfed00000);
pci_read_config_dword(dev, 0x14, &val);
+
+ /* enable interrupt */
+ outb(0x72, 0xcd6); b = inb(0xcd7);
+ b |= 0x1;
+ outb(0x72, 0xcd6); outb(b, 0xcd7);
+ outb(0x72, 0xcd6); b = inb(0xcd7);
+ if (!(b & 0x1))
+ return;
+ pci_read_config_dword(dev, 0x64, &d);
+ d |= (1<<10);
+ pci_write_config_dword(dev, 0x64, d);
+ pci_read_config_dword(dev, 0x64, &d);
+ if (!(d & (1<<10)))
+ return;
+
force_hpet_address = val;
force_hpet_resume_type = ATI_FORCE_HPET_RESUME;
dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at 0x%lx\n",
force_hpet_address);
cached_dev = dev;
- return;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS,
ati_force_enable_hpet);

2008-10-07 11:19:44

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

On Tue, Oct 07, 2008 at 06:57:57AM +0200, Ingo Molnar wrote:
>
> * Dmitry Torokhov <[email protected]> wrote:
>
> > On Tue, Oct 07, 2008 at 05:41:32AM +0200, Ingo Molnar wrote:
> > >
> > > * Andreas Herrmann <[email protected]> wrote:
> > >
> > > > So, let's work around BIOS bugs in Linux then ...
> > > >
> > > > Following patch is almost untested -- especially I didn't get my hands
> > > > on one of the HP Laptops with broken DSDT.
> > > [...]
> > > > On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
> > > > but the SB450 chipset is configured such that timer interrupts goe to
> > > > INT0 of IOAPIC.
> > > >
> > > > Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
> > > > timer override.
> > > >
> > > > Signed-off-by: Andreas Herrmann <[email protected]>
> > > >
> > > > ---
> > > > arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
> > > > 1 files changed, 48 insertions(+), 0 deletions(-)
> > >
> > > very nice, thanks Andreas! Applied to tip/x86/quirks. This PCI ID based
> > > quirk should be more complete than DMI matches.
> > >
> >
> > You may add 'Tested by: Dmitry Torokhov <[email protected]> on nx6115'
> > It works fine here with Andreas patch applied and with Rafael's patch
> > dropped.
> >
> > Thanks Andreas!
>
> ok, added your Tested-by to the changelog, thanks.
>
> I also applied the patch below to deprioritize the DMI quirks for this
> problem (without actually removing them, yet). Could you please check
> whether latest tip/master:
>
> http://people.redhat.com/mingo/tip.git/README
>
> boots fine out of box and that the WARN() does not trigger?
>

While I did not test tip/master I applied this patch on top of Andreas's
patch and the warning, as expected, did not trigger.

--
Dmitry

2008-10-07 11:38:03

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Tue, Oct 07, 2008 at 11:10:32AM +0200, Andreas Herrmann wrote:
> >On Mon, Oct 06, 2008 at 11:42:35PM -0400, Dmitry Torokhov wrote:
> > On Mon, Oct 06, 2008 at 09:53:50PM +0200, Andreas Herrmann wrote:
> > >
> > > FYI.
> > > Commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3 of tip/master is
> > > needed to really enable hpet on SB400. I guess that patch should go
> > > upstream asap -- and probably it's a good idea to add a check for timer
> > > interrupt routing as well which could solve the issues on HP nx6xxx
> > > laptops.
> > >
> >
> > Having trouble locating this one. Could you please send me a patch so I
> > can try it here? Thanks!
>
> Here it is.
>

Hmm, that unfortunately does not work because I have SB4X0 revision 0x11
and the patch cuts off everything below 0x82. Is there anything that can
be done to enable HPET on early revisions?

Thanks.

--
Dmitry

2008-10-07 11:45:49

by Matthew Garrett

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

On Tue, Oct 07, 2008 at 07:38:08AM +0200, Andi Kleen wrote:

> Also calling the workaround a BIOS bug is just unfair in this case. It really
> isn't.

The BIOS bug in these machines is that they set the thermal trip points
to 16 degrees C if the APIC is set up in a specific way. It's specific
to the HPs and it was there in the initial BIOS release - before anyone
added workarounds for the SB700 issue. It's clearly and unambiguously
broken, and it's clearly the BIOS's fault. However, it's also clearly
our responsibility to avoid triggering it on this hardware.

--
Matthew Garrett | [email protected]

2008-10-07 12:04:55

[permalink] [raw]

Subject: Re: [PATCH] x86 ACPI: Blacklist two HP machines with buggy BIOSes (Re: 2.6.27-rc8+ - first impressions)

* Andi Kleen <[email protected]> wrote:

> On Tue, Oct 07, 2008 at 02:35:01AM +0100, Maciej W. Rozycki wrote:
> >
> > > > It's not that we are unresponsive or do not take
> > > > responsibility for our bugs, is it?
> > >
> > > These workarounds are not for mainline kernels but for specific
> > > distribution releases (as in "fixes SLES/RHEL x.y" instead of
> > > "fixes 2.6.xy")
> >
> > I am happy to fix any bugs I introduced myself (as much as one can
> > be happy about mistakes once they have discovered they made them
> > that is) and certainly have a look into other Linux bugs by request
> > of any vendor of a Linux distribution made on behalf of a hardware
> > manufacturer.
> >
> > OTOH I do not feel responsible even a little bit for someone else's
> > bugs like those of BIOS developers. Though I will certainly
> > consider providing them with any assistance needed to get things
> > related to Linux resolved in a best possible way if they ask nicely.
>
> To be honest I think you have a unrealistic approach to this. That is
> not how it works.
>
> For the BIOS developers OS are like some piece of random hardware ot a
> OS developer. If something doesn't work and if they care they will add
> a workaround. Just as the OS developer adds a workaround for the
> hardware issue. And yes workarounds are typically not pretty. And
> sometimes the workaround come later back to bite someone That is what
> happened here. But they still have to support the old releases if they
> worked before, otherwise they got a regression too.
>
> Using a PCI ID quirk to disable the workaround is a reasonable
> approach, although it has its issues too.
>
> Also calling the workaround a BIOS bug is just unfair in this case. It
> really isn't.

The BIOS causes all thermal trip points to be 16C when the kernel pokes
the IO-APIC pins, causing the system to be very slow and causing the CPU
fan to spin like mad. That is utterly broken. So stop wasting our time
with your stupid nonsense.

Ingo

2008-10-07 12:07:59

by Parag Warudkar

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Tue, Oct 7, 2008 at 7:37 AM, Dmitry Torokhov
<[email protected]> wrote:
> Hmm, that unfortunately does not work because I have SB4X0 revision 0x11
> and the patch cuts off everything below 0x82. Is there anything that can
> be done to enable HPET on early revisions?
>

Later BIOS revisions for the 6115 "enable Vista support" which
actually means HPET is properly enabled in BIOS for Vista to work.
(i.e. there won't be a need to force enable it with later BIOS versions.)

Any reason you could not try the BIOS upgrade I pointed out earlier?

Parag

2008-10-07 13:20:33

[permalink] [raw]

Subject: Re: 2.6.27-rc8+ - first impressions

On Tue, Oct 07, 2008 at 07:37:47AM -0400, Dmitry Torokhov wrote:
> On Tue, Oct 07, 2008 at 11:10:32AM +0200, Andreas Herrmann wrote:
> > >On Mon, Oct 06, 2008 at 11:42:35PM -0400, Dmitry Torokhov wrote:
> > > On Mon, Oct 06, 2008 at 09:53:50PM +0200, Andreas Herrmann wrote:
> > > >
> > > > FYI.
> > > > Commit e7250b8ae3870f37f660c2f65cafcaba85e3bfd3 of tip/master is
> > > > needed to really enable hpet on SB400. I guess that patch should go
> > > > upstream asap -- and probably it's a good idea to add a check for timer
> > > > interrupt routing as well which could solve the issues on HP nx6xxx
> > > > laptops.
> > > >
> > >
> > > Having trouble locating this one. Could you please send me a patch so I
> > > can try it here? Thanks!
> >
> > Here it is.
> >
>
> Hmm, that unfortunately does not work because I have SB4X0 revision 0x11
> and the patch cuts off everything below 0x82. Is there anything that can
> be done to enable HPET on early revisions?

No, sorry.
It won't work as interrupts won't properly delivered.

Regards,

Andreas

2008-10-07 15:26:09

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

On Tue, 7 Oct 2008, Andreas Herrmann wrote:

> Following patch is almost untested -- especially I didn't get my
> hands on one of the HP Laptops with broken DSDT.

Thanks a lot for the fix even though I cannot test it!

Maciej

2008-10-07 20:27:37

[permalink] [raw]

Subject: Re: [PATCH] x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

On Tuesday, 7 of October 2008, Andreas Herrmann wrote:
> On Mon, Oct 06, 2008 at 10:39:25PM +0100, Maciej W. Rozycki wrote:
> > On Mon, 6 Oct 2008, Andi Kleen wrote:
> >
> > > The real reason is actually a workaround in the BIOS for problems
> > > in the older Linux code that caused duplicated timer interrupts. The
> > > old Linux would fall into "enable both IO-APIC and 8259" fallback mode
> > > and the resulted in duplicated timer events, which made everything unhappy.
> > > They instead configured the northbridge in a way that one of the inputs
> > > is ignored.
> >
> > Hmm, working around Linux problems in the BIOS is a new and truly odd
> > concept to me. It's not that we are unresponsive or do not take
> > responsibility for our bugs, is it?
>
> So, let's work around BIOS bugs in Linux then ...
>
> Following patch is almost untested -- especially I didn't get my
> hands on one of the HP Laptops with broken DSDT.

The patch works on my nx6325. I removed the DMI workarouds for this test, so
I'm quite sure. :-)

You can add my Tested-by to it too.

Thanks,
Rafael

> --
>
> On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
> but the SB450 chipset is configured such that timer interrupts goe to
> INT0 of IOAPIC.
>
> Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
> timer override.
>
> Signed-off-by: Andreas Herrmann <[email protected]>
> ---
> arch/x86/kernel/early-quirks.c | 48 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 4353cf5..6b839b1 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -95,6 +95,52 @@ static void __init nvidia_bugs(int num, int slot, int func)
>
> }
>
> +static u32 ati_ixp4x0_rev(int num, int slot, int func)
> +{
> + u32 d;
> + u8 b;
> +
> + b = read_pci_config_byte(num, slot, func, 0xac);
> + b &= ~(1<<5);
> + write_pci_config_byte(num, slot, func, 0xac, b);
> +
> + d = read_pci_config(num, slot, func, 0x70);
> + d |= 1<<8;
> + write_pci_config(num, slot, func, 0x70, d);
> +
> + d = read_pci_config(num, slot, func, 0x8);
> + d &= 0xff;
> + return d;
> +}
> +
> +static void __init ati_bugs(int num, int slot, int func)
> +{
> +#if defined(CONFIG_ACPI) && defined (CONFIG_X86_IO_APIC)
> + u32 d;
> + u8 b;
> +
> + if (acpi_use_timer_override)
> + return;
> +
> + d = ati_ixp4x0_rev(num, slot, func);
> + if (d < 0x82)
> + acpi_skip_timer_override = 1;
> + else {
> + /* check for IRQ0 interrupt swap */
> + outb(0x72, 0xcd6); b = inb(0xcd7);
> + if (!(b & 0x2))
> + acpi_skip_timer_override = 1;
> + }
> +
> + if (acpi_skip_timer_override) {
> + printk(KERN_INFO "SB4X0 revision 0x%x\n", d);
> + printk(KERN_INFO "Ignoring ACPI timer override.\n");
> + printk(KERN_INFO "If you got timer trouble "
> + "try acpi_use_timer_override\n");
> + }
> +#endif
> +}
> +
> #define QFLAG_APPLY_ONCE 0x1
> #define QFLAG_APPLIED 0x2
> #define QFLAG_DONE (QFLAG_APPLY_ONCE|QFLAG_APPLIED)
> @@ -114,6 +160,8 @@ static struct chipset early_qrk[] __initdata = {
> PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
> { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
> PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
> + { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS,
> + PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
> {}
> };
>

2008-10-08 01:08:15