That was quick; I only managed to find out that it hangs with a kernel from 29th...
Chavdar On 5 November 2013 12:20, Thomas Klausner <w...@netbsd.org> wrote: > On Tue, Nov 05, 2013 at 10:22:29AM +0000, Chavdar Ivanov wrote: >> I'll try some bisection. > > My bisection so far points to a change on the 23rd. > > I couldn't reproduce the problem (yet?) with a kernel from 'cvs up -D > 20131023', but I had a hang with one from 'cvs up -D 20131024'. > > The changes from the 23rd are: > > 7766 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/usb > just a config change > > 7767 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci > gffb, which I don't use > > 7768 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/macppc/conf > kernel config only > > 7769 L Oct 23 To source-chang (0.3K) CVS commit: src/doc > docs > > 7770 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/dev/pci > gffb copyright change > > 7771 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/amd64/conf > + xhci (which I've removed in my kernel) > > 7772 L Oct 23 To source-chang (0.4K) CVS commit: src/sys/arch/i386/conf > same > > 7773 L Oct 23 To source-chang (0.6K) CVS commit: src > use MODULE_CLASS_MISC for Lua modules > which looks harmless enough and doesn't really touch the kernel > > 7774 L Oct 23 To source-chang (3.1K) CVS commit: src/sys > > Use the MI "pcu" framework for bookkeeping of npx/fpu states on x86. > This reduces the amount of MD code enormously, and makes it easier > to implement support for newer CPU features which require more fpu > state, or for fpu usage by the kernel. > For access to FPU state across CPUs, an xcall kthread is used now > rather than a dedicated IPI. > No user visible changes intended. > > 7775 L Oct 23 To source-chang (0.5K) CVS commit: src/sys/arch/arm/arm > different architecture > > So currently it looks to me like the problem might come from the MI > pcu framework commit. Matthias, does that sound possible? Could you > please check the patch again if it might introduce these symptoms? > (see thread for details) > Thomas > >> Chavdar >> >> On 5 November 2013 10:07, David Brownlee <a...@netbsd.org> wrote: >> > On 5 November 2013 08:27, Chavdar Ivanov <ci4...@gmail.com> wrote: >> >> Tried - the screen stays as it was, no movement whatsoever. No network >> >> activity, the keyboard is also dead - does not respond to CtrlAltEsc, >> >> even the lights are off and CapsLock/NumLock does not trigger >> >> anything. >> > >> > I've noticed a recent netbsd-6 xen DOM0 hanging on similar big >> > compiles (firefox24/25) if run while the DOMUs are active. Possibly >> > unrelated, but just as a data point. >> >> >> >> -- >> ---- >> -- ----
