Re: Sentris 650 serial ports
> >Blabbing about problems
> >with the 'undefined' serial here won't do anything beyond pointing out you
> >don't understand the problem.
>
>
>
> Once again Michael, you need to take a course in 'How to Win Friends
> and Influence People'.
I neither want to win friends here, nor influence people. I've heard that
myth about how the 'undefined' message from setserial is a symptom of some
breakage of users or kernel space code one too many times. Wait, make that
ten too many times. It's all in the list archives, I've explained it
numerous times, why doesn't anybody listen?
OK, message repeats:
1) setserial's 'undefined' message is broken. setserial assumes it can
probe for Intel style hardware regardless of the architecture it was
compiled for. Someone please take a minute to file a bug report, or cook
up a patch. It might even be fixed in the setserial version in potato.
I've found no mention of this 'bug' in the Debian bug tracking system, so
it seems even those that complained here didn't consider it enough of a
bug to report it?
2) this 'bug' is of no consequece whatsoever for the normal functions of
setserial (setting speed handling, locking). These functions reside in the
kernel serial driver. One of the functions of the kernel is to present a
uniform interface to access serial hardware independent of its specific
hardware implementation, remember? As a result, the same user space
program can be used to access serial interfaces on Amiga, Atari, Mac and
so on, without any special case handling. So if there's a bug, it's
not related to setserial (I don't hear Amiga or Atari users complain).
Incorrect serial parameters or a kernel driver bug come to mind.
Attempts to set the baud base or custom divisor may fail to produce the
expected results on SCC hardware. There was a special SCC version of
setserial (setSCCserial) written for that purpose.
3) there's another tool to control the serial behavior (rather that of the
tty layer using the serial hardware but these are hard to separate). Use
stty -F /dev/ttyS0 -a to learn about the current settings of the ttyS0
line. Setting crtscts or -clocal will result in problems with serial
cables without hardware handshake or modem control lines.
4) I can't remember having problems with the Mac serial driver but that's
a year or so back, and I've not used minicom or a modem. I've mostly used
it for SLIP networking. If someone can give a more detailed description
where access to the serial port fails, and evicence points to a failed or
blocked system call (strace is your friend), I'd consider calling it a
kernel bug. Otherwise, I'd have to call it user error, and recommend
reading the various serial HOWTOS. If someone is interested in hacking on
the kernel driver I can offer some advice. Having no Mac and no spare time
for Mac hacking, that's all I can offer (aside from giving lengthy
explanations why it's not setserial's fault).
Message ends.
As a side note: Mac users please try setserial -F /dev/ttyS[0,1]
low_latency and check if serial throughput during disk activity improves.
> Please take your elitist attitude down a notch (or three). We know
> you can do better.
Huh? I thought elitist attitude is what m68k (and Mac) is all about?
Michael
Reply to: