found 648754 linux-2.6/2.6.32-39
quit

Matthieu Dubuget wrote:

> I tried different kernels packages:
>
> matt@keynuxmatt:~$ dpkg -l linux-image* | grep "^ii"
> ii linux-image-2.6.32-5-amd64 2.6.32-39 Linux 2.6.32 for 64-bit PCs
[...]
> The problem is that I could not find a working kernel among the kernel
> packages I was able to install.

Thanks for checking. Very good to know.

> I booted the system in single mode.
> I think that virtualbox and nvidia drivers are not loaded:

Yep, good.

[...]
| [ 0.000000] DMI: Compal PBL21/PBL21, BIOS 1.71 04/19/2011

Hmm. Someone else reported trouble on a Compal laptop a short
while ago upstream[1].

[...]
> [ 0.704413] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
> [ 0.704679] ACPI: No dock devices found.
> [ 0.704775] HEST: Table not found.
> [ 0.704870] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [ 0.705390] \_SB_.PCI0:_OSC invalid UUID
> [ 0.705391] _OSC request data:1 8 1f

I don't suspect it will change anything, but could you test with
pci=nocrs on the kernel command line?

> DSDT @ 0xaf7f0000
[...]
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I'll leave interpreting ACPI tables to the experts. Next time, please
use attachments instead of copy+paste.

> After that, the only system I was able to run that is able to power
> off the computer is ubuntu 10.04.3 live CD (11.10 was tried without
> success).
>
> dmesg output:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[...]
> [ 0.797057] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

Hm, interesting. Does pcie_aspm=off on the newer kernels make a
difference? (I don't think it will, but seems worth a try.)

> [ 2.850829] _OSC invalid UUID
> [ 2.850923] _OSC invalid UUID

So this one doesn't look like it's the problem.

[...]
> acpidump output (I had to edit sources, apt-get update and apt-get
> install it):

Because I'm incredibly lazy: can you check if this is the same as the
acpidump from the system that doesn't work (3.x)?

> Hoping this will be usable?

Yes, I think we're ready to take this upstream.

Please send a summary of the symptoms you've experienced to
linux-acpi@vger.kernel.org, including the following information:

- steps to reproduce: install kernel, "shutdown -h now". Says
"Will now power off" (does it?) but the backlight does not turn
off and reopening the lid turns the computer on again.

- affected versions:

Debian 3.0.0-6 (which is very close to upstream stable v3.0.8)
Debian 3.1.0-1~experimental.1 (which is basically linus's v3.1)
Debian 2.6.32-39 (close to longterm v2.6.32.43)

not affected:

Ubuntu 2.6.32.41+drm33.18

- dmesg from an affected kernel (attached)
- acpidump output (attached)
- dmesg from an unaffected kernel (attached)
- a pointer to the bug at http://bugs.debian.org/648754
- any other hints or weird observations

and cc either me or this bug log so we can track it.

Thanks a lot, and good luck,
Jonathan

[1] http://thread.gmane.org/gmane.linux.acpi.devel/50155



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111116044358.GB5889@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111116044358.GB5889@elie.hsd1.il.comcast.net

Hello Jonathan

Thanks a lot for your advices.

Before I report upstream, here are some answers to your questions.


Hmm. Someone else reported trouble on a Compal laptop a short
while ago upstream[1].
[1] http://thread.gmane.org/gmane.linux.acpi.devel/50155


I had not found this one. Thanks. I will also contact this guy directly.


I don't suspect it will change anything, but could you test with
pci=nocrs on the kernel command line?


No change, except from the comment in the log.


I'll leave interpreting ACPI tables to the experts. Next time, please
use attachments instead of copy+paste.


I'm sorry for that.


Hm, interesting. Does pcie_aspm=off on the newer kernels make a
difference? (I don't think it will, but seems worth a try.)


No.


Because I'm incredibly lazy: can you check if this is the same as the
acpidump from the system that doesn't work (3.x)?


I did some diffs. Interesting summary:

All acpidump obtained from non-working kernels are identical.
There is a difference between the acpidump when the power off is
working and when it does not work:

$ diff acpidump-not-working acpidump-working
2805a2806,2813
> RSDT @ 0xaf7fe0ac
> 0000: 52 53 44 54 58 00 00 00 01 8a 49 4e 53 59 44 45 RSDTX.....INSYDE
> 0010: 48 52 20 43 52 42 20 20 01 00 00 00 20 20 20 20 HR CRB ....
> 0020: 13 00 00 01 00 c0 7f af 00 d0 7f af 00 b0 7f af ................
> 0030: 00 a0 7f af 00 90 7f af 00 f0 7e af 00 e0 7e af ..........~...~.
> 0040: 00 d0 7e af 00 b0 7e af 00 80 7e af 00 70 7e af ..~...~...~..p~.
> 0050: 00 60 7e af 00 50 7e af .`~..P~.
>


Next step: upstream report

Thanks again for your time.

Matt




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EC38919.1070009@gmail.com">http://lists.debian.org/4EC38919.1070009@gmail.com