Re: port-alpha/38335 (kernel freeze on alpha MP system)

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

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

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: Jarle Greipsland <jarle%uninett.no@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: port-alpha/38335 (kernel freeze on alpha MP system)
Date: Tue, 6 Oct 2009 11:28:59 -0600 (MDT)

 On Tue, 6 Oct 2009, Jarle Greipsland wrote:
 
 > Another data point: It crashed again; still with the same panic
 > from your patch, which I forgot to comment out when I updated my
 > sources.  So, even with the IPL_VM->IPL_SCHED change in, it still
 > reaches the "Whoa!  pool_cache_get returned an in-use entry!"
 > printf statement.  I have no idea whether that's significant or
 > not.
 >
 > I'll comment out the "Oops"-panic now, and see what happens
 > then.
 
    That's interesting - I've been running a number of -j4 builds on an
 ES40 with only 2 cpus enabled (to more closely simulate the CS20), and 
 haven't been able to hit that message, or some checks I've got in the
 pool_cache code.
 
    What I was trying to do was to see if just changing the mutex 
 initialization to IPL_SCHED was enough, or if it needed to be IPL_HIGH.
 I was also trying IPL_SCHED and IPL_HIGH in the pool_cache_bootstrap()
 just prior to the mutex_init.
 
 --
 Michael L. Hitch                       mhitch%montana.edu@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA