Reboot anomaly - VxWorks

This is a discussion on Reboot anomaly - VxWorks ; My organization has recently upgraded from VxWorks 5.2 to VxWorks 5.5 on our MV2700 boards. An anomaly with entering "reboot" to the shell has been noted. It takes two entries of "reboot" to actually get the processor to reboot. After ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Reboot anomaly

  1. Reboot anomaly

    My organization has recently upgraded from VxWorks 5.2 to VxWorks 5.5
    on our MV2700 boards. An anomaly with entering "reboot" to the shell
    has been noted. It takes two entries of "reboot" to actually get the
    processor to reboot. After the first, the system appears to be in an
    odd state, with interrupts off (?) but some tasks still running. You
    can type the second "reboot" if you are on the serial console, but not
    if you were logged into the shell via telnet. Are "reboot" and ^X on
    the shell identical? How does a warm boot differ from a cold boot
    (power reset)? Thanks in advance for your help.

  2. Re: Reboot anomaly

    On Mar 19, 4:46 am, Chris wrote:
    > My organization has recently upgraded from VxWorks 5.2 to VxWorks 5.5
    > on our MV2700 boards. An anomaly with entering "reboot" to the shell
    > has been noted. It takes two entries of "reboot" to actually get the
    > processor to reboot. After the first, the system appears to be in an
    > odd state, with interrupts off (?) but some tasks still running. You
    > can type the second "reboot" if you are on the serial console, but not
    > if you were logged into the shell via telnet. Are "reboot" and ^X on
    > the shell identical? How does a warm boot differ from a cold boot
    > (power reset)? Thanks in advance for your help.


    CTRL-X and reboot have largely the same effect. With CTRL-X, I think
    the reboot is actually triggered from interrupt context (the ISR that
    handles serial port interrupts dispatches the reboot event directly)
    whereas typing reboot from the shell causes the reboot() routine to be
    called directly from the tShell task context.

    As for the difference between a power cycle or hard reset and
    reboot(), the latter isn't really a reboot. When you do a warm boot in
    VxWorks, it eventually calls sysToMonitor() in the BSP, and what that
    usually does (it varies a little depending on the BSP) is turn off the
    caches and then jump back to the warm reset entry point in flash or
    ROM. Typically, this is the entry to the VxWorks bootrom, though it
    could be entry point to a VxWorks ROMable image instead. The important
    difference is that reboot() doesn't actually cause a CPU reset: it
    basically just does a very long 'goto' back to the start of the
    bootstrap code (bootrom or VxWorks ROMable image).

    (If you really want to have reboot() to a real reboot, then you need
    to modify your BSP's sysToMonitor() function in sysLib.c. The ability
    to actually trigger a CPU reset may depend on CPU-specific or board-
    specific features. With the Intel x86 family, there's an easy way to
    trigger a CPU reset: you deliberately trigger a triple fault. With
    PowerPC, there's no simple way to do it. Very often a given board will
    have an FPGA with a special register you can poke that will strobe the
    hard reset pin on the processor.)

    One of the things that reboot() also does is call a set of reboot
    hooks. These can be added to a reboot hook list using rebootHookAdd()
    (which is part of rebootLib). I'm pretty sure that one of the reboot
    hooks that's added is for muxDevStopAllImmediate(). This function is
    supposed to do a muxDevStop() on all network interfaces attached to
    the MUX. This may be the source of your problem. If you're trying to
    do a reboot when logged in via telnet, reboot() will ultimately call
    muxDevStopAllImmediate() via the reboot hook mechanism, which will try
    to do a muxDevStop() on the very interface that you're logged in
    through. There may be a deadlock condition here, since the driver's RX
    handler routine will be executing in tNetTask: if the driver's stop
    routine does something that might collide with the RX handler, you'll
    be blocked against yourself.

    What you might try doing instead is:

    -> sp reboot

    This will spawn a separate task and invoke the reboot() function in
    another context. This may prevent the network driver from deadlocking
    with itself.

    Note that it's technically a bug to install muxDevStopAllImmediate()
    as a reboot hook. Per the documentation, reboot hooks are not allowed
    to call blocking OS routines, but muxDevStop() and muxDevStart() are
    not restricted in this way.

    -Bill

+ Reply to Thread