Distribution: Debian unstable Hardware Environment: ASUS M2400N Centrino notebook Software Environment: Problem Description: Hangs on boot when executing all _STA and _INI methods. More exactly, with 'Local APIC' enabled, the computer hangs when executing \_SB.PCI0.VGA._INI during boot-up, and also later when VGA-related methods are called (after removing _INI from a custom DSDT to boot the system). There's none of these problems when 'Local APIC' is disabled. Linux 2.4.22 and 2.6.0-test5 appear to behave the same here (both with ACPI 20030916). The actual offending code in the DSDT appears to be a write to IO address 0xB2 by a method \ISMI (Issue SMI?). These calls are used to query and set the active display devices (flat panel and/or external monitor). The XFree86 driver for the integrated chipset, i855GM (the driver is i810) has some code for switching display devices via 'int 10h', i.e. the video BIOS. I have extracted this and made a small test program with LRMI (http://sourceforge.net/projects/lrmi) and this can successfully set and read the attached display state. This works both with or without 'Local APIC' support (as does the X server). So perhaps the BIOS makes the same calls to the video BIOS when told to by the DSDT? Steps to reproduce: Apply ACPI 20030916 patch (though I doubt this is necessary, I haven't tested without), patch ACPI to circumvent bug #1260, and reboot.
Created attachment 932 [details] DSDT that causes this problem This is the original DSDT (minus cosmetic changes to make it compile) that exhibits this problem. The offending code is \ISMI, called by various VGA-related methhods (GCDD, GNDD, GCAD, SWH[GD], _INI).
Created attachment 933 [details] program to switch displays This is a hack of vbetest.c that's included with LRMI (http://sourceforge.net/projects/lrmi) that talks to the video BIOS to query the active display state and optionally set it. It works regardless of whether 'Local APIC' is enabled.
can you attach '/proc/ioports' with local apic enabled and disabled?
Created attachment 938 [details] /proc/ioports on 2.4.22 /proc/ioports turned out to be the same regardless of whether 'Local APIC' is enabled. With the 'Local APIC' kernel (identical in configuration apart from this option to the other kernel), I bypassed the boot problem by passing acpi=off to the kernel.
If I disable the vga console completely, I can boot successfully with ACPI and Local APIC.
>00a0-00bf : pic2 0xB2 is in the IO rang of pic2, I don't know if it's a problem.
I have a question, Since there is a entry: { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY } in standard_io_resources, the ioport range for pic2 should be 0xa0 - 0xa1. I don't understand why your box could have 0xa0 - 0xbf ?
I also found below code in you dsdt: Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, 0x0020, 0x00, 0x02) IO (Decode16, 0x00A0, 0x00A0, 0x00, 0x02) IRQNoFlags () {2} }) } Maybe we need to exploit this method to setup IO PORT resources for PIC1 and PIC2.
I guess if you disable CONFIG_PM option, the kernel can work with ACPI, APIC and VGA console enabled.
Thanks for your efforts. I hope I'll be able to do some more testing tonight, certainly tomorrow. Regarding the IORESOURCE_BUSY range, the /proc/ioports is from Linux 2.4.22, which has 0xa0 to 0xbf there. However, the problem definitely also exists with Linux 2.6.0-test5. I'll attach a copy of 2.6.0-/proc/ioports later.
Created attachment 939 [details] /proc/ioports on 2.6.0-test5 this is on 2.6.0-test5 with ACPI, Local APIC, without Power Management, with acpi=off.
I've compiled 2.6.0-test5 with Local APIC, ACPI and vga console, but without CONFIG_PM as suggested. It hangs in the same place, though.
From your comments , the problem looks interesting. Below is my understanding: 1) APIC + ACPI + VGA console = boot hang 2) ACPI + VGA console - APIC = ok 3) ACPI + APIC - VGA console = ok 4) APIC + VGA console - ACPI = ok Did you try Serial console? Could you please catch dmesg from it. It can help me a lot. I also need your config file. thanks a lot.
0xb2 is for power managment. In my machine (dell desktop), write 0x70 -> 0xb2 ioport, enable ACPI mode write 0x71 -> 0xb2 ioport, disable ACPI mode I don't know why your dsdt write the ioport frequently. VGA need special power managment?
First off, I unfortunately won't be able to work on this bug very well since I handed the notebook off to its owner this weekend. I only prepared it for him and got the chance to play with it a little. I'll post to the support list to encourage some of the other M2N-owners to follow up on this. Regarding the vga console: I found that it would boot without vga console on 2.4.22 and haven't been able to test it on 2.6.0-test5 as I didn't manage to disable the configuration option. Re comment #13: Unfortunately, the notebook doesn't have a serial port (and I don't have an appropriate cable), so I couldn't test the serial console. I'll attach the dmesg output of 2.6.0-test5 with and without APIC and the config file later. Re comment #14: The DSDT writes to that IO port to query and set how the video is routed from the video chip to the output ports: The chipset supports an analog output, an internal flat panel and two digital outputs (my notebook only has the first two). Also, it internally has two pipes, and these can be attached to the output ports in different ways. E.g. analog (external CRT) and flat panel both to pipe B to clone the display, or analog to pipe A and flat panel to pipe B when you want to drive both monitors separately (e.g. for Xinerama). The DSDT switches this mapping, and queries what it will be after the next switch, by writing to 0xb2. Since this mapping can also be queried and changed by talking to the video BIOS (for example, the program I've attached does this), I suspect that the BIOS might do the same when told to by appropriate writes to port 0xb2. That's pretty much speculation, though.
Created attachment 961 [details] dmesg of 2.6.0-test5 with APIC This is the output of dmesg on 2.6.0-test5 with APIC (and VGA console and ACPI), where ACPI was disabled using acpi=off. Unfortunately, I failed to copy the configuration -- it was rather minimal. I might be able to post it in a few days.
Created attachment 962 [details] dmesg of 2.6.0-test5 without APIC This is 2.6.0-test5 without local APIC support, but with ACPI and VGA console. The only difference from the config of the previous attachment is that I removed 'Local APIC', and I booted without parameters (i.e. no acpi=off).
Created attachment 1257 [details] a proposal patch for fixing this issue Kernel hang when writing 0x95 to port 0xB2. If disable APIC , such kind of opertation will not hang. It looks like APIC local timer cause the problem. At least below code in __setup_APIC_LVTT seems to be write reserved bits of LVT Timer Register. lvtt1_value = SET_APIC_TIMER_BASE(APIC_TIMER_BASE_DIV) | //which access APIC_LVT_TIMER_PERIODIC | LOCAL_TIMER_VECTOR;
*** Bug 1774 has been marked as a duplicate of this bug. ***
*** Bug 1677 has been marked as a duplicate of this bug. ***
well after 2 years e 4 days:: _after_ buy my laptop , APIC works with ACPI ! or seem to work for me its a great new. using kernel-2.4.25-pre6 + cpufreq-LINUX_2_4-20040123.tar.bz2 + http://bugzilla.kernel.org/attachment.cgi?id=1257&action=view however cat /proc/interrupts still XT-PIC #cat /proc/interrupts CPU0 0: 61973 XT-PIC timer 1: 739 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 615 XT-PIC usb-uhci 10: 2 XT-PIC acpi 12: 13064 XT-PIC PS/2 Mouse 14: 13012 XT-PIC ide0 15: 7846 XT-PIC ide1 NMI: 0 LOC: 61462 ERR: 36 MIS: 0 5: 882 XT-PIC VIA686A has disapear disappear ???
*** Bug 1026 has been marked as a duplicate of this bug. ***
After several days of tests I found 2 problems in this proposal patch : 1- Won't compile if we don't enable APIC in kernel configuration drivers/acpi/acpi.o: In function `acpi_bus_init': drivers/acpi/acpi.o(.text.init+0xa4f): undefined reference to `disable_APIC_timer' drivers/acpi/acpi.o(.text.init+0xb05): undefined reference to `enable_APIC_timer' drivers/acpi/acpi.o(.text.init+0xc14): undefined reference to `enable_APIC_timer' 2- Pressing Fn+F3 hangs computer instead print: [ACPI Debug] String: ==== Fn+F3 hot key handler ==== [ACPI Debug] String: Change between LCD, CRT, or both LCD and CRT displays [ACPI Debug] String: --------- VIA SOFTWARE SMI PMIO 2Fh ------------ Anyway, one workaround disable APIC, if we have it enabled, but at least won't hang on boot, this problem affect many computers at least all series of compaq presario 7xx denoted by APIC victims
I just tried 2.6.2 and 2.6.2-mm1 both with ACPI & APIC enabled and the problem seems to have reappeared, as the machine hangs during boot with "ACPI: IRQ9 SCI: Edge set to Level Trigger I can boot with "acpi=off" or I can compile the kernel without APIC and then things seem fine. This is on an ASUS M2N, for more information about it, please see http://bugzilla.kernel.org/show_bug.cgi?id=1774 It seems there is still something fishy in ACPI & APIC interaction. (Also see http://bugzilla.kernel.org/show_bug.cgi?id=1890)
I can confirm that Compaq Presario 2540ea, with linux-2.6.2 with "lapic" on comand line does NOT boot, while without "lapic", it boots OK. BTW, second part of the patch (the part against drivers/acpi/bus.c) seems not to be included in patch-2.6.2
second part of the patch is a workaround. can acpi_pic_sci=edge help?
Hello My experience says that this problem happens in all version of 2.4.x and 2.6.x. so I test mainly with 2.4 and all the patch seems not to be included in patch-2.4.25-rc1
Using: kernel-2.4.25-rc1 + cpufreq-LINUX_2_4-20040207.tar.bz2 + http://bugzilla.kernel.org/attachment.cgi?id=1257&action=view + last acpi patch Re:#26 boot with acpi_pic_sci=edge Disable all acpi events, that prevents laptop hangs when we press fn+F3, because event isn't generate. fn-F7 (- bright) and fn-F8 (+bright) works normally Other note: I upgrade my system and now I use FC1 and compile vanilla kernel with gcc3.2 like is recommended by fedora team. (just swap gcc with gcc32 in Makefile) and the beaver of laptop is exactly the same !
Created attachment 2059 [details] 2.4.25-rc1 with boot option acpi_pic_sci=edge the result from normal boot is : -ACPI: IRQ10 SCI: Edge set to Level Trigger. +ACPI: IRQ10 SCI: Edge Trigger.
Created attachment 2060 [details] lspci -v
>second part of the patch is a workaround. >can acpi_pic_sci=edge help? On Compaq Presario 2540EA, using plain 2.6.2, with "lapic acpi_pic_sci=edge" on command line, don't boot. Plain 2.6.2 and plain 2.6.2 with "acpi_pic_sci=edge" on command line, both boots but without LAPIC
On an Acer TravelMate 803LMi (4A14 BIOS), a vanilla 2.6.2 kernel with UP_APIC *sometimes* hangs on boot immediately after printing ACPI: IRQ9 SCI: Edge set to Level Trigger It seems to be unpredictable whether it will hang or not, except that if I completely remove power first (both unplug AC power and remove battery) it always seems to boot OK. The DSDT is in the acpi.sourceforge.net collection. I've switched to a kernel without APIC and so far it hasn't hung on boot. Unfortunately this machine doesn't have a serial port, which limits the opportunities for kernel debugging. (I'm trying to get hold of a port extender with a serial port.)
James: I have exactly the same Notebook, and had the same problem, with 2.6.3-rc2-mm1 and earlier kernels. The error disappears for me and I can use APIC when I enable "HPET" and "Power Management Timer Support" in the kernel. I have no idea if that makes sense. I'll attach my .config for you, so you can try.
Created attachment 2107 [details] TM803 kernel config - works for me with APIC
I'm curious whether the patch of disabling local apic timer can work for your Acer TravelMate 803LMi ?
Created attachment 2108 [details] timer patch for 2.6.3-rc2 Disabling the timer with the patch from Karol Kozimor helps on my Acer 803lmi (with 2.6.3-rc2).
As far as I can tell, the TM803 doesn't have an HPET (at least acpidmp doesn't show an HPET table), so I think it is only the "Power Management Timer Support" option that is making the difference. This is in the mm kernels but isn't in the vanilla 2.6.2 kernel, so to test this I applied http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2/2.6.2-mm1/broken-out/acpi-pm-timer-3.patch to a vanilla 2.6.2 kernel. So far, with this patch, and enabling both X86_PM_TIMER and X86_UP_APIC I haven't yet had a hang on boot.
I just upgraded from 2.6.2 to 2.6.3 and this bug has got worse. Enabling X86_PM_TIMER no longer prevents the problem. Also instead of hanging on boot only sometimes, it now hangs every time. However, disabling the APIC timer in bus.c is still an effective workaround.
Created attachment 2193 [details] Patch to disable APIC timer on 2.6.3
> Found and enabled local APIC! Either we need to change this default action, or we need to blacklist his platform (and others like it) to run "nolapic". please attach the output from dmidecode. thanks, -Len
Attached is the output from dmidecode on my acer travelmate 803lmi.
Created attachment 2313 [details] dmidecode.txt
FYE: I just updated to the new BIOS (its not yet officially announced, it seems) on my M2400N, and (2.6.4, that is, haven't tried others) booted without disabling local apic. ftp://ftp.asuscom.de/pub/NOTEBOOK/M2x00N/Bios/M2n0208a.zip See also #1963.
I can confirm that with 2.6.3 after BIOS upgrade. But I'm now seeing a lot of codec_semaphore: semaphore is not ready [0x1][0x700300] lines during ALSA init. They don't seem to do much harm, though - sound is working fine.
On the Acer Travelmate 803lmi it seems to be fixed with Bios 4a17 and/or Linux 2.6.4. I could boot 2.6.4 with Bios 4a13 and 4a17 and I can boot 2.6.3 with 4a17. I haven't retried the old comination 2.6.3 with 4a13 which hade made problems.
sorry, s/4a13/4a14/
*** Bug 2044 has been marked as a duplicate of this bug. ***
*** Bug 1682 has been marked as a duplicate of this bug. ***
*** Bug 2694 has been marked as a duplicate of this bug. ***
As far as I know, this is an obvious BIOS bug. If you really want try APIC timer with ACPI, please try workaround patch above. Thanks, Luming
Created attachment 2891 [details] workaround for 2.4 the real fix should be in BIOS. --Luming
There are too many systems with this failure. We need a Linux fix -- even if it turns out to effectively be a BIOS workaround.
Created attachment 3126 [details] 2.6.6 disable_APIC_timer() debug patch If your system hangs on boot w/o "nolapic" and the earlier disable_APIC_timer() patch allowed you to use the LAPIC, then please try this debug version of the disable_APIC_timer() patch and see if it behaves any differently. The intent is to confirm the notion that the hang happens when we write to the SMI_CMD register to enable ACPI, and that if the LAPIC timer is disabled at that point, then the hang does not occur.
I agree totally to many computers with this. RE: Can I try this on kernel 2.4.26 ? I got this errors on 2.4.26: In file included from hwacpi.c:47: /usr/src/linux-2.4.26s/include/asm/apic.h: In function `apic_write': /usr/src/linux-2.4.26s/include/asm/apic.h:25: warning: implicit declaration of function `fix_to_virt' /usr/src/linux-2.4.26s/include/asm/apic.h:25: `FIX_APIC_BASE' undeclared (first use in this function) /usr/src/linux-2.4.26s/include/asm/apic.h:25: (Each undeclared identifier is reported only once /usr/src/linux-2.4.26s/include/asm/apic.h:25: for each function it appears in.) /usr/src/linux-2.4.26s/include/asm/apic.h: In function `apic_write_atomic': /usr/src/linux-2.4.26s/include/asm/apic.h:30: `FIX_APIC_BASE' undeclared (first use in this function) /usr/src/linux-2.4.26s/include/asm/apic.h: In function `apic_read': /usr/src/linux-2.4.26s/include/asm/apic.h:35: `FIX_APIC_BASE' undeclared (first use in this function) make[4]: *** [hwacpi.o] Error 1
Created attachment 3139 [details] disable_APIC_timer() debug patch (2.4.26 or 2.6.6) sure, this version of the debug patch applies cleanly to either 2.4.26 or 2.6.6.
Created attachment 3141 [details] dmesg with apic on 2.4.26 ok boots with apic, but still XT-PIC interruptss, even cleaning via quirks from drivers/pci, still hangs when press fn+F3 (tv-out).
S
thanks, for this mini lesson, I really didn't knew the difference of local APIC and IO-APIC, and yes I don't have MADT, so I just have one local APIC, for sure the kernel is built with IOAPIC and lapic and yes /proc/interrupts show LOC incrementing. yes this COMPAQ has been some fun in past and have several workarounds in kernel one on file arch/i386/kernel/pci-pc.c, is: Disabling VIA memory write queue (PCI ID 0305, rev 80): [55] 3c & 1f -> 1c, I don't know what this done, but appears this comment: /* Addresses issues with problems in the memory write queue timer in * certain VIA Northbridges. This bugfix is per VIA's specifications, * except for the KL133/KM133: clearing bit 5 on those Northbridges seems * to trigger a bug in its integrated ProSavage video card, which * causes screen corruption. We only clear bits 6 and 7 for that chipset, * until VIA can provide us with definitive information on why screen * corruption occurs, and what exactly those bits do. * * VIA 8363,8622,8361 Northbridges: * - bits 5, 6, 7 at offset 0x55 need to be turned off * VIA 8367 (KT266x) Northbridges: * - bits 5, 6, 7 at offset 0x95 need to be turned off * VIA 8363 rev 0x81/0x84 (KL133/KM133) Northbridges: * - bits 6, 7 at offset 0x55 need to be turned off */ in my case is exactly KL133/KM133 Northbridges with ProSavage video card. The bios system is the latest from compaq and is dated of 2002-07-15. ACPI SCI works on any event as usual, except fn+F3 (tvout) has I write in my last message of this bug and also increments acpi entry. This was reported on this weekend testing, with 48 hours of up-time and comment the lines 771 to 778 of linux-2.4.26s/drivers/pci/quirks.c #ifdef CONFIG_X86_IO_APIC /* { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_ioapic }, */ #endif /* { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_acpi }, */ /* { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_acpi }, */ /* { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irqpic }, */ /* { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irqpic }, */ /* { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6, quirk_via_irqpic }, */ I don't see much difference, comment or not comment this lines, on behavior of the laptop, but I know that will be applied on my laptop if I uncomment.
Created attachment 3154 [details] cat /proc/interrupts
Created attachment 3155 [details] cat /proc/acpi/processor/CPU0/power
I'm running 2.6.7 on an acer travelmate 800lci, and am experiencing some form of this bug as well (boot hangs with "ACPI: IRQ9 SCI: Edge set to Level Trigger") with acpi, lapic and io-apic. The problem got a lot worse with the latest acpi patch (acpi-20040715-2.6.7), to the point that I couldn't boot the machine anymore (it would hang everytime). For me the workaround patch at http://marc.theaimsgroup.com/?l=linux-kernel&m=107477355619716&w=2 worked perfectly. The first part of this patch is already included in the acpi patch, the second part is the same as in comment #39. It works great now with acpi and lapic.
Created attachment 3495 [details] 2.6.7 test patch to enter ACPI mode before LAPIC init This patch enables ACPI mode earlier, hopefully avoiding this issue altogether. Please give it a test.
Created attachment 3509 [details] 2.4.27 early-init patch 2.4 version of 2.6 patch above
2.4.27 early-init patch, seems to work on my laptop, if no colateral problems, I think that should be applied. thanks
I forgot to test ! Fn+F2 (switch to external CRT) crashes kernel. so maybe it is not good idea apply patch, yet.
with allow "lapic" to force enable LAPIC patch http://bugme.osdl.org/show_bug.cgi?id=3238 just resolve my problem and is already included on kernel 2.6.9-rc4 btw: I realize when I had LAPIC enabled I got this message: spurious 8259A interrupt: IRQ7. that can be the root of the lapic problem. If I may suggest and if we don't have regretions, this patch should also enter in kernel-2.4.28 big thanks,
shipped in 2.6.9 and also in 2.4.28 -- closing.
*** Bug 3002 has been marked as a duplicate of this bug. ***
*** Bug 3451 has been marked as a duplicate of this bug. ***