Re: [PATCH] ACPI: Do not modify SCI_EN directly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-12-29 at 19:19 +0100, Rafael J. Wysocki wrote:> From: Rafael J. Wysocki <rjw@xxxxxxx>> > According to the ACPI specification the SCI_EN flag is controlled by> the hardware, which sets this flag to inform the kernel that ACPI is> enabled.  For this reason, we shouldn't try to modify SCI_EN> directly.  Also, we don't need to do it in irqrouter_resume(), since> lower-level resume code takes care of enabling ACPI in case it hasn't> been enabled by the BIOS before passing control to the kernel (which> by the way is against the ACPI specification).

Hi, 
I am an unfortunate owner of an acer notebook ( aspire 5720 if thismatters) and it doesn't come back after second suspend, subsequently  Ifigured out that bios doesn't pass control to linux at all, after secondresume, and moreover, a suspend to disk , 'fixes' this and enables me todo another suspend/resume cycle. This is a poor man workaround I usenow.
I already told about this here, and many peoples from here (includingyou) tried to help me, but unfortunately this is very weird issue, andnether me nor you can do much about, it is all about guesswork,something, at least something is 'armed' on resume, so it confuses biosthen (it could be that yet, the critical part that confuses bios happensin second suspend time)
Needless to say that nothing useful appears in the logs, and everythingseems to work fine following each successful resume (both disk and ram).
so I have a question, do you have a git branch to pull that includes allpatches like this to test, so I build it weekly, and who knows, maybesomething like above will fix it.
Anyway I would gladly test any patch that you suspect might be involvedhere.

Also, I tried to do a I/O port and PCI config dump before and after aresume, aka in 'armed' and 'unarmed' state.
While there were many I/O port registers changes, and I yet to processit bit after bit (and unfortunately there are plenty of undocumentedstuff), I noticed a meaningful change between bad and good state:

>From ICH8 manual:
"PIRQ[n]_ROUT—PIRQ[A,B,C,D] Routing Control Register
and
PIRQ[n]_ROUT—PIRQ[E,F,G,H]
Interrupt Routing Enable (IRQEN) — R/W.0 = The corresponding PIRQ is routed to one of the ISA-compatibleinterrupts      specified in bits[3:0].1 = The PIRQ is not routed to the 8259.
NOTE: BIOS must program this bit to 0 during POST for any of the PIRQsthat are being used. The value of this bit may subsequently be changedby the OS when setting up for I/O APIC interrupt delivery mode."

bit #7 of all those regs is '1' in good state, and '0' in bad state.
I tried to change it back, but this didn't help, so I post this just incase, I don't think it is useful.

Best regards,	Maxim Levitsky


_______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux