Upgraded utils...

Hi,
Since I'm working on 2.4.0-testx I upgraded modutils, e2fsprogs and
util-linux as suggested... (looking at the changes list).

Now I have the following behaviour:

on boot

"cannot access hardware clock by any known method"

on damaged boot partition --- 2.4.0-test4 crashes one in three times on
reboot :-(

generally heart-stopping behaviour from fsck saying that is cannot find
things and then dropping me into manual fsck...

Is there something else I need to upgrade? or remove?

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Iain Sandoe wrote:

Hi,
Since I'm working on 2.4.0-testx I upgraded modutils, e2fsprogs and
util-linux as suggested... (looking at the changes list).

You compiled util-linux yourself?

Now I have the following behaviour:

on boot

"cannot access hardware clock by any known method"

Could be /sbin/hwclock is now a binary that was compiled with
util-linux. This doesn't mean it works, though. Better put the old fake
hwclock shell script there ("/sbin/clock -s"). Or is one now supposed to
create /dev/rtc and use it as on any other architecture?

on damaged boot partition --- 2.4.0-test4 crashes one in three times on
reboot :-(

Mine doesn't boot at all, so you are more advanced there :-)

generally heart-stopping behaviour from fsck saying that is cannot find
things and then dropping me into manual fsck...

Is there something else I need to upgrade? or remove?

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 20:54 14.07.00, Martin Costabel wrote:

Could be /sbin/hwclock is now a binary that was compiled with
util-linux. This doesn't mean it works, though. Better put the old fake
hwclock shell script there ("/sbin/clock -s"). Or is one now supposed to
create /dev/rtc and use it as on any other architecture?

Yes! That's why I did CONFIG_PPC_RTC, it's such simple code, but it helps a
lot to bring us in line with the other architectures.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Franz Sirl wrote:

At 20:54 14.07.00, Martin Costabel wrote:

quoted

Could be /sbin/hwclock is now a binary that was compiled with
util-linux. This doesn't mean it works, though. Better put the old fake
hwclock shell script there ("/sbin/clock -s"). Or is one now supposed to
create /dev/rtc and use it as on any other architecture?

Yes! That's why I did CONFIG_PPC_RTC, it's such simple code, but it helps a
lot to bring us in line with the other architectures.

Yes, sorry I forgot, I have actually already used this, back in the good
old days when I could still boot 2.4.0-testX. But does this actually
work with the hwclock program from standard RedHat util-linux?

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Franz Sirl wrote:

At 20:54 14.07.00, Martin Costabel wrote:

quoted

Could be /sbin/hwclock is now a binary that was compiled with
util-linux. This doesn't mean it works, though. Better put the old fake
hwclock shell script there ("/sbin/clock -s"). Or is one now supposed to
create /dev/rtc and use it as on any other architecture?

Yes! That's why I did CONFIG_PPC_RTC, it's such simple code, but it helps a
lot to bring us in line with the other architectures.

For the record: Yes, it works. (On a Pmac 6400, with a 2.2.17pre11
kernel from bitkeeper; 2.4.0-test4 still doesn't want to boot, so I
can't test it).

I was too timid and had compiled PPC_RTC only as a module. Apparently
the kernel does not load this module automatically, but when I put a
line
  /sbin/modprobe rtc
just before the hwclock stuff in /etc/rc.sysinit, it works (yes
/etc/rc.sysinit; this is initscripts-5.27 which has /etc/rc.d as symlink
to /etc, so that all the rc* stuff now clutters /etc. Big progress...)

/sbin/hwclock comes from util-linux-2.10k, compiled without problems
from the RedHat SRPM.

Thanks

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Martin Costabel wrote:

Franz Sirl wrote:

[]

quoted

Yes! That's why I did CONFIG_PPC_RTC, it's such simple code, but it helps a
lot to bring us in line with the other architectures.

For the record: Yes, it works. (On a Pmac 6400, with a 2.2.17pre11
kernel from bitkeeper; 2.4.0-test4 still doesn't want to boot, so I
can't test it).

On bitkeeper kernel 2.4.0-test4, I could get it to work, with the
following modifications (a patch is attached below):

- The file drivers/macintosh/rtc.c was absent. I copied the one from the
_2_2 kernel tree and changed it in analogy to the sbus/rtc.c file.

- In drivers/macintosh/Makefile, rtc.o should be in O_OBJS instead of
L_OBJS.

- If compiled as module, rtc reports unresolved symbols, because the
EXPORT_SYMBOLS in arch/ppc/kernel/ppc_ksyms.c are between
#ifdef CONFIG_PPC_RTC - #endif
instead of #ifdef CONFIG_PPC_RTC_MODULE, as in the _2_2 tree.

--
Martin