From: Georg C. F. G. <gr...@gn...> - 2004-08-31 13:41:00
|
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 <gr...@gn...> Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World (http://brave-gnu-world.org) |