Take a look at the lines 43 to 45 in ztdummy.c (1.4 here)? You have to disable the RTC in Zaptel when running it inside Xen domains, or you should try to use a USB timing for it, if possible in your environment.

I believe it's not a real bug, it's a domU limitation due the way Xen domains access real hardware and kernel code in the host system.

Can you please try what caio said? And also, per the email on the list URL you gave - this works fine with an earlier version of Xen?

I commented out the '#define USE_RTC'.
Loading ztdummy does not result the kernel panic anymore.
But it still failes with a message about wrong kernel timing. Loading ztdummy requires a 1000 Hz kernel but the 2.6 kernel was set back to 250 Hz.

I am using 2.6.19 - I was not happy with 2.6.20.
Today kernel 2.6.21 was launched and changelog says something about a new high res timer.

Xen is 3.0.3-8.fc6.

You can use the Con Koliva's "vhz" patch to allow dynamic changing of your HZ in 2.4.x or use the 2.6.13 kernel or newer (after which it has been changed AFAIK). You can hack your ztdummy.c file and change the HZ value inside that or even comment out the line that blocks the module to get loaded because this timing issue. My opinion: comment out the mentioned line in ztdummy.c. It's faster to test and you already know how it works and how it will behaves. Unfortunately Xen' stuff is still a little bit hackish.

That, of course, will always depend on what kernel package you use: whether it's from your Linux distributor or built manually by yourself. Anyway, yet I can't see it as a bug.

In order to get Asterisk to work in our XEN domains we created ztxen. This is currently just ztdummy with the RTC stuff removed. We created versions for both 1.2.17.1 and 1.4.2.1 (though they would probably work with some earlier versions). You however do need to have your kernel compiled with the timer interrupt set to 1000Hz for these to work.
We have not done very extensive testing with them at present, just placed a few phone calls while the system was under load and listened to a few recordings. We plan on doing more extensive testing with them in the near future as we are going to be creating a VICIDIAL domU which uses a number of MeetMes as well as IAX trunks.
The main reason to create a new modules for it was that we plan in the future to actually rework the whole module so that if you load it in your dom0 domain as well as your domU domains it would take any zaptel timing source on the dom0 domain and pass it to the domU domains. This way they would all be running off the same timing source and would be far more accurate. It would also work with kernels that have the kernel interrupt timer set to something other than 1000Hz. This seemed far more elegant than reworking ztdummy to just check if it is being compiled in a domU domain and not use RTC.

I've commented all "#define USE_RTC" in ztdummy.c and changed "#define ZAPTEL_RATE 1000" instead of 250. "make" and "make install".
Then I load ztdummy with no problem but the MeetMe sound is "slow".

So I assume that I should to recompile my Kernel with "CONFIG_HZ=1000" instead of 250 (that is the default value in Linux 2.6).

ibc, your assumption is correct, this currently requires the kernel to be compiled with CONFIG_HZ=1000, further it works nicely under low load, under higher load you need a zaptel hardware timer, we are still working on the complete xen hardware forwarding.

Closing.

The simple solution here is to just comment out the #define USE_RTC in ztdummy.c. The ztxen module does not appear to be needed.