Mageia forum

Has something changed drastically in the recent kernels re: serial port handling?

Under MDV 2010.2, I was getting >60 updates/second talking to a megasquirt2, (@115200), was working OK under Mageia 1, (didn't notice an issue but not benchmarked) and under Mageia 2 I start having serial port overruns if I set the updates higher than 25/sec. (That's max throttled, next choice is unlimited, which produces endless streams of garbage w/default setup)

Hardware is unchanged (Pentium M laptop GM855 with dedicated ATI graphics (not shared mem))
Apparently has 16550As, going by setserials output.

I've tried reducing the fifo size to 1 in 8250.c (recompiled kernel), tried setting the clocks to 100/300/1000 and turned tickless on with nohz=1, the latter helps quite a bit, the 1 byte FIFo seems to help less than it should, as tuning that under XP can change the data rate from <30->60+ FPS.

setserial is run in the rc.local with the low_latency spd_vhi options to no avail.
irq4 is only used by serial ttyS0/ttyS2, and ttyS2 is not used. (It is connected to a winmodem, but it's not used)
I don't THINK I'm missing any of the usual tricks, so what am I missing?

I have the rt-kernel loaded up and will try to prioritize irq4, but this seems all rediculous as Linux has always worked better for me esp on serial comms.


Help!

The issue was the removal of proper CPU profiles in KDE, setting /etc/sysconfig/cpufreq GOVERNOR=performance solved the issue.

Apparently the default "ondemand" govenor may not consider irq traffic, so the overruns where happening when the CPU was transitioning back/forth to 600MHz, and the cpu could no longer keep up with the serial port generated irq traffic.

Mageia2 seems to currently lack the kernel.org tools (cpufreq-info etc) or any userspace tools(?) to change this easily, so I'll leave it like that for the time being, but a nice userspace tool to change this from scripts or such would be a Good Thing.

I'll take a look at the ondemand govenor and see if it can be made to care about IRQ usage easily, but that's bordering on heavy voodoo.

Looks like cpufreqd is perfect, can change the policy based on many variables, including running programs, so for example if TunerStudio is running, CPU clock will scale to max to avoid serial overruns.
.
Also happens to be part of Mageia2...

10 thumbs up for cpufreqd, works excellent, also works as expected, and easily configured, should be the default.

I simply added java to the "Movie Watcher" performance profile and tweaked the thermal triggers to match my systems cpu temp range in /etc/cpufreqd.conf ... very simple.

Great it works, and thanks for keeping us updated.

FWIW, could you post your changes so that others can take a look, please?

I have been doing some more work on it, compiling the kernel (as std) with "NO_HZ" , low latency desktop, also 1000 hz as an option, and changing one line in /usr/src/linux/drivers/tty/serial/8250/8250.c (Also set it to "PentiumM" FWIW, as that is correct for this old laptop)

Code: Select all

-                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+                .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_00,


The speedup/reliability improvement here is SOLEY due to the fact that I'm talking to a microcontroller which has a 3 wire serial connection, RX/TX and ground, so it uses softtware flow control.

On a device where you have proper hardware flow control, the FIFO buffers are typically a win.
The "00" sets the "FIFO" to a single bit, but on SW flow control, when it changes from send to recieve, data in the FIFO should be expected to be lost.

On WinX typical 16550A drivers allow you to set this in the config with a slider, but I digress.

This has not completely restored the data rates I once enjoyed, but I no longer see any overruns, it IS faster, and most of all I don't lose/corrupt data, even when allowing the CPU to run at 600 MHz, CPU utilization with TunerStudio running minimized is in the noise.(~same as idle, just does periodic I/O to write datalogs if logging)

nohz=yes on the kernel comand line at boot seems to work best on this SW/hardware combo, YMMV.

I still like the control of cpufreqd, and am still using it, although I removed Java from the "MovieWatcher" entry, as the faster/power sucking CPU no longer seems to make a difference with the nohz on and the buffer size set to 1 bit.

Thanks for the feedback, maybe it helps other who have similar problems

Bringing this back up as it has gotten unbearable.

Linux serial drivers have gotten some extensive rework lately, and the performance has gotten FAR worse.

Even with the kernel patched to set the fifo to 1 bit, the sw flow control serial performance with S12x microcontrollers has constant dropouts, producing garbage.

I basically now have to dual boot Mandriva 2010.2 to get any actual work done, as the current kernels (even patched and with optimized configs/recompile) are useless.

Then please report this as a bug: https://wiki.mageia.org/en/How_to_report_a_bug_properly

I have heard of great performance with the lowlatency setting,
have you tried it?

http://linux.die.net/man/8/setserial

setserial is obsolete, or at least the good features. apparently.

I also bought a couple faster Core2 based laptops, which helped.
With the better USB<>serial converters like FTDI is becomes a non-issue.

Serial performance has actually been working ~awesome lately with the cauldron w/daily updates up to MGA3 release, but I cannot even access serial ports after doing a clean install from the release, must be some sort of silly permissions issue again, user is set as member of dialout, and /dev/ttyUSB0 is owned by root.dialout, etc...

I think I had to set up an init script to run at boot to set run/lock to the proper ownership to allow use of rxtx, but I blew it away with the fresh install, and I have slept since then.

Edit: Had to create /etc/rc.d/rc.local and chown/chgrp to 775/uucp (or something NOT root and safe to add a user to) so serial lockfiles can be used by non-root users.
(you can still use rxtx-nolock, but the software frequently bangs it's head checking for /var/lock access and borks anyway)

the systemd rc-local service runs by default at boot.