Hi Greg and Shannon,
b265da5a45ce60bd3d7505cc0eaa6cfba50946a1
arm64: perf: fix unassigned cpu_pmu->plat_device when probing PMU PPIs
This looks applicable to stable-4.1, that fix "No PMU device registered"
when use "perf list hw"，which was introduced by commit d795ef9aa831("arm64:
perf: don't war
On 08/13/2015, 03:33 AM, Xie XiuQi wrote:
> e21404d ipmi: fix timeout calculation when bmc is disconnected
>
> This patch looks applicable to stable-3.4, stable-3.10 and stable-3.12,
> that fixed a bug when bmc is disconnected. Sebastian Parschauer
> () also found this bug on linux-3.12.y.
Applie
Hi Zefan, Greg, and Jiri,
e21404d ipmi: fix timeout calculation when bmc is disconnected
This patch looks applicable to stable-3.4, stable-3.10 and stable-3.12,
that fixed a bug when bmc is disconnected. Sebastian Parschauer
() also found this bug on linux-3.12.y.
It was built successful for me
On Thu, 2015-05-14 at 14:29 +0800, Rui Xiang wrote:
> Hi Zefan,
>
> c10d73671ad30f54692f7f69f0e09e75d3a8926a
> softirq: reduce latencies
>
> This commit can reduce softirq latencies in some various network workloads.
>
> 34376a50fb1fa095b9d0636fa41ed2e73125f214
> Fix lockup related to stop_machi
On Fri, Jul 31, 2015 at 11:03:48AM +0800, Rui Xiang wrote:
> ping
>
> On 2015/7/29 19:03, Rui Xiang wrote:
2 days ago? For a very old and slowly updated kernel release? Hah, be
happy if you get a response in a month...
--
To unsubscribe from this list: send the line "unsubscribe stable" in
ping
On 2015/7/29 19:03, Rui Xiang wrote:
> Hi Zefan, Suresh or Peter,
>
> 9c1c3fac53378c9782c18f80107965578d7b7167
> x86, kvm: use kernel_fpu_begin/end() in kvm_load/put_guest_fpu()
>
> We never cause the "Device Not Available" exception in kernel mode,
> but without this patch, the orign u
Hi Zefan, Suresh or Peter,
9c1c3fac53378c9782c18f80107965578d7b7167
x86, kvm: use kernel_fpu_begin/end() in kvm_load/put_guest_fpu()
We never cause the "Device Not Available" exception in kernel mode,
but without this patch, the orign unlazy_fpu() do stts(), the following
fpu_restore_checking() w
9c1c3fac53378c9782c18f80107965578d7b7167
x86, kvm: use kernel_fpu_begin/end() in kvm_load/put_guest_fpu()
We never cause the "Device Not Available" exception in kernel mode,
but without this patch, the orign unlazy_fpu() do stts(), the following
fpu_restore_checking() will trigger a DNA(Device Not
于 2015/5/14 14:29, Rui Xiang wrote:
> Hi Zefan,
>
> c10d73671ad30f54692f7f69f0e09e75d3a8926a
> softirq: reduce latencies
>
> This commit can reduce softirq latencies in some various network workloads.
>
> 34376a50fb1fa095b9d0636fa41ed2e73125f214
> Fix lockup related to stop_machine being stuck i
Hi Greg and Jiri,
The following patch commit ee53664bda169f519ce3c6a22d378f0b946c8178
mm: Fix NULL pointer dereference in madvise(MADV_WILLNEED) support
fix CVE-2014-8173. I wish you could merge this fix into stable 3.10
and 3.12, because the linux kernel before 3.13 on NUMA systems
is affected
On Wed, Jan 28, 2015 at 04:06:24PM +0800, HuKeping wrote:
> Hi greg,
> We want to use pstore on linux 3.10. But we found several bugfixs have not
> been merged yet. Most of them are obvious and can be cherry-picked cleanly.
> Would you please apply them to stable 3.10?
>
> v1 -> v2:
> - remove d4
On Tue, Nov 11, 2014 at 11:31:27AM +, Hou Pengyang wrote:
> Hi Greg,
>
> These patches are backported to make LPAE more robust, most of which
> are important bugfixs. So I suggest merging them into 3.10.
>
> For ARM, when LPAE is triggered, 40-bit physical address is available,
> translation
Hi greg,
We want to use pstore on linux 3.10. But we found several bugfixs have not
been merged yet. Most of them are obvious and can be cherry-picked cleanly.
Would you please apply them to stable 3.10?
v1 -> v2:
- remove d4bf205da618bbd0b038e404d646f14e76915718 which has already been merged
-
Hi greg,
We want to use pstore on linux 3.10. But we found several bugfixs have not
been merged yet. Most of them are obvious and can be cherry-picked cleanly.
Would you please apply them to stable 3.10?
Change from v1:
- remove d4bf205da618bbd0b038e404d646f14e76915718 which has already been merg
some of them have already been merged, I'll check it and resend later :)
于 2015/1/28 9:21, Greg KH 写道:
On Mon, Nov 03, 2014 at 05:57:47PM +0800, HuKeping wrote:
Hi greg,
We want to use pstore on linux 3.10. But we found several bugfixs have not
merged into it. Most of them are obvious and can b
On Mon, Nov 03, 2014 at 05:57:47PM +0800, HuKeping wrote:
> Hi greg,
> We want to use pstore on linux 3.10. But we found several bugfixs have not
> merged into it. Most of them are obvious and can be cherry-picked cleanly.
> Would you please apply them to stable 3.10?
>
> PART 1: patches that can
Hi,
This patch fixes a bug on intel NICs which may avoid link to up when starting
the interface or plugging the ethernet cable.
Todd Fujinaka (1):
igb: bring link up when PHY is powered up
drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
1 file changed, 2 insertions(+)
--
2.1.0
--
To unsu
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to
kernel/time/sched_clock.c because of upgradi
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to
kernel/time/sched_clock.c because of upgradi
This looks applicable to stable-3.10, which load cycle count after
epoch stabilizes. The function was moved from
arch/arm/kernel/sched_clock.c to kernel/time/sched_clock.c
because of upgrading version. I rearrange this patch for
fixing bug in stable-3.10.
The commit id is 336ae1180df5f69b9e0fb656
On 2014/12/5 7:39, Greg KH wrote:
On Wed, Nov 26, 2014 at 03:49:59PM +0800, Hou Pengyang wrote:
On 2014/11/11 19:31, Hou Pengyang wrote:
Hi Greg,
These patches are backported to make LPAE more robust, most of which
are important bugfixs. So I suggest merging them into 3.10.
For ARM, when LPAE
On Wed, Nov 26, 2014 at 03:49:59PM +0800, Hou Pengyang wrote:
> On 2014/11/11 19:31, Hou Pengyang wrote:
> >Hi Greg,
> >
> >These patches are backported to make LPAE more robust, most of which
> >are important bugfixs. So I suggest merging them into 3.10.
> >
> >For ARM, when LPAE is triggered, 40-
On Thu, Dec 04, 2014 at 09:22:20AM +0800, Hou Pengyang wrote:
> On 2014/12/2 21:44, Luis Henriques wrote:
> >On Wed, Nov 26, 2014 at 03:49:59PM +0800, Hou Pengyang wrote:
> >>On 2014/11/11 19:31, Hou Pengyang wrote:
> >>>Hi Greg,
> >>>
> >>>These patches are backported to make LPAE more robust, mos
On 2014/12/2 21:44, Luis Henriques wrote:
On Wed, Nov 26, 2014 at 03:49:59PM +0800, Hou Pengyang wrote:
On 2014/11/11 19:31, Hou Pengyang wrote:
Hi Greg,
These patches are backported to make LPAE more robust, most of which
are important bugfixs. So I suggest merging them into 3.10.
For ARM, w
On Wed, Nov 26, 2014 at 03:49:59PM +0800, Hou Pengyang wrote:
> On 2014/11/11 19:31, Hou Pengyang wrote:
> >Hi Greg,
> >
> >These patches are backported to make LPAE more robust, most of which
> >are important bugfixs. So I suggest merging them into 3.10.
> >
> >For ARM, when LPAE is triggered, 40-
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
It was built successful for me. What do you think?
Stephen Boyd (1):
ARM: sched_clock: Load cycle coun
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
It was built successful for me. What do you think?
Stephen Boyd (1):
ARM: sched_clock: Load cycle coun
On 2014/11/11 19:31, Hou Pengyang wrote:
Hi Greg,
These patches are backported to make LPAE more robust, most of which
are important bugfixs. So I suggest merging them into 3.10.
For ARM, when LPAE is triggered, 40-bit physical address is available,
translation table becomes 3-level, and every
On Fri, Oct 24, 2014 at 06:37:14PM +0800, Wang Nan wrote:
> Hi Greg,
>
>Could you please queue following patches to 3.10 LTS queue and the
>second one to 3.14 LTS queue?
>
>commit 63328070eff2f4fd730c86966a0dbc976147c39f:
> ARM: Correct BUG() assembly to ensure it is endian-agnos
Hi Greg,
These patches are backported to make LPAE more robust, most of which
are important bugfixs. So I suggest merging them into 3.10.
For ARM, when LPAE is triggered, 40-bit physical address is available,
translation table becomes 3-level, and every table entry is 64 bit
instead of 32. Howe
Hi Li,
commit 936597631dd310e220544dc5c6075d924efd39b2
ixgbevf: Prevent RX/TX statistics getting reset to zero
This looks applicable to stable-3.4, which fixed RX/TX statistics to be zero.
We met the problem in our product, command ifconfig can't get RX/TX statistics.
and this patch fixed the pr
Hi greg,
We want to use pstore on linux 3.10. But we found several bugfixs have not
merged into it. Most of them are obvious and can be cherry-picked cleanly.
Would you please apply them to stable 3.10?
PART 1: patches that can be cleanly applied:
0405a5cec3406f19e69da07c8111a6bf1088ac29
pstore
On Fri, 2014-09-12 at 09:57 +0800, Wang Nan wrote:
> Hi Greg and Zefan:
>
> upstream commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de:
> ext2: Fix fs corruption in ext2_get_xip_mem()
>
> looks applicable for 3.10 and 3.4.
>
> On 3.10, without this patch we can easily trigger a bug using:
>
> #
On 10/24/2014, 05:52 AM, Hou Pengyang wrote:
> hi gerg,
>
> Now on IvyBridge machines with 3.10 stable, perf could not get proper
> dTLB-load-misses event when performing "perf stat -e dTLB-load-misses
> sleep 1", which outputs:
>
> Performance counter stats for 'sleep 1':
> 0 dTLB-load-misses
>
Hi Greg,
Could you please queue following patches to 3.10 LTS queue and the
second one to 3.14 LTS queue?
commit 63328070eff2f4fd730c86966a0dbc976147c39f:
ARM: Correct BUG() assembly to ensure it is endian-agnostic
commit 888be25402021a425da3e85e2d5a954d7509286e:
ARM: probes
From: Ben Dooks
commit 63328070eff2f4fd730c86966a0dbc976147c39f upstream.
Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text. This
means that the BU
From: Ben Dooks
commit 888be25402021a425da3e85e2d5a954d7509286e upstream.
If we are running BE8, the data and instruction endianness do not
match, so use to correctly translate memory accesses
into ARM instructions.
Acked-by: Jon Medhurst
Signed-off-by: Ben Dooks
[taras.kondrat...@linaro.org
hi gerg,
Now on IvyBridge machines with 3.10 stable, perf could not get proper
dTLB-load-misses event when performing "perf stat -e dTLB-load-misses
sleep 1", which outputs:
Performance counter stats for 'sleep 1':
0 dTLB-load-misses
1.000951106 seconds time elapsed
0 dTLB-load-misses means w
On 2014/10/3 8:06, Greg KH wrote:
> On Sat, Aug 16, 2014 at 11:05:18AM +0800, Wang Nan wrote:
>> Hi Greg,
>>
>>Could you please queue following patch to 3.10.x?
>>
>>Commit 888be25402021a425da3e85e2d5a954d7509286e:
>> ARM: probes: fix instruction fetch order with
>>
>>Without this
On Thu, Aug 14, 2014 at 08:59:00PM +0800, zhangzhiqiang wrote:
> hi Grep,
>
> commit 4921e320244e099bdf237fd10428594ce5f5b87d
>
> perf kmem: Make it work again on non NUMA machines
>
> the commit '2814eb0 perf kmem: Remove die() calls' disabled 'perf kmem'
> command for machines without numa sup
On Sat, Aug 16, 2014 at 11:05:18AM +0800, Wang Nan wrote:
> Hi Greg,
>
>Could you please queue following patch to 3.10.x?
>
>Commit 888be25402021a425da3e85e2d5a954d7509286e:
> ARM: probes: fix instruction fetch order with
>
>Without this patch, kprobe on ARM big endian is broke
On 09/30/2014, 06:18 AM, Liu hua wrote:
> Hi Greg, Luis and Jiri,
>
> Upstream commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 solved a
> regression for THUMB2 kernel.
>
> Without this patch THUMB2 kernel can not go through kdump process.
> This patch applies to v3.13+. And 3.10 stable ,3.11 stab
On Tue, Sep 30, 2014 at 12:18:41PM +0800, Liu hua wrote:
> Hi Greg, Luis and Jiri,
>
> Upstream commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 solved a
> regression for THUMB2 kernel.
>
> Without this patch THUMB2 kernel can not go through kdump process.
> This patch applies to v3.13+. And 3.10
Hi Greg, Luis and Jiri,
Upstream commit e2ccba49085ab5d71b092de2a5176eb9b19cc876 solved a
regression for THUMB2 kernel.
Without this patch THUMB2 kernel can not go through kdump process.
This patch applies to v3.13+. And 3.10 stable ,3.11 stable and 3.12
stable need it. And this patch can cherry-
hi all,
Now on non NUMA machines with 3.10 stable,perf kmem command does not work well.
For instance,
when exec perf kmem record sleep 2, we can get the perf.data file correctly.
but when we exec
perf kmem stat there is nothing return.
In upstream the bug has been fixed and perf kmem work well o
On 2014/9/12 9:57, Wang Nan wrote:
> Hi Greg and Zefan:
>
> upstream commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de:
> ext2: Fix fs corruption in ext2_get_xip_mem()
>
> looks applicable for 3.10 and 3.4.
>
> On 3.10, without this patch we can easily trigger a bug using:
>
> # mkfs.ext2 -b 40
I've already sent these to stable mailing list.
On 2014/9/12 10:22, Wang Nan wrote:
> Hi Greg,
>
> Upstream commit 0c740d0afc3bff0a097ad03a1c8df92757516f5c and
> 1da4db0cd5c8a31d4468ec906b413e75e604b465 looks ignored by 3.10 (they are
> included by 3.12.22). Without these patches we meet real dea
Hi Greg,
Upstream commit 0c740d0afc3bff0a097ad03a1c8df92757516f5c and
1da4db0cd5c8a31d4468ec906b413e75e604b465 looks ignored by 3.10 (they are
included by 3.12.22). Without these patches we meet real deadlock in oom killer
code.
They can not be clearly cherry-pick to 3.10.54 because 3.10 LTS doe
Hi Greg and Zefan:
upstream commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de:
ext2: Fix fs corruption in ext2_get_xip_mem()
looks applicable for 3.10 and 3.4.
On 3.10, without this patch we can easily trigger a bug using:
# mkfs.ext2 -b 4096 /dev/ram1
# mount -t ext2 -o xip /dev/ram1 /mnt
# cp
On Thu, Sep 04, 2014 at 02:52:43PM +0100, Markos Chandras wrote:
> On 08/28/2014 08:54 AM, Markos Chandras wrote:
> > On 08/27/2014 10:23 PM, Greg KH wrote:
> >> On Wed, Aug 27, 2014 at 03:04:51PM +0100, Markos Chandras wrote:
> >>> Hi Greg,
> >>>
> >>> Could you please apply the following patches
On 08/28/2014 08:54 AM, Markos Chandras wrote:
> On 08/27/2014 10:23 PM, Greg KH wrote:
>> On Wed, Aug 27, 2014 at 03:04:51PM +0100, Markos Chandras wrote:
>>> Hi Greg,
>>>
>>> Could you please apply the following patches to the 3.16.X stable kernels?
>>>
>>> - MIPS: EVA: Add new EVA header
>>> (f8
commit 1aa2b3b7a6c4f3dbd3671171113a20e6a6190e3b:
[PATCH] ARM: 7748/1: oabi: handle faults when loading swi instruction
from userspace
Hi Greg,
Could you please queue the following patch to 3.10.x?
We have this problem in 2.6.34, and find that the patch is not included in
3.10.x. This
On 08/27/2014 10:23 PM, Greg KH wrote:
> On Wed, Aug 27, 2014 at 03:04:51PM +0100, Markos Chandras wrote:
>> Hi Greg,
>>
>> Could you please apply the following patches to the 3.16.X stable kernels?
>>
>> - MIPS: EVA: Add new EVA header
>> (f85b71ceabb9d8d8a9e34b045b5c43ffde3623b3)
>> - MIPS: Malta
On Wed, Aug 27, 2014 at 03:04:51PM +0100, Markos Chandras wrote:
> Hi Greg,
>
> Could you please apply the following patches to the 3.16.X stable kernels?
>
> - MIPS: EVA: Add new EVA header
> (f85b71ceabb9d8d8a9e34b045b5c43ffde3623b3)
> - MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_ini
Hi Greg,
Could you please apply the following patches to the 3.16.X stable kernels?
- MIPS: EVA: Add new EVA header
(f85b71ceabb9d8d8a9e34b045b5c43ffde3623b3)
- MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
(ca4d24f7954f3746742ba350c2276ff777f21173)
- MIPS: CPS: Initialize EVA befor
On Mon, Aug 18, 2014 at 02:59:33PM +0100, Markos Chandras wrote:
> Hi Greg,
>
> Could you please apply the following patch to the 3.16.X stable kernels?
>
> c3b9b945e02e011c63522761e91133ea43eb6939
> "MIPS: math-emu: Fix instruction decoding"
Now applied.
--
To unsubscribe from this list: send t
Hi Greg,
Could you please apply the following patch to the 3.16.X stable kernels?
c3b9b945e02e011c63522761e91133ea43eb6939
"MIPS: math-emu: Fix instruction decoding"
Thank you
--
markos
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@v
Hi Greg,
Could you please queue following patch to 3.10.x?
Commit 888be25402021a425da3e85e2d5a954d7509286e:
ARM: probes: fix instruction fetch order with
Without this patch, kprobe on ARM big endian is broken.
I have backport it to 3.10. Please see following post.
Thank yo
hi Grep,
commit 4921e320244e099bdf237fd10428594ce5f5b87d
perf kmem: Make it work again on non NUMA machines
the commit '2814eb0 perf kmem: Remove die() calls' disabled 'perf kmem'
command for machines without numa support. It made the command fail if
'/sys/devices/system/node' dir wasn't found.
On Fri, Jul 25, 2014 at 10:35:15AM +0800, Qiang Huang wrote:
> Hi Greg,
>
> 7f88f88f83ed609650a01b18572e605ea50cd163
> mm: kmemleak: avoid false negatives on vmalloc'ed objects
>
> This patch looks applicable to stable-3.4, it fixed a regression that
> kmemleak was rarely reporting vmalloc()
On Tue, 2014-06-24 at 12:02 +0800, Rui Xiang wrote:
> Hi Greg or Thomas,
>
> 0e576acbc1d9600cf2d9b4a141a2554639959d50
> nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
>
> This fixed an inconsistency about nohz.
>
> Without this patch, When we boot with nohz=off and CONFIG_
Hi Greg,
7f88f88f83ed609650a01b18572e605ea50cd163
mm: kmemleak: avoid false negatives on vmalloc'ed objects
This patch looks applicable to stable-3.4, it fixed a regression that
kmemleak was rarely reporting vmalloc() leaks. It was tested fine
by me.
This patch needs some adjustments, before
On Fri, Jun 13, 2014 at 03:57:46PM +0800, Wang Nan wrote:
> Hi Greg,
>
>Could you please queue following patches to 3.10.x?
>
>commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa:
> serial: 8250_dw: Report CTS asserted for auto flow
>
>commit c49436b657d0a56a6ad90d14a7c3041add7cf64d
On 2014/6/25 15:20, Wang Nan wrote:
> Hi Greg,
>
>Following 3 patches fix a 8250 serial problem which causes stty stall:
>
>33acbb82695f84e9429c1f7fbdeb4588dea12ffa
>serial: 8250_dw: Report CTS asserted for auto flow
>
>c49436b657d0a56a6ad90d14a7c3041add7cf64d
>serial: 8250_d
On Wed, Jun 25, 2014 at 04:33:29PM +0800, Wang Nan wrote:
> Hi Greg,
>
>Following 3 patches fix a 8250 serial problem which causes stty stall:
>
>33acbb82695f84e9429c1f7fbdeb4588dea12ffa
>serial: 8250_dw: Report CTS asserted for auto flow
>
>c49436b657d0a56a6ad90d14a7c3041add7
On Tue, Jun 24, 2014 at 12:02:34PM +0800, Rui Xiang wrote:
> Hi Greg or Thomas,
>
> 0e576acbc1d9600cf2d9b4a141a2554639959d50
> nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
>
> This fixed an inconsistency about nohz.
>
> Without this patch, When we boot with nohz=off and
Updating Tim Kryger's e-mail address.
On 25 June 2014 00:20, Wang Nan wrote:
> From: James Hogan
>
> upstream unclusion
> DTS: DTS2014060600056
> directory: cherry-pick
>
>
>
> commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream
>
> Commit c49436b657
On 06/25/2014 10:33 AM, Wang Nan wrote:
> Hi Greg,
>
>Following 3 patches fix a 8250 serial problem which causes stty stall:
>
>33acbb82695f84e9429c1f7fbdeb4588dea12ffa
>serial: 8250_dw: Report CTS asserted for auto flow
>
>c49436b657d0a56a6ad90d14a7c3041add7cf64d
>serial:
Hi Greg,
Following 3 patches fix a 8250 serial problem which causes stty stall:
33acbb82695f84e9429c1f7fbdeb4588dea12ffa
serial: 8250_dw: Report CTS asserted for auto flow
c49436b657d0a56a6ad90d14a7c3041add7cf64d
serial: 8250_dw: Improve unwritable LCR workaround
6979f8d280
From: Tim Kryger
commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream.
When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designware UART will ignore writes
to the LCR if the UART is busy. The current workaround saves a copy of
the las
From: Tim Kryger
commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa upstream.
When a serial port is configured for RTS/CTS flow control, serial core
will disable the transmitter if it observes CTS is de-asserted. This is
perfectly reasonable and appropriate when the UART lacks the ability to
automa
From: James Hogan
commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream.
Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check that the LCR was written properly
to detect and workaround the busy quirk, but the behaviour of bit 5
(UART_L
On 2014/6/25 15:20, Wang Nan wrote:
> From: Tim Kryger
>
...
> upstream inclusion
> DTS: DTS2014060600056
> directory: cherry-pick
>
>
>
Please remove the above lines.
> commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa upstream
>
commit 33acbb82695f84
On 2014/6/25 15:20, Wang Nan wrote:
> Hi Greg,
>
>Following 3 patches fix a 8250 serial problem which causes stty stall:
>
>33acbb82695f84e9429c1f7fbdeb4588dea12ffa
>serial: 8250_dw: Report CTS asserted for auto flow
>
>c49436b657d0a56a6ad90d14a7c3041add7cf64d
>serial: 8250_d
From: James Hogan
upstream unclusion
DTS: DTS2014060600056
directory: cherry-pick
commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream
Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check tha
From: Tim Kryger
upstream inclusion
DTS: DTS2014060600056
directory: cherry-pick
commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream
When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designwa
From: Tim Kryger
upstream inclusion
DTS: DTS2014060600056
directory: cherry-pick
commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa upstream
When a serial port is configured for RTS/CTS flow control, serial core
will disable the transmitter if it observes
Hi Greg,
Following 3 patches fix a 8250 serial problem which causes stty stall:
33acbb82695f84e9429c1f7fbdeb4588dea12ffa
serial: 8250_dw: Report CTS asserted for auto flow
c49436b657d0a56a6ad90d14a7c3041add7cf64d
serial: 8250_dw: Improve unwritable LCR workaround
6979f8d280498
On Tue, Jun 24, 2014 at 12:02:34PM +0800, Rui Xiang wrote:
> Hi Greg or Thomas,
>
> 0e576acbc1d9600cf2d9b4a141a2554639959d50
> nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
>
> This fixed an inconsistency about nohz.
>
> Without this patch, When we boot with nohz=off and
Hi Greg or Thomas,
0e576acbc1d9600cf2d9b4a141a2554639959d50
nohz: Fix another inconsistency between CONFIG_NO_HZ=n and nohz=off
This fixed an inconsistency about nohz.
Without this patch, When we boot with nohz=off and CONFIG_NO_HZ=Y,
and the system is idle, powertop shows the cpu is always i
Thanks!
On 2014/6/17 1:19, Cong Wang wrote:
> On Sun, Jun 15, 2014 at 8:14 PM, chenweilong wrote:
>> Oh..sorry,
>>
>> I must missed something important!
>
> Yes, you miss the FAQ:
> https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
>
>> What's the right way?
>>
>
> Q: How can
On Sun, Jun 15, 2014 at 8:14 PM, chenweilong wrote:
> Oh..sorry,
>
> I must missed something important!
Yes, you miss the FAQ:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
> What's the right way?
>
Q: How can I tell what patches are queued up for backporting to the
vari
Oh..sorry,
I must missed something important!
What's the right way?
This patch solves the bug is 67951 on bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=67951
It's very worthy to be applied to stable 3.4.x kernels.
As this patch can't be applied directly, I just modify
it in my last mail,
From: Chen Weilong
Date: Mon, 16 Jun 2014 10:04:39 +0800
> From: Gao feng
>
> commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.
>
> /* CHANGELOG */
>
No, this is not how you ask for networking changes to be submitted to
-stable.
--
To unsubscribe from this list: send the line "unsubs
From: Gao feng
commit 33d99113b1102c2d2f8603b9ba72d89d915c13f5 upstream.
/* CHANGELOG */
CC: Sabrina Dubroca
CC: Hannes Frederic Sowa
Reported-by: Weilong Chen
Signed-off-by: Weilong Chen
Signed-off-by: Gao feng
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
[weilong: s/ip
From: Tim Kryger
commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream.
When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designware UART will ignore writes
to the LCR if the UART is busy. The current workaround saves a copy of
the las
From: Tim Kryger
commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa upstream
When a serial port is configured for RTS/CTS flow control, serial core
will disable the transmitter if it observes CTS is de-asserted. This is
perfectly reasonable and appropriate when the UART lacks the ability to
automat
Hi Greg,
Could you please queue following patches to 3.10.x?
commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa:
serial: 8250_dw: Report CTS asserted for auto flow
commit c49436b657d0a56a6ad90d14a7c3041add7cf64d:
serial: 8250_dw: Improve unwritable LCR workaround
(with conte
From: James Hogan
commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream.
Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check that the LCR was written properly
to detect and workaround the busy quirk, but the behaviour of bit 5
(UART_L
On Tue, May 27, 2014 at 10:00:12AM +0800, Weng Meiling wrote:
>
> Hi Dave, Stephane, Knut, Peter or Will,
>
> 14c63f17b1fde5a575a28e96547a22b451c71fb5
> perf: Drop sample rate when sampling is too slow
>
> e5302920da9ef23f9d19d4e9ac85704cc25bee7a
> perf: Fix interrupt handler timing harness
>
>
On Fri, Apr 18, 2014 at 02:08:09PM +0800, xiakaixu wrote:
> Hi Greg,
>
> Could you please queue following patch to 3.10.x ?
>
> Commit b69e63a45f2d96a0dfe930ed20385058d4574d2f :
> perf evsel: Fix printing of perf_event_paranoid message
>
> Which is upstreamed in v3.11.
>
> Without this patch,
On Thu, Jun 05, 2014 at 05:12:41PM +0100, Ben Hutchings wrote:
> On Wed, 2014-06-04 at 21:11 -0700, Greg KH wrote:
> > On Thu, Jun 05, 2014 at 11:47:20AM +0800, Li Zefan wrote:
> > > On 2014/6/5 11:16, Xiangyu Lu wrote:
> > > > Hi Greg,
> > > > I found this bugfix is not in the latest 3.10.y, pleas
On Wed, 2014-06-04 at 21:11 -0700, Greg KH wrote:
> On Thu, Jun 05, 2014 at 11:47:20AM +0800, Li Zefan wrote:
> > On 2014/6/5 11:16, Xiangyu Lu wrote:
> > > Hi Greg,
> > > I found this bugfix is not in the latest 3.10.y, please backport it.
> > > As for now, 3.10.y LTS would still be vulnerable to
On Thu, Jun 05, 2014 at 11:47:20AM +0800, Li Zefan wrote:
> On 2014/6/5 11:16, Xiangyu Lu wrote:
> > Hi Greg,
> > I found this bugfix is not in the latest 3.10.y, please backport it.
> > As for now, 3.10.y LTS would still be vulnerable to CVE-2014-2672.
> >
>
> Please add this line：
>
> "From:
On Fri, May 23, 2014 at 04:07:11PM +0900, Greg Kroah-Hartman wrote:
> On Fri, May 23, 2014 at 02:49:18PM +0800, Yijing Wang wrote:
> > On 2014/4/25 22:42, Bjorn Helgaas wrote:
> > > On Fri, Apr 25, 2014 at 12:14 AM, Yijing Wang
> > > wrote:
> > >> From: Joe Lawrence
> > >>
> > >> Hi Greg or Bjor
On 2014/6/5 11:16, Xiangyu Lu wrote:
> Hi Greg,
> I found this bugfix is not in the latest 3.10.y, please backport it.
> As for now, 3.10.y LTS would still be vulnerable to CVE-2014-2672.
>
Please add this line：
"From: Stanislaw Gruszka "
> [ Upstream commit 21f8aaee0c62708654988ce092838aa7df4
Hi Greg,
I found this bugfix is not in the latest 3.10.y, please backport it.
As for now, 3.10.y LTS would still be vulnerable to CVE-2014-2672.
[ Upstream commit 21f8aaee0c62708654988ce092838aa7df4d25d8 ]
We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
is race condition wh
On Wed, Jun 04, 2014 at 11:49:30AM +, Liu Xue wrote:
> Hi Greg,
> I'm not sure if you did not include this for a reason in the latest 3.10.y
> or if you just missed it. If in the later case, please backport it.
I didn't add it to 3.10-stable as it did not apply to that tree.
Thanks for doing
Hi Greg,
I'm not sure if you did not include this for a reason in the latest 3.10.y
or if you just missed it. If in the later case, please backport it.
[ Upstream commit 621b5060e823301d0cba4cb52a7ee3491922d291 ]
When we fork/clone we currently don't copy any of the TM state to the new
thread. T
On Wed, Apr 30, 2014 at 09:03:36PM +0200, Thomas Gleixner wrote:
> Hi,
>
> commit b20a774495671f037e7160ea2ce8789af6b61533
> Author: David Ertman
> Date: Tue Mar 25 04:27:55 2014 +
>
> e1000e: Fix no connectivity when driver loaded with cable out
>
> fixes an issue which affects quite
1 - 100 of 206 matches
Mail list logo
