lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 20 Jan 2007 23:07:38 -0800 From: "H. Peter Anvin" <hpa@...or.com> To: Joe Barr <joe@...rimer.com> CC: Linux Kernel mailing List <linux-kernel@...r.kernel.org> Subject: Re: Serial port blues Joe Barr wrote: > I'm forwarding this post by the author of a great little program for > digital amateur radio on Linux, because I'm curious whether or not the > problem he is seeing can be resolved outside the kernel. > > All comments welcome on/off list. > > Thanks, > Joe Barr > K1GPL [...] > > I've spent the last day staring at the oscilloscope and pins RTS and DTR > on the serial output for 4 different computers running 4 different > versions of Linux. Also have exhausted the search on the internet for > information regarding both the latency and jitter associated with ioctl > calls to the serial driver (both ttyS and ttyUSB). I'm sure it is out > there somewhere, I just cannot find it. > > I am now convinced that the current serial port drivers available to us > on the Linux platform WILL NOT support CW and/or RTTY that is software > generated in a satisfactory manner. > > To test the latency and jitter of the ioctl calls to set or clear RTS > and / or DTR I built a basic square wave generator with microsecond > timing precision. The timing could be derived either from the select > system call or by controlled i/o to the sound card. Both provide very > precise timing of the program loop. Each time through the loop either > the RTS/DTR was set or cleared. The timing jitter for each 1/2 cycle > was from 0 to +4 msec. This varied between systems as each had > different cpu clock rates. The jitter is caused by the asynchronous > response of the kernel to the request to control the port. ioctl > requests apparantly do not have a very high priority for the kernel. > They are probably just serviced by a first-in first-out interrupt > service request loop. That type of jitter is tolerable up to about 20 > wpm CW. It totally wipes out the ability to generate an FSK signal on > the DTR or RTS pin. Okay, here he's using bit-banging of the DTR and RTS pins to generate a fairly high precision output wave. This is not really the > Direct access to the serial port(s) is a kernel perogative in Linux. > Only kernel level drivers are allowed such port access. So write a kernel driver. It's not like we're locking anybody out. There is certainly enough Amateur Radio/Linux crossover that a kernel enhancement to support Amateur Radio is going to get frowned upon. > So ... bottom line is that all of my attempts over the past couple of > months to provide CW and / or FSK output signal have been to fraught > with pitfalls. The CW seems OK for slow speed keying, but the FSK seems > impossible to achieve. > > The FSK using the UART is also limited by the Linux operating system and > the current drivers. That limitation excludes the use of 45 or 56 baud > BAUDOT. That is true at the moment (due to unfortunate design choices made early on), but this is already in the process of being changed: http://lkml.org/lkml/2006/10/18/280 > Until such time as new information becomes available I am going to > comment out all references to CW and / or FSK via RTS/DTR. I also > question how useful the FSK on TxD (UART derived) might be to most users > since the 45.45 baudrate is not available in the serial port driver. > That function will also be commented out. > > All this should not really come as a surprise since Linux is not a > real-time operating system. By the way, I did try the tests with the > test program running with nice -20. Not much difference. See again how he should be using real-time priority rather than nice -20. > Sorry folks, but we win some and lose some. > > 73, Dave, W1HKJ -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists