* [uml-devel] 2.4.22-[67] problems @ 2003-12-20 1:13 Matt Zimmerman 2003-12-20 17:14 ` Jeff Dike 2003-12-20 19:05 ` Nick Craig-Wood 0 siblings, 2 replies; 43+ messages in thread From: Matt Zimmerman @ 2003-12-20 1:13 UTC (permalink / raw) To: user-mode-linux-devel; +Cc: 224431, 224502 There definitely seems to be something awry here, even in skas mode. I am getting a lot of ENOSYS errors inside UML: /usr/lib/apt/methods/http: error while loading shared libraries: libc.so.6: cannot map zero-fill pages: Error 38 dpkg: error processing /var/cache/apt/archives/debhelper_4.0.2_all.deb (--unpack): failed to rmdir/unlink `/usr/share/man/man1/dh_compress.1.gz.dpkg-tmp': Function not implemented basename: write error: Function not implemented etc. Downgrading to user-mode-linux 2.4.22-6um-1 still has the problem, downgrading further to 2.4.22-5um-1 (the old binary) fixes it. The following things changed from 2.4.22-5um-1 to 2.4.22-6um-1, most of which were outside of UML itself: 1. -6um and later were built with a glibc using 2.6 kernel headers (linux-kernel-headers in Debian unstable). This also required a patch to get UML to compile: @@ -35628,7 +35631,7 @@ + */ +static void disable_lcall(void) +{ -+ struct modify_ldt_ldt_s ldt; ++ struct user_desc ldt; + int err; + + bzero(&ldt, sizeof(ldt)); @@ -36784,7 +36787,7 @@ + nregs = sizeof(dummy->u_debugreg)/sizeof(dummy->u_debugreg[0]); + for(i = 0; i < nregs; i++){ + if((i == 4) || (i == 5)) continue; -+ if(ptrace(PTRACE_POKEUSR, pid, &dummy->u_debugreg[i], ++ if(ptrace(PTRACE_POKEUSER, pid, &dummy->u_debugreg[i], + regs[i]) < 0) + printk("write_debugregs - ptrace failed on " + "register %d, errno = %d\n", errno); @@ -36799,7 +36802,7 @@ + dummy = NULL; + nregs = sizeof(dummy->u_debugreg)/sizeof(dummy->u_debugreg[0]); + for(i = 0; i < nregs; i++){ -+ regs[i] = ptrace(PTRACE_PEEKUSR, pid, ++ regs[i] = ptrace(PTRACE_PEEKUSER, pid, + &dummy->u_debugreg[i], 0); + } +} 2. CONFIG_UML_REAL_TIME_CLOCK=y was added to the configuration 3. Various newer versions of the compiler toolchain were used, with the exception of gcc (the Debian package has been explicitly building using gcc 2.95 for a long time) 4. Update Debian kernel source tree So at this point, I don't know whether something in the development environment has broken UML, or if UML has broken itself somehow. I haven't tried patching 2.4.22-5um to compile with linux-kernel-headers yet, so I don't know whether a new binary of that older code would also work. I don't know whether I'm dealing with one bug or several. There are a lot of factors to try to eliminate, so to help with the investigation, I'd like to know if anyone else s seeing problems similar to http://bugs.debian.org/{224431,224502}, the ENOSYS errors shown above, or anything else strange with 2.4.22-6um or -7um, or after updating any toolchain components. I'd especially like to hear from Debian unstable users, especially anyone building from non-Debian kernel sources. Thanks... -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-20 1:13 [uml-devel] 2.4.22-[67] problems Matt Zimmerman @ 2003-12-20 17:14 ` Jeff Dike 2003-12-21 0:47 ` Matt Zimmerman ` (2 more replies) 2003-12-20 19:05 ` Nick Craig-Wood 1 sibling, 3 replies; 43+ messages in thread From: Jeff Dike @ 2003-12-20 17:14 UTC (permalink / raw) To: user-mode-linux-devel, 224431, 224502 On Fri, Dec 19, 2003 at 05:13:23PM -0800, Matt Zimmerman wrote: > There definitely seems to be something awry here, even in skas mode. I am > getting a lot of ENOSYS errors inside UML: > > /usr/lib/apt/methods/http: error while loading shared libraries: libc.so.6: cannot map zero-fill pages: Error 38 > > dpkg: error processing /var/cache/apt/archives/debhelper_4.0.2_all.deb (--unpack): > failed to rmdir/unlink `/usr/share/man/man1/dh_compress.1.gz.dpkg-tmp': Function not implemented > > basename: write error: Function not implemented > > etc. > > Downgrading to user-mode-linux 2.4.22-6um-1 still has the problem, > downgrading further to 2.4.22-5um-1 (the old binary) fixes it. The > following things changed from 2.4.22-5um-1 to 2.4.22-6um-1, most of which > were outside of UML itself: These changes look OK. I looked through the -5 to -6 diffs and saw nothing that would cause stuff to start returning -ENOSYS. The only thing that seemed remotely relevant is the unistd.h change, which fixes a bug in the case of an error in an internally called system call. You can try reverting that and see what happens. Beyond that, if you can find a system call that reproducably fails, then just step through it, and see where the -ENOSYS comes from. This shouldn't be too difficult. Jeff ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-20 17:14 ` Jeff Dike @ 2003-12-21 0:47 ` Matt Zimmerman 2003-12-21 15:58 ` BlaisorBlade 2003-12-21 0:52 ` Matt Zimmerman 2003-12-21 1:29 ` [uml-devel] 2.4.22-[67] problems Matt Zimmerman 2 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 0:47 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 224431, 224502 On Sat, Dec 20, 2003 at 12:14:50PM -0500, Jeff Dike wrote: > On Fri, Dec 19, 2003 at 05:13:23PM -0800, Matt Zimmerman wrote: > > There definitely seems to be something awry here, even in skas mode. I am > > getting a lot of ENOSYS errors inside UML: > > > > /usr/lib/apt/methods/http: error while loading shared libraries: libc.so.6: cannot map zero-fill pages: Error 38 > > > > dpkg: error processing /var/cache/apt/archives/debhelper_4.0.2_all.deb (--unpack): > > failed to rmdir/unlink `/usr/share/man/man1/dh_compress.1.gz.dpkg-tmp': Function not implemented > > > > basename: write error: Function not implemented > > > > etc. > > > > Downgrading to user-mode-linux 2.4.22-6um-1 still has the problem, > > downgrading further to 2.4.22-5um-1 (the old binary) fixes it. The > > following things changed from 2.4.22-5um-1 to 2.4.22-6um-1, most of which > > were outside of UML itself: > > These changes look OK. I looked through the -5 to -6 diffs and saw nothing > that would cause stuff to start returning -ENOSYS. The only thing that > seemed remotely relevant is the unistd.h change, which fixes a bug in the > case of an error in an internally called system call. You can try reverting > that and see what happens. > > Beyond that, if you can find a system call that reproducably fails, then > just step through it, and see where the -ENOSYS comes from. This shouldn't > be too difficult. Thanks for looking at it. It's sounding more and more like the new glibc/linux-kernel-headers packages have broken UML. Maybe something is getting the host's kernel headers when it needs the ones from the UML build tree? -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 0:47 ` Matt Zimmerman @ 2003-12-21 15:58 ` BlaisorBlade 2003-12-21 22:40 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: BlaisorBlade @ 2003-12-21 15:58 UTC (permalink / raw) To: user-mode-linux-devel Alle 01:47, domenica 21 dicembre 2003, Matt Zimmerman ha scritto: > Thanks for looking at it. It's sounding more and more like the new > glibc/linux-kernel-headers packages have broken UML. > Maybe something is > getting the host's kernel headers when it needs the ones from the UML build > tree? Something is getting the host's headers and it must get them, not the ones from UML build tree. Every UML arch file with its name ending in _user.c(+ quite a lot of other ones, listed in USER_OBJS in Makefiles) are built against the host headers, since they are the code interacting with the host. But you need to actually compile UML against 2.4 host headers to see if this is the reason; debugging it can be worst than an unnoticed wrong pointer or buffer overrun, since probably a macro went in silently and it changed the semantics of sources... -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 15:58 ` BlaisorBlade @ 2003-12-21 22:40 ` Matt Zimmerman 2003-12-21 23:16 ` Matt Zimmerman 2003-12-24 12:48 ` BlaisorBlade 0 siblings, 2 replies; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 22:40 UTC (permalink / raw) To: user-mode-linux-devel; +Cc: 224431, 224502 On Sun, Dec 21, 2003 at 04:58:44PM +0100, BlaisorBlade wrote: > Alle 01:47, domenica 21 dicembre 2003, Matt Zimmerman ha scritto: > > Thanks for looking at it. It's sounding more and more like the new > > glibc/linux-kernel-headers packages have broken UML. > > Maybe something is > > getting the host's kernel headers when it needs the ones from the UML build > > tree? > Something is getting the host's headers and it must get them, not the ones > from UML build tree. > > Every UML arch file with its name ending in _user.c(+ quite a lot of other > ones, listed in USER_OBJS in Makefiles) are built against the host headers, > since they are the code interacting with the host. Yes, I understand that. Was my sentence unclear? I was suggesting that it was possible that the host's kernel headers were being used in a situation where the UML tree kernel headers _should_ be used. > But you need to actually compile UML against 2.4 host headers to see if this > is the reason; debugging it can be worst than an unnoticed wrong pointer or > buffer overrun, since probably a macro went in silently and it changed the > semantics of sources... ...which is one thing that I have tested. I substituted 2.4.22 kernel headers for the 2.6 ones provided by linux-kernel-headers and rebuilt UML, and the problem persists. I have heard reports that building the same source on Debian woody (glibc 2.2.5-11.5 with 2.4 kernel headers) works, however. I am going to be testing this myself shortly. If it works, the cause is most likely somewhere in glibc. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 22:40 ` Matt Zimmerman @ 2003-12-21 23:16 ` Matt Zimmerman 2003-12-22 0:25 ` Jeff Dike 2003-12-24 12:48 ` BlaisorBlade 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 23:16 UTC (permalink / raw) To: user-mode-linux-devel, 224431, 224502; +Cc: debian-glibc On Sun, Dec 21, 2003 at 02:40:01PM -0800, Matt Zimmerman wrote: > I have heard reports that building the same source on Debian woody (glibc > 2.2.5-11.5 with 2.4 kernel headers) works, however. I am going to be > testing this myself shortly. If it works, the cause is most likely > somewhere in glibc. I have just verified this myself. Building user-mode-linux 2.4.22-7um-1 on woody works fine (even when running on unstable), but building it on unstable does not. The one built on unstable randomly sees ENOSYS from certain system calls, such as select, read and mmap. I would appreciate any suggestions for how to track this problem down further. I suspect that changes in glibc/linux-kernel-headers have broken things. I tried replacing the headers in linux-kernel-headers (asm, asm-generic and linux) with the ones from Linux 2.4.22, but this did not help. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 23:16 ` Matt Zimmerman @ 2003-12-22 0:25 ` Jeff Dike 2003-12-22 4:08 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Jeff Dike @ 2003-12-22 0:25 UTC (permalink / raw) To: Matt Zimmerman; +Cc: user-mode-linux-devel, 224431, 224502, debian-glibc mdz@debian.org said: > I have just verified this myself. Building user-mode-linux > 2.4.22-7um-1 on woody works fine (even when running on unstable), but > building it on unstable does not. Conversely, does a unstable-built UML run on woody? > The one built on unstable randomly sees ENOSYS from certain system > calls, such as select, read and mmap. Only those, or are there others that you can tell are failing? Offhand, I don't see any commonality between those three, in terms of their interactions with the host. > I would appreciate any suggestions for how to track this problem down > further. The randomness is strange. It suggests that somehow interrupts are getting in the way. One possibility would be host system calls returning ENOSYS instead of EINTR. I don't see much possibility that that's what's actually happening, but that's the sort of thing I'd think about. Jeff ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-22 0:25 ` Jeff Dike @ 2003-12-22 4:08 ` Matt Zimmerman 2003-12-22 5:49 ` Daniel Jacobowitz 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-22 4:08 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 224431, 224502, debian-glibc On Sun, Dec 21, 2003 at 07:25:47PM -0500, Jeff Dike wrote: > mdz@debian.org said: > > I have just verified this myself. Building user-mode-linux > > 2.4.22-7um-1 on woody works fine (even when running on unstable), but > > building it on unstable does not. > > Conversely, does a unstable-built UML run on woody? The unstable-built UML is broken on woody as well. So far, my most reproducible test case so far (not 100%, but close) is to start up a netcat listener, and connect to it with input from /dev/zero, i.e. just push a bunch of data over a TCP connection. What happens is this: rootstrap:~# nc -v -l -p 1234 >/dev/null </dev/null & [2] 138 rootstrap:~# listening on [any] 1234 ... rootstrap:~# nc -v -v localhost 1234 </dev/zero connect to [127.0.0.1] from localhost [127.0.0.1] 1028 localhost [127.0.0.1] 1234 (?) open select fuxored : Function not implemented too many output retries : Broken pipe sent 27820032, rcvd 0 [2]+ Exit 1 nc -v -l -p 1234 >/dev/null </dev/null The relevant netcat source code isn't doing anything unusual: rr = select (16, ding2, 0, 0, timer2); /* here it is, kiddies */ if (rr < 0) { if (errno != EINTR) { /* might have gotten ^Zed, etc ?*/ holler ("select fuxored"); close (fd); return (1); } } /* select fuckup */ so select is returning ENOSYS, but, as can be seen from the transfer statistics, it succeeds many times before it fails. Some other times, a program will simply hang (sometimes even stalling the boot process), or segfault. > > The one built on unstable randomly sees ENOSYS from certain system > > calls, such as select, read and mmap. > > Only those, or are there others that you can tell are failing? Offhand, I > don't see any commonality between those three, in terms of their interactions > with the host. Those are the ones that I have been able to easily identify. select came from the netcat test you see above. mmap was evident from the APT HTTP method: /usr/lib/apt/methods/http: error while loading shared libraries: libc.so.6: cannot map zero-fill pages: Error 38 (that error is from dl-load.c in glibc, and as far as I can tell indicates that mmap gave ENOSYS). basename from coreutils seemed to see write(2) failing: basename: write error: Function not implemented I also saw unlink do it, in dpkg: dpkg: error processing /var/cache/apt/archives/debhelper_4.0.2_all.deb (--unpack): failed to rmdir/unlink `/usr/share/man/man1/dh_compress.1.gz.dpkg-tmp': Function not implemented apt occasionally blows up read()ing from a socket as well: (none):~# apt-get update Get:1 http://debian woody/main Packages [1774kB] Err http://debian woody/main Packages Error reading from server - read (38 Function not implemented) Get:2 http://debian woody/main Release [95B] Fetched 95B in 0s (259B/s) Failed to fetch http://debian/dists/woody/main/binary-i386/Packages Error reading from server - read (38 Function not implemented) Reading Package Lists... Done Building Dependency Tree... Done E: Some index files failed to download, they have been ignored, or old ones used instead. > > I would appreciate any suggestions for how to track this problem down > > further. > > The randomness is strange. It suggests that somehow interrupts are getting > in the way. One possibility would be host system calls returning ENOSYS > instead of EINTR. I don't see much possibility that that's what's actually > happening, but that's the sort of thing I'd think about. Can you think of any way that userland changes could produce that kind of effect? I don't think I would know where to look. My kernel didn't change, and the problem seems to occur on different host kernels. I tried running UML under strace; this produces an impressive amount of output, but made it much more difficult to reproduce the bug. I finally got it to happen under strace, and I have a 226M logfile (7M gzipped) from the session, if you're interested in taking a look. I've put it up at http://people.debian.org/~mdz/temp/uml.strace.gz. I don't see any host system calls returning ENOSYS; the only failures are some very innocuous-looking EINTRs and a few EAGAINs that looks like they're associated with a terminal device. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-22 4:08 ` Matt Zimmerman @ 2003-12-22 5:49 ` Daniel Jacobowitz 2003-12-22 9:08 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Daniel Jacobowitz @ 2003-12-22 5:49 UTC (permalink / raw) To: Jeff Dike, user-mode-linux-devel, 224431, 224502, debian-glibc On Sun, Dec 21, 2003 at 08:08:57PM -0800, Matt Zimmerman wrote: > On Sun, Dec 21, 2003 at 07:25:47PM -0500, Jeff Dike wrote: > > > mdz@debian.org said: > > > I have just verified this myself. Building user-mode-linux > > > 2.4.22-7um-1 on woody works fine (even when running on unstable), but > > > building it on unstable does not. > > > > Conversely, does a unstable-built UML run on woody? > > The unstable-built UML is broken on woody as well. So far, my most > reproducible test case so far (not 100%, but close) is to start up a netcat > listener, and connect to it with input from /dev/zero, i.e. just push a > bunch of data over a TCP connection. What happens is this: ... Matt, could you try with different compilers? This sounds a lot more to me like a compiler bug than a libc one (but that's just a hunch). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-22 5:49 ` Daniel Jacobowitz @ 2003-12-22 9:08 ` Matt Zimmerman 2004-01-05 17:51 ` Adam Heath 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-22 9:08 UTC (permalink / raw) To: Jeff Dike, user-mode-linux-devel, 224431, 224502, debian-glibc On Mon, Dec 22, 2003 at 12:49:14AM -0500, Daniel Jacobowitz wrote: > On Sun, Dec 21, 2003 at 08:08:57PM -0800, Matt Zimmerman wrote: > > On Sun, Dec 21, 2003 at 07:25:47PM -0500, Jeff Dike wrote: > > > > > mdz@debian.org said: > > > > I have just verified this myself. Building user-mode-linux > > > > 2.4.22-7um-1 on woody works fine (even when running on unstable), but > > > > building it on unstable does not. > > > > > > Conversely, does a unstable-built UML run on woody? > > > > The unstable-built UML is broken on woody as well. So far, my most > > reproducible test case so far (not 100%, but close) is to start up a netcat > > listener, and connect to it with input from /dev/zero, i.e. just push a > > bunch of data over a TCP connection. What happens is this: > > Matt, could you try with different compilers? This sounds a lot more > to me like a compiler bug than a libc one (but that's just a hunch). user-mode-linux builds with gcc-2.95 explicitly, which I don't think has had substantial changes this year. I should note that UML is statically linked as well. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-22 9:08 ` Matt Zimmerman @ 2004-01-05 17:51 ` Adam Heath 2004-01-05 18:10 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Adam Heath @ 2004-01-05 17:51 UTC (permalink / raw) To: Matt Zimmerman Cc: Jeff Dike, user-mode-linux-devel, 224431, 224502, debian-glibc On Mon, 22 Dec 2003, Matt Zimmerman wrote: > user-mode-linux builds with gcc-2.95 explicitly, which I don't think has had > substantial changes this year. > > I should note that UML is statically linked as well. try a dynamic skas-only build(on unstable), running on unstable, then woody. If this works, then it's probably a bug in libc itself. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2004-01-05 17:51 ` Adam Heath @ 2004-01-05 18:10 ` Matt Zimmerman 0 siblings, 0 replies; 43+ messages in thread From: Matt Zimmerman @ 2004-01-05 18:10 UTC (permalink / raw) To: Adam Heath; +Cc: user-mode-linux-devel, 224431, 224502, debian-glibc On Mon, Jan 05, 2004 at 11:51:24AM -0600, Adam Heath wrote: > On Mon, 22 Dec 2003, Matt Zimmerman wrote: > > > user-mode-linux builds with gcc-2.95 explicitly, which I don't think has had > > substantial changes this year. > > > > I should note that UML is statically linked as well. > > try a dynamic skas-only build(on unstable), running on unstable, then woody. > > If this works, then it's probably a bug in libc itself. Building with gcc-3.3 fixed the problem. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 22:40 ` Matt Zimmerman 2003-12-21 23:16 ` Matt Zimmerman @ 2003-12-24 12:48 ` BlaisorBlade 1 sibling, 0 replies; 43+ messages in thread From: BlaisorBlade @ 2003-12-24 12:48 UTC (permalink / raw) To: user-mode-linux-devel Alle 23:40, domenica 21 dicembre 2003, Matt Zimmerman ha scritto: > > > Thanks for looking at it. It's sounding more and more like the new > > > glibc/linux-kernel-headers packages have broken UML. > > > Maybe something is > > > getting the host's kernel headers when it needs the ones from the UML > > > build tree? > > > > Something is getting the host's headers and it must get them, not the > > ones from UML build tree. > > > > Every UML arch file with its name ending in _user.c(+ quite a lot of > > other ones, listed in USER_OBJS in Makefiles) are built against the host > > headers, since they are the code interacting with the host. > > Yes, I understand that. Was my sentence unclear? No, just I don't think that situation can happen. Maybe the problem is just that glibc is built against 2.6(i.e. you should try not only replacing headers, but also rebuilding glibc after that). Maybe this could be related with new things from glibc and 2.6, i.e. vsyscall or NPTL(I am just shooting in the middle, I don't even have ideas of what vsyscall is). I've tried even if any of the header-generator programs use some changed headers, but for I saw is that every definition stayed the same (except #define PTRACE_OLDSETOPTIONS 21 which had same number but was named PTRACE_SETOPTIONS in 2.4). > I was suggesting that > it was possible that the host's kernel headers were being used in a > situation where the UML tree kernel headers _should_ be used. I understood this; only I think this doesn't happen... -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-20 17:14 ` Jeff Dike 2003-12-21 0:47 ` Matt Zimmerman @ 2003-12-21 0:52 ` Matt Zimmerman 2003-12-21 1:06 ` Matt Zimmerman 2003-12-21 1:29 ` [uml-devel] 2.4.22-[67] problems Matt Zimmerman 2 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 0:52 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 224431, 224502 On Sat, Dec 20, 2003 at 12:14:50PM -0500, Jeff Dike wrote: > Beyond that, if you can find a system call that reproducably fails, then > just step through it, and see where the -ENOSYS comes from. This shouldn't > be too difficult. Unfortunately, I can't seem to find a system call that reproducibly fails. There's something weird and racy going on. With exactly the same UML invocation, twice in a row, the first will panic: Kernel panic: Segfault with no mm In idle task - not syncing and the second will boot successfully. Even within an invocation, things aren't normal: sh-2.05a# apt-get source -b hello apt-get: error while loading shared libraries: /lib/libm.so.6: cannot read file data: Error 38 sh-2.05a# sh-2.05a# apt-get source -b hello Reading Package Lists... Done Building Dependency Tree... Done And of course, I haven't been able to get this to happen in the debugger (yet). -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 0:52 ` Matt Zimmerman @ 2003-12-21 1:06 ` Matt Zimmerman 2003-12-28 9:33 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 1:06 UTC (permalink / raw) To: Jeff Dike, user-mode-linux-devel, 224431, 224502 On Sat, Dec 20, 2003 at 04:52:57PM -0800, Matt Zimmerman wrote: > sh-2.05a# apt-get source -b hello > apt-get: error while loading shared libraries: /lib/libm.so.6: cannot read > file data: Error 38 > sh-2.05a# > sh-2.05a# apt-get source -b hello > Reading Package Lists... Done > Building Dependency Tree... Done > > And of course, I haven't been able to get this to happen in the debugger > (yet). Well, with enough attempts, I'm able to get it to happen in gdb. However, I can't get it down to a single syscall, and can't do it reliably. I tried setting a breakpoint at the point in syscall_kern.c where it can return -ENOSYS, but it never hits it. It doesn't help that apparently when I send SIGINT to try to get back to gdb, it kills UML. This might be a gdb 6.0 problem. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-21 1:06 ` Matt Zimmerman @ 2003-12-28 9:33 ` Matt Zimmerman 2003-12-28 9:51 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-28 9:33 UTC (permalink / raw) To: user-mode-linux-devel; +Cc: 224431 On Sat, Dec 20, 2003 at 05:06:56PM -0800, Matt Zimmerman wrote: > On Sat, Dec 20, 2003 at 04:52:57PM -0800, Matt Zimmerman wrote: > > > sh-2.05a# apt-get source -b hello > > apt-get: error while loading shared libraries: /lib/libm.so.6: cannot read > > file data: Error 38 > > sh-2.05a# > > sh-2.05a# apt-get source -b hello > > Reading Package Lists... Done > > Building Dependency Tree... Done > > > > And of course, I haven't been able to get this to happen in the debugger > > (yet). > > Well, with enough attempts, I'm able to get it to happen in gdb. However, I > can't get it down to a single syscall, and can't do it reliably. I tried > setting a breakpoint at the point in syscall_kern.c where it can return > -ENOSYS, but it never hits it. It looks like in the case where it breaks, the system call number is 0, so it is passing the test in execute_syscall_skas, and instead invoking sys_ni_syscall. Here is the regs struct in one instance: $16 = {regs = {tt = {syscall = 2, sc = 0xbfffd68c}, skas = {regs = {2, 3221214860, 14, 14, 3221214860, 3221214492, 4294967258, 43, 43, 0, 0, 4, 1074631684, 35, 2097815, 3221214444, 43}, fp = { 0 <repeats 27 times>}, xfp = {2098047, 0 <repeats 31 times>, 4294967295, 2734743551, 16401, 0, 0, 3413842944, 16404, 0 <repeats 88 times>, 2726428672}, fault_addr = 0, fault_type = 1, trap_type = 0, syscall = 0, is_user = 1}}} The process isn't invoking syscall 0 (in this case it was actually __NR_select (82)). syscall matches ORIG_EAX, though, so I guess something is going wrong earlier, maybe in move_registers? -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-28 9:33 ` Matt Zimmerman @ 2003-12-28 9:51 ` Matt Zimmerman 2003-12-28 9:52 ` Matt Zimmerman 2003-12-28 10:12 ` Matt Zimmerman 0 siblings, 2 replies; 43+ messages in thread From: Matt Zimmerman @ 2003-12-28 9:51 UTC (permalink / raw) To: user-mode-linux-devel, 224431 On Sun, Dec 28, 2003 at 01:33:17AM -0800, Matt Zimmerman wrote: > On Sat, Dec 20, 2003 at 05:06:56PM -0800, Matt Zimmerman wrote: > > > On Sat, Dec 20, 2003 at 04:52:57PM -0800, Matt Zimmerman wrote: > > > > > sh-2.05a# apt-get source -b hello > > > apt-get: error while loading shared libraries: /lib/libm.so.6: cannot read > > > file data: Error 38 > > > sh-2.05a# > > > sh-2.05a# apt-get source -b hello > > > Reading Package Lists... Done > > > Building Dependency Tree... Done > > > > > > And of course, I haven't been able to get this to happen in the debugger > > > (yet). > > > > Well, with enough attempts, I'm able to get it to happen in gdb. However, I > > can't get it down to a single syscall, and can't do it reliably. I tried > > setting a breakpoint at the point in syscall_kern.c where it can return > > -ENOSYS, but it never hits it. > > It looks like in the case where it breaks, the system call number is 0, so > it is passing the test in execute_syscall_skas, and instead invoking > sys_ni_syscall. Here is the regs struct in one instance: > > $16 = {regs = {tt = {syscall = 2, sc = 0xbfffd68c}, skas = {regs = {2, > 3221214860, 14, 14, 3221214860, 3221214492, 4294967258, 43, 43, 0, 0, > 4, 1074631684, 35, 2097815, 3221214444, 43}, fp = { > 0 <repeats 27 times>}, xfp = {2098047, 0 <repeats 31 times>, > 4294967295, 2734743551, 16401, 0, 0, 3413842944, 16404, > 0 <repeats 88 times>, 2726428672}, fault_addr = 0, fault_type = 1, > trap_type = 0, syscall = 0, is_user = 1}}} > > The process isn't invoking syscall 0 (in this case it was actually __NR_select > (82)). syscall matches ORIG_EAX, though, so I guess something is going wrong > earlier, maybe in move_registers? This is making less and less sense. handle_trap has this code: syscall_nr = PT_SYSCALL_NR(regs->skas.regs); UPT_SYSCALL_NR(regs) = syscall_nr; if(syscall_nr < 1){ relay_signal(SIGTRAP, regs); return; } As I understand it, PT_SYSCALL_NR refers to ORIG_EAX, and UPT_SYSCALL_NR refers to skas.syscall. i.e., syscall=0 can't happen. So either things are not as they seem, or something is happening to regs between here and execute_syscall_skas. Maybe there is some disconnect between uml_pt_regs and pt_regs? I can't think how, though. the structs are identical in asm/ptrace.h. In fact, the only differences are these: --- ptrace.h-2.4 2003-12-28 01:44:17.000000000 -0800 +++ ptrace.h-2.6 2003-12-28 01:44:20.000000000 -0800 @@ -49,15 +49,14 @@ #define PTRACE_GETFPXREGS 18 #define PTRACE_SETFPXREGS 19 -#define PTRACE_SETOPTIONS 21 +#define PTRACE_OLDSETOPTIONS 21 -/* options set using PTRACE_SETOPTIONS */ -#define PTRACE_O_TRACESYSGOOD 0x00000001 +#define PTRACE_GET_THREAD_AREA 25 +#define PTRACE_SET_THREAD_AREA 26 #ifdef __KERNEL__ #define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs)) #define instruction_pointer(regs) ((regs)->eip) -extern void show_regs(struct pt_regs *); #endif #endif -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-28 9:51 ` Matt Zimmerman @ 2003-12-28 9:52 ` Matt Zimmerman 2004-01-06 2:59 ` Jeff Dike 2003-12-28 10:12 ` Matt Zimmerman 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-28 9:52 UTC (permalink / raw) To: user-mode-linux-devel, 224431 On Sun, Dec 28, 2003 at 01:51:15AM -0800, Matt Zimmerman wrote: > syscall_nr = PT_SYSCALL_NR(regs->skas.regs); > UPT_SYSCALL_NR(regs) = syscall_nr; > if(syscall_nr < 1){ > relay_signal(SIGTRAP, regs); > return; > } By the way, why is the test < 1 here, and < 0 in execute_syscall_skas? Shouldn't they match? -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-28 9:52 ` Matt Zimmerman @ 2004-01-06 2:59 ` Jeff Dike 0 siblings, 0 replies; 43+ messages in thread From: Jeff Dike @ 2004-01-06 2:59 UTC (permalink / raw) To: Matt Zimmerman; +Cc: user-mode-linux-devel, 224431 mdz@debian.org said: > By the way, why is the test < 1 here, and < 0 in execute_syscall_skas? No idea :-) > Shouldn't they match? Yup. Jeff ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-28 9:51 ` Matt Zimmerman 2003-12-28 9:52 ` Matt Zimmerman @ 2003-12-28 10:12 ` Matt Zimmerman 2003-12-28 11:30 ` Matt Zimmerman 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-28 10:12 UTC (permalink / raw) To: user-mode-linux-devel, 224431 On Sun, Dec 28, 2003 at 01:51:15AM -0800, Matt Zimmerman wrote: > This is making less and less sense. handle_trap has this code: > > syscall_nr = PT_SYSCALL_NR(regs->skas.regs); > UPT_SYSCALL_NR(regs) = syscall_nr; > if(syscall_nr < 1){ > relay_signal(SIGTRAP, regs); > return; > } > > As I understand it, PT_SYSCALL_NR refers to ORIG_EAX, and UPT_SYSCALL_NR > refers to skas.syscall. i.e., syscall=0 can't happen. So either things are > not as they seem, or something is happening to regs between here and > execute_syscall_skas. [a few hundred printf's later] So, the sequence of events in handle_trap is this: 1. UPT_SYSCALL_NR(regs) == 78 2. ptrace(PTRACE_POKEUSER,...) 3. UPT_SYSCALL_NR(regs) == 78 (still OK) 4. ptrace(PTRACE_SYSCALL,...) 5. UPT_SYSCALL_NR(regs) == 78 (still OK) 6. waitpid(pid,...) 7. UPT_SYSCALL_NR(regs) == 0 (boom) I have no idea why. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-28 10:12 ` Matt Zimmerman @ 2003-12-28 11:30 ` Matt Zimmerman 2003-12-30 18:43 ` Resolution (Re: [uml-devel] 2.4.22-[67] problems) Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-28 11:30 UTC (permalink / raw) To: user-mode-linux-devel, 224431 On Sun, Dec 28, 2003 at 02:12:40AM -0800, Matt Zimmerman wrote: > So, the sequence of events in handle_trap is this: > > 1. UPT_SYSCALL_NR(regs) == 78 > > 2. ptrace(PTRACE_POKEUSER,...) > > 3. UPT_SYSCALL_NR(regs) == 78 (still OK) > > 4. ptrace(PTRACE_SYSCALL,...) > > 5. UPT_SYSCALL_NR(regs) == 78 (still OK) > > 6. waitpid(pid,...) > > 7. UPT_SYSCALL_NR(regs) == 0 (boom) > > I have no idea why. I added some code to dump the regs struct before and after waitpid, and it turns out that in fact, the syscall element is the only one which is different; the rest of the structure is untouched. Corruption seems unlikely, and the waitpid call certainly shouldn't be touching this...could another thread be clobbering it somehow? -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2003-12-28 11:30 ` Matt Zimmerman @ 2003-12-30 18:43 ` Matt Zimmerman 2004-01-06 2:58 ` Jeff Dike 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2003-12-30 18:43 UTC (permalink / raw) To: user-mode-linux-devel, 224431 On Sun, Dec 28, 2003 at 03:30:42AM -0800, Matt Zimmerman wrote: > On Sun, Dec 28, 2003 at 02:12:40AM -0800, Matt Zimmerman wrote: > > > So, the sequence of events in handle_trap is this: > > > > 1. UPT_SYSCALL_NR(regs) == 78 > > > > 2. ptrace(PTRACE_POKEUSER,...) > > > > 3. UPT_SYSCALL_NR(regs) == 78 (still OK) > > > > 4. ptrace(PTRACE_SYSCALL,...) > > > > 5. UPT_SYSCALL_NR(regs) == 78 (still OK) > > > > 6. waitpid(pid,...) > > > > 7. UPT_SYSCALL_NR(regs) == 0 (boom) > > > > I have no idea why. > > I added some code to dump the regs struct before and after waitpid, and it > turns out that in fact, the syscall element is the only one which is > different; the rest of the structure is untouched. Corruption seems > unlikely, and the waitpid call certainly shouldn't be touching this...could > another thread be clobbering it somehow? It turns out that this problem seems to be due to compiler incompatibility. UML had been built with gcc 2.95 due to old breakage, and when built with gcc 3.3 (as glibc is), everything starts working again. My suspicion is that this is due to certain recent changes in pthreads. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2003-12-30 18:43 ` Resolution (Re: [uml-devel] 2.4.22-[67] problems) Matt Zimmerman @ 2004-01-06 2:58 ` Jeff Dike 2004-01-06 7:41 ` Nuno Silva 2004-01-08 7:07 ` Matt Zimmerman 0 siblings, 2 replies; 43+ messages in thread From: Jeff Dike @ 2004-01-06 2:58 UTC (permalink / raw) To: Matt Zimmerman; +Cc: user-mode-linux-devel, 224431 mdz@debian.org said: > It turns out that this problem seems to be due to compiler > incompatibility. UML had been built with gcc 2.95 due to old breakage, > and when built with gcc 3.3 (as glibc is), everything starts working > again. My suspicion is that this is due to certain recent changes in > pthreads. Is it your opinion that there's no problem in UML itself? Having a field in the sigcontext getting magically munged is somewhat worrying. I'd be happier knowing what exactly was happening so I can be sure this wasn't exposing some subtle UML bug. Jeff ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 2:58 ` Jeff Dike @ 2004-01-06 7:41 ` Nuno Silva 2004-01-06 8:02 ` Matt Zimmerman 2004-01-06 9:20 ` Nuno Silva 2004-01-08 7:07 ` Matt Zimmerman 1 sibling, 2 replies; 43+ messages in thread From: Nuno Silva @ 2004-01-06 7:41 UTC (permalink / raw) To: Jeff Dike; +Cc: Matt Zimmerman, user-mode-linux-devel, 224431 Hi! Jeff Dike wrote: > mdz@debian.org said: > >>It turns out that this problem seems to be due to compiler >>incompatibility. UML had been built with gcc 2.95 due to old breakage, >>and when built with gcc 3.3 (as glibc is), everything starts working >>again. My suspicion is that this is due to certain recent changes in >>pthreads. > > > Is it your opinion that there's no problem in UML itself? Having a field > in the sigcontext getting magically munged is somewhat worrying. I'd be > happier knowing what exactly was happening so I can be sure this wasn't > exposing some subtle UML bug. > I've been doing some tests and I'd say that the problem is something regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and 2.3.3cvs)... But I'm clueless about the fix :-) I'll setup a chroot where I can play around with glibc setups. OARS, why does linux (the UML executable) doesn't run under /lib/ld-linux.so? Example: puma:/tmp# ldd /usr/bin/scp libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x4002f000) libz.so.1 => /usr/lib/libz.so.1 (0x40032000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0x40044000) libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x40059000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40156000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4028f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) puma:/tmp# ldd ./linux libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0x40018000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x4001b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) puma:/tmp# scp has a superset of linux's shared libs and runs ok: puma:/tmp# /lib/ld-linux.so.2 --library-path /lib:/usr/lib /usr/bin/scp usage: scp [-pqrvBC1246] [-F config] [-S program] [-P port] [-c cipher] [-i identity] [-l limit] [-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2 puma:/tmp# But linux does not run: puma:/tmp# /lib/ld-linux.so.2 --library-path /lib:/usr/lib /tmp/linux Checking for the skas3 patch in the host...found Checking for /proc/mm...found Mapping memory: Invalid argument puma:/tmp# If linux could run under ld-linux-so helper testing would be easier :) Regards, Nuno Silva ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 7:41 ` Nuno Silva @ 2004-01-06 8:02 ` Matt Zimmerman 2004-01-06 8:20 ` Nuno Silva 2004-01-06 9:20 ` Nuno Silva 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-06 8:02 UTC (permalink / raw) To: Nuno Silva; +Cc: Jeff Dike, user-mode-linux-devel, 224431 On Tue, Jan 06, 2004 at 07:41:39AM +0000, Nuno Silva wrote: > Jeff Dike wrote: > >mdz@debian.org said: > >Is it your opinion that there's no problem in UML itself? Having a field > >in the sigcontext getting magically munged is somewhat worrying. I'd be > >happier knowing what exactly was happening so I can be sure this wasn't > >exposing some subtle UML bug. > > > > I've been doing some tests and I'd say that the problem is something > regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and > 2.3.3cvs)... But I'm clueless about the fix :-) I suspect that the problem lies in this direction, because it's the only relevant news that I've heard from glibc in recent months, but I wouldn't expect NPTL to relate directly because I'm running on 2.4 (as are several others who have seen the problem). This is the issue where i386 support was dropped and i486-specific instructions used, right? -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 8:02 ` Matt Zimmerman @ 2004-01-06 8:20 ` Nuno Silva 2004-01-06 8:47 ` Nuno Silva 0 siblings, 1 reply; 43+ messages in thread From: Nuno Silva @ 2004-01-06 8:20 UTC (permalink / raw) To: Matt Zimmerman; +Cc: Jeff Dike, user-mode-linux-devel, 224431 Matt Zimmerman wrote: > On Tue, Jan 06, 2004 at 07:41:39AM +0000, Nuno Silva wrote: > > >>Jeff Dike wrote: >> >>>mdz@debian.org said: >>>Is it your opinion that there's no problem in UML itself? Having a field >>>in the sigcontext getting magically munged is somewhat worrying. I'd be >>>happier knowing what exactly was happening so I can be sure this wasn't >>>exposing some subtle UML bug. >>> >> >>I've been doing some tests and I'd say that the problem is something >>regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and >>2.3.3cvs)... But I'm clueless about the fix :-) > > > I suspect that the problem lies in this direction, because it's the only > relevant news that I've heard from glibc in recent months, but I wouldn't > expect NPTL to relate directly because I'm running on 2.4 (as are several > others who have seen the problem). > > This is the issue where i386 support was dropped and i486-specific > instructions used, right? > Yes, AFAIK nptl requires 486 asm. I just finished testing debian-unstable with glibc with nptl, tls and __thread support in chroot and everything works fine except UML :) I'm recompiling glibc with profiling to get a usable backtrace right now. With this setup linux gets a SIGSTOP (automagically) and after SIGCONT it just segfaults... In a few moments I'll have a backtrace :-) Regards, Nuno Silva ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 8:20 ` Nuno Silva @ 2004-01-06 8:47 ` Nuno Silva 0 siblings, 0 replies; 43+ messages in thread From: Nuno Silva @ 2004-01-06 8:47 UTC (permalink / raw) To: Nuno Silva; +Cc: Matt Zimmerman, Jeff Dike, user-mode-linux-devel, 224431 >> >> I suspect that the problem lies in this direction, because it's the only >> relevant news that I've heard from glibc in recent months, but I wouldn't >> expect NPTL to relate directly because I'm running on 2.4 (as are several >> others who have seen the problem). >> >> This is the issue where i386 support was dropped and i486-specific >> instructions used, right? >> > > Yes, AFAIK nptl requires 486 asm. > > I just finished testing debian-unstable with glibc with nptl, tls and > __thread support in chroot and everything works fine except UML :) > Another suspect is sysenter/sysexit support present in recent libc when used with 2.6.0... Hmmm :) Regards, Nuno Silva ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 7:41 ` Nuno Silva 2004-01-06 8:02 ` Matt Zimmerman @ 2004-01-06 9:20 ` Nuno Silva 2004-01-06 17:13 ` Matt Zimmerman 1 sibling, 1 reply; 43+ messages in thread From: Nuno Silva @ 2004-01-06 9:20 UTC (permalink / raw) To: user-mode-linux-devel; +Cc: 224431 [-- Attachment #1: Type: text/plain, Size: 4133 bytes --] Nuno Silva wrote: [...] > > I've been doing some tests and I'd say that the problem is something > regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and > 2.3.3cvs)... But I'm clueless about the fix :-) > > I'll setup a chroot where I can play around with glibc setups. > OK, just finished the chroot: debian unstable with glibc-2.3.3cvs hand-compiled (../libc/configure --with-tls --with-__thread --enable-add-ons=nptl --prefix=/ --enable-kernel=2.6.0) and removed the debian's libc. Everything runs OK with the new glibc, tested: bash, apt-get, perl, mc, strace, gcc, etc. However linux (UML's executable) doesn't run: puma:/uml# ls -la /proc/mm --w--w--w- 1 root root 0 Jan 6 08:33 /proc/mm puma:/uml# uname -a Linux puma 2.6.0 #2 Mon Jan 5 09:25:45 WET 2004 i686 unknown unknown GNU/Linux puma:/uml# ./linux Checking for the skas3 patch in the host...found Checking for /proc/mm...found [1]+ Stopped ./linux puma:/uml# fg ./linux Segmentation fault puma:/uml# Now with strace: (see attached file) Now with gdb: puma:/uml# gdb ./linux GNU gdb 6.0-debian Copyright 2003 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 "i386-linux"... (gdb) run Starting program: /uml/linux Detaching after fork from child process 26378. Checking for the skas3 patch in the host...found Checking for /proc/mm...found Detaching after fork from child process 26379. Program received signal SIGSTOP, Stopped (signal). 0x400f18dc in clone () from /lib/libc.so.6 (gdb) bt #0 0x400f18dc in clone () from /lib/libc.so.6 #1 0x4014f000 in ?? () #2 0x00000007 in ?? () #3 0x00001000 in ?? () #4 0xa00a7b7f in start_userspace (cpu=26379) at process.c:113 #5 0xa00a88e2 in start_uml_skas () at process_kern.c:162 #6 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 #7 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at arch/um/main.c:146 (gdb) cont Continuing. Program received signal SIGSTOP, Stopped (signal). 0x400f18dc in clone () from /lib/libc.so.6 (gdb) bt #0 0x400f18dc in clone () from /lib/libc.so.6 #1 0x4014f000 in ?? () #2 0x00000007 in ?? () #3 0x00001000 in ?? () #4 0xa00a7b7f in start_userspace (cpu=26379) at process.c:113 #5 0xa00a88e2 in start_uml_skas () at process_kern.c:162 #6 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 #7 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at arch/um/main.c:146 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0xa001305a in panic (fmt=0xbfffc000 "") at panic.c:67 67 panic.c: No such file or directory. in panic.c (gdb) bt #0 0xa001305a in panic (fmt=0xbfffc000 "") at panic.c:67 #1 0xa00a7bdd in start_userspace (cpu=-1073758208) at process.c:127 #2 0xa00a88e2 in start_uml_skas () at process_kern.c:162 #3 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 #4 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at arch/um/main.c:146 (gdb) cont Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) quit puma:/uml# In my tree, arch/um/kernel/skas/process.c:113 is the pid=clone(..., in void start_userspace(int cpu) { void *stack; unsigned long sp; int pid, status, n; stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if(stack == MAP_FAILED) panic("start_userspace : mmap failed, errno = %d", errno); sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *); pid = clone(userspace_tramp, (void *) sp, CLONE_FILES | CLONE_VM | SIGCHLD, NULL); I hope this makes sense to someone because I'm off to sleep a few hours :-) Regards, Nuno Silva [-- Attachment #2: straced-linux.txt --] [-- Type: text/plain, Size: 7914 bytes --] execve("./linux", ["./linux"], [/* 25 vars */]) = 0 uname({sys="Linux", node="puma", ...}) = 0 brk(0) = 0xa01f6000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 open("/lib/tls/i686/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/i686/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/i686", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/tls/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/tls/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/i686/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/i686/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\16\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=92994, ...}) = 0 mmap2(NULL, 10672, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000 mmap2(0x4001a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x4001a000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PZ\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=19666162, ...}) = 0 mmap2(NULL, 1252652, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000 mmap2(0x40142000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127) = 0x40142000 mmap2(0x4014b000, 7468, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014b000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014d000 set_thread_area({entry_number:-1 -> 6, base_addr:0x4014d070, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 rt_sigprocmask(SIG_SETMASK, [IO], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0xa01f6000 brk(0xa0217000) = 0xa0217000 brk(0) = 0xa0217000 rt_sigaction(SIGINT, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 rt_sigaction(SIGTERM, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 rt_sigaction(SIGHUP, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 fstat64(1, {st_mode=S_IFREG|0644, st_size=3126, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014e000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014f000 clone(child_stack=0x4014ffd8, flags=0|SIGCHLD) = 26355 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 waitpid(26355, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP], WUNTRACED) = 26355 ptrace(0x34 /* PTRACE_??? */, 26355, 0, 0xbffff8a0) = 0 ptrace(PTRACE_GETREGS, 26355, 0, 0xa01d8c60) = 0 ptrace(PTRACE_GETFPXREGS, 26355, 0, 0xa01d8d40) = 0 ptrace(PTRACE_CONT, 26355, 0, SIG_0) = 0 waitpid(26355, [WIFEXITED(s) && WEXITSTATUS(s) == 1], 0) = 26355 --- SIGCHLD (Child exited) @ 0 (0) --- munmap(0x4014f000, 4096) = 0 access("/proc/mm", W_OK) = 0 brk(0) = 0xa0217000 uname({sys="Linux", node="puma", ...}) = 0 gettimeofday({1073378804, 532883}, NULL) = 0 getpid() = 26354 open("/tmp/vm_file-AukWKw", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/tmp/vm_file-AukWKw") = 0 fchmod(3, 0777) = 0 _llseek(3, 33554432, [33554432], SEEK_SET) = 0 write(3, "\0", 1) = 1 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 mmap2(0xa0800000, 25165824, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x800) = 0xa0800000 mkdir("/root/.uml/", 0777) = -1 EEXIST (File exists) open("/root/.uml/uPjYnh", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 close(4) = 0 unlink("/root/.uml/uPjYnh") = 0 mkdir("/root/.uml/uPjYnh", 0777) = 0 open("/root/.uml/uPjYnh/pid", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4 write(4, "26354\n", 6) = 6 close(4) = 0 mprotect(0xa0196000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 write(1, "Checking for the skas3 patch in "..., 79Checking for the skas3 patch in the host...found Checking for /proc/mm...found ) = 79 mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014f000 clone(child_stack=0x4014ffd8, flags=CLONE_VM|CLONE_FILES|SIGCHLD) = 26356 --- SIGCHLD (Child exited) @ 0 (0) --- --- SIGSTOP (Stopped (signal)) @ 0 (0) --- --- SIGSTOP (Stopped (signal)) @ 0 (0) --- rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 waitpid(26356, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WUNTRACED) = 26356 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 9:20 ` Nuno Silva @ 2004-01-06 17:13 ` Matt Zimmerman 2004-01-09 7:22 ` Nuno Silva 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-06 17:13 UTC (permalink / raw) To: Nuno Silva; +Cc: user-mode-linux-devel, 224431 On Tue, Jan 06, 2004 at 09:20:06AM +0000, Nuno Silva wrote: > Nuno Silva wrote: > > [...] > > > > >I've been doing some tests and I'd say that the problem is something > >regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and > >2.3.3cvs)... But I'm clueless about the fix :-) > > > >I'll setup a chroot where I can play around with glibc setups. > > > > OK, just finished the chroot: debian unstable with glibc-2.3.3cvs > hand-compiled (../libc/configure --with-tls --with-__thread > --enable-add-ons=nptl --prefix=/ --enable-kernel=2.6.0) and removed the > debian's libc. > > Everything runs OK with the new glibc, tested: bash, apt-get, perl, mc, > strace, gcc, etc. > > However linux (UML's executable) doesn't run: > puma:/uml# ls -la /proc/mm > --w--w--w- 1 root root 0 Jan 6 08:33 /proc/mm > puma:/uml# uname -a > Linux puma 2.6.0 #2 Mon Jan 5 09:25:45 WET 2004 i686 unknown unknown > GNU/Linux > puma:/uml# ./linux > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > > [1]+ Stopped ./linux > puma:/uml# fg > ./linux > Segmentation fault > puma:/uml# This looks quite different from what I and others were seeing in #224431, which was random ENOSYS errors because the system call number in the regs struct was being mysteriously cleared during a context switch on the cost. > Now with strace: > (see attached file) > > Now with gdb: > puma:/uml# gdb ./linux > GNU gdb 6.0-debian > Copyright 2003 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 "i386-linux"... > (gdb) run > Starting program: /uml/linux > Detaching after fork from child process 26378. > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > Detaching after fork from child process 26379. > > Program received signal SIGSTOP, Stopped (signal). > 0x400f18dc in clone () from /lib/libc.so.6 > (gdb) bt > #0 0x400f18dc in clone () from /lib/libc.so.6 > #1 0x4014f000 in ?? () > #2 0x00000007 in ?? () > #3 0x00001000 in ?? () > #4 0xa00a7b7f in start_userspace (cpu=26379) at process.c:113 > #5 0xa00a88e2 in start_uml_skas () at process_kern.c:162 > #6 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 > #7 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at > arch/um/main.c:146 > (gdb) cont > Continuing. > > Program received signal SIGSTOP, Stopped (signal). > 0x400f18dc in clone () from /lib/libc.so.6 > (gdb) bt > #0 0x400f18dc in clone () from /lib/libc.so.6 > #1 0x4014f000 in ?? () > #2 0x00000007 in ?? () > #3 0x00001000 in ?? () > #4 0xa00a7b7f in start_userspace (cpu=26379) at process.c:113 > #5 0xa00a88e2 in start_uml_skas () at process_kern.c:162 > #6 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 > #7 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at > arch/um/main.c:146 > (gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0xa001305a in panic (fmt=0xbfffc000 "") at panic.c:67 > 67 panic.c: No such file or directory. > in panic.c > (gdb) bt > #0 0xa001305a in panic (fmt=0xbfffc000 "") at panic.c:67 > #1 0xa00a7bdd in start_userspace (cpu=-1073758208) at process.c:127 > #2 0xa00a88e2 in start_uml_skas () at process_kern.c:162 > #3 0xa00a6bcb in linux_main (argc=0, argv=0xa0000000) at um_arch.c:387 > #4 0xa000de0e in main (argc=1, argv=0xbffffa44, envp=0xbffffa4c) at > arch/um/main.c:146 > (gdb) cont > Continuing. > > Program terminated with signal SIGSEGV, Segmentation fault. > The program no longer exists. > (gdb) quit > puma:/uml# > > In my tree, arch/um/kernel/skas/process.c:113 is the pid=clone(..., in > > void start_userspace(int cpu) > { > void *stack; > unsigned long sp; > int pid, status, n; > > stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > if(stack == MAP_FAILED) > panic("start_userspace : mmap failed, errno = %d", errno); > sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *); > > pid = clone(userspace_tramp, (void *) sp, > CLONE_FILES | CLONE_VM | SIGCHLD, NULL); > > > I hope this makes sense to someone because I'm off to sleep a few hours :-) > > Regards, > Nuno Silva > > > > > execve("./linux", ["./linux"], [/* 25 vars */]) = 0 > uname({sys="Linux", node="puma", ...}) = 0 > brk(0) = 0xa01f6000 > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 > open("/lib/tls/i686/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/tls/i686/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/tls/i686/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/tls/i686", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/tls/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/tls/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/tls/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/tls", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/i686/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/i686/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/i686/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/i686", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/mmx/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) > stat64("/lib/mmx", 0xbffff16c) = -1 ENOENT (No such file or directory) > open("/lib/libutil.so.1", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\16\0\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=92994, ...}) = 0 > mmap2(NULL, 10672, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000 > mmap2(0x4001a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x4001a000 > close(3) = 0 > open("/lib/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PZ\1\000"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=19666162, ...}) = 0 > mmap2(NULL, 1252652, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000 > mmap2(0x40142000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127) = 0x40142000 > mmap2(0x4014b000, 7468, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014b000 > close(3) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014d000 > set_thread_area({entry_number:-1 -> 6, base_addr:0x4014d070, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > rt_sigprocmask(SIG_SETMASK, [IO], NULL, 8) = 0 > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 > brk(0) = 0xa01f6000 > brk(0xa0217000) = 0xa0217000 > brk(0) = 0xa0217000 > rt_sigaction(SIGINT, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 > rt_sigaction(SIGTERM, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 > rt_sigaction(SIGHUP, {0xa000dc90, [], SA_NOMASK|SA_ONESHOT}, NULL, 8) = 0 > fstat64(1, {st_mode=S_IFREG|0644, st_size=3126, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014e000 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014f000 > clone(child_stack=0x4014ffd8, flags=0|SIGCHLD) = 26355 > --- SIGCHLD (Child exited) @ 0 (0) --- > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > waitpid(26355, [WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP], WUNTRACED) = 26355 > ptrace(0x34 /* PTRACE_??? */, 26355, 0, 0xbffff8a0) = 0 > ptrace(PTRACE_GETREGS, 26355, 0, 0xa01d8c60) = 0 > ptrace(PTRACE_GETFPXREGS, 26355, 0, 0xa01d8d40) = 0 > ptrace(PTRACE_CONT, 26355, 0, SIG_0) = 0 > waitpid(26355, [WIFEXITED(s) && WEXITSTATUS(s) == 1], 0) = 26355 > --- SIGCHLD (Child exited) @ 0 (0) --- > munmap(0x4014f000, 4096) = 0 > access("/proc/mm", W_OK) = 0 > brk(0) = 0xa0217000 > uname({sys="Linux", node="puma", ...}) = 0 > gettimeofday({1073378804, 532883}, NULL) = 0 > getpid() = 26354 > open("/tmp/vm_file-AukWKw", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 > unlink("/tmp/vm_file-AukWKw") = 0 > fchmod(3, 0777) = 0 > _llseek(3, 33554432, [33554432], SEEK_SET) = 0 > write(3, "\0", 1) = 1 > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > mmap2(0xa0800000, 25165824, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x800) = 0xa0800000 > mkdir("/root/.uml/", 0777) = -1 EEXIST (File exists) > open("/root/.uml/uPjYnh", O_RDWR|O_CREAT|O_EXCL, 0600) = 4 > close(4) = 0 > unlink("/root/.uml/uPjYnh") = 0 > mkdir("/root/.uml/uPjYnh", 0777) = 0 > open("/root/.uml/uPjYnh/pid", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4 > write(4, "26354\n", 6) = 6 > close(4) = 0 > mprotect(0xa0196000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 > write(1, "Checking for the skas3 patch in "..., 79Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > ) = 79 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4014f000 > clone(child_stack=0x4014ffd8, flags=CLONE_VM|CLONE_FILES|SIGCHLD) = 26356 > --- SIGCHLD (Child exited) @ 0 (0) --- > --- SIGSTOP (Stopped (signal)) @ 0 (0) --- > --- SIGSTOP (Stopped (signal)) @ 0 (0) --- > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > waitpid(26356, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WUNTRACED) = 26356 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [], [IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM IO], NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM], [ALRM VTALRM IO], 8) = 0 > rt_sigprocmask(SIG_BLOCK, [IO], NULL, 8) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 17:13 ` Matt Zimmerman @ 2004-01-09 7:22 ` Nuno Silva 0 siblings, 0 replies; 43+ messages in thread From: Nuno Silva @ 2004-01-09 7:22 UTC (permalink / raw) To: Matt Zimmerman; +Cc: user-mode-linux-devel, 224431 Matt Zimmerman wrote: >>puma:/uml# fg >>./linux >>Segmentation fault >>puma:/uml# > > > This looks quite different from what I and others were seeing in #224431, > which was random ENOSYS errors because the system call number in the regs > struct was being mysteriously cleared during a context switch on the cost. Yes, probably not the same issue. I've made some new tests and I'd say that my problem relates to NPTL in glibc. (I don't have a fix, yet :( ) I'll open another thread :-) Regards, Nuno Silva ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems) 2004-01-06 2:58 ` Jeff Dike 2004-01-06 7:41 ` Nuno Silva @ 2004-01-08 7:07 ` Matt Zimmerman 2004-01-12 18:36 ` [uml-devel] Panic with slirp transport and gcc 3.3 Matt Zimmerman 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-08 7:07 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 224431, debian-gcc On Mon, Jan 05, 2004 at 09:58:32PM -0500, Jeff Dike wrote: > mdz@debian.org said: > > It turns out that this problem seems to be due to compiler > > incompatibility. UML had been built with gcc 2.95 due to old breakage, > > and when built with gcc 3.3 (as glibc is), everything starts working > > again. My suspicion is that this is due to certain recent changes in > > pthreads. > > Is it your opinion that there's no problem in UML itself? Having a field > in the sigcontext getting magically munged is somewhat worrying. I'd be > happier knowing what exactly was happening so I can be sure this wasn't > exposing some subtle UML bug. I was not able to come to a satisfactory conclusion as to the origin of the problem, and once I found a solution, I stopped looking. I'm copying debian-gcc and debian-glibc in case they're interested. Summary for debian-{gcc,glibc}: UML built with gcc-2.95 fails to run correctly on a current unstable system with a 2.4 kernel. The symptoms are very strange; This started to happen recently; UML had been building with gcc 2.95 successfully for over 9 months now with no problems. Details are here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224431 -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [uml-devel] Panic with slirp transport and gcc 3.3 2004-01-08 7:07 ` Matt Zimmerman @ 2004-01-12 18:36 ` Matt Zimmerman 2004-01-13 15:25 ` [uml-devel] " Bill Allombert 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-12 18:36 UTC (permalink / raw) To: Jeff Dike, user-mode-linux-devel, debian-gcc, ballombe, 176485 On Wed, Jan 07, 2004 at 11:07:18PM -0800, Matt Zimmerman wrote: > On Mon, Jan 05, 2004 at 09:58:32PM -0500, Jeff Dike wrote: > > > mdz@debian.org said: > > > It turns out that this problem seems to be due to compiler > > > incompatibility. UML had been built with gcc 2.95 due to old breakage, > > > and when built with gcc 3.3 (as glibc is), everything starts working > > > again. My suspicion is that this is due to certain recent changes in > > > pthreads. > > > > Is it your opinion that there's no problem in UML itself? Having a field > > in the sigcontext getting magically munged is somewhat worrying. I'd be > > happier knowing what exactly was happening so I can be sure this wasn't > > exposing some subtle UML bug. > > I was not able to come to a satisfactory conclusion as to the origin of the > problem, and once I found a solution, I stopped looking. I'm copying > debian-gcc and debian-glibc in case they're interested. > > Summary for debian-{gcc,glibc}: > > UML built with gcc-2.95 fails to run correctly on a current unstable system > with a 2.4 kernel. The symptoms are very strange; This started to happen recently; UML had been building > with gcc 2.95 successfully for over 9 months now with no problems. > > Details are here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224431 By the way, the original reason why I started building UML with gcc-2.95 was because building with 3.x broke the slirp transport like so: Kernel panic: read of switch_pipe failed, errno = 9 errno 9 is EBADF. I never did find the real cause of that bug, but it has resurfaced now that I am building with gcc 3.3 again to fix the other, worse bug. I would be interested to know if anyone else has run into it. More information is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=176485&archive=yes -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-12 18:36 ` [uml-devel] Panic with slirp transport and gcc 3.3 Matt Zimmerman @ 2004-01-13 15:25 ` Bill Allombert 2004-01-13 17:30 ` Jeff Dike 0 siblings, 1 reply; 43+ messages in thread From: Bill Allombert @ 2004-01-13 15:25 UTC (permalink / raw) To: Jeff Dike, user-mode-linux-devel, 176485; +Cc: mdz On Mon, Jan 12, 2004 at 10:36:23AM -0800, Matt Zimmerman wrote: > By the way, the original reason why I started building UML with gcc-2.95 was > because building with 3.x broke the slirp transport like so: > > Kernel panic: read of switch_pipe failed, errno = 9 > > errno 9 is EBADF. I never did find the real cause of that bug, but it has > resurfaced now that I am building with gcc 3.3 again to fix the other, worse > bug. I would be interested to know if anyone else has run into it. More > information is here: For what it worth with the current Debian UML package I get $ linux ubd0=uml root=/dev/ubd0 eth0=slirp|& less ... Netdevice 0 : SLIRP backend - command line: 'slirp' mconsole (version 2) initialized on /home/bill/.uml/wksNEk/mconsole Partition check: ubda: unknown partition table Initializing stdio console driver NET4: Linux TCP/IP 1.0 for NET4.0 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Kernel panic: Segfault with no mm Without the eth0=slirp parameter, there are no kernel panic. So at least the error message has changed. The host kernel has the skas patch from the Debian package applied. Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-13 15:25 ` [uml-devel] " Bill Allombert @ 2004-01-13 17:30 ` Jeff Dike 2004-01-13 17:44 ` Bill Allombert 2004-01-13 18:51 ` Matt Zimmerman 0 siblings, 2 replies; 43+ messages in thread From: Jeff Dike @ 2004-01-13 17:30 UTC (permalink / raw) To: Bill Allombert; +Cc: user-mode-linux-devel, 176485, mdz allomber@math.u-bordeaux.fr said: > Kernel panic: Segfault with no mm > Without the eth0=slirp parameter, there are no kernel panic. Can someone get a stack trace from this? Jeff ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-13 17:30 ` Jeff Dike @ 2004-01-13 17:44 ` Bill Allombert 2004-01-13 18:51 ` Matt Zimmerman 1 sibling, 0 replies; 43+ messages in thread From: Bill Allombert @ 2004-01-13 17:44 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 176485, mdz On Tue, Jan 13, 2004 at 12:30:22PM -0500, Jeff Dike wrote: > allomber@math.u-bordeaux.fr said: > > Kernel panic: Segfault with no mm > > Without the eth0=slirp parameter, there are no kernel panic. > > Can someone get a stack trace from this? Here what I get: NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Program received signal SIGSEGV, Segmentation fault. walk_init_root (name=0xf4a33ee8 <Address 0xf4a33ee8 out of bounds>, nd=0xa08f7b74) at atomic.h:107 107 __asm__ __volatile__( (gdb) bt #0 walk_init_root (name=0xf4a33ee8 <Address 0xf4a33ee8 out of bounds>, nd=0xa08f7b74) at atomic.h:107 (gdb) c Continuing. Breakpoint 1, segv (address=4104339216, ip=2685837537, is_write=2, is_user=0, sc=0xf4a33f10) at trap_kern.c:124 124 if(!is_user && (address >= start_vm) && (address < end_vm)){ (gdb) bt #0 segv (address=4104339216, ip=2685837537, is_write=2, is_user=0, sc=0xf4a33f10) at trap_kern.c:124 (gdb) bt #0 segv (address=4104339216, ip=2685837537, is_write=2, is_user=0, sc=0xf4a33f10) at trap_kern.c:124 (gdb) c Continuing. Breakpoint 2, panic (fmt=0xa08f4000 "") at panic.c:58 58 machine_paniced = 1; (gdb) bt #0 panic (fmt=0xa08f4000 "") at panic.c:58 (gdb) c Continuing. Kernel panic: Segfault with no mm Program exited normally. Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-13 17:30 ` Jeff Dike 2004-01-13 17:44 ` Bill Allombert @ 2004-01-13 18:51 ` Matt Zimmerman 2004-01-16 2:38 ` Jeff Dike 1 sibling, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-13 18:51 UTC (permalink / raw) To: Jeff Dike; +Cc: Bill Allombert, user-mode-linux-devel, 176485 On Tue, Jan 13, 2004 at 12:30:22PM -0500, Jeff Dike wrote: > allomber@math.u-bordeaux.fr said: > > Kernel panic: Segfault with no mm > > Without the eth0=slirp parameter, there are no kernel panic. > > Can someone get a stack trace from this? Certainly (this is from 2.4.23-1um). Seems like something goes weird with procfs, but I've no idea why this only happens with slirp (and newer gcc for that matter). (gdb) bt #0 panic (fmt=0x0) at panic.c:58 #1 0xa00d769b in segv (address=8, ip=2685922193, is_write=0, is_user=0, sc=0x0) at trap_kern.c:144 #2 0xa00d7af5 in segv_handler (sig=11, regs=0xa0350274) at trap_user.c:67 #3 0xa00df411 in sig_handler_common_skas (sig=11, sc_ptr=0x58) at trap_user.c:33 #4 0xa00d7c05 in sig_handler (sig=0, sc= {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 2687843188, esi = 2688540673, ebp = 2687843100, esp = 2687843028, ebx = 2687843188, edx = 2687843188, ecx = 2687827968, eax = 0, trapno = 14, err = 4, eip = 2684641864, cs = 35, __csh = 0, eflags = 2163202, esp_at_signal = 2687843028, ss = 43, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 8}) at trap_user.c:103 #5 <signal handler called> #6 0xa0046248 in link_path_walk (name=0xa03fe001 "dev", nd=0xa0353b74) at namei.c:462 #7 0xa004674e in path_walk (name=0x0, nd=0xa0353b74) at namei.c:659 #8 0xa0046919 in path_lookup (path=0xa03fe000 "/dev", flags=2687843188, nd=0xa0353b74) at namei.c:748 #9 0xa0047754 in sys_mkdir (pathname=0x0, mode=448) at namei.c:1345 #10 0xa000eafa in prepare_namespace () at init/do_mounts.c:917 #11 0xa000e613 in init (unused=0x0) at init/main.c:580 #12 0xa00d22f9 in run_kernel_thread (fn=0xa000e600 <init>, arg=0x0, #13 0xa00de930 in new_thread_handler (sig=10) at process_kern.c:70 #14 <signal handler called> (gdb) i sym 2685922193 kill + 17 in section .text (gdb) i line *2685922193 Line 155 of "proc_fs.h" starts at address 0xa0178e94 <svc_proc_register+68> and ends at 0xa01c3913. (gdb) up 6 #6 0xa0046248 in link_path_walk (name=0xa03fe001 "dev", nd=0xa0353b74) at namei.c:462 462 inode = nd->dentry->d_inode; (gdb) print *nd $1 = {dentry = 0x0, mnt = 0x0, last = { name = 0x8124 <Address 0x8124 out of bounds>, len = 1, hash = 2686526256}, flags = 16, last_type = 1} -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-13 18:51 ` Matt Zimmerman @ 2004-01-16 2:38 ` Jeff Dike 2004-01-16 2:38 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Jeff Dike @ 2004-01-16 2:38 UTC (permalink / raw) To: Matt Zimmerman; +Cc: Bill Allombert, user-mode-linux-devel, 176485 mdz@debian.org said: > Certainly (this is from 2.4.23-1um). Seems like something goes weird > with procfs, but I've no idea why this only happens with slirp (and > newer gcc for that matter). Just tried it, boots fine here, but then I'm not playing with new gccs. Can you send me the binary that crashes? I assume it's statically linked... I'm thinking that something funky is happening in the initcalls, and the slirp initcall happens to push the funkiness over the edge. Jeff ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-16 2:38 ` Jeff Dike @ 2004-01-16 2:38 ` Matt Zimmerman 2004-01-16 20:04 ` Jeff Dike 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-16 2:38 UTC (permalink / raw) To: Jeff Dike; +Cc: Bill Allombert, user-mode-linux-devel, 176485 On Thu, Jan 15, 2004 at 09:38:34PM -0500, Jeff Dike wrote: > mdz@debian.org said: > > Certainly (this is from 2.4.23-1um). Seems like something goes weird > > with procfs, but I've no idea why this only happens with slirp (and > > newer gcc for that matter). > > Just tried it, boots fine here, but then I'm not playing with new gccs. > > Can you send me the binary that crashes? I assume it's statically linked... > > I'm thinking that something funky is happening in the initcalls, and the slirp > initcall happens to push the funkiness over the edge. http://people.debian.org/~mdz/temp/linux-176485 -- - mdz ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-16 2:38 ` Matt Zimmerman @ 2004-01-16 20:04 ` Jeff Dike 2004-01-16 19:49 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Jeff Dike @ 2004-01-16 20:04 UTC (permalink / raw) To: Matt Zimmerman; +Cc: Bill Allombert, user-mode-linux-devel, 176485 % file linux-176485 linux-176485: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped Having it stripped is inconvenient. Can you compress a debuggable binary and put it someplace I can grab it? Jeff ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-16 20:04 ` Jeff Dike @ 2004-01-16 19:49 ` Matt Zimmerman 2004-01-17 0:42 ` Matt Zimmerman 0 siblings, 1 reply; 43+ messages in thread From: Matt Zimmerman @ 2004-01-16 19:49 UTC (permalink / raw) To: Jeff Dike; +Cc: Bill Allombert, user-mode-linux-devel, 176485 On Fri, Jan 16, 2004 at 03:04:21PM -0500, Jeff Dike wrote: > % file linux-176485 > linux-176485: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > Having it stripped is inconvenient. Can you compress a debuggable binary > and put it someplace I can grab it? http://people.debian.org/~mdz/temp/linux-176485.gz (ETA ~10 minutes; it's rather enormous) -- - mdz ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] Re: Panic with slirp transport and gcc 3.3 2004-01-16 19:49 ` Matt Zimmerman @ 2004-01-17 0:42 ` Matt Zimmerman 0 siblings, 0 replies; 43+ messages in thread From: Matt Zimmerman @ 2004-01-17 0:42 UTC (permalink / raw) To: Jeff Dike, Bill Allombert, user-mode-linux-devel, 176485 On Fri, Jan 16, 2004 at 11:49:29AM -0800, Matt Zimmerman wrote: > On Fri, Jan 16, 2004 at 03:04:21PM -0500, Jeff Dike wrote: > > > % file linux-176485 > > linux-176485: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > > > Having it stripped is inconvenient. Can you compress a debuggable binary > > and put it someplace I can grab it? > > http://people.debian.org/~mdz/temp/linux-176485.gz > > (ETA ~10 minutes; it's rather enormous) As mentioned on IRC, if I change slirp_init to return early and skip the printk's at the end, UML boots and runs fine; the interface even comes up OK. So if there is corruption happening, maybe it's down below somewhere (or maybe it's weirder still). -- - mdz ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-20 17:14 ` Jeff Dike 2003-12-21 0:47 ` Matt Zimmerman 2003-12-21 0:52 ` Matt Zimmerman @ 2003-12-21 1:29 ` Matt Zimmerman 2 siblings, 0 replies; 43+ messages in thread From: Matt Zimmerman @ 2003-12-21 1:29 UTC (permalink / raw) To: Jeff Dike; +Cc: user-mode-linux-devel, 224431, 224502 On Sat, Dec 20, 2003 at 12:14:50PM -0500, Jeff Dike wrote: > The only thing that seemed remotely relevant is the unistd.h change, which > fixes a bug in the case of an error in an internally called system call. > You can try reverting that and see what happens. FWIW, I tried reverting this and it made no difference. -- - mdz ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [uml-devel] 2.4.22-[67] problems 2003-12-20 1:13 [uml-devel] 2.4.22-[67] problems Matt Zimmerman 2003-12-20 17:14 ` Jeff Dike @ 2003-12-20 19:05 ` Nick Craig-Wood 1 sibling, 0 replies; 43+ messages in thread From: Nick Craig-Wood @ 2003-12-20 19:05 UTC (permalink / raw) To: user-mode-linux-devel, 224431, 224502 On Fri, Dec 19, 2003 at 05:13:23PM -0800, Matt Zimmerman wrote: > There definitely seems to be something awry here, even in skas mode. > I am getting a lot of ENOSYS errors inside UML: FYI I had no end of trouble building 2.4.22-7 with Debian testing (with gcc 2-95). I got it to compile OK (with lots of warnings), but I couldn't get it to run reliably. I've changed to building it in a woody chroot and it runs perfectly now! > 2. CONFIG_UML_REAL_TIME_CLOCK=y was added to the configuration Watch out if running on > 2 GHz CPU - see list archives for patch the UML will hang quite early on. Sorry not a very scientific report! -- Nick Craig-Wood ncw1@axis.demon.co.uk ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2004-01-17 0:42 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-12-20 1:13 [uml-devel] 2.4.22-[67] problems Matt Zimmerman 2003-12-20 17:14 ` Jeff Dike 2003-12-21 0:47 ` Matt Zimmerman 2003-12-21 15:58 ` BlaisorBlade 2003-12-21 22:40 ` Matt Zimmerman 2003-12-21 23:16 ` Matt Zimmerman 2003-12-22 0:25 ` Jeff Dike 2003-12-22 4:08 ` Matt Zimmerman 2003-12-22 5:49 ` Daniel Jacobowitz 2003-12-22 9:08 ` Matt Zimmerman 2004-01-05 17:51 ` Adam Heath 2004-01-05 18:10 ` Matt Zimmerman 2003-12-24 12:48 ` BlaisorBlade 2003-12-21 0:52 ` Matt Zimmerman 2003-12-21 1:06 ` Matt Zimmerman 2003-12-28 9:33 ` Matt Zimmerman 2003-12-28 9:51 ` Matt Zimmerman 2003-12-28 9:52 ` Matt Zimmerman 2004-01-06 2:59 ` Jeff Dike 2003-12-28 10:12 ` Matt Zimmerman 2003-12-28 11:30 ` Matt Zimmerman 2003-12-30 18:43 ` Resolution (Re: [uml-devel] 2.4.22-[67] problems) Matt Zimmerman 2004-01-06 2:58 ` Jeff Dike 2004-01-06 7:41 ` Nuno Silva 2004-01-06 8:02 ` Matt Zimmerman 2004-01-06 8:20 ` Nuno Silva 2004-01-06 8:47 ` Nuno Silva 2004-01-06 9:20 ` Nuno Silva 2004-01-06 17:13 ` Matt Zimmerman 2004-01-09 7:22 ` Nuno Silva 2004-01-08 7:07 ` Matt Zimmerman 2004-01-12 18:36 ` [uml-devel] Panic with slirp transport and gcc 3.3 Matt Zimmerman 2004-01-13 15:25 ` [uml-devel] " Bill Allombert 2004-01-13 17:30 ` Jeff Dike 2004-01-13 17:44 ` Bill Allombert 2004-01-13 18:51 ` Matt Zimmerman 2004-01-16 2:38 ` Jeff Dike 2004-01-16 2:38 ` Matt Zimmerman 2004-01-16 20:04 ` Jeff Dike 2004-01-16 19:49 ` Matt Zimmerman 2004-01-17 0:42 ` Matt Zimmerman 2003-12-21 1:29 ` [uml-devel] 2.4.22-[67] problems Matt Zimmerman 2003-12-20 19:05 ` Nick Craig-Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.