Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Blocker Blocker
    • Resolution: Fixed
    • Component/s: ztdummy
    • Labels:
      None
    • Mantis ID:
      9592
    • Regression:
      No

      Description

      loading ztdummy in xen creates an rtc problem.

      at my fedora system it looks like this:
      http://lists.xensource.com/archives/html/xen-users/2006-07/msg00267.html

                • ADDITIONAL INFORMATION ******

      I am using a Beronet BN8S0 with mod pciback in domu - this works fine.

      The domu system is:
      Linux 2.6.19-1.2911.6.5.fc6xen #1 SMP Sun Mar 4 16:59:41 EST 2007 i686 i686 i386 GNU/Linux

      The dum0 is similar

      Additional Questions are welcome - fixes too - I fight this problem for some weeks and do not want to leave the virtualization concept.

        Activity

        Hide
        Caio Begotti added a comment -

        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.

        Show
        Caio Begotti added a comment - 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.
        Hide
        Joshua Colp added a comment -

        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?

        Show
        Joshua Colp added a comment - 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?
        Hide
        Thomas Wenzel added a comment -

        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.

        Show
        Thomas Wenzel added a comment - 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.
        Hide
        Caio Begotti added a comment -

        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.

        Show
        Caio Begotti added a comment - 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.
        Hide
        Frank Waller added a comment -

        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.

        Show
        Frank Waller added a comment - 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.
        Hide
        Iñaki Baz Castillo added a comment -

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

        Show
        Iñaki Baz Castillo added a comment - 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).
        Hide
        Frank Waller added a comment -

        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.

        Show
        Frank Waller added a comment - 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.
        Hide
        Jason Parker added a comment -

        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.

        Show
        Jason Parker added a comment - 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.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development