Re: port-amd64/40067: HP BL680c is unable to boot NetBSD with SMP enabled

["Chris Gilbert" <chris%dokein.co.uk@localhost>]

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

From: "Chris Gilbert" <chris%dokein.co.uk@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: ad%netbsd.org@localhost
Subject: Re: port-amd64/40067: HP BL680c is unable to boot NetBSD with SMP  
         enabled
Date: Mon, 1 Dec 2008 18:08:49 -0000 (GMT)

 On Mon, December 1, 2008 5:27 pm, Chris Gilbert wrote:
 > On Mon, December 1, 2008 10:20 am, Andrew Doran wrote:
 >
 >>  This is also the point at which at which the gates are opened for
 >> non-boot
 >>  CPUs. Up until this point they sit in a loop spinning.
 >>
 >>  http://nxr.homeunix.org/source/xref/sys/arch/x86/x86/cpu.c#689
 >>
 >>  Can you break into the debugger and get a backtrace to see where it i=
 s
 >>  hanging?
 >
 > I tried with the iLO keyboard, but it didn't work because it's a USB
 > interface.
 >
 > With the serial port I think it's also not dropping into ddb.  The Seri=
 al
 > port is accessible via the iLO, using either a Java app or ssh.  Break
 > isn't working for either method.
 >
 > I might try booting without SMP, and see if I can drop to ddb normally =
 (IE
 > can I actually reach ddb, or is the system not allowing ddb access...)
 
 I figured out the key stroke, it's:
 ctrl-alt-B (from Putty)
 
 Sadly a bt isn't helpful as it reveals little due to a lack of symbols on
 the boot CDs.
 
 However ps/l shows a list of lwps:
 db{0}> ps /l
  PID         LID S     FLAGS       STRUCT LWP *               NAME WAIT
 >0           154 2       204   ffff8000d1037be0       isp1:fc_thrd
              153 2       204   ffff8000d1032020       isp0:fc_thrd
              152 2       204   ffff8000d1032400           scsibus0
              151 2       204   ffff8000d10327e0               pms0
              150 2       204   ffff8000d1032bc0           xcall/23
              149 1       204   ffff8000d1031000         softser/23
              148 1       204   ffff8000d10313e0         softclk/23
              147 1       204   ffff8000d10317c0         softbio/23
              146 1       204   ffff8000d1031ba0         softnet/23
              145 1       205   ffff8000d102f040            idle/23
 
 [snip 22 identical per cpu threads for xcall, softser, clk, bio, net and
 idle]
 
               12 2       204   ffff8000bf80f420             sysmon
               11 2       204   ffff8000bf80f800           pmfevent
               10 2       204   ffff8000bf80fbe0            cachegc
                9 2       204   ffff8000bf80c020              vrele
                8 2       204   ffff8000bf80c400          modunload
                7 2       204   ffff8000bf80c7e0            xcall/0
            >   6 7       204   ffff8000bf80cbc0          softser/0
                5 1       204   ffff8000bf80a000          softclk/0
                4 1       204   ffff8000bf80a3e0          softbio/0
                3 1       204   ffff8000bf80a7c0          softnet/0
                2 1       205   ffff8000bf80aba0             idle/0
                1 7       204   ffffffff80bb4880            swapper
 
 digging a bit further shows:
 db{0}> show event
 evcnt type 0: bus_dma loads =3D 189
 evcnt type 0: bus_dma nbouncebufs =3D 11323
 evcnt type 1: ioapic0 pin 4 =3D 58
 db{0}> show all callout
 hardclock_ticks now: 0
     ticks  wheel               arg  func
      3000 -1/-256 ffff8000d10449d0  ?
       300 -1/-256 ffff8000d112f048  ?
 
 My guess is that hardclock_ticks should be increasing, but it's static at
 0, which suggests that the clock interrupt isn't occurring or routed
 correctly.
 
 Thanks,
 Chris