From: vincent-perrier <vin...@cl...> - 2008-05-20 22:34:26
|
Hello, Can somebody remind me where the last skas4 patch is, I would like to give it a try and it seems not so easy to find. Regards Vincent Perrier |
From: Flavio <fbc...@gm...> - 2008-05-21 08:21:53
|
2008/5/21 vincent-perrier <vin...@cl...>: > > Hello, > Can somebody remind me where the last skas4 patch is, I would > like to give it a try and it seems not so easy to find. > Regards > Vincent Perrier Hello Vincent, the last skas4 patch has been sent to this mailing list from Jeff Dike, as well as for the previous one. Flavio > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user |
From: vincent-perrier <vin...@cl...> - 2008-05-21 17:41:15
|
Thank-you for the info. On Wed, 2008-05-21 at 10:21 +0200, Flavio wrote: > 2008/5/21 vincent-perrier <vin...@cl...>: > > > > Hello, > > Can somebody remind me where the last skas4 patch is, I would > > like to give it a try and it seems not so easy to find. > > Regards > > Vincent Perrier > Hello Vincent, > > the last skas4 patch has been sent to this mailing list from Jeff > Dike, as well as for the previous one. > > Flavio > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > User-mode-linux-user mailing list > > Use...@li... > > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > � > |
From: Flavio <fbc...@gm...> - 2008-05-21 17:40:26
|
2008/5/21 vincent-perrier <vin...@cl...>: > Thank-you for the info. You are welcome, Flavio > > On Wed, 2008-05-21 at 10:21 +0200, Flavio wrote: >> 2008/5/21 vincent-perrier <vin...@cl...>: >> > >> > Hello, >> > Can somebody remind me where the last skas4 patch is, I would >> > like to give it a try and it seems not so easy to find. >> > Regards >> > Vincent Perrier >> Hello Vincent, >> >> the last skas4 patch has been sent to this mailing list from Jeff >> Dike, as well as for the previous one. >> >> Flavio >> >> > >> > >> > ------------------------------------------------------------------------- >> > This SF.net email is sponsored by: Microsoft >> > Defy all challenges. Microsoft(R) Visual Studio 2008. >> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> > _______________________________________________ >> > User-mode-linux-user mailing list >> > Use...@li... >> > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user >> � >> > > |
From: Jeff D. <jd...@ad...> - 2008-05-21 20:08:31
|
On Wed, May 21, 2008 at 10:21:51AM +0200, Flavio wrote: > 2008/5/21 vincent-perrier <vin...@cl...>: > > > > Hello, > > Can somebody remind me where the last skas4 patch is, I would > > like to give it a try and it seems not so easy to find. > > Regards > > Vincent Perrier > Hello Vincent, > > the last skas4 patch has been sent to this mailing list from Jeff > Dike, as well as for the previous one. FWIW, the full patch can be had from http://marc.info/?l=user-mode-linux-devel&m=121088437926424&q=raw and the broken-out patches are currently listed at http://marc.info/?l=user-mode-linux-devel&r=1&b=200805&w=2 Jeff -- Work email - jdike at linux dot intel dot com |
From: vincent-perrier <vin...@cl...> - 2008-05-24 09:52:13
|
Here is the trace, and after is the print that led to the trace: Locating the top of the address space ... 0xffffd000 Core dump limits : soft - 1024000000 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /root/tmp/...OK Checking for SKAS4 support in the host: /proc/self/mm ... OK new_mm ... OK switching over ... switched back ... OK PTRACE_SWITCH_MM ... OK Full CPU fault information in siginfo_t ... OK Full CPU fault information in PTRACE_GETSIGINFO ... OK vcpu ... Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) clownix: vcpu returned with signal 19, 0, 0 8497 0 8497 0 136958120 8 136958120 -153633628 8 8 8 8497 0 8 8497 0Failed Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO... [1]+ Stopped ./linux if (vcpu_data.event == VCPU_SIGNAL) { non_fatal("clownix: vcpu returned with signal\n" "%d, %d, %d \n" "%d %d %d \n" "%d %d %d \n" "%d %d %d \n" "%d %d %d \n" "%d %d %d \n%d", vcpu_data.siginfo.si_signo, vcpu_data.siginfo.si_errno, vcpu_data.siginfo.si_code, vcpu_data.siginfo._sifields._kill._pid, vcpu_data.siginfo._sifields._kill._uid, vcpu_data.siginfo._sifields._timer._tid, vcpu_data.siginfo._sifields._timer._overrun, vcpu_data.siginfo._sifields._timer._sys_private, vcpu_data.siginfo._sifields._sigchld._status, vcpu_data.siginfo._sifields._sigchld._utime, vcpu_data.siginfo._sifields._sigchld._stime, vcpu_data.siginfo._sifields._rt._sigval, vcpu_data.siginfo._sifields._rt._sigval.sival_int, vcpu_data.siginfo._sifields._rt._sigval.sival_ptr, vcpu_data.siginfo._sifields._sigfault._addr, vcpu_data.siginfo._sifields._sigfault._trapno, vcpu_data.siginfo._sifields._sigfault._error, vcpu_data.siginfo._sifields._sigpoll._band, vcpu_data.siginfo._sifields._sigpoll._fd); On Fri, 2008-05-23 at 14:56 -0400, Jeff Dike wrote: > On Fri, May 23, 2008 at 06:37:58PM +0200, vincent-perrier wrote: > > Here is strace (attached file) > > This time, it actually sorta worked... > > > write(1, "\tvcpu ... ", 10 vcpu ... ) = 10 > > msgsnd(4294967295, {4, ptrace: umoven: Input/output error > > 0x4}, 136966304, 0) = -1 ENOSYS (Function not implemented) > > write(1, "OK\n", 3OK > > I have no idea why strace thought that was msgsnd - it should have > said SYS_329 or something. The ENOSYS caused by vcpu and ptrace > interacting badly. > > It might be that the behavior difference is caused by a context switch > (to strace and back) before vcpu returns to userspace. I saw this > when I was debugging it. > > Can you get the full contents of the siginfo that vcpu is returning? > > Jeff > |
From: Jeff D. <jd...@ad...> - 2008-05-28 15:37:35
|
Is this a 32-bit UML on a 64-bit host? On Sat, May 24, 2008 at 11:52:08AM +0200, vincent-perrier wrote: > Locating the top of the address space ... 0xffffd000 This suggests that it is... > Detected host type: i386 > (GDT indexes 6 to 9) This suggests that it isn't... As for the siginfo stuff - > 8497 0 > vcpu_data.siginfo._sifields._kill._pid, > vcpu_data.siginfo._sifields._kill._uid, Makes some sort of sense as a pid and a uid. Can you see if this is pid that makes sense? Jeff -- Work email - jdike at linux dot intel dot com |
From: vincent p. <vin...@cl...> - 2008-05-28 16:24:48
Attachments:
config-2.6.22.15.tex1
|
Hello, I just crashed and restored my machine, so I can do the test again only tomorrow or later. I am 32 bits, but a quad cpu may be special: Linux localhost 2.6.22.15.tex1 #1 SMP Sat Dec 15 13:15:05 CST 2007 i686 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/Linux Config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.15.tex1 # Sat Dec 15 12:04:05 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y ... see attached file for the rest. On Wed, 2008-05-28 at 11:37 -0400, Jeff Dike wrote: > Is this a 32-bit UML on a 64-bit host? > > On Sat, May 24, 2008 at 11:52:08AM +0200, vincent-perrier wrote: > > Locating the top of the address space ... 0xffffd000 > > This suggests that it is... > > > Detected host type: i386 > > (GDT indexes 6 to 9) > > This suggests that it isn't... > > As for the siginfo stuff - > > > 8497 0 > > > vcpu_data.siginfo._sifields._kill._pid, > > vcpu_data.siginfo._sifields._kill._uid, > > Makes some sort of sense as a pid and a uid. Can you see if this is > pid that makes sense? > > Jeff > |
From: vincent-perrier <vin...@cl...> - 2008-05-21 21:52:26
|
Hello, The skas4 patch was OK for kernel 2.6.25.4, I rebuilt my host in my usual way (I take the distrib's config from /boot and do not modify this config). My host started ok: Linux localhost 2.6.25.4 #1 SMP Wed May 21 23:31:19 CEST 2008 i686 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/Linux I built my guest as usual, with my usual config options, I took my old root_fs, (with the modules from the un-skas-patched linux 2.6.25.4). Here is the startup trace: bulk$ ./linux root_fs Locating the top of the address space ... 0xc0000000 Core dump limits : soft - 1024000000 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /root/tmp/...OK Checking for SKAS4 support in the host: /proc/self/mm ... OK new_mm ... OK switching over ... switched back ... OK PTRACE_SWITCH_MM ... OK Full CPU fault information in siginfo_t ... OK Full CPU fault information in PTRACE_GETSIGINFO ... OK vcpu ... Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) vcpu returned with event = 1 Failed Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO... [1]+ Stopped ./linux root_fs bulk$ Regards Vincent Perrier On Wed, 2008-05-21 at 16:08 -0400, Jeff Dike wrote: > On Wed, May 21, 2008 at 10:21:51AM +0200, Flavio wrote: > > 2008/5/21 vincent-perrier <vin...@cl...>: > > > > > > Hello, > > > Can somebody remind me where the last skas4 patch is, I would > > > like to give it a try and it seems not so easy to find. > > > Regards > > > Vincent Perrier > > Hello Vincent, > > > > the last skas4 patch has been sent to this mailing list from Jeff > > Dike, as well as for the previous one. > > FWIW, the full patch can be had from > http://marc.info/?l=user-mode-linux-devel&m=121088437926424&q=raw > and the broken-out patches are currently listed at > http://marc.info/?l=user-mode-linux-devel&r=1&b=200805&w=2 > > Jeff > |
From: Jeff D. <jd...@ad...> - 2008-05-22 16:22:47
|
On Wed, May 21, 2008 at 11:52:16PM +0200, vincent-perrier wrote: > vcpu returned with event = 1 > Failed > Checking for the skas3 patch in the host: > - /proc/mm...not found: No such file or directory > - PTRACE_FAULTINFO... > [1]+ Stopped ./linux root_fs > bulk$ That's different. Can you try the patch (to UML) below to see if provides any useful information? Jeff -- Work email - jdike at linux dot intel dot com Index: linux-2.6-skas4/arch/um/os-Linux/start_up.c =================================================================== --- linux-2.6-skas4.orig/arch/um/os-Linux/start_up.c 2008-05-22 12:21:28.000000000 -0400 +++ linux-2.6-skas4/arch/um/os-Linux/start_up.c 2008-05-22 12:21:54.000000000 -0400 @@ -864,6 +864,12 @@ static __init int check_vcpu(void) goto bad; } + if (vcpu_data.event == VCPU_SIGNALL) { + non_fatal("vcpu returned with signal %d\n", + vcpu_data.siginfo.si_signo); + goto bad; + } + if (vcpu_data.event != VCPU_SYSCALL) { non_fatal("vcpu returned with event = %d\n", vcpu_data.event); goto bad; |
From: vincent-perrier <vin...@cl...> - 2008-05-22 17:40:21
|
I put the patch by hand and replaced VCPU_SIGNALL with VCPU_SIGNAL: if (vcpu_data.event == VCPU_SIGNAL) { non_fatal("clownix: vcpu returned with signal %d\n", vcpu_data.siginfo.si_signo); goto bad; } if (vcpu_data.event != VCPU_SYSCALL) { Here is the result: bulk$ ./linux root_fs Locating the top of the address space ... 0xc0000000 Core dump limits : soft - 1024000000 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking for tmpfs mount on /dev/shm...OK Checking PROT_EXEC mmap in /root/tmp/...OK Checking for SKAS4 support in the host: /proc/self/mm ... OK new_mm ... OK switching over ... switched back ... OK PTRACE_SWITCH_MM ... OK Full CPU fault information in siginfo_t ... OK Full CPU fault information in PTRACE_GETSIGINFO ... OK vcpu ... Host TLS support detected Detected host type: i386 (GDT indexes 6 to 9) clownix: vcpu returned with signal 19 Failed Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO... [1]+ Stopped ./linux root_fs On Thu, 2008-05-22 at 12:22 -0400, Jeff Dike wrote: > On Wed, May 21, 2008 at 11:52:16PM +0200, vincent-perrier wrote: > > vcpu returned with event = 1 > > Failed > > Checking for the skas3 patch in the host: > > - /proc/mm...not found: No such file or directory > > - PTRACE_FAULTINFO... > > [1]+ Stopped ./linux root_fs > > bulk$ > > That's different. Can you try the patch (to UML) below to see if > provides any useful information? > > Jeff > |
From: Jeff D. <jd...@ad...> - 2008-05-22 19:26:05
|
On Thu, May 22, 2008 at 07:40:09PM +0200, vincent-perrier wrote: > Detected host type: i386 > (GDT indexes 6 to 9) > clownix: vcpu returned with signal 19 Odd, you're getting SIGSTOPs for some reason, which is consistent with this bit later: > - PTRACE_FAULTINFO... > [1]+ Stopped ./linux root_fs Can you look at the si_errno and si_code fields of the siginfo? They may say where the signal is coming from... Jeff -- Work email - jdike at linux dot intel dot com |
From: vincent-perrier <vin...@cl...> - 2008-05-22 19:55:13
|
As I said, si_errno and si_code are 0, but the uml does not diseapear properly, see the ps following, I have to use kill -9 to clean them. clownix: vcpu returned with signal 19, 0, 0 Failed Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO... [1]+ Stopped ./linux root_fs bulk$ bulk$ bulk$ bulk$ bulk$ ps -ef |grep linux root 10526 6236 0 21:51 pts/2 00:00:00 ./linux root_fs root 10532 10526 0 21:51 pts/2 00:00:00 [linux] <defunct> root 10533 10526 0 21:51 pts/2 00:00:00 ./linux root_fs root 10535 6236 0 21:51 pts/2 00:00:00 grep linux On Thu, 2008-05-22 at 15:25 -0400, Jeff Dike wrote: > On Thu, May 22, 2008 at 07:40:09PM +0200, vincent-perrier wrote: > > Detected host type: i386 > > (GDT indexes 6 to 9) > > clownix: vcpu returned with signal 19 > > Odd, you're getting SIGSTOPs for some reason, which is consistent with > this bit later: > > > - PTRACE_FAULTINFO... > > [1]+ Stopped ./linux root_fs > > Can you look at the si_errno and si_code fields of the siginfo? They > may say where the signal is coming from... > > Jeff > |
From: vincent-perrier <vin...@cl...> - 2008-05-22 20:09:14
|
I tried gdb, here is what I got: bulk$ gdb ./linux GNU gdb 6.3-9pclos2007 (PCLinuxOS release 2007) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandriva-linux-gnu"...Using host libthread_db library "/lib/i686/libthread_db.so.1". (gdb) run Starting program: /home/perrier/result/bulk/linux Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 Locating the top of the address space ... Program received signal SIGSEGV, Segmentation fault. 0x0806a1cd in page_ok (page=0) at arch/um/os-Linux/sys-i386/task_size.c:31 31 n = *address; On Thu, 2008-05-22 at 15:25 -0400, Jeff Dike wrote: > On Thu, May 22, 2008 at 07:40:09PM +0200, vincent-perrier wrote: > > Detected host type: i386 > > (GDT indexes 6 to 9) > > clownix: vcpu returned with signal 19 > > Odd, you're getting SIGSTOPs for some reason, which is consistent with > this bit later: > > > - PTRACE_FAULTINFO... > > [1]+ Stopped ./linux root_fs > > Can you look at the si_errno and si_code fields of the siginfo? They > may say where the signal is coming from... > > Jeff > |
From: Jeff D. <jd...@ad...> - 2008-05-23 14:50:09
|
On Thu, May 22, 2008 at 09:49:32PM +0200, vincent-perrier wrote: > si_errno and si_code are both zeros, I am sad to say. That doesn't necessarily mean there's no information. zero might mean the signal came from a process. Can you strace it? Also, send me the full siginfo? There might be something in .si_pid and .si_user. As for your gdb problem: > Locating the top of the address space ... > Program received signal SIGSEGV, Segmentation fault. > 0x0806a1cd in page_ok (page=0) at > arch/um/os-Linux/sys-i386/task_size.c:31 UML is causing segfaults on purpose, which gdb doesn't really expect. Do (gdb) handle SIGSEGV pass nostop noprint to tell gdb to ignore them. Jeff -- Work email - jdike at linux dot intel dot com |
From: vincent-perrier <vin...@cl...> - 2008-05-23 16:38:19
Attachments:
skas4_tst
|
Here is strace (attached file) On Fri, 2008-05-23 at 10:49 -0400, Jeff Dike wrote: > On Thu, May 22, 2008 at 09:49:32PM +0200, vincent-perrier wrote: > > si_errno and si_code are both zeros, I am sad to say. > > That doesn't necessarily mean there's no information. zero might mean > the signal came from a process. > > Can you strace it? > > Also, send me the full siginfo? There might be something in .si_pid > and .si_user. > > As for your gdb problem: > > Locating the top of the address space ... > > Program received signal SIGSEGV, Segmentation fault. > > 0x0806a1cd in page_ok (page=0) at > > arch/um/os-Linux/sys-i386/task_size.c:31 > > UML is causing segfaults on purpose, which gdb doesn't really expect. > > Do > (gdb) handle SIGSEGV pass nostop noprint > to tell gdb to ignore them. > > Jeff > |
From: Jeff D. <jd...@ad...> - 2008-05-23 18:57:06
|
On Fri, May 23, 2008 at 06:37:58PM +0200, vincent-perrier wrote: > Here is strace (attached file) This time, it actually sorta worked... > write(1, "\tvcpu ... ", 10 vcpu ... ) = 10 > msgsnd(4294967295, {4, ptrace: umoven: Input/output error > 0x4}, 136966304, 0) = -1 ENOSYS (Function not implemented) > write(1, "OK\n", 3OK I have no idea why strace thought that was msgsnd - it should have said SYS_329 or something. The ENOSYS caused by vcpu and ptrace interacting badly. It might be that the behavior difference is caused by a context switch (to strace and back) before vcpu returns to userspace. I saw this when I was debugging it. Can you get the full contents of the siginfo that vcpu is returning? Jeff -- Work email - jdike at linux dot intel dot com |