* 2.6.0-test4: Tested the Power Management Update
@ 2003-08-31 2:34 Michael Frank
2003-08-31 7:52 ` Michael Frank
2003-09-02 23:28 ` Patrick Mochel
0 siblings, 2 replies; 4+ messages in thread
From: Michael Frank @ 2003-08-31 2:34 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel
Patrick,
Thank you for taking this on.
1) IMPROVED: S3/mem works better than ever - no resume failures encountered!
2) WORKS AGAIN: S4/disk functionality restored, no problems seen.
3) NEW: ACPI alarm function has new problem:
echo > /proc/acpi/alarm often (not always) causes:
Aug 31 09:16:36 mhfl2 kernel: irq 9: nobody cared!
Aug 31 09:16:36 mhfl2 kernel: Call Trace:
Aug 31 09:16:36 mhfl2 kernel: [<c010c35b>] __report_bad_irq+0x2b/0x90
Aug 31 09:16:36 mhfl2 kernel: [<c010c363>] __report_bad_irq+0x33/0x90
Aug 31 09:16:36 mhfl2 kernel: [<c010c438>] note_interrupt+0x50/0x78
Aug 31 09:16:36 mhfl2 kernel: [<c010c5b2>] do_IRQ+0x96/0xf4
Aug 31 09:16:36 mhfl2 kernel: [<c010afe8>] common_interrupt+0x18/0x20
Aug 31 09:16:36 mhfl2 kernel: [<c011dd58>] do_softirq+0x48/0xb0
Aug 31 09:16:36 mhfl2 kernel: [<c010c600>] do_IRQ+0xe4/0xf4
Aug 31 09:16:36 mhfl2 kernel: [<c010afe8>] common_interrupt+0x18/0x20
Aug 31 09:16:36 mhfl2 kernel: [<c01e110d>] acpi_os_write_port+0x35/0x50
Aug 31 09:16:36 mhfl2 kernel: [<c01f65de>] acpi_hw_low_level_write+0x7e/0x11e
Aug 31 09:16:36 mhfl2 kernel: [<c01f632d>] acpi_hw_register_write+0xb9/0x1c0
Aug 31 09:16:37 mhfl2 kernel: [<c01f6046>] acpi_set_register+0x262/0x2d0
Aug 31 09:16:37 mhfl2 kernel: [<c020ac7c>] acpi_system_write_alarm+0x4f8/0x544
Aug 31 09:16:37 mhfl2 kernel: [<c01464fe>] vfs_write+0x9e/0xd0
Aug 31 09:16:37 mhfl2 kernel: [<c01465b0>] sys_write+0x30/0x50
Aug 31 09:16:37 mhfl2 kernel: [<c010adc7>] syscall_call+0x7/0xb
Aug 31 09:16:37 mhfl2 kernel:
Aug 31 09:16:37 mhfl2 kernel: handlers:
Aug 31 09:16:37 mhfl2 kernel: [<c01e0f6c>] (acpi_irq+0x0/0x1c)
Aug 31 09:16:37 mhfl2 kernel: Disabling IRQ #9
$ cat /proc/interrupts
CPU0
0: 786435 XT-PIC timer
1: 2266 XT-PIC i8042
2: 0 XT-PIC cascade
5: 1 XT-PIC 0000:00:12.0
8: 0 XT-PIC rtc
9: 96 XT-PIC acpi
10: 1003 XT-PIC eth0
12: 8252 XT-PIC i8042
14: 6937 XT-PIC ide0
NMI: 0
ERR: 2
4) UNCHANGED: Alarm wakeup from S3 powers up and hangs.
5) MAJOR UNCHANGED: (ACPI routed) PCI interrupt links still stay dead
on S3 resume as their state was lost upon powerdown of the router and
on resume USB, Network and PCMCIA/Yenta are dead.
I had posted a patch earlier to set all links again in ACPI prior to
resuming devices, Russell said it was discussed at OLS, what will be
done about it?
6) MINOR UNCHANGED: As to the mouse, i8042 does not resume, so I
config i8042 as a module and reload it on resume. However, current
drivers/input/serio/Kconfig makes this impossible, which I whined
about a few times already ;)
config SERIO_I8042
tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
Maybe bug in kconfig: Even when X86 if off, can't touch i8042
using menuconfig.
Regards
Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.0-test4: Tested the Power Management Update
2003-08-31 2:34 2.6.0-test4: Tested the Power Management Update Michael Frank
@ 2003-08-31 7:52 ` Michael Frank
2003-09-02 23:28 ` Patrick Mochel
1 sibling, 0 replies; 4+ messages in thread
From: Michael Frank @ 2003-08-31 7:52 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel
On Sunday 31 August 2003 10:34, Michael Frank wrote:
> 6) MINOR UNCHANGED: As to the mouse, i8042 does not resume, so I
> config i8042 as a module and reload it on resume. However, current
> drivers/input/serio/Kconfig makes this impossible, which I whined
> about a few times already ;)
>
> config SERIO_I8042
> tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
>
> Maybe bug in kconfig: Even when X86 if off, can't touch i8042
> using menuconfig.
No, just another BUG in my head: I mistook X86_GENERIC for X86
- How BRILLIANT to _hide_ X86 away in arch/i386/Kconfig - it
is even inaccessible ....
mainmenu "Linux Kernel Configuration"
config X86
bool
default y
help
This is Linux's home port. Linux was originally native to the Intel
386, and runs on all the later x86 processors including the Intel
486, 586, Pentiums, and various instruction-set-compatible chips by
AMD, Cyrix, and others.
Couldn't one have a better way of handling this ?
Regards
Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.0-test4: Tested the Power Management Update
2003-08-31 2:34 2.6.0-test4: Tested the Power Management Update Michael Frank
2003-08-31 7:52 ` Michael Frank
@ 2003-09-02 23:28 ` Patrick Mochel
2003-09-03 1:27 ` Michael Frank
1 sibling, 1 reply; 4+ messages in thread
From: Patrick Mochel @ 2003-09-02 23:28 UTC (permalink / raw)
To: Michael Frank; +Cc: linux-kernel
> 3) NEW: ACPI alarm function has new problem:
>
> echo > /proc/acpi/alarm often (not always) causes:
Heh. You can see my first attempts at kernel code there. I haven't tested
it in ages, and could probably use a cleaning up. I'll look into this.
> 4) UNCHANGED: Alarm wakeup from S3 powers up and hangs.
Noted. Will try it also.
> 5) MAJOR UNCHANGED: (ACPI routed) PCI interrupt links still stay dead
> on S3 resume as their state was lost upon powerdown of the router and
> on resume USB, Network and PCMCIA/Yenta are dead.
>
> I had posted a patch earlier to set all links again in ACPI prior to
> resuming devices, Russell said it was discussed at OLS, what will be
> done about it?
Sorry, I completely forgot about this. Would you please send me the patch
again? It's ok if it's old and doesn't apply. We'll get it worked out and
fixed.
> 6) MINOR UNCHANGED: As to the mouse, i8042 does not resume, so I
> config i8042 as a module and reload it on resume. However, current
> drivers/input/serio/Kconfig makes this impossible, which I whined
> about a few times already ;)
I presume by your later message you got this worked out ok?
Thanks for testing,
Pat
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.0-test4: Tested the Power Management Update
2003-09-02 23:28 ` Patrick Mochel
@ 2003-09-03 1:27 ` Michael Frank
0 siblings, 0 replies; 4+ messages in thread
From: Michael Frank @ 2003-09-03 1:27 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel
On Wednesday 03 September 2003 07:28, Patrick Mochel wrote:
> > 5) MAJOR UNCHANGED: (ACPI routed) PCI interrupt links still stay dead
> > on S3 resume as their state was lost upon powerdown of the router and
> > on resume USB, Network and PCMCIA/Yenta are dead.
> >
> > I had posted a patch earlier to set all links again in ACPI prior to
> > resuming devices, Russell said it was discussed at OLS, what will be
> > done about it?
>
> Sorry, I completely forgot about this. Would you please send me the patch
> again? It's ok if it's old and doesn't apply. We'll get it worked out and
> fixed.
>
This message of 18 July refers to and patch is against 2.6.0-test1.
Current implementation:
- Looses PCI IRQ links on resume from
ACPI S1-S4 when the router was powered down.
This results in nonfunctional PCI IRQ's
after S3 for example.
- Does not set PCI IRQ links claimed to be set by BIOS,
which results in the IRQ not working when BIOS did
not really set it or when setting was "lost".
- BIOS enabled IRQ's are frequently reused resulting in 2
links being assigned to the same IRQ while other
IRQ's remain available and unused.
This patch:
1) Always sets ACPI-routed PCI interrupt links regardless of whether
link is claimed to be set by BIOS already.
2) Restores ACPI-routed PCI interrupt links on resume from ACPI S1-S4
3) Prevents BIOS-enabled IRQ's being reused by BIOS-disabled IRQ's
On my system, all PCI interrupts are now routed without conflicts
and functional on resume. yenta_socket and e100 resume fine.
ohci-hcd must be reloaded, as it's interrupt handler does not
survive suspending.
===== include/acpi/acpi_drivers.h 1.15 vs edited =====
--- 1.15/include/acpi/acpi_drivers.h Wed Jun 25 05:16:55 2003
+++ edited/include/acpi/acpi_drivers.h Fri Jul 18 17:49:16 2003
@@ -59,6 +59,7 @@
/* ACPI PCI Interrupt Link (pci_link.c) */
+int acpi_pci_links_set (void);
int acpi_pci_link_check (void);
int acpi_pci_link_get_irq (acpi_handle handle, int index);
===== drivers/acpi/sleep/main.c 1.24 vs edited =====
--- 1.24/drivers/acpi/sleep/main.c Wed Jul 9 06:13:14 2003
+++ edited/drivers/acpi/sleep/main.c Fri Jul 18 18:11:31 2003
@@ -264,7 +264,10 @@
acpi_leave_sleep_state(state);
acpi_system_restore_state(state);
- /* make sure interrupts are enabled */
+ /* Resume pci interrupt links */
+ acpi_pci_links_set();
+
+ /* make sure interrupts are enabled */
ACPI_ENABLE_IRQS();
/* reset firmware waking vector */
===== drivers/acpi/pci_link.c 1.15 vs edited =====
--- 1.15/drivers/acpi/pci_link.c Fri Feb 28 08:24:14 2003
+++ edited/drivers/acpi/pci_link.c Fri Jul 18 17:51:16 2003
@@ -294,10 +294,6 @@
if (!link || !irq)
return_VALUE(-EINVAL);
- /* See if we're already at the target IRQ. */
- if (irq == link->irq.active)
- return_VALUE(0);
-
/* Make sure the target IRQ in the list of possible IRQs. */
for (i=0; i<link->irq.possible_count; i++) {
if (irq == link->irq.possible[i])
@@ -368,7 +364,6 @@
return_VALUE(0);
}
-
/* --------------------------------------------------------------------------
PCI Link IRQ Management
-------------------------------------------------------------------------- */
@@ -396,6 +391,42 @@
10000, 100000, 100000, 100000,
};
+/*
+ * acpi_pci_links_set sets all PCI IRQ links
+ * on completion of acpi_pci_link_check
+ * or
+ * on resume from S1-S4 as the PCI IRQ router
+ * may have lost power
+ * W
+ */
+
+int
+acpi_pci_links_set (void)
+{
+ int result = 0;
+
+ struct list_head *node = NULL;
+ struct acpi_pci_link *link = NULL;
+
+ ACPI_FUNCTION_TRACE("acpi_pci_links_set");
+
+ list_for_each(node, &acpi_link.entries) {
+
+ link = list_entry(node, struct acpi_pci_link, node);
+ if (!link) {
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
+ continue;
+ }
+
+ if (link->irq.active) {
+ printk(PREFIX "%s [%s] enabled at IRQ %d\n",
+ acpi_device_name(link->device),
+ acpi_device_bid(link->device), link->irq.active);
+ result |= acpi_pci_link_set(link, link->irq.active) != 0;
+ }
+ }
+ return_VALUE(result ? -ENODEV : 0);
+}
int
acpi_pci_link_check (void)
@@ -417,8 +448,9 @@
continue;
}
- if (link->irq.active)
- acpi_irq_penalty[link->irq.active] += 100;
+ /* Never use an active IRQ */
+ if (link->irq.active)
+ acpi_irq_penalty[link->irq.active] = 1000000;
else if (link->irq.possible_count) {
int penalty = 100 / link->irq.possible_count;
for (i=0; i<link->irq.possible_count; i++) {
@@ -432,7 +464,6 @@
* Pass #2: Enable boot-disabled Links at 'best' IRQ.
*/
list_for_each(node, &acpi_link.entries) {
- int irq = 0;
int i = 0;
link = list_entry(node, struct acpi_pci_link, node);
@@ -441,33 +472,27 @@
continue;
}
- if (link->irq.active)
+ /* Never use BIOS enabled IRQ's */
+ if (link->irq.active)
continue;
-
- irq = link->irq.possible[0];
+ link->irq.active = link->irq.possible[0];
/*
* Select the best IRQ. This is done in reverse to promote
* the use of IRQs 9, 10, 11, and >15.
*/
for (i=(link->irq.possible_count-1); i>0; i--) {
- if (acpi_irq_penalty[irq] > acpi_irq_penalty[link->irq.possible[i]])
- irq = link->irq.possible[i];
+ if (acpi_irq_penalty[link->irq.active] > acpi_irq_penalty[link->irq.possible[i]])
+ link->irq.active = link->irq.possible[i];
}
- /* Enable the link device at this IRQ. */
- acpi_pci_link_set(link, irq);
-
- acpi_irq_penalty[link->irq.active] += 100;
-
- printk(PREFIX "%s [%s] enabled at IRQ %d\n",
- acpi_device_name(link->device),
- acpi_device_bid(link->device), link->irq.active);
+ /* Never re-use an activated IRQ */
+ acpi_irq_penalty[link->irq.active] = 1000000;
}
-
- return_VALUE(0);
+
+ /* Now set all links */
+ return acpi_pci_links_set();
}
-
int
acpi_pci_link_get_irq (
> > 6) MINOR UNCHANGED: As to the mouse, i8042 does not resume, so I
> > config i8042 as a module and reload it on resume. However, current
> > drivers/input/serio/Kconfig makes this impossible, which I whined
> > about a few times already ;)
>
> I presume by your later message you got this worked out ok?
>
After biting my lower rear portion again - (last time was with
logbuffer size = 256), but here is no documentation to read...
Could there be another menu to select system type when x86
-Standard-PC EMBEDDED=0 X86=1, MMU=1, VID16=1, SBUS=0, GENERIC_ISA_DMA=1
Use this for ease of configuration in most PC applications.
-Custom-PC EMBEDDED=0 X86=0, MMU=1, VID16=1, SBUS=0, GENERIC_ISA_DMA=1
Use this in specialized PC applications to enable less
frequently used configuration options.
Beware that this requires more intricate knowledge of PC
hardware and the kernel subsystems
-Embedded EMBEDDED=1 X86=0, MMU=user, VID16=user, SBUS=user, GENERIC_ISA_DMA=user
Use this option when running the kernel on an embedded system to
maximize configuration capability. This option is generally unsuitable
in PC applications.
Regards
Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-09-03 1:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-08-31 2:34 2.6.0-test4: Tested the Power Management Update Michael Frank
2003-08-31 7:52 ` Michael Frank
2003-09-02 23:28 ` Patrick Mochel
2003-09-03 1:27 ` Michael Frank
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox