Subject: port-sparc/10263: panic during timer attachment
To: None <>
From: Havard Eidnes <>
List: netbsd-bugs
Date: 06/02/2000 03:26:13
>Number:         10263
>Category:       port-sparc
>Synopsis:       panic during timer attachment
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 02 03:27:00 PDT 2000
>Originator:     Havard Eidnes
>Release:        NetBSD-current 20000601
	NetBSD 1.4Y NetBSD 1.4Y (ANKER) #1: Thu May 11 14:20:54 CEST 2000 sparc
System: NetBSD 1.4Y NetBSD 1.4Y (ANKER) #1: Thu May 11 14:20:54 CEST 2000 sparc

	A sparc kernel compiled from June 1 2000 sources crashes early
	during the attachment of the on-board timer on our Sparc 600MP
	system, like this:

anker# reboot
Jun  2 10:50:45 anker reboot: rebooted by root
Jun  2 10:50:45 anker reboot: rebooted by root
Jun  2 10:50:45 anker syslogd: exiting on signal 15
Jun  2 10:50:45 anker syslogd: exiting on signal 15
syncing disks... 4 4 1 done

Resetting ... 
SPARCsystem 600MP Series (2 X CY605C), No Keyboard
ROM Rev. 2.5, 128 MB memory installed, Serial #4196356.
Ethernet address 8:0:20:e:f7:94, Host ID: 71400804.

Rebooting with command:                                               
Boot device: /iommu/sbus/dma@f,81000/esp@f,80000/sd@3,0   File and args: 
: >> NetBSD/sparc Secondary Boot, Revision 1.9
: >> (pk@sam, Tue Apr 11 19:44:58 MEST 2000)
Booting netbsd
1698316+104688+182280 [68+103600+81973]=0x2221f8
entry: 0x4000, bootinfo: 0x2261f8
bootinfo[0]=0x2265f8; bootinfo[1]=0x226200
nsym=0x1, ssym=0x1f8b08, esym=0x2261f8
OBP version 3, revision 2.5 (plugin rev 2)
[ preserving 186096 bytes of netbsd ELF symbol table ]
Copyright (c) 1996, 1997, 1998, 1999, 2000
    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 1.4Z (ANKER) #2: Fri Jun  2 01:50:45 CEST 2000
total memory = 127 MB
avail memory = 115 MB
using 896 buffers containing 6632 KB of memory
bootpath: /iommu0/sbus0/dma@f,81000/esp@f,80000/sd@3,0
mainbus0 (root): SUNW,Sun 4/600
cpu0 at mainbus0: mid 8: CY7C601/605 (v.c) @ 40 MHz, RT602 or WTL3171 FPU
cpu0: 64K byte write-back, 32 bytes/line, sw flush: cache enabled
cpu1 at mainbus0: mid 9: CY7C601/605 (v.c) @ 40 MHz, RT602 or WTL3171 FPU
cpu1: 64K byte write-back, 32 bytes/line, sw flush: cache enabled
obio0 at mainbus0
clock0 at obio0 slot 0 offset 0x200000: mk48t08 (eeprom)
timer0 at obio0 slot 0 offset 0x300000data fault: pc=0xf01310f8 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW>
panic: kernel fault
Stopped in swapper at   cpu_Debugger+0x4:       jmpl            [%o7 + 0x8], %g0

db{0}> show regs
No such command
db{0}> show ?
Bad character
all             map             buf             registers
arptab          object          vnode           watches
breaks          page            pool
db{0}> show registers
psr         0x11001fc6
pc          0xf015ff94  cpu_Debugger+0x4
npc         0xf015ff98  cpu_Debugger+0x8
y            0x1c00000
wim         0xf01bd400  defcorename+0xa0
g0                   0
g1          0xf01cc460  kmem_map_store
g2                   0
g3                0x93
g4          0xf01cc488  kmem_map_store+0x28
g5          0xffffffff  end+0xfe074f7
g6                0x10
g7                   0
o0                 0x1
o1          0xf01bbc00  db_examine_format+0x8
o2          0xf01bd400  defcorename+0xa0
o3                   0
o4          0xf01ba1ac  u0+0x179c
o5                 0x5
o6          0xf01ba0f0  u0+0x16e0
o7          0xf003eff8  panic+0x74
l0          0xf01bd400  defcorename+0xa0
l1                 0x1
l2                 0x3
l3          0xf01ba1d9  u0+0x17c9
l4                   0
l5                0x2c
l6          0xf0187060  fmt.80+0x1138
l7                   0
i0          0xf019d8d0  T+0x4a8
i1               0x100
i2          0xf01bd400  defcorename+0xa0
i3          0xf01ba1b8  u0+0x17a8
i4                0x1e
i5                   0
i6          0xf01ba158  u0+0x1748
i7          0xf015eb48  mem_access_fault4m+0x310
cpu_Debugger+0x4:       jmpl            [%o7 + 0x8], %g0
db{0}> trace
mem_access_fault4m(0x0, 0x126, 0x0, 0xf01ba260, 0x1, 0x1000) at mem_access_fault4m+0x310
memfault_sun4m(0x1, 0x78, 0xf1302000, 0x0, 0x2, 0xf01f8800) at memfault_sun4m+0xe4
_sbus_bus_map(0x4, 0x0, 0xf0002000, 0x2, 0xf05ecfb0, 0x2) at _sbus_bus_map+0x84
timerattach_obio(0xf05f1f00, 0xf05fbe80, 0xf01ba4d8, 0xf0130ecc, 0x0, 0x4) at timerattach_obio+0x1fc
config_attach(0xf05fbe80, 0xf01bb784, 0xf01ba4d8, 0xf01bc400, 0xf013613c, 0x5) at config_attach+0x338
config_found_sm(0xf05f1f00, 0xf01ba4d8, 0xf013613c, 0x0, 0xf01ba4d8, 0x5) at config_found_sm+0x24
sbus_attach_common(0xf05f1f00, 0xf0194cb0, 0xf0194ca0, 0xf0194c74, 0xdeadbeef, 0x5) at sbus_attach_common+0x11c
obioattach(0xf05fbfc0, 0xf05f1f00, 0xf01ba6f8, 0xf012faa4, 0x0, 0x1) at obioattach+0x5c
config_attach(0xf05f1f00, 0xf01bb784, 0xf01ba6f8, 0xf01bc400, 0xf0152af4, 0x8) at config_attach+0x338
config_found_sm(0xf05fbfc0, 0xf01ba6f8, 0xf0152af4, 0x0, 0x0, 0x0) at config_found_sm+0x24
mainbus_attach(0xf01c6c00, 0xf05fbfc0, 0xf01c6c00, 0xf01c6c00, 0xf019bc30, 0x0) at mainbus_attach+0x250
config_attach(0xf05fbfc0, 0xf01bb784, 0x0, 0xf01bc400, 0x0, 0xf0189c70) at config_attach+0x338
config_rootfound(0xf019bbb8, 0x0, 0xf0158748, 0xf01bed74, 0x0, 0xf0187f98) at config_rootfound+0x40
cpu_configure(0xf01e78c4, 0xf01e78b4, 0xf01e7800, 0xffffffff, 0x3c, 0xf01c0000) at cpu_configure+0x30
configure(0xf01f5400, 0xf01f5400, 0xf01f5400, 0xf01f4000, 0x1, 0x10000000) at configure+0x40
main(0xf01e5000, 0xfffffff8, 0xf00021d8, 0xf01baaf3, 0xffffffff, 0x10) at main+0x3b8
startmap_done(0x0, 0x2ffd58, 0x10, 0x0, 0x30f400, 0xffffffff) at startmap_done+0x12c

	"addr=0x0" would seem to indicate that there's a null pointer
	dereference going on, and the PC mentioned in the trap message

data fault: pc=0xf01310f8 addr=0x0 sfsr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW>

	points to this line in timerattach():

		discard = *limreg;
	and limreg is one of the arguments given in the call to
	timerattach() in timerattach_obio():

		timerattach(&counterreg4m->t_counter, &counterreg4m->t_limit);

	counterreg4m in its turn is

		#define counterreg4m cpuinfo.counterreg_4m

	at which point I couldn't find more obvious leads.

	See above.

	Sorry, none supplied.