Glen Turner,
I have read your posts to lkml containing your serial console flow control
patches firstly for 2.4.x and then for 2.6.x kernels.
Rationale:
"[PATCH] 0/3 Fix serial console flow control"
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1790.html
2.4 patches:
"[PATCH] 1/3 Fix serial console flow control, serial.c"
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1791.html
"[PATCH] 2/3 Fix serial console flow control, serialP.h"
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1792.html
"[PATCH] 3/3 Fix serial console flow control, serial-console.txt"
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1793.html
2.6 patch:
"[PATCH] Fix CTS/RTS flow control in serial console"
http://www.ussg.iu.edu/hypermail/linux/kernel/0310.2/1080.html
I have not been able to find any feedback on those patches in the lkml
archives. Also I can find no evidence that the patch made it into the
2.6.8.1 kernel. This is a shame as I found your rationale very
persuasive.
Do you maintain an up-to-date version of this patch?
Did you get any feedback for this patch, positive or negative?
Do you need people (i.e. me) to test this patch?
Thanks
Alex Owen
Alex Owen wrote:
> Glen Turner,
>
> I have read your posts to lkml containing your serial console flow control
> patches firstly for 2.4.x and then for 2.6.x kernels.
>
> Rationale:
> "[PATCH] 0/3 Fix serial console flow control"
> http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1790.html
> 2.4 patches:
> "[PATCH] 1/3 Fix serial console flow control, serial.c"
> http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1791.html
> "[PATCH] 2/3 Fix serial console flow control, serialP.h"
> http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1792.html
> "[PATCH] 3/3 Fix serial console flow control, serial-console.txt"
> http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1793.html
> 2.6 patch:
> "[PATCH] Fix CTS/RTS flow control in serial console"
> http://www.ussg.iu.edu/hypermail/linux/kernel/0310.2/1080.html
>
> I have not been able to find any feedback on those patches in the lkml
> archives. Also I can find no evidence that the patch made it into the
> 2.6.8.1 kernel. This is a shame as I found your rationale very
> persuasive.
>
> Do you maintain an up-to-date version of this patch?
> Did you get any feedback for this patch, positive or negative?
> Do you need people (i.e. me) to test this patch?
>
> Thanks
> Alex Owen
> -
Does this fix junk being output from the serial console?
If one is using Pentium 4 HT, it seems that both CPU cores try to send
characters to the serial port at the same time, resulting in lost
characters as one CPU over writes the output from the other.
James Courtier-Dutton <[email protected]> wrote:
>> I have read your posts to lkml containing your serial console flow control
>> patches firstly for 2.4.x and then for 2.6.x kernels.
>
>Does this fix junk being output from the serial console?
>If one is using Pentium 4 HT, it seems that both CPU cores try to send
>characters to the serial port at the same time, resulting in lost
>characters as one CPU over writes the output from the other.
We have multiple P4-HT enabled servers with debian installed & serial
console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
Danny
--
"If Microsoft had been the innovative company that it calls itself, it
would have taken the opportunity to take a radical leap beyond the Mac,
instead of producing a feeble, me-too implementation." - Douglas Adams -
On Mon, Sep 06, 2004 at 10:32:27AM +0000, Danny ter Haar wrote:
> James Courtier-Dutton <[email protected]> wrote:
> >> I have read your posts to lkml containing your serial console flow control
> >> patches firstly for 2.4.x and then for 2.6.x kernels.
> >
> >Does this fix junk being output from the serial console?
> >If one is using Pentium 4 HT, it seems that both CPU cores try to send
> >characters to the serial port at the same time, resulting in lost
> >characters as one CPU over writes the output from the other.
>
> We have multiple P4-HT enabled servers with debian installed & serial
> console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
I don't think this is a serial problem as such, but a problem with the
kernel console subsystem (printk) itself. Maybe James can provide an
example output to confirm exactly what he's seeing.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> On Mon, Sep 06, 2004 at 10:32:27AM +0000, Danny ter Haar wrote:
>
>>James Courtier-Dutton <[email protected]> wrote:
>>
>>>>I have read your posts to lkml containing your serial console flow control
>>>>patches firstly for 2.4.x and then for 2.6.x kernels.
>>>
>>>Does this fix junk being output from the serial console?
>>>If one is using Pentium 4 HT, it seems that both CPU cores try to send
>>>characters to the serial port at the same time, resulting in lost
>>>characters as one CPU over writes the output from the other.
>>
>>We have multiple P4-HT enabled servers with debian installed & serial
>>console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
>
>
> I don't think this is a serial problem as such, but a problem with the
> kernel console subsystem (printk) itself. Maybe James can provide an
> example output to confirm exactly what he's seeing.
>
http://www.superbug.demon.co.uk/latency/
There are 2 oops traces there. At about line 176, the corruption starts.
On Mon, Sep 06, 2004 at 04:45:22PM +0100, James Courtier-Dutton wrote:
> Russell King wrote:
> > On Mon, Sep 06, 2004 at 10:32:27AM +0000, Danny ter Haar wrote:
> >
> >>James Courtier-Dutton <[email protected]> wrote:
> >>
> >>>>I have read your posts to lkml containing your serial console flow control
> >>>>patches firstly for 2.4.x and then for 2.6.x kernels.
> >>>
> >>>Does this fix junk being output from the serial console?
> >>>If one is using Pentium 4 HT, it seems that both CPU cores try to send
> >>>characters to the serial port at the same time, resulting in lost
> >>>characters as one CPU over writes the output from the other.
> >>
> >>We have multiple P4-HT enabled servers with debian installed & serial
> >>console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
> >
> >
> > I don't think this is a serial problem as such, but a problem with the
> > kernel console subsystem (printk) itself. Maybe James can provide an
> > example output to confirm exactly what he's seeing.
> >
>
> http://www.superbug.demon.co.uk/latency/
>
> There are 2 oops traces there. At about line 176, the corruption starts.
They both look like a two printk's overlapping each other, which isn't
unreasonable since one is an oops. We try real hard to get oopses
out, which means "busting" the printk spinlocks. The side effect of
busting those spinlocks is of course no console locking.
It may be annoying, but unless some SMP person wants to fix the spinlock
busting to be a little more inteligent, you can expect this situation
to continue.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Mon, 6 Sep 2004 16:52:30 +0100 Russell King wrote:
| On Mon, Sep 06, 2004 at 04:45:22PM +0100, James Courtier-Dutton wrote:
| > Russell King wrote:
| > > On Mon, Sep 06, 2004 at 10:32:27AM +0000, Danny ter Haar wrote:
| > >
| > >>James Courtier-Dutton <[email protected]> wrote:
| > >>
| > >>>>I have read your posts to lkml containing your serial console flow control
| > >>>>patches firstly for 2.4.x and then for 2.6.x kernels.
| > >>>
| > >>>Does this fix junk being output from the serial console?
| > >>>If one is using Pentium 4 HT, it seems that both CPU cores try to send
| > >>>characters to the serial port at the same time, resulting in lost
| > >>>characters as one CPU over writes the output from the other.
| > >>
| > >>We have multiple P4-HT enabled servers with debian installed & serial
| > >>console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
| > >
| > >
| > > I don't think this is a serial problem as such, but a problem with the
| > > kernel console subsystem (printk) itself. Maybe James can provide an
| > > example output to confirm exactly what he's seeing.
| > >
| >
| > http://www.superbug.demon.co.uk/latency/
| >
| > There are 2 oops traces there. At about line 176, the corruption starts.
|
| They both look like a two printk's overlapping each other, which isn't
| unreasonable since one is an oops. We try real hard to get oopses
| out, which means "busting" the printk spinlocks. The side effect of
| busting those spinlocks is of course no console locking.
|
| It may be annoying, but unless some SMP person wants to fix the spinlock
| busting to be a little more inteligent, you can expect this situation
| to continue.
I've seen it enough times that I would like to see it fixed,
and David Howells (RH) has posted a patch for it several times.
I'm woondering if this:
http://linux.bkbits.net:8080/linux-2.5/diffs/kernel/[email protected]?nav=index.html|src/|src/kernel|hist/kernel/printk.c
is supposed to be a patch for the problem in the 'latency' log above.
If so, it's not as good a solution as David Howells's patch is.
His latest (AFAIK) is:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105730993512692&w=2
--
~Randy
On Mon, Sep 06, 2004 at 09:46:22AM -0700, Randy.Dunlap wrote:
> On Mon, 6 Sep 2004 16:52:30 +0100 Russell King wrote:
>
> | On Mon, Sep 06, 2004 at 04:45:22PM +0100, James Courtier-Dutton wrote:
> | > Russell King wrote:
> | > > On Mon, Sep 06, 2004 at 10:32:27AM +0000, Danny ter Haar wrote:
> | > >
> | > >>James Courtier-Dutton <[email protected]> wrote:
> | > >>
> | > >>>>I have read your posts to lkml containing your serial console flow control
> | > >>>>patches firstly for 2.4.x and then for 2.6.x kernels.
> | > >>>
> | > >>>Does this fix junk being output from the serial console?
> | > >>>If one is using Pentium 4 HT, it seems that both CPU cores try to send
> | > >>>characters to the serial port at the same time, resulting in lost
> | > >>>characters as one CPU over writes the output from the other.
> | > >>
> | > >>We have multiple P4-HT enabled servers with debian installed & serial
> | > >>console enabled (RPB++ ;-) and _i_ have never seen this behaviour.
> | > >
> | > >
> | > > I don't think this is a serial problem as such, but a problem with the
> | > > kernel console subsystem (printk) itself. Maybe James can provide an
> | > > example output to confirm exactly what he's seeing.
> | > >
> | >
> | > http://www.superbug.demon.co.uk/latency/
> | >
> | > There are 2 oops traces there. At about line 176, the corruption starts.
> |
> | They both look like a two printk's overlapping each other, which isn't
> | unreasonable since one is an oops. We try real hard to get oopses
> | out, which means "busting" the printk spinlocks. The side effect of
> | busting those spinlocks is of course no console locking.
> |
> | It may be annoying, but unless some SMP person wants to fix the spinlock
> | busting to be a little more inteligent, you can expect this situation
> | to continue.
>
> I've seen it enough times that I would like to see it fixed,
> and David Howells (RH) has posted a patch for it several times.
>
> I'm woondering if this:
> http://linux.bkbits.net:8080/linux-2.5/diffs/kernel/[email protected]?nav=index.html|src/|src/kernel|hist/kernel/printk.c
> is supposed to be a patch for the problem in the 'latency' log above.
> If so, it's not as good a solution as David Howells's patch is.
> His latest (AFAIK) is:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105730993512692&w=2
here is an updated version:
--- ./kernel/printk.c.orig 2004-09-10 23:56:11.000000000 +0200
+++ ./kernel/printk.c 2004-09-11 22:56:33.000000000 +0200
@@ -521,6 +521,8 @@ asmlinkage int printk(const char *fmt, .
return r;
}
+static volatile int printk_cpu = -1;
+
asmlinkage int vprintk(const char *fmt, va_list args)
{
unsigned long flags;
@@ -529,11 +531,12 @@ asmlinkage int vprintk(const char *fmt,
static char printk_buf[1024];
static int log_level_unknown = 1;
- if (unlikely(oops_in_progress))
+ if (unlikely(oops_in_progress && printk_cpu == smp_processor_id()))
zap_locks();
/* This stops the holder of console_sem just where we want him */
spin_lock_irqsave(&logbuf_lock, flags);
+ printk_cpu = smp_processor_id();
/* Emit the output into the temporary buffer */
printed_len = vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
HTH,
Herbert
> --
> ~Randy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/