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 -- http://mail.python.org/mailman/listinfo/python-list
