From: roland <for...@gm...> - 2003-12-08 00:29:27
|
Hi ! I found a better workaround: digging deeper into yast, i found that yast (fortunately) uses a special "ycp" Scripting language. A menu-entry in yast consinsts of several ycp modules. a module, which loads quite often is the module "Arch.ycp". with that, yast seems to detect, which hardware architecture it`s running on. unfortunately, the detection within uml doesn`t seem to work correctly and results in the hanging "y2base"(seems to be the ycp "interpreter") process. i can supply more detailed strace output. y2base receives SIGSEGV after a fork (but still keeps running). as a workaround, i would like to recommend the following: edit /usr/share/Yast2/modules/Arch.ycp and replace the line "list systemProbe = SCR:Read(.probe.system);" with "list systemProbe = nil;" that works for me and fixes a lot of the "hanging" in yast. unfortunatly, starting the software-installation-module in yast is VERY slow under uml, when it reads the package information. strace (works inside uml, after all) shows me, that there are LOTS of seeks (was it llseek? must look again). is llseek known to be "extra slow" within uml and can be called a "worse case" ? btw: what would be a better solution: asking the suse people to make yast "uml-aware" or fixing those things inside uml? gerd, since i seem to be not the only person to experience this problem, perhaps you could add my solution to the suse uml-howto at http://www.suse.de/~kraxel/uml/howto.html, if you find it useful ? (btw: i had done the suse9 setup with the uml-suse-install script) regards roland >Date: 2003-12-05 10:26 >Sender: nobody >Logged In: NO > >I have seen a similar bug with YaST using SuSE8.2 running >under UML. I don't know a fix, but I do know a work around: > >Login via ssh, run top, locate the process that is consumming >most of the CPU cycles and send it a SIGHUP. Once the signal >is sent, YaST recovers and the CPU cycles drop to normal. > >But here is the strange thing, Sometimes, usually the first >attempt, it is only necessary to make the ssh connection to >recover the box. But on subsequent invocations of YaST, only >the signal will do. ----- Original Message ----- From: "roland" <for...@gm...> To: <use...@li...>; "uml-user" <use...@li...> Sent: Monday, December 01, 2003 12:03 AM Subject: bug: [ 851759 ] SuSE YAST in textmode does not work > Hi, > i have submitted a bugreport related to yast: > http://sourceforge.net/tracker/index.php?func=detail&atid=100429&aid=851759&group_id=429 > i don`t know if it`s a yast bug or if it`s a uml bug - but the effect is, that yast isn`t really usable inside an uml. did others > experience this bug? comments? > > regards > roland > > ps: > it is important for me to fix this, because if i setup uml`s for my users, the first thing they will do is firing up yast to install > packages. so - this is an essential tool which should work correct. > > pps: > sorry for flooding uml-lists with so many posts - but i had just some time this weekend :D > |
From: Matt A. <ma...@te...> - 2003-12-08 00:34:24
|
I don't know about llseek, but access to /dev/random seems to be VERY slow from within UML. On Sun, 2003-12-07 at 19:33, roland wrote: > Hi ! > I found a better workaround: > > digging deeper into yast, i found that yast (fortunately) uses a special "ycp" Scripting language. A menu-entry in > yast consinsts of several ycp modules. a module, which loads quite often is the module "Arch.ycp". with that, yast seems to detect, > which hardware architecture it`s running on. > unfortunately, the detection within uml doesn`t seem to work correctly and results in the hanging "y2base"(seems to be the ycp > "interpreter") process. i can supply more detailed strace output. y2base receives SIGSEGV after a fork (but still keeps running). > > as a workaround, i would like to recommend the following: > > edit /usr/share/Yast2/modules/Arch.ycp > > and replace the line > "list systemProbe = SCR:Read(.probe.system);" > with > "list systemProbe = nil;" > > that works for me and fixes a lot of the "hanging" in yast. > unfortunatly, starting the software-installation-module in yast is VERY slow under uml, when it reads the package information. > strace (works inside uml, after all) shows me, that there are LOTS of seeks (was it llseek? must look again). is llseek known to be > "extra slow" within uml and can be called a "worse case" ? > > btw: what would be a better solution: asking the suse people to make yast "uml-aware" or fixing those things inside uml? > > gerd, since i seem to be not the only person to experience this problem, perhaps you could add my solution to the suse uml-howto at > http://www.suse.de/~kraxel/uml/howto.html, if you find it useful ? (btw: i had done the suse9 setup with the uml-suse-install > script) > > regards > roland > > > >Date: 2003-12-05 10:26 > >Sender: nobody > >Logged In: NO > > > >I have seen a similar bug with YaST using SuSE8.2 running > >under UML. I don't know a fix, but I do know a work around: > > > >Login via ssh, run top, locate the process that is consumming > >most of the CPU cycles and send it a SIGHUP. Once the signal > >is sent, YaST recovers and the CPU cycles drop to normal. > > > >But here is the strange thing, Sometimes, usually the first > >attempt, it is only necessary to make the ssh connection to > >recover the box. But on subsequent invocations of YaST, only > >the signal will do. > > > ----- Original Message ----- > From: "roland" <for...@gm...> > To: <use...@li...>; "uml-user" <use...@li...> > Sent: Monday, December 01, 2003 12:03 AM > Subject: bug: [ 851759 ] SuSE YAST in textmode does not work > > > > Hi, > > i have submitted a bugreport related to yast: > > http://sourceforge.net/tracker/index.php?func=detail&atid=100429&aid=851759&group_id=429 > > i don`t know if it`s a yast bug or if it`s a uml bug - but the effect is, that yast isn`t really usable inside an uml. did others > > experience this bug? comments? > > > > regards > > roland > > > > ps: > > it is important for me to fix this, because if i setup uml`s for my users, the first thing they will do is firing up yast to > install > > packages. so - this is an essential tool which should work correct. > > > > pps: > > sorry for flooding uml-lists with so many posts - but i had just some time this weekend :D > > > > > > ------------------------------------------------------- > 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 > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Matt Ayres <ma...@te...> TekTonic |
From: Henrik N. <hn...@ma...> - 2003-12-08 09:40:44
|
On Sun, 7 Dec 2003, Matt Ayres wrote: > I don't know about llseek, but access to /dev/random seems to be VERY > slow from within UML. That would not be supricing... UML does not have very good random sources to populate /dev/random and /dev/random very easily gets drained of the little random information it has.. and in fact the same applies to all architectures unless your hardware has a random number generator. Generally /dev/urandom provides sufficient random information for most purposes. Why are you using /dev/random and not /dev/urandom? Regards Henrik |
From: Henrik N. <hn...@ma...> - 2003-12-08 09:44:36
|
On Mon, 8 Dec 2003, roland wrote: > digging deeper into yast, i found that yast (fortunately) uses a special > "ycp" Scripting language. A menu-entry in yast consinsts of several ycp > modules. a module, which loads quite often is the module "Arch.ycp". > with that, yast seems to detect, which hardware architecture it`s > running on. Are you running UML in TT or SKAS mode? Regards Henrik |
From: roland <for...@gm...> - 2003-12-08 20:27:50
|
> Are you running UML in TT or SKAS mode? I hated TT mode for all the time - for that reason i run SKAS :) ----- Original Message ----- From: "Henrik Nordstrom" <hn...@ma...> To: "roland" <for...@gm...> Cc: <use...@li...>; "uml-user" <use...@li...>; "Gerd Knorr" <kr...@by...> Sent: Monday, December 08, 2003 10:44 AM Subject: [uml-user] Re: [uml-devel] Workaround for bug #851759 - SuSE YAST in textmode does not work > On Mon, 8 Dec 2003, roland wrote: > > > digging deeper into yast, i found that yast (fortunately) uses a special > > "ycp" Scripting language. A menu-entry in yast consinsts of several ycp > > modules. a module, which loads quite often is the module "Arch.ycp". > > with that, yast seems to detect, which hardware architecture it`s > > running on. > > Are you running UML in TT or SKAS mode? > > Regards > Henrik > > > > ------------------------------------------------------- > 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-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Gerd K. <kr...@by...> - 2003-12-08 10:20:12
|
> "list systemProbe = SCR:Read(.probe.system);" Oh, that one. Didn't know yast triggeres this too. That is actually a bug in the uml kernel (there should be a mail in the -devel archive ...). One if the things the hardware probes does is to check whenever it runs within vmware or not, and that test hangs (source code below). Known workarounds: * boot with "hwprobe=-sys" (that will make the hardware detect skip the critical test), or * don't use skas mode (it hangs in skas mode only for some musterious reason), or * just do something else in another terminal, that will unblock it too (scheduler bug in the uml kernel?). > btw: what would be a better solution: asking the suse people to make > yast "uml-aware" or fixing those things inside uml? IMHO this one is a UML kernel bug. Gerd ==============================[ cut here ]============================== #define _GNU_SOURCE /* we want memmem() */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <signal.h> #include <sys/types.h> #include <sys/wait.h> void sigsegv_handler(int signum) { exit(77); } int chk_vmware(void) { static int is_vmware = -1; int child, status; /* do the check only once */ if(is_vmware < 0) { child = fork(); if(child == 0) { signal(SIGSEGV, sigsegv_handler); asm( "push %ebx\n" "\tpush %edx\n" "\tpush %eax\n" "\tpush %ecx\n" "\tmov $0x564d5868,%eax\n" "\tmov $0xa,%ecx\n" "\tmov $0x5658,%edx\n" "\tin (%dx),%eax\n" "\tpop %ecx\n" "\tpop %eax\n" "\tpop %edx\n" "\tpop %ebx\n" ); _exit(66); } else { if(waitpid(child, &status, 0) == child) { status = WEXITSTATUS(status); if(status == 66) is_vmware = 1; if(status == 77) is_vmware = 0; } } } return is_vmware; } int main(int argc, char *argv[]) { int rc; fprintf(stderr, "check for vmware... "); rc = chk_vmware(); fprintf(stderr, "%s\n", rc ? "yes" : "no"); return rc; } |
From: roland <for...@gm...> - 2003-12-08 22:25:57
|
hi! > Known workarounds: > * boot with "hwprobe=-sys" (that will make the hardware detect > skip the critical test), or ah - thanks, that seems to work fine. is this just a param, that tells yast to skip the detection test? can you tell me, why i need to pass that as a kernel param, not as a Yast param or an environment variable? if this doesn`t break or influence other things, i think this is _THE_ workaround for the problem and should be mentioned in the suse-howto or in the faq. btw: does YaST2 in gui mode behave the same? don`t have X11- Yast installed inside my uml root-image - so i cannot test at the moment. i deliver a text snippet here - perhaps someone could make some correction or addition because my english is not so perfect: ------------------ Yast problems within UML ------------------------ Yast is the setup and configuration tool of SuSE-Linux. If you are going to use it, you may encounter problems(Yast seems to freeze). It`s not for sure, but it is possibly an UML bug (to be fixed). Some modules within YaST do automatic hardware detection and there is a routine inside which detects, if your linux runs "inside" vmware. This seems to cause the problem. A known workaround for this is to add "hwprobe=-sys" to the uml commandline. This will make the hardware detection inside Yast skip the critical test. Further information can be found here: http://sourceforge.net/mailarchive/message.php?msg_id=6224097 ----------------- regards roland ----- Original Message ----- From: "Gerd Knorr" <kr...@by...> To: "roland" <for...@gm...> Cc: <use...@li...>; "uml-user" <use...@li...> Sent: Monday, December 08, 2003 10:59 AM Subject: [uml-user] Re: Workaround for bug #851759 - SuSE YAST in textmode does not work > > "list systemProbe = SCR:Read(.probe.system);" > > Oh, that one. Didn't know yast triggeres this too. That is actually > a bug in the uml kernel (there should be a mail in the -devel archive > ...). One if the things the hardware probes does is to check whenever > it runs within vmware or not, and that test hangs (source code below). > > Known workarounds: > * boot with "hwprobe=-sys" (that will make the hardware detect > skip the critical test), or > * don't use skas mode (it hangs in skas mode only for some > musterious reason), or > * just do something else in another terminal, that will unblock > it too (scheduler bug in the uml kernel?). > > > btw: what would be a better solution: asking the suse people to make > > yast "uml-aware" or fixing those things inside uml? > > IMHO this one is a UML kernel bug. > > Gerd > > ==============================[ cut here ]============================== > #define _GNU_SOURCE /* we want memmem() */ > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <unistd.h> > #include <signal.h> > > #include <sys/types.h> > #include <sys/wait.h> > > void sigsegv_handler(int signum) { exit(77); } > > int chk_vmware(void) > { > static int is_vmware = -1; > int child, status; > > /* do the check only once */ > if(is_vmware < 0) { > > child = fork(); > > if(child == 0) { > signal(SIGSEGV, sigsegv_handler); > > asm( > "push %ebx\n" > "\tpush %edx\n" > "\tpush %eax\n" > "\tpush %ecx\n" > "\tmov $0x564d5868,%eax\n" > "\tmov $0xa,%ecx\n" > "\tmov $0x5658,%edx\n" > "\tin (%dx),%eax\n" > "\tpop %ecx\n" > "\tpop %eax\n" > "\tpop %edx\n" > "\tpop %ebx\n" > ); > > _exit(66); > } > else { > if(waitpid(child, &status, 0) == child) { > status = WEXITSTATUS(status); > if(status == 66) is_vmware = 1; > if(status == 77) is_vmware = 0; > } > } > } > return is_vmware; > } > > int main(int argc, char *argv[]) > { > int rc; > > fprintf(stderr, "check for vmware... "); > rc = chk_vmware(); > fprintf(stderr, "%s\n", rc ? "yes" : "no"); > return rc; > } > > > ------------------------------------------------------- > 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-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Gerd K. <kr...@by...> - 2003-12-09 09:20:42
|
On Mon, Dec 08, 2003 at 11:30:18PM +0100, roland wrote: > hi! > > > Known workarounds: > > * boot with "hwprobe=-sys" (that will make the hardware detect > > skip the critical test), or > ah - thanks, that seems to work fine. is this just a param, that tells > yast to skip the detection test? can you tell me, why i need to pass > that as a kernel param, not as a Yast param or an environment variable? It must work for installations too, and there usually the kernel command line is the only way to pass parameters ... > in the faq. btw: does YaST2 in gui mode behave the same? don`t have X11- Probably. The actual code is in the hardware detection shared library, (package hwinfo). "hwinfo --cpu" shows this behavior too. Gerd -- You have a new virus in /var/mail/kraxel |
From: Henrik N. <hn...@ma...> - 2003-12-10 21:14:16
|
On Mon, 8 Dec 2003, Gerd Knorr wrote: > IMHO this one is a UML kernel bug. The hang certainly can be considered a UML bug. I think the same hang should be seen on any SIGSEGV due to incorrect X86 I/O operations. Can you try these two simple programs to try to isolate the error? /* test1.c */ #include <sys/io.h> int main(int argc, char **argv) { inw(0x1234); } /* test2.c */ #include <sys/types.h> #include <sys/unistd.h> #include <sys/io.h> int main(int argc, char **argv) { pid_t pid; pid = fork(); if (pid == 0) { inw(0x1234); } else { waitpid(pid, NULL, 0); } } The test as such will however (if not hanging) give a false positive if UML is running within vmware and can be questioned unless complemented with a UML test. Regards Henrik |
From: roland <for...@gm...> - 2003-12-10 23:47:55
|
Hi Henrik, i made the tests with your programs and here is the result: linux-uml:/mnt # ./test1 Segmentation fault linux-uml:/mnt # strace -f ./test1 execve("./test1", ["./test1"], [/* 43 vars */]) = 0 uname({sys="Linux", node="linux-uml", ...}) = 0 brk(0) = 0x804a000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=12585, ...}) = 0 old_mmap(NULL, 12585, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 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\0\0^\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1470060, ...}) = 0 old_mmap(NULL, 1269380, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000 old_mmap(0x4014a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12e000) = 0x4014a000 old_mmap(0x4014f000, 7812, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014f000 close(3) = 0 munmap(0x40017000, 12585) = 0 -------------------------------------------------------------------------------------- -> here the output stops until i type sth. into another VC window and hit enter. -> hitting ONLY enter isn`t enough - i need to type at least one char. furthermore, -> typing chars into the VC LOGIN PROMPT and hitting enter isn`t enough,too. i need to -> type it at the shell-prompt. after <key><enter> there, test1 segfaults like this: --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ this is absolutely reproducable. it _ALWAYS_ segfaults at once, when started from the console and it _ALWAYS_ hangs after munmap, when started under control of strace (or from within a shellscript).then it segfaults after <key><enter>. i have recognised that an ALPHANUMERICAL key _AND_ enter needs to be pressed to initiate the segfault. using cursorkeys alone or repeating commands at the shell-prompt (bash history cursor up/down) does NOT inititate a segfault. --------- test2 behaves different - and it behaves strange. first i recognized, that most of the time, after starting the program, i`m back at the prompt without any output(no segfault). but that`s not always - every 5-20 times i start test2, it hangs and can be ended by pressing <key><enter> in antother VC, too. under control of strace, again it ALWAYS hangs (as seen in test1): linux-uml:/mnt # strace -f ./test2 execve("./test2", ["./test2"], [/* 43 vars */]) = 0 uname({sys="Linux", node="linux-uml", ...}) = 0 brk(0) = 0x804a000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=12585, ...}) = 0 old_mmap(NULL, 12585, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000 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\0\0^\1\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1470060, ...}) = 0 old_mmap(NULL, 1269380, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000 old_mmap(0x4014a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12e000) = 0x4014a000 old_mmap(0x4014f000, 7812, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014f000 close(3) = 0 munmap(0x40017000, 12585) = 0 fork(Process 1561 attached ) = 1561 [pid 1560] waitpid(1561, Process 1560 suspended ------------------------------------------------------------------ -> now it hangs -> when i hit a <key><enter> in another VC it continues and gives: <unfinished ...> [pid 1561] --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 1560 resumed Process 1561 detached <... waitpid resumed> NULL, 0) = 1561 --- SIGCHLD (Child exited) @ 0 (0) --- exit_group(1561) = ? In both cases, on the host(2.6-test9-skas) uml-linux-process(2.6-test11) is eating most of the cpu (~ 1/3 user, ~ 2/3 system) Hope this information is useful :) regards roland ----- Original Message ----- From: "Henrik Nordstrom" <hn...@ma...> To: "Gerd Knorr" <kr...@by...> Cc: "roland" <for...@gm...>; <use...@li...>; "uml-user" <use...@li...> Sent: Wednesday, December 10, 2003 10:14 PM Subject: Re: [uml-devel] Re: Workaround for bug #851759 - SuSE YAST in textmode does not work > On Mon, 8 Dec 2003, Gerd Knorr wrote: > > > IMHO this one is a UML kernel bug. > > The hang certainly can be considered a UML bug. > > I think the same hang should be seen on any SIGSEGV due to incorrect X86 > I/O operations. Can you try these two simple programs to try to isolate > the error? > > > /* test1.c */ > > #include <sys/io.h> > > int main(int argc, char **argv) > { > inw(0x1234); > } > > > /* test2.c */ > > #include <sys/types.h> > #include <sys/unistd.h> > #include <sys/io.h> > > int main(int argc, char **argv) > { > pid_t pid; > pid = fork(); > if (pid == 0) { > inw(0x1234); > } else { > waitpid(pid, NULL, 0); > } > } > > > The test as such will however (if not hanging) give a false positive if > UML is running within vmware and can be questioned unless complemented > with a UML test. > > Regards > Henrik > > |
From: Gerd K. <kr...@by...> - 2003-12-11 11:55:15
|
On Wed, Dec 10, 2003 at 10:14:07PM +0100, Henrik Nordstrom wrote: > On Mon, 8 Dec 2003, Gerd Knorr wrote: > > > IMHO this one is a UML kernel bug. > > The hang certainly can be considered a UML bug. > > I think the same hang should be seen on any SIGSEGV due to incorrect X86 > I/O operations. Can you try these two simple programs to try to isolate > the error? > /* test1.c */ > /* test2.c */ Both test do hang (until doing something else in another terminal). test1 does *not* print a "Segmentation fault" message as it should (and does outside a uml machine). > The test as such will however (if not hanging) give a false positive if > UML is running within vmware and can be questioned unless complemented > with a UML test. The test seems to work correctly. Probably it tries to access a "magic" i/o port which is used for communication between vmware and guest os, but I don't know for sure. Gerd -- You have a new virus in /var/mail/kraxel |
From: Henrik N. <hn...@ma...> - 2003-12-11 12:59:11
|
On Thu, 11 Dec 2003, Gerd Knorr wrote: > The test seems to work correctly. Probably it tries to access a "magic" > i/o port which is used for communication between vmware and guest os, > but I don't know for sure. This is what the test does, and this will give a false positive when running UML within vmware making SuSe think it is running on vmware hardware when it is not really (UML and the host kernel is inbetween) Regards Henrik |
From: Gerd K. <kr...@by...> - 2003-12-11 14:00:18
|
> This is what the test does, and this will give a false positive when > running UML within vmware making SuSe think it is running on vmware > hardware when it is not really (UML and the host kernel is inbetween) Ah, *that* corner case you are talking about. Yea, in that case it will succeed although it doesn't run (directly) on vmware. Gerd -- You have a new virus in /var/mail/kraxel |
From: roland <for...@gm...> - 2003-12-11 21:54:54
|
mhhh, that result is different to the results i posted. what uml on what host are you using? regards roland ----- Original Message ----- From: "Gerd Knorr" <kr...@by...> To: "Henrik Nordstrom" <hn...@ma...> Cc: "roland" <for...@gm...>; <use...@li...>; "uml-user" <use...@li...> Sent: Thursday, December 11, 2003 1:00 PM Subject: Re: [uml-devel] Re: Workaround for bug #851759 - SuSE YAST in textmode does not work > On Wed, Dec 10, 2003 at 10:14:07PM +0100, Henrik Nordstrom wrote: > > On Mon, 8 Dec 2003, Gerd Knorr wrote: > > > > > IMHO this one is a UML kernel bug. > > > > The hang certainly can be considered a UML bug. > > > > I think the same hang should be seen on any SIGSEGV due to incorrect X86 > > I/O operations. Can you try these two simple programs to try to isolate > > the error? > > > /* test1.c */ > > > /* test2.c */ > > Both test do hang (until doing something else in another terminal). > test1 does *not* print a "Segmentation fault" message as it should > (and does outside a uml machine). > > > The test as such will however (if not hanging) give a false positive if > > UML is running within vmware and can be questioned unless complemented > > with a UML test. > > The test seems to work correctly. Probably it tries to access a "magic" > i/o port which is used for communication between vmware and guest os, > but I don't know for sure. > > Gerd > > -- > You have a new virus in /var/mail/kraxel > |
From: Gerd K. <kr...@by...> - 2003-12-12 08:55:24
|
On Thu, Dec 11, 2003 at 10:59:13PM +0100, roland wrote: > mhhh, > that result is different to the results i posted. > what uml on what host are you using? Host is 2.4.23, uml was 2.4.20. Just retested with a 2.6.0-test9 uml kernel, same results with one exeption: > > test1 does *not* print a "Segmentation fault" message as it should > > (and does outside a uml machine). I do get the "Segmentation fault" message with test1. Gerd -- You have a new virus in /var/mail/kraxel |
From: Henrik N. <hn...@ma...> - 2003-12-12 11:31:58
|
On Fri, 12 Dec 2003, Gerd Knorr wrote: > Host is 2.4.23, uml was 2.4.20. SKAS / TT? Regards Henrik |
From: Gerd K. <kr...@by...> - 2003-12-12 12:15:13
|
On Fri, Dec 12, 2003 at 12:31:44PM +0100, Henrik Nordstrom wrote: > On Fri, 12 Dec 2003, Gerd Knorr wrote: > > > Host is 2.4.23, uml was 2.4.20. > > SKAS / TT? skas, in tt mode it doesn't hang. Gerd -- You have a new virus in /var/mail/kraxel |