Subject: Re: "Bad pAUX_base" again
To: None <firstname.lastname@example.org>
From: Bruce O'Neel <email@example.com>
Date: 10/07/2005 10:06:54
Sorry this isn't a true followup. Back around 5/9 through 9/9 there
was chatter about Bad pAUX_base and which systems this occured on. I
finally got the time and put a 60mhz SuperSparc in a SS20 and did a
build.sh run. 3 days later and we don't have any cores nor Bad
pAUX_base messages in the build log.
So, the current status seems to be:
- MicroSparc IIs @ 110mhz in SS4 and SS5 system. Yes, you get it.
(me SS4, Laurent FAILLIE SS5)
- SparcBook and Krups with basically the same CPUs, yes. (Michael)
- Dual Supersparc @ 50mhz in a SS20. Yes, so often that it is
unusable. (Rui Paulo)
- Tri hypersparc @ different mhz in a SS20. I've never seen it. I've
also not seen it with assorted other hypersparc combos that I've run
over time. They all have been rock solid. (me)
- Single supersparc @ 60mhz in a SS20, seems not. (me)
- one has to assume that some other types of systems are ok otherwise
there would be more chatter about this.
Is it the level 2 cache? (I'm frowning but you can't see that) The
microsparc IIs don't have it. My hypersparcs do, and so does my
Rui Paulo, according the the snippet of your dmesg, your 50mhz CPUs
don't. What exact part numbers are they?
According to http://mbus.sunhelp.org/modules/index.htm the 501-2568,
501-2712, 501-2528, and 501-2708 are up to 50 mhz but have no cache.
Is this what you have?
Can someone shed any more light on this? If someone has one of the
above 50mhz mbus modules and are close to Geneva I wouldn't mind
swapping cpu modules to see if that's the problem.
This is the dmesg from the working SS20 with a supersparc.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
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 3.99.7 (GENERIC.MP) #0: Tue Jun 28 22:17:21 CEST 2005
total memory = 97604 KB
avail memory = 91456 KB
mainbus0 (root): SUNW,SPARCstation-20: hostid 72772a74
cpu0 at mainbus0: TMS390Z50 v0 or TMS390Z55 @ 60 MHz, on-chip FPU
cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled
obio0 at mainbus0
clock0 at obio0 slot 0 offset 0x200000: mk48t08
timer0 at obio0 slot 0 offset 0x300000: delay constant 28
zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
kbd0 at zs1 channel 0: baud rate 1200
ms0 at zs1 channel 1: baud rate 1200
fdc0 at obio0 slot 0 offset 0x700000 level 11: no drives attached
auxreg0 at obio0 slot 0 offset 0x800000
power0 at obio0 slot 0 offset 0xa01000 level 2
iommu0 at mainbus0 ioaddr 0xe0000000: version 0x3/0x1, page-size 4096, range 64MB
sbus0 at iommu0: clock = 25 MHz
dma0 at sbus0 slot 15 offset 0x400000: DMA rev 2
esp0 at dma0 slot 15 offset 0x800000 level 4: ESP200, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
ledma0 at sbus0 slot 15 offset 0x400010: DMA rev 2
le0 at ledma0 slot 15 offset 0xc00000 level 6: address 08:00:20:77:2a:74
le0: 8 receive buffers, 2 transmit buffers
bpp0 at sbus0 slot 15 offset 0x4800000 level 2 (ipl 3): DMA rev 2
SUNW,DBRIe at sbus0 slot 14 offset 0x10000 level 9 not configured
eccmemctl0 at mainbus0 ioaddr 0x0: version 0x0/0x2
Kernelized RAIDframe activated
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 3 lun 0: <QUANTUM, FB1080J SUN1.05, 630D> disk fixed
sd0: 1042 MB, 3835 cyl, 4 head, 139 sec, 512 bytes/sect x 2134305 sectors
sd0: sync (100.00ns offset 8), 8-bit (10.000MB/s) transfers
root on sd0a dumps on sd0b
root file system type: ffs
cpu0: booting secondary processors:
SDF Public Access UNIX System - http://sdf.lonestar.org