stty crtscts < /dev/ttyS1
derobert at erols.com
Mon Apr 10 03:42:42 EST 2000
At 9:08 AM -0800 on 4/8/00, Greg Noel wrote:
>At 8:35 PM -0400 on 4/7/00, Giuliano Pochini wrote:
>>I don't know why this happen exactly. It seems that the printer changes
>>continuosly with very high frequency the state of CTS, which cause the
>>serial driver to loop indefinitely.
>At 12:05 AM -0400 4/8/00, DeRobertis replied:
>>Ouch! Broken hardware... how can I document this is happening, so that
>>I can demand an answer from Epson?
>From your messages, it's not clear to me that it's the printer. It could
>easily be the cable. Try replacing the cable with one that only connects
>the signals you're using and properly grounds all the other signals.
It's a Mac DIN-8 (I think that's the name) cable; I don't believe there
are any unused signals. And pulling the printer off the remote end or
the cable out of the local end both unfreeze linux. Same with turning
off the printer.
>>Or maybe I should just hack the serial driver to ignore this. And WTF
>>is the serial driver doing looking at CTS on a port with no data?!
>If there are multiple ports, it may not be possible to disable a specific
>interrupt for an individual port, so it always has to be enabled in case
>any port needs it. That was the case with the hardware I had.
Same hardware does not kill the MacOS -- even when it's using the port.
Seems like a Linux problem.
However, I've come up with something interesting -- to run a Mac serial
port at the speed the printer's docs say it can (1.8Mbps), you need
external clocking... more on this in another message.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev