WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] NPTL/TLS problem in -unstable ?

On Mon, 10 Jan 2005, Christian Limpach wrote:

I've given it another try (since my previous test was with a non-default
kernel config file) but it still works for me (boot with /lib/tls in place).
When it hangs, is Xen still alive, i.e. does pressing ctrl-a 3 times
switch to Xen's console?  Can you give some more information, like what
CPU you're using and can you find out what the last version was which
worked?  Does 2.0-testing work?

I cannot get to the Xen console, but alt-sysrq-p does
work.

It looks like most of the time the call trace is:

force_evtchn_callback+0xa/0xc
force_sig_info+0x19a/0x1a0
do_page_fault+0x4f6/0x597
[varying stack leftovers]
evtchn_do_upcall+0x7e/0xc0
page_fault+0x3b/0x40

Hmmm, looks like a segmentation fault.  Possibly the same
segfault that was hitting the first program run after
switching on NPTL by moving /lib/tls back on an already
running system.

After pressing alt+sysrq+p a few hundred times, I got lucky:

(typed in by hand)
Pid: 1, comm:                 init
EIP: 0061:[<c0109f00>] CPU: 0
EIP is at page_fault+0x0/0x40
 EFLAGS: 00001286    Not tainted  (2.6.10-1.175_FC4xen0)
EAX: c02f8558 EBX: c02f8989 ECX: ffffffe0 EDX: 00000002
ESI: 00000000 EDI: 00000006 EBP: bffffe84 DS: 007b ES: 007b

Now, from arch/xen/i386/kernel/entry.S:

# This handler is special, because it gets an extra value on its stack,
# which is the linear faulting address.
# fastcall register usage:  %eax = pt_regs, %edx = error code,
#                           %ecx = fault address
ENTRY(page_fault)
        pushl %ds
...

If so, are we faulting on ffffffe0 ?   I know the vsyscall
page shouldn't be compatible with Xen (or execshield), so
why is init trying to fault there ?

Why isn't do_page_fault bailing out and trying to kill the
process ?

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel