Re: [RFC] m68k: Fix dead code in bus_error030()

On Sat, 10 Mar 2018, Michael Schmitz wrote: > > > > It's a hardware exception, not a software exception. The bus error is > > generated by signals from one of Apple's ASICs. This logic circuit > > effectively interfaces the SCSI bus with the system bus, via the SCSI > > controller, for

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, Am 10.03.2018 um 11:51 schrieb Finn Thain: > On Fri, 9 Mar 2018, Michael Schmitz wrote: > >> How does the PDMA logic raise the exception? If we find none of the >> usual MMU status register bits are set, we could take that as an >> indication that the exception wasn't raised by the

Re: [RFC] m68k: Fix dead code in bus_error030()

On Fri, 9 Mar 2018, Geert Uytterhoeven wrote: > If it introduced a crash, it is not dead code? > That code was dead when I wrote about it in 2014 and it's still dead now. True, it is not dead after the RFC patch (but the patch is incomplete so it crashes). -- -- To unsubscribe from this

Re: [RFC] m68k: Fix dead code in bus_error030()

On Fri, 9 Mar 2018, Michael Schmitz wrote: > How does the PDMA logic raise the exception? If we find none of the > usual MMU status register bits are set, we could take that as an > indication that the exception wasn't raised by the MMU, so no page or > protection fault. Pretty much leaves

Re: [RFC] m68k: Fix dead code in bus_error030()

Geert, the crash was introduced after Finn re-livened the dead code (and thereby bypassed exception table fix-up AFAICS). Cheers, Michael Am 09.03.2018 um 21:12 schrieb Geert Uytterhoeven: > Hi Finn, > > On Fri, Mar 9, 2018 at 8:13 AM, Finn Thain wrote:

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, Am 09.03.2018 um 20:13 schrieb Finn Thain: >> mmusr was reloaded in the default branch so might have been modified >> from the first test. > > Right. That mmusr value in the log is not the original value. It comes > from an ATC search with function code 1. That's a user mode search,

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, On Fri, Mar 9, 2018 at 8:13 AM, Finn Thain wrote: > On Fri, 9 Mar 2018, Michael Schmitz wrote: > I think I can find a solution for that. The main reason for this RFC is a > bunch of question I can't answer: > > - What are the implications of the existing

Re: [RFC] m68k: Fix dead code in bus_error030()

On Fri, 9 Mar 2018, Michael Schmitz wrote: > > > > What raises that signal in the !(mmusr & (MMU_I | MMU_WP)) && (ssw & > > RM) case? > > You're right - these aren't handled at all by the present code. With > your patch, these are either handled as invalid access or 'weird > access'. Would

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, Am 05.03.2018 um 21:29 schrieb Finn Thain: > On Mon, 5 Mar 2018, Michael Schmitz wrote: > >> About evading a signal - as the code is now, any faults that are not >> write protect or invalid MMU descriptor faults would end up in that >> branch. In particular, for anything that should

Re: [RFC] m68k: Fix dead code in bus_error030()

On Mon, 5 Mar 2018, I wrote: > The only sensible place for the !(mmusr & MMU_I) test is inside the > (mmusr & (MMU_I | MMU_WP)) branch. It is redundant when used in the > else branch. > > Moreover, when used in the else branch it defeats the remaining > conditionals. Hence the (mmusr &

Re: [RFC] m68k: Fix dead code in bus_error030()

On Mon, 5 Mar 2018, Michael Schmitz wrote: > About evading a signal - as the code is now, any faults that are not > write protect or invalid MMU descriptor faults would end up in that > branch. In particular, for anything that should have been caught by the > branch below, we'd expect to see

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, makes sense, unless that else_if branch was meant to follow the if (do_page_fault (>ptregs, addr, errorcode) < 0) (which it clearly doesn't, and this code hasn't changed since 2.4.30 at least. The net effect would be the same as after your patch.). Worth a try IMO. About evading a

[RFC] m68k: Fix dead code in bus_error030()

The only sensible place for the !(mmusr & MMU_I) test is inside the (mmusr & (MMU_I | MMU_WP)) branch. It is redundant when used in the else branch. Moreover, when used in the else branch it defeats the remaining conditionals. Hence the (mmusr & (MMU_B|MMU_L|MMU_S)) branch is unreachable, along