linux-kernel - Re: [PATCH] ACPI: Do not modify SCI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1230585366.4667.26.camel@maxim-laptop>
Date:	Mon, 29 Dec 2008 23:16:06 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Len Brown <lenb@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH] ACPI: Do not modify SCI_EN directly

On Mon, 2008-12-29 at 19:19 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@...k.pl>
> 
> 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 this
matters) and it doesn't come back after second suspend, subsequently  I
figured out that bios doesn't pass control to linux at all, after second
resume, and moreover, a suspend to disk , 'fixes' this and enables me to
do another suspend/resume cycle. This is a poor man workaround I use
now.

I already told about this here, and many peoples from here (including
you) tried to help me, but unfortunately this is very weird issue, and
nether me nor you can do much about, it is all about guesswork,
something, at least something is 'armed' on resume, so it confuses bios
then (it could be that yet, the critical part that confuses bios happens
in second suspend time)

Needless to say that nothing useful appears in the logs, and everything
seems 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 all
patches like this to test, so I build it weekly, and who knows, maybe
something like above will fix it.

Anyway I would gladly test any patch that you suspect might be involved
here.

Also, I tried to do a I/O port and PCI config dump before and after a
resume, aka in 'armed' and 'unarmed' state.

While there were many I/O port registers changes, and I yet to process
it bit after bit (and unfortunately there are plenty of undocumented
stuff), 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-compatible
interrupts
      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 PIRQs
that are being used. The value of this bit may subsequently be changed
by 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 in
case, I don't think it is useful.

Best regards,
	Maxim Levitsky

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/