[uml-devel] Expected SIGSTOP persists in 2.4.26-3um

[uml-devel] Expected SIGSTOP persists in 2.4.26-3um

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

launching UMLs with nice seems to aggravate this problem --
but it also has been seen w/o adding that irritant.

status is 0x1c7f - which maps to 0x1c (SIGWINCH	28 right?)

here it is trying to panic and generates a segfault

#4  0x08051270 in main (argc=11, argv=0xbfffd3e4, envp=0xbfffd414) at 
arch/um/main.c:148
#3  0x080dd2f4 in linux_main (argc=11, argv=0xbfffd3e4) at um_arch.c:332
#2  0x080d9154 in can_do_skas () at process.c:255
#1  0x080d9058 in stop_ptraced_child (pid=21301, stack=0x40001000, 
exitcode=1) at process.c:182
#0  0x0805628c in panic (fmt=0x81c8080 "check_ptrace : child exited with 
status 0x%x") at panic.c:67

values for locals and parameters in stop_ptraced_child are:

(gdb) print errno
$1 = 0
(gdb) print n
$2 = -1073774592
(gdb) print pid
$3 = 21301
(gdb) print status
$4 = 7295
(gdb) print exitcode
$5 = 1
(gdb) set radix 16
(gdb) print status
$6 = 0x1c7f
(gdb) print n
$7 = 0xbfff8000

also have seen:

2.4.24-1um + reboot-signals

   Checking for the skas3 patch in the host...found
   Checking for /proc/mm...found
   CONFIG_HIGHMEM not enabled - physical memory shrunk to 499122176 bytes
   Kernel virtual memory size shrunk to 32505856 bytes
   capture_stack : Expected SIGSTOP, got status = 0x1c7f


2.4.26-3um

   Checking for the skas3 patch in the host...found
   Checking for /proc/mm...found
   capture_stack : Expected SIGSTOP, got status = 0x1c7f



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

[uml-devel] No Bug Here: [Was: Expected SIGSTOP persists in 2.4.26-3um ]

[D. Bahi]

[-- Attachment #1.1: Type: text/plain, Size: 1951 bytes --]

I withdraw this error report against 2.4.26-3um
against any plain vanilla UML kernel for that matter.

I've launched 2.4.26-3um about 200 times (50 at once
even, with the script attached its easy to stress test!)
and never seen this in a kernel that we haven't modified
ourselves... still if anyone has any ideas....

Thanks for your patience.

D. Bahi wrote:
> launching UMLs with nice seems to aggravate this problem --
> but it also has been seen w/o adding that irritant.
> 
> status is 0x1c7f - which maps to 0x1c (SIGWINCH    28 right?)
> 
> here it is trying to panic and generates a segfault
> 
> #4  0x08051270 in main (argc=11, argv=0xbfffd3e4, envp=0xbfffd414) at 
> arch/um/main.c:148
> #3  0x080dd2f4 in linux_main (argc=11, argv=0xbfffd3e4) at um_arch.c:332
> #2  0x080d9154 in can_do_skas () at process.c:255
> #1  0x080d9058 in stop_ptraced_child (pid=21301, stack=0x40001000, 
> exitcode=1) at process.c:182
> #0  0x0805628c in panic (fmt=0x81c8080 "check_ptrace : child exited with 
> status 0x%x") at panic.c:67
> 
> values for locals and parameters in stop_ptraced_child are:
> 
> (gdb) print errno
> $1 = 0
> (gdb) print n
> $2 = -1073774592
> (gdb) print pid
> $3 = 21301
> (gdb) print status
> $4 = 7295
> (gdb) print exitcode
> $5 = 1
> (gdb) set radix 16
> (gdb) print status
> $6 = 0x1c7f
> (gdb) print n
> $7 = 0xbfff8000
> 
> also have seen:
> 
> 2.4.24-1um + reboot-signals
> 
>   Checking for the skas3 patch in the host...found
>   Checking for /proc/mm...found
>   CONFIG_HIGHMEM not enabled - physical memory shrunk to 499122176 bytes
>   Kernel virtual memory size shrunk to 32505856 bytes
>   capture_stack : Expected SIGSTOP, got status = 0x1c7f
> 
> 
> 2.4.26-3um
> 
>   Checking for the skas3 patch in the host...found
>   Checking for /proc/mm...found
>   capture_stack : Expected SIGSTOP, got status = 0x1c7f
> 
> 

-- 
Damn it! Morons don't learn until they die! -- Faye Valentine, _Cowboy Bebop, The 
Movie_.

