ioctl32 translations for clock

ioctl32 translations for clock

[Meelis Roos]

This is 2.6.5-rc1 on an Ultra 5 running Debian unstable up-to-date (with
udev 0.23-3).

ioctl32(hwclock:451): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc58) on /dev/tty1
ioctl32(hwclock:454): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc48) on /dev/tty1
ioctl32(hwclock:455): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc58) on /dev/tty1

and hwclock tells at the same time
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
System time was Thu Apr  1 06:01:10 UTC 2004.
Setting the System Clock using the Hardware Clock as reference...
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
System Clock set. System local time is now Thu Apr  1 06:01:11 UTC 2004.

Looks like a missing ioctl32 translation?

-- 
Meelis Roos (mroos@linux.ee)

Re: ioctl32 translations for clock

[David S. Miller]

On Thu, 1 Apr 2004 09:06:50 +0300 (EEST)
Meelis Roos <mroos@linux.ee> wrote:

> ioctl32(hwclock:451): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc58) on /dev/tty1
> ioctl32(hwclock:454): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc48) on /dev/tty1
> ioctl32(hwclock:455): Unknown cmd fd(3) cmd(00004b50){00} arg(effffc58) on /dev/tty1

It's always going to spit these out, this is hwclock trying to figure out
the access method and one thing it tries are the old M68K platform specific
ioctls which the translation layer doesn't handle of course.

> Cannot access the Hardware Clock via any known method.

I've seen this too, and upgrading to current debian fixed all of that.

The kernel has had the correct translations for this clock stuff for
years.  It's something on the userlevel side.

Re: ioctl32 translations for clock

[Meelis Roos]

> It's always going to spit these out, this is hwclock trying to figure out
> the access method and one thing it tries are the old M68K platform specific
> ioctls which the translation layer doesn't handle of course.

Yep, sounds familiar.

> > Cannot access the Hardware Clock via any known method.
>
> I've seen this too, and upgrading to current debian fixed all of that.

This is a current debian. Will investigate tomorrow.

-- 
Meelis Roos (mroos@ut.ee)      http://www.cs.ut.ee/~mroos/

Re: ioctl32 translations for clock

[Baurjan Ismagulov]

Hello,

On Thu, Apr 01, 2004 at 10:34:43PM +0300, Meelis Roos wrote:
> > > Cannot access the Hardware Clock via any known method.
> > I've seen this too, and upgrading to current debian fixed all of that.
> This is a current debian. Will investigate tomorrow.

IIRC, I've solved that with "modprobe rtc".

With kind regards,
Baurjan.

Re: ioctl32 translations for clock

[Meelis Roos]

> I've seen this too, and upgrading to current debian fixed all of that.

hwclock --debug --hctosys --utc
hwclock from util-linux-2.12
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

I am using udev and a custom 2.6.5-rc3 kernel. There is no /dev/rtc node
after udev has just started. I have compiled rtc modular for some
strange reason. Loading the module by hand creates /dev/rtc so udev is
working correctly. There just isn't any hook for autoloading rtc
automatically at that point so the best should be compiling rtc into
kernel, not modular - at least when using udev. Considering I had
similar problems some time ago (without udev), it's probably good to
compile rtc statically anyway.

Compiling rtc statically solved it, I just tested. /dev/rtc node was
created on udev startup and everything was OK.

So the solution is to compile rtc statically as the help tells.

-- 
Meelis Roos (mroos@linux.ee)