Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#4472 closed bug (fixed)

pauses during desktop use

Reported by: zebrandao Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Audio/auich Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (4)

list_of_devices_and_drivers.txt (26.5 KB ) - added by zebrandao 15 years ago.
list of devices and kernel info
kernel_debug_screenshot_20.jpg (121.7 KB ) - added by zebrandao 15 years ago.
kernel debug "ints" instruction results (screenshot)
syslog1 (318.5 KB ) - added by zebrandao 15 years ago.
syslog2 (320.3 KB ) - added by zebrandao 15 years ago.

Download all attachments as: .zip

Change History (21)

by zebrandao, 15 years ago

list of devices and kernel info

by zebrandao, 15 years ago

kernel debug "ints" instruction results (screenshot)

comment:1 by tonestone57, 15 years ago

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.

comment:2 by marcusoverhagen, 15 years ago

Status: newassigned

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.

comment:3 by mmlr, 15 years ago

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

comment:4 by PieterPanman, 15 years ago

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...

comment:5 by marcusoverhagen, 15 years ago

Owner: changed from marcusoverhagen to nobody
Status: assignednew

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

comment:6 by zebrandao, 15 years ago

Component: Drivers/DiskDrivers/USB

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

in reply to:  6 comment:7 by mmlr, 15 years ago

Owner: changed from nobody to mmlr
Status: newassigned

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.

by zebrandao, 15 years ago

Attachment: syslog1 added

by zebrandao, 15 years ago

Attachment: syslog2 added

comment:8 by zebrandao, 15 years ago

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

comment:9 by mmlr, 15 years ago

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.

comment:10 by marcusoverhagen, 15 years ago

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

comment:11 by zebrandao, 15 years ago

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

comment:12 by stippi, 15 years ago

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.

comment:13 by zebrandao, 15 years ago

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

comment:14 by mmlr, 15 years ago

Component: Drivers/USBDrivers/Audio
Owner: changed from mmlr to nobody
Status: assignednew

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.

comment:15 by nielx, 15 years ago

Version: R1 alpha1R1/alpha1

comment:16 by korli, 14 years ago

Resolution: fixed
Status: newclosed

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

comment:17 by diver, 13 years ago

Component: Drivers/AudioDrivers/Audio/AUICH
Note: See TracTickets for help on using tickets.