Crash in entry.S:resume on Atari ST

[Matthias Reis]

Hi all,

in the frame of a hobby project
(https://ford.biologie.hu-berlin.de/matze/linux-m68k-atarinommu/wikis/home),
I did some changes to the kernel to make it boot on MMU-less, original
Atari ST machines.

So far, my kernel manages to mount a root filesystem from fd0 and run
busybox.

However, busybox (nano-X as well), produces a bus error and crashes the
whole kernel:

==== hatari emulator output:
M68000 Bus Error reading at address $0 PC=$48f2.
Bus error exception at 0x48f2!
====

The disassembly from objdump -D shows, that this happens in resume
(https://ford.biologie.hu-berlin.de/matze/linux-m68k-atarinommu/blob/master/arch/m68k/kernel/entry.S#L2195):

=== objdump -D vmlinux output:
000048cc <resume>:
48cc: 2208 movel %a0,%d1
48ce: 40e8 0320 movew %sr,%a0@(800)
48d2: 48e7 031e moveml %d6-%d7/%a3-%fp,%sp@-
48d6: 214f 0318 movel %sp,%a0@(792)
48da: 4e6b movel %usp,%a3
48dc: 214b 031c movel %a3,%a0@(796)
48e0: 2669 031c moveal %a1@(796),%a3
48e4: 4e63 movel %a3,%usp
48e6: 2e69 0318 moveal %a1@(792),%sp
48ea: 4cdf 78c0 moveml %sp@+,%d6-%d7/%a3-%fp
48ee: 46e9 0320 movew %a1@(800),%sr
48f2: 4e75 rtsp
===

It can be seen from the register dump given by the hatari debugger, that
USP contains 0x0 and the superuser bit (indicated by "S=0") is not set:

=== hatari emulator output:
CPU=$48f2, VBL=6379, FrameCycles=86856, HBL=387, LineCycles=168, DSP=N/A
$000048f2 : 4e75 rts
r
D0 00000008 D1 00002200 D2 00005401 D3 00961EC8
D4 00000000 D5 00940020 D6 602E0206 D7 00E00030
A0 00865B68 A1 00961EEC A2 0080E000 A3 000026E4
A4 000045C0 A5 000045E4 A6 00004794 A7 00000000
USP 00000000 ISP 00000018
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=2 STP=0
Prefetch 42a7 (CLR) 4e75 (RTS) Chip latch 00000000
000048F2 4e75 RTS
Next PC: 000048f4

===

If I understand correctly, the problem is that RTS sets the PC to USP,
so the Atari wants to execute the code at 0x0, which is wrong and not
allowed, of course.

I found the line "p->thread.usp = 0;" in the function copy_thread
(https://ford.biologie.hu-berlin.de/matze/linux-m68k-atarinommu/blob/master/arch/m68k/kernel/process.c#L158),
which is executed under the condition "unlikely(p->flags & PF_KTHREAD)".
Just setting p->thread.usp = usp; did not help and I'm not sure why this
should be necessary anyway.

Another thing I found out is that the crash happens at first call of
resume with the superuser bit set to zero. Before that certain call,
there are many successful calls in superuser mode.

Do you have any idea why this might happen? Is it maybe a nommu-related
issue? Any speculations are welcome.

Thanks in advance!

Best regards,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg Ungerer]

Hi Matthias,

On 16/09/16 08:35, Matthias Reis wrote:
> Hi all,
>
> in the frame of a hobby project (https://ford.biologie.hu-berlin.de/matze/linux-m68k-atarinommu/wikis/home), I did some changes to the kernel to make it boot on MMU-less, original Atari ST machines.
>
> So far, my kernel manages to mount a root filesystem from fd0 and run busybox.
>
> However, busybox (nano-X as well), produces a bus error and crashes the whole kernel:

What procedure did you follow to build your apps?
Are you using flat format binaries?

It is unlikely you would need to change anything here. That code works
as is on nommu ColdFire and other 68k nommu parts (68328 for example).

> Another thing I found out is that the crash happens at first call of resume with the superuser bit set to zero. Before that certain call, there are many successful calls in superuser mode.
>
> Do you have any idea why this might happen? Is it maybe a nommu-related issue? Any speculations are welcome.

So is this crashing at the step of trying to load and run the
first user app?

Regards
Greg

[Andreas Schwab]

On Sep 16 2016, Matthias Reis <matthi...@hu-berlin.de> wrote:

> === objdump -D vmlinux output:
> 000048cc <resume>:
> 48cc: 2208 movel %a0,%d1
> 48ce: 40e8 0320 movew %sr,%a0@(800)
> 48d2: 48e7 031e moveml %d6-%d7/%a3-%fp,%sp@-
> 48d6: 214f 0318 movel %sp,%a0@(792)
> 48da: 4e6b movel %usp,%a3
> 48dc: 214b 031c movel %a3,%a0@(796)
> 48e0: 2669 031c moveal %a1@(796),%a3
> 48e4: 4e63 movel %a3,%usp
> 48e6: 2e69 0318 moveal %a1@(792),%sp
> 48ea: 4cdf 78c0 moveml %sp@+,%d6-%d7/%a3-%fp
> 48ee: 46e9 0320 movew %a1@(800),%sr
> 48f2: 4e75 rtsp
> ===
>
> It can be seen from the register dump given by the hatari debugger, that
> USP contains 0x0 and the superuser bit (indicated by "S=0") is not set:

SR should never contain S=0 at this point, as returning from kernel
context always happens with RTE (via resume_userspace).

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Matthias Reis]

Hi Greg,

On Fri, Sep 16, 2016 at 04:39:06PM +1000, Greg Ungerer wrote:
> What procedure did you follow to build your apps?

In short, I used the -m68000 gcc switch and set the following options:

uClibc .config:
TARGET_ARCH="m68k"
# UCLIBC_FORMAT_FLAT is not set
UCLIBC_FORMAT_FLAT_SEP_DATA=y
# UCLIBC_FORMAT_SHARED_FLAT is not set

busybox .config:
CONFIG_STATIC=y
# CONFIG_PIE is not set
CONFIG_NOMMU=y


The full details can be found under:
https://ford.biologie.hu-berlin.de/matze/linux-m68k-atarinommu/uploads/22f7c78b30c92605adcc8dc40af3220e/build-binutils-gcc-uClibc-busybox.tar.bz2

In the tarball, you can there is a script that should include all steps,
including the ./configure options, as well as all .config's.

> Are you using flat format binaries?

$ ./flthdr ../busybox/busybox_unstripped
./busybox/busybox_unstripped
Magic: bFLT
Rev: 4
Build Date: Mon Sep 5 16:26:38 2016
Entry: 0x44
Data Start: 0x20eb4
Data End: 0x25238
BSS End: 0x27ae0
Stack Size: 0x3e80
Reloc Start: 0x25238
Reloc Count: 0x73
Flags: 0x2 ( Has-PIC-GOT )

> So is this crashing at the step of trying to load and run the
> first user app?

It happens after run_init_process() is called.

Thanks!

Matthias

[Andreas Schwab]

On Sep 16 2016, Matthias Reis <matthi...@hu-berlin.de> wrote:

Given the value of SSP and the values loaded into D6/D7 (which match the
ROM shadow at address 0), it is clear that SP was 0 at $48ea. So it
looks like A1 is just pointing at a block of zeros, not at a valid task
struct.

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Matthias Reis]

Hi Andreas,

On Fri, Sep 16, 2016 at 04:23:05PM +0200, Andreas Schwab wrote:
> > === hatari emulator output:
> > CPU=$48f2, VBL=6379, FrameCycles=86856, HBL=387, LineCycles=168, DSP=N/A
> > $000048f2 : 4e75 rts
> > r
> > D0 00000008 D1 00002200 D2 00005401 D3 00961EC8
> > D4 00000000 D5 00940020 D6 602E0206 D7 00E00030
> > A0 00865B68 A1 00961EEC A2 0080E000 A3 000026E4
> > A4 000045C0 A5 000045E4 A6 00004794 A7 00000000
> > USP 00000000 ISP 00000018
> > T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=2 STP=0
>
> Given the value of SSP and the values loaded into D6/D7 (which match the
> ROM shadow at address 0), it is clear that SP was 0 at $48ea. So it
> looks like A1 is just pointing at a block of zeros, not at a valid task
> struct.

Maybe the allocation for the task struct failed? I will check that. Thanks for
your analysis!

Matthias