Bug 12856

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.

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.

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.

Created attachment 20505 [details]
Acpidump output

Created attachment 20506 [details]
dmidecode output

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).

Reproduced on 1.5

>      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").

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.

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?

(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.

Created attachment 20522 [details]
facp.dat

please attach the kernel config file in both 2.6.28 and 2.6.29-rc7 kernel.

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.
    

(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.

Cannot reproduce with 2.6.29-rc8 (nor -rc9 of course).