Anybody having issues with ztdummy under the current 2.6 RC7? I get the following errors when trying to modprobe ztdummy: "Unable to register zaptel rtc driver" Doing a Google on the error shows reference to a message from 2004 that said you might not have RTC compiled into the kernel. Checking via: cd /usr/src/linux-2.6.13-rc7 grep -i rtc .config shows: CONFIG_APM_RTC_IS_GMT=y CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y CONFIG_HPET_RTC_IRQ=y CONFIG_SENSORS_RTC8564=m CONFIG_SND_RTCTIMER=m Any suggestions? Doug
Doug Lytle wrote:> Anybody having issues with ztdummy under the current 2.6 RC7? I get > the following errors when trying to modprobe ztdummy: > >Failed to mention that this was under the current Asterisk 1.2 Beta 1 release
In article <43121C89.9090702@drdos.info>, Doug Lytle <support@drdos.info> wrote:> Anybody having issues with ztdummy under the current 2.6 RC7? I get the > following errors when trying to modprobe ztdummy: > > "Unable to register zaptel rtc driver" > > Doing a Google on the error shows reference to a message from 2004 that > said you might not have RTC compiled into the kernel. Checking via: > > cd /usr/src/linux-2.6.13-rc7 > grep -i rtc .config > > shows: > > CONFIG_APM_RTC_IS_GMT=y > CONFIG_RTC=m > CONFIG_GEN_RTC=m > CONFIG_GEN_RTC_X=y > CONFIG_HPET_RTC_IRQ=y > CONFIG_SENSORS_RTC8564=m > CONFIG_SND_RTCTIMER=m > > > Any suggestions?rtc and genrtc are alternatives to each other. Make sure that the rtc module is loaded, and *not* genrtc. ztdummy is not compatible with genrtc, only with rtc. Cheers Tony -- Tony Mountifield Work: tony@softins.co.uk - http://www.softins.co.uk Play: tony@mountifield.org - http://tony.mountifield.org
Tony Mountifield wrote:>In article <43121C89.9090702@drdos.info>, >Doug Lytle <support@drdos.info> wrote: > > >>Anybody having issues with ztdummy under the current 2.6 RC7? I get the >>following errors when trying to modprobe ztdummy: >> >>"Unable to register zaptel rtc driver" >> >>Doing a Google on the error shows reference to a message from 2004 that >>said you might not have RTC compiled into the kernel. Checking via: >> >>cd /usr/src/linux-2.6.13-rc7 >>grep -i rtc .config >> >>shows: >> >>CONFIG_APM_RTC_IS_GMT=y >>CONFIG_RTC=m >>CONFIG_GEN_RTC=m >>CONFIG_GEN_RTC_X=y >>CONFIG_HPET_RTC_IRQ=y >>CONFIG_SENSORS_RTC8564=m >>CONFIG_SND_RTCTIMER=m >> >> >>Any suggestions? >> >> > >rtc and genrtc are alternatives to each other. > >Make sure that the rtc module is loaded, and *not* genrtc. > >ztdummy is not compatible with genrtc, only with rtc. > > > >I had time tonight to try this. Under Linux 2.6.13 final. Looking at make menuconfig shows that both Generic /dev/rtc emulation and Enhanced Real Time Clock support Removing one and enabling the other, compiling and recompiling zaptel: make clean;make linux26 make install (udev rules in place) I am unable to do a modprobe ztdummy without the above error. Any others running Linux 2.6.13 and successfully using ztdummy for timing? Doug
You need to care about the _actual_ error, not the report there is an
error. The error is (usually) reported to the console. Reboot the
computer and type this:
dmesg -c > /dev/null
modprobe ztdummy
dmesg
The output of the second dmesg will show you exactly what the error
message is.
Being that you have 'hpet' enabled, it's going to be
'Input/Output
error'. There's code in the kernel rtc driver that doesn't let you
use
it if hpet is on:
--snippy--
int rtc_register(rtc_task_t *task)
{
#ifndef RTC_IRQ
return -EIO;
#else
if (task == NULL || task->func == NULL)
return -EINVAL;
--snippy--
[From your kernel config]> >>CONFIG_HPET_RTC_IRQ=y
So. Turn that off, and recompile the rtc module and it'll start working
--Rob
In article <431B8F50.3040503@drdos.info>, Doug Lytle <support@drdos.info> wrote:> > Tony Mountifield wrote: > > >In article <43121C89.9090702@drdos.info>, > >Doug Lytle <support@drdos.info> wrote: > > > > > >>Anybody having issues with ztdummy under the current 2.6 RC7? I get the > >>following errors when trying to modprobe ztdummy: > >> > >>"Unable to register zaptel rtc driver" > >> > >>Doing a Google on the error shows reference to a message from 2004 that > >>said you might not have RTC compiled into the kernel. Checking via: > >> > >>cd /usr/src/linux-2.6.13-rc7 > >>grep -i rtc .config > >> > >>shows: > >> > >>CONFIG_APM_RTC_IS_GMT=y > >>CONFIG_RTC=m > >>CONFIG_GEN_RTC=m > >>CONFIG_GEN_RTC_X=y > >>CONFIG_HPET_RTC_IRQ=y > >>CONFIG_SENSORS_RTC8564=m > >>CONFIG_SND_RTCTIMER=m > >> > >> > >>Any suggestions? > > > >rtc and genrtc are alternatives to each other. > > > >Make sure that the rtc module is loaded, and *not* genrtc. > > > >ztdummy is not compatible with genrtc, only with rtc. > > I had time tonight to try this. Under Linux 2.6.13 final. Looking at > make menuconfig shows that both Generic /dev/rtc emulation and Enhanced > Real Time Clock support > > Removing one and enabling the other, compiling and recompiling zaptel: > > make clean;make linux26 make install (udev rules in place) > > I am unable to do a modprobe ztdummy without the above error. Any > others running Linux 2.6.13 and successfully using ztdummy for timing?There was nothing wrong with the original kernel config, as both rtc and genrtc were set to be compiled as modules. What you need to do is find where the system is deciding to load genrtc and make it load rtc instead. Failing that, before loading zaptel and ztdummy, do "modprobe -r genrtc" followed by "modprobe rtc". Cheers Tony -- Tony Mountifield Work: tony@softins.co.uk - http://www.softins.co.uk Play: tony@mountifield.org - http://tony.mountifield.org
Tony Mountifield wrote:>In article <431B8F50.3040503@drdos.info>, >Doug Lytle <support@drdos.info> wrote: > > >There was nothing wrong with the original kernel config, as both rtc and >genrtc were set to be compiled as modules. > >What you need to do is find where the system is deciding to load genrtc >and make it load rtc instead. Failing that, before loading zaptel and >ztdummy, do "modprobe -r genrtc" followed by "modprobe rtc". > > >Thanks for the input Tony, but the instructions that Rob Thomas wrote took care of my issue. Thanks again to both of you! Doug