Opened 14 years ago
Closed 14 years ago
#4088 closed bug (duplicate)
System is slow
|Reported by:||atmartens||Owned by:||axeld|
I am new to Haiku, and just built and installed it to a partition. When I boot into Haiku, I make it to the desktop quickly. However, the system then becomes extremely slow.
-the mouse responds, but with a lot of lag
-I can't type text into the terminal window
-the desktop items do not respond (and sometimes don't even appear)
However, I can bring up the F12 debugger and run commands there. I've tried to see if I could extract anything useful from it but am not sure I have. I did get a vm_page_fault twice:
panic: vm_page_fault: unhandled page fault in kernel space at 0x48, ip 0x844c798d
I also got the same error with ip 0x844f498d
Two other times I got a different error:
could not read block 1573588: bytesRead: -1, error: Device timeout
I also got the same error on block 1573420
Since this is my first time using the system I can't tell if those errors are related to my problem or not. I can also give some hardware specs if needed; I built my computer just over a year ago.
Change History (8)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Also useful might be a list of hardware in the machine (listdev from Haiku, or lspci -nn from linux)..
For example, if you have an intel pro 10/100 network chip, the ipro100 driver is notorious for interrupt storm problems (you'll see an 'fxp intr' thread or some such taking up all the CPU).
comment:3 by , 14 years ago
linux:~$ lspci -nn 00:00.0 Host bridge : Intel Corporation 82X38/X48 Express DRAM Controller [8086:29e0] (rev 01) 00:01.0 PCI bridge : Intel Corporation 82X38/X48 Express Host-Primary PCI Express Bridge [8086:29e1] (rev 01) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1b.0 Audio device : Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) 00:1c.0 PCI bridge : Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.2 PCI bridge : Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 02) 00:1c.4 PCI bridge : Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge : Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge : Intel Corporation 82801IR (ICH9R) LPC Interface Controller [8086:2916] (rev 02) 00:1f.2 RAID bus controller : Intel Corporation 82801 SATA RAID Controller [8086:2822] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 01:00.0 VGA compatible controller : nVidia Corporation G94 [GeForce 9600 GT] [10de:0622] (rev a1) 02:00.0 IDE interface : JMicron Technologies, Inc. JMB368 IDE controller [197b:2368] 03:00.0 Ethernet controller : Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller [11ab:4364] (rev 12) 05:02.0 Multimedia audio controller : VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller [1412:1712] (rev 02) 05:03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev c0)
So I did some more investigating and here is what I found (excerpt):
int 3, enabled 3, handled 4239954, unhandled 0 hda:_ZL21hda_interrupt_handlerP14hda_controller (0x844ee99f), data 0x844f46c0 oss:ossintr (0x851373e0), data 0x810a40cc ahci:_ZN14AHCIController9InterruptEPv (0x805ba55a), data 0x80fb6bf4
There are a lot of handled interrupts, and that number increases rather quickly (good guess, stippi!).
So at first glance I thought maybe the BIOS hard drive settings are involved. I changed my hard drive from AHCI mode to IDE mode. This time, the boot sequence didn't finish, and it gave me a different error message (I forgot to write it down, can always get it again if need be). It said something along the line that there were no interrupts, or they were disabled, I forget. Going back to AHCI mode allows for the boot sequence to finish but gives me all those interrupts.
In a perhaps related note, I have had issues using Linux's realtime kernel. Specifically, one of my two cores gets pegged on hardware interrupts (as seen by top), and after a few hours the system hangs. Switching to IDE mode makes no difference. The regular Linux kernel works fine, though, as does Windows. I have the latest BIOS version, and otherwise have no reason to suspect general hardware issues.
comment:4 by , 14 years ago
You appear to have OpenSound installed, and it's probably trying to access the same HDA hardware as Haiku's built-in HDA driver.
You should never install OpenSound if existing drivers already support your hardware.
comment:5 by , 14 years ago
Yes, I can confirm that removing OpenSound from my build profile resolved the issue. However, I do recommend then that you remove OpenSound from the default @disk build profile, someone else is bound to make the same mistake. Thanks.
comment:6 by , 14 years ago
AFAIK, There's no "default" @disk profile - unless you're referring to either UserBuildConfig.ReadMe, or UserBuildConfig.sample.
The @alpha* profiles do not contain OpenSound, but do contain the optional packages that are currently recommended for the (not-yet-released) Haiku alpha build.
If you're looking for a good "base" system, I would use these as a guideline.
comment:7 by , 14 years ago
Yes, I was referring to the ".sample" file. I will take a look at those.
comment:8 by , 14 years ago
|Status:||new → closed|
I could close this as yet another duplicate of our device manager problem with BeOS style drivers not being prevented to access the same device... was it #5 or something? :-)
It sounds very much like you are suffering from an interrupt storm. In the kernel debugger, you can use the "ints" command to get a listing. There should not be an interrupt line with thousands of unhandled interrupts. From there, you can also see which driver registered a handler. Best is probably to post the ints output here and maybe someone knows what could be done about it.