[Nut-upsuser] Cyberpower/powerpanel error: Data stale
kjell.claesson at epost.tidanet.se
Thu Oct 30 08:01:04 UTC 2008
Den Wednesday 29 October 2008 22.16.47 skrev Arjen de Korte:
> Citeren Kjell Claesson <kjell.claesson at epost.tidanet.se>:
> > The driver looks OK, and changing the timing (delays) in it is not going
> > to help.
Hm, maybe I'm wrong this time too. The answer is about 120 mS and the delay
for answer in the read-buf is 250 mS, then a respond delay (sleep) of 200 mS.
So 250-120=130+200=330 mS
So the ups have about 330 mS to respond. This should be more than enough,
but I have seen slower equipment.
> There is one slight problem in it. The ser_get_buf_len() that is used
> will not differentiate between 'no characters read' and 'not enough
> characters read'. It will either return the requested number of
> characters or '-1'. This fooled me once again, so I think I will
> rework that part. Lines 382 - 385 in powerp-bin.c are basically a
> no-op now.
Yep, it fooled me too. It say in new-drivers.txt
"Like ser_get_char, but this one waits for buflen bytes to arrive,
storing all of them in buf. The buffer is zeroed regardless of success
or failure. It returns the number of bytes read or -1 on failure,
including a timeout."
And reading it the right way, it say 'if buflen bytes not read = fail, clear
buffer, return -1'.
But I read 'If something is read but not buflen on timeout = return bytes read
and clear buf, return -1 if buf empty'
> I think the best way to fix this, would be to change the
> ser_get_buf_len() function in serial.c, as other drivers also seem to
> expect that on timeout the number of characters actually read are
> returned as well. I'll check with the other drivers that use this
> function (and possibly others as well). I guess most drivers will
> already check if the returned number of characters is what they
> expect, so this should have little impact.
Yes it may help debugging communication errors like this.
The serial driver for bcmxcp would not be broken by this, but
I have not checked the other drivers.
> Something similar should be done for partial sending of data, although
> here quite a couple of drivers don't seem to bother checking the
> return code of the ser_send_* functions at all.
Hm, bcmxcp_ser.c is one ;-(
Use it for retry, but the driver gives no error on fail, that is not good.
More information about the Nut-upsuser