Intermittent Failure on Serial Port

[H J van Rooyen]

Serge Orlof wrote:

| H J van Rooyen wrote:
| > Serge Orloff wrote:
| >
| > | H J van Rooyen wrote:
| > | > Traceback (most recent call last):
| > | >   File "portofile.py", line 232, in ?
| > | >     ret_val = main_routine(port, pollstruct, pfifo)
| > | >   File "portofile.py", line 108, in main_routine
| > | >     send_nak(port, timeout)      # so bad luck - comms error
| > | >   File "/home/hvr/Polling/lib/readerpoll.py", line 125, in send_nak
| > | >     port.flush()
| > | > IOError: [Errno 29] Illegal seek
| > | > close failed: [Errno 29] Illegal seek
| > | >
| > |
| > |
| > | > Where can I find out what the Errno 29 really means?
| > | > Is this Python, the OS or maybe hardware?
| > |
| > | It is from kernel: grep -w 29 `locate errno`
| > | /usr/include/asm-generic/errno-base.h: #define   ESPIPE          29
| > |  /* Illegal seek */
| > |
| > | man lseek:
| > |
| > | ERRORS:
| > |         ESPIPE fildes is associated with a pipe, socket, or FIFO.
| > |
| > | RESTRICTIONS:
| > |         Linux  specific  restrictions:  using  lseek  on  a  tty device
| > | returns ESPIPE.
| >
| >
| > Thanks for the info - so the Kernel sometimes bombs me out - does anybody
know
| > why the python flush sometimes calls lseek?
|
| I thought it was your own flush method. If it is file.flush method that
| makes the issue more complicated, since stdlib file.flush doesn't call
| lseek method. I suggest you run your program using strace to log system
| calls, without such log it's pretty hard to say what's going on. The
| most interesting part is the end, but make sure you have enough space
| for the whole log, it's going to be big.

Thanks - I will research and use the strace - havent used it before - I have
about 30 gig disk space left...
Trouble is that the silly thing works for anything from some hours to some days
before it falls over - ugly...
Will bleat again when I have some more results...

In the meantime I have a datascope attached to the line, and it appears as if it
was on the point of sending a nak in response to a perfectly well formed
message - almost as if either an interrupt was missed - unlikely at 9600 baud
and a pentium 3 at some 2 GHz - or there is a weird hardware error - also
unlikely - hardware normally just breaks, does not work for millions for chars
and miss one... - I dont like the implication...

I also dont really understand the second reference - to a close that failed -
anyway we have to wait for the trace...


- Hendrik