Re: [PATCH] [wireless-next] mt76: fix building without CONFIG_LEDS_CLASS

On 2018-01-18 14:14, Arnd Bergmann wrote: > When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while > mt76 is built-in, we run into a link error: > > drivers/net/wireless/mediatek/mt76/mac80211.o: In function > `mt76_register_device': > mac80211.c:(.text+0xb78): relocation truncated

Re: [PATCH] [wireless-next] mt76: fix building without CONFIG_LEDS_CLASS

On 2018-01-18 14:14, Arnd Bergmann wrote: > When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while > mt76 is built-in, we run into a link error: > > drivers/net/wireless/mediatek/mt76/mac80211.o: In function > `mt76_register_device': > mac80211.c:(.text+0xb78): relocation truncated

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 9:26 AM, Luck, Tony wrote: >> Both are real page. But why do you expect pages to be 64-byte alinged? >> Both are aligned to 64-bit as they suppose to be IIUC. > > On a 64-bit kernel sizeof struct page == 64 (after much work by people to > trim out

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 9:26 AM, Luck, Tony wrote: >> Both are real page. But why do you expect pages to be 64-byte alinged? >> Both are aligned to 64-bit as they suppose to be IIUC. > > On a 64-bit kernel sizeof struct page == 64 (after much work by people to > trim out excess stuff). So I

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 8:56 AM, Kirill A. Shutemov wrote: > > I can't say I fully grasp how 'diff' got this value and how it leads to both > checks being false. I think the problem is that page difference when they are in different sections. When you do

RE: [mm 4.15-rc8] Random oopses under memory pressure.

> Both are real page. But why do you expect pages to be 64-byte alinged? > Both are aligned to 64-bit as they suppose to be IIUC. On a 64-bit kernel sizeof struct page == 64 (after much work by people to trim out excess stuff). So I thought we made sure to align the base address of blocks of

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 8:56 AM, Kirill A. Shutemov wrote: > > I can't say I fully grasp how 'diff' got this value and how it leads to both > checks being false. I think the problem is that page difference when they are in different sections. When you do pte_page(*pvmw->pte) - pvmw->page

RE: [mm 4.15-rc8] Random oopses under memory pressure.

> Both are real page. But why do you expect pages to be 64-byte alinged? > Both are aligned to 64-bit as they suppose to be IIUC. On a 64-bit kernel sizeof struct page == 64 (after much work by people to trim out excess stuff). So I thought we made sure to align the base address of blocks of

Re: [BUG] function_graph trace causes hang when using sleepgraph (4.15.0-rc1 and newer)

On Tue, 2018-01-09 at 11:13 -0500, Steven Rostedt wrote: > On Mon, 08 Jan 2018 17:25:15 -0800 > Todd Brandt wrote: > > > Can you reproduce the issue there? I just want to be sure it's not > > something local to our machines here, as long as you have CONFIG_PM > >

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Thu, 2018-01-18 at 12:03 -0500, Mike Snitzer wrote: > On Thu, Jan 18 2018 at 11:50am -0500, > Bart Van Assche wrote: > > My comments about the above are as follows: > > - It can take up to q->rq_timeout jiffies after a .queue_rq() > > implementation returned

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu 18-01-18 18:40:26, Kirill A. Shutemov wrote: [...] > + /* > + * Make sure that pages are in the same section before doing pointer > + * arithmetics. > + */ > + if (page_to_section(pvmw->page) != page_to_section(page)) > + return false; OK, THPs shouldn't

Re: [BUG] function_graph trace causes hang when using sleepgraph (4.15.0-rc1 and newer)

On Tue, 2018-01-09 at 11:13 -0500, Steven Rostedt wrote: > On Mon, 08 Jan 2018 17:25:15 -0800 > Todd Brandt wrote: > > > Can you reproduce the issue there? I just want to be sure it's not > > something local to our machines here, as long as you have CONFIG_PM > > enabled it should work the same

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Thu, 2018-01-18 at 12:03 -0500, Mike Snitzer wrote: > On Thu, Jan 18 2018 at 11:50am -0500, > Bart Van Assche wrote: > > My comments about the above are as follows: > > - It can take up to q->rq_timeout jiffies after a .queue_rq() > > implementation returned BLK_STS_RESOURCE before

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu 18-01-18 18:40:26, Kirill A. Shutemov wrote: [...] > + /* > + * Make sure that pages are in the same section before doing pointer > + * arithmetics. > + */ > + if (page_to_section(pvmw->page) != page_to_section(page)) > + return false; OK, THPs shouldn't

Re: [PATCH 3/3] phy: rockchip-typec: reset USB3 controller before initializing PHY

2018-01-12 11:08 GMT+01:00 William Wu : > According to the RK3399 TRM, for Type-C USB start-up sequence, > we need to hold the whole USB 3.0 OTG controller in reset state > to keep the PIPE power state in P2 while initializing PHY. This > is because when initialize the

Re: [PATCH 2/3] arm64: dts: rockchip: add USB3 OTG reset for Type-C PHY on rk3399

2018-01-12 11:08 GMT+01:00 William Wu : > Add USB3 OTG reset for Type-C PHY. It can be used to hold the USB3 > OTG controller in reset state before initializing the Type-C PHY. > > Signed-off-by: William Wu > --- >

Re: [PATCH 2/3] arm64: dts: rockchip: add USB3 OTG reset for Type-C PHY on rk3399

2018-01-12 11:08 GMT+01:00 William Wu : > Add USB3 OTG reset for Type-C PHY. It can be used to hold the USB3 > OTG controller in reset state before initializing the Type-C PHY. > > Signed-off-by: William Wu > --- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++ > 1 file changed, 6

Re: [PATCH 3/3] phy: rockchip-typec: reset USB3 controller before initializing PHY

2018-01-12 11:08 GMT+01:00 William Wu : > According to the RK3399 TRM, for Type-C USB start-up sequence, > we need to hold the whole USB 3.0 OTG controller in reset state > to keep the PIPE power state in P2 while initializing PHY. This > is because when initialize the Type-C PHY for USB3, we need

Re: [PATCH 1/3] dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset

2018-01-17 23:07 GMT+01:00 Brian Norris : > + Enric > > On Fri, Jan 12, 2018 at 06:08:22PM +0800, William Wu wrote: >> This patch adds USB3 OTG reset property for rk3399 Type-C PHY >> to hold the USB3 controller in reset state. >> >> Signed-off-by: William Wu

Re: [PATCH 1/3] dt-bindings: phy: phy-rockchip-typec: add usb3 otg reset

2018-01-17 23:07 GMT+01:00 Brian Norris : > + Enric > > On Fri, Jan 12, 2018 at 06:08:22PM +0800, William Wu wrote: >> This patch adds USB3 OTG reset property for rk3399 Type-C PHY >> to hold the USB3 controller in reset state. >> >> Signed-off-by: William Wu >> --- > > I was going back and forth

Re: [PATCH v3 00/14] Add MMCI support for STM32F SoCs family

On 18 January 2018 at 15:34, wrote: > From: Patrice Chotard > > This series reworks patches submitted one year ago by Andrea Merello [1] > but without succeed to merged it. > > STM32F4 and STM32F7 SoCs families embeds a variant of the ARM

Re: [PATCH v3 00/14] Add MMCI support for STM32F SoCs family

On 18 January 2018 at 15:34, wrote: > From: Patrice Chotard > > This series reworks patches submitted one year ago by Andrea Merello [1] > but without succeed to merged it. > > STM32F4 and STM32F7 SoCs families embeds a variant of the ARM PrimeCell > PL18x SD host controller, for which the mmci

Re: [PATCH v7 11/14] MIPS: ingenic: Initial JZ4770 support

Hi James, Le mer. 17 janv. 2018 à 22:28, James Hogan a écrit : On Tue, Jan 16, 2018 at 04:48:01PM +0100, Paul Cercueil wrote: Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by:

Re: [PATCH v7 11/14] MIPS: ingenic: Initial JZ4770 support

Hi James, Le mer. 17 janv. 2018 à 22:28, James Hogan a écrit : On Tue, Jan 16, 2018 at 04:48:01PM +0100, Paul Cercueil wrote: Provide just enough bits (clocks, clocksource, uart) to allow a kernel to boot on the JZ4770 SoC to a initramfs userspace. Signed-off-by: Paul Cercueil

[PATCH] irq-imgpdc: Delete two error messages for a failed memory allocation in pdc_intc_probe()

From: Markus Elfring Date: Thu, 18 Jan 2018 18:05:46 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] irq-imgpdc: Delete two error messages for a failed memory allocation in pdc_intc_probe()

