RE: VxWorks VME Ctrl-X vs. Power Cycle

[Mark Rivers <rivers@cars.uchicago.edu>]

The APS adapter works with cards like the MVME6100.  We just "Tee" the RS-232 transmit line (host to VME CPU line) and run it both to the VME CPU console port and to the APS adapter card.

I've found it essential to working on vxWorks crates that are hard to access.

Mark

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Matt Rippa [mrippa@gemini.edu]
Sent: Friday, March 21, 2014 4:13 PM
To: Andrew Johnson; tech-talk@aps.anl.gov
Subject: Re: VxWorks VME Ctrl-X vs. Power Cycle

Hi Andrew,

On 03/21/2014 10:37 AM, Andrew Johnson wrote:
> Hi Matt,
>
> On 03/21/2014 02:21 PM, Matt Rippa wrote:
>> I have an MVME6100 with Epics 3.14.12.2 running vxWorks 5.5.
>> Sometimes when testing changes to a new vxworks kernel or just
>> an update to a new epics module, my shell stops hard, and Ctrl-x
>> doesn't work. Power cycling is my best friend in that case, but
>> is it my only option?
>
> Does hitting the VME Chassis reset button rescue you from those hang-ups?

Yes, most times this works. But not always.

>> Can a modified reboot handler help with any of these occurrences?
>
> I think by the time the CPU has frozen it's going to be too late, unless
> a VMEbus reset does work and you can arrange for some way to trigger it
> remotely.

> Here at the APS we connect to most of our VME console ports through a
> locally-designed adapter board which monitors the serial line for a
> particular key sequence (usually Ctrl+Y three times in a row). When it
> sees that, it pulses the VMEbus reset line, which is usually enough to
> restart most frozen systems. If we're unlucky we might have to send
> someone to walk out to the crate to power-cycle it, but that's fairly rare.

That's what I thought. My cases are fairly rare too.

The adapter sounds quite useful. Would this type of design work
with the MVME-6100 board which doesn't use the VME backplane for
serial communications? In my case though, it seems like a
tougher sell than adding a network bootbar.

> The other thing I would recommend is that you examine all of your
> drivers for cards that use interrupts, and make sure that they all
> register a reboot hook routine (or an epicsAtExit one) that disables the
> interrupt on the card. In my experience the main reason for systems
> freezing over a reboot is that they leave an interrupt line asserted,
> and that prevents the OS from coming back up properly.

Oh, good to know. I have a few periphery boards and will see if
this applies.

> HTH,
>
> - Andrew
>

Thank you,
-Matt