Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)

To: port-hp300%netbsd.org@localhost, thorpej%me.com@localhost
Subject: Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Date: Sun, 7 Jan 2024 13:07:48 +0900
thorpej@ wrote on port-m68k:
 https://mail-index.netbsd.org/port-m68k/2024/01/06/msg000845.html

> > I guess we can simply change PGSHIFT to 13, but I wonder we should
> > also consider again to reorganize 040 pmap to make it possible to
> > expand L2 STEs on demend, as mhitch@ mentioned back in 2009:
> > https://mail-index.netbsd.org/port-m68k/2009/05/12/msg000143.html
> > 
> > Maybe we also have to consider about 3-level pmap like sun3x..
> > https://mail-index.netbsd.org/port-m68k/2001/07/20/0003.html
> 
> That's an idea, but that won't work for the HP MMU on the 320 / 350.

I should have asked this earlier, but now is the good timing:
 "I'm considering dropping support of (at least) HP320 and HP318/319/330"

The reason why is it looks memory bus design of these hardware
don't support CAS instruction.

Recently (back in 2022) I have acquired HP319 and HP320
(as hp300 maintainer) and tried NetBSD 9.3.
However both machine panicked by bus error on CAS instructions
in mutex_enter(9) during early boot:

---
SELF-TEST MODE
Copyright 1987,
Hewlett-Packard Company.
All Rights Reserved.

BOOTROM Rev. C
Bit Mapped Display
MC68020 Processor
MC68881 Coprocessor
Keyboard
RESET To Power-Up

 LOADING MEMORY

 SELF-TEST MODE
HP-IB
DMA-C0

 TESTING MEMORY

 SELF-TEST MODE
RAM 8388384 Bytes
HP98644 (RS232) at 9
HP98625 (HPIB) at 14
HP98643 (LAN) at 21, 080009026A99

 SEARCHING FOR A SYSTEM (RETURN To Pause)
:HP7958, 1400, 0, 0

   1Z SYS_UBOOT


 BOOTING A SYSTEM
>> NetBSD/hp300 Primary Boot, Revision 1.21 (Thu Aug  4 15:30:37 UTC 2022) (from NetBSD 9.3)
>> HP 9000/318/319/330 SPU
>> Enter "reset" to reset system.
Boot: [[[rd8a:]netbsd][-a][-c][-d][-s][-v][-q]] :-  -s
3103228+137028 [371392+243934]=0x3ad8b8
Start @ 0xff803400 [1=0xffb19140-0x3ad8b8]...
Entry point: 0xff803400
[   1.0000000] bootinfo found at 0xff802000
[   1.0000000] trap type 0, code = 0x1c5, v = 0x311a7c
[   1.0000000] kernel program counter = 0x1e0c0
[   1.0000000] kernel: Bus error trap
[   1.0000000] pid = 0, lid = 1, pc = 0001E0C0, ps = 2710, sfc = 1, dfc = 1
[   1.0000000] Registers:
[   1.0000000]              0        1        2        3        4        5        6        7
[   1.0000000] dreg: 00000000 002EFB40 00000002 013E3000 0001E0B4 0001E0CE 00000000 0000001C
[   1.0000000] areg: 00311A7C 013E3000 00311A08 002F2148 00311A7C 0015E06C 003AFDE4 FFEFFFFC

[   1.0000000] Kernel stack (003AFBC0):
[   1.0000000] 3AFBC0: 00013620 003AFD18 00000080 00000002 013E3000 0001E0B4 0001E0CE 00000000
[   1.0000000] 3AFBE0: 0000001C 00311A08 002F2148 00311A7C 0015E06C 003128D4 00312BE4 0030C73C
[   1.0000000] 3AFC00: 0001E0CE 00312C40 00000004 00000001 00000000 001A3F02 003133E8 00312BF0
[   1.0000000] 3AFC20: 0001E0B4 003AFC5C 001A4094 003128D4 00312BE4 0030C73C 00000000 00000000
[   1.0000000] 3AFC40: 001A3F02 0018271A 001700B0 001512D8 00312BE4 00312BF0 00312CD0 00001000
[   1.0000000] 3AFC60: 00000000 00000000 00001000 00312BE4 003133E0 00312BF0 00000000 003AFC94
[   1.0000000] 3AFC80: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   1.0000000] 3AFCA0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   1.0000000] 3AFCC0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   1.0000000] 3AFCE0: 00000000 00000000 00000000 00000000 00000000 00000000 013D16E0 013D1860
[   1.0000000] 3AFD00: 003AFDE4 00001968 003AFD18 00000000 000001C5 00311A7C 00000000 002EFB40
[   1.0000000] 3AFD20: 00000002 013E3000 0001E0B4 0001E0CE 00000000 0000001C 00311A7C 013E3000
[   1.0000000] 3AFD40: 00311A08 002F2148 00311A7C 0015E06C 003AFDE4 FFEFFFFC 00000000 27100001
[   1.0000000] 3AFD60: E0C0B008 1E2C01C5 66024E75 00311A7C 00311A7C 002EFB40 0ED00040 0001E0C8
[   1.0000000] 3AFD80: 0001E0C6 0001E0C4 FFFAFFFF 00400040 000F11AF 00000000 00000002 00000040
[   1.0000000] 3AFDA0: 00000040 C0200000 003AFDBC 0000D7EF 00000000 003AFDE8 0019CBEC 00311A7C
[   1.0000000] panic: Bus error
[   1.0000000] cpu0: Begin traceback...
[   1.0000000] ?(?)
[   1.0000000] db_panic(2714,0,ffffff7f,19fd40,3afbc0) at 0
[   1.0000000] vpanic(25cf6a,3afbcc,3afd00,1363c,25cf6a) + 162
[   1.0000000] panic(25cf6a,2,13e3000,1e0b4,1e0ce) + c
[   1.0000000] trap(3afd18,0,1c5,311a7c) + 268
[   1.0000000] mutex_enter(?)
[   1.0000000] pool_get(311a08,2,2,13d69a4,13d692c) + c
[   1.0000000] pool_grow(13d692c,2) + 26a
[   1.0000000] pool_get(13d692c,2,13d6a1c,2710,0) + dc
[   1.0000000] pool_cache_get_slow(13d6aac,2710,3afe9c,0,2) + e6
[   1.0000000] pool_cache_get_paddr(13d692c,2,0) + 90
[   1.0000000] kmem_intr_alloc(?)
[   1.0000000] kmem_alloc(400,2) + 88
[   1.0000000] hashinit(100,0,0,30c1cc,c) + a2
[   1.0000000] uao_create(0,ff800000,2,13d1000,ff800000,3aff4c,3aff50,30c380,0,9c) + ee
[   1.0000000] uvm_init(c,ffffffff,ffffffff,3ae000,a1000002) + 9a
[   1.0000000] uvm_fault(0x30cb00, 0xa0fff000, 0x1) -> 0xe
[   1.0000000]   type 8, code [mmu,,ssw]: 4810145
[   1.0000000] trap type 8, code = 0x4810145, v = 0xa0fffffc
[   1.0000000] kernel program counter = 0x14304
[   1.0000000] kernel: MMU fault trap
[   1.0000000] trap during panic!
[   1.0000000] pid = 0, lid = 1, pc = 00014304, ps = 2704, sfc = 1, dfc = 1
[   1.0000000] Registers:
[   1.0000000]              0        1        2        3        4        5        6        7
[   1.0000000] dreg: 00000004 00000004 003AFA8C 00000004 4AB90000 0000FFF2 00000001 0025A1A8
[   1.0000000] areg: 003AFA8C A0FFFFFC A1000002 000AEB58 003AFB18 000B2EE0 003AFA6C FFEFFFFC

