Re: acpi-20040715: functional regression on ASUS M2N

["Georg C. F. Greve" <greve-mXXj517/zsQ@public.gmane.org>]

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

 || On Tue, 31 Aug 2004 16:45:04 +0800
 || "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: 

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

Thanks a lot for the pointer, it indeed appears to be the same
problem.


 ls> Currently there are two workarounds:

 ls> 1. comment one line in pci_link.c:acpi_pci_link_allocate, like
 ls> [...]
 ls> This disables rebalance IRQ, which fixes my problem.

This makes the problematic behaviour disappear, but not the messages
about the problem. I still see the syslog messages, although things
seem to work fine.


 ls> 2. change 'device_initcall(i8259A_init_sysfs);' to
 ls> 'late_initcall(i8259A_init_sysfs);'

This makes both the problematic behaviour and the messages disappear.

Also, it saves me the weird graphical behaviour upon resume, blocky
primitive graphics patterns, changing in one or two steps. 

Now I only have the "inu" close to the upper left corner for a second
or two as I had before the functional regression occured to me. 

All in all, #1 looks like a pretty brutal workaround to me, #2 looks
more like a fix.


 ls> It seems that if OS changed BIOS IRQ router setting (like ACPI
 ls> change Link device setting), IRQ router should resume before
 ls> PIC. This possibly proves what Venki said.

Well, it seems that my experience supports that.

If swsusp2 would also work now, things would be pretty nice.

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: application/pgp-signature, Size: 188 bytes --]