Bug 12856 - Thinkpad freezes with X.org and acpi=rsdt
Summary: Thinkpad freezes with X.org and acpi=rsdt
Status: CLOSED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Tables (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks: 12398
  Show dependency tree
 
Reported: 2009-03-11 16:46 UTC by uzytkownik2@gmail.com
Modified: 2009-03-22 03:57 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.29-rc7
Tree: Mainline
Regression: Yes


Attachments
xorg.conf (2.53 KB, text/plain)
2009-03-11 23:10 UTC, uzytkownik2@gmail.com
Details
Acpidump output (174.86 KB, text/plain)
2009-03-12 08:20 UTC, uzytkownik2@gmail.com
Details
dmidecode output (11.98 KB, text/plain)
2009-03-12 08:21 UTC, uzytkownik2@gmail.com
Details
facp.dat (129 bytes, application/octet-stream)
2009-03-14 15:12 UTC, uzytkownik2@gmail.com
Details

Description uzytkownik2@gmail.com 2009-03-11 16:46:25 UTC
Latest working kernel version: 2.6.28
Earliest failing kernel version: 2.6.29-rc7
Distribution: Gentoo
Hardware Environment: Thinkpad R51e
Software Environment: X.org 7.4
Problem Description:

Steps to reproduce: acpi=rsdt parameter[1] with X.org (more precise Gnome as gdm seems not affact it) running after some time freezes the computer. I.e. machine cannot be pinged via wifi, pointer does not move etc. I used in-kernel radeon driver. dmesg is unfortunatly unavaible.

[1] Discovered as it have been suggested as possible solution to ACPI problems in bug #12826.
Comment 1 ykzhao 2009-03-11 18:18:30 UTC
From the problem description it seems that this is a regression. Will you please use git-bisect to identify the commit which causes the regression?
    
     How about if adding the following boot option?
     a. idle=poll
     b. nolapic_timer
     
     Will you please also attach the output of acpidump, dmidecode?
     Thanks.
Comment 2 Zhang Rui 2009-03-11 19:04:25 UTC
First of all, I don't know if we should mark it as a regression, because "the latest working kernel version 2.6.28" means that the cpufreq sysfs I/F is available in that kernel, as stated in bug #12826.

Maciej, I think the laptop also freezes in 2.6.28 with "acpi=rsdt", right?

please attach the /etc/X11/xorg.conf file.
Comment 3 uzytkownik2@gmail.com 2009-03-11 23:10:51 UTC
Created attachment 20497 [details]
xorg.conf

(In reply to comment #2)
> First of all, I don't know if we should mark it as a regression, because "the
> latest working kernel version 2.6.28" means that the cpufreq sysfs I/F is
> available in that kernel, as stated in bug #12826.
> 
> Maciej, I think the laptop also freezes in 2.6.28 with "acpi=rsdt", right?
> 

No it does not. If it would I would put it in 'not working' not 'last working'.
Now I'm on Linux 2.6.28 with acpi=rsdt.

(In reply to comment #1)
> From the problem description it seems that this is a regression. Will you
> please use git-bisect to identify the commit which causes the regression?
> 

Not before the weekend. Rebuilding the kernel takes a long time so even with logarithmic nature of bisect it would take over a workday (I guess it will take over 12 h).

>      How about if adding the following boot option?
>      a. idle=poll
>      b. nolapic_timer
> 
>      Will you please also attach the output of acpidump, dmidecode?
>      Thanks.
> 

Ok. I will do it this evening.
Comment 4 uzytkownik2@gmail.com 2009-03-12 08:20:04 UTC
Created attachment 20505 [details]
Acpidump output
Comment 5 uzytkownik2@gmail.com 2009-03-12 08:21:48 UTC
Created attachment 20506 [details]
dmidecode output
Comment 6 uzytkownik2@gmail.com 2009-03-12 08:26:10 UTC
It seems to not occure with xorg-server 1.5. I'll check with 1.6. If it work it means that a) it is a 'random' bug b) it is fixed in git. I'll check it soon (or report that it hanged with 1.5 - the last time there was different periods before hang).
Comment 7 uzytkownik2@gmail.com 2009-03-12 09:27:24 UTC
Reproduced on 1.5
Comment 8 uzytkownik2@gmail.com 2009-03-12 10:17:31 UTC
>      How about if adding the following boot option?
>      a. idle=poll
>      b. nolapic_timer
> 

In addition to or instead of acpi=rsdt?
I can check the idle=poll but since acpi=rsdt was suppose to be part of solution to overheating it does not seems to be a long-term solution - it may serve only as the debugging.
nolapic_timer will not affect the system as APIC is disabled anyway (it used to cause problems so I disabled it "# CONFIG_X86_UP_APIC is not set").
Comment 9 Zhang Rui 2009-03-12 18:18:05 UTC
XSDT and RSDT use different FADT on this laptop.

this is what I got from the FACP.dsl when RSDT is used,

[080h 128  1]         Value to cause reset : 06
**** ACPI table terminates in the middle of a data structure!

Maciej, please boot with "acpi=rsdt", run "cat /sys/firmware/acpi/FACP > facp.dat" and attach the facp.dat file here.
Comment 10 Zhang Rui 2009-03-12 19:20:46 UTC
The commit caused the regression in but #12826 has already been reverted.
http://bugzilla.kernel.org/show_bug.cgi?id=12826#c30

so Maciej, the cpufreq driver can work well again without acpi=rsdt, right?
Comment 11 uzytkownik2@gmail.com 2009-03-12 23:07:32 UTC
(In reply to comment #10
> 
> so Maciej, the cpufreq driver can work well again without acpi=rsdt, right?
> 

Well. But it will be removed eventually AFAIK.
Comment 12 uzytkownik2@gmail.com 2009-03-14 15:12:57 UTC
Created attachment 20522 [details]
facp.dat
Comment 13 Zhang Rui 2009-03-15 19:29:04 UTC
please attach the kernel config file in both 2.6.28 and 2.6.29-rc7 kernel.
Comment 14 ykzhao 2009-03-17 19:43:27 UTC
Hi, Maciej
    From the dmesg log in http://bugzilla.kernel.org/show_bug.cgi?id=12826#C3 it seems that local and I/O APIC is disabled in kernel configuration.
    Will you please enable it in kernel configuration and see whether the box still freezes?
    
    From the acpidump in comment #4 it seems that there exists the mismatch between 32x/64x GPE0block address. 
   >32/64X address mismatch in "Gpe0Block": [00008020] [0000000000008028], using 64X [20080213]
    In such case it will be better to use the RSDT instead of XSDT.
    So IMO this issue is not caused by the boot option of "acpi=rsdt".
    
    Will you please confirm whether the box still freezes under console mode?(Of course the boot option of "acpi=rsdt" is still needed).
    Thanks.
    
Comment 15 uzytkownik2@gmail.com 2009-03-21 15:53:40 UTC
(In reply to comment #14)
> Hi, Maciej

Sorry for late response. I don't know why but I haven't recived this message by email.

>     From the dmesg log in http://bugzilla.kernel.org/show_bug.cgi?id=12826#C3
> it seems that local and I/O APIC is disabled in kernel configuration.
>     Will you please enable it in kernel configuration and see whether the box
> still freezes?
> 

Ok. 

>     From the acpidump in comment #4 it seems that there exists the mismatch
> between 32x/64x GPE0block address. 
>    >32/64X address mismatch in "Gpe0Block": [00008020] [0000000000008028],
> using 64X [20080213]
>     In such case it will be better to use the RSDT instead of XSDT.
>     So IMO this issue is not caused by the boot option of "acpi=rsdt".
> 

Well. It is. Every time it is present the computer freeze and if it is not it does not. It might be not caused by rsdt table however.

>     Will you please confirm whether the box still freezes under console
> mode?(Of course the boot option of "acpi=rsdt" is still needed).
>     Thanks.
> 
> 

I just build 2.6.29-rc9. Checking.
Comment 16 uzytkownik2@gmail.com 2009-03-22 01:58:42 UTC
Cannot reproduce with 2.6.29-rc8 (nor -rc9 of course).

Note You need to log in before you can comment on or make changes to this bug.