Thomas, this looks like one for you.

This is probably an X60, not a T60?

*** This bug has been marked as a duplicate of 177963 ***

Of course this is not an Lenovo X60s, it is a HP nx9420 as stated in comment #1...

For acpidump, dmesg info see #177963:

*** Before cpufreq_verify_within_limits()
    policy->min: 1000000
    policy->max: 1333000
    ppc:         1
    ppc_freq:    1333000

The ppc value (processor performance count) is the value that limits the freq. The value "1" means the highest freq (0) is disabled by BIOS.

I had a quick look in acpidump. There are no obvious compile errors. CPU0/1.PPC is returning the value of C009. Argh, this getting too complicated as the disassmbled stuff doesn't contain any meaning names. I expect it slips into:
              If (LLess (C000, Local1))
                {
                    Add (C000, 0x01, C000)
                }
in C009. C000 is the returned PPC value which is increased in this if/else path by one. This could be verified by adding stuff like e.g.:
     Store (C000, debug)
in this function which is then showed in the kernel syslog when ACPI_DEBUG is compiled into the kernel and the recompiled DSDT is attached to initrd.
Some doku how to do that can be found here:
http://suse.osuosl.org/people/trenn/powersave_documentation/DSDT.html#DSDT

For me this also looks like a BIOS issue, but it's hard to say.
I also saw the INI function of the CPU object is only invoked if OS name is set to "Windows 2001 SP1". Maybe this helps you can override this via kernel boot param:
acpi_os_name="Windows 2001 SP1"

You might also want to execute acpi_listen
and tell us the output if you (un)plug AC adapter. The interesting parts are the processor events.

Hi Thomas,

I've tried acpi_os_name="Windows 2001 SP2" and acpi_os_name="Microsoft Windows NT" with no result as dmesg say in the two cases:
ACPI: Overriding _OS definition to 'Microsoft Windows NT'
 not found!

acpi_listen say NOTHING at all when you plug/unplug the AC adapter...

dmesg | grep -2i acpi say:
dmesg | grep -2i acpi
 BIOS-e820: 0000000000100000 - 000000003ffd0000 (usable)
 BIOS-e820: 000000003ffd0000 - 000000003ffe5600 (reserved)
 BIOS-e820: 000000003ffe5600 - 000000003fff8000 (ACPI NVS)
 BIOS-e820: 000000003fff8000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
--
DMI 2.4 present.
Using APIC driver default
ACPI: RSDP (v000 HP                                    ) @ 0x000f7e20
ACPI: RSDT (v001 HP     309F     0x04050620 HP   0x00000001) @ 0x3ffe5684
ACPI: FADT (v002 HP     309F     0x00000002 HP   0x00000001) @ 0x3ffe5600
ACPI: MADT (v001 HP     309F     0x00000001 HP   0x00000001) @ 0x3ffe56c4
ACPI: MCFG (v001 HP     309F     0x00000001 HP   0x00000001) @ 0x3ffe572c
ACPI: TCPA (v002 HP     309F     0x00000001 HP   0x00000001) @ 0x3ffe5768
ACPI: SSDT (v001 HP       HPQNLP 0x00000001 MSFT 0x0100000e) @ 0x3fff5356
ACPI: SSDT (v001 HP       HPQSAT 0x00000001 MSFT 0x0100000e) @ 0x3fff53af
ACPI: SSDT (v001 HP        CpuPm 0x00003000 INTL 0x20050624) @ 0x3fff5b9c
ACPI: DSDT (v001 HP       nc9700 0x00010000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:14 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:14 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
Overriding APIC driver with bigsmp
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Physflat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Built 1 zonelists
Kernel command line: root=/dev/sda2 vga=0x345    resume=/dev/sda1  splash=silent acpi_os_name="Microsoft Windows NT"
bootsplash: silent mode.
Enabling fast FPU save and restore... done.
--
checking if image is initramfs... it is
Freeing initrd memory: 2410k freed
ACPI: Overriding _OS definition to 'Microsoft Windows NT'
 not found!
CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
--
HP Compaq Laptop series board detected. Selecting BIOS-method for reboots.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0322, last bus=32
PCI: Using configuration type 1
ACPI: Subsystem revision 20060127
ACPI Error (evgpeblk-0284): Unknown GPE method type: C345 (name not of form _Lxx or _Exx) [20060127]
ACPI Error (evgpeblk-0284): Unknown GPE method type: C238 (name not of form _Lxx or _Exx) [20060127]
ACPI Error (evgpeblk-0284): Unknown GPE method type: C346 (name not of form _Lxx or _Exx) [20060127]
ACPI Error (evgpeblk-0284): Unknown GPE method type: C347 (name not of form _Lxx or _Exx) [20060127]
ACPI Error (evgpeblk-0284): Unknown GPE method type: C26C (name not of form _Lxx or _Exx) [20060127]
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [C003] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.C003] bus is 0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:01:00.0
--
PCI: Bus #03 (-#06) is hidden behind transparent bridge #02 (-#03) (try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.C003._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C07F._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C094._PRT]
ACPI: Embedded Controller [C006] (gpe 22) interrupt mode.
ACPI Exception (acpi_bus-0072): AE_NOT_FOUND, No context for object [dffe6580] [20060127]
ACPI: Power Resource [C211] (on)
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C0FD._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C10D._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.C003.C113._PRT]
ACPI: Power Resource [C219] (on)
ACPI: PCI Interrupt Link [C109] (IRQs *10 11)
ACPI: PCI Interrupt Link [C10A] (IRQs *10 11)
ACPI: PCI Interrupt Link [C10B] (IRQs 10 *11)
ACPI: PCI Interrupt Link [C10C] (IRQs 10 11) *5
ACPI: PCI Interrupt Link [C125] (IRQs *10 11)
ACPI: PCI Interrupt Link [C126] (IRQs *10 11)
ACPI: PCI Interrupt Link [C127] (IRQs 10 *11)
ACPI Exception (pci_link-0182): AE_NOT_FOUND, Evaluating _PRS [20060127]
ACPI: Power Resource [C310] (off)
ACPI: Power Resource [C311] (off)
ACPI: Power Resource [C312] (off)
ACPI: Power Resource [C313] (off)
ACPI: Power Resource [C314] (off)
ACPI: Power Resource [C315] (off)
ACPI: Power Resource [C316] (off)
ACPI: Power Resource [C317] (off)
ACPI: Power Resource [C318] (off)
ACPI: Power Resource [C319] (off)
ACPI: Power Resource [C31A] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
--
  MEM window: f4200000-f45fffff
  PREFETCH window: 50000000-51ffffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1c.1 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 18 (level, low) -> IRQ 201
apm: BIOS not found.
audit: initializing netlink socket (disabled)
--
io scheduler deadline registered
io scheduler cfq registered (default)
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
--
NET: Registered protocol family 1
Using IPI No-Shortcut mode
ACPI wakeup devices:
C094 C0F3 C0F4 C0F5 C0F6 C0FD C21A C10D C225 C113 C226
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 188k freed
Write protecting the kernel read-only data: 287k
--
input: SynPS/2 Synaptics TouchPad as /class/input/input2
ICH7: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 177
ICH7: chipset revision 1
ICH7: not 100% native mode: will probe irqs later
--
libata version 1.20 loaded.
ahci 0000:00:1f.2: version 1.2
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 21 (level, low) -> IRQ 58
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode
--
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: CPU1 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU1] (supports 8 throttling states)
ACPI: Thermal Zone [TZ0] (57 C)
ACPI: Thermal Zone [TZ1] (47 C)
ACPI: Thermal Zone [TZ2] (55 C)
ACPI: Thermal Zone [TZ3] (44 C)
ACPI: Thermal Zone [TZ4] (33 C)
ACPI: Thermal Zone [TZ5] (23 C)
ACPI: Fan [C31B] (off)
ACPI: Fan [C31C] (off)
ACPI: Fan [C31D] (off)
ACPI: Fan [C31E] (off)
ACPI: Fan [C31F] (off)
ACPI: Fan [C320] (off)
ACPI: Fan [C321] (off)
ACPI: Fan [C322] (off)
ACPI: Fan [C323] (off)
ACPI: Fan [C324] (on)
ACPI: Fan [C325] (off)
Attempting manual resume
ReiserFS: sda2: found reiserfs format "3.6" with standard journal
--
agpgart: AGP aperture is 256M @ 0x0
tg3.c:v3.49 (Feb 2, 2006)
ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:08:00.0 to 64
eth0: Tigon3 [partno(BCM95751M) rev 4201 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:0f:b0:fa:10:f6
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
ACPI: PCI Interrupt 0000:02:06.1[B] -> <6>ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 74
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
--
hub 1-0:1.0: 2 ports detected
GSI 19 (level, low) -> IRQ 193
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 22 (level, low) -> IRQ 82
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
--
hub 2-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 201
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
--
usb 1-1: Manufacturer: Broadcom Corp
usb 1-1: configuration #1 chosen from 1 choice
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 193
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
--
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 74
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
--
hci_usb_probe: Can't set isoc interface settings
usb 1-1: USB disconnect, address 2
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 18 (level, low) -> IRQ 201
Yenta: CardBus bridge found at 0000:02:06.0 [103c:309f]
usbcore: registered new driver hci_usb
--
pcmcia: parent PCI bridge Memory window: 0xf4200000 - 0xf45fffff
pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x51ffffff
ACPI: PCI Interrupt 0000:10:00.0[A] -> GSI 17 (level, low) -> IRQ 185
PCI: Setting latency timer of device 0000:10:00.0 to 64
ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
--
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:00:1b.0 to 64
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023f992989140c]
--
audit(1150213812.011:2): AppArmor (version 2.0-19.43r6320) initialized

ACPI: AC Adapter [C1B7] (on-line)
ACPI: Battery Slot [C1B9] (battery present)
ACPI: Battery Slot [C1B8] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C23B]
ACPI: Lid Switch [C233]
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
--
[fglrx] Maximum main memory to use for locked dma buffers: 928 MBytes.
[fglrx] module loaded - fglrx 8.25.18 [May 18 2006] on minor 0
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 177
[fglrx] total      GART = 67108864
[fglrx] free       GART = 51118080


I've tried the DSDT thing.
iasl -d dsdt.aml > dsdt.asl give an error:
dsdt.dsl     1: ACPIethod (_CRS, 0, NotSerialized)
Error    4094 -    ^ syntax error, unexpected PARSEOP_NAMESEG, expecting PARSEOP_DEFINITIONBLOCK

because of these lines (x 4 times) at the beginning of dsdt.dsl
ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]

If I remove these 4 lines and recompile
iasl -tc dsdt.dsl 
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060512 [May 26 2006]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

dsdt2.dsl  3595:                                         And (Local1, 0xFFFF)
Warning  1104 -         Result is not used, operator has no effect ^

dsdt2.dsl  4996:                     Method (_DSM, 4, NotSerialized)
Warning  1086 -                                 ^ Not all control paths return a value (_DSM)

dsdt2.dsl  4996:                     Method (_DSM, 4, NotSerialized)
Warning  1079 -                                 ^ Reserved method must return a value (_DSM)

dsdt2.dsl  7481:             Method (_WED, 1, NotSerialized)
Warning  1086 -                         ^ Not all control paths return a value (_WED)

dsdt2.dsl  7481:             Method (_WED, 1, NotSerialized)
Warning  1079 -                         ^ Reserved method must return a value (_WED)

dsdt2.dsl  9035:             Method (WMBA, 3, NotSerialized)
Warning  1086 -                         ^ Not all control paths return a value (WMBA)

dsdt2.dsl 13428:                 CreateByteField (C1E1, \_SB.C003.C004._X0F._LEN, C090)
Error    4062 -                                          Object does not exist ^  (\_SB.C003.C004._X0F._LEN)

ASL Input:  dsdt2.dsl - 13983 lines, 497969 bytes, 6389 keywords
Compilation complete. 1 Errors, 6 Warnings, 0 Remarks, 2170 Optimizations

I've tried to correct warnings and errors (except the first #1104) with the help of Google and reboot loading the new DSDT with no change except for a few new errors because it does not found _X0F._LEN (I've declared it in an EXTERNAL statement to correct the iasl error)

Hope this helps.

Philippe.

Created attachment 89180 [details]
original dsdt.asl

There already happen errors during the disassemble process (head of your .dsl file):

ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]
ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]
ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]
ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]

Could you please attach full acpidump output.
This dsdt seem to be very buggy (or you hit some ACPI kernel bug).

Especially this line:
ACPI: Embedded Controller [C006] (gpe 22) interrupt mode.
ACPI Exception (acpi_bus-0072): AE_NOT_FOUND, No context for object [dffe6580]
[20060127]

Looks like your Embedded Controller won't get used at all? In this case you won't see any AC adapter, thermal and whatever other ACPI events.

Hmm, we shouldn't mix up too much things here. It might come out in the end, that the problem described in the beginning of the bug gets fixed by fixing the DSDT table or ACPI kernel parts. Still I like you to open a new bug for that and attach acpidump there and assign it to me to avoid further confusion and to make it easy for other people popping in to concentrate on specific issues. No need to describe there everything, maybe a pointer to this bug and a title like "ACPI interpreter problem, iasl already throws errors when disassembling" should be enough.
BTW: I am very interested in this one, be sure we track this down to a BIOS or kernel error. The latter could be fixed. The first possibly with some discussion with HP.

I probably already asked: You run the latest BIOS from the vendor? If not pls upgrade before going on.

Forget the new bug, just attach it here, I still was at the X60 bug with about 40 comments... sorry.

Created attachment 89194 [details]
acpi dump

Thomas,

:-)
Yes, I run the last BIOS release (F11).
Apart of the AC plug/unplug and CPU max scaling problems, the notebook is working fine. Perhaps the battery time is a little short (2h) against specifications (3h30/4h00).
If I use the "ACPI monitor", all seems right but you may be right as cpu temps don't change...
I remember that I had to use the notebook with the battery and it detected perfectly the AC unplug (after 3-4 mn) and indicates 2 hours remaining.
So it maybe a defect of the new bios release...
Do you need I revert to the old release?

Philippe.

IMO this is a bug in the ACPICA kernel parts.

The problem seems to be that C1EF is used as a device (device (C1EF) { ... }) and as (several times) local WordField.
The device node has Path:
\_SB.C003.C004.C1EF
and (one of) the local WordField e.g.:
\_SB_.C003.C004.C1BB.C1EF

Here some relevant parts if I try to disassemble with iasl -x0x403 -d dsdt.
It's the parts when these WordFields are parsed and searched in namespace:

CreateWordField (C020, \_SB.C003.C004.C1BB.C1F5._CRS._X0D._INT, C1EB)
CreateWordField (C020, \_SB.C003.C004.C1BB.C1F5._CRS._X0E._DMA, C1EF)

C1EF already exists in upper scope (\_SB.C003.C004.C1EF):

nssearch-0475 [06] NsSearchAndEnter      : C1EE Not found in 0x6bf5a0 [Not adding]
nsaccess-0682 [05] NsLookup              : Name [C1EE] not found in scope [_SRS] 0x6bf5a0
nsaccess-0510 [05] NsLookup              : Searching relative to prefix scope [_SRS] (0x6bf5a0)
nsaccess-0619 [05] NsLookup              : Simple Pathname (1 segment, Flags=3)
  nsdump-0176 [05] NsPrintPathname       : [C1EB]
nssearch-0187 [07] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED._SRS (0x6bf5a0) For [C1EB] (Untyped)
nssearch-0245 [07] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [_SRS] 0x6bf5a0 first child (nil)
nssearch-0315 [07] NsSearchParentTree    : Searching parent [C1ED] for [C1EB]
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED (0x6bee60) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C1ED] 0x6bee60 first child 0x6bef00
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004.C1BB (0x6bb1d0) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C1BB] 0x6bb1d0 first child 0x6bb270
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004 (0x69a7d0) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C004] 0x69a7d0 first child 0x69a870
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003 (0x697380) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C003] 0x697380 first child 0x697420
nssearch-0187 [08] NsSearchNode          : Searching \_SB_ (0x680190) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [_SB_] 0x680190 first child 0x691f90
nssearch-0187 [08] NsSearchNode          : Searching \ (0x67fbc0) For [C1EB] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope ["\" ] 0x67fbc0 first child 0x680110
nssearch-0475 [06] NsSearchAndEnter      : C1EB Not found in 0x6bf5a0 [Not adding]
nsaccess-0682 [05] NsLookup              : Name [C1EB] not found in scope [_SRS] 0x6bf5a0
nsaccess-0510 [05] NsLookup              : Searching relative to prefix scope [_SRS] (0x6bf5a0)
nsaccess-0619 [05] NsLookup              : Simple Pathname (1 segment, Flags=3)
  nsdump-0176 [05] NsPrintPathname       : [C1EF]
nssearch-0187 [07] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED._SRS (0x6bf5a0) For [C1EF] (Untyped)
nssearch-0245 [07] NsSearchNode          : Name [C1EF] (Untyped) not found in search in scope [_SRS] 0x6bf5a0 first child (nil)
nssearch-0315 [07] NsSearchParentTree    : Searching parent [C1ED] for [C1EF]
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED (0x6bee60) For [C1EF] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EF] (Untyped) not found in search in scope [C1ED] 0x6bee60 first child 0x6bef00
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004.C1BB (0x6bb1d0) For [C1EF] (Untyped)
nssearch-0245 [08] NsSearchNode          : Name [C1EF] (Untyped) not found in search in scope [C1BB] 0x6bb1d0 first child 0x6bb270
nssearch-0187 [08] NsSearchNode          : Searching \_SB_.C003.C004 (0x69a7d0) For [C1EF] (Untyped)
nssearch-0218 [08] NsSearchNode          : Name [C1EF] (Device) 0x6c2d70 found in scope [C004] 0x69a7d0



 nsalloc-0317 [03] NsInstallNode         : C1F3 (BufferField) [Node 0x85a980 Owner 0] added to _CRS (Method) [Node 0x6bf6e0]
nsaccess-0510 [01] NsLookup              : Searching relative to prefix scope [_CRS] (0x6bf6e0)
nsaccess-0619 [01] NsLookup              : Simple Pathname (1 segment, Flags=3)
  nsdump-0176 [01] NsPrintPathname       : [C1EB]
nssearch-0187 [03] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED._CRS (0x6bf6e0) For [C1EB] (BufferField)
nssearch-0245 [03] NsSearchNode          : Name [C1EB] (BufferField) not found in search in scope [_CRS] 0x6bf6e0 first child 0x75d180
nssearch-0315 [03] NsSearchParentTree    : Searching parent [C1ED] for [C1EB]
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED (0x6bee60) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C1ED] 0x6bee60 first child 0x6bef00
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004.C1BB (0x6bb1d0) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C1BB] 0x6bb1d0 first child 0x6bb270
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004 (0x69a7d0) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C004] 0x69a7d0 first child 0x69a870
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003 (0x697380) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [C003] 0x697380 first child 0x697420
nssearch-0187 [04] NsSearchNode          : Searching \_SB_ (0x680190) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope [_SB_] 0x680190 first child 0x691f90
nssearch-0187 [04] NsSearchNode          : Searching \ (0x67fbc0) For [C1EB] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EB] (Untyped) not found in search in scope ["\" ] 0x67fbc0 first child 0x680110
 nsalloc-0317 [03] NsInstallNode         : C1EB (BufferField) [Node 0x85a9c0 Owner 0] added to _CRS (Method) [Node 0x6bf6e0]
nsaccess-0510 [01] NsLookup              : Searching relative to prefix scope [_CRS] (0x6bf6e0)
nsaccess-0619 [01] NsLookup              : Simple Pathname (1 segment, Flags=3)
  nsdump-0176 [01] NsPrintPathname       : [C1EF]
nssearch-0187 [03] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED._CRS (0x6bf6e0) For [C1EF] (BufferField)
nssearch-0245 [03] NsSearchNode          : Name [C1EF] (BufferField) not found in search in scope [_CRS] 0x6bf6e0 first child 0x75d180
nssearch-0315 [03] NsSearchParentTree    : Searching parent [C1ED] for [C1EF]
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004.C1BB.C1ED (0x6bee60) For [C1EF] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EF] (Untyped) not found in search in scope [C1ED] 0x6bee60 first child 0x6bef00
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004.C1BB (0x6bb1d0) For [C1EF] (Untyped)
nssearch-0245 [04] NsSearchNode          : Name [C1EF] (Untyped) not found in search in scope [C1BB] 0x6bb1d0 first child 0x6bb270
nssearch-0187 [04] NsSearchNode          : Searching \_SB_.C003.C004 (0x69a7d0) For [C1EF] (Untyped)
nssearch-0218 [04] NsSearchNode          : Name [C1EF] (Device) 0x6c2d70 found in scope [C004] 0x69a7d0
ACPI Warning (nsaccess-0716): NsLookup: Type mismatch on C1EF (Device), searching for (BufferField) [20060512]


This is sever -> Critical.
I think I could come up with a workaround like: If "type missmatch" add a new node... Hopefully Robert could help here a bit and solve this properly.

The log output is badly formatted...
What goes on here:

First parse loop:
 - C1EB is searched the namespace upwards.
 - Not found.
 - Node not added because first parse loop.

 - C1EF is searched the namespace upwards.
 - found.

Second parse loop:
 - C1EB is searched the namespace upwards.
 - Not found.
 - A new node gets added with type buffer/wordfield. Correct.

 - C1EF is searched the namespace upwards.
 - found.
 - The device node (one or two "scopes upwards") is wrongly used/assigned 
   instead of creating a new local one.

I recently fixed a couple of issues with the upsearch during disassembly. The 20060608 version of the compiler disassembles with no warnings.

Couple of other problems:

dsdt2.dsl  3595:                                         And (Local1, 0xFFFF)
Warning  1104 -         Result is not used, operator has no effect ^

This appears to be a real bug in the ASL, we recently added this warning

dsdt2.dsl 13428:                 CreateByteField (C1E1,
\_SB.C003.C004._X0F._LEN, C090)
Error    4062 -                                          Object does not exist
^  (\_SB.C003.C004._X0F._LEN)

Not sure about this one, I will investigate further.

> I recently fixed a couple of issues with the upsearch during disassembly. The
> 20060608 version of the compiler disassembles with no warnings.
But this is not only a disassembler issue, it's the same way the kernel parses this and there might be strange things happening with our ACPICA version on such double declarations?

Now there is the "merge little fixes from acpica into our kernel" problem.
I expect that this fix is too intrusive anyway for Code10 GM now.
I just had a look at the latest ACPI changelog:
kernel/people/lenb/acpi/patches/test/2.6.17/acpi-test-20060608-2.6.17-rc6.diff.gz
It seems as if there are already a lot important fixes again.
At least for SP1 we probably would like to have some of them.

Not sure whether we should just add the acpica-latest-big-feature_fixes.patch for SP1. Chances are high that some already supported machines might break.

Adding only most important fixes, requires separated patches of the latest acpica components. Len/Robert?

I checked latest ACPICA version and can confirm that now the table gets disassembled correctly (at least the double declaration issue).
Robert: Thanks for adding my "IO nameclash" and "segfault if no permissions on dsdt.dsl output file" patches. I wanted to answer on the first issue, but didn't come to it.

Phillipe: Please stay tuned. If we found out about the _LEN problem, we should (hopefully if this was the issue) be able to get your system running as wanted with a patched DSDT for now. The real fix in kernel might be backported later for some kernel update if the patches got some testing in mainline kernel.

Problem was indeed disassembler only, the namespace search was not being invoked with the correct flag.

We are moving toward a separate patch model, Len can elaborate.

The _LEN issue is a problem in the disassembler. The patch below corrects the ASL by inserting the correct scope name C340:

- CreateByteField (C1E1, \_SB.C003.C004._X0F._LEN, C090)
+ CreateByteField (C1E1, \_SB.C003.C004.C340._X0F._LEN, C090)

Thanks to all for your great work! 

Of course I stay tuned! I like very much to see the progression of the solution and how you work all together. This is very instructive! 

Some updates from HP Support forums (http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1026460&admit=-682735245+1150742016920+28353475):

- suspend2ram not working: "After a resume, upon almost any command (e.g. "ls") I obtain "Input/Output-Error" messages. The error seems to be similar as those described in  http://www.thinkwiki.org/wiki/Problems_with_SATA_and_Linux"
I suppose this is related to our problem.

- Very slow BIOS boot: "my nx 9420 is working quite well with ubuntu linux but I have a strange problem. When I've used linux, the next time I boot, it takes nearly 30 seconds to get through the bios. First I only see a blinking curser for 10 to 15 seconds and then for 10 to 15 seconds the bios with the HP logo."
I can confirm this one (maybe not so slow...) with Suse 10.1 and others too.
Siegfried adds: "Sadly, I have the same cpu freq problem with the ubuntu and the current version of the 686 ubuntu kernel"

- One comment about the cpu frequency: from Peter Paul "In my case, /proc/cpuinfo does in fact show 1333 MHz, but "powersave -r" returns 1828.785767 MHz." Same here...


I hope those give you some new information...

Philippe

Especially with the second SSDT iasl seem to have some problems.
Latest 06-08-2006 version disassembles a bit better, but still I see stuff like:

---------------------------------------
                Method (_GTF, 0, NotSerialized)
                {
                    Return (\_SB.C246)
                    C349
                    0x00
                }
