Problem solved with revert of 2.6.25.2 version of 8250 driver. The
attached patch reverts only the section that had the negative effect on
DM6446.
Mark
Mark Lokowich wrote:
We also got a flaky console after upgrading from 2.6.25 git to 2.6.26
git. The #ifdef 0 portion of the patch helps me get a useable log-in,
but I'm still missing kernel prints in the init process. These get
"kicked" to the console with a few keyboard taps allowing me to
finally get a prompt. I also integrated some of Sudhakar's patches of
8/7 that move the serial platform device into the board module,
suspecting some initialization issue, but the console still flaky.
Any help?
Mark Lokowich
Advanced Communication Design
Rajashekhara, Sudhakar wrote:
Kai,
I have attached a patch which I had used to overcome similar problem
in kernel version 2.6.19 from GIT. This patch will not directly apply
on the latest kernel, but you can manually do the modifications by
going through the patch. Check whether this solves your problem.
Regards, Sudhakar
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Kai Fischer
Sent: Monday, June 16, 2008 8:57 PM
To: [email protected]
Subject: Re: Problem with serial console
Hi,
Unfortunately this did not fix the problem.
I investigated it a little further by sending some text to
/dev/console from my remote shell:
cat /proc/interrupts | grep serial
40: 36 AINTC serial
echo hello > /dev/console
cat /proc/interrupts | grep serial
40: 36 AINTC serial
Nothing happens on the console, which is pretty obvious, since no
serial interrupt occured after the echo command.
But pressing the enter key on the serial console somehow triggers the
interrupt and "hello" finally shows up there.
Another cat /proc/interrupts gives
40: 41 AINTC serial
I am afraid that further investigation will mean to debug the kernel.
Any other suggestions?
Best regards,
Kai
-----Ursprüngliche Nachricht-----
Von: Andrew Goeldner [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 16. Juni 2008 12:25
An: Kai Fischer
Cc: [email protected]
Betreff: Re: Problem with serial console
I had a similar problem, to fix it I had to mknod a console.
This had to be done as part of the boot as I could not log on!
Apologies if my terminology is not quite right - I am new to
this, but here goes
in /etc/inittab, I already had the lines
=======================================
# This line provides a nice out-of-box experience. For
regular use, you # should replace it with the proper getty
lines below.
con:2345:respawn:/sbin/getty console
=======================================
I added the following lines in
/etc/rc.d/init.d/rcS
====================
mknod /dev/console c 4 64
mknod /dev/ttySER c 4 64
chmod 666 /dev/console
chmod 666 /dev/ttySER
=====================
This allowed the console to run, and afterwards I could
delete the lines added to rcS. You should be able to do this over ssh.
I am not sure if this release has changed something about
device nodes - I am still having some problems with mounting
compact flash drives over the USB which (nearly) worked
before which I suspect is a similar issue.
Hope this helps,
Andrew Goeldner.
On Fri, 2008-06-13 at 17:25 +0200, Kai Fischer wrote:
Hi,
I have a very strange problem with my serial console
since I updated
from git tag "2.6.25-davinci1" to the most current master tree:
During the early boot process, when the kernel sends
messages to the
console, everything works fine. But then, after the
init process is
started, the boot messages appear only after pressing
the return key. It
is also impossible to login on the serial console
because of this
behaviour (but I can do remote logins).
Switching back to an old kernel version
(2.6.25-davinci1) solves this
problem instantly without touching the root filesystem
(Debian lenny -
armel).
I already searched the git log for any clues, but did
not find anything
suspect. But maybe someone else has an idea about this...
Many thanks in advance!
Best regards,
Kai
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
------------------------------------------------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--- linux-2.6/drivers/serial/8250.c 2008-08-06 15:56:53.000000000 -0500
+++ linux-2.6-vanilla/drivers/serial/8250.c 2008-08-07 12:24:29.000000000 -0500
@@ -1867,7 +1867,6 @@
}
if (is_real_interrupt(up->port.irq)) {
- unsigned char iir1;
/*
* Test for UARTs that do not reassert THRE when the
* transmitter is idle and the interrupt has already
@@ -1881,7 +1880,7 @@
wait_for_xmitr(up, UART_LSR_THRE);
serial_out_sync(up, UART_IER, UART_IER_THRI);
udelay(1); /* allow THRE to set */
- iir1 = serial_in(up, UART_IIR);
+ serial_in(up, UART_IIR);
serial_out(up, UART_IER, 0);
serial_out_sync(up, UART_IER, UART_IER_THRI);
udelay(1); /* allow a working UART time to re-assert THRE */
@@ -1894,7 +1893,7 @@
* If the interrupt is not reasserted, setup a timer to
* kick the UART on a regular basis.
*/
- if (!(iir1 & UART_IIR_NO_INT) && (iir & UART_IIR_NO_INT)) {
+ if (iir & UART_IIR_NO_INT) {
pr_debug("ttyS%d - using backup timer\n", port->line);
up->timer.function = serial8250_backup_timeout;
up->timer.data = (unsigned long)up;
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
