Linux emulation instability

[Divacky Roman]

On Wed, Mar 07, 2007 at 08:48:51AM +0100, Alexander Leidinger wrote:
> Quoting Doug Barton <dougb at FreeBSD.org> (from Tue, 06 Mar 2007  
> 15:10:40 -0800):
> 
> >Alexander Leidinger wrote:
> >>Quoting Doug Barton <dougb at FreeBSD.org> (from Mon, 05 Mar 2007   
> >>16:05:29 -0800):
> >>
> >>>compat.linux.osrelease: 2.4.2
> >>>
> >>>Based on your description, and the fact that you're running with
> >>>ULE+libthr but with UP, I'd be pretty comfortable saying an SMP problem
> >>>is "likely" at this point. If someone wants to come up with some
> >>>patches that will likely help the futex+SMP problem, I'll be glad to
> >>>test them. Otherwise further testing on my part will have to wait till
> >>>I get some more spare cycles.
> >>
> >>I would be surprised if 2.6.x features like futexes are used with   
> >>2.4.2. We don't disable futexes with 2.4.2, but some 2.6.x features  
> >> are disabled and the glibc of linux_base-fc4 doesn't switch to   
> >>using 2.6.x features when osrelease is set to 2.4.2. Additionally   
> >>futexes are not fully implemented on amd64 (at least not in HEAD).
> >>
> >>Also you should not focus on libthr, as it is not used for linux stuff.
> >
> >Thanks for clearing that up. Would switching to a different linux_base
> >port, and/or setting compat.linux.osrelease to something else be a
> 
> There are two possibilities for osrelease in our kernel. The default  
> and some 2.6.x value. In the Linux glibc as used in our default  
> linux_base port there may be other possibilites. Depending on  
> osrelease the glibc makes use of different syscalls.
 
as I was corrected by netbsd guys this might be PER PROCESS and doesnt
depend directly on setting of osversion... if you set $LD_ASSUME_VERSION
to 2.6 it will use NPTL for a given process even if you dont have osversion=2.6
 
> I don't know if using a different linux_base port would give us an  
> useful hint what is going on. At least it would narrow it down to  
> glibc (or some other lib).

panics happen in kernel. no matter what evil glibc might do we CANNOT panic

> >useful exercise? This is thunderbird 2.0b2, so it may be expecting 2.6
> >stuff that we're not giving it, which may be why it's crashing.
> 
> You should see a panic string, as Roman has some KASSERTs for this  
> case. I'm not sure if this covers everything. Roman?

I guess....

> >>It would be interesting to know where linux-thunderbird locks up.   
> >>With a ktrace and maybe the output of linuxulator debugging   
> >>messages we may be able to narrow this down to the real problem.
> >
> >Ok, ktrace I can handle, what kind of debugging needs to be set for the
> >linuxulator?
> 
> You can't use the FreeBSD kdump, you have to use linux_kdump. A  
> package is available at http://www.Leidinger.net/FreeBSD/ for i386  
> (you need a different linux_base port than the default to compile it).
> 
> Set compat.linux.debug=all, you have to compile (the module) with  
> -DDEBUG to get it.

I am most interestd in the panic backtrace... doug, can you please try
to run the thunderbird remotely over X? ie. we see the panic. without
it it can be basically anything :(