From: Markus Elfring Date: Thu, 18 Jan 2018 18:05:46 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/irqchip/irq-imgpdc.c | 10 -- 1 file changed, 4

Re: [RFC] Per file OOM badness

On Thu 18-01-18 18:00:06, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > Hi, this series is a revised version of an RFC sent by Christian König > > a few years ago. The original RFC can be found at > >

Re: [RFC] Per file OOM badness

On Thu 18-01-18 18:00:06, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > Hi, this series is a revised version of an RFC sent by Christian König > > a few years ago. The original RFC can be found at > >

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 18/01/2018 18:08, Dave Hansen wrote: > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: >>> >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -3932,6 +3932,7 @@ >>> retpoline - replace indirect

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 18/01/2018 18:08, Dave Hansen wrote: > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: >>> >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -3932,6 +3932,7 @@ >>> retpoline - replace indirect

Re: [RFC][PATCH] get rid of the use of set_fs() (by way of kernel_recvmsg()) in sunrpc

On Thu, Jan 18, 2018 at 08:29:57AM -0800, Christoph Hellwig wrote: > > We could turn ->msg_control/->msg_controllen into another > > iov_iter, but seeing that we never do scatter-gather for those > > IMO that would be a massive overkill. A flag controlling whether > > ->msg_control is kernel

Re: [RFC][PATCH] get rid of the use of set_fs() (by way of kernel_recvmsg()) in sunrpc

On Thu, Jan 18, 2018 at 08:29:57AM -0800, Christoph Hellwig wrote: > > We could turn ->msg_control/->msg_controllen into another > > iov_iter, but seeing that we never do scatter-gather for those > > IMO that would be a massive overkill. A flag controlling whether > > ->msg_control is kernel

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: >> >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -3932,6 +3932,7 @@ >> retpoline - replace indirect branches >>

Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: >> >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -3932,6 +3932,7 @@ >> retpoline - replace indirect branches >>

RE: [PATCH v2] r8152: disable RX aggregation on Dell TB16 dock

> -Original Message- > From: Kai Heng Feng [mailto:kai.heng.f...@canonical.com] > Sent: Thursday, January 18, 2018 10:57 AM > To: David Miller > Cc: Hayes Wang ; gre...@linuxfoundation.org; linux- > u...@vger.kernel.org; net...@vger.kernel.org;

RE: [PATCH v2] r8152: disable RX aggregation on Dell TB16 dock

> -Original Message- > From: Kai Heng Feng [mailto:kai.heng.f...@canonical.com] > Sent: Thursday, January 18, 2018 10:57 AM > To: David Miller > Cc: Hayes Wang ; gre...@linuxfoundation.org; linux- > u...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; > Limonciello,

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote: > On 17 January 2018 at 05:31, Alexander Shishkin > wrote: > > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote: > >> > index 39106ae61b..d7a11faac1 100644 > >> > ---

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote: > On 17 January 2018 at 05:31, Alexander Shishkin > wrote: > > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote: > >> > index 39106ae61b..d7a11faac1 100644 > >> > --- a/kernel/events/core.c > >> > +++

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 08:58:08AM -0800, Dan Williams wrote: > On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote: > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: > >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds > >>

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 08:58:08AM -0800, Dan Williams wrote: > On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote: > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: > >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds > >> wrote: > >> > On Thu, Jan 11, 2018 at 4:46 PM, Dan

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Thu, Jan 18 2018 at 11:50am -0500, Bart Van Assche wrote: > On 01/17/18 18:41, Ming Lei wrote: > >BLK_STS_RESOURCE can be returned from driver when any resource > >is running out of. And the resource may not be related with tags, > >such as kmalloc(GFP_ATOMIC), when

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On Thu, Jan 18 2018 at 11:50am -0500, Bart Van Assche wrote: > On 01/17/18 18:41, Ming Lei wrote: > >BLK_STS_RESOURCE can be returned from driver when any resource > >is running out of. And the resource may not be related with tags, > >such as kmalloc(GFP_ATOMIC), when queue is idle under this

Re: [tip:x86/pti] module: Add retpoline tag to VERMAGIC

