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 be interesting to see whether I get that triggered some
way.
But the mmusr in the panic log from Stan is 0x400 which is MMU_I. So you
should have taken the first branch here.
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).
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.
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
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?
- What was the author trying to achieve? Why a special case for RMW
faults?
- How much latitude is there to change this without breaking weird
platforms?
- Should the dead code be deleted because the live algorithm cannot be
improved upon? (The present algorithm works fine for PDMA for example.)
--
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
