Skip to contentSkip to conversation

Expected SIGSTOP persists in 2.4.26-3um

uml-devel D. Bahi 2 participants 5 messages Aug 17, 2004 – Aug 19, 2004 User-mode Linux (UML)

lore
Share & tools
lore

D. Bahi

author
#0 lore raw

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

author
#1 lore raw

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

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.

Quoted 49 lines · D. Bahi

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

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

#!/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"

#2 lore raw

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

Quoted 2 lines · [email protected] 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 [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

author
#3 lore raw

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

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.

Quoted 10 lines · Jeff Dike
Quoted 2 lines · [email protected] 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

author
#4 lore raw

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

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?)

Quoted 23 lines · D. Bahi

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.

Quoted 11 lines · Jeff Dike
Quoted 2 lines · [email protected] 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

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