Re: port-macppc/54331: macppc MP kernels fail to boot successfully in -current (8.99.49)

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

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

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost, mrg%eterna.com.au@localhost
Cc: 
Subject: Re: port-macppc/54331: macppc MP kernels fail to boot successfully
 in -current (8.99.49)
Date: Mon, 12 Aug 2019 22:24:53 -0400

 On Sun, 2019-08-11 at 23:10 +0000, matthew green wrote:
 > The following reply was made to PR port-macppc/54331; it has been noted by GNATS.
 > 
 > From: matthew green <mrg%eterna.com.au@localhost>
 > To: "David H. Gutteridge" <david%gutteridge.ca@localhost>
 > Cc: gnats-bugs%netbsd.org@localhost
 > Subject: re: port-macppc/54331: macppc MP kernels fail to boot successfully in -current (8.99.49)
 > Date: Mon, 12 Aug 2019 09:07:32 +1000
 > 
 >  > Your patch fixed the remaining issue booting an MP+DEBUG+DIAGNOSTIC+
 >  > LOCKDEBUG kernel built from the netbsd-8 branch. Thanks!
 >  
 >  great news.  i sent a pullup request.  i had actually fixed one
 >  of the two chunks back in march, but both are commited now.
 >  
 >  > With this plus macallan@'s earlier patch applied, I don't see any
 >  > remaining issues for netbsd-8, so we've narrowed this PR to what's in
 >  > HEAD/netbsd-9 now.
 >  
 >  i will get the above additional fix into netbsd-9.
 >  
 >  can you update us with the status of -current/-9?  the system
 >  hangs after probing USB still?
 >  
 >  if so and if you can drop to DDB, can you inspect the
 >  "config_pending" variable?  eg, "x/x config_pending".  if it
 >  is zero, that means that some device configuration has called
 >  config_incr() without a matching config_decr(), which makes the
 >  code that allows mountroot and then init to run to wait.  this
 >  is normally for eg, boot device probe, but it tends to indicate
 >  that there is a lack of interupts, allowing a device probe to
 >  complete, but really, anything that stops the driver from
 >  getting to its config_decr() moment will do this.
 
 I built an MP+DEBUG+DIAGNOSTIC+LOCKDEBUG 9.99.7 kernel with the patches
 included, and it's hanging after USB devices are attached. I can unplug
 and reattach USB devices and it continues to handle those events fine,
 but it never actually mounts (or prompts to mount) the hard drive. I
 don't see anything useful in the output to indicate why. I'm not able
 to get into ddb as far as I know. That is, typing something on the USB
 keyboard that's attached doesn't result in anything happening.
 
 Dave