Hi folks, I did a previous search on this mailing list archive and found no similar problem, that's why I'm posting it now. My problem is similar to this one:
http://bugzilla.kernel.org/show_bug.cgi?id=5751 which seems to be resolved but I got the latest kernel available (2.6.15.4) and the problem still persists on my machine. (than I rolled back to 2.6.12) A brief decription: My notebook is having serious problems with all periferics like network cards, keyboard, mouse and sound. Some times the network just dies, other times the mouse. The keyboard is the worse, I can't type five chars in a row that it miss one. (so, im sorry for many typos on this message ;) I used Suse linux without ACPI and it was just fine, but when I wanted the ACPI working I started my nightmare. Now I use Ubuntu and I can't turn off the ACPI (by adding acpi=off on kernel's line) because when I do it the kernel assign IRQ 102 to my wireless card and the wired card just don't get up. I posted a message like this on usenet and a nice guy (Peter Breuer) got me some answers but he was conviced that my problem was the NIC. Unfortunatelly everything else is failing. Now, my system: Machine: Toshiba Equium L20 198 (a crap, I might say) - ATI mainboard, sound and graphics - Realtek 10/100 wired NIC (yeah, I know) - Atheros 10/100 wireless NIC All cards are on-board, no PCMCIA, USB etc. $ uname -a Linux brubeck 2.6.12-10-386 #1 Mon Jan 16 17:18:08 UTC 2006 i686 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Celeron(R) M processor 1.50GHz stepping : 8 cpu MHz : 1497.275 cache size : 1024 KB $ acpi -v acpi 0.09 (...) $ acpi -V Thermal 1: ok, 52.0 degrees C AC Adapter 1: on-line $ acpi -b $ (on Suse it used to give me the battery as well) The error messages I have on /var/log/messages: Feb 12 20:59:25 localhost kernel: [4331271.014000] ACPI-0362: *** Error: Looking up [Z00D] in namespace, AE_NOT_FOUND Feb 12 20:59:25 localhost kernel: [4331271.014000] search_node dde85920 start_node dde85920 return_node 00000000 Feb 12 20:59:25 localhost kernel: [4331271.014000] ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node dde84820), AE_NOT_FOUND Feb 12 20:59:30 localhost kernel: [4331275.912000] ACPI-0362: *** Error: Looking up [Z00D] in namespace, AE_NOT_FOUND Feb 12 20:59:30 localhost kernel: [4331275.912000] search_node dde85920 start_node dde85920 return_node 00000000 Feb 12 20:59:30 localhost kernel: [4331275.912000] ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node dde84820), AE_NOT_FOUND (as you can see, one group every 5 seconds, must be some kind of polling) Some detailed output such as dmesg and lspci -v are at http://www.systemcall.com.br/rengolin/acpi/ but here I'll post some of them I found more interesting: === DMESG When using ACPI, the first lines of 'dmesg | grep -i acpi' are: [4294671.224000] ACPI: Looking for DSDT in initrd... not found! [4294671.409000] ACPI: bus type pci registered [4294671.409000] ACPI: Subsystem revision 20050729 [4294671.411000] ACPI-0362: *** Error: Looking up [Z00D] in namespace, AE_NOT_FOUND So, first, it wasn't updated according to the kernel bugzilla (stated above). Then, it didn't find ay DSDT, so ow could it know how t deal accordingly with my hardware's powermanagement ? Is it the cause of the messages I see on ar/log/messages ? Also, it says later: [4294764.683000] ACPI: AC Adapter [ACAD] (on-line) [4294764.863000] ACPI: Battery Slot [BAT1] (battery present) So, if it's really dettecting my battery, why 'acpi -b' won't show it ? When not using ACPI, the 'dmesg | grep -i pci' shows me: [ 20.386353] PCI->APIC IRQ transform: 0000:09:01.0[B] -> IRQ 17 [ 20.386358] PCI->APIC IRQ transform: 0000:09:02.0[A] -> IRQ 0 [ 20.386364] PCI->APIC IRQ transform: 0000:09:04.0[A] -> IRQ 102 Some weird IRQs for me, never saw something like that, but, is APIC the fallback for routing IRQs when no ACPI is in use ? Why some said me to turn off the local APIC ? (btw, noapic on kernel line gave me kernel panic) The board receiving the weir IRQs (0 and 102) are both NIC (see lspci output on my site). Also, if you do a diff on the output of 'lspci -v' with and without ACPI, you will find: $ diff lspci.acpi lspci.noacpi [ this is Realtek's line ] 92c92 < Flags: bus master, medium devsel, latency 64, IRQ 21 --- > Flags: bus master, medium devsel, latency 64 [ and this is Atheros line ] 99c99 < Flags: bus master, medium devsel, latency 168, IRQ 22 --- > Flags: medium devsel, IRQ 102 One more thing I've noted, it says: [4294671.537000] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Well,I did booted with 'pci=routeirq' but the problem persists. So, on my site http://www.systemcall.com.br/rengolin/acpi/ I've put all files mentioned here and some others related to this problem. If you need more information, please ask me. The filenames are: program-name.[acpi|noacpi].greped-string Please note that I've taked a long time to write this, debgging and rebooing lots of times and, as I stated on the beginning, the problem might have been resolved in future versions of the kernel, but I'd like to contriute as many as I can to ACPI development even if all my debug information is outdated. Maybe you can use all this information for something else. many thanks in advance, --rengolin - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
