Re: port-alpha/38358: LOCKDEBUG panic when attaching tsp1

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

The following reply was made to PR port-alpha/38358; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
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@localhost 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@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA