http://bugzilla.kernel.org/show_bug.cgi?id=7562
------- Additional Comments From [EMAIL PROTECTED] 2006-12-25 07:46 -------
I found a workaround; everything is working for me.
Booting with pci=usepirqmask
The order (and perhaps the timing) in which the modules are loaded is critical.
If I "modprobe snd_hda_intel" first, I am toast. The order that works for me
is:
i2c_core nvidia snd_hda_codec cpufreq_conservative ohci_hcd snd_hda_intel
ndiswrapper
Working interrupts:
kimchee% cat /proc/interrupts
CPU0 CPU1
0: 5657 1208070 IO-APIC-edge timer
1: 6 944 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 0 226 IO-APIC-level acpi
11: 0 3 IO-APIC-level ohci1394
12: 106 21276 IO-APIC-edge i8042
14: 0 270 IO-APIC-edge ide0
50: 292 52725 IO-APIC-level wlan0
201: 2501 498403 IO-APIC-level eth0
209: 99 20435 IO-APIC-level libata
217: 1210 295445 IO-APIC-level nvidia
225: 99 19055 IO-APIC-level ohci_hcd:usb1
233: 0 135 IO-APIC-level HDA Intel
NMI: 242 360
LOC: 1213743 1213720
ERR: 0
MIS: 0
I did run into a problem with USB 1.0 devices where I was getting a timeout and
sometimes a hang. I "fixed" that also by modifying hub.c and changing the
timeout value manually from 1000 to 5000 (around line 2327 on my 2.6.18 kernel).
I suspect the real problem is that things are getting initialized too quickly.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla