public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* Re: acpi-20040715: functional regression on ASUS M2N
@ 2004-08-05 18:49 Nathan Bryant
       [not found] ` <4112814C.2070808-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
  0 siblings, 1 reply; 25+ messages in thread
From: Nathan Bryant @ 2004-08-05 18:49 UTC (permalink / raw)
  To: ACPI Developers; +Cc: Li, Shaohua, Georg C. F. Greve


Hi all. Some thoughts on this:

The ELCR save/restore patch is causing regressions for some people. What 
if the problem is that we're saving/restoring registers at the wrong time?

For example, on the Intel PIIX, the PIC is a child of PCI device 
31:function 0. What if this PCI device is disabled at the time we decide 
to save ELCR? If the I/O space is not mapped, we would probably read 
0xff in this case, I think, and I think that would set everything to 
level. What could be disabling it?

Georg, can you add some printk's to save_ELCR and log the values that we 
are actually saving?

Nathan



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: acpi-20040715: functional regression on ASUS M2N
@ 2004-08-31  8:45 Li, Shaohua
       [not found] ` <B44D37711ED29844BEA67908EAF36F03AC6ACF-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 25+ messages in thread
From: Li, Shaohua @ 2004-08-31  8:45 UTC (permalink / raw)
  To: Georg C. F. Greve; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

