System stutters with no load at all

[Ken]

I'm using Ubuntu 8.10 on with a 2.6.27.10 kernel. (I only recompiled the kernel, using the Ubuntu packages, to add support for extra memory on the 32 bit build).

My audio device from lspci:

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)

The problem is that essentially, rhythmbox will skip or even repeat the same split second of music several times without cause. I have a dou core 2.26ghz CPU and there will be nothing but emacs running, and sure enough, rhythmbox will choke.

This is a new laptop for me, so I'm not sure if it's happened in previous versions.

Quite lame.

Rythmbox: 0.11.6svn20081008-0ubuntu4

[Pedro Villavicencio (pedro)]

thanks for the report, this is happening with the crossfading backend enabled or disabled? does the same happens with totem?

[Ken (kkinder)]

Thanks for the follow-up, Pedro. Cross-fading is not enabled. Yes, the same problem seems to happen in Totem as well.

[Pedro Villavicencio (pedro)]

does killing the pulseaudio daemon fixes the issue? this might be a pulseaudio or alsa problem.

[Ken (kkinder)]

Hmmm. Killing pulseaudio improved it, but actually, it's still noticeably stuttering. Strange.

[Ken (kkinder)]

Ok, I have more information. I don't think it's a problem specifically in the audio system, but I don't know where to recategorize it.

Something is hijacking the system. I've noticed that when pulseaudio/rhythmbox stutters, my typing also lags for a split second. I think it's reasonable to conclude then that something is taking over my system for that split second and not letting anything else do anything.

I don't have any background indexing going on (I disabled that to make sure) and when keeping top running in a window, I don't see anything popping up when the system stutters.

To make it weirder, the problem only seems to happen when I *boot up* docked. That is, if I boot up with the computer in the docking station, I get this stuttering. If I boot up undocked, there is no problem. If I undock the computer, however, the problem persists. (I haven't been able to dock the undocked computer and have it transfer the video over to DVI properly, so I haven't tested that.)

The only thing plugged into the docking station is a USB keyboard, a DVD burner, and a DVI monitor. However, a friend thought maybe it could be the USB subsystem; and the docking station does have a USB hub.

How can I proceed on this ticket in getting it categorized properly? Thanks so much for your help; it appears the audio system is not the problem.

[Ken (kkinder)]

Actually, I was able to dock it. Docking the laptop doesn't cause the problem if it boots up undocked.

If I boot up docked, pulseaudio stutters and my typing lags. I grepped /var/log/messages and I didn't see anything about IRQ failures (I thought maybe IRQ conflict)?

[Sebastien Bacher (seb128)]

you could look in the system monitor if anything take ressources by pick when getting the issue

[Sebastien Bacher (seb128)]

that's not a rhythmbox issue

[Gordon Hopper (gohopper)]

Latencytop may be able to help diagnose this issue ( http://www.latencytop.org/index.php ). This was added in intrepid, so "sudo apt-get install latencytop" should install it for you.

[Ken (kkinder)]

It isn't skipping as much as usual, but every now and then, I hear something. I see values like this:

-------------------
Scheduler: waiting for cpu 116.6 msec 36.9 %
opening cdrom device 5.8 msec 1.4 %
Waiting for event (select) 5.0 msec 18.1 %
Userspace lock contention 5.0 msec 14.7 %
Waiting for event (poll) 4.9 msec 27.3 %
Executing raw SCSI command 3.0 msec 1.3 %
SCSI cdrom ioctl 1.4 msec 0.2 %
SCSI ioctl command 0.9 msec 0.1 %
acpi_ec_transaction acpi_ec_burst_enable acpi_ec_s 0.6 msec 0.1 %
-------------------
Scheduler: waiting for cpu 15.4 msec 31.0 %
Waiting for event (poll) 5.0 msec 43.5 %
Userspace lock contention 4.9 msec 13.3 %
Waiting for event (select) 4.1 msec 6.7 %
opening cdrom device 3.4 msec 2.3 %
Executing raw SCSI command 3.0 msec 2.8 %
SCSI cdrom ioctl 1.3 msec 0.3 %
----------------
Scheduler: waiting for cpu 135.1 msec 42.7 %
opening cdrom device 6.6 msec 1.1 %
Waiting for event (select) 5.0 msec 9.9 %
Waiting for event (poll) 5.0 msec 29.5 %
Userspace lock contention 4.9 msec 15.6 %
Executing raw SCSI command 3.2 msec 1.0 %
SCSI cdrom ioctl 1.8 msec 0.1 %
SCSI ioctl command 0.8 msec 0.1 %
acpi_ec_transaction acpi_ec_burst_enable acpi_ec_s 0.4 msec 0.0 %
data_from_field acpi_ex_resolve_node_to_value acpi_ex_resolve_to_value acpi_ds_evaluate_name_path acpi_ds_exec_end_op

Anything unusual here?

[Ken (kkinder)]

Seemed to have gone away a while ago, but came right back with the new kernel package they put out today. 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

[Gordon Hopper (gohopper)]

Those latencytop numbers seem very healthy to me, but I'm not an expert with latencytop. When you run latencytop, make sure the audio application is selected on the bottom half of the screen. Since your system as a whole seems fairly responsive, the top half of the screen (overall system) is less important than the bottom half of the screen (the selected application). You can check "vmstat 1" or "top" to see if anything is running in the background. You shouldn't get audio stuttering from a modest system load, unless one of the apps is misbehaving.

This may be a hardware driver issue for something that is in the docking station (possibly not the audio driver). You might compare "lsmod" when you boot up docked versus undocked, to see if there are additional modules loaded for one configuration (also lspci, etc). It sounds like the "bad" driver isn't being loaded when you boot up undocked. You can also try "dmesg" instead of /var/log/messages, which sometimes gives more detail.

When you boot up in/out of the dock, are you doing a cold boot, or could this be related to suspend/resume?

[michael thompson (michaeldt)]

I have and had a similar problem. With 9.04 when freshly installed, I had this audio skipping problem. I can't remember what I did to fix it though. Now with 9.10 it's back again. Doesn't happen all the time, which is annoying as it's hard to reproduce. When it happened yesterday, it was after I had a crash report icon in the notification area. I had 3 at once and once I'd reported them, I opened spotify and the music was skipping. Tried rhythmbox and the same happened. Went away after a restart.

[Leo Arias (elopio)]

Hi Ken,
We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Michael, if you could provide latencytop information too it would be useful.

[Ken (kkinder)]

Sorry, Leo I didn't notice the comment above.

At this point it's a fairly infrequent, sporadic issue -- happening at most a time or two a month. I think what was going on was a USB hub I had was either conflicting with something else or just plain defective. I was getting other over-power USB errors from it and since unplugging it, I don't think it's been an issue.

I'm sorry I can't provide a lot of useful information. You all have been pretty diligent in getting back to me. I do tend to agree that it's some kind of hardware issue, either with USB or possibly an IRQ conflict (though I did look for IRQ conflicts and I didn't see any).

Can you recommend any tools to look for USB problems?

[Launchpad Janitor (janitor)]

[Expired for Ubuntu because there has been no activity for 60 days.]