Skip to contentSkip to conversation

ACPI on hp tc1100

DISCUSSION Joshua Wise 4 participants 10 messages Dec 5, 2004 – Dec 26, 2004 8 messages not in the archive ACPI

lore
Share & tools
lore
#0 lore raw

Hi all,

I'd like to start off this email by commending the authors of the ACPI drivers for Linux. I've done a little bit of looking into fixing the DSDT for the hp tc1100, and in my research, I gained quite an appreciation for what an endeavour it must be to write something to parse this, make sense out of it, and then act properly on it.

Anyway, without further ado, here's my status report for hp tc1100:

* No crashes on boot. That's good.

* The device does the Right Thing in terms of going on battery and off battery.

* ACPI detects the multiple clock states available to the processor, and seems to be able to act on them.

* ACPI detects the battery and can figure out its charge state.

* When the device is commanded to go into standby (S0) via the following command ...

	# echo standby > /sys/power/sleep
  ... the device turns its screen black, then restores the contents of 
the screen by repainting. The system is then as it was left.

* When the device is commanded to suspend to ram (S3) via the following command ...

	# echo mem > /sys/power/sleep
  ... the system does any one of a number of things.

- The system can fail to acquire some semaphore as reported in the
system log. It will then fail to go to sleep.
- If the nvidia binary-only driver has been loaded, and X has been
run within that cycle of loading the nvidia driver, then the system goes to sleep. When commanded to wake through the power switch, the system will switch to a console momentarily, print some debugging messages, then blank the screen and seemingly halt.
- If the nvidia binary-only driver has been loaded, and X has not
been run within that cycle of loading the nvidia driver, then the system goes to sleep. When commanded to wake through the power switch, the system will go back to the console in which the system was left. The system will be functional, except for the wireless driver, as will be mentioned below. If X is run in this load cycle of the nvidia binary-only driver, the system's display will blank and the system will seemingly halt.
- If the nvidia binary-only driver has not been loaded, then the
system goes to sleep. When commanded to wake through the power switch, the system will go back to the console in which the system was left. The system will be functional, except for the wireless driver, as will be mentioned below.

* After the device has been woken, the internal ipw2100 wireless card will no longer function. Reloads of the module will succeed, but no card will be detected.

* The device seems to run very warm, and the fan is almost always on. I am not sure whether this is a function of running Linux, or whether this has always happened -- Windows was only running on this device for about two or three hours before Debian was loaded on it.

* The wacom_acpi patch provided by Jamey Hicks seems to work out of the box on 2.6.9, although with the latest ACPI patches, it seems that acpi_get_current_resources has been deprecated. What is the replacement for that?

Does anyone have any insight to the problems seen? If you need more detail, feel free to reply.

Thanks for all the great work!
joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): 41B2912D.8020105-NtISFavHD68j5TC/[email protected]

#2 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Joshua,
regarding the nvidia problem, I would recomend you searching the november posts to this list for a thread called "Success with kernel-swsusp and Nvidia-closed-source" started by me. Just to repeat two things:
I was not sucessfull with the latest nvidia driver. I needed to use the nvidia agpgart with 'Option "NvAGP" "1"', as with my Acer ali-agp it would crash on resume.

Quoted 2 lines · Joshua Wise

- If the nvidia binary-only driver has been loaded, and X has been run
within that cycle of loading the nvidia driver, then the system goes to sleep. When commanded to wake through the power switch, the system will switch to a console momentarily, print some debugging messages, then blank the screen and seemingly halt.

If you login through the network and run "top" you would see, that X is claiming nearly 100% of CPU-cycles..., that happens, when you switch to the virtual-console, where the nvidia-binary-only driver is running (or if it is resumed to this console...) and the AGP-bus is not initialised.

As you may read often on this list, start with suspend to disk, as it is the easiest to get running. Then go for S1 and S3 (the S0 you mentioned is S1). Just always think of doing a sync before trying to suspend; then fsck has a lot better chances to put things together after a crash.

Cheers
hartwig felger

Hartwig Felger informatics

- -- 1024D/339FD693 Hartwig Felger <[email protected]> Key fingerprint = FB2F 3EE9 345A D55B 6FF2 0EC1 F5B0 684F 339F D693 For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBsu/89bBoTzOf1pMRApUzAJ9hlkn3Ud+GKvgt/VrThnFtS3vj8QCgqQVR vaPt0WmVkOWsUj9qfY8w63s=
=GwUm
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.60.0412051210070.990-KnfdeQs3A3X/[email protected]

#4 lore raw
Quoted 1 line

regarding the nvidia problem, I would recomend you searching the november posts to this list for a thread called "Success with kernel-swsusp and Nvidia-closed-source" started by me.

Okay, I read through that.

Quoted 2 lines

Just to repeat two things:
I was not sucessfull with the latest nvidia driver. I needed to use the nvidia agpgart with 'Option "NvAGP" "1"', as with my Acer ali-agp it would crash on resume.

Hm. First, I tried just setting Option "NvAGP" "1" in my XF86Config without downgrading, and that seemed to do the trick! I am running the latest NVidia drivers: 6629. However, when the system 'comes back to life', the wireless is non-functional, as described below. The wacom-acpi driver also seems to need to be reloaded: on resume, dmesg reports that ttyS4 failed the LSR safety check. If I get a chance, I'll see if I can't write a patch for that to kill off and reload the serial
on suspend and resume, respectively. (This shouldn't go in
suspend/resume scripts because we need to maintain continuity across a suspend - X doesn't know how to re-open the device when it gets unexpectedly closed.)

Quoted 1 line

If you login through the network and run "top" you would see, that X is claiming nearly 100% of CPU-cycles..., that happens, when you switch to the virtual-console, where the nvidia-binary-only driver is running (or if it is resumed to this console...) and the AGP-bus is not initialised.

Ah. In fact, when this system resumes from suspend, the wireless card refuses to work. Errors in dmesg:
<system power on>
ipw2100: eth0: ipw2100_verify failed: -5
ipw2100: eth0: Failed to power on the adapter.
ipw2100: eth0: Failed to start the firmware.
Restarting tasks... done
<I try to reload the driver>
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.1
ipw2100: Copyright(c) 2003-2004 Intel Corporation
ACPI: PCI interrupt 0000:02:05.0[A] -> GSI 15 (level, low) -> IRQ 15
ipw2100Device not found via register read.

I will see if removing the driver before bringing the system down helps.

Quoted 1 line

As you may read often on this list, start with suspend to disk, as it is the easiest to get running. Then go for S1 and S3 (the S0 you mentioned is S1). Just always think of doing a sync before trying to suspend; then fsck has a lot better chances to put things together after a crash.

Yup. Sync before suspend has saved me repeatedly. I actually just got S3 mostly working, as described previously. I will try swsusp in a while to see if that fixes my ipw2100 problems.

Quoted 2 lines

Cheers
hartwig felger

joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): 41B377AE.7080108-NtISFavHD68j5TC/[email protected]

#6 lore raw
Quoted 13 lines

Ah. In fact, when this system resumes from suspend, the wireless card refuses to work. Errors in dmesg:
<system power on>
ipw2100: eth0: ipw2100_verify failed: -5
ipw2100: eth0: Failed to power on the adapter.
ipw2100: eth0: Failed to start the firmware.
Restarting tasks... done
<I try to reload the driver>
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.0.1
ipw2100: Copyright(c) 2003-2004 Intel Corporation
ACPI: PCI interrupt 0000:02:05.0[A] -> GSI 15 (level, low) -> IRQ 15 ipw2100Device not found via register read.

Quoted 1 line

I will see if removing the driver before bringing the system down helps.

Try the attached patch(against the ipw2100 driver.

Stefan

ipw2100.c +2 -0
@@ -6664,6 +6664,8 @@ static int ipw2100_suspend(struct pci_de
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
 	pci_save_state(pci_dev, priv->pm_state);
+#else
+	pci_save_state(pci_dev);
 #endif
 	pci_set_power_state(pci_dev, state);
 

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 1 line
Quoted 1 line

I will see if removing the driver before bringing the system down helps.

I tried rmmod'ing ipw2100 before putting the system into S3. The driver would not reload after awakening the system. (As an aside, the driver does not trash the card's state. If I rmmod the driver and immediately reload it and the system has not been suspended, the driver will successfully load.)

Quoted 1 line

Try the attached patch(against the ipw2100 driver.

There was no behavioral change. I'm running 2.6.9+acpi-latest, anyway.

joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

#9 lore raw
In reply to a message not in the archive
Quoted 1 line · Joshua Wise

Hm. First, I tried just setting Option "NvAGP" "1" in my XF86Config without downgrading, and that seemed to do the trick! I am running the latest NVidia drivers: 6629. However, when the system 'comes back to life', the wireless is non-functional, as described below. The wacom-acpi driver also seems to need to be reloaded: on resume, dmesg reports that ttyS4 failed the LSR safety check.

Well, digging this out of the archive.... I figured out why NvAGP 1 "fixed" the problem. It seems that the tc1100's AGP host bridge is in fact unsupported by the NVIDIA AGP driver, so when we force the NVIDIA driver's AGP mode, we effectively disable AGP and only use PCI. I wonder if kernel AGPGART is not doing some sort of appropriate AGP magic before the NVIDIA driver comes back up?

joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): 41CE656C.1050500-NtISFavHD68j5TC/[email protected]

#11 lore raw
Quoted 8 lines · Joshua Wise
Quoted 6 lines · Joshua Wise

Hm. First, I tried just setting Option "NvAGP" "1" in my XF86Config without downgrading, and that seemed to do the trick! I am running the latest NVidia drivers: 6629. However, when the system 'comes back to life', the wireless is non-functional, as described below. The wacom-acpi driver also seems to need to be reloaded: on resume, dmesg reports that ttyS4 failed the LSR safety check.

Quoted 6 lines

Well, digging this out of the archive.... I figured out why NvAGP 1 "fixed" the problem. It seems that the tc1100's AGP host bridge is in fact unsupported by the NVIDIA AGP driver, so when we force the NVIDIA driver's AGP mode, we effectively disable AGP and only use PCI. I wonder if kernel AGPGART is not doing some sort of appropriate AGP magic before the NVIDIA driver comes back up?

What does lspci say about the host/pci bridge ?

Dave

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#13 lore raw
Quoted 1 line

What does lspci say about the host/pci bridge ?

I'm not quite sure what you were asking for.

I first did an lspci -t, knowing that my video card was 01:00.0, and found the following line (coming off bus 00):

      +-01.0-[01]----00.0

So it looks like 00:01.0 is the AGP bridge. I looked in there with lspci -v -v -s:

joshua@shebang:~$ sudo lspci -v -v -s 00:01.0
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: d8000000-dfffffff
        Prefetchable memory behind bridge: e8000000-f7ffffff
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

So there's my AGP bridge: part of the 82855PM.

For good measure, I'll also give you the lspci details about the graphics card:

joshua@shebang:~$ sudo lspci -v -v -s 01:00.0
0000:01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company: Unknown device 08b0
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium 
Quoted 1 line

TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 248 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Region 2: Memory at e8000000 (32-bit, prefetchable) [size=512K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 

PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4

                Command: RQ=32 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- 

FW- Rate=x4

Let me know if you have further questions.

Quoted 1 line

Dave

joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): 41CF1DF0.60504-NtISFavHD68j5TC/[email protected]

#15 lore raw
Quoted 4 lines · Joshua Wise
Quoted 1 line

What does lspci say about the host/pci bridge ?

I'm not quite sure what you were asking for.

Quoted 8 lines

I first did an lspci -t, knowing that my video card was 01:00.0, and found the following line (coming off bus 00):

      +-01.0-[01]----00.0

So it looks like 00:01.0 is the AGP bridge. I looked in there with lspci -v -v -s:

joshua@shebang:~$ sudo lspci -v -v -s 00:01.0
0000:00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller 

The 855 should work fine with the in-kernel GART driver. The NVidia driver I can't say, but I'd be surprised if it doesn't also support it.

Dave

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

A message that is not in the archive (sent off-list or not yet received): [email protected]

#17 lore raw
Quoted 2 lines

The 855 should work fine with the in-kernel GART driver. The NVidia driver I can't say, but I'd be surprised if it doesn't also support it.

Right. The in-kernel GART's AGP support works, but suspend to RAM doesn't (or I guess, more accurately, restore from RAM...) The system hangs if the NVidia driver is using the GART when suspending/resuming, however if I disable AGP, suspend/resume works fine. (well, on the graphics driver front, at least.)

Quoted 1 line

Dave

joshua

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/