[-- Attachment #1: Type: text/plain, Size: 8565 bytes --]

Hi,
I guess it's the problem I encountered (the dmesg is the same as mine).
Attached email includes two workarounds for this issue, but no final
solution yet.

Thanks,
Shaohua

>-----Original Message-----
>From: Georg C. F. Greve [mailto:greve-1r/uNngapc3YtjvyW6yDsg@public.gmane.org] On Behalf Of Georg C.
F.
>Greve
>Sent: Tuesday, August 31, 2004 4:16 PM
>To: ACPI Developers; Li, Shaohua
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>Hi all,
>
>I thought you might like to know that I've just managed to build a
>kernel that allows me to suspend to ram again -- and in fact better
>than before in so far as the network cards work correctly after
>resume. Unfortunately this only works once. So there is progress on
>the problem, even though it is not fully solved yet.
>
>The kernel is a 2.6.9-rc1 with the following patches applied in this
>order:
>
> acpi-20040816-26-latest-release.diff.bz2
> alsa-bk-2004-08-26.patch.gz
> software-suspend-2.0.0.105-for-2.6.8.1.tar.bz2
>
>(Note: the software suspend 2 has one reject that is apparently
> relatively easy to fix, however software suspend 2 does not work
> anymore on this kernel. On suspend it does not switch to the suspend
> screen, although the machine appears to be suspending successfully,
> but on resume the machine hangs when "Copying original kernel back")
>
>Please note that the ALSA patch is absolutely necessary for this to
>work, when I left it out, the resume from suspend to ram hung. Only
>with the patch applied it resumes properly and I see the messages for
>irq 6 and irq 11 having been disabled during the suspend phase.
>
>In the syslog it shows that something still appears to be fishy,
>however:
>
> kernel: Back to C!
> kernel: irq 6: nobody cared!
> kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
> kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
> kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
> kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
> kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [time_resume+66/74] time_resume+0x42/0x4a
> kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
> kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
> kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
> kernel:  [enter_state+105/161] enter_state+0x69/0xa1
> kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
> kernel:  [acpi_system_write_sleep+96/139]
>acpi_system_write_sleep+0x60/0x8b
> kernel:  [acpi_system_write_sleep+117/139]
>acpi_system_write_sleep+0x75/0x8b
> kernel:  [acpi_system_write_sleep+0/139]
acpi_system_write_sleep+0x0/0x8b
> kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
> kernel:  [sys_write+81/128] sys_write+0x51/0x80
> kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> kernel: handlers:
> kernel: [snd_intel8x0_interrupt+0/542]
(snd_intel8x0_interrupt+0x0/0x21e)
> kernel: Disabling IRQ #6
> kernel: irq 11: nobody cared!
> kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
> kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
> kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
> kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
> kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [time_resume+66/74] time_resume+0x42/0x4a
> kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
> kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
> kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
> kernel:  [enter_state+105/161] enter_state+0x69/0xa1
> kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
> kernel:  [acpi_system_write_sleep+96/139]
>acpi_system_write_sleep+0x60/0x8b
> kernel:  [acpi_system_write_sleep+117/139]
>acpi_system_write_sleep+0x75/0x8b
> kernel:  [acpi_system_write_sleep+0/139]
acpi_system_write_sleep+0x0/0x8b
> kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
> kernel:  [sys_write+81/128] sys_write+0x51/0x80
> kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> kernel: handlers:
> kernel: [pg0+536303635/1068441600] (ohci_irq_handler+0x0/0x80e
[ohci1394])
> kernel: Disabling IRQ #11
> kernel: PM: Finishing up.
> [...]
> kernel: ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) ->
IRQ
>11
> kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) ->
IRQ 5
> kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 7 (level, low) ->
IRQ 7
> kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 4 (level, low) ->
IRQ 4
> kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
> kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) ->
IRQ 7
> kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 6 (level, low) ->
IRQ 6
> kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64
> kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) ->
IRQ 6
> kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) ->
IRQ 7
> kernel: ACPI: PCI interrupt 0000:01:03.2[C] -> GSI 11 (level, low) ->
IRQ
>11
> [...]
> kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) ->
IRQ 6
> kernel: Yenta: CardBus bridge found at 0000:01:03.0 [1043:1754]
> kernel: yenta 0000:01:03.0: Preassigned resource 1 busy,
reconfiguring...
> kernel: yenta 0000:01:03.0: Preassigned resource 2 busy,
reconfiguring...
> kernel: yenta 0000:01:03.0: Preassigned resource 3 busy,
reconfiguring...
> kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 6
> kernel: Socket status: 30000006
> kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) ->
IRQ 7
> kernel: Yenta: CardBus bridge found at 0000:01:03.1 [1043:1754]
> kernel: yenta 0000:01:03.1: Preassigned resource 0 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 1 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 2 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 3 busy,
reconfiguring...
> kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 7
> [...]
> kernel: ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M)
USB
>2.0 EHCI Controller
> kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
> kernel: ehci_hcd 0000:00:1d.7: irq 4, pci mem e0434c00
> kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus
number
>4
> kernel: PCI: cache line size of 32 is not supported by device
0000:00:1d.7
> kernel: ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver
2004-
>May-10
> kernel: hub 4-0:1.0: USB hub found
> kernel: hub 4-0:1.0: 6 ports detected
> pci.agent[4271]:      ehci-hcd: loaded successfully
> [...]
> kernel: usb 1-1: control timeout on ep0out
> kernel: uhci_hcd 0000:00:1d.0: Unlink after no-IRQ?  Different ACPI or
>APIC settings may help.
>
>The second attempt at suspending gives
>
> kernel: ehci_hcd 0000:00:1d.7: remove, state 1
>
>upon stopping the hotplug services. The system does not resume but
>keeps running, apparently remaining functional.
>
>If more info is helpful, let me know.
>
>Regards,
>Georg
>
>--
>Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
>Free Software Foundation Europe
(http://fsfeurope.org)
>Brave GNU World
(http://brave-gnu-world.org)

[-- Attachment #2: Type: message/rfc822, Size: 8609 bytes --]

From: "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, <stefandoesinger-RbZlAiThDcE@public.gmane.org>, "Nathan Bryant" <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
Cc: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>, "Linux Kernel Mailing List" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
Date: Mon, 23 Aug 2004 13:58:52 +0800
Message-ID: <B44D37711ED29844BEA67908EAF36F039EA6C2-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

Right, this looks like the problem I encounter. My current test shows that the problem only occurs if ACPI changed LINK devices' IRQ. If ACPI use default LINK device IRQ, the problem went off.
Currently there are two workarounds:
1. comment one line in pci_link.c:acpi_pci_link_allocate, like below
	/*
	 * forget active IRQ that is not in possible list
	 */
	if (i == link->irq.possible_count) {
		if (acpi_strict)
			printk(KERN_WARNING PREFIX "_CRS %d not found"
				" in _PRS\n", link->irq.active);
+//		link->irq.active = 0;
	}
This disables rebalance IRQ, which fixes my problem.

2. change 'device_initcall(i8259A_init_sysfs);' to 'late_initcall(i8259A_init_sysfs);'
It seems that if OS changed BIOS IRQ router setting (like ACPI change Link device setting), IRQ router should resume before PIC. This possibly proves what Venki said.

PS. For the resume order, isn't it strange Local APIC resumes after PIT? I guess it should be the first device to resume.

Thanks,
Shaohua
>-----Original Message-----
>From: Pallipadi, Venkatesh
>Sent: Saturday, August 21, 2004 3:00 AM
>To: stefandoesinger-RbZlAiThDcE@public.gmane.org; Nathan Bryant
>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Brown, Len; Linux Kernel list; Li,
>Shaohua
>Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>
>
>
>
>>-----Original Message-----
>>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
>>Stefan Dösinger
>>Sent: Friday, August 20, 2004 9:36 AM
>>To: Nathan Bryant
>>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Brown, Len; Linux Kernel
>>list; Li, Shaohua
>>Subject: Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>>
>>Am Freitag, 20. August 2004 14:18 schrieb Nathan Bryant:
>>> Stefan -
>>>
>>> Also - did suspend/resume for the ipw2100 ever work under any kernel
>>> version?
>>Yes, it works with acpi=noirq at least up to 2.6.7(not tested
>>with later
>>versions, but I'm sure it does)
>>It works with 2.6.8-rc2 and 2.6.8-rc4 and 2.6.8.1 with acpi IRQs and a
>>modified dsdt which forces LNKE to IRQ 10. I attached a dmesg
>>output of a
>>successful resume.
>>
>>Cheers,
>>Stefan
>
>This seems to be the same resume order issue, that Shaohua is hitting.
>
>On my system the resume order looks like this:
>Resuming System Devices
>Resuming type 'cpu':
> cpu0
>aux driver resume 0xc010e410 (mtrr_restore)
>aux driver resume 0xc03365f0 (cpufreq_resume)
>Resuming type 'i8259':
> i82590
>Resuming type 'timer':
> timer0
>Resuming type 'pit':
> pit0
>Resuming type 'lapic':
> lapic0
>Resuming type 'irqrouter':
> irqrouter0
>Resuming type 'i8042':
> i80420
>
>The current theory I have for this issue is we resume pci_link driver
>A bit too late, which is causing this problem.
>
>Say a particular device doesn't do anything for suspend and resume.
>So, as soon as we resume this particular device can start
>generating interrupts. Once we have PIC enabled, it starts sending
>interrupts and no one handles that original IRQ. As pci_link that
>resumes later is reprogramming the device to different IRQ, where the
>driver is handling the device.
>
>That's probably the reason why it works with acpi=noirq or
>modified DSDT. Does it make sense?
>
>I think we have to resume pci_link device before PIC.
>We should be able to achieve this my changing the makefile orders.
>
>Thanks,
>Venki
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: acpi-20040715: functional regression on ASUS M2N
@ 2004-08-09  8:10 Li, Shaohua
  0 siblings, 0 replies; 25+ messages in thread
From: Li, Shaohua @ 2004-08-09  8:10 UTC (permalink / raw)
  To: Matthew Garrett
  Cc: Nathan Bryant, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	Georg C. F. Greve

I guess sysdev suffers from the problem much. Device core doesn't
maintain a tree for all sysdev. It's just a list, so PIC, LAPIC, PIT,
and so on may suspend/resume in random order. Don't know if it's indeed
an issue, but it looks crazy. 

Thanks,
Shaohua

>-----Original Message-----
>From: Matthew Garrett [mailto:mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org]
>Sent: Friday, August 06, 2004 11:24 PM
>To: Nathan Bryant
>Cc: ACPI Developers; Li, Shaohua; Georg C. F. Greve
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:
>
>> The ELCR save/restore patch is causing regressions for some people.
What
>> if the problem is that we're saving/restoring registers at the wrong
time?
>
>On closer investigation, I found that the system was restoring my
ioapic
>state /after/ it had started the programmable interrupt timer back up.
>Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
>seems to have greatly improved my ability to suspend and resume (which
>worked fine before the interrupt controller suspend/resume patches,
>except that I didn't get many interrupts...)
>
>There doesn't seem to be any fine-grained way to control the order of
>suspend/resume for individual drivers. It seems to be assumed that
>everything that devices depend on will be higher than them in the tree,
>and so everything will "just work" - I'm not sure this is true. As
>another example, I just had my wireless card fail to resume correctly.
>It tried to do a hotplug firmware load on resume. Which was difficult,
>because it was resumed before the IDE interface was. How can this sort
>of thing be avoided?
>
>--
>Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: acpi-20040715: functional regression on ASUS M2N
@ 2004-08-02 16:45 Nathan Bryant
       [not found] ` <410E6F9C.2040904-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
  0 siblings, 1 reply; 25+ messages in thread
From: Nathan Bryant @ 2004-08-02 16:45 UTC (permalink / raw)
  To: Georg C. F. Greve, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	shaohua.li-ral2JQCrhuEAvxtiuMwx3w

> I added your suggested patch to
> 
>   arch/i386/kernel/i8259.c
> 
> and recompiled. 
> 
> Problem persists, no difference I could tell.

I don't know why the patch masks out the reserved interrupts. None of 
the other code that sets ELCR is masking out those bits, and it all 
works fine. Possibly some chipsets use different edge/level behavior for 
these, and the save code is forcing them back to edge. Does the problem 
persist if you go into arch/i386/kernel/i8259.c and change:

static void save_ELCR(char *trigger)
{
         /* IRQ 0,1,2,8,13 are marked as reserved */
         trigger[0] = inb(0x4d0) & 0xF8;
         trigger[1] = inb(0x4d1) & 0xDE;
}

to:

static void save_ELCR(char *trigger)
{
         /* IRQ 0,1,2,8,13 are marked as reserved */
         trigger[0] = inb(0x4d0);
         trigger[1] = inb(0x4d1);
}



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: acpi-20040715: functional regression on ASUS M2N
@ 2004-07-27 12:24 Li, Shaohua
       [not found] ` <B44D37711ED29844BEA67908EAF36F036BCD7C-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 25+ messages in thread
From: Li, Shaohua @ 2004-07-27 12:24 UTC (permalink / raw)
  To: Georg C. F. Greve; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Hi,
does a patch like below help your system? Please manually add it and
try. 

Thanks,
Shaohua

static int i8259A_resume(struct sys_device *dev)
 {
+	unsigned long flags;
 	init_8259A(0);
+ 
+	spin_lock_irqsave(&i8259A_lock, flags);
	restore_ELCR(irq_trigger);
+	spin_unlock_irqrestore(&i8259A_lock, flags);
	return 0;
}

>-----Original Message-----
>From: Georg C. F. Greve [mailto:greve-1r/uNngapc3YtjvyW6yDsg@public.gmane.org] On Behalf Of Georg C.
F.
>Greve
>Sent: Tuesday, July 27, 2004 7:14 PM
>To: Matthew Garrett
>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Li, Shaohua
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>Hi all,
>
>okay, I did some more checks on the problems I experienced with
>acpi-20040715 on Intel Centrino 855GM notebook ASUS M2N.
>
>Background: As of kernel 2.6.7 suspend to RAM (s3_bios) actually
>worked and even with DRI/DRM and AGP compiled in and the X server
>running, things are working nicely.
>
>When restarting from suspend to RAM, I briefly see a yellow "inu" in
>the uppermost row for a second, then the screen flickers once and X11
>is back.
>
>Only disadvantage: network cards (both wired & ipw2100 wireless) are
>dead after suspend to ram, I need a suspend to disk (swsusp2 version
>2.0.0.100) to bring them back to life. (referred to as "fine" below)
>
>When upgrading to acpi-20040715 I discovered that resume from suspend
>to RAM was broken. Contrary to what I wrote in my previous mail, it
>seems that there is the yellow "inu" in the uppermost row and then the
>machine is dead. (referred to as "dead" below)
>
>I need a forced poweroff plus "needle-pushed reset button" to bring it
>back to life.
>
>
>Having had some time to let the machine compile in the background, I
>narrowed down the code that broke the resume from suspend to RAM on my
>machine. Apparently it was the patch that is supposed to fix the
>network card problems.
>
>When starting from a patched 2.6.7 with suspend to ram and resume
>working fine as described above (=base), I have applied two patches
>
> (a) acpi-20040715
>
> (b) Fix ACPI after S3 patch of David Shaohua:


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

^ permalink raw reply	[flat|nested] 25+ messages in thread
* acpi-20040715: functional regression on ASUS M2N
@ 2004-07-19 23:31 Georg C. F. Greve
       [not found] ` <m3d62rzi9a.fsf-eMhNhoSsuh6q92djB/mqZw@public.gmane.org>
  0 siblings, 1 reply; 25+ messages in thread
From: Georg C. F. Greve @ 2004-07-19 23:31 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Hi all,

I just tried a kernel 2.6.8-rc2 with swsusp2-2.0.0.100 and some other
minor patches -- overall with great success. But when I updated from
the ACPI included in the kernel to the acpi-20040715 patch for 2.6.8,
suspend to ram does not work anymore: the machine hangs on resume.

Except for the network cards, which are broken after resume from S3,
it otherwise works fine for the previous ACPI versions with kernel
2.6.7 and kernel 2.6.8 -- which are the first kernels for which this
is true.

This is on an ASUS M2N with intel 855GM Centrino chipset, running the
Debian GNU/Linux distribution.

If you need more info, let me know.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve-BSDwwRMYa8fNLxjTenLetw@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
GNU Business Network                        (http://mailman.gnubiz.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2004-09-01 15:16 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-05 18:49 acpi-20040715: functional regression on ASUS M2N Nathan Bryant
     [not found] ` <4112814C.2070808-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-06 11:21   ` Georg C. F. Greve
     [not found]     ` <m37jsc3424.fsf-glUV91rXKAHWIjgkaejU9x2eb7JE58TQ@public.gmane.org>
2004-08-06 13:36       ` Nathan Bryant
     [not found]         ` <41138944.3060309-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-06 16:54           ` Georg C. F. Greve
     [not found]             ` <m3u0vgurzy.fsf-glUV91rXKAHWIjgkaejU9x2eb7JE58TQ@public.gmane.org>
2004-08-06 17:07               ` Nathan Bryant
     [not found]                 ` <4113BAD5.1030909-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-06 20:50                   ` Georg C. F. Greve
2004-08-31  8:15                     ` Georg C. F. Greve
2004-08-06 15:23   ` Matthew Garrett
2004-08-06 15:50     ` Nathan Bryant
2004-08-06 16:38     ` Nate Lawson
2004-08-06 19:32     ` Nathan Bryant
  -- strict thread matches above, loose matches on Subject: below --
2004-08-31  8:45 Li, Shaohua
     [not found] ` <B44D37711ED29844BEA67908EAF36F03AC6ACF-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-31 13:38   ` Georg C. F. Greve
     [not found]     ` <m3zn4bbf6x.fsf-eMhNhoSsuh6q92djB/mqZw@public.gmane.org>
2004-09-01 15:16       ` Georg C. F. Greve
2004-08-09  8:10 Li, Shaohua
2004-08-02 16:45 Nathan Bryant
     [not found] ` <410E6F9C.2040904-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
2004-08-04  0:23   ` Georg C. F. Greve
2004-07-27 12:24 Li, Shaohua
     [not found] ` <B44D37711ED29844BEA67908EAF36F036BCD7C-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-07-27 13:42   ` Georg C. F. Greve
2004-07-19 23:31 Georg C. F. Greve
     [not found] ` <m3d62rzi9a.fsf-eMhNhoSsuh6q92djB/mqZw@public.gmane.org>
2004-07-20 19:03   ` Matthew Garrett
     [not found]     ` <1090350197.4828.5.camel-myFlNLNQP+Q@public.gmane.org>
2004-07-21  8:17       ` Georg C. F. Greve
     [not found]         ` <m3acxthizw.fsf-eMhNhoSsuh6q92djB/mqZw@public.gmane.org>
2004-07-27 11:14           ` Georg C. F. Greve
     [not found]             ` <m3oem1u2gg.fsf-glUV91rXKAHWIjgkaejU9x2eb7JE58TQ@public.gmane.org>
2004-07-27 11:24               ` Matthew Garrett
     [not found]                 ` <1090927462.4412.26.camel-myFlNLNQP+Q@public.gmane.org>
2004-07-27 13:40                   ` Georg C. F. Greve

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox