ACPI on Macbook
Hello. I have been working on getting my new Macbook working with Ubuntu dapper for suspend. Initially, the machine would crash on wake up. I created a fix to the PCI drivers for that and now it doesn't crash (fix is now in the Ubuntu kernel repository). After this fix I noticed that ACPI was non-functional after reboot. This is because the irq9 handler gets disabled with the nobody cared message. This happens because when the machine comes up, irq9 is high (level-triggered) but the ACPI code doesn't think it has anything to do. It therefore returns IRQ_NONE instead of IRQ_HANDLED and the kernel starts ignoring irq9 (preventing ACPI from working). I found that the cause of this problem is that when the laptop returns from sleep the SCI_EN bit has been cleared. Actually, the entire PM1 register has been cleared (from inspecting the ports with a userspace app). On the ICH7 you can directly set this bit by 'or'ing the contents of the PM1 port (0x404) with the value 0x01. Currently in my custom-patched kernel I have a quick outw(1, 0x404); as soon as the system comes back from sleep (before re-enabling interrupts, even). This fixes the problem and no spurious irq9's are issued. This works smashingly well for me but unfortunately it's a gigantic ugly hack. I've been talking to Matthew Garrett (mjg59) about this problem and he suggested that it might be at least a tiny bit cleaner to put a call to acpi_enable() there instead (set SCI_EN indirectly since the ACPI spec says it might not be correct to set it directly). Unfortunately, when I do this the machine locks on resume. So I'm writing this list to ask a couple of things: 1) Why do y'all think SCI_EN is being cleared when the machine goes to sleep and wakes up again? 2) What is the best way of dealing with this problem in a non-hackish way? I'm not on the list so please reply-to-all. Cheers signature.asc Description: This is a digitally signed message part
Re: [patch 12/13] Fix HPET operation on 64-bit NVIDIA platforms
Hi,
I experience this kernel panic during boot with acpi=off and IIRC
pci=noacpi, but what I like to know if this can resolve any other
problems on my bug: http://bugzilla.kernel.org/show_bug.cgi?id=6419
http://bugzilla.kernel.org/show_bug.cgi?id=6419#c17
btw I will try this patch anyway
Thanks,
On Thu, 2006-06-01 at 20:18 -0700, [EMAIL PROTECTED] wrote:
From: Andy Currid [EMAIL PROTECTED]
This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
that have HPET enabled.
When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
advertised as such in the ACPI APIC table - but an earlier workaround in the
kernel was ignoring this override. The fix is to honor timer IRQ overrides
from ACPI when HPET is detected on an NVIDIA platform.
Signed-off-by: Andy Currid [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: Yu, Luming [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/x86_64/kernel/io_apic.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff -puN
arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-platforms
arch/x86_64/kernel/io_apic.c
---
devel/arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-platforms
2006-06-01 20:17:10.0 -0700
+++ devel-akpm/arch/x86_64/kernel/io_apic.c 2006-06-01 20:17:10.0
-0700
@@ -271,6 +271,18 @@ __setup(enable_8254_timer, setup_enabl
#include linux/pci_ids.h
#include linux/pci.h
+
+#ifdef CONFIG_ACPI
+
+static int nvidia_hpet_detected __initdata;
+
+static int __init nvidia_hpet_check(unsigned long phys, unsigned long size)
+{
+ nvidia_hpet_detected = 1;
+ return 0;
+}
+#endif
+
/* Temporary Hack. Nvidia and VIA boards currently only work with IO-APIC
off. Check for an Nvidia or VIA PCI bridge and turn it off.
Use pci direct infrastructure because this runs before the PCI subsystem.
@@ -317,11 +329,19 @@ void __init check_ioapic(void)
return;
case PCI_VENDOR_ID_NVIDIA:
#ifdef CONFIG_ACPI
- /* All timer overrides on Nvidia
-seem to be wrong. Skip them. */
- acpi_skip_timer_override = 1;
- printk(KERN_INFO
- Nvidia board detected. Ignoring ACPI timer override.\n);
+ /*
+ * All timer overrides on Nvidia are
+ * wrong unless HPET is enabled.
+ */
+ nvidia_hpet_detected = 0;
+ acpi_table_parse(ACPI_HPET,
+ nvidia_hpet_check);
+ if (nvidia_hpet_detected == 0) {
+ acpi_skip_timer_override = 1;
+ printk(KERN_INFO Nvidia board
+ detected. Ignoring ACPI
+ timer override.\n);
+ }
#endif
/* RED-PEN skip them on mptables too? */
return;
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 12/13] Fix HPET operation on 64-bit NVIDIA platforms
This patch won't have any affect on your system; you're running a
VIA-based Intel platform, and this patch only applies to NVIDIA-based
platforms (i.e. nForce chipset).
Andy
-Original Message-
From: Sergio Monteiro Basto [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 06, 2006 08:07
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-acpi@vger.kernel.org; Andy Currid;
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [patch 12/13] Fix HPET operation on 64-bit NVIDIA platforms
Hi,
I experience this kernel panic during boot with acpi=off and IIRC
pci=noacpi, but what I like to know if this can resolve any other
problems on my bug: http://bugzilla.kernel.org/show_bug.cgi?id=6419
http://bugzilla.kernel.org/show_bug.cgi?id=6419#c17
btw I will try this patch anyway
Thanks,
On Thu, 2006-06-01 at 20:18 -0700, [EMAIL PROTECTED] wrote:
From: Andy Currid [EMAIL PROTECTED]
This patch fixes a kernel panic during boot that occurs on NVIDIA
platforms that have HPET enabled.
When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2
and is advertised as such in the ACPI APIC table - but an earlier
workaround in the kernel was ignoring this override. The fix is to
honor timer IRQ overrides from ACPI when HPET is detected on an NVIDIA
platform.
Signed-off-by: Andy Currid [EMAIL PROTECTED]
Cc: Brown, Len [EMAIL PROTECTED]
Cc: Yu, Luming [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/x86_64/kernel/io_apic.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff -puN
arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-platfor
ms arch/x86_64/kernel/io_apic.c
---
devel/arch/x86_64/kernel/io_apic.c~fix-hpet-operation-on-64-bit-nvidia-p
latforms2006-06-01 20:17:10.0 -0700
+++ devel-akpm/arch/x86_64/kernel/io_apic.c 2006-06-01
20:17:10.0 -0700
@@ -271,6 +271,18 @@ __setup(enable_8254_timer, setup_enabl
#include linux/pci_ids.h #include linux/pci.h
+
+#ifdef CONFIG_ACPI
+
+static int nvidia_hpet_detected __initdata;
+
+static int __init nvidia_hpet_check(unsigned long phys, unsigned long
+size) {
+ nvidia_hpet_detected = 1;
+ return 0;
+}
+#endif
+
/* Temporary Hack. Nvidia and VIA boards currently only work with
IO-APIC
off. Check for an Nvidia or VIA PCI bridge and turn it off.
Use pci direct infrastructure because this runs before the PCI
subsystem.
@@ -317,11 +329,19 @@ void __init check_ioapic(void)
return;
case PCI_VENDOR_ID_NVIDIA:
#ifdef CONFIG_ACPI
- /* All timer overrides on Nvidia
-seem to be wrong. Skip them.
*/
- acpi_skip_timer_override = 1;
- printk(KERN_INFO
- Nvidia board detected. Ignoring ACPI timer override.\n);
+ /*
+ * All timer overrides on Nvidia
are
+ * wrong unless HPET is enabled.
+ */
+ nvidia_hpet_detected = 0;
+ acpi_table_parse(ACPI_HPET,
+
nvidia_hpet_check);
+ if (nvidia_hpet_detected == 0) {
+ acpi_skip_timer_override
= 1;
+ printk(KERN_INFO Nvidia
board
+ detected. Ignoring
ACPI
+ timer
override.\n);
+ }
#endif
/* RED-PEN skip them on mptables
too? */
return;
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi
in the body of a message to [EMAIL PROTECTED] More majordomo
info at http://vger.kernel.org/majordomo-info.html
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3: oops when ejecting dock
On Mon, 2006-06-05 at 17:54 -0700, Jeremy Fitzhardinge wrote: Kristen Accardi wrote: I was able to reproduce this issue on an x40 - I found a bug in the code, however, when I fixed that bug I seem to have uncovered another one. I'll send you a patch hopefully in the next day or so. Great, looking forward to it. Do you know if this will properly disconnect the optical drive, or does that need some more ata/ide support? Thanks, J I don't know - this is something I am trying to look into, but don't really have the equipment to test right now. ASAIK, minimally you will need to have the very latest libata stuff that includes some kind of hotplug capability (I've copied the linux-ide list in case they can answer this question). I don't know if this is actually in -mm or in some separate tree. I'd like to work with you on making this work if you are willing - hopefully it will Just Work, but if not perhaps we can figure out what needs to be done. Thanks, Kristen - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm3: oops when ejecting dock
On Mon, 2006-06-05 at 17:54 -0700, Jeremy Fitzhardinge wrote:
Kristen Accardi wrote:
I was able to reproduce this issue on an x40 - I found a bug in the
code, however, when I fixed that bug I seem to have uncovered another
one. I'll send you a patch hopefully in the next day or so.
Great, looking forward to it. Do you know if this will properly
disconnect the optical drive, or does that need some more ata/ide support?
Thanks,
J
So, here is a patch which will fix the bug. The problem that I found
after I fixed the bug occurs in this circumstance:
1. boot in ultrabase
2. undock
But not in this case:
1. boot outside base
2. dock/undock etc.
The symptom of the problem is that you will undock and your machine will
get a softlockup on a CPU and just hang. Checking the log file (when
possible) shows lots errors from hdc: and ide: (this ultrabase has a
cdrom on it which would be hdc). I am using an x40 to duplicate the
issue, so you may have a different experience than I do. The problem
seems to be that the cdrom that is on the ultrabase is not unplugging
gracefully. I may have to hook up with whoever is working on the ide
hotplug and see if this is something I can fix.
Incidentally, the reason it works fine when you boot outside the base
and then dock/undock is because the cdrom is also not getting properly
inserted. So, it appears to power it on, but it is not actually being
hotplugged.
anyway, this bug fix is needed either way... Andrew can you apply it?
Thanks,
Kristen
Properly use return value from acpi_get_device
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
---
drivers/acpi/dock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6-mm.orig/drivers/acpi/dock.c
+++ 2.6-mm/drivers/acpi/dock.c
@@ -273,7 +273,7 @@ static void dock_remove_acpi_device(acpi
struct acpi_device *device;
int ret;
- if (acpi_bus_get_device(handle, device)) {
+ if (!acpi_bus_get_device(handle, device)) {
ret = acpi_bus_trim(device, 1);
if (ret)
pr_debug(error removing bus, %x\n, -ret);
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
what is MCFG area ?
http://lkml.org/lkml/2006/3/23/213 On my buggy computer i get cat dmesg09 | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x05000602 MSFT 0x0097) @ 0x3ffb0410 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. Should ACPI read MCFG area ? Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: 2.6.17-rc5-mm3: oops when ejecting dock
On Tue, 2006-06-06 at 16:34 -0700, Jeremy Fitzhardinge wrote: Kristen Accardi wrote: So, here is a patch which will fix the bug. The problem that I found after I fixed the bug occurs in this circumstance: 1. boot in ultrabase 2. undock But not in this case: 1. boot outside base 2. dock/undock etc. The symptom of the problem is that you will undock and your machine will get a softlockup on a CPU and just hang. Checking the log file (when possible) shows lots errors from hdc: and ide: (this ultrabase has a cdrom on it which would be hdc). I am using an x40 to duplicate the issue, so you may have a different experience than I do. The problem seems to be that the cdrom that is on the ultrabase is not unplugging gracefully. I may have to hook up with whoever is working on the ide hotplug and see if this is something I can fix. Incidentally, the reason it works fine when you boot outside the base and then dock/undock is because the cdrom is also not getting properly inserted. So, it appears to power it on, but it is not actually being hotplugged. I've observed this without the acpi dock driver present. I was wondering if the ibm acpi ultrabay file (bay) entry could be used to eject the optical device. It doesn't appear on the X60 (listed as not supported), probably because the ACPI name changed to SATA from than IDE0; I haven't really looked into it yet. But I think the basic problem is that the IDE layer doesn't seem to support hot add/remove of devices. Using the eject file won't help for a couple of other reasons besides just the name change. First, it requires that the device be present at boot. Second, AFAIK it just calls the device's _EJ0 method, which I don't think is really the only thing that is needed here. I think we also need a generic way to do this without using the ibm driver. You could scan the acpi namespace for IDE controllers based on checking for some methods that are used only in IDE or SATA devices and write a acpi driver to handle insert/remove events, but it seems like for device hotplug though you'd still somehow need to rescan from ide. To me it seems unwise to do anything outside the ide subsystem other than notify of an event and call some handler or something. I guess that means that at present the acpi dock driver does nothing, but it at least gives us an event to hang the ata device events off once the subsystem supports hot (or even warm) device add/remove. J - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: what is MCFG area ?
On my buggy computer i get cat dmesg09 | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x05000602 MSFT 0x0097) @ 0x3ffb0410 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. I'm getting exactly the same messages, just the numbers in the MCFG line are different: [EMAIL PROTECTED]:~# dmesg | grep MM\|MCFG ACPI: MCFG (v001 A M I OEMMCFG 0x11000524 MSFT 0x0097) @ 0x3f7d03f0 PCI: BIOS Bug: MCFG area is not E820-reserved PCI: Not using MMCONFIG. PCI-DMA: Disabling IOMMU. It's on a MSI motherboard with Intel 945 chipset (MS-7210). The machine otherwise works very well. The Disabling IOMMU message I'm getting also on another, Nvidia NF4/Opteron based board, without this MCFG bug. I think it's unrelated and because Linux properly detected the BIOS bug and probably fixed it, I think the MCFG message is harmless. With regards, Pavel Troller - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ASRock K7Upgrade-880 with S3
I'm prefacing my question with email to the FreeBSD ACPI list as this problem is to ultimately debug an ACPI problem in FreeBSD. -- START FreeBSD Email -- I'm trying to get my desktop to STR (S3) and can't even get S3 to semi-powered down state. 6.1-RELEASE-p1 I've updated the BIOS to the latest version. When I do an acpiconf -s 3 the suspend get all the way into the AcpiEnterSleepState function and begins to write registers. The last line I see (with full ACPI debugging enabled): heregs-0708 HwRegisterWrite : Entry Then the power light on the case starts to blink seeming to indicate that it is in suspend, except I can still see output on the monitor and the fans and harddrives are still running. Then when I press the power button to try to bring the system back up it then displays: heregs-0708 HwRegisterWrite : Exit and then continues with a few more HwRegisterWrite and then exits the AcpiEnterSleepState function and then does nothing. The system shows no life of coming back. I then need to perform a cold boot, because if I just hit the reset button the system doesn't restart to the point where it gets to the BIOS screen. My acpidump output is at: http://am-productions.biz/docs/bigguy.asl I've fixed the errors in the asl and tried using that, but it showed the same problem. http://am-productions.biz/docs/bigguy-fix.asl dmesg: http://am-productions.biz/docs/bigguy.dmesg When I do an acpidump -dt I see the following message displayed: acpidump: RSDT entry 2 (sig OEMB) is corrupt Windows isn't installed on this system so I can't compare it with that. I tried suspending with Knoppix (2006-06-01) and that worked a bit better. It successfully shuts off the disks on suspend, but the case fans and video card/monitor were still on. When you press the power button again in knoppix it successfully brought the system back to life. Getting it to the point of Knoppix would be a good start. S1 in FreeBSD does work, but it doesn't shut anything down, so it's not really useful. hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S3 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 5 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% debug.acpi.acpi_ca_version: 0x20041119 I've also tried CURRENT with ACPI-CA 20051021 with the same results. -- END FreeBSD Email -- Now for the Linux part. Since Linux (Knoppix with kernel 2.6.17) seems to get at least some of the suspend/resume right I'm trying to figure out how to get it to display the full debug information to compare with FreeBSD. I'm looking for how to do the following in Linux: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html Specifically the ACPI layer and level debugging mention at the end of the page. Thanks, -- Anish Mistry pgpNBisK2SkFO.pgp Description: PGP signature
