I have some more info, and it's pretty weird. APC says, and my
experience seems to confirm it, that you need a different serial cable
for Unixy systems than Windows. And if you want to dual boot, well,
that's just too bad.
Unix, they say, is putting a voltage on a pin that the UPS detects and
takes as a shut down signal. APC says this is a feature for people
who don't have computers (e.g., you're powering some alarms).
So this configuration fails (that is, powers off immediately on loss
of power):
serial cable connected. apcupsd removed. Linux running.
And this "works":
Serial cable disconnected from serial port (but still in the UPS).
apcupsd removed. Linux running.
Now, it seems to me that there must be a software solution to this,
since clearly the hardware works OK under windows.
Independent of this, the "LSR safety check engaged" indicates
something is wrong with that serial port and my setup. I get the
message even when the cable is out of the port.
Pigeon, thanks for the info, though I only sort of understand it. I'm
comfortable programming, but I don't know how to access the device
registers under Linux.
Perhaps there some way to hack serial.c to solve this? Or, better,
some way to communicate with the driver? I've looked, and can't find
any description of options for this driver. Judging from the
comments, it enables FIFO, which I think is the opposite of XON/XOFF;
at any rate APC said I should disable FIFO.
I thought XON/XOFF was hardware flow control...
On Thu, Jan 23, 2003 at 03:02:38PM +0000, Pigeon wrote:
> On Wed, Jan 22, 2003 at 06:08:59PM -0800, Ross Boylan wrote:
> > I disconnected the serial cable from the UPS to the PC, and apt-get
> > remove apcupsd. Now when I pull the UPS plug from the wall the
> > computer keeps going. Progress, though of course it no longer has a
> > way of knowing the power has failed.
> >
> > When the system was on with the cable connected the green LED on the
> > UPS was off. It went back on as Linux shutdown. With the cable
> > disconnected, the LED stays one. This tends to support theory #2
> > below.
> >
> (Theory 2 was:)
> > > 2) The UPS detects that communication has failed and shuts down. The
> > > problem with this theory is that the UPS uses simple (dumb) signalling:
> > > messages only go from the UPS to the computer. So there doesn't seem
> > > to be anyway the UPS would even know there was a problem.
> >
> > I'm not quite sure what to do with this theory. APC says the port
> > needs to be set for 2400 bps with FLOW XON/XOFF. setserial stores
> > some configuration, namely /var/lib/setserial/autoserial.conf (I have
> > no /etc/serial.conf)
> > /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test
> >
> > setserial seems to have no XON related options, and, as I understand
> > it, doesn't actually set the hardware. /proc/isapnp shows my
> > modem (which uses a serial port) and sound card, but I don't see
> > anything for the serial ports themselves. How do I configure them?
> > (lspci also doesn't show serial ports).
>
> Messages only go from the UPS to the computer... but the UPS clearly
> receives something FROM the computer, which affects its LED... and
> you're supposed to use XON/XOFF ("software") flow control.
>
> My guess is that the UPS is using the hardware flow control signals
> (RTS etc) to determine whether or not the computer is switched on;
> Linux initialises these differently from Windoze; and the UPS
> therefore thinks that the computer is not switched on, and doesn't
> bother to provide power when you kill the mains.
>
> So, you could try programming the hardware flow control lines high or
> low, and seeing which one makes your green LED go on and off. You
> could then write a script to set the relevant line to its proper state
> and call it at bootup.
>
> For the experimenting bit, I'd use DEBUG in DOS, so you can experiment
> by pulling the plug and not have all that fscking around if it doesn't
> work. How to do it in Linux, from a script, without writing any C, I'm
> afraid I don't know. The C code would be very simple though!
>
> Serial port register definitions attached.
>
> Pigeon