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 have been caught by the
branch below, we'd expect to see kernel mode faults cause signals or
unexpected bus errors that should really have caused a panic. I've never
seen these unexpected bus errors in my logs.
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. 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.
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?
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
