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