Revert Alan's SMP related console race fix as it breaks on some embedded
PowerPC's.
Signed-off-by: Kumar Gala <[email protected]>
---
commit 50c58924f3ddde690f22ef7bad122c8c279a0273
tree 13b6a0761697718fb446ddc6d12fa47de24e5ab1
parent 17ec766166ea8211717f0a97bc3db532a54a499b
author Kumar Gala <[email protected]> Mon, 06 Feb 2006 11:27:48 -0600
committer Kumar Gala <[email protected]> Mon, 06 Feb 2006 11:27:48 -0600
drivers/serial/8250.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 179c1f0..141220f 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2211,7 +2211,7 @@ serial8250_console_write(struct console
* Now, do each character
*/
for (i = 0; i < count; i++, s++) {
- wait_for_xmitr(up, UART_LSR_THRE);
+ wait_for_xmitr(up, BOTH_EMPTY);
/*
* Send the character out.
@@ -2219,7 +2219,7 @@ serial8250_console_write(struct console
*/
serial_out(up, UART_TX, *s);
if (*s == 10) {
- wait_for_xmitr(up, UART_LSR_THRE);
+ wait_for_xmitr(up, BOTH_EMPTY);
serial_out(up, UART_TX, 13);
}
}
@@ -2229,7 +2229,7 @@ serial8250_console_write(struct console
* and restore the IER
*/
wait_for_xmitr(up, BOTH_EMPTY);
- serial_out(up, UART_IER, ier | UART_IER_THRI);
+ serial_out(up, UART_IER, ier);
}
static int serial8250_console_setup(struct console *co, char *options)
On Llu, 2006-02-06 at 11:20 -0600, Kumar Gala wrote:
> Revert Alan's SMP related console race fix as it breaks on some embedded
> PowerPC's.
Please figure out why your hardware is misbehaving before you make a
mess of everyone elses stuff. I've seen nothing from you in the way of
register dumps when this occurs. You need to find out what is actually
happening on your board.
Alan
On Feb 6, 2006, at 12:24 PM, Alan Cox wrote:
> On Llu, 2006-02-06 at 11:20 -0600, Kumar Gala wrote:
>> Revert Alan's SMP related console race fix as it breaks on some
>> embedded
>> PowerPC's.
>
> Please figure out why your hardware is misbehaving before you make a
> mess of everyone elses stuff. I've seen nothing from you in the way of
> register dumps when this occurs. You need to find out what is actually
> happening on your board.
I wan't trying to be difficult, just looking for next steps. I
replied to your initial suggestion but never heard back on what to
try or do going forward.
Can you explain further why you had to change wait_for_xmitr() from
testing BOTH_EMPTY to UART_LSR_THRE.
Also, what exactly would you be looking for in a register dump?
thanks
- kumar
On Llu, 2006-02-06 at 13:14 -0600, Kumar Gala wrote:
> Can you explain further why you had to change wait_for_xmitr() from
> testing BOTH_EMPTY to UART_LSR_THRE.
Because you want to wait for the uart to show that it is ready to accept
a character, not that the byte has been clocked out entirely. Thats
essential for working with virtual serial ports on servers as they use
the fact there is no pending character to work out how to packetize it
as a TCP stream.
> Also, what exactly would you be looking for in a register dump?
When it gets stuck what state are the serial chip registers in and where
is the OS hanging ?
On Feb 6, 2006, at 1:38 PM, Alan Cox wrote:
> On Llu, 2006-02-06 at 13:14 -0600, Kumar Gala wrote:
>> Can you explain further why you had to change wait_for_xmitr() from
>> testing BOTH_EMPTY to UART_LSR_THRE.
>
> Because you want to wait for the uart to show that it is ready to
> accept
> a character, not that the byte has been clocked out entirely. Thats
> essential for working with virtual serial ports on servers as they use
> the fact there is no pending character to work out how to packetize it
> as a TCP stream.
>
>
>> Also, what exactly would you be looking for in a register dump?
>
> When it gets stuck what state are the serial chip registers in and
> where
> is the OS hanging ?
The following seems to make things better for me. Can you take a
look and let me know what you thing. If it looks good, I'll send
Russell a clean patch:
- kumar
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 179c1f0..b1fc97d 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2229,6 +2229,7 @@ serial8250_console_write(struct console
* and restore the IER
*/
wait_for_xmitr(up, BOTH_EMPTY);
+ up->ier |= UART_IER_THRI;
serial_out(up, UART_IER, ier | UART_IER_THRI);
}
On Llu, 2006-02-06 at 14:56 -0600, Kumar Gala wrote:
> The following seems to make things better for me. Can you take a
> look and let me know what you thing. If it looks good, I'll send
> Russell a clean patch:
That looks sensible.