Re: Update PS2 R5900 to kernel 4.x?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 4 aug. 2017 kl. 16:13 skrev Joshua Kinard <kumba@xxxxxxxxxx>:
> 
> Digging back into the Linux/MIPS git repo, it looks like this commit is part of
> a branch that Viro was working on and there's one more commit by Viro that
> comes after it, 50150d2bb903 ("mips: switch to generic sys_fork() and
> sys_clone()").  So you might try to apply that change after 64b3122df48b, then
> apply the three changes by Ralf in the same branch as well.  The branch merges
> back into the main/master branch after that.

I’ve tried Al’s following commit and Ralf’s commits (except the whitespace
cleanup change which conflicts a lot), but unfortunately it still crashes in
the same way. The top commits of

    https://github.com/frno7/linux/tree/ps2-v3.9-rc1-memory-fault

are

    1: abb12d2 mips: switch to generic sys_fork() ... [cp of 50150d2b]
    2: a17178c mips: take the "zero newsp means inherit ... [cp of 64b3122d]
    3: 3de638d Experimental update for Playstation 2
    4: 974fdb3 mips: no magic arguments for sysm_pipe()
       ...
       12890d0 MIPS: sysmips: Rewrite to use SYSCALL_DEFINE3().
       f2ace93 MIPS: sysmips: Use unreachable().

where (4) is part of v3.9-rc1, (3) is the PS2 patch (which boots to Busybox),
and (2) and (1) are Al’s patches cherry-picked and adapted for (3) by removing
_sysn32_clone and replacing {sysn32_clone,sys_fork} with __sys_{clone,fork} in
arch/mips/kernel/scall32-n32.S (updates that seem obvious). So there are some
further adaptions that need to be done but I’m not sure what these could be.

Al’s changes touch MIPS register 29, perhaps the PS2 patch assumes something
about it that becomes invalid?

> It appears the busybox init didn't like the changes to _sys_fork in
> 64b3122df48b, and is thus crashing, which causes the kernel to panic due to PID
> 1 dying.  Usually, the first thing init does after loading is fork off a call
> to the shell/interpreter to start parsing the startup scripts, or process
> /etc/inittab to load up what's specified in the runlevels.  That means the
> "Memory fault" messages are not coming from the kernel, but from userland.

Is it possible to print detailed memory fault backtraces in a simple way?

Fredrik





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux