Problems with serial console on a i386 machine

Hi y'all!

We use a SBC with a Geode CPU (i386 compatible) and now wanted to switch off VGA console support (and the onboard graphics as well). As a console can be handy sometimes, we planned to use a serial console and built a kernel (2.4.20 with PPSKit patches) supporting this.

Now, when we boot the system everything works fine, console messages can be read over the serial port, but when the kernel finished its first initialization and init bangs in, the serial output begins to crawl.

After every 16 characters the output sleeps for approx. 10 seconds, this leads to a boot up time of 15 minutes (compared to less than 1 minute with a VGA console enabled).

Afterwards the system runs with normal speed, but everytime I try to output something on the serial port I use as a console, the output is as slow as described above.

We wonder if this is a problem with the signal pins or something like that. We tried ZOC as a terminal program as well as one or two others without a change.

If we do not use the serial port as a console, it works flawlessy.

It would be great if anyone could point us into the right direction.

Thanks in advance, kind regards,

Heiko

--
Meinberg radio clocks: 25 years of accurate time worldwide

Meinberg Radio Clocks
 Click to see the full signature
Reply to
Heiko Gerstung
Loading thread data ...

This is a known interrupt problem with the serial interface of ELAN CPUs and there is a serial driver setting (or another driver source code) that works around this.

Perhaps the Geode has the same bug.

-Michael

Reply to
Michael Schnell

Hi Michael,

thank you for your reply. We applied the patch to our kernel version, without improvement. We used setserial to change the uart setting from

16550A to 8250 and then the 10s pause happens after each single char, because of the non-FIFO situation we caused by using a 8250.

This really seems to be an interrupt problem. Interesting fact: Everytime we enable the onboard VGA graphics of our board, the serial port seems to work without problems. The delay only happens when no VGA adapter is existing in the system.

Any ideas what could cause this?

Thank you in advance, kind regards, Heiko

Michael Schnell wrote:

--
Meinberg radio clocks: 25 years of accurate time worldwide

Meinberg Radio Clocks
 Click to see the full signature
Reply to
Heiko Gerstung

I've had a similar problem where things stopped working when I removed the VGA adapter. I figured out that the init scripts were continuously trying to start the agetty process on the virtual terminals that are normally used when a VGA adapter is present. In inittab the process was using respawn, so init will continuously try to start these processes. I ended up editing my inittab to remove these entries and things started working after that. Might be worth trying.

Mark

Reply to
Mark

Is there a tty0 device node on your system? Mine lacked that one, i created it (per the manual) like so:

mknod -m 622 tty0 c 4 0

But maybe you just need to remove /etc/ioctl.save before reboot. And as Mark sugested try and edit /etc/inittab to disable any getty(s) otherwise respawn on tty[1-6].

Using BusyBox as init , i have this:

$ su -c 'grep -A1 serial /etc/lilo.conf' Password: # LILO serial console, kernel serial console serial = 0,9600n8 append = "console=ttyS0,9600n8" $ grep respawn /etc/inittab |grep -v -e ^$ -e ^# ::respawn:/bin/login ::respawn:/sbin/getty -L ttyS1 9600 vt102 $

Note, no getty on ttyS0 just a "login" process, as the kernel is told to use ttyS0 as console - in runlevel 1 - it "just works". In any other runlevel, a getty would be needed.

The getty i /do/ have running (on ttyS1) is just so i get a login prompt, no matter which serial-port i happen to connect my null-modem cable to ...

Also, i have had odd things happen if the serial-console settings of any bootloader (Lilo, Grub, Syslinux) differed from the kernel or getty ones. To avoid that rearing again i use 9600n8 as the _only_ setting(s).

formatting link

HTH.

--
-Menno.
Reply to
Menno Duursma

Hi Mark,

thank you for your reply. We already removed all inittab entries covering the getty processes for all serial and virtual ports, without success. As the systems performance is normal after bootup (where it is dead slow because of the delays occuring when printing out something on the serial port) and because top does not show any cpu consuming processes, it seems to be an interrupt problem.

Another indication is the fact that if we "switch off the FIFO" by setting the port type to 8250, the pause occurs after each char (not after 16 chars).

Any other ideas? I already tried to apply the interrupt handling patch for the AMD ELAN cpu architecture, where a similiar error has been found (in the hardware, not in the serial driver), but this patch did not fix the problem.

Kind regards, Heiko

Mark wrote:

--
Meinberg radio clocks: 25 years of accurate time worldwide

Meinberg Radio Clocks
 Click to see the full signature
Reply to
Heiko Gerstung

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.