[LAD] Timers, hpet, hrtimer -> kind of solved (for too old motherboards)

[James Warden]

Philipp,

The alsa-lib source package comes with some test programs. One is called timer.c and can be compiled as well if you locally compile alsa-lib (no need to install, just compile):

cd alsa-lib-xxx
./configure
make
cd test
make timer

then, you can see what you have:

./timer list

and test some of them

./timer class=1 card=0 device=3  # that's the high res timer used by ALSA

(well, replace card by what makes sense to you, I personally do not have a hw:0, I reserve hw:0 for the onboard chip, which I disabled in the BIOS, so I use card=1, which is my PCI card).

class, sclass, device, etc are defined in the ALSA lib API doc.
class=1 is I think GLOBAL
sclass=-1 is slave class = NONE I think (not in front of the API doc). 

device=3 seems to confirm what Clemens said about kernel reserved timers.

(when you list the timers with ./timer list, the GLOBAL ones will show up with a card=-1. Yet, to test them as I indicated above, you will need to invoke ./timer with card=X with X = some valid card index).

For the group permission, I am not sure this is needed. I did that because of some permission issue message I saw a long time ago. Not sure if this is relevant. Since I compiled my kernel with HR timer as default for ALSA, I guess all is fine, I do not need to invoke jackd with -ch, the hpet timer is used by default.


On the other hand, when I set rosegarden to use the HR timer, I get a complete total freeze of my system, nothing works at all, not even connecting to the machine remotely via LAN. Not sure what is going on here.

J.

--- On Tue, 11/10/09, hollunder at gmx.at <hollunder at gmx.at> wrote:

> From: hollunder at gmx.at <hollunder at gmx.at>
> Subject: Re: [LAD] Timers, hpet, hrtimer -> kind of solved (for too old motherboards)
> To: linux-audio-dev at lists.linuxaudio.org
> Date: Tuesday, November 10, 2009, 8:40 AM
> On Tue, 10 Nov 2009 12:48:42 +0100
> Clemens Ladisch <clemens at ladisch.de>
> wrote:
> 
> > hollunder at gmx.at
> wrote:
> > > $  dmesg | grep -i hpet
> > > Kernel command line:
> > >
> root=/dev/disk/by-uuid/3e47466f-5ca1-499b-85fc-152074f36364
> ro
> > > hpet=force pci 0000:00:11.0: Failed to force
> enable HPET
> > > 
> > > /dev/hpet was still created,
> > 
> > Then you have it.  The message is probably
> because it doesn't need
> > to be forced.
> 
> I added hpet=force because I found a line in dmesg that
> said
> something along the lines of: hpet isn't available, try
> hpet=force
> 
> > See /proc/iomem at address fed00000.
> cat /proc/iomem | grep -i fed00000 -> Nothing
> > 
> > It's possible that your log buffer is too small and
> that the earlier
> > HPET messages were lost.  Do you have more
> HPET-releated messages
> > in /var/log/messages or /var/log/syslog?
> 
> cat /var/log/messages.log | grep -i hpet only found the
> kernel command
> line
> cat /var/log/syslog.log | grep -i hpet didn't find
> anything
> 
> > > but when I changed its group and told jack to use
> it I got:
> > > This system has no accessible HPET device (Device
> or resource busy)
> > 
> > "Busy" means that it's there, but already being
> used.  Many
> > motherboard BIOSes do not initialize the third HPET
> interrupt, and
> > the first two are taken by the kernel.
> > 
> > 
> > Best regards,
> > Clemens
> 
> Thanks a lot Clemens, but I'm still not sure what the issue
> is or how
> to solve it.
> 
> Regards,
> Philipp
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>