Well, after running the ktr_sched-enabled kernel for about 4h50 now, I
did just see a short freeze. Abt 2-3 seconds. And I got a ktr dump
right after it came back. It can be downloaded here (I guess rt-click
and save the link):
http://opal.com/jr/freebsd/releng_7-freeze/200801132250-ktr.out
When I run schedgraph, all it shows for the whole period is just:
CPU 0
irq 17: pcm0 ath0
ath0 taskq
that's it. I have a shared irq between ath and the sound. Funnily
enough, within a few mins before the freeze, I was just listening
to a voicemail (i.e., I ran mplayer on a .wav file), but that was done
easily a minute or more before the freeze. I tried repeating that,
listening to the file and waiting a bit, but no more freezes. So not
sure if this is a possible indication of the cause, or not. It's
annoying not to be able to find a way of triggering this problem on
demand, though.
Anyway, I looked at the other system where I've had long freezes.
It has a shared [irq9: pcm0 cbb0++*] and on cbb0 I have an ath card!
So there, too, is an irq shared between pcm and ath. On this system,
if I find I'm in a long freeze and don't want to be, I've found that
pulling the ath card causes an immediate un-freeze.
Admittedly, based on the recent days' discussion in this thread, I
was more expecting to see moused or powerd or an xorg problem.
Oh! Another freeze, right then! This dump shows pcm0/ath0 too, but
also a bit more activity just after the return.
http://opal.com/jr/freebsd/releng_7-freeze/200801132337-ktr.out
This time I was not listening to sound. I was typing this email.
Wasn't there a thread about shared irqs here (or maybe on current)
recently?
-jr
signature.asc
Description: PGP signature