On Wed, Jan 17, 2018 at 02:40:43AM -0800, tip-bot for Andi Kleen wrote: > Commit-ID: 6cfb521ac0d5b97470883ff9b7facae264b7ab12 > Gitweb: > https://git.kernel.org/tip/6cfb521ac0d5b97470883ff9b7facae264b7ab12 > Author: Andi Kleen > AuthorDate: Tue, 16 Jan 2018

Re: [tip:x86/pti] module: Add retpoline tag to VERMAGIC

On Wed, Jan 17, 2018 at 02:40:43AM -0800, tip-bot for Andi Kleen wrote: > Commit-ID: 6cfb521ac0d5b97470883ff9b7facae264b7ab12 > Gitweb: > https://git.kernel.org/tip/6cfb521ac0d5b97470883ff9b7facae264b7ab12 > Author: Andi Kleen > AuthorDate: Tue, 16 Jan 2018 12:52:28 -0800 > Committer:

Re: [PATCH v3 00/14] Add MMCI support for STM32F SoCs family

Hi Patrice, On 01/18/2018 03:34 PM, patrice.chot...@st.com wrote: From: Patrice Chotard This series reworks patches submitted one year ago by Andrea Merello [1] but without succeed to merged it. STM32F4 and STM32F7 SoCs families embeds a variant of the ARM PrimeCell

Re: [PATCH v3 00/14] Add MMCI support for STM32F SoCs family

Hi Patrice, On 01/18/2018 03:34 PM, patrice.chot...@st.com wrote: From: Patrice Chotard This series reworks patches submitted one year ago by Andrea Merello [1] but without succeed to merged it. STM32F4 and STM32F7 SoCs families embeds a variant of the ARM PrimeCell PL18x SD host

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 05:56:12PM +0100, David Sterba wrote: > On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > > Thank you! I shall attempt to debug. Was this with a btrfs root > > filesystem? I'm most suspicious of those patches right now, since they've > > received next to

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 05:56:12PM +0100, David Sterba wrote: > On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > > Thank you! I shall attempt to debug. Was this with a btrfs root > > filesystem? I'm most suspicious of those patches right now, since they've > > received next to

Re: [RFC 4/6] softirq: Run per-group per-cpu ksoftirqd thread

On Thu, 2018-01-18 at 16:12 +, Dmitry Safonov wrote: > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > index 2ea09896bd6e..17e1a04445fa 100644 > --- a/include/linux/interrupt.h > +++ b/include/linux/interrupt.h > @@ -508,11 +508,21 @@ extern void

Re: [RFC 4/6] softirq: Run per-group per-cpu ksoftirqd thread

On Thu, 2018-01-18 at 16:12 +, Dmitry Safonov wrote: > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > index 2ea09896bd6e..17e1a04445fa 100644 > --- a/include/linux/interrupt.h > +++ b/include/linux/interrupt.h > @@ -508,11 +508,21 @@ extern void

Re: [RFC] Per file OOM badness

On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > Hi, this series is a revised version of an RFC sent by Christian König > a few years ago. The original RFC can be found at > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > This is the same idea and I've just

Re: [RFC] Per file OOM badness

On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > Hi, this series is a revised version of an RFC sent by Christian König > a few years ago. The original RFC can be found at > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > This is the same idea and I've just

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On 17 January 2018 at 05:31, Alexander Shishkin wrote: > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote: >> > index 39106ae61b..d7a11faac1 100644 >> > --- a/kernel/events/core.c >> > +++ b/kernel/events/core.c >> > @@ -8194,7 +8194,8 @@ static

Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure

On 17 January 2018 at 05:31, Alexander Shishkin wrote: > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote: >> > index 39106ae61b..d7a11faac1 100644 >> > --- a/kernel/events/core.c >> > +++ b/kernel/events/core.c >> > @@ -8194,7 +8194,8 @@ static void

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 6:38 AM, Dave Hansen wrote: > On 01/18/2018 05:12 AM, Kirill A. Shutemov wrote: >> - if (pte_page(*pvmw->pte) - pvmw->page >= >> - hpage_nr_pages(pvmw->page)) { > > Is ->pte guaranteed to map a page which

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 6:38 AM, Dave Hansen wrote: > On 01/18/2018 05:12 AM, Kirill A. Shutemov wrote: >> - if (pte_page(*pvmw->pte) - pvmw->page >= >> - hpage_nr_pages(pvmw->page)) { > > Is ->pte guaranteed to map a page which is within the same section

Re: [PATCH] kconfig: Clarify choice dependency propagation

On Thu, Jan 18, 2018 at 5:47 PM, Masahiro Yamada wrote: > 2018-01-14 23:12 GMT+09:00 Ulf Magnusson : >> It's easy to miss that choices are special-cased to pass on their mode >> as the parent dependency. >> >> No functional changes. Only

Re: [PATCH] kconfig: Clarify choice dependency propagation

On Thu, Jan 18, 2018 at 5:47 PM, Masahiro Yamada wrote: > 2018-01-14 23:12 GMT+09:00 Ulf Magnusson : >> It's easy to miss that choices are special-cased to pass on their mode >> as the parent dependency. >> >> No functional changes. Only comments added. >> >> Signed-off-by: Ulf Magnusson >> ---

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote: > Hi Dan, Linus, > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds >> wrote: >> > On Thu, Jan 11, 2018 at 4:46 PM, Dan

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote: > Hi Dan, Linus, > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds >> wrote: >> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams >> > wrote: >> >> >> >> This series

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > Thank you! I shall attempt to debug. Was this with a btrfs root > filesystem? I'm most suspicious of those patches right now, since they've > received next to no testing. I'm going to put together a smaller patchset > which just

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 08:48:43AM -0800, Matthew Wilcox wrote: > Thank you! I shall attempt to debug. Was this with a btrfs root > filesystem? I'm most suspicious of those patches right now, since they've > received next to no testing. I'm going to put together a smaller patchset > which just

Re: [PATCH v2] r8152: disable RX aggregation on Dell TB16 dock

> On 18 Jan 2018, at 10:50 PM, David Miller wrote: > > From: Hayes Wang > Date: Thu, 18 Jan 2018 03:04:08 + > >> [...] r8153 on Dell TB15/16 dock corrupts rx packets. This change is suggested by Realtek. They guess that the XHCI

Re: [PATCH v2] r8152: disable RX aggregation on Dell TB16 dock

> On 18 Jan 2018, at 10:50 PM, David Miller wrote: > > From: Hayes Wang > Date: Thu, 18 Jan 2018 03:04:08 + > >> [...] r8153 on Dell TB15/16 dock corrupts rx packets. This change is suggested by Realtek. They guess that the XHCI controller doesn't have enough buffer,

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 03:58:30PM +0100, Andrea Arcangeli wrote: > On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > > [ 10.084024] diff: -858690919 > > > [ 10.084258] hpage_nr_pages: 1 > > > [ 10.084386] check1: 0 > > > [

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Thu, Jan 18, 2018 at 03:58:30PM +0100, Andrea Arcangeli wrote: > On Thu, Jan 18, 2018 at 06:45:00AM -0800, Dave Hansen wrote: > > On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote: > > > [ 10.084024] diff: -858690919 > > > [ 10.084258] hpage_nr_pages: 1 > > > [ 10.084386] check1: 0 > > > [

Re: [PATCH] usb: dwc3: core: power on PHYs before initializing core

2018-01-17 22:46 GMT+01:00 Brian Norris : > On Fri, Jan 12, 2018 at 12:00:16PM +0800, William Wu wrote: >> The dwc3_core_init() gets the PHYs and initializes the PHYs with >> the usb_phy_init() and phy_init() functions before initializing >> core, and power on the PHYs

Re: [PATCH] usb: dwc3: core: power on PHYs before initializing core

2018-01-17 22:46 GMT+01:00 Brian Norris : > On Fri, Jan 12, 2018 at 12:00:16PM +0800, William Wu wrote: >> The dwc3_core_init() gets the PHYs and initializes the PHYs with >> the usb_phy_init() and phy_init() functions before initializing >> core, and power on the PHYs after core initialization is

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 01/17/18 18:41, Ming Lei wrote: BLK_STS_RESOURCE can be returned from driver when any resource is running out of. And the resource may not be related with tags, such as kmalloc(GFP_ATOMIC), when queue is idle under this kind of BLK_STS_RESOURCE, restart can't work any more, then IO hang may

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 01/17/18 18:41, Ming Lei wrote: BLK_STS_RESOURCE can be returned from driver when any resource is running out of. And the resource may not be related with tags, such as kmalloc(GFP_ATOMIC), when queue is idle under this kind of BLK_STS_RESOURCE, restart can't work any more, then IO hang may

[PATCH 2/4] oom: take per file badness into account

Try to make better decisions which process to kill based on per file OOM badness Signed-off-by: Andrey Grodzovsky --- mm/oom_kill.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 29f8555..825ed52 100644

[PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers

Large amounts of VRAM are usually not CPU accessible, so they are not mapped into the processes address space. But since the device drivers usually support swapping buffers from VRAM to system memory we can still run into an out of memory situation when userspace starts to allocate to much. This

[PATCH 2/4] oom: take per file badness into account

Try to make better decisions which process to kill based on per file OOM badness Signed-off-by: Andrey Grodzovsky --- mm/oom_kill.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 29f8555..825ed52 100644 --- a/mm/oom_kill.c +++

[PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers

Large amounts of VRAM are usually not CPU accessible, so they are not mapped into the processes address space. But since the device drivers usually support swapping buffers from VRAM to system memory we can still run into an out of memory situation when userspace starts to allocate to much. This

[PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu.

Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 46a0c93..6a733cdc8 100644 ---

Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Thu, Jan 18, 2018 at 8:38 AM, Christoph Hellwig wrote: > > > But there are about ~100 set_fs() calls in generic code, and some of > > those really are pretty fundamental. Doing things like "kernel_read()" > > without set_fs() is basically impossible. > > Not if we move to

[PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu.

Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 46a0c93..6a733cdc8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++

Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths

On Thu, Jan 18, 2018 at 8:38 AM, Christoph Hellwig wrote: > > > But there are about ~100 set_fs() calls in generic code, and some of > > those really are pretty fundamental. Doing things like "kernel_read()" > > without set_fs() is basically impossible. > > Not if we move to iov_iter or

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 05:07:50PM +0100, David Sterba wrote: > On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > This version of the XArray has no known bugs. > > I've booted this patchset on 2 boxes, both had random

Re: [PATCH v6 00/99] XArray version 6

On Thu, Jan 18, 2018 at 05:07:50PM +0100, David Sterba wrote: > On Wed, Jan 17, 2018 at 12:20:24PM -0800, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > This version of the XArray has no known bugs. > > I've booted this patchset on 2 boxes, both had random problems during > boot. On one

[PATCH 1/4] fs: add OOM badness callback in file_operatrations struct.

This allows device drivers to specify an additional badness for the OOM when they allocate memory on behalf of userspace. Signed-off-by: Andrey Grodzovsky --- include/linux/fs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/fs.h

[PATCH 1/4] fs: add OOM badness callback in file_operatrations struct.

This allows device drivers to specify an additional badness for the OOM when they allocate memory on behalf of userspace. Signed-off-by: Andrey Grodzovsky --- include/linux/fs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/fs.h b/include/linux/fs.h index 511fbaa..938394a

Re: [PATCH] kconfig: Clarify choice dependency propagation

2018-01-14 23:12 GMT+09:00 Ulf Magnusson : > It's easy to miss that choices are special-cased to pass on their mode > as the parent dependency. > > No functional changes. Only comments added. > > Signed-off-by: Ulf Magnusson > --- >

Re: [PATCH] kconfig: Clarify choice dependency propagation

2018-01-14 23:12 GMT+09:00 Ulf Magnusson : > It's easy to miss that choices are special-cased to pass on their mode > as the parent dependency. > > No functional changes. Only comments added. > > Signed-off-by: Ulf Magnusson > --- > scripts/kconfig/menu.c | 7 +++ > 1 file changed, 7

[RFC] Per file OOM badness

Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a

[RFC] Per file OOM badness

Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a

Re: [PATCH 3/5] powerpc/ftw: Implement a simple FTW driver

Randy Dunlap [rdun...@infradead.org] wrote: > > + > > + default: > > + return -EINVAL; > > + } > > +} > > Nit: some versions of gcc (or maybe clang) complain about a typed function > not always having a return value in code like above, so it is often done as: Ok. > > > +static

Re: [PATCH 3/5] powerpc/ftw: Implement a simple FTW driver

Randy Dunlap [rdun...@infradead.org] wrote: > > + > > + default: > > + return -EINVAL; > > + } > > +} > > Nit: some versions of gcc (or maybe clang) complain about a typed function > not always having a return value in code like above, so it is often done as: Ok. > > > +static

Re: Use arm64's scheme for registering first-level IRQ handlers on RISC-V

On Thu, Jan 18, 2018 at 4:40 PM, Palmer Dabbelt wrote: > This patch set has been sitting around for a while, but it got a bit lost in > the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for > interrupt handling) to our first-level interrupt controller.

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Jeff Moyer writes: > FYI, this kernel has issues. It will boot up, but I don't have > networking, and even rebooting doesn't succeed. I'm looking into it. A bisect lands on: eventfd: switch to ->poll_mask. That's not super helpful, though. I did run the ltp eventfd2

Re: Use arm64's scheme for registering first-level IRQ handlers on RISC-V

On Thu, Jan 18, 2018 at 4:40 PM, Palmer Dabbelt wrote: > This patch set has been sitting around for a while, but it got a bit lost in > the shuffle. In RISC-V land we currently couple do_IRQ (the C entry point for > interrupt handling) to our first-level interrupt controller. While this isn't >

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Jeff Moyer writes: > FYI, this kernel has issues. It will boot up, but I don't have > networking, and even rebooting doesn't succeed. I'm looking into it. A bisect lands on: eventfd: switch to ->poll_mask. That's not super helpful, though. I did run the ltp eventfd2 tests, and they all

Re: [PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API

Randy Dunlap [rdun...@infradead.org] wrote: > > +#define FTW_FLAGS_PIN_WINDOW 0x1 > > + > > +#define FTW_SETUP _IOW('v', 1, struct ftw_setup_attr) > > ioctls should be documented in Documentation/ioctl/ioctl-number.txt. > Please update that file. Ok. Here is the updated patch.

Re: [PATCH 2/5] powerpc/ftw: Define FTW_SETUP ioctl API

Randy Dunlap [rdun...@infradead.org] wrote: > > +#define FTW_FLAGS_PIN_WINDOW 0x1 > > + > > +#define FTW_SETUP _IOW('v', 1, struct ftw_setup_attr) > > ioctls should be documented in Documentation/ioctl/ioctl-number.txt. > Please update that file. Ok. Here is the updated patch.

Re: [PATCH] PCI: dwc: dra7xx: add back CONFIG_PCI dependency for endpoint

On Thu, Jan 18, 2018 at 4:03 PM, Niklas Cassel wrote: > On Thu, Jan 18, 2018 at 02:15:54PM +0100, Arnd Bergmann wrote: >> It was a nice idea to split out the PCI host and endpoint mode configuration >> into separate options. Unfortunately it doesn't build: >> >>

Re: [PATCH] PCI: dwc: dra7xx: add back CONFIG_PCI dependency for endpoint

On Thu, Jan 18, 2018 at 4:03 PM, Niklas Cassel wrote: > On Thu, Jan 18, 2018 at 02:15:54PM +0100, Arnd Bergmann wrote: >> It was a nice idea to split out the PCI host and endpoint mode configuration >> into separate options. Unfortunately it doesn't build: >> >>

Re: [PATCH 1/2] clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK

Hi Gabriel, Tested successfully on f469 disco board. Tested-by: Philippe Cornu Many thanks, Philippe :-) On 01/18/2018 03:49 PM, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > Update of END_PRIMARY_CLK was missed, it should be

Re: [PATCH 2/2] clk: stm32: Add DSI clock for STM32F469 Board

Hi Gabriel, Tested successfully on f469 disco board. Tested-by: Philippe Cornu Many thanks, Philippe :-) On 01/18/2018 03:49 PM, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch adds DSI clock for STM32F469 board > >

Re: [PATCH 1/2] clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK

Hi Gabriel, Tested successfully on f469 disco board. Tested-by: Philippe Cornu Many thanks, Philippe :-) On 01/18/2018 03:49 PM, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > Update of END_PRIMARY_CLK was missed, it should be after CLK_SYSCLK > hsi and sysclk are overwritten

Re: [PATCH 2/2] clk: stm32: Add DSI clock for STM32F469 Board

Hi Gabriel, Tested successfully on f469 disco board. Tested-by: Philippe Cornu Many thanks, Philippe :-) On 01/18/2018 03:49 PM, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch adds DSI clock for STM32F469 board > > Signed-off-by: Gabriel Fernandez > --- >

<    5   6   7   8   9   10   11   12   13   14   >