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, so
it's probably meaningless here.
Can you print mmusr in the first pr_err() in that branch, before it's
reloaded? Otherwise we can't hope to see what the fault condition was.
The presence of the "level 0 mmusr" message clearly means that we are on
the default branch and hence the original mmusr has no bits set among
(MMU_I|MMU_WP|MMU_B|MMU_L|MMU_S).
Leaves MMU_M and MMU_T, but I rather doubt these would be at issue here.
It's normal for the PDMA logic to raise these exceptions. There's nothing
wrong with the access that generated the fault, hence Roman Zippel's patch
for 040 below.
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 only the PDMA logic (if present).
Regarding changes to the 040 fault handler to accomodate PDMA - git
history doesn't go back that far. Do we still have an old CVS repo with
ancient history?
It's in mainline, commit 3b17f136bf32 ("m68k: Handle 68040 bus faults").
See also https://marc.info/?l=linux-m68k&m=120344206029296
Oh, bother.
Does hwreg_present() go through the default exception handling, or would
it be immune against problems there?
This might explain the trouble I had when probing for the absent
EtherNAT device when the Falcon runs in 030 mode. Works on 040 (and
probably 060 as well) after Roman's patch, but kills the 030 stone dead
(recursive faults??). I discussed this with Geert and we blamed ioremap
running too early in the boot, but it might be a problem with the 030
fault handler. I'll try to dig up what I have on that problem - the
Atari platform device set-up code hasn't changed in five years and I
don't see the problem anymore these days.
The changes in this RFC mean that mac_scsi on '030 fails in the same way
that '040 used to fail before Roman made allowances for my mac_esp driver.
Apparently this patch needs changes equivalent to Roman's patch.
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 logic error?
We might miss handling (MMU_B|MMU_L|MMU_S) && (ssw & RM) (should be
harmless), and might log (MMU_B|MMU_L|MMU_S) && !(ssw & RM) as
unexpected bus error if there wasn't a user process to signal or an
exception vector to fix up, or even panic. Doesn't seem to happen though.
- What was the author trying to achieve? Why a special case for RMW
faults?
Because the 020 can't do RMW instructions, so these faults have to be
expected? (My memory might be tripping me up there, though..)
- How much latitude is there to change this without breaking weird
platforms?
Are there any weirder platforms than Mac ? ;-)
- Should the dead code be deleted because the live algorithm cannot be
improved upon? (The present algorithm works fine for PDMA for example.)
The end result might be the same with the current code (except for PDMA
working): signal to user process (maybe the wrong one; weird access
forces SEGV), or panic. The main difference is we don't fix up the
exception from process exception tables. I believe that is what makes
PDMA work, i.e. fixes up the PDMA bus fault?
So perhaps try send_fault_signal() in the default branch, which will
also run die_if_kernel() if need be.
(I'm no mm whiz, as you certainly know. Might be more prudent to leave
the code as-is, and slap on a comment 'do not touch' ...)
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
