Re: init receiving SIGILL on XEN3_DOM0/amd64

[Andrew Doran <ad%netbsd.org@localhost>]

On Tue, May 27, 2008 at 01:31:21PM +0200, Christoph Egger wrote:

> On Monday 26 May 2008 22:57:06 Christoph Egger wrote:
> > Manuel Bouyer wrote:
> > > On Sun, May 18, 2008 at 02:32:37PM +0200, Manuel Bouyer wrote:
> > >> On Sun, May 18, 2008 at 01:43:04PM +0200, Christoph Egger wrote:
> > >>>> When the CPU sends an illegal intruction trap, I guess.
> > >>>
> > >>> In that case, I have a wild guess:
> > >>> sysenter is an illegal opcode on amd64. The difference is, AMD CPUs
> > >>> throw an exception, Intel CPUs don't.
> > >>> Is sysenter used somewhere?
> > >>
> > >> I don't think it should be for amd64 binaries.
> > >> i386 binaries may, but only if I686_LIBC is defined. Othewrise int $0x80
> > >> is used.
> > >
> > > OK, I've been seeing this occasionally now on an Intel CPU. A dom0 kernel
> > > will fail to start init in this way once in a while. But hitting ^A^A^AR
> > > on the serial console cause the system to reboot, and the next boot is
> > > usually successfull without changing anything in kernel or boot options.
> > >
> > > The intermittent aspect makes it hard to debug, and also confuses me a
> > > bit about what the cause could be.
> >
> > I see this, too on AMD CPU. I tracked this down to when start_init()
> > returns to lwp_trampoline which in turn returns to Xosyscall.
> > Xosyscall wants to send SIG 4 to pid 1 (no idea why)
> > and calls trap for this.
> > In trap a page fault happens which in turn leads into an
> > endless loop of traps into ddb.
> 
> start_init() returns to lwp_trampoline which in turn jmp into Xosyscall.
> 
> Xosyscall notices an AST is pending and calls trap. trap sends SIG 4
> to pid 1 (init).
> 
> Hope, that helps someone understanding the code better than I do
> to fix this.

Does this patch have any impact?

        http://www.netbsd.org/~ad/vm_machdep.c.diff

Andrew