Re: Please test EARLY_AP_STARTUP

On Sunday, November 27, 2016 12:46:31 PM O. Hartmann wrote:
> Am Fri, 25 Nov 2016 10:20:36 -0800
> John Baldwin <jhb_at_freebsd.org> schrieb:
> 
> > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD.  Some folks
> > have been testing it for the last week or so which has exposed some 
> > additional things to fix.  I think I've resolved most of those in one
> > way or another, but it will make things smoother if other folks can
> > start testing this over the next few days before it is enabled by default.
> > 
> > (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.)
> > 
> > Note that non-x86 platforms should eventually adopt this, but I don't
> > think any of them are ready yet.
> > 
> 
> I tried. I use three boxes, all running most recent CURRENT. Only one box does work and
> boot with the option mentioned above in the kernel. The other two don't, they stop at
> printing something about HPET timer initialisation and stop - forever.
> 
> I did not digg deeper into it, but there is something strange:
> 
> Both failing boxes have CPUs with two cores, four threads. One is a notebook with an
> Haswell 4200M, the other is a i3-3220.
> 
> The i3-3220 box has a motherboard ASROCK Z77-Pro4 (UEFI on this crap is not working), 8
> GB RAM (2x 4GB), lates firmware from 2013. 
> 
> The working box has an ASROCK Z77-Pro4 M (mini ATX size mobo), 16 GB RAM (2x 8GB), but a
> 4 core/8 thread XEON IvyBridge E3-1245 V2. The firmare is the latest, from 2013. The box
> is running well with the option EARLY_AP_STARTUP set. 
> 
> At a first glance it looks like the failure is dependend on the CPU count ;-) I have also
> a small PCengine APU 2C4, AMD Jaguar CPU with 4 core/4 threads which is about to be tested
> also with the most recent CURRENT and the option in question set - but it takes time.
> 
> Just for the record, my apologizes if someone feels disturbed from naive observations.

Some things to help debug:

- See if you can break into the debugger via Ctrl-Alt-Esc.  If so, please grab
  the output of 'ps' and 'tr 0' from DDB.
- Boot with SMP disabled (kern.smp.disabled=1).  This isn't a permament
  solution but can help narrow down the issue.
- Compile a kernel with KTR, KTR_COMPILE=KTR_PROC, KTR_VERBOSE, and
  KTR_MASK=KTR_PROC (all are options) and boot.  Hopefully it stops printing
  lines when it hangs rather than spinning forever.  If so, grab a screen
  shot (or console serial log) when it hangs.

-- 
John Baldwin