[   1.0000000] Kernel stack (003AF874):
[   1.0000000] 3AF874: 00013620 003AF9CC 00000080 003AFA8C 00000004 4AB90000 0000FFF2 00000001
[   1.0000000] 3AF894: 0025A1A8 A1000002 000AEB58 003AFB18 000B2EE0 0030E6C8 0019FAAA 00000001
[   1.0000000] 3AF8B4: 0030CB00 A0FFF000 00000000 003AF9E0 00000000 003AF9A0 003AF9A0 0026DB58
[   1.0000000] 3AF8D4: 00000000 00000007 003128D4 00000000 003AF91F 00000006 00000000 00000000
[   1.0000000] 3AF8F4: 00000000 0000000F 00000000 003AF9E0 00000001 0001E0B4 003AF944 003AF940
[   1.0000000] 3AF914: 0003925E 002F5F14 003AF94C 0003925E 002F5F14 005BB010 00000000 0000000A
[   1.0000000] 3AF934: 0000000A 00000001 00000000 00000000 00000000 00000000 00000001 00000000
[   1.0000000] 3AF954: 00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000
[   1.0000000] 3AF974: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   1.0000000] 3AF994: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 003AF9EB
[   1.0000000] 3AF9B4: 003AFA6C 00001968 003AF9CC 00000008 04810145 A0FFFFFC 00000004 00000004
[   1.0000000] 3AF9D4: 003AFA8C 00000004 4AB90000 0000FFF2 00000001 0025A1A8 003AFA8C A0FFFFFC
[   1.0000000] 3AF9F4: A1000002 000AEB58 003AFB18 000B2EE0 003AFA6C FFEFFFFC 00000000 27040001
[   1.0000000] 3AFA14: 4304B008 1C2C0145 60227202 A0FFFFFC 003AFA8C 00000004 20912091 0001430A
[   1.0000000] 3AFA34: 00014308 00014306 FFFFFFFF 6022FF04 000F1481 00000000 00000000 00003800
[   1.0000000] 3AFA54: 00000000 80200000 003AFA7C 00000000 00A10000 003AFAA0 003AFA90 000AEB7A
[   1.0000000] Skipping crash dump on recursive panic
[   1.0000000] panic: MMU fault
[   1.0000000] Faulted in mid-traceback; aborting...
Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x6:        unlk    a6
db> 
---

NetBSD/hp300 5.0 also fails in mutex_enter(9).
NetBSD/hp300 4.0.1 boots:
 https://dmesgd.nycbug.org/index.cgi?do=view&id=6786

(The late) ryo@ commented that he also saw the similar bus errors
on CAS/TAS instructions on his X68000 with 3rd party expansion RAM
that didn't support read-modified-write cycle.

I'm afraid HP320 and HP330 (also 318/319) have the similar hardware
design, because SMP was unlikely yet in 1980s.
(though it looks Sun 3/60 bus supports CAS properly)

I tried to build a kernel without CAS but using RAS for sun2/m68010
implementation, it booted to multiuser on HP320:
 https://twitter.com/tsutsuii/status/1597909609205104640

(BTW, it looks HP98543 topcat seems to have VRAM only at even addresses
 so we need more work in rasops(9) (as 4-depth in 16-bpp?) to support
 it properly)

If the only reason we cannot switch to 3-level MMU pmap is HP-MMU,
those machines (at least HP320) need more special work, including
userland binaries, to keep them "supported".  That's my point.


I wonder if HP350 (that has RAMs on its local bus, not 16-bit DIO bus?)
supports CAS/TAS instructions (i.e. read-modified-write cycle), but
I have not have a chance to acquireq it.

Does anyone still have HP350 and tried recent NetBSD (5.0 and later)
on it?

Thanks,
---
Izumi Tsutsui
Follow-Ups:
- Re: Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
  - From: Jason Thorpe
Prev by Date: Sv: Re: I8n oddity on HP9000/340
Next by Date: Re: Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
Previous by Thread: I8n oddity on HP9000/340
Next by Thread: Re: Considering EOL of HP320/330/350 (Re: NetBSD/virt68k booting multi-user)
Indexes:
Home | Main Index | Thread Index | Old Index