Re: badaddr() panics when TT is enabled

At Thu, 13 Apr 2023 00:01:20 +0900,
Izumi Tsutsui wrote:
> > Here is a patch.
> > According to 68030 Users' Manual (Fig.9-39 in p.9-62), the T bit of
> > MMUSR should be checked before any other bits.
> 
> Looks correct.
> At least a patched GENERIC kernel works on my NWS-1750:
:
> [   1.0000000] NetBSD 10.99.3 (GENERIC) #2: Wed Apr 12 23:12:40 JST 2023
> [   1.0000000] 	tsutsui@mirage:/s/cvs/src/sys/arch/news68k/compile/GENERIC
> [   1.0000000] SONY NET WORK STATION, Model NWS-1750, Machine ID #10557
:
> [   1.0000000] zsc0 at hb0 addr 0xe0d40000 ipl 5 vect 64
> [   1.0000000] zstty0 at zsc0 channel 0 (console i/o)
> [   1.0000000] zstty1 at zsc0 channel 1
> [   1.0000000] si0 at hb0 addr 0xe0cc0000 ipl 4
> [   1.0000000] scsibus0 at si0: 8 targets, 8 luns per target

Thank you for your quick response!
Would you also try a case where badaddr() fires in TT area?
I don't know well about NEWS but how about this?

--- a/sys/arch/news68k/conf/GENERIC
+++ b/sys/arch/news68k/conf/GENERIC
@@ -196,7 +196,8 @@ zstty1  at zsc0 channel 1
 # and disable disconnect/reselect for targets 0-3
 #
 si0    at hb0 addr 0xe0cc0000 ipl 4 flags 0x0
-scsibus* at si0
+si1    at hb0 addr 0xe0c40000 ipl 4 flags 0x0
+scsibus* at si?

 sd*    at scsibus? target ? lun ?      # SCSI disks
 st*    at scsibus? target ? lun ?      # SCSI tapes

If NEWS hardware returns a bus error where device is not present,
the patched kernel will boot (without si1).

> Some comments:
> 
> > --- a/src/sys/arch/m68k/m68k/busaddrerr.s
> > +++ b/src/sys/arch/m68k/m68k/busaddrerr.s
> > @@ -219,7 +219,12 @@ Lbe10:
> >  	jeq	Lbe10a			| if no, done
> >  	movql	#5,%d0			| else supervisor program access
> >  Lbe10a:
> > -	ptestr	%d0,%a0@,#7		| do a table search
> > +	ptestr	%d0,%a0@,#0		| check without table search
> 
> I prefer a comment like "check entire the ATC" per UM 9.7.4.

Hmm, I don't see your point.
This ptestr is not intended to check the entire ATC.
It is intended to detect that the address %a0@ is located in TT
area (and in that case, it's not necessary to do neither a table
search nor an ATC check).

> > +	pmove	%psr,%sp@
> 
> Put "save result" comment as the existing #7 check?

This pmove is not intended to save the result.  It only loads
%psr to %d1 via stack due to addressing mode restriction.

By the way, I'm not sure whether the comment "save result" at
ptestr #7 is still correct today...  Just a quick look, I could
not find who use this saved %psr in the stack.
I will left it as is this time.

> > +	movw	%sp@,%d1
> > +	btst	#6,%d1			| TT?
> 
> Also prefer "transparent (TT0 or TT1)?" or so per UM Table 9-3.

I will do so.

> > I have confirmed it on luna68k (real LUNA-I):
> >  - lcd_match() uses badaddr().  It works on an address that
> >    device is present even with above patch.
> >  - The following is a PoC patch.  0xc0000000 on LUNA-I is in TT
> >    area and causes a bus error.  badaddr() without above patch
> >    panics for this address but with above patch don't panic.
> 
> How about enabling enabling badaddr() in spc_mainbus_match()
> and specify the second SPC on LUNA-I?
> (I should check it myself but I'm a bit lazy)

(You looks to have resolved it by yourself but just for recording.)
Unfortunately, it's not possible to find spc0 and spc1 correctly
by only using current spc_mainbus_match() on LUNA due to its hard-
ware characteristics.

Thanks,
---
Tetsuya Isaki <[email protected] / [email protected]>