[-- Attachment #1.2: uml_launch --]
[-- Type: text/plain, Size: 2369 bytes --]

#!/bin/bash 

declare -i idx= first=1

rm -rf   /local/target0/umltest
mkdir -p /local/umltest/cow
mkdir -p /local/umltest/hostfs

if (( $# < 1 )); then
    idx=1
else
    idx=$1
fi

root="/local/dbahi/root_fs.rh-9-full"
swap="/local/dbahi/swap_fs.256"
pipe="/local/umltest/pipe"

linux="/view/dmerrill_linux/ccase/linux24/src/linux"

if [[ ! -x "${linux}" ]]; then
  echo -ne "${linux}\n\nnot found or not executable!!!!\n"
  exit
fi

pause=5
mem="128M"
nice="nice"
screen="screen -DmS"
xterm="xterm -e screen -r"
tunctl="tunctl -b -u $USER"

echo -ne "\n#  Will launch $idx UML(s)...\n#\n#"
echo -ne "\n#  Launching tunctl for tap interface with command:\n#"
echo -ne "\n#     ${tunctl}\n#\n#"

tapdev=$(${tunctl})

umlxcmd="/usr/bin/uml_switch -unix ${pipe} -tap ${tapdev}"
tunrm="tunctl -d ${tapdev}"

echo -ne "\n#  Launching uml_switch with command:\n#"
echo -ne "\n#     ${screen} uml_switch -t uml_switch ${umlxcmd}\n#\n#"
echo -ne "\n#  Attaching uml_switch with command:\n#"
echo -ne "\n#     ${xterm} uml_switch\n#\n#"

${screen} uml_switch -t uml_switch ${umlxcmd} &
${xterm} uml_switch &

cur=1
while (( $cur <= $idx )); do
    umid="uml_${cur}"
    mac=$(echo "ibase=10; obase=16; ${cur}" | bc)
    ubd0cow="/local/umltest/cow/ubd0_${cur}"
    ubd1cow="/local/umltest/cow/ubd1_${cur}"
    hfsdir="/local/umltest/hostfs/host_${cur}"
    eth="daemon,fe:fd:00:00:00:${mac},unix,${pipe}"

    cmd="${nice} ${linux} umid=${umid} ubd0=${ubd0cow},${root} ubd1=${ubd1cow},${swap} hostfs=${hfsdir} mem=${mem} eth0=${eth}"

    if (( $first > 0 )); then
        first=0
        echo -ne "\n#  Launching UML with commands like:\n#"
        echo -ne "\n#     ${screen} ${umid} -t ${umid} ${cmd}\n#\n#"
        echo -ne "\n#  Attaching UML with commands like:\n#"
        echo -ne "\n#     ${xterm} ${umid}\n#\n#"
        echo -ne "\n#  Use the following to shutdown:\n\n\n"
        echo -ne "pkill uml_switch\n\n"
    fi
    echo -ne "uml_mconsole ${umid} halt"

    mkdir -p ${hfsdir}
    ${screen} ${umid} -t ${umid} ${cmd} &
    ${xterm} ${umid} &

    if (( $cur < $idx )); then
        echo -ne "    # pausing .";
        slept=0
        while (( $slept < $pause )); do
            sleep 1
            echo -ne "."
            slept=$((slept + 1))
        done
    fi
    echo -ne "\n"
    cur=$((cur + 1))
done

echo -ne "\n$tunrm\n"

echo -ne "\n\n#  Done.\n"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [uml-devel] No Bug Here: [Was: Expected SIGSTOP persists in 2.4.26-3um ]

[Jeff Dike]

dbahi@enterasys.com said:
> I withdraw this error report against 2.4.26-3um against any plain
> vanilla UML kernel for that matter. 

Is it possible you were mistaken about the versions, or whether the 
reboot-signals patch was present?

				Jeff



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] No Bug Here: [Was: Expected SIGSTOP persists in 2.4.26-3um ]

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

no sir. the versions were correct. and the reboot-patch was applied
to the 2.4.24-1um kernel - this i originally reported as fixed, but
in later runs it showed up again... sigh.

the errors reported were those versions w/patches mentioned + all
our mods. more recent testing with just kernel.org + UML leads
to believe this is something we're inducing... so should not be
reported against what everyone else is playing with.

Jeff Dike wrote:

> dbahi@enterasys.com said:
> 
>>I withdraw this error report against 2.4.26-3um against any plain
>>vanilla UML kernel for that matter. 
> 
> 
> Is it possible you were mistaken about the versions, or whether the 
> reboot-signals patch was present?
> 
> 				Jeff
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [uml-devel] No Bug Here: [Was: Expected SIGSTOP persists in 2.4.26-3um ]

[D. Bahi]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

here is the last bread crumb trail i can think of -

we're loading modules with our stuff and i wasn't loading modules
in the kernel.org + UML massive launches.

it seems in our stuff that mem=1024 leads, not only to more
frequent encounters of launch SIGSTOP, but also, runtime
random kernel panics (stack overflow) (unhandled irq). (we used
to use mem=512 with 2.4.24-1um (it wouldn't do HIGHMEM either)).

light bulbs?

(i'm going to try building some modules for the vanilla stuff
but there have to be others out there using modules in their
UMLs --- is anybody else seeing these?)

D. Bahi wrote:

> no sir. the versions were correct. and the reboot-patch was applied
> to the 2.4.24-1um kernel - this i originally reported as fixed, but
> in later runs it showed up again... sigh.
> 
> the errors reported were those versions w/patches mentioned + all
> our mods. more recent testing with just kernel.org + UML leads
> to believe this is something we're inducing... so should not be
> reported against what everyone else is playing with.
> 
> Jeff Dike wrote:
> 
>> dbahi@enterasys.com said:
>>
>>> I withdraw this error report against 2.4.26-3um against any plain
>>> vanilla UML kernel for that matter. 
>>
>>
>>
>> Is it possible you were mistaken about the versions, or whether the 
>> reboot-signals patch was present?
>>
>>                 Jeff
>>
> 

-- 
Damn it! Morons don't learn until they die! -- Faye Valentine, _Cowboy Bebop, The 
Movie_.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]