---------------------------------------
I think this should be disassembled to something like:
---------------------------------------
                Method (_GTF, 0, NotSerialized)
                {
                    Return (\_SB.C246(C349,0x00)
                }
---------------------------------------
Here the byte code:
  0340: 44 52 0a 00 14 17 5f 47 54 46 00 a4 5c 2e 5f 53  DR...._GTF..\._S
  0350: 42 5f 43 32 34 36 43 33 34 39 0a 00              B_C246C349..

\_SB.C246 is in the DSDT, affected code in second SSDT.

Some lines above in the same SSDT I get:

---------------------------------------
         Store (C0E3 (0x00, 0x00, C34A, C34C, Local1), Local2)
         Store (C0E7 (0x00, 0x00, C34B, C34C, Local1, Local3), \_SB.C240)
         Local2
         Local3
         Local1
         C349
---------------------------------------
I expect it should be disassembled to:
         Store (C0E3 (0x00, 0x00, C34A, C34C, Local1), Local2)
         Store (C0E7 (0x00, 0x00, C34B, C34C, Local1), Local3)
         \_SB.C240(Local2, Local3, Local1, C349)
not sure though.

Created attachment 90581 [details]
Modified DSDT with SSDTs included

Phillipe: I do not think that this gets fixed with a 2.6.17 kernel.
You still might want to give it a try and to compile your own kernel from kernel.bugzilla.org, you can use make oldconf(ig?) to get similar compile options. But this can end up in a lot of work and reading.

Do you have a BIOS setting for cpufreq?
Can you check, that there is nothing like "Always swtich to step XY"

Can you try the attached compiled DSDT, please.
It also contains the SSDTs. I tried to get rid of all errors, only some harmless warnings left. Best is you:
  - copy the file to /etc/DSDT.aml
  - modify ACPI_DSDT="" to ACPI_DSDT="/etc/DSDT.aml"
    in /etc/sysconfig/kernel
  - mkinitrd
  - reboot (in next dmesg there must be a line that
    DSDT got overridden by kernel)

If this helps, we can be sure it was due to the ACPI parser.

If not, I will compile a kernel with ACPI and cpufreq debug included and provide you with an rpm, then we have to go on digging.

Created attachment 90610 [details]
dmesg | grep -2i acpi with new DSDT

Hi Thomas,

Tried your new DSDT with no success: same problems...
acpi_listen stay mude.
I've joined the result of dmesg | grep -2i acpi as some errors are differents.
The nx9420 (with last bios release F11) has no bios settings related to ACPI (battery, power management, etc...) that I have been able to find.

Philippe

Disassembling control method invocations for methods that are external (in another table) is extremely difficult, because there is no information in the AML to tell the disassembler how many arguments the method requires.

Basically, the disassembler often has to *guess*. The quality of that guess may vary. But, I will take a look at the cases above.

The only real solution (that I can think of) to the disassembly problem (external methods) is probably something like allowing the specification of additional tables in order to resolve the methods. 

Something like:

iasl -e dsdt.aml -d ssdt.aml

Another note: This error message was removed recently from ACPICA, it was unnecessary:

ACPI Error (evgpeblk-0284): Unknown GPE method type: C345 (name not of form
_Lxx or _Exx) [20060127]

comment #21 sounds sane. As the new acpixtract automatically extracts SSDT[1,2,..] for those could also be searched automatically for..., this isn't too difficult (hopefully), I already had a look at that code. I can implement something that loads additional SSDTs for the compiler if wanted...

Phillip: I build a kernel with acpi and cpufreq debug compiled in:
ftp.suse.com/pub/people/trenn/RC3_debug_kernel/kernel-smp-2.6.16.20-2.i586.rpm

To activate debug levels at runtime you can:

   - echo 0x1F >/proc/acpi/debug_level   (ACPI)
   - echo 7 >/sys/modules/cpufreq/debug  (or similar path for cpufreq)

To activate debug at boot time using boot params:

   - acpi_dbg_level=0x1F    (ACPI, you also might want to set log_buf_len=XY 
     bytes, e.g. 10*1024*1024 for 10MB of ring buffer)

   - cpufreq.debug=7        (cpufreq debug)

Best is you let the kernel run one time with acpi_dbg_level=0x1F and search dmesg for something strange (and/or attach it).

For debug the cpufreq stuff, I would make sure all non-necessary ACPI modules should not be loaded so that log won't be that full:

    - modify var to ACPI_MODULES="NONE" in /etc/sysconfig/powersave/common
    - remove "processor thermal fan" from INITRD_MODULES in
      /etc/sysconfig/kernel and invoke "mkinitrd"
    - stop the powersaved service to be started automatically: 
      "chkconfig powersaved off"

-> Reboot
Now you can increase ACPI/cpufreq debug levels before you try loading cpufreq modules by hand (you can do a cat /proc/acpi/debug_level and you might want to pass a higher value to that file to increase debug output (be careful, there coming tons of log lines if debug level is too high)).

Hmm, maybe best is you increase debug level of ACPI and cpufreq subsys (as described above at runtime) and then start the powersaved:

rcpowersaved start      (cpufreq modules should get loaded now and syslog should 
                         have a lot, at least more output)

Maybe you already see something suspicious, please attach dmesg output then.
Just ask if something is unclear.

David, this is about an HP nx9420.
We do not have such a system.
The BIOS rev is:
  Version: 68YAF Ver. F.11
  Release Date: 05/04/2006

Can you add some HP people who can take care that this gets fixed in the next BIOS release?

The acpi code seem to be parsed/interpreted correctly.
BUT the _PPC (Processor Performance Count) ACPI function always returns 0x1, means the highest freq is not allowed by BIOS. PPC invokes a function "C00A" were something seems to go wrong..., but I hope HP can have a look at that as this is (I doubt that Intel ACPI interpreter does something wrong here) clearly a BIOS issue.

Spec of PPC is:
allow X..n cpufreq steps.
X : returned value of PPC
n : lowest freq
if X is 0, all steps are allowed.

Phillipe: Be aware that if you upgrade your BIOS or exchange some hardware, you MUST revert the patched DSDT again. You can do that by reverting the variable in /etc/sysconfig/kernel and invoke mkinitrd. The DSDT tables could be partly generated by BIOS and the patched DSDT may not match your hardware configuration then anymore.

Thomas, the Angelfire-unit available from Holger is a nx94xx. Isn't that one usable?

Thomas,

I've restored "processor thermal fan" to INITRD_MODULES.
cpufreq is still working now, but AC state and battery state are not working. Not sure about this but I remember having AC state working with your previous DSDT at one moment (it didn't work first, but suddenly begin to work! I didn't remember having changed anything though!!!)

Philippe.

Oh yes..., please revert the:
ACPI_MODULES="NONE" and replace it with:
ACPI_MODULES=""
in /etc/sysconfig/powersave/common

Does it work again?

Thomas,

Very strange!
Just after you installed the new DSDT, my battery exhausted and the machine turned off.
So I turned it on and restored "processor thermal fan" to INITRD_MODULES and ACPI_MODULES=""
Since then I've rebooted 3 times with no change. Each time AC and battery state were failing.
This morning I have resume from suspend to disk and it is working! So I turned off the machine and boot it again: still workng perfectly!
There are some acpi errors in dmesg, mainly this one 

ACPI Error (dswload-0305): [\_SB_.C003.C0FD.C21A._EJ0] Namespace lookup failure,
 AE_ALREADY_EXISTS
ACPI Exception (psloop-0281): AE_ALREADY_EXISTS, During name lookup/catalog [200
60127]

There are some others, but from what I understand from previous post, there are cosmetic ones.

I'm not sure about the fans. They seem to be working, but I've still to stress a little the machine...

Thanks again.

Philippe

Re Comment #26: Yes, but our Anglefire unit is an early prototype.

The HP BIOS people are asking what wattage the AC adapter has (65W, 90W, 135W)?

Wattage is 90W.

comment #30:
That is strange. I reverted the renaming of C1EF, as this shouldn't affect the kernel, only the disassember and the message seems unrelated to me.
Did this also occur before?
If yes it might be worth looking at. If HP takes care about fixing the PPC issue, maybe this could also be done.

EJ0 is probably an eject function for docking station or whatever and shouldn't be used with current linux kernel (docking support comes with 2.6.17) and therefore shouldn't have any negative impact (hope it's not repeatedly logging).

Hi,

Any news / comments from HP?
Here is a small resume of the situation with the patched DSDT:
- CPUfreq is working: speed varies between 1000MHz and 1833MHz. (not sure if it is using intermediate speeds)
- Power state (battery / AC power) is working sometimes! It is actually not working but I can't see anything which could cause this behaviour...
- Fans are not working: if they start, they never stop; you have to shtdown the machine.


From HP forums: (both from Peter Paul)

- For a test, I just installed the kernel 2.6.17-AS25-smpdesk from
ftp://ftp4.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/RPMS.suser-jengelh/
* The "long boot problem" as well as the problem about the battery status not being updated seem to be fixed with this kernel.
* /proc/cpuinfo still shows the wrong frequency.
* suspend2ram now results into a hang after resume and a command which needs disk access ("ls" is o.k., but "du" not). I assume this is still the SATA problem.

- I found something out: If you turn off the computer by pressing the power button, then it doesn't end up in a "bad state". 
One way to achieve that the computer is not switched off after calling "halt" or "shutdown" is to add a line at line 53 of /etc/init.d/halt (the line after the esac) as follows:

command="halt"
(this overrides the previous value of "halt -p")

Then the computer won't be switched off after "halt" and just ends up in a halting state. So you can switch it off manually and it will remain in a "good state" for the next boot.

It seems that the kernel-command which actually turns the computer off (probably some ACPI command) is responsible for the "bad state"...


Hope it helps!


Philippe.

> Any news / comments from HP?
Seems as if not, David?

> Here is a small resume of the situation with the patched DSDT: 
> - CPUfreq is working: speed varies between 1000MHz and 1833MHz. (not sure
> if it is using intermediate speeds) 
> - Power state (battery / AC power) is working sometimes! It is actually not 
> working but I can't see anything which could cause this behaviour... 
This could get a bit more complicated. Maybe a locking problem...hard to say. We probably need an ACPI debug kernel running on the machine.
> - Fans are not working: if they start, they never stop; you have to shtdown
> the machine. 
These two could both be related to this one:
http://bugzilla.kernel.org/show_bug.cgi?id=5534

> - For a test, I just installed the kernel 2.6.17-AS25-smpdesk from 
> * suspend2ram now results into a hang after resume and a command which needs 
> disk access ("ls" is o.k., but "du" not). I assume this is still the SATA 
> problem.
There is a know bug in some 2.6.17 kernels that prevent S2Ram from working. AFAIK it's already fixed in newer kernels at least people are working on that.

----------------------------------------------------
- I found something out: If you turn off the computer by pressing the power 
button, then it doesn't end up in a "bad state". 
One way to achieve that the computer is not switched off after calling "halt" 
or "shutdown" is to add a line at line 53 of /etc/init.d/halt (the line after 
the esac) as follows: 

command="halt" 
(this overrides the previous value of "halt -p") 

Then the computer won't be switched off after "halt" and just ends up in a 
halting state. So you can switch it off manually and it will remain in a "good 
state" for the next boot. 

It seems that the kernel-command which actually turns the computer off 
(probably some ACPI command) is responsible for the "bad state"... 
---------------------------------------------------
That sounds interessting. What is a bad state (one reboot cycle after next power on?)
Sorry if you already mentioned that, the bug is just too long...

UnCC'ing Robert and Len. This came out to be a BIOS issue... Thanks anyways!

Phillipe: If you still have problems, please open a new bug. For the battery and fan issue you might want to open one and assign it to me again.
This is just getting too confusing (e.g. if HP people should have a look at this they need half an hour going through unrelated information).

Created attachment 94320 [details]
acpidump taken on hp nx6310

I think the same problem exists on HP nx6310: ACPI doesn't update battery stats, cpufreq can't set maximum cpu frequency. Additionally, after rebooting from Linux, BIOS hangs for a while and booting (until GRUB loads) lasts longer. 
In my opinion, BIOS hanging is a clue. It occurs only when I restart from Linux. After rebooting from MS Windows, BIOS runs smoothly and quickly. Also, cpufreq and acpi problems exist only after boot from hanged BIOS.
Another interesting fact is that rebooting from kernel _without_ ACPI compiled in, also results in BIOS hanging. So it seems that ACPI isn't a reason here.
Maybe the problem is how Linux itself reboots/halts.

Just for your information:

problem with maximum CPU frequency also occurs on HP nx7400-T2400.

Reassigning... no input from HP... we could get help from cpufreq list.
Hopefully they will fix that in BIOS if we could find the exact problem in ACPI code...

*** Bug 177963 has been marked as a duplicate of this bug. ***

In addtition, I have the same bios hang after rebooting, the remaining battery time is unavailable. The same thing in UBUNTU Dapper Drake. My machine CeleronM based intel 945GM powered HP-Compaq nx6310.

Hope this will help.

I found the cause, no solution yet.
It's unrelated to http://bugzilla.kernel.org/show_bug.cgi?id=5534 (As one of the methods is serialized and locks are intensively used I thought it could be related, but it's not. Hmm, maybe the bug there gets better if this one is fixed, as writing to random memory parts could cause all kind of phenomenons).

The problem are wrong Operating Region definitions (I expect wrong from BIOS, something with the BIOS developers' AML generater seems to go wrong? Would be nice if Robert could validate this. Any chance to workaround this?).

If you disassmble DSDT from acpidump from comment #40, there are serveral OperationRegions that use name strings as SystemMemory Offset.

I paste the wrong acpidump and ASL parts (The first OperationRegion has a valid address to memory, the others are wrong. I realized that the strings that are used as memory addresses are also used as method declarations somewhere else):

        OperationRegion (C02F, SystemMemory, 0x000F8000, 0x2C)
        Field (C02F, WordAcc, NoLock, Preserve)
        {
            C02A,   32, 
            C030,   16
        }

        OperationRegion (C031, SystemMemory, C029, 0x1040)
        Field (C031, AnyAcc, NoLock, Preserve)
        {
            C032,   33280
        }

        OperationRegion (C033, SystemMemory, C02B, 0xD2)
        Field (C033, AnyAcc, NoLock, Preserve)
        {
            C00A,   16, 
            C034,   16, 
            C035,   16, 
            C036,   16, 
            C037,   16, 
            C038,   8, 
            C039,   8, 
                    Offset (0x10), 
            C03A,   1544
        }

        OperationRegion (C03B, SystemMemory, C02B, 0x41)
        Field (C03B, AnyAcc, NoLock, Preserve)
        {
                    Offset (0x18), 
            C03C,   8, 
            C03D,   160, 
            C03E,   160
        }

        OperationRegion (C03F, SystemMemory, C02E, 0x0140)
        Field (C03F, AnyAcc, NoLock, Preserve)
        {
            C040,   32, 
            C041,   4, 
            C042,   1, 
            C008,   4, 
            C043,   5, 
            C044,   1, 
            C045,   1, 
            C046,   3, 
            C047,   1, 
            C048,   1, 
            C049,   1, 
            C04A,   1, 
            C04B,   1, 
            C04C,   8, 
            C04D,   32, 
            C027,   16, 
            C007,   32, 
            C01D,   8, 
            C04E,   8, 
            C04F,   8, 
            C050,   8, 
            C051,   8, 
            C052,   8, 
                    Offset (0x1A), 
            C028,   32, 
            C053,   8, 
            C054,   8, 
            C055,   8, 
            C056,   8, 
            C057,   8, 
            C058,   8, 
            C059,   48, 
                    Offset (0x40), 
            C05A,   32, 
            C05B,   32, 
            C05C,   32, 
            C05D,   32, 
            C05E,   32
        }

        OperationRegion (C060, SystemMemory, C02D, 0x05DA)
        Field (C060, AnyAcc, NoLock, Preserve)
        {
            C061,   8, 
            C062,   312, 
            C063,   8, 
            C064,   136, 
            C065,   640,
            C065,   640, 
            C066,   640, 
            C067,   640, 
            C068,   640, 
            C069,   640, 
            C06A,   640, 
            C06B,   640, 
            C06C,   640, 
            C06D,   640, 
            C06E,   640, 
            C06F,   640, 
            C070,   640, 
            C071,   640, 
            C072,   8, 
            C073,   128, 
            C074,   8, 
            C075,   264, 
            C076,   264, 
            C077,   8, 
            C078,   264, 
            C079,   264, 
            C07A,   32, 
            C07B,   16
        }


The acpidump parts are:

  0650: c0 7e 02 00 60 a4 60 5b 80 43 30 32 46 00 0c 00  .~..`.`[.C02F...
  0660: 80 0f 00 0a 2c 5b 81 10 43 30 32 46 02 43 30 32  ....,[..C02F.C02
  0670: 41 20 43 30 33 30 10 5b 80 43 30 33 31 00 43 30  A C030.[.C031.C0
  0680: 32 39 0b 40 10 5b 81 0d 43 30 33 31 00 43 30 33  29.@.[..C031.C03
  0690: 32 80 20 08 5b 80 43 30 33 33 00 43 30 32 42 0a  2. .[.C033.C02B.
  06a0: d2 5b 81 31 43 30 33 33 00 43 30 30 41 10 43 30  .[.1C033.C00A.C0
  06b0: 33 34 10 43 30 33 35 10 43 30 33 36 10 43 30 33  34.C035.C036.C03
  06c0: 37 10 43 30 33 38 08 43 30 33 39 08 00 20 43 30  7.C038.C039.. C0
  06d0: 33 41 48 60 5b 80 43 30 33 42 00 43 30 32 42 0a  3AH`[.C03B.C02B.
  06e0: 41 5b 81 1a 43 30 33 42 00 00 40 0c 43 30 33 43  A[..C03B..@.C03C
  06f0: 08 43 30 33 44 40 0a 43 30 33 45 40 0a 5b 80 43  .C03D@.C03E@.[.C
  0700: 30 33 46 00 43 30 32 45 0b 40 01 5b 81 40 0c 43  03F.C02E.@.[.@.C
  0710: 30 33 46 00 43 30 34 30 20 43 30 34 31 04 43 30  03F.C040 C041.C0
  0720: 34 32 01 43 30 30 38 04 43 30 34 33 05 43 30 34  42.C008.C043.C04
  0730: 34 01 43 30 34 35 01 43 30 34 36 03 43 30 34 37  4.C045.C046.C047
  0740: 01 43 30 34 38 01 43 30 34 39 01 43 30 34 41 01  .C048.C049.C04A.
  0750: 43 30 34 42 01 43 30 34 43 08 43 30 34 44 20 43  C04B.C04C.C04D C
  0760: 30 32 37 10 43 30 30 37 20 43 30 31 44 08 43 30  027.C007 C01D.C0
  0770: 34 45 08 43 30 34 46 08 43 30 35 30 08 43 30 35  4E.C04F.C050.C05
  0780: 31 08 43 30 35 32 08 00 10 43 30 32 38 20 43 30  1.C052...C028 C0
  0790: 35 33 08 43 30 35 34 08 43 30 35 35 08 43 30 35  53.C054.C055.C05
  07a0: 36 08 43 30 35 37 08 43 30 35 38 08 43 30 35 39  6.C057.C058.C059
  07b0: 30 00 40 0b 43 30 35 41 20 43 30 35 42 20 43 30  0.@.C05A C05B C0
  07c0: 35 43 20 43 30 35 44 20 43 30 35 45 20 5b 80 43  5C C05D C05E [.C
  07d0: 30 36 30 00 43 30 32 44 0b da 05 5b 81 42 0a 43  060.C02D...[.B.C
  07e0: 30 36 30 00 43 30 36 31 08 43 30 36 32 48 13 43  060.C061.C062H.C
  07f0: 30 36 33 08 43 30 36 34 48 08 43 30 36 35 40 28  063.C064H.C065@(
  0800: 43 30 36 36 40 28 43 30 36 37 40 28 43 30 36 38  C066@(C067@(C068
  0810: 40 28 43 30 36 39 40 28 43 30 36 41 40 28 43 30  @(C069@(C06A@(C0
  0820: 36 42 40 28 43 30 36 43 40 28 43 30 36 44 40 28  6B@(C06C@(C06D@(
  0830: 43 30 36 45 40 28 43 30 36 46 40 28 43 30 37 30  C06E@(C06F@(C070
  0840: 40 28 43 30 37 31 40 28 43 30 37 32 08 43 30 37  @(C071@(C072.C07
  0850: 33 40 08 43 30 37 34 08 43 30 37 35 48 10 43 30  3@.C074.C075H.C0
  0860: 37 36 48 10 43 30 37 37 08 43 30 37 38 48 10 43  76H.C077.C078H.C
  0870: 30 37 39 48 10 43 30 37 41 20 43 30 37 42 10 14  079H.C07A C07B..



Setting this to blocker now as so much machines seem to be affected.

Ahh I think I know what they want to do:
The interpreter should use the address returned by the method..., that's sick.
E.g.:
        Method (C02E, 0, NotSerialized)
        {
            Add (C029 (), 0x00027EC0, Local0)
            Return (Local0)
        }
        OperationRegion (C03F, SystemMemory, C02E, 0x0140)

-> Execute method C02E and use the value returned as memory address. All these offsets are based on C02A, it seems they want to make the OperationRegion addresses dynamic by that:

        Method (C029, 0, NotSerialized)
        {
            Store (C02A, Local0)
            Return (Local0)
        }

        Method (C02B, 0, NotSerialized)
        {
            Add (C02A, 0x1040, Local0)
            Return (Local0)
        }

        Method (C02D, 0, NotSerialized)
        {
            Add (C02A, 0x00014F14, Local0)
        }

        Method (C02E, 0, NotSerialized)
        {
            Add (C029 (), 0x00027EC0, Local0)
            Return (Local0)
        }

I try to exchange the string values with real addresses if I find out which value to use.

Rethinking that, I am quite sure that this violates the ACPI spec. On page 530 (spec 3.0b) a RegionOffset is declared as an Integer and must not be a method/reference/whatever (maybe this is a feature supposed for not existing spec 3.1 and M$ ASL compiler already makes use of it?):

DefOpRegion := OpRegionOp NameString RegionSpace RegionOffset RegionLen
OpRegionOp := ExtOpPrefix 0x80
RegionSpace := ByteData // 0x00 SystemMemory
// 0x01 SystemIO
// 0x02 PCI_Config
// 0x03 EmbeddedControl
// 0x04 SMBus
// 0x05 CMOS
// 0x06 PciBarTarget
// 0x80-0xFF: User Defined

RegionOffset := TermArg => Integer

RegionLen := TermArg => Integer

Also adding Len...
The main problem I see is: If this functionality will be implemented into ACPICA, how should we backport this (probably huge/risky) patch into SP1 safely (IMO this should even be addressed with an earlier kernel update)?
If this is a feature of some M$ ASL compiler it's likely that more (all) new BIOSes make use of this...
Also adding Greg and Andi our kernel gurus...
Reading comment #47 should be enough to understand the problem...

Thomas,

You are a champion!

Sorry for not answering you on previous post, but i was in a hurry...

Given the problem you discovered, surely the fan and battery issues are related. Do you still think I have to open another bug?

About the fan and battery issue, there are three workaround:
 - Turn off the machine and quit battery, Place the battery again.
 - Next time you turn on the machine, turn it off during post.
 - "modprobe -r psmouse" (after compiling psmouse as a module) before shutdown the machine.
Next time you turn on the machine, battery status is working. Not sure about the fans...

Philippe.

Strange is that the wrong addresses are not used, maybe resolving those methods as addresses in OperationRegions is already implemented, but something still goes wrong?

These are parts of syslog ACPI debug output when reading the wrong value (C00A is 4, I expect it shouldn't as the further calcs based on C00A value let PPC return 1). Output is stripped to esssentials and commented a bit (marked with ##):

## C00A is searched and found
kernel:   nsdump-0087 [DFDFB030] [10] ns_print_pathname     : [_SB_.C00A]
kernel: nssearch-0144 [DFDFB030] [12] ns_search_one_scope   : Name [C00A] (RegionField) c547b694 found in scope [_SB_] c547b3c4
kernel: dswstate-0423 [DFDFB030] [09] ds_obj_stack_push     : Obj=c547b694 [RegionField] State=dfef6c00 #Ops=1
kernel:  dsutils-0717 [DFDFB030] [08] ds_create_operands    : Arg #0 (d8ec6694) done, Arg1=d8ec6694
kernel: utobject-0328 [DFDFB030] [11] ut_allocate_object_des: dff32cf4 Size 28
kernel: dswstate-0423 [DFDFB030] [09] ds_obj_stack_push     : Obj=dff32cf4 [Integer] State=dfef6c00 #Ops=2
kernel:  dsutils-0717 [DFDFB030] [08] ds_create_operands    : Arg #1 (d8ec65b4) done, Arg1=d8ec6694
kernel: utobject-0328 [DFDFB030] [11] ut_allocate_object_des: dff32c54 Size 28
kernel: dswstate-0423 [DFDFB030] [09] ds_obj_stack_push     : Obj=dff32c54 [Reference] State=dfef6c00 #Ops=3
kernel:  dsutils-0717 [DFDFB030] [08] ds_create_operands    : Arg #2 (d8ec6678) done, Arg1=d8ec6694
kernel: dswstate-0379 [DFDFB030] [07] ds_result_stack_pop   : Result=d8ec7928 RemainingResults=0 State=dfef6c00
kernel:  exresop-0163 [DFDFB030] [08] ex_resolve_operands   : Opcode 74 [Subtract] RequiredOperandTypes=000018CF

## Why Local0, should be Local1? Should be unrelated...

kernel:  exresop-0257 [DFDFB030] [08] ex_resolve_operands   : Operand is a Reference, RefOpcode [Local0]
kernel: exresolv-0119 [DFDFB030] [09] ex_resolve_to_value   : Resolved object dff32cf4
kernel: exresnte-0102 [DFDFB030] [10] ex_resolve_node_to_val: Entry=c547b694 SourceDesc=c54694ac [RegionField]
kernel: exresnte-0207 [DFDFB030] [10] ex_resolve_node_to_val: FieldRead Node=c547b694 SourceDesc=c54694ac Type=11
kernel: utobject-0328 [DFDFB030] [13] ut_allocate_object_des: dff32c7c Size 28

## Read the first 8 bits for C00A (it's 16 bits) at address 000000001FFD1040
## I thought it should be 0x43303242 (C02B, maybe endian reversed, but this 
## value has nothing to do with C02B?)

kernel: evregion-0403 [DFDFB030] [15] ev_address_space_dispa: Handler dfd4572c (@c01d9013) Address 000000001FFD1040 [SystemMemory]
kernel: exregion-0186 [DFDFB030] [16] ex_system_memory_space: System-Memory (width 8) R/W 0 Address=000000001FFD1040

## Read the second 8 bits for C00A at address  000000001FFD1041

kernel: evregion-0403 [DFDFB030] [15] ev_address_space_dispa: Handler dfd4572c (@c01d9013) Address 000000001FFD1041 [SystemMemory]
kernel: exregion-0186 [DFDFB030] [16] ex_system_memory_space: System-Memory (width 8) R/W 0 Address=000000001FFD1041
kernel: exresolv-0119 [DFDFB030] [09] ex_resolve_to_value   : Resolved object dff32c7c

## Now we are at substract C00A is 4, something went wrong:

kernel:   exdump-0796 [DFDFB030] [07] ex_dump_operands      : ************* Operand Stack Contents (Opcode [Subtract], 3 Operands)
kernel:   exdump-0497 [DFDFB030] [07] ex_dump_operand       : dff32c54 Reference: Local1
kernel:   exdump-0497 [DFDFB030] [07] ex_dump_operand       : dff32cf4 Integer 0000000000000001
kernel:   exdump-0497 [DFDFB030] [07] ex_dump_operand       : dff32c7c Integer 0000000000000004
kernel:   exdump-0810 [DFDFB030] [07] ex_dump_operands      : ************* Operand Stack dump from dswexec(426), after ExResolveOperands


The corresponding ASL part in C009 (invoked by PPC):

        OperationRegion (C02F, SystemMemory, 0x000F8000, 0x2C)
        Field (C02F, WordAcc, NoLock, Preserve)
        {
            C02A,   32,
            C030,   16
        }

        Method (C02B, 0, NotSerialized)
        {
            Add (C02A, 0x1040, Local0)
            Return (Local0)
        }

        OperationRegion (C033, SystemMemory, C02B, 0xD2)
        Field (C033, AnyAcc, NoLock, Preserve)
        {
            C00A,   16,
            ...
        }

// This is the executed code of debug message above, because C00A is 4 (should
// be 0 or 1, PPC is 1 later...):
        If (LGreater (\_SB.C00A, 0x00))
        {
            Subtract (\_SB.C00A, 0x01, Local1)
        }

Maybe the addresses got resolved once at parse/initialisation time, but need to be resolved every time a field variable with dynamic offset is accessed? There is no C02B stuff resolved/executed at PPC execution time...

I will go on digging on Monday, maybe this is debuggable in userspace somehow.

HP has a policy that if the machine has a BIOS problem that causes issues with
Linux, they will update and fix the BIOS.  It sounds like this is the case
here.

Philippe, can you contact HP to see if there is a BIOS upgrade, or who to give
this information to so that they can fix their AML?

Greg,

Unhappely, we have no input from HP. 
There's no answer from them in their Business Forum, and no news from them in this bug report.
Hopefully they fix something in the next bios release for this machine which will be made public on 2006/08/15. I'll tell you something as soon as I can download it.
With bios F11, cpufreq changes between 1000MHz and 1333MHz and never reached 1833MHz. With bios F12 (actual) cpufreq is bloqued at 1833MHz!

I have no info for how to contact HP. In fact, I was thinking Novell/Suse had a direct channel to communicate with them. Maybe you could get some info from David Strbac.
Meanwhile, I'll do a search for howto submit them this bug.

Philippe.

I was wrong, the ACPI interpreter seems to already resolve the addresses in OperationRegions via methods correctly (I wonder where in ACPI spec it's stated that such things are allowed...).
Everything works fine, beside the fact that C00A is 4.
Would be nice if HP could tell us what is checked with C00A ...


The PDC function makes use of the new OSC (Operating System Capabitities) function, maybe something goes wrong there...
It's also checked for the Operating System string in the CPU0.INI func and at some other points. Explicitly invoking this line didn't help either. I will try to boot with some acpi_osi="Windows 2001", acpi_osi="Windows 2006"... have a look at CPU0._OSC and then I have to give up.

I tried acpi_osi="Windows 2001" (with some tweaking, function is not yet implemented) and expierenced that it then writes some stuff to system management memory in CPU0.INI(). This makes the machine incredibly slow, but doesn't bring the last frequency step. acpi_osi="Windows 2006" and acpi_osi="" didn't help also.

I also had a look at the _OSC func, but I doubt that the error comes from there. It is a bit complicated code, but nothing that writes to system memory, just info for the OS, so I doubt there is anything that could make C00A not to return 4.

I tried to let the kernel read the C00A word at once (WordAcc), that did also not help.

We need to know what is behind the word at address 0x1FFD1040 and why it returns 4.

To avoid confusion: I couldn't see any misbehavour concerning Intel's ACPICA code (comment #47 is wrong), means in kernel seems to work everything fine. So for now I'd say something from BIOS goes wrong. Don't know how to come here any further without any input from HP.

I will let severity to Blocker for a while as so much (all new?) HP models (nx7400, nx9420, nx6310 reported) show this symptom.

Has anyone measured the frequency on windows, yet?

I have measured frequency with msinfo32 as Windows help says that it shows actual cpu speed. So it shown 1596mhz, that is maximum for my cpu. 
I would like to draw Your attention, again, to fact that on my machine, after rebooting from Windows and then booting Linux there is no frequency scaling problem (so as bios hanging/pausing - I wrote about this in comment #40). These problems occur _only_ when I reboot from Linux. Can anyone boot Windows, restart, than boot Linux and check frequency to verify my observations?

That is very interessting (sorry for overreading that...)!
Phillip said that there might come a BIOS update soon (tomorrow/today?).
If this should still not fix anything, I try to get HP's attention again, as I am quite sure now that there cannot be done much in kernel without knowing with which hw parts ACPI interpreter communicates when using these mysterious memory addresses.

Phillip pointed me to a HP site where they say that the nx9420 is certified with SLED 9 (SP3?).
So I expect that this already worked with older kernels?
If this is the case, my last attempt would be a binary search, ripping out ACPICA patches until it works and then try to find the culprit in last non-working patch...
If you could point me to already working/nonworking kernels, that would make this "time intensive" job a bit easier...
It may take some time until I can get such a machine again, please be patient.

More recently, the nx9420 was also certified for SLED 10. See http://developer.novell.com/yes/85095.htm
According to the package list, SLED10 ships with kernel 2.6.16.21. Same as SuSE10.1?

in reply to comments #40 and #56:
These comments indicate a difference in the behavior of the nx9420 and the nx6310. On my nx9420 the bios hanging/pausing and the no-battery-update-problem are fixed by booting windows. But the cpu-freq problem is not fixed! In fact, just judging by the effects, it seems unlikely that cpu-freq scaling and the other problems (bios-hanging / no-battery-update) are related (on the nx9420). 

While currently the only solution to the cpu-freq problem seems to be an acpi-patch, the bios-hanging / no-battery-update problem can be circumvented by one of the following on the nx9420 (and this has been confirmed by several sources).
1. booting windows before booting linux
2. unplugging all power sources (battery+ac-adaptor) before the next boot
3. instead of linux rebooting, powering the machine off "by hand" (i.e. pressing the power button just before the linux-kernel powers it off by bios or acpi-call)
4. compiling "psmouse" as module and removing this module during reboot.

Again, none of these fix the cpu-freq problem (on nx9420).

In reply to comment #59

If I remember correctly OpenSuse 10.1 ship with kernel 2.6.16.13, but kernel 2.6.16.21 is available as an official update thru update channel. I'm running it and I can't apreciate any difference.
So Thomas, there is no need to install NLD9 or regress ACPICA patches. but this  lead me to a doubt: what do they test during the certification?

I have contacted HP 'normal' support and HP Business Support. After working hard (very!) with us, I think (hope) they have submitted the case to BIOS support people, but I have no confirmation for now.

I'll let you know...

Philippe.

For knowing if same problem is showing with windows, I've posted a "Call for report max cpu speed on windows" on HP Business Forums (http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1052525&admit=-682735245+1156003796050+28353475)
Only one response for now :-((

> CPU Model see below System information from my laptop
> BIOS and Win Version see below
> Max theoretical CPU freq 1833MHz
> Max measured CPU freq 1830MHz
> - just when encoding Video Data and using
> dynamic switching with "Notebook Hardware Control". NBC is used as the
> measuring tool also. Normally it its 998MHz.
> On Linux its all the time 1833MHz with the F.12 Bios. Module 
> centrino_speedstep is no longer loadable. 

Note the problem is different with BIOS F.12. I have not tried it personnely because of (thanks to...) the DSDT compiled by Thomas.


Referring to the last response from HP 'normal' support, I paste it here without any comment. I'll let it as it is because I'm tired to send us emails with that kind of response or worse... I wonder if they ever read what I wrote: have you ever talked to a wall?
I hope HP Business Support people will be more comprehensive... (and if it is, it's quite a shame too: why these differences between business people and 'normal' persons?)

> Hello Philippe,
> 
> Thank you for contacting Hewlett‑Packard's Commercial Solutions Center.
> 
> This is in response to your e‑mail regarding the HP nx9420 notebook.
> 
> We would like to thank you for sharing the link with us. (### link referring to the SLED 10 certification ###)
> 
> Further, Linux is developed by Novell and customers need to contact Novell for > any issues with Linux. We apologize for the inconvenience that this has caused > to you.
> 
> HP provides Linux software downloads as a courtesy to our customers who are 
> using the Linux operating system. These software downloads and any related
> documentation are not supported by HP Customer Support and are provided 
> without warranties of any kind. The Linux software provided under software 
> downloads is the extent of Linux software that HP will provide for these 
> products.
> HP cannot ensure the compatibility, quality, or performance of this software, > and HP will not necessarily provide maintenance or updates. HP does not 
> endorse any specific distribution of Linux.
> 
> Please e‑mail us if you need any further assistance and we will be glad to help.

...etc...

Greg, it seems like if this policy exist (comment #52), HP support people does not know about it....
Maybe someone at Novell should know about that!

Philippe.

New BIOS F.14 for nx9420 is available since 06/08/29 at http://h18007.www1.hp.com/support/files/hpcpqnk/us/locate/63_6253.html.

Only fix announced:
- Updates microcode to support new factory-installed processors.

No mention of Linux.

I'll try to install it tomorrow at night and report later.

Philippe.

I have installed new bios F.14 and remove DSDT patch.
It seems this bios have same behaviour than bios F.12: Cpu Freq shows a static frequency of 1833MHz (max) for both cores. This is a big problem for the battery life...
May I revert to old bios F.11 (Curiously, bios F.11 is no more available on HP site, but F.02 and F.12 are...) or wait for a new DSDT or patch?

From several reports, seems like Windows people is not having this kind of problems.


Philippe.

I am on holidays for 1 1/2 weeks.
Hopefully there is a machine to work on when I am back, don't know.
If you want to get a new DSDT to override to get all freqs, please attach acpidump and I try to come to it the next days.
It should be a minor thing (just "return (0x0)" in _PPC function(s)), but IIRC, iasl got a little scope thing wrong and the DSDT needs another little thing to be corrected.
I also like to have a look why the scope is wrong at this specific point as iasl works correctly at a lot other similar places ... but that has minor priority ATM and needs to wait.

Created attachment 97628 [details]
acpi dump nx9420 bios F.14

Hi Thomas,

Thanks for your quick answer.
Please, don't worry and enjoy your holidays full time...
I can wait.

I'm not sure this so simple as the boot log say:
"rcpowersaved: CPU frequency scaling is not supported by your processor"!!!

Bonnes vacances!

Philippe.

Created attachment 98740 [details]
Results of Linux-ready Firmware Developer Kit tests, hp nx6310

I've recently found a nice (Intel?) project: Linux-ready Firmware Developer Kit (http://www.linuxfirmwarekit.org/). I took the tests on my machine, results are attached (full output here: http://fatcat.ftj.agh.edu.pl/~lfx/upload/laptop/). Maybe this will tell somebody how to resolve the bug.

Thanks! This tool should be out since some days, this is very useful.

Most reports should not be sever, but this looks suspicious to me:
E820: XSDT (0x78c50000) is not in reserved or ACPI memory!
ACPI: there are different addresses (0 and 3f7e5728) for table MCFG in XSDT versus RSDT.

Hmm, I cannot see whether XSDT or RSDT is used now. I wonder whether a boot option acpi=forceXSDT or acpi=forceRSDT could be useful (don't try they don't exist yet).

Firstly, I excuse for not an appropriate topic. BUT, as I wrote before, this problem exists on other distros (Ubuntu 6.06 aka Dapper Drake) and other HP laptops (HP nx6310) with somewhat other CPUs (CeleronM).
I have installed Suspend2 for linux http://www.suspend2.net/ and the hang before bios_splash_screen_appears (HP logo and stuff) disappered. Now my CPU speed & battery status are shown correctly. It uses custom build kernel+some own packages. There also are rpms for SUSE.
Dapper uses older kernel, 2.6.15-26, but I've had SUSE 10.1 with 2.6.16(?) and the problem existed.
Give suspend2 a try, it might help somehow.
Good luck (=

I have nx6310 too, but applying Suspend2 patch didn't help me (Arch Linux, vanilla kernel 2.6.17.11). I didn't try to suspend, only compiled patched kernel. I'll continue trying with it.

RegionOffset := TermArg => Integer
RegionLen := TermArg => Integer

This means "TermArg" that resolves to an integer. TermArg can be most anything, including a method invocation.

Yes, missed the fact that this works only while hibernating, hibernating from the terminal O=)

(In reply to comment #69)
> Firstly, I excuse for not an appropriate topic. BUT, as I wrote before, this
> problem exists on other distros (Ubuntu 6.06 aka Dapper Drake) and other HP
> laptops (HP nx6310) with somewhat other CPUs (CeleronM).
> I have installed Suspend2 for linux http://www.suspend2.net/ and the hang
> before bios_splash_screen_appears (HP logo and stuff) disappered. Now my CPU
> speed & battery status are shown correctly. It uses custom build kernel+some
> own packages. There also are rpms for SUSE.
> Dapper uses older kernel, 2.6.15-26, but I've had SUSE 10.1 with 2.6.16(?) and
> the problem existed.
> Give suspend2 a try, it might help somehow.
> Good luck (=
> 

Good night from Tallinn!
I found this interesting page http://home.no/slazz/nx6310/nx6310.html
I managed to translate it, and for now the BIOS hang is gone both after reboot & shutdown. Add modprobe -r psmouse after comments to /etc/init.d/halt and /etc/init.d/reboot
As I see, author also speaks something about frequency scaling.

Note, that I use Ubuntu, but hope SUSErs will also take advantage of that.
Good luck!

(In reply to comment #73)
> modprobe -r psmouse 

Huh, it seems that this works;) 
Thanks a lot.

I thought I already added Vojtech.., seems as if I did not -> as this comes out to be an interference problem between mouse and ACPI and needs a fix/workaround in mouse driver code I better reassing this to Vojtech.

I placed kernels to:
ftp://ftp.suse.com/pub/people/trenn/sle10_SP1_hp_fix_cpufreq_ACPI_events_kernels/

that hopefully fixes this issue (thanks to Vojtech for i8042 suggestions) and the issues stated in:
#200169 - HP nx9420 AC / Battery status not updated.

This kernel is based on the SLE SP1 update kernel. This won't be fixed in one of the SLE 10 update kernels (only in SP) as the patches are too intrusive.

I tried suspend to disk and it still worked. Ihno tried suspend to ram and reported that it broke (worked with plain SLE10 kernels).
I am trying to find out what goes wrong there.

I could only test this shortly on an older HP which does not have the symptoms. The patches are mainly collected and adjusted patches from linux-acpi list and current kernel.

Pls give it a try. It would be nice if you could check whether everything (fans, battery,..) still work fine after a suspend to disk. Thanks.

Be aware that according to comment #60:
You have to either:
   - unplug battery and AC when laptop is shut down (and better wait some mins).
or
   - boot into M$ OS
as the values written by the mouse module seem to survive a reboot.
Then boot this kernel -> it should work?
Then reboot again -> it hopefully still works.

Just a pointer for myself:
suspend to ram might be a problem caused by some other patch, see coment #35 from Phillipe.

Thomas, thanks a lot for working on this. I tried the new kernel (-smp), but unfortunately it doesn't seem to fix any of the problems on my machine (nx9420, Bios F.11). 
Without the custom DSDT, cpufreq is at 1333 max (instead of 1833) and the "long boot" error still persists. 

One more note about suspend2ram. I think this never worked (at least on my machine). See bug 187955 (https://bugzilla.novell.com/show_bug.cgi?id=187955).

Can I help anything to debug this?

Thomas,

I probe the new kernel (-smp), but it does not fix any of the problems.
- "bad state" / Bat/AC status: system was working with psmouse compiled as a module before I apply the new kernel. Now the system exhibit the "bad state" problem, etc...
- cpu freq: With last BIOS (F.14), new kernel does not recognise the Core Duo as speedstep capable (same with standart kernel). Probed without your last DSDT.

Which supplementary info do you need?


Philipp,

I suppose that Thomas is working with the last BIOS, so I do not expect any of his last patches working with BIOS F.11. They are too different... (F.14 is only working with cpufreq at max speed 1833)


Philippe.

Let me explain what I did:
I tried to fix three problems at once:

 - psmouse stuff that forbids highest freq (with Vojtech suggestions)
 - battery readings/writings (which I thought are related to stuck ACPI
   processes also see http://bugzilla.kernel.org/show_bug.cgi?id=5534, but I
   was wrong, this is also related to the psmouse mod?)
 - fan problems on some HPs (at least nx6125)

What I learned from that:
 - The fan problems at least should be unrelated to the mouse issue.
 - The battery problems on the nx9420 seem to be related to the mouse issue.
 - Vojtech suggestions did not fix the mouse and the resulting ACPI problems

What next:
I compiled new kernels (hmm I forgot to rip out the mouse patch that did not work, but it shouldn't matter). I compiled the psmouse stuff as module and still added the other workarounds for fan/thermal/power issues.
They are (or should pop up soon) here:
ftp.suse.com/pub/people/trenn/sle10_SP1_hp_fix_cpufreq_ACPI_events_kernels_snd_try 
If someone wants to have a look at the patches, I also placed them there.

Could you try out these kernels and rmmod the psmouse module to see if everything works fine then, pls.
If yes, there is only the mouse issue left... bad enough. I have to discuss that with Vojtech again... no idea how to solve this one yet.
If something still does not work pls report, then there are still other things..
Most important are regressions. If you find anything not working, that did before, pls tell me.

Phillipe:
- cpu freq: With last BIOS (F.14), new kernel does not recognise the Core Duo
as speedstep capable (same with standart kernel). Probed without your last
DSDT.
-> Yes, I am really sorry about that. I had a short look but didn't find anything. It looks like the new BIOS breaks some cpufreq things and cpufreq does not work at all. I am still hoping to get such a machine (David?), this would make things much easier...

Thomas,

- New kernel is apparently working for me with and without psmouse loaded. I'll make supplementary test in the next two days and let you know.
- Cpufreq: it seems to me that the cpufreq problem is related to acpi because gtkacpiw is reporting the cpu with "power management: no"

Thanks for your continous efforts to make this working.

Philippe.

This bug gets my quote for the most weird bug of the year...

Phillipe: Ignore the "power management: no" flag, it doesn't say much.

found something...:
According to Vojtech the mouse driver uses IO address 0x60 and 0x64 and irq12/1.
In ACPI namespace the mouse device is declared with IO address 0x60 and 0x64 and irq1.

On i386 we have PNP and PNP_ACPI compiled in.
Therefore I expect for the ACPI device with PNP0303 id, the drivers/input/serio/i8042-x86ia64io.h code is kicking in.

Could you try boot param:
i8042.nopnp=1  (this should work?)

if above works, this one might also work without above option?:
i8042.noloop=1 (for this one already a blacklist with compaqs exist, adding 
                nx9420 would be a easy fixup)

as this is about unloading the module, this might also help?:
i8042.reset=1

with the original SLE 10, 10.1 kernel.
Hopefully this is it or I begin to run out of ideas...

Thomas,

I have re-installed the original SLED10 kernel without compiling psmouse as a module.
- i8042.nopnp=1 does not work. First time you boot Batt/AC state is ok. When you reboot notebook is in "bad state"
- i8042.noloop=1 not probed as above does not work
- i8042.reset=1 does not work. First time you boot (from good state) Batt/AC state is NOT updated. When you reboot notebook is in "bad state"
Sorry, Thomas!  

I suppose the solutions given for the nx6325 at http://www.wolframschenck.de/nx6325.htm#sect3http://www.wolframschenck.de/nx6325.htm#sect3 and sub-links does not apply to our case?

I have an half good news!!!!! HP have released new bios F.17. This bios have same behaviour than bios F.11: cpufreq does not reach max cpu frequency.
Can I apply the tricks you made to your last DSDT and try to make one?

Philippe.

Thomas,

I have found this bug (http://bugzilla.kernel.org/show_bug.cgi?id=7157) which may explain why bios F.14 (and F.12) don't allow to load cpufreq.

Currently, I'm working with original kernel with psmouse compliled as a module. There are problems with vents which don't stop.

I have observed that if I boot trying to use acpi-cpufreq the module is not accepted with this cpu. But the frequency is 1833MHz (max). If I try to load speedstep-centrino after that, the frequency is still 1833MHz and is not changing.
If I boot directly with speedstep-centrino, cpu frequency changes beetween 1000MHz and 1333MHZ.
So, BIOS or speedstep-centrino error?


Philippe.

Thomas, 

One addendum for the fan problem.
Fan is working and don't stop because acpi doesn't know about it!
gtkacpiw shows all the fans being OFF while at least one is ON.

Another problem is that Bat/AC state is very slow to update when battery is exhausted. (2-3mn)

Philippe. 

> Fan is working and don't stop because acpi doesn't know about it!
> gtkacpiw shows all the fans being OFF while at least one is ON.

Yes, fan control may have changed in these kernels, but should now work as desired. You can check by:

watch -n1 cat /proc/acpi/thermal_zone/*/{temperature,trip_points} /proc/acpi/fan/*/state

For each active trip point you pass, one fan state should turn to on. If you subceed the active trip point, it should turn to off again.
Because of not working cpufreq, fan activity might be much higher than normally.

About the i8042.nopnp option.
There is a ACPI device for the mouse/kbd declared. As for i386 ACPI_PNP is compiled in, I thought the pnp sublayer might recon the PNP id provided by ACPI and break something which could get fixed by the i8042.nopnp=1 option.

To be sure someone could try a kernel with PNP_ACPI not compiled in or rip out the device declared in ACPI in DSDT (you might want to send me acpidump and I can do that). Tell me if I should place a kernel without that option on ftp to test.

I wonder why ACPI_PNP is compiled in for i386, but not for x86_64. It's marked experimental and I don't know what it could be good for ATM, maybe it has just been overseen.

> I have found this bug (http://bugzilla.kernel.org/show_bug.cgi?id=7157) which
> may explain why bios F.14 (and F.12) don't allow to load cpufreq.
Yes, that is probably the same BIOS upgrade.
It looks like HP has blown up cpufreq support functions in their latest BIOS.
David, can you tell them, pls, above bug should hold enough info for them.

Created attachment 102227 [details]
ACPIDUMP for bios F.17

Bios F.17 is better than F.11.
When you boot with speedtep-centrino, frequency change beetween 1GHz and 1,33GHz but (from HP forum) if you execute
echo 1833000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 1833000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
frequency as it should beetween 1GHz and 1,83GHz.
So it seems last bios is nearly working except for fan problem. But why speedstep-centrino is limiting the speed to 1,33GHz?

Philippe.

I placed a plain SLE10 kernel with ACPI_PNP compiled out and mouse again compiled in here:
ftp.suse.com/pub/people/trenn/sle10_SP1_hp_fix_cpufreq_no_ACPI_PNP

AFAIK ACPI_PNP plays around with system resources and potentially has the power to mess up system memory, which I think (if I interpret Vojtechs input right) psmouse has not.
If this works I have a beginning where in kernel code it's worth to look at...
Thanks for any feedback.

I possibly found it. I added an EC fix found on bugzilla.kernel.org (#6455) to SP1 kernel. This should fix the battery issue. It's likely that this also fixes the cpufreq bug. As the cpufreq bug is in a mysterious way related to the mouse... EC bugs often show mouse failures as both access the same HW, so it's worth a try.

The kernel is here:
/ftp.suse.com/pub/projects/kernel/kotd/sles10-i386/SLES10_SP1_BRANCH/kernel-default.i586.rpm

(or get the smp kernel if it's a dual core).

As ftp syncing might take a while you might want to check the changelog whether the fix is included:
rpm -qp --changelog downloaded-kernel.rpm |less

should include this entry:

* Thu Nov 02 2006 - trenn@suse.de

- patches.fixes/acpi_fix_ec_issue.patch: Fix battery/AC status
  update (#6455 (kernel.org)).


Lowering severity, I thought this one is related to a non working fan issue on some HPs. This is also known and came out to be something else. It is still not fixed properly mainline, collecting all things is a pain, but I try to backport these for SP1 soon, too.

hi thomas,
i would like to thank you.

i am using a hp notebook model nc8430.
this is very similar to the nx9420.
i had similar problems as you discussed it above:
with new bios versions for the nc8430 powersaved had the problem not using the highest cpu speed.
battery status didn't update

after reading this bugzilla-entry, i tried your kernel at ftp.suse.com/pub/people/trenn/sle10_SP1_hp_fix_cpufreq_ACPI_events_kernels_third_try/
and with that, the battery status is working.
and the cpu throtteling also.
the only thing i had to do additionally is the following:
echo 2000000 >/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
echo 2000000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
so that powersaved knows about the correct highest cpu frequency for this notebook. without that it thinks it can only go up to 1667 mhz.

but now nearly everthing works like expected.
(ok, the ati-driver for the x1600 graphics card is shit, and latest versions of this driver crash, but thats another story ;-)

thanks alot for your kernel!

I ran into overheating problems on my new xn6325 with suse 10.1, upgraded
the bios (no help), inserted print statements into the acpi drivers and
gradually started that there were several things going wrong.

I then found patches and bugs on kernel.org. 2.6.19-rc5 has some of the
patches. Applying one more patch got me over the problems with this rc5
kernel. Then I backported the patches to my 2.6.16.21-0.25 Suse 10.1
kernel. Things mostly work (with one glitch remaining -- sticky temp 
readings causing delayed fan on/off).

Could someone let me know what might be the timeline when I might see
the relevant patches in an online update to Suse 10.1? I'm also happy
to switch to SLED10/SLES10 if this venue would give me relief sooner.

Melt-down problems are rather important in my mind (should this really 
be a P5 bug?).

Sincerely,
Ole

P.S. Can share patches against the 2.6.16.21-0.25 kernel if you wish.

Created attachment 106391 [details]
Patch from Bruno Ducrot that should fix the issue

I added this one to the recent 10.2 RC1 and 10.1 SP1 kernel.
Sorry, only security issues or real blockers are allowed to be commited to 10.1/SLE10 update kernel. Hmm, this one is rather safe I will ask...

> should this really be a P5 bug
Severity is important for me, Priority is for others...

> Can share patches against the 2.6.16.21-0.25 kernel if you wish.
Yes please!
I have a collection of patches, but there are still issues. Fans that were active before suspend breaking away after suspend I got fixed. I am currently fighting with the problem of randomly disappearing Fan device handles at boot time...
The problem is that the patches which are currently discussed for mainline inclusion:
  a) did not get much testing. E.g. the "execute ACPI notify in own workqueuey"
     patch from http://bugzilla.kernel.org/show_bug.cgi?id=5534 went mainline,
     was ripped out again, because it produced endless threads on other 
     machine(s), was reworked and commited and now ripped out again...
  b) some need a lot adjustance for 2.6.16

Ole: Maybe best is to communicate via mail... I am happy if you can send me some patches, I can send you my stuff, but I'd better wait until I found the last issue.

*** Bug 227765 has been marked as a duplicate of this bug. ***

Hi,

Thank you for tou answer Thomas.
Swithing off all power sources solves the problem.
Unfortunately it is still not solved in way of patch that can be downloaded by SuSE Update (openSUSE 10.2). 
Is there any chance that someone will do that soon?

There`s nothing left to do than just waiting i guess.
Unfortunately my knowledge about C++, ASM, kernel source etc. is too much poor to be helpful (i`m PHP and Java programmer), but it would be great to get some smart manuals or howtos.

Best regards
Piotr Klimczak

*** Bug 226069 has been marked as a duplicate of this bug. ***

*** Bug 200169 has been marked as a duplicate of this bug. ***

*** Bug 202389 has been marked as a duplicate of this bug. ***

I collected all related HP problems in this bug for now, 10.1 and 10.2. If you describe problems pls drop a short note whether it's 10.1 or 10.2, even the problem exists on both

Things should go better for 10.2 with this kernel:
ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/kernel-default.i586.rpm

and for 10.1/SLED10 people with this kernel:
ftp.suse.com/pub/projects/kernel/kotd/sle10-sp-i386/SLES10_SP1_BRANCH/kernel-default.i586.rpm

Would be great if people could try those out.
Be aware that there are several problems:
a) There still might be issues with ACPI after suspend to disk (concerning fans)
   There have been several patches suggested, I still want to wait for the final
   one. In the 10.1/SLED10-SP1 kernel some infrastructure already has been added
   to be able to apply specific ACPI suspend patches then.

b) There is also the phenomenon that some HPs (mostly Pentium Dual Cores?) that
   when firmware comes into some kind of bad state (you should see this if:
   cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq does not show the
   highest supported frequency). If this is the case, booting windows or
   removing battery and AC (all power) for some minutes should help. Also 
   compiling psmouse as a moudule and rmmodding it before shutddown helps (not
   sure whether this is enough to bring it back to the "good state". I wonder
   whether those kernels work fine as soon as the machine is in "good state". I
   don't/can't go for the psmouse compiled as module workaround which only
   hides a bug anyway.
   Thanks to Alessandro, there is another bug opened here:
   http://bugzilla.kernel.org/show_bug.cgi?id=7689
   and Intel people who have much more man power are working on it.

It would be great if these kernels could be tested and reported back what works (updating AC/battery state should work now) and what still does not work (still switching into "bad state"?, still AC/battery problems?). Play a bit with the ACPI things, unplugging AC, closing lid, reading out hardware info through /proc/acpi/thermal_zone/*/* and /proc/acpi/battery/*/* and watch a bit the system whether everything works stable for longer time. If you experience much better behaviour, this patch will go in.

I am still very busy, came back from vacation some days ago and got 4 new bugs only yesterday. Still I consider this one the most important and will go on with "time intensive" debugging after I at least answered on bugs and emails...

Related bugzilla.kernel.org bugs:
Thanks to Alessandro (he fall out of CCs?):
http://bugzilla.kernel.org/show_bug.cgi?id=7689
Describes the "firmware falls into bad state" problem

http://bugzilla.kernel.org/show_bug.cgi?id=5534
Describes the problem of too many notify/gpes/.. happening and processing of ACPI methods get stuck/cancled because all are running in one kernel thread. The latest patch from comment #180 is in above kernels and should make things better (could be that this also cause the "bad state", try to evaluate this...).

http://bugzilla.kernel.org/show_bug.cgi?id=7122
Possible broken fans after suspend to disk. This should not be that hard to resolve, but I like above problems should be clarified first. Maybe it's related and those "workaround" patches not needed or can be written nicer.

i tried do install kotd for openSUSE10.2 but there is a dependency, which could not be solved:
wlan-kmp-default-1_2.6.18.2_34-16 depends on kernel 2.8.18.

and my hp nc8430 notebook has an ipw3945 wlan-card and i don't want to loose my wlan-connectivity.....

what can i do to solve this?

Install with rpm -ivh kernel-xy.rpm --force --nodeps
You possibly have to duplicate a boot entry in:
/boot/grub/menu.lst
and let vmlinux and initrd directly point to the kernel/initrd files in /boot/:
vmlinux-2.6.x.y (instead of the symlink vmlinux)
initrd-2.6.x.y (instead of the symlink initrd)

(you also might want to add a "debug" at the new boot entry's title)
Now you can boot both kernels, the working one, against which the kernel packages are correctly linked against and the new one where wlan will not work.
Later you can get rid of the new kernel again by:
rpm -e kernel-exact-version-of-newly-installed-kernel

Created attachment 112343 [details]
Unregister serio drivers on shutdown

It's as easy as that.
Waiting for confirmation whether that really fixes it.
I copied test kernels for 10.2 into my ftp(could also work with kernel-packages (wlan, nvidia,..), not sure whether it matches the recent updated kernel verion exactly):
ftp.suse.com/pub/people/trenn/hp_fixes_final
May take a while until it's synced and they pop up.
On top of latest 10.2 kernel they include the patch from:
http://bugzilla.kernel.org/show_bug.cgi?id=5534 (comment #180) and this one.

Vojtech can I add this one to SLE10-SP1 and 10.2 update as soon as someone confirms it fixes the issue.

Thomas,

I have installed the kernel from ftp.suse.com/pub/people/trenn/hp_fixes_final this morning and the "bad state" problem seems fixed with it. 
When I boot with this kernel and reboot the machine, the nx9420 is still in "good state". :-)

However the cpufreq problem is still an issue (I mean scaling max cpufreq is 1333MHz after booting, You have to echo 1833 >/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq)

I could not test it more extensively for now because of my work; maybe this weekend...
This is because I have many dependencies: novfs, vmware, fglrx, ...

Philippe.

Hi

I'm not sure whether I should add this here or open a new bug. I own and HP NX 9420 with bios F.17 and running openSUSE 10.2 on it. I rebuilt the kernel by compiling psmouse as a module and doing the necessary changes to /etc/sysconfig/kernel and /etc/init.d/halt.local. The problem I'm having is that when I remove my AC adapter the laptop immediately starts powering down. This is a clean shutdown. SuSE just drops from run level 5 to 0. Shutting down all services cleanly. Does anyone else have this problem? Any workaround? If I have posted on the wrong place please let me know and I'll open a new bug.

Thanks
Michael Magua

Michael,

I'm not sure this is the good place for your problem, but others are more qualified than I am to tell you.
It seems your 9420 has a problem with its battery. One way to confirm that is installing a small utility like acpiw to monitor your battery state. It will show you the battery factory capacity, actual capacity and the like...
If all is correct, please tell us as this may be a problem with the bios. If remaining capacity is low, you have a problem with the battery and you may contact your HP representative. You could also use HP Business forums to submit your case and / or search for similar problems (I remember having seen somes)
If all is correct, could you try it with Windows?

Philippe.

Hi Philippe

Thanks for the speedy reply... This does not happen under Windows. You may have noticed that I have posted the same thing on the HP business support forums under topic "Linux installation on an HP Nx 9420". This does not happen on Fedora, Ubuntu, Mandriva but openSUSE. I am stumped...

Thanks
Michael

Hi again...

If I disable powersaved the problem goes away. I don't really know what to say. Sorry if I have gone off topic here. I'm also using the kernel from ftp.suse.com/pub/people/trenn/hp_fixes_final . Both default and this kernel give me the same problem with powersaved running.

Michael

(In reply to comment #108)
> I have installed the kernel from ftp.suse.com/pub/people/trenn/hp_fixes_final
On our hp nx6325 Turion X2
APCI is greatly improved:
kpowersave now sees the battery and AC events.
 
> However the cpufreq problem is still an issue (I mean scaling max cpufreq is
> 1333MHz after booting, You have to echo 1833
> >/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq)

CPU frequency scales fine to 1.6GHz

Thanks to all for working on this. I hope this gets into the main line of 10.2 kernels soon.

Bernhard

After some more testing, I am not so sure everything is okay.

AC and battery status seem to work, CPU freq scaling also.

However, the fans never seem to turn on, even though acpi -V shown temperatures up to 67 C.

How can I test fan control really works?

Bernhard

This is known if you've done a suspend to disk:
http://bugzilla.kernel.org/show_bug.cgi?id=7570
and will also be fixed soon.

You can check the fans with:
watch -n1 cat /proc/acpi/fan/*/state /proc/acpi/thermal_zone/*/{temperature,trip_points}

You may want to replace the "*" wildcard for thermal_zone(s) with the thermal_zone (e.g. TZ0) that exports active trip points.

Each active trip point represents a temperature limit and a fan (level). When the temperature limit is exceeded you must see a fan state switching to "on".

Can you describe the problem a bit further (working at the beginning, breaking after some minutes/hours, only breaking after suspend to disk, ...). Please also have a look at dmesg whether you see an ACPI error like: "No context for object" or other ACPI warnings/errors.

The machine does not go thru suspend2disk.

The fan(s) are on when the machine is turned on.
The turn on very early in the boot phase and never turn on again.

I thought I could turn them on manually by doing sth like
echo 3 > /proc/acpi/fan/*/state
but this has no effect.

There are four fan labeled "034F" ... "0352", all of which report "off" in the state.

I have seen thermal event in the acpid log file, and the current temp is above some of the trip points, so I would expect the fans to run.

I will look a demsg as soon as I get back to that machine.

Bernhard

hi thomas,
now i also have tried the new kernel.
it was a bit tricky, because after insalling it, i had no more graphics-card-driver and wlan-card-driver, and i could not rebuild these drivers, because the kernel-source, does not match the installed kernel.
kernel-version: 2.6.18.5-34
kenerl-source-version: 2.6.18.2-34

but because of the similarity of these 2 versions i tried to simply copy the required modules from /lib/modules/2.6.18.2-34-default to /lib/modules/2.6.18.5-34-default/ and it seems to work....

right now my nc8430 notebook is in (as we all call it now ;-) "good state".
until today it happend from time to time that the notebook suddenly was in "bad state". mostly when i used it running on battery.

i will use now the new kernel as long is i don't see any disadvantage.
and i will report in the next days if there is any change or new behaviour.

> it happend from time to time that the notebook suddenly was in "bad
> state". mostly when i used it running on battery.
This means that you couldn't reach max cpufreq on battery (sometimes?).
Some BIOSes provide advanced configuration for cpufreq (e.g. performance/power optimised for battery/AC mode). Maybe it's intended by BIOS to tell the OS/kernel to run on lower frequencies on battery.

> kernel-version: 2.6.18.5-34
> kenerl-source-version: 2.6.18.2-34
Yes this is a problem.
As there shouldn't be any kernel ABI changes it should work out if you move the newly installed module directory and create a link instead pointing to the old one:
mv /lib/modules/"new_kernel_modules_dir" /lib/modules/"new_kernel_modules_dir.bak"
ln -s /lib/modules/"old_kernel_modules_dir" /lib/modules/"new_kernel_modules_dir"

Bernhard: On my nc6400 fans are working fine. Hmm or better, as you stated a lot things got fixed, can you open a new bug for it and post acpidump and machine model and BIOS version again there, pls. Also check for BIOS updates, all this is heavily depending on correct a BIOS. Most reports here are with an Intel CPU, yours is a Turion X2 (quite new machine/BIOS probably). This sounds like a new/other problem.

> This means that you couldn't reach max cpufreq on battery (sometimes?).

without a script (doing "cp /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq") max cpufreq can never be reached.
and this is regardless if running on battery or not.

but when machine is in "bad state", even this script didn't help.

"good state":
max cpufreq is not reached automatically.
but with little "help-script" it is reached.

"bad state":
max cpufreq is not reached automatically.
little "help-script" doesn't solve problem.

> As there shouldn't be any kernel ABI changes it should work out if you move   > the newly installed module directory and create a link instead pointing to the > old one

i did it the other way around and copied every missing directory from /lib/modules/2.6.18.2-34-default to /lib/modules/2.6.18.5-34-default which also works.

status so far:
until today, i NEVER EVER reached "bad state" with your new 2.6.18.5-34-default kernel.
batteray-status is updated.
cpu reaches maximum freq (with little "helper script")
temperatures are not going so high any more.

from my point of view this is the best kernel ever for a hp nc8430 notebook.
please make an official opensuse10.2 update kernel with all these changes as soon as possible.
thanks!

i will post anything new here, when something changes or happens.

*** Bug 237157 has been marked as a duplicate of this bug. ***

I committed the two fixes to 10.2 (will be in next updated kernel) and SLE10-SP1 kernel branch (10.1 gets synced with the latter AFAIK, but this could take a while).

If there are still problems left, please open a new bug.

Also be aware that you must not boot an older (not including the fixes) kernel in between as the firmware will switch into bad state again and you need to boot a fixed kernel twice then.

Rainer: about "i had no more graphics-card-driver and wlan-card-driver", this should also get fixed by reinstalling kernel module packages (rpm -qa |grep kmp).

when will next opensuse10.2 update kernel arrive?

the only remainig problem is that you need a little helper-script for cpu reaching max cpufreq.
but i can live with that.

in the meantime i updated notebook with latest bios from HP (you can enable vanderpool-virtualization-technology now!).
no problem! everything is fine. (except cpu reaching max cpufreq automatically).

and again:
until today, i NEVER EVER reached "bad state" with your new 2.6.18.5-34-default
kernel.

thanks for the tip with reinstalling kernel module packages.
right now copying of the modules-files did the trick.
and when official-update-kernel arrives, i will install it, and then i can get rid of your "hp-fix-special-kernel 2.6.18.5-34-default" and my copied kernel module files.
then i will build fglrx for the new kernel and ipw3945 (wlan) should come automatically with official-update-kernel.

i hope i have not to wait very long for this official-update-kernel.
thanks.

> the only remainig problem is that you need a little helper-script for cpu
> reaching max cpufreq.
This one could be related to this issue:
http://marc.theaimsgroup.com/?l=linux-acpi&m=116900368102272&w=2
-> also added.

I don't know when the next update kernel appears. AFAIK they are only released for security issues.

> also added.

with "also added" you mean this fix will also be added in the next official-update-kernel for opensuse10.2?

> AFAIK they are only released for security issues.

oh no!
that means i have to wait for the time, where enough security-fixes are done to justify a new update kernel?

this could take months.... :-(

(In reply to comment #115)
> Can you describe the problem a bit further (working at the beginning, breaking
> after some minutes/hours, only breaking after suspend to disk, ...). Please
> also have a look at dmesg whether you see an ACPI error like: "No context for
> object" or other ACPI warnings/errors.
> 

Finally I got around to look at this again.
The ACPI fan control fails from the beginning (without going thru suspend).

I have seen the following ACPI warings in dmesg:

ACPI: Transitioning device [C352] to D0
ACPI: Transitioning device [C352] to D0
ACPI: Unable to turn cooling device [dffde9b4] 'on'
ACPI: Transitioning device [C351] to D0
ACPI: Transitioning device [C351] to D0
ACPI: Unable to turn cooling device [dffdea04] 'on'
ACPI: Transitioning device [C350] to D0
ACPI: Transitioning device [C350] to D0
ACPI: Unable to turn cooling device [dffdea54] 'on'

(I will post the full output of 'dmesg | grep ACPI' as an attachment)

The machine is an hp compaq nx6325 (Turion X2)
I found no newer BIOS for this one.

I am using the fixed hp kernel described in the bug.

Thanks
Bernhard

hi thomas,

is the kernel from http://ftp.gwdg.de/linux/suse/opensuse/repositories/Kernel:/SL102_BRANCH/openSUSE_10.2/i586/ the same or at least with all the same latest fixes as your kernel from ftp.suse.com/pub/people/trenn/hp_fixes_final?
the version-number could lead to that conclusion.
opensuse-kernel-repo: 2.6.18.5-181
and your's:           2.6.18.5-34

or am i wrong with this assumption?
in this repo is also included a kernel-source-rpm, which would make things a little bit easier.

after thomas told me, that kernel from kernel-repo also has the patches i tried kernel from http://ftp.gwdg.de/linux/suse/opensuse/repositories/Kernel:/SL102_BRANCH/openSUSE_10.2/i586/

everything works! :-)

after installing it, i just reinstalled kernel-dependend drivers (fglrx, wlan, ...) either by source-rpm-rebuilding or just executing the installer.

big thanks to thomas!