68000: unable to change owner of controlling tty

[ddraig68k]

I've had some time to start looking at getting FUZIX up and running again. It start's booting OK and when logging in I'm getting the "unable to change owner of controlling tty" error.

A:/>loadmem fuzix.bin 100000
Loaded 44332 bytes from file fuzix.bin to location 100000
A:/>run 100000
FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2023 Alan Cox <alan@etchedpixels.co.uk>
Devboot
Motorola 68010 processor detected.
8196kB total RAM, 7093kB available to processes (64 processes max)
Enabling interrupts ... ok.
IDE drive 0: hda: hda1 hda2 hda3
IDE drive 1:
bootdev: hda1
Mounting root fs (root_dev=1, ro): OK
Starting /init
init version 0.9.1

 ^ ^
 n n   Fuzix 0.4pre1
 >@<
       Welcome to Fuzix
 m m

login: root
login: unable to change owner of controlling tty

Welcome to FUZIX.

In an atttempt to figure out exactly what's going on here, i started digging into the code a little more. Enabling DEBUG_SYSCALL to see if there was any helpful information there i see the following:

        pid 3: syscall 73   setgroups(00000001, 0011AEC6, 00000000)
            pid 3: ret syscall 73, ret 00000000 err 00000000
        pid 3: syscall 50   fchown(00000000, 00000000, 00000000)
            pid 3: ret syscall 50, ret FFFFFFFF err 0000001E
        pid 3: syscall 8    write(00000001, 00119426, 00000031)
login: unable to change owner of controlling tty

It looks like the fchown call is failing with error 1E (30) which is "Read only file system". It look like it does mount the disk as read only initially (Mounting root fs (root_dev=1, ro): OK) but I assume that it's set to write at some point during the boot process.

I tried the 68000 filesystem from the website but that seems to get nowhere.

A:/>run 100000
FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2023 Alan Cox <alan@etchedpixels.co.uk>
Devboot
Motorola 68010 processor detected.
8196kB total RAM, 7093kB available to processes (64 processes max)
Enabling interrupts ... ok.
IDE drive 0: hda: hda1 hda2 hda3
IDE drive 1:
bootdev: hda1
Mounting root fs (root_dev=1, ro): OK
Starting /init

panic: no /init

Any suggestions on where I can look on this?

[EtchedPixels]

The earlier scripts didn't run properly. I'll take a bet that if you grab the root fs from fuzix.org it works. That's the classic symptom of what appears to be a weird binutils or compiler bug (or maybe something bizarrely wrong in the makefiles).

If you dig you'll probably find an alignment trap in a signed divide that the toolchain screwed up.

See README.68000.md

The critical thing appears to be building the compiler for the right target (the old uclinux one is very broken in other ways for all but coldfire and I don't think really maintained any more) and the binutils/gcc combo seems to produce broken support libraries that contain 68020 stuff if you build bintuils with a forced cpu type.

I think I ended up with binutils just by

../binutils-2.39/configure --target=m68k-elf --prefix=/opt/gcc12-68k

then installing them and getting them on the path first, then a clean build of gcc as per the README. If you set the cpu type to 68000 for binutils it breaks. Very weird.

[ddraig68k]

I tried using the rootfs image from the fuzix.org and I get the "panic: no /init" error. I'm using binutils 2.37 rather than 2.39 but i'll rebuild the toolchain using that version just to check.

I'll add some debug information to see if I can work out what's happening before init is called and see if that helps work out the problem.

I have a version of GCC built specifically for testing this, i'm not using the m68k-linux-gnu tools. I'm configuring binutils with:

--prefix=$(PREFIX_TARGET) --target=m68k-elf --disable-werror --enable-lto

And this is my gcc config:

m68k-elf-gcc -v
Using built-in specs.
COLLECT_GCC=m68k-elf-gcc
COLLECT_LTO_WRAPPER=/opt/m68k-elf/bin/../libexec/gcc/m68k-elf/10.4.1/lto-wrapper
Target: m68k-elf
Configured with: /home/steve/code/m68k-elf-toolchain/projects/gcc/configure --prefix=/opt/m68k-elf-fuzix --target=m68k-elf --enable-languages=c --disable-threads --disable-shared --without-headers --disable-libquadmath --disable-libssp --disable-libgcj --disable-gold --disable-libmpx --disable-libgomp --disable-libatomic --with-cpu=68000 --src=../../projects/gcc
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.4.1 20230321 (GCC)

[ddraig68k]

I've found the source of the issue here, it's not a file system issue at all it seems. Working through the startup code I saw that it was calling "install_vdso()".

It seems that my code was using memcpy((void *)udata.u_codebase, &vdso, 0x40); where other platforms are using memcpy((void *)udata.u_codebase, &vdso, 0x20);

Not sure where that 0x40 came from, i was mainly using code from where i looked at FUZIX previously so it's probably a mistake from there. Obviously the mem copy was corrupting data somewhere causing the problems I was seeing.

I've even tried my previous m68k-elf build of gcc and that also works fine.

FUZIX version 0.4pre1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2023 Alan Cox <alan@etchedpixels.co.uk>
Devboot
Motorola 68010 processor detected.
8196kB total RAM, 7093kB available to processes (64 processes max)
Enabling interrupts ... ok.
IDE drive 0: hda: hda1 hda2 hda3
IDE drive 1:
bootdev: hda1
Mounting root fs (root_dev=1, ro): OK
Starting /init
init version 0.9.1
Checking root file system.

 ^ ^
 n n   Fuzix 0.4pre1
 >@<
       Welcome to Fuzix
 m m

login: root

Welcome to FUZIX.
# cat test.txt
FUZIX running on Y Ddraig 68K computer
#

[EtchedPixels]

On Wed, 22 Mar 2023 04:33:04 -0700 Y Ddraig @.***> wrote:

I've found the source of the issue here, it's not a file system issue at all it seems. Working through the startup code I saw that it was calling "install_vdso()".

It seems that my code was using memcpy((void *)udata.u_codebase, &vdso, 0x40); where other platforms are using memcpy((void *)udata.u_codebase, &vdso, 0x20);

Not sure where that 0x40 came from, i was mainly using code from where i looked at FUZIX previously so it's probably a mistake from there. Obviously the mem copy was corrupting data somewhere causing the problems I was seeing.

Cool - the size changed when I switched to a.out. I obviously forgot to adjust that one. Mea culpa. Glad you are not hitting the compiler funny even though it looked the same bug.

Alan

[ddraig68k]

I did compare my code with some of the latest 68000 platforms but I obviously missed that one. Now that I have it running I can start looking at getting some of the other hardware up and running.