pauses during desktop use

[zebrandao]

I have installed Haiku from the CD into an extended partition on my computer, an Asus A6G laptop. Everything runs fine apart from a single problem that ruins the experience: very often, the OS becomes non responsive for 1 or 2 seconds.

A typical example: I am moving the mouse on the screen; all of a sudden, the pointer stops responding for 1 or 2 seconds; after that, it jumps to a position far away, a position, in fact, that corresponds roughly to the position it should find itself in had the progression of the pointer been shown on the screen.

I have search the tickets on the bug tracking system and the only thing similar that I have found is bug #2359 regarding disk IO that blocked the OS. Nevertheless it has been closed as solved.

Attached to the tickets are the results of the commands "listdev" and "listimage" in the file "list_of_devices_and_drivers.txt" as well as a photograph of a debug session screen with th output of a "halts" instruction. It shows that the ATA handler is dropping as many interrupts as not.

[zebrandao]

list of devices and kernel info

[zebrandao]

kernel debug "ints" instruction results (screenshot)

[tonestone57]

Interesting. Appears there may be an issue with ATA for you. Are you able to test with an image with the IDE driver instead? You'd have to build it yourself or download an older version, before the switch to ATA ( no iso, just raw & vmware ).

Would like to see if Haiku with IDE works better for you.

[marcusoverhagen]

Please attach a syslog using trunk hrev33042 or newer. Do not try the IDE stack.

What happens when the mouse pointer doesn't move, is everything frozen? You can test this by running Chart or GL Teapot.

[mmlr]

That's actually normal. On all of my systems the handled vs. unhandled count is like that.

[PieterPanman]

I've noticed the same behavior on a Haiku compiled yesterday. In my case, it seems to happen most when the CPU is taxed (for example playing a movie). The movies continue playing fine, but the mouse just stops moving...

[marcusoverhagen]

Unhandled interrupts on irq 14 and 15 are a bug in the ata stack, but they are not related to mouse pointer freezing.

[zebrandao]

Hello,

Update on the problem: The mouse was a usb mouse connected through a usb hub (the same with the keyboard). I have re-installed Haiku, this time from the R1 alpha image. Connecting the mouse through the usb hub, the problem persists, but connecting directly to one of the laptop's usb plug, the mouse works flawlessly.

An aside: to refresh my hard drive installation, I used a usb stick on which the raw image was copied. Booting from the usb stick, the booting time is unnaturally long, several times slower than from the hard drive. Could there be a problem with the usb driver?

Best regards,

José Brandão

[mmlr]

Replying to zebrandao:

The mouse was a usb mouse connected through a usb hub (the same with the keyboard). I have re-installed Haiku, this time from the R1 alpha image. Connecting the mouse through the usb hub, the problem persists, but connecting directly to one of the laptop's usb plug, the mouse works flawlessly.

Curious thing. I haven't seen something like that here. Is there any output on the syslog when this happens? How often does this happen on average? Is it like once a minute or more like once every few seconds or even every second? What you could try is suspending the explore thread to see if this one causes the trouble. To do so, enter KDL and use "threads | grep explore". You should see the usb explore thread, with the second number (a number somewhere around 20-50) being the thread id. Then use "suspend <thread number of usb explore thread>", then leave KDL with "continue".

An aside: to refresh my hard drive installation, I used a usb stick on which the raw image was copied. Booting from the usb stick, the booting time is unnaturally long, several times slower than from the hard drive. Could there be a problem with the usb driver?

No, that's just because of it using a suboptimal way of transferring data between the subsystems. I'm working on that.

[zebrandao]

Hello again,

I have followed your instructions. Answering your questions:

• The seizure happens every 1 or 2 minutes.
• After several instances of mouse seizure, I have cat'd syslog into syslog1, annexed here.
• Subsequently, I started a kernel debugging session (Alt+SysReq+D) where i executed:

  threads | go explore

  with the result (minus formatting):

0x8180c800 29 zzz - 5 0x802b5000 1 usb explore

Then I executed:

suspend 29 continue

• In the desktop, the problem persisted. As comparison, I re-cat'd syslog into syslog2 (annexed here) to allow for the comparison with the state before the KDL session.

Best regards,

José Brandão

[mmlr]

From the rest of the log it seems that some interrupts get lost at times. I find it a bit disturbing that from the screenshot of the ints command it looks like the audio driver is installed to interrupt line 0. That usually is the PIT and seems very odd to me to be reused. The difference is that if you use it by hub, the mouse is attached to EHCI, while when connected directly it'll use UHCI. Still I don't see where the EHCI errors would come from, especially not as irregularly as they appear to be. Could of course just be a bug somewhere in EHCI. Without being able to reproduce it's difficult to work on it sadly.

[marcusoverhagen]

This could be a problem with the auich driver. Please remove it and reboot. Does the problem persist? What does this ints command show?

[zebrandao]

I am afraid you assume a great deal more knowledge on my part than is actually the case: how do I go about removing the auich driver?

Best regards

José Brandão

[stippi]

Right-click your Haiku boot volume icon on the Desktop. Navigate along the path with the menu:

system -> add-ons -> kernel -> drivers -> bin

and click the "bin" folder such that it opens. Now rename "auich" to "auich.disabled" (acknowledge the protesting alert). There is a link to this driver binary in

/boot/system/add-ons/kernel/drivers/dev/audio/hmulti.

This link will now point nowhere and the driver should not be loaded.

[zebrandao]

I renamed /system/add-ons/kernel/drivers/bin/auich to auich.disabled.

As a result, the problem still happens but MUCH MUCH less often. Looking at KDL's ints instruction, there were no longer any significant number of dropped interrupts.

As an additional and welcomed secondary effect, the media player now works most of the time with avi and mpeg files, although without sound and not for mp4 or wmv files, which are recognized by the system as multimedia files. I hadn't bothered reporting that the media player didn't work at all because I wanted to put the mouse issue behind me first.

Additional points: I diplayed on screen the cpu load thingamingy, and it showed that when the seizure happen, the cpu load drops to nil. Also, with the mouse connected through the usb hub, if I keep moving the pointer fast, the cpu load climbs to around 30%; while, with the mouse at rest, it keeps itself at 5~6%. This happens neither with the laptop's pointing panel (I don't remember the name of the device: the thing on the keyboard that replace a mouse) nor with the mouse connected to one of the laptop's actual usb plugs.

Best regards,

José Brandão

[mmlr]

OK, so this is not actually a USB problem but one of the auich driver. Attaching to interrupt line 0 looks like a non-configured interrupt line. Since 0 is usually the PIT, it'd be possible that the auich driver is flooded with interrupts and then blocks the system while trying to handle those or something in that direction.

[korli]

Please try again with hrev39310 or newer. It shouldn't help with the sound if the device is not configured, but avoid troubles booting.