NetBSD Problem Report #38358
From jarle@festningen.uninett.no Wed Apr 2 17:54:32 2008
Return-Path: <jarle@festningen.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 118FE63B293
for <gnats-bugs@gnats.NetBSD.org>; Wed, 2 Apr 2008 17:54:32 +0000 (UTC)
Message-Id: <20080402175429.35DDE80B63@festningen.uninett.no>
Date: Wed, 2 Apr 2008 19:54:29 +0200 (CEST)
From: jarle@uninett.no
Reply-To: jarle@uninett.no
To: gnats-bugs@gnats.NetBSD.org
Subject: LOCKDEBUG panic when attaching tsp1
X-Send-Pr-Version: 3.95
>Number: 38358
>Category: port-alpha
>Synopsis: LOCKDEBUG panic when attaching tsp1
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: mhitch
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Apr 02 17:55:00 +0000 2008
>Closed-Date: Wed Jan 13 06:23:53 +0000 2010
>Last-Modified: Wed Jan 13 06:23:53 +0000 2010
>Originator: Jarle Greipsland
>Release: -current
>Organization:
>Environment:
System: NetBSD sweetheart.urc.uninett.no 4.99.58 NetBSD 4.99.58 (GENERIC-$Revision: 1.314 $) #1: Sat Mar 29 20:46:15 CET 2008 jarle@sweetheart.urc.uninett.no:/usr/obj/sys/arch/alpha/compile/CS20.MP alpha
Architecture: alpha
Machine: alpha
>Description:
I'm trying to boot a very recent -current kernel on a CS20 dual cpu system,
and the kernel panics during autoconfig:
Boot file: netbsd
Boot flags: a
3717536+499256 [255144+163989]=0x46c418
Entering netbsd at 0xfffffc0000301210...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008
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 4.99.58 (GENERIC-$Revision: 1.314 $) #0: Wed Apr 2 19:20:16 CEST 2008
jarle@sweetheart.urc.uninett.no:/usr/obj/sys/arch/alpha/compile/CS20.MP
API CS20D 833 MHz, s/n
8192 byte page size, 2 processors.
total memory = 1024 MB
(2776 KB reserved for PROM, 1021 MB used by NetBSD)
avail memory = 1001 MB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21264B-3
cpu0: Architecture extensions: 1307<PAT,MVI,CIX,FIX,BWX>
cpu1 at mainbus0: ID 1, 21264B-3
cpu1: Architecture extensions: 1307<PAT,MVI,CIX,FIX,BWX>
tsc0 at mainbus0: 21272 Core Logic Chipset, Cchip rev 0
tsc0: 4 Dchips, 1 memory bus of 32 bytes
tsc0: arrays present: 1024MB, 0MB, 0MB, 0MB, Dchip 0 rev 1
tsp0 at tsc0
pci0 at tsp0 bus 0
esiop0 at pci0 dev 3 function 0: Symbios Logic 53c1010-66 (ultra3-wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at dec 6600 irq 16
scsibus0 at esiop0: 16 targets, 8 luns per target
fxp0 at pci0 dev 4 function 0: i82559 Ethernet, rev 8
fxp0: interrupting at dec 6600 irq 20
fxp0: Ethernet address 00:02:56:00:06:f9
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sio0 at pci0 dev 7 function 0: Acer Labs M1533 PCI-ISA Bridge (rev. 0xc3)
aceride0 at pci0 dev 16 function 0
aceride0: Acer Labs M5229 UDMA IDE Controller (rev. 0xc2)
aceride0: primary channel interrupting at isa irq 14
atabus0 at aceride0 channel 0
aceride0: secondary channel interrupting at isa irq 15
atabus1 at aceride0 channel 1
Acer Labs M7101 Power Management Controller (miscellaneous prehistoric) at pci0 dev 17 function 0 not configured
isa0 at sio0
lpt0 at isa0 port 0x3bc-0x3bf irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
attimer0 at isa0 port 0x40-0x43: AT Timer
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
isabeep0 at pcppi0
mcclock0 at isa0 port 0x70-0x71: mc146818 compatible time-of-day clock
attimer0: attached to pcppi0
tsp1 at tsc0
Mutex error: lockdebug_alloc: already initialized
lock address : 0xfffffc00006ccfe0 type : spin
shared holds : 0 exclusive: 0
shares wanted: 0 exclusive: 0
current cpu : 0 last held: 0
current lwp : 0xfffffc000067e660 last held: 000000000000000000
last locked : 0xfffffc00004d78b8 unlocked : 0xfffffc00004d79fc
initialized : 0xfffffc00004d7bc4
owner field : 000000000000000000 wait/spin: 0/0
panic: LOCKDEBUG
Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x4: ret zero,(ra
)
db{0}> trace
cpu_Debugger() at netbsd:cpu_Debugger+0x4
panic() at netbsd:panic+0x264
lockdebug_abort1() at netbsd:lockdebug_abort1+0x108
lockdebug_alloc() at netbsd:lockdebug_alloc+0x10c
mutex_init() at netbsd:mutex_init+0x5c
extent_create() at netbsd:extent_create+0xe4
tsp_bus_io_init() at netbsd:tsp_bus_io_init+0x278
tsp_init() at netbsd:tsp_init+0x84
tspattach() at netbsd:tspattach+0x4c
config_attach_loc() at netbsd:config_attach_loc+0x208
tscattach() at netbsd:tscattach+0x1f8
config_attach_loc() at netbsd:config_attach_loc+0x208
mbattach() at netbsd:mbattach+0x158
config_attach_loc() at netbsd:config_attach_loc+0x208
cpu_configure() at netbsd:cpu_configure+0x30
configure() at netbsd:configure+0x5c
main() at netbsd:main+0x380
locorestart() at netbsd:locorestart+0x68
--- root of call graph ---
db{0}> show reg
v0 0x6
t0 0x1
t1 0x1
t2 0xfffffc003ff48000
t3 0xfffffc003ff496a6
t4 0
t5 0xfffffc00005f549f dosdirtemplate+0xfaf
t6 0
t7 0
s0 0xfffffc000068c36c msgbufenabled
s1 0x100
s2 0xfffffc000068b098 db_onpanic
s3 0xfffffc00006eb580 ld_prime+0x78
s4 0x1
s5 0xfffffc00006cb0e0 bt_cache+0x60
s6 0xffffffff
a0 0x6
a1 0xfffffd01fc0003f8
a2 0
a3 0x8
a4 0x3
a5 0x8
t8 0xfffffc000020393f
t9 0x8
t10 0x800000000000000
t11 0xfffffe0013232848
ra 0xfffffc00004e2564 panic+0x264
t12 0xfffffc00005b9d60 cpu_Debugger
at 0xdfffffffffffffff
gp 0xfffffc000068b0e0 esiop_led_off+0x4
sp 0xfffffc0000203a58
pc 0xfffffc00005b9d64 cpu_Debugger+0x4
ps 0x6
ai 0xfffffe0013232848
pv 0xfffffc00005b9d60 cpu_Debugger
netbsd:cpu_Debugger+0x4: ret zero,(ra)
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Jarle Greipsland <jarle@uninett.no>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-alpha/38358: LOCKDEBUG panic when attaching tsp1
Date: Fri, 16 May 2008 17:37:15 +0200 (CEST)
[ re-sent to gnats-bugs@netbsd.org in order to have it recorded
for posterity. ]
Hi,
some further input. I added a debug printf (diff below) to the
relevant bus_io_init function in pci_bwx_bus_io_chipdep.c. It
turns out that the first printout from this function occurs right
after the kernel gets control from the boot blocks:
Boot file: netbsd
Boot flags: a
4060656+476168 [258960+166553]=0x4bbea8
Entering netbsd at 0xfffffc0000301210...
chip_io_ex_store(v) = 0xfffffc0000720f30
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008
The NetBSD Foundation, Inc. All rights reserved.
and then the second printout occurs later on:
[ ... ]
tsp1 at tsc0
chip_io_ex_store(v) = 0xfffffc0000720f30
Mutex error: lockdebug_alloc: already initialized
lock address : 0xfffffc0000720f38 type : spin
shared holds : 0 exclusive: 0
shares wanted: 0 exclusive: 0
current cpu : 0 last held: 0
current lwp : 0xfffffc00006d2180 last held: 000000000000000000
last locked : 0xfffffc00005012dc unlocked : 0xfffffc0000501478
initialized : 0xfffffc0000501684
owner field : 000000000000000000 wait/spin: 0/0
panic: LOCKDEBUG
Might this somehow be related to initialization of the console
(which is on a serial port on this system)?
-jarle
Diff:
Index: sys/arch/alpha/pci/pci_bwx_bus_io_chipdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/pci/pci_bwx_bus_io_chipdep.c,v
retrieving revision 1.17
diff -u -r1.17 pci_bwx_bus_io_chipdep.c
--- sys/arch/alpha/pci/pci_bwx_bus_io_chipdep.c 28 Apr 2008 20:23:11 -0000 1.17
+++ sys/arch/alpha/pci/pci_bwx_bus_io_chipdep.c 16 May 2008 14:46:44 -0000
@@ -218,7 +218,7 @@
void *v;
{
struct extent *ex;
-
+ void *p;
/*
* Initialize the bus space tag.
*/
@@ -301,6 +301,8 @@
t->abs_c_4 = __C(CHIP,_io_copy_region_4);
t->abs_c_8 = __C(CHIP,_io_copy_region_8);
+ p = (void *)CHIP_IO_EX_STORE(v);
+ printf("chip_io_ex_store(v) = %p\n", p);
ex = extent_create(__S(__C(CHIP,_bus_io)), 0x0UL, 0xffffffffUL,
M_DEVBUF, (void *)CHIP_IO_EX_STORE(v), CHIP_IO_EX_STORE_SIZE(v),
EX_NOWAIT|EX_NOCOALESCE);
From: Tobias Nygren <tnn@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-alpha/38358
Date: Sat, 31 Jan 2009 13:32:45 +0100
I can reproduce the problem and am looking into a fix.
From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-alpha/38358: LOCKDEBUG panic when attaching tsp1
Date: Thu, 29 Oct 2009 23:33:59 -0600 (MDT)
On Wed, 2 Apr 2008, jarle@uninett.no wrote:
> I'm trying to boot a very recent -current kernel on a CS20 dual cpu system,
> and the kernel panics during autoconfig:
...
> attimer0: attached to pcppi0
> tsp1 at tsc0
> Mutex error: lockdebug_alloc: already initialized
>
> lock address : 0xfffffc00006ccfe0 type : spin
> shared holds : 0 exclusive: 0
> shares wanted: 0 exclusive: 0
> current cpu : 0 last held: 0
> current lwp : 0xfffffc000067e660 last held: 000000000000000000
> last locked : 0xfffffc00004d78b8 unlocked : 0xfffffc00004d79fc
> initialized : 0xfffffc00004d7bc4
> owner field : 000000000000000000 wait/spin: 0/0
>
> panic: LOCKDEBUG
The extent storage for tsp(4) was being allocated statically, and
was being used for both tsp0 and tsp1, which meant that mutex_init()
was getting called twice to initialize the mutex.
I'm testing a fix to allocate the extent storage in the tsp softc
structure so each instance gets its own storage.
--
Michael L. Hitch mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
Responsible-Changed-From-To: port-alpha-maintainer->mhitch
Responsible-Changed-By: mhitch@NetBSD.org
Responsible-Changed-When: Fri, 30 Oct 2009 05:37:13 +0000
Responsible-Changed-Why:
Taking responsibility.
State-Changed-From-To: open->analyzed
State-Changed-By: mhitch@NetBSD.org
State-Changed-When: Fri, 30 Oct 2009 05:37:13 +0000
State-Changed-Why:
Analyzed the problem, and testing a fix.
From: "Michael L. Hitch" <mhitch@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/38358 CVS commit: src/sys/arch/alpha/pci
Date: Fri, 30 Oct 2009 18:55:46 +0000
Module Name: src
Committed By: mhitch
Date: Fri Oct 30 18:55:45 UTC 2009
Modified Files:
src/sys/arch/alpha/pci: tsp_bus_io.c tsp_bus_mem.c tsvar.h
Log Message:
The tsc(4) bus initialization was using a single statically allocated
extent storage for each tsp(4), which caused a LOCKDEBUG kernel to fail
because the extent storage contained a mutex which panics when the second
mutex_init() is attempted. Put the extent storage into the tsp_config
structure so each tsp(4) gets it own. Fixes PR port-alpha/38358.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/alpha/pci/tsp_bus_io.c
cvs rdiff -u -r1.8 -r1.9 src/sys/arch/alpha/pci/tsp_bus_mem.c
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/alpha/pci/tsvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Stephen Borrill <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/38358 CVS commit: [netbsd-5] src/sys/arch/alpha/pci
Date: Sat, 31 Oct 2009 13:35:03 +0000
Module Name: src
Committed By: sborrill
Date: Sat Oct 31 13:35:03 UTC 2009
Modified Files:
src/sys/arch/alpha/pci [netbsd-5]: tsp_bus_io.c tsp_bus_mem.c tsvar.h
Log Message:
Pull up the following revisions(s) (requested by mhitch in ticket #1120):
sys/arch/alpha/pci/tsp_bus_io.c: revision 1.6
sys/arch/alpha/pci/tsp_bus_mem.c: revision 1.9
sys/arch/alpha/pci/tsvar.h: revision 1.7
The tsc(4) bus initialization was using a single statically allocated
extent storage for each tsp(4), which caused a LOCKDEBUG kernel to fail
because the extent storage contained a mutex which panics when the second
mutex_init() is attempted. Put the extent storage into the tsp_config
structure so each tsp(4) gets it own. Fixes PR port-alpha/38358.
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.5.140.1 src/sys/arch/alpha/pci/tsp_bus_io.c
cvs rdiff -u -r1.8 -r1.8.88.1 src/sys/arch/alpha/pci/tsp_bus_mem.c
cvs rdiff -u -r1.5 -r1.5.88.1 src/sys/arch/alpha/pci/tsvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: analyzed->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 12 Jan 2010 06:37:23 +0000
State-Changed-Why:
Is this fully fixed?
From: Jarle Greipsland <jarle@uninett.no>
To: gnats-bugs@NetBSD.org, dholland@NetBSD.org
Cc: mhitch@NetBSD.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 19:16:23 +0100 (CET)
dholland@NetBSD.org writes:
> Synopsis: LOCKDEBUG panic when attaching tsp1
>
> State-Changed-From-To: analyzed->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Tue, 12 Jan 2010 06:37:23 +0000
> State-Changed-Why:
> Is this fully fixed?
Hard to say. I can no longer boot a -current GENERIC.MP kernel:
Entering netbsd.new at 0xfffffc0000431220...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
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.23 (GENERIC-$Revision: 1.330 $) #0: Tue Jan 12 18:50:39 CET 2010
jarle@sweetheart.urc.uninett.no:/usr/obj/sys/arch/alpha/compile/GENERIC.MP
API CS20D 833 MHz, s/n
8192 byte page size, 2 processors.
total memory = 1024 MB
(2776 KB reserved for PROM, 1021 MB used by NetBSD)
avail memory = 996 MB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21264B-3
cpu0: Architecture extensions: 0x1307<PAT,MVI,CIX,FIX,BWX>
cpu1 at mainbus0: ID 1, 21264B-3
cpu1: Architecture extensions: 0x1307<PAT,MVI,CIX,FIX,BWX>
tsc0 at mainbus0: 21272 Core Logic Chipset, Cchip rev 0
tsc0: 4 Dchips, 1 memory bus of 32 bytes
tsc0: arrays present: 1024MB, 0MB, 0MB, 0MB, Dchip 0 rev 1
tsp0 at tsc0
pci0 at tsp0 bus 0
esiop0 at pci0 dev 3 function 0: Symbios Logic 53c1010-66 (ultra3-wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at dec 6600 irq 16
scsibus0 at esiop0: 16 targets, 8 luns per target
fxp0 at pci0 dev 4 function 0: i82559 Ethernet, rev 8
fxp0: interrupting at dec 6600 irq 20
fxp0: Ethernet address 00:02:56:00:06:f9
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Acer Labs M1533 PCI-ISA Bridge (ISA bridge, revision 0xc3) at pci0 dev 7 function 0 not configured
aceride0 at pci0 dev 16 function 0: Acer Labs M5229 UDMA IDE Controller (rev. 0xc2)
aceride0: primary channel interrupting at isa irq 14
atabus0 at aceride0 channel 0
aceride0: secondary channel interrupting at isa irq 15
atabus1 at aceride0 channel 1
Acer Labs M7101 Power Management Controller (miscellaneous prehistoric) at pci0 dev 17 function 0 not configured
tsp1 at tsc0
pci1 at tsp1 bus 0
fxp1 at pci1 dev 3 function 0: i82559 Ethernet, rev 8
fxp1: interrupting at dec 6600 irq 32
fxp1: Ethernet address 00:02:56:00:06:fa
inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 4
inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
panic: cpu_initclocks: no clock attached
Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x4: ret zero,(ra
)
db{0}>
Suggestions?
-jarle
From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: Jarle Greipsland <jarle@uninett.no>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 11:45:15 -0700 (MST)
On Tue, 12 Jan 2010, Jarle Greipsland wrote:
> Hard to say. I can no longer boot a -current GENERIC.MP kernel:
...
> fxp0 at pci0 dev 4 function 0: i82559 Ethernet, rev 8
> fxp0: interrupting at dec 6600 irq 20
> fxp0: Ethernet address 00:02:56:00:06:f9
> inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> Acer Labs M1533 PCI-ISA Bridge (ISA bridge, revision 0xc3) at pci0 dev 7 function 0 not configured
^^^
This is the problem; none of the ISA devices get configured, which
includes the clock (and serial ports).
It should show:
sio0 at pci0 dev 7 function 0: vendor 0x10b9 product 0x1533 (rev. 0xc3)
> Suggestions?
Something changed so the PCI-ISA bridge isn't recognized. I don't see
anything obvious yet. The last changes in sys/arch/alpha/pci/sio.c look
OK.
I was able to boot a -current kernel as of last November.
--
Michael L. Hitch mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
From: Jarle Greipsland <jarle@uninett.no>
To: gnats-bugs@NetBSD.org, mhitch@lightning.msu.montana.edu
Cc: mhitch@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 20:46:14 +0100 (CET)
"Michael L. Hitch" <mhitch@lightning.msu.montana.edu> writes:
> > Acer Labs M1533 PCI-ISA Bridge (ISA bridge, revision 0xc3) at pci0 dev 7 function 0 not configured
> ^^^
> This is the problem; none of the ISA devices get configured, which
> includes the clock (and serial ports).
>
> It should show:
> sio0 at pci0 dev 7 function 0: vendor 0x10b9 product 0x1533 (rev. 0xc3)
>
> > Suggestions?
>
> Something changed so the PCI-ISA bridge isn't recognized. I don't see
> anything obvious yet. The last changes in sys/arch/alpha/pci/sio.c look
> OK.
Maybe the changes in -r1.1003 - -r1.1004 of src/sys/dev/pci/pcidevs
are to blame?
-jarle
From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: Jarle Greipsland <jarle@uninett.no>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 13:15:39 -0700 (MST)
On Tue, 12 Jan 2010, Jarle Greipsland wrote:
>> Something changed so the PCI-ISA bridge isn't recognized. I don't see
>> anything obvious yet. The last changes in sys/arch/alpha/pci/sio.c look
>> OK.
> Maybe the changes in -r1.1003 - -r1.1004 of src/sys/dev/pci/pcidevs
> are to blame?
That would be it. The current sio.c is matching against
PCI_PRODUCT_ALI_M1543, although the product code is really 0x1533 which
used to match, but no longer does.
--
Michael L. Hitch mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: Jarle Greipsland <jarle@uninett.no>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 13:27:29 -0700 (MST)
On Tue, 12 Jan 2010, Jarle Greipsland wrote:
>> Something changed so the PCI-ISA bridge isn't recognized. I don't see
>> anything obvious yet. The last changes in sys/arch/alpha/pci/sio.c look
>> OK.
> Maybe the changes in -r1.1003 - -r1.1004 of src/sys/dev/pci/pcidevs
> are to blame?
sys/arch/alpha/pci/sio.c has been corrected to use the correct product
symbol, and should fix that problem.
--
Michael L. Hitch mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
From: Jarle Greipsland <jarle@uninett.no>
To: mhitch@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-alpha/38358 (LOCKDEBUG panic when attaching tsp1)
Date: Tue, 12 Jan 2010 21:38:41 +0100 (CET)
"Michael L. Hitch" <mhitch@lightning.msu.montana.edu> writes:
> >> Something changed so the PCI-ISA bridge isn't recognized. I don't see
> >> anything obvious yet. The last changes in sys/arch/alpha/pci/sio.c look
> >> OK.
> > Maybe the changes in -r1.1003 - -r1.1004 of src/sys/dev/pci/pcidevs
> > are to blame?
>
> sys/arch/alpha/pci/sio.c has been corrected to use the correct product
> symbol, and should fix that problem.
Excellent. Meanwhile, in my local src tree I partially reverted
the changes in version 1.1004 of pcidevs and built a new
LOCKDEBUG.MP kernel, i.e. GENERIC.MP with the LOCKDEBUG option.
The result kernel boots fine. So the (original) "attaching tsp1"
problem is certainly gone.
-jarle
--
"Avoiding precedents does not mean nothing should ever be done.
It only means that nothing should ever be done for the first time."
-- Sir Humphrey Appleby K.C.B.
State-Changed-From-To: feedback->closed
State-Changed-By: mhitch@NetBSD.org
State-Changed-When: Wed, 13 Jan 2010 06:23:53 +0000
State-Changed-Why:
Feedback received, verifying the problem has been fixed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home