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: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

Hi Finn, Geert, > + /* We are passed DMA addresses i.e. physical addresses, but must > use > +* kernel virtual addresses here, so remap to virtual. This is > easy > +* enough for the case of residual bytes of an extended message in > +*

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