Removing options MIPS3 cause DS5000 to loop during boot
Erik Bertelsen <[email protected]> Thu, 21 Apr 2011 17:42:52 +0200
| Newsgroups | gmane.os.netbsd.ports.pmax |
|---|---|
| Message-ID | <[email protected]> |
I have a DS5000/133 where I try to keep NetBSD running and self-buildable. This has not been possible for the last year or so, but after recent work on the mips architecture, the situation has improved somewhat. I used to have a trimmed-down custom kernel that just supports the hardware present in the machine, but this kernel does not work. A current GENERIC kernel does, however, boot and then fails when going multi-user, but that's another story about updating userland. Now I have started from scratch and done several reductions from GENERIC to see when it stops working. If I remove support for non 3MIN machines like this: diff S2 S4 34,36d33 < options DEC_3100 # DECstation 2100, 3100 (kn01) < options DEC_5100 # DECsystem 5100 (kn230) < options DEC_3MAX # DECstation 5000/200 (kn02) 38,43d34 < options DEC_MAXINE # Personal DECstation 5000/xx (kn02ca) < options DEC_3MAXPLUS # DECstation 5000/240 (kn03), 5000/260 (kn05) < < #options DEC_5400 # DECsystem 5400 (kn210) < #options DEC_5500 # DECsystem 5500 (kn220) < #options DEC_5800 # DECsystem 58x0 (kn5800) 211,220d201 < # 3MAX has TURBOchannel but no IOASIC < ibus0 at tc? slot ? offset ? # 3MAX system slot < < # PMAX, 3MAX and MIPSMATE common devices < mcclock* at ibus0 addr ? # DS1287 RTC < dz* at ibus0 addr ? # DC7085 quad line serial device < < lkkbd* at dz? line 0 # Keyboard < vsms* at dz? line 1 # Mouse < 236,241d216 < # PMAX and MIPSMATE < ibus0 at mainbus0 < pm* at ibus0 addr ? # 3100 onboard fb < le* at ibus0 addr ? # 3100, 5100 onboard LANCE < sii* at ibus0 addr ? # DC7061 onboard SCSI < 257d231 < wsdisplay* at pm? 264d237 < scsibus* at sii? the machine can still boot to single user and give me a prompt where I can work. If I further remove MIPS3 support: diff S4 S5 30d29 < options MIPS3 # R4000/R4400 CPUs then the machine boots to the point of starting init and then hangs solidly -- the only recovery seems to power cycle the machine. The full console output is: KN02-BA V5.7j >>boot 3/rz4/netbsd.s5 NetBSD/pmax 1.6ZC FFS Primary Bootstrap NetBSD/pmax 5.99.40 Secondary Bootstrap, Revision 1.5 ([email protected], Sat Oct 10 23:31:25 CEST 2009) Boot: 3/rz4/netbsd.s5 3056528+110568 [189424+184633]=0x360db8 Starting at 0x80030000 segment 0 start 00000000 size 02000000 phys segment: 0x2000000 @ 0 adding 0x46d000 @ 0x393000 to freelist 1 adding 0x1800000 @ 0x800000 to freelist 0 pmap_steal_memory: seg 0: 0x393 0x393 0x800 0x800 pmap_steal_memory: seg 0: 0x3b9 0x3b9 0x800 0x800 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.99.49 (S5) #0: Thu Apr 21 17:21:51 CEST 2011 [email protected]:/home/NetBSD/crossbuild/obj.pmax/sys/arch/pmax/compile/S5 DECstation 5000/133 (3MIN) total memory = 32768 KB avail memory = 28304 KB mainbus0 (root) cpu0 at mainbus0: MIPS R3000A CPU (0x230) Rev. 3.0 with MIPS R3010 FPC Rev. 4.0 cpu0: 64KB/4B direct-mapped Instruction cache, 64 TLB entries cpu0: 128KB/4B direct-mapped write-through Data cache tc0 at mainbus0: 12.5 MHz clock ioasic0 at tc0 slot 3 offset 0x0 le0 at ioasic0 offset 0xc0000: address 08:00:2b:32:56:6f le0: 32 receive buffers, 8 transmit buffers zsc0 at ioasic0 offset 0x100000 vsms0 at zsc0 channel 0 wsmouse0 at vsms0 mux 0 zstty0 at zsc0 channel 1 zsc1 at ioasic0 offset 0x180000 lkkbd0 at zsc1 channel 0 wskbd0 at lkkbd0 mux 1 zstty1 at zsc1 channel 1 (console i/o) mcclock0 at ioasic0 offset 0x200000: mc146818 or compatible asc0 at ioasic0 offset 0x300000: NCR53C94, 25MHz, SCSI ID 7 scsibus0 at asc0: 8 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 4 lun 0: <QUANTUM, QM39100TD-S, N1B0> disk fixed sd0: 8683 MB, 8057 cyl, 10 head, 220 sec, 512 bytes/sect x 17783249 sectors sd0: sync (200.00ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing boot device: sd0 root on sd0a dumps on sd0b root file system type: ffs pid 1(init): ABI set to O32 (e_flags=0x1007) There is not difference in the console messages between the S4 and S5 kernels except that the 'avail memory' has increased slightly (because of a smaller kernel?) Can anyone explain this? I'll be happy to test patches to resolve this. kind regards - Erik