on, not
terminate the protocol handshaking.
Signed-off-by: Denis Du <dudenis2...@yahoo.ca>
---
drivers/net/wan/hdlc_ppp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index afeca6b..ab8b3cb 100644
--- a/drivers/n
on, not
terminate the protocol handshaking.
Signed-off-by: Denis Du
---
drivers/net/wan/hdlc_ppp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index afeca6b..ab8b3cb 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net
Hi, David:
How is your thinking about this patch?
>From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00:00:00 2001
From: Denis Du <dudenis2...@yahoo.ca>
Date: Mon, 15 Jan 2018 17:26:06 -0500
Subject: [PATCH] netdev: carrier detect ok, don't turn off negotiation
Somet
Hi, David:
How is your thinking about this patch?
>From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00:00:00 2001
From: Denis Du
Date: Mon, 15 Jan 2018 17:26:06 -0500
Subject: [PATCH] netdev: carrier detect ok, don't turn off negotiation
Sometimes when physical lines have a j
, February 6, 2018, 10:29:53 AM EST, David Miller
<da...@davemloft.net> wrote:
From: Denis Du <dudenis2...@yahoo.ca>
Date: Tue, 6 Feb 2018 15:15:28 + (UTC)
> How do you think my patch?
>
> As you see, Krzysztof think my patch is ok to be accepted.
> But if you have a
, February 6, 2018, 10:29:53 AM EST, David Miller
wrote:
From: Denis Du
Date: Tue, 6 Feb 2018 15:15:28 + (UTC)
> How do you think my patch?
>
> As you see, Krzysztof think my patch is ok to be accepted.
> But if you have a better idea to fix it,I am glad to see it. Anyway, t
Hi, David:
How do you think my patch?
As you see, Krzysztof think my patch is ok to be accepted.
But if you have a better idea to fix it,I am glad to see it. Anyway, this issue
have to be fixed.
Denis DU
On Sunday, January 28, 2018, 9:34:15 AM EST, Krzysztof Halasa <k...@pm.waw
Hi, David:
How do you think my patch?
As you see, Krzysztof think my patch is ok to be accepted.
But if you have a better idea to fix it,I am glad to see it. Anyway, this issue
have to be fixed.
Denis DU
On Sunday, January 28, 2018, 9:34:15 AM EST, Krzysztof Halasa
wrote
s not
my theory guessing, it is a real problem.
On Monday, January 22, 2018, 3:25:16 PM EST, David Miller <da...@davemloft.net>
wrote:
From: Denis Du <dudenis2...@yahoo.ca>
Date: Tue, 16 Jan 2018 16:58:25 + (UTC)
> From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00:
s not
my theory guessing, it is a real problem.
On Monday, January 22, 2018, 3:25:16 PM EST, David Miller
wrote:
From: Denis Du
Date: Tue, 16 Jan 2018 16:58:25 + (UTC)
> From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00:00:00 2001
> From: Denis Du
> Date: Mon, 15 Ja
will be up, Because the carrier down and up
again and then trigger the timer to restart.
Denis Du
On Monday, January 22, 2018, 3:25:16 PM EST, David Miller <da...@davemloft.net>
wrote:
From: Denis Du <dudenis2...@yahoo.ca>
Date: Tue, 16 Jan 2018 16:58:25 + (
will be up, Because the carrier down and up
again and then trigger the timer to restart.
Denis Du
On Monday, January 22, 2018, 3:25:16 PM EST, David Miller
wrote:
From: Denis Du
Date: Tue, 16 Jan 2018 16:58:25 + (UTC)
> From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00
17 00:00:00 2001
From: Denis Du <dudenis2...@yahoo.ca>
Date: Mon, 15 Jan 2018 17:26:06 -0500
Subject: [PATCH] netdev: carrier detect ok, don't turn off negotiation
Sometimes when physical lines have a just good noise to make the protocol
handshaking fail, but the carrier detect stil
17 00:00:00 2001
From: Denis Du
Date: Mon, 15 Jan 2018 17:26:06 -0500
Subject: [PATCH] netdev: carrier detect ok, don't turn off negotiation
Sometimes when physical lines have a just good noise to make the protocol
handshaking fail, but the carrier detect still good. Then after remove
Hi, guys:
I confirmed the Patch worked great on non-SMP 3.12 kernel. But on SMP it will
still have race condition happened.
Does anyone have another patch for the SMP as mentioned in commit
19e2ad6a09f0c06dbca19c98e5f4584269d913dd
Denis Du
- Original Message -
From: Peter Hurley
Hi, guys:
I confirmed the Patch worked great on non-SMP 3.12 kernel. But on SMP it will
still have race condition happened.
Does anyone have another patch for the SMP as mentioned in commit
19e2ad6a09f0c06dbca19c98e5f4584269d913dd
Denis Du
- Original Message -
From: Peter Hurley
On 12/10/2014, 07:38 PM, Denis Du wrote:
>
> Hi, Guys:
Hi, are you sending this using some robot? I think I have seen like ten
copies of this patch already.
Sorry, I always have troubles to send the patch in correct format, even now I
am not
100% sure this patch have the c
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
Hi, Guys:
It was found that the 3.12 kernel tty layer will lose or corrupt data
when have a full-duplex communication, especially in high baud rate, for
example 230k for my OMAP5 uart. Eventually I found there is lock missing
between copy data to ldisc layer buffer and copy data from the same
On 12/10/2014, 07:38 PM, Denis Du wrote:
Hi, Guys:
Hi, are you sending this using some robot? I think I have seen like ten
copies of this patch already.
Sorry, I always have troubles to send the patch in correct format, even now I
am not
100% sure this patch have the correct format
Hi, Jeremiah:
This patch was generated base on 3.12 kernel. But possibly I have a wrong
format to put this patch on a plain text. I am working to do a new patch now.
Denis Du
- Original Message -
From: Jeremiah Mahler
To: Denis Du
Cc: "linux-kernel@vger.kernel.org"
Se
Hi, Jeremiah:
This patch was generated base on 3.12 kernel. But possibly I have a wrong
format to put this patch on a plain text. I am working to do a new patch now.
Denis Du
- Original Message -
From: Jeremiah Mahler jmmah...@gmail.com
To: Denis Du dudenis2...@yahoo.ca
Cc: linux
Hi, Guys:
I found that the 3.12 kernel tty layer will lose or corrupt data when having a
full-duplex communication, especcially in high baudrate, for example 230k for
my OMAP5 uart. Eventually I found there is a lock missing between copy data to
ldisc layer buffer and copy data from the same
Hi, Guys:
I found that the 3.12 kernel tty layer will lose or corrupt data when having a
full-duplex communication, especcially in high baudrate, for example 230k for
my OMAP5 uart. Eventually I found there is a lock missing between copy data to
ldisc layer buffer and copy data from the same
atomic_read_lock, but it doesn’t work.
Denis Du--- drivers/tty/n_tty.c-old 2014-10-16 16:39:35.909350338 -0400
+++ drivers/tty/n_tty.c 2014-10-16 16:49:00.004930469 -0400
@@ -124,6 +124,7 @@
struct mutex atomic_read_lock;
struct mutex output_lock;
+ struct mutex read_buf_lock;
};
static
atomic_read_lock, but it doesn’t work.
Denis Du--- drivers/tty/n_tty.c-old 2014-10-16 16:39:35.909350338 -0400
+++ drivers/tty/n_tty.c 2014-10-16 16:49:00.004930469 -0400
@@ -124,6 +124,7 @@
struct mutex atomic_read_lock;
struct mutex output_lock;
+ struct mutex read_buf_lock;
};
static
30 matches
Mail list logo
