[PATCH v2 30/58] staging: lustre: create striped directory

From: wang di 1. client send create request to the master MDT, which will allocate FIDs and create slaves. for all of slaves. 2. Client needs to revalidate slaves during intent getattr and open request. 3. lmv_stripe_md will include attributes(size, nlink etc) from

[PATCH v2 30/58] staging: lustre: create striped directory

From: wang di 1. client send create request to the master MDT, which will allocate FIDs and create slaves. for all of slaves. 2. Client needs to revalidate slaves during intent getattr and open request. 3. lmv_stripe_md will include attributes(size, nlink etc) from all of stripe, which

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site for both

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site for both

[PATCH 2/4] x86/ioapic: Fix setup_res() failing to get resource

setup_res() doesn't actually get any resoure because it mistakenly checks the return value of acpi_dev_filter_resource_type(), which returns 0 on success, and 1 on failure. Fix it by taking the return value of non-zero as failing to match the specified resource type. Signed-off-by: Rui Wang

[PATCH 3/4] x86/ioapic: Fix lost ioapic resource after hot-removal and hotadd

ioapic resource at 0xfecx gets lost from /proc/iomem after hot-removing and then hot-adding the ioapic devices. After system boot, in /proc/iomem: fec0-fecf : PNP0003:00 fec0-fec003ff : IOAPIC 0 fec01000-fec013ff : IOAPIC 1 fec4-fec403ff : IOAPIC 2 fec8-fec803ff :

[PATCH 2/4] x86/ioapic: Fix setup_res() failing to get resource

setup_res() doesn't actually get any resoure because it mistakenly checks the return value of acpi_dev_filter_resource_type(), which returns 0 on success, and 1 on failure. Fix it by taking the return value of non-zero as failing to match the specified resource type. Signed-off-by: Rui Wang ---

[PATCH 3/4] x86/ioapic: Fix lost ioapic resource after hot-removal and hotadd

ioapic resource at 0xfecx gets lost from /proc/iomem after hot-removing and then hot-adding the ioapic devices. After system boot, in /proc/iomem: fec0-fecf : PNP0003:00 fec0-fec003ff : IOAPIC 0 fec01000-fec013ff : IOAPIC 1 fec4-fec403ff : IOAPIC 2 fec8-fec803ff :

[PATCH 1/4] x86/ioapic: Support hot-removal of IOAPICs present during boot

IOAPICs present during system boot aren't added to ioapic_list, thus are unable to be hot-removed. Fix it by calling acpi_ioapic_add() during root bus enumeration. Signed-off-by: Rui Wang --- drivers/acpi/internal.h | 2 -- drivers/acpi/ioapic.c | 7 ---

[PATCH 1/4] x86/ioapic: Support hot-removal of IOAPICs present during boot

IOAPICs present during system boot aren't added to ioapic_list, thus are unable to be hot-removed. Fix it by calling acpi_ioapic_add() during root bus enumeration. Signed-off-by: Rui Wang --- drivers/acpi/internal.h | 2 -- drivers/acpi/ioapic.c | 7 --- drivers/acpi/pci_root.c | 13

[PATCH 4/4] x86/ioapic: Fix ioapic failing to request resource

handle_ioapic_add() uses request_resource() to request ACPI "_CRS" resources. This can fail with the following error message: [ 247.325693] ACPI: \_SB_.IIO1.AID1: failed to insert resource This happens when there are multiple ioapics and DSDT groups their "_CRS" resources as the children of a

[PATCH 4/4] x86/ioapic: Fix ioapic failing to request resource

handle_ioapic_add() uses request_resource() to request ACPI "_CRS" resources. This can fail with the following error message: [ 247.325693] ACPI: \_SB_.IIO1.AID1: failed to insert resource This happens when there are multiple ioapics and DSDT groups their "_CRS" resources as the children of a

[PATCH 0/4] Fixing a set of bugs for ioapic hotplug

Hi all, The 1st patch has been discussed before Bjorn went on vacation. I've fixed all the issues. Bjorn, please advise how we'll move forward. The remaining patches fix newly found bugs while testing ioapic hotplug. Regards, Rui Rui Wang (4): x86/ioapic: Support hot-removal of IOAPICs

[PATCH 0/4] Fixing a set of bugs for ioapic hotplug

Hi all, The 1st patch has been discussed before Bjorn went on vacation. I've fixed all the issues. Bjorn, please advise how we'll move forward. The remaining patches fix newly found bugs while testing ioapic hotplug. Regards, Rui Rui Wang (4): x86/ioapic: Support hot-removal of IOAPICs

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

On Tue, 2016-07-26 at 23:32 +0800, Fengguang Wu wrote: > Hi Eric, > > It works! > > On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote: > >On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote: > >> Greetings, > >> > >> This BUG message can be found in recent kernels as well as v4.4

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

On Tue, 2016-07-26 at 23:32 +0800, Fengguang Wu wrote: > Hi Eric, > > It works! > > On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote: > >On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote: > >> Greetings, > >> > >> This BUG message can be found in recent kernels as well as v4.4

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: > On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: > >> > Unless I'm missing something, I think it should be fine for nested NMIs, > >> > since they're all on the same stack. I can try to test it. What

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Mon, Jul 25, 2016 at 05:09:44PM -0700, Andy Lutomirski wrote: > On Sat, Jul 23, 2016 at 7:04 AM, Josh Poimboeuf wrote: > >> > Unless I'm missing something, I think it should be fine for nested NMIs, > >> > since they're all on the same stack. I can try to test it. What in > >> > particular

[PATCH v1] usb: gadget: configfs: log function unbinding as information

Disabling USB gadget functions configured through configfs is something that can happen in normal use cases. Keep the existing log for this type of event, but only as information, not as an error. Signed-off-by: Romain Izard --- drivers/usb/gadget/configfs.c | 5

[PATCH v1] usb: gadget: configfs: log function unbinding as information

Disabling USB gadget functions configured through configfs is something that can happen in normal use cases. Keep the existing log for this type of event, but only as information, not as an error. Signed-off-by: Romain Izard --- drivers/usb/gadget/configfs.c | 5 +++-- 1 file changed, 3

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

On 07/26/2016 05:08 PM, Greg KH wrote: > On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote: >> On 07/25/2016 07:47 PM, Greg KH wrote: >>> Ick, don't add new module parameters if at all possible. >> >> I agree, I'd rather not add a parameter either, but... >> >> - It's a hardware issue >>

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

On 07/26/2016 05:08 PM, Greg KH wrote: > On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote: >> On 07/25/2016 07:47 PM, Greg KH wrote: >>> Ick, don't add new module parameters if at all possible. >> >> I agree, I'd rather not add a parameter either, but... >> >> - It's a hardware issue >>

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tue, Jul 26, 2016 at 12:00:33PM +0200, Alexander Stein wrote: > On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote: > > On 26/07/2016 11:05, Alexander Stein wrote: > > > On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > > >> On 26/07/2016 10:21, Alexander Stein wrote: > > >>> On

Re: [PATCH v3 1/4] hwmon: iio_hwmon: delay probing with late_initcall

On Tue, Jul 26, 2016 at 12:00:33PM +0200, Alexander Stein wrote: > On Tuesday 26 July 2016 11:33:59, Quentin Schulz wrote: > > On 26/07/2016 11:05, Alexander Stein wrote: > > > On Tuesday 26 July 2016 10:24:48, Quentin Schulz wrote: > > >> On 26/07/2016 10:21, Alexander Stein wrote: > > >>> On

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote: > > > On 22.07.16 16:58, Grygorii Strashko wrote: >> Fix deadlock in cpdma_ctlr_destroy() which is triggered now on >> cpsw module removal: >> cpsw_remove() >> - cpdma_ctlr_destroy() >>- spin_lock_irqsave(>lock, flags) >>-

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote: > > > On 22.07.16 16:58, Grygorii Strashko wrote: >> Fix deadlock in cpdma_ctlr_destroy() which is triggered now on >> cpsw module removal: >> cpsw_remove() >> - cpdma_ctlr_destroy() >>- spin_lock_irqsave(>lock, flags) >>-

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

On 07/26/2016 08:44 AM, Jia He wrote: > This patch is to fix such soft lockup. I thouhgt it is safe to call > cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page > are out of spin_lock/unlock section. Yikes. So the call site for both the things you patch is this: >

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

On 07/26/2016 08:44 AM, Jia He wrote: > This patch is to fix such soft lockup. I thouhgt it is safe to call > cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page > are out of spin_lock/unlock section. Yikes. So the call site for both the things you patch is this: >

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 09:44:27PM -0700, Kees Cook wrote: > On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: > > To date, all callers of randomize_range() have set the length to 0, and > > check for a zero return value. For the current callers, the only way > > to get

Re: [RFC patch 1/6] random: Simplify API for random address requests

On Mon, Jul 25, 2016 at 09:44:27PM -0700, Kees Cook wrote: > On Mon, Jul 25, 2016 at 8:01 PM, Jason Cooper wrote: > > To date, all callers of randomize_range() have set the length to 0, and > > check for a zero return value. For the current callers, the only way > > to get zero returned is if

Re: [PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Tue, Jul 26, 2016 at 04:58:10PM +0800, Bob Liu wrote: > > On 07/26/2016 04:44 PM, Roger Pau Monné wrote: > > On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote: > >> The current VBD layer reserves buffer space for each attached device based > >> on > >> three statically configured

Re: [PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Tue, Jul 26, 2016 at 04:58:10PM +0800, Bob Liu wrote: > > On 07/26/2016 04:44 PM, Roger Pau Monné wrote: > > On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote: > >> The current VBD layer reserves buffer space for each attached device based > >> on > >> three statically configured

Re: [PATCH] hwmon: iio_hwmon: fix memory leak in name attribute

On Tue, Jul 26, 2016 at 09:47:09AM +0200, Quentin Schulz wrote: > The "name" variable's memory is now freed when the device is destructed > thanks to devm function. > > Signed-off-by: Quentin Schulz > Reported-by: Guenter Roeck Applied.

Re: [PATCH] hwmon: iio_hwmon: fix memory leak in name attribute

On Tue, Jul 26, 2016 at 09:47:09AM +0200, Quentin Schulz wrote: > The "name" variable's memory is now freed when the device is destructed > thanks to devm function. > > Signed-off-by: Quentin Schulz > Reported-by: Guenter Roeck Applied. Thanks, Guenter > --- > drivers/hwmon/iio_hwmon.c | 24

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Tue, Jul 26, 2016 at 07:23:57AM -0700, Greg Kroah-Hartman wrote: > On Tue, Jul 26, 2016 at 06:53:48AM -0700, Guenter Roeck wrote: > > On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.6.5 release. > > > There are 203 patches in this

Re: [PATCH 4.6 000/203] 4.6.5-stable review

On Tue, Jul 26, 2016 at 07:23:57AM -0700, Greg Kroah-Hartman wrote: > On Tue, Jul 26, 2016 at 06:53:48AM -0700, Guenter Roeck wrote: > > On 07/25/2016 01:53 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 4.6.5 release. > > > There are 203 patches in this

Re: [PATCH v2] staging: emxx_udc: allow modular build

On Mon, Jul 25, 2016 at 04:54:00PM +1000, Stephen Rothwell wrote: > Hi Linus, > > I have been using the following patch as a merge resolution in the > merge of the usb tree for a while now. Greg seems to have missed it > when asking you to merge his tree ... It now applies cleanly to your >

Re: [PATCH v2] staging: emxx_udc: allow modular build

On Mon, Jul 25, 2016 at 04:54:00PM +1000, Stephen Rothwell wrote: > Hi Linus, > > I have been using the following patch as a merge resolution in the > merge of the usb tree for a while now. Greg seems to have missed it > when asking you to merge his tree ... It now applies cleanly to your >

[RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

In large memory(32TB) powerpc servers, we watched several soft lockup under stress tests. The call trace are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2.

[RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

In large memory(32TB) powerpc servers, we watched several soft lockup under stress tests. The call trace are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2.

RE: Why does BIOS assign memory to 16 byte BAR

Adding yinghai lu. > > > > Subject: Re: Why does BIOS assign memory to 16 byte BAR > > > > > > > > On Fri, Jul 22, 2016 at 10:15:46AM -0500, Bjorn Helgaas wrote: > > > > > Hi Bharat, > > > > > > > > > > On Fri, Jul 22, 2016 at 09:24:22AM +, Bharat Kumar Gogada wrote: > > > > > > Hi, > > > > >

RE: Why does BIOS assign memory to 16 byte BAR

Adding yinghai lu. > > > > Subject: Re: Why does BIOS assign memory to 16 byte BAR > > > > > > > > On Fri, Jul 22, 2016 at 10:15:46AM -0500, Bjorn Helgaas wrote: > > > > > Hi Bharat, > > > > > > > > > > On Fri, Jul 22, 2016 at 09:24:22AM +, Bharat Kumar Gogada wrote: > > > > > > Hi, > > > > >

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Mon, Jul 25, 2016 at 03:56:48PM +0100, Jon Hunter wrote: > > When tearing down, call timers_dead_cpu before notify_dead. > > There is a hidden dependency between: > > > > - timers > > - Block multiqueue > > - rcutree > > > > If timers_dead_cpu() comes later than

Re: [patch 61/66] timers: Convert to hotplug state machine

Jon, On Mon, Jul 25, 2016 at 03:56:48PM +0100, Jon Hunter wrote: > > When tearing down, call timers_dead_cpu before notify_dead. > > There is a hidden dependency between: > > > > - timers > > - Block multiqueue > > - rcutree > > > > If timers_dead_cpu() comes later than

Re: [PATCH] USB: appledisplay: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 11:11:18AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "wq" is involved in controlling the brightness of an > Apple Cinema Display over USB. > > It has a single work item(>work) per appledisplay and hence > doesn't require ordering. Also, it is not being used on a

Re: [PATCH] USB: appledisplay: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 11:11:18AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "wq" is involved in controlling the brightness of an > Apple Cinema Display over USB. > > It has a single work item(>work) per appledisplay and hence > doesn't require ordering. Also, it is not being used on a

Re: [PATCH] usb: ftdi-elan: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:47:20AM +0530, Bhaktipriya Shridhar wrote: > The status workqueue is involved in initializing the Uxxx and polling > the Uxxx until a supported PCMCIA CardBus device is detected. > It then starts the command and respond workqueues and then loads the > module that handles

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

Hi Stefan, On Mon, Jul 25, 2016 at 03:37:23PM +0300, Stefan Mavrodiev wrote: > A33-OLinuXino is A33 development board designed by Olimex LTD. > > It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector, > headphone and mic jacks, connector for LiPo battery and optional > 4GB NAND

Re: [PATCH] usb: ftdi-elan: Remove deprecated create_singlethread_workqueue

On Tue, Jul 26, 2016 at 10:47:20AM +0530, Bhaktipriya Shridhar wrote: > The status workqueue is involved in initializing the Uxxx and polling > the Uxxx until a supported PCMCIA CardBus device is detected. > It then starts the command and respond workqueues and then loads the > module that handles

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

Hi Stefan, On Mon, Jul 25, 2016 at 03:37:23PM +0300, Stefan Mavrodiev wrote: > A33-OLinuXino is A33 development board designed by Olimex LTD. > > It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector, > headphone and mic jacks, connector for LiPo battery and optional > 4GB NAND

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

On 26/07/16 13:15, Juergen Gross wrote: > pv_time_ops might be overwritten with xen_time_ops after the > steal_clock operation has been initialized already. To prevent calling > a now uninitialized function pointer add the steal_clock static > initialization to xen_time_ops. Applied to

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

On 26/07/16 13:15, Juergen Gross wrote: > pv_time_ops might be overwritten with xen_time_ops after the > steal_clock operation has been initialized already. To prevent calling > a now uninitialized function pointer add the steal_clock static > initialization to xen_time_ops. Applied to

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Hi Eric, It works! On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote: On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote: Greetings, This BUG message can be found in recent kernels as well as v4.4 and linux-stable. It happens when running modprobe netconsole

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Hi Eric, It works! On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote: On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote: Greetings, This BUG message can be found in recent kernels as well as v4.4 and linux-stable. It happens when running modprobe netconsole

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

"Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

"Michael Kerrisk (man-pages)" writes: > Hello Eric, > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for sandboxes to limit the attack surface from >> namespaces.

RE: Why does BIOS assign memory to 16 byte BAR

> Subject: RE: Why does BIOS assign memory to 16 byte BAR > > > Subject: RE: Why does BIOS assign memory to 16 byte BAR > > > > > Subject: Re: Why does BIOS assign memory to 16 byte BAR > > > > > > On Fri, Jul 22, 2016 at 10:15:46AM -0500, Bjorn Helgaas wrote: > > > > Hi Bharat, > > > > > > > >

RE: Why does BIOS assign memory to 16 byte BAR

> Subject: RE: Why does BIOS assign memory to 16 byte BAR > > > Subject: RE: Why does BIOS assign memory to 16 byte BAR > > > > > Subject: Re: Why does BIOS assign memory to 16 byte BAR > > > > > > On Fri, Jul 22, 2016 at 10:15:46AM -0500, Bjorn Helgaas wrote: > > > > Hi Bharat, > > > > > > > >

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

Hi Jean, On Tue, Jul 26, 2016 at 12:41 AM, Jean Delvare wrote: > Hi Viresh, > > On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote: >> On 25-07-16, 11:39, Jean Delvare wrote: >> > The problem is that the patch proposed by Viresh has nothing to do with >> > this. It's not

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

Hi Jean, On Tue, Jul 26, 2016 at 12:41 AM, Jean Delvare wrote: > Hi Viresh, > > On Mon, 25 Jul 2016 15:31:40 -0700, Viresh Kumar wrote: >> On 25-07-16, 11:39, Jean Delvare wrote: >> > The problem is that the patch proposed by Viresh has nothing to do with >> > this. It's not adding

Re: [PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Tue, Jul 26, 2016 at 04:58:58PM +0200, Maarten Lankhorst wrote: > Op 26-07-16 om 16:50 schreef Lyude: > > Since the watermark calculations for Skylake are still broken, we're apt > > to hitting underruns very easily under multi-monitor configurations. > > While it would be lovely if this was

Re: [PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Tue, Jul 26, 2016 at 04:58:58PM +0200, Maarten Lankhorst wrote: > Op 26-07-16 om 16:50 schreef Lyude: > > Since the watermark calculations for Skylake are still broken, we're apt > > to hitting underruns very easily under multi-monitor configurations. > > While it would be lovely if this was

Re: [PATCH] lkdtm: fix maybe-uninitialized warning

On Tue, Jul 26, 2016 at 5:28 AM, Arnd Bergmann wrote: > The do_usercopy_stack() function uses uninitialized stack data to initialize > more of the stack, which causes a warning in some configurations (ARM > allmodconfig): > > drivers/misc/lkdtm_usercopy.c:52:15: warning:

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

"Michael Kerrisk (man-pages)" writes: > Hello Eric, > > I realized I had a question after the last mail. > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> -

Re: [PATCH] lkdtm: fix maybe-uninitialized warning

On Tue, Jul 26, 2016 at 5:28 AM, Arnd Bergmann wrote: > The do_usercopy_stack() function uses uninitialized stack data to initialize > more of the stack, which causes a warning in some configurations (ARM > allmodconfig): > > drivers/misc/lkdtm_usercopy.c:52:15: warning: 'bad_stack' may be used

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

"Michael Kerrisk (man-pages)" writes: > Hello Eric, > > I realized I had a question after the last mail. > > On 07/21/2016 06:39 PM, Eric W. Biederman wrote: >> >> This patchset addresses two use cases: >> - Implement a sane upper bound on the number of namespaces. >> - Provide a way for

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

On Tue, Jul 26, 2016 at 09:52:40AM -0500, Eric W. Biederman wrote: Fengguang Wu writes: On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: kernel test robot writes: [snip] [ 19.206454] VFS: Warning: trinity-c0 using old

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

On Tue, Jul 26, 2016 at 09:52:40AM -0500, Eric W. Biederman wrote: Fengguang Wu writes: On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: kernel test robot writes: [snip] [ 19.206454] VFS: Warning: trinity-c0 using old stat() call. Recompile your binary. Elapsed time:

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi, On Mon, Jul 25, 2016 at 10:08:39AM -0700, Dmitry Torokhov wrote: > > > > ... but your driver isn't registered yet. How does input_report and > > > > input_sync behave in such a case? > > > > > > This is explicitly allowed: > > > > > > " > > > ... > > > * NOTE: input_event() may be safely

Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen

Hi, On Mon, Jul 25, 2016 at 10:08:39AM -0700, Dmitry Torokhov wrote: > > > > ... but your driver isn't registered yet. How does input_report and > > > > input_sync behave in such a case? > > > > > > This is explicitly allowed: > > > > > > " > > > ... > > > * NOTE: input_event() may be safely

RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

Hi Andrew, Thanks for the inputs... > > > > > > Hi Kedareswara > > > > > > > > So looking at the device tree, you have the gmiitorgmii as an mdio > > > > device. It will get probed as an mdio device, and from that you > > > > know the address on the bus. However, your driver does not > >

RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

Hi Andrew, Thanks for the inputs... > > > > > > Hi Kedareswara > > > > > > > > So looking at the device tree, you have the gmiitorgmii as an mdio > > > > device. It will get probed as an mdio device, and from that you > > > > know the address on the bus. However, your driver does not > >

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote: > On 07/25/2016 07:47 PM, Greg KH wrote: > > On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote: > >> Some serial ports may not emit IRQs properly, or there may be a defect > >> in their routing on the motherboard. > >> > >> This

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote: > On 07/25/2016 07:47 PM, Greg KH wrote: > > On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote: > >> Some serial ports may not emit IRQs properly, or there may be a defect > >> in their routing on the motherboard. > >> > >> This

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

Fengguang Wu writes: > On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: >>kernel test robot writes: [snip] >>> >>> [ 19.206454] VFS: Warning: trinity-c0 using old stat() call. Recompile >>> your binary. >>> >>> Elapsed time: 70

Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed

Fengguang Wu writes: > On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: >>kernel test robot writes: [snip] >>> >>> [ 19.206454] VFS: Warning: trinity-c0 using old stat() call. Recompile >>> your binary. >>> >>> Elapsed time: 70 >>> BUG: kernel test crashed >> >>What

Re: [PATCH v4 4/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED

Hi Mitch, On 25/07/16 20:16, Mitchel Humpherys wrote: > The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that > are only accessible to privileged DMA engines. Implement it in > dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. > > Signed-off-by: Mitchel

Re: [PATCH v4 4/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED

Hi Mitch, On 25/07/16 20:16, Mitchel Humpherys wrote: > The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that > are only accessible to privileged DMA engines. Implement it in > dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it. > > Signed-off-by: Mitchel

[GIT PULL] userns related vfs enhancements for v4.8

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: aeaa4a79ff6a5ed912b7362f206cf8576fca538b fs: Call d_automount with the filesystems creds [ Merging note. There are some minor merge

[GIT PULL] userns related vfs enhancements for v4.8

Linus, Please pull the for-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus HEAD: aeaa4a79ff6a5ed912b7362f206cf8576fca538b fs: Call d_automount with the filesystems creds [ Merging note. There are some minor merge

[PATCH -next] rtc: asm9260: remove .owner field for driver

Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Wei Yongjun --- drivers/rtc/rtc-asm9260.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/rtc/rtc-asm9260.c

[PATCH -next] rtc: asm9260: remove .owner field for driver

Remove .owner field if calls are used which set it automatically. Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Signed-off-by: Wei Yongjun --- drivers/rtc/rtc-asm9260.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/rtc/rtc-asm9260.c b/drivers/rtc/rtc-asm9260.c

Re: [PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Op 26-07-16 om 16:50 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this however, is

Re: [PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Op 26-07-16 om 16:50 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this however, is

[PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v3 4/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-)

[PATCH v3 4/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH v3 5/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v3 5/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v3 3/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[PATCH v3 3/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[PATCH v3 6/6] drm/i915/skl: Always wait for pipes to update after a flush

Unfortunately right now we don't really update watermarks on Skylake properly, since ideally we'd be updating both the ddb allocations, plane properties, and watermarks all in a single go. Until this is fixed however, we can improve things somewhat by adding a vblank wait after the third iteration

[PATCH v3 6/6] drm/i915/skl: Always wait for pipes to update after a flush

Unfortunately right now we don't really update watermarks on Skylake properly, since ideally we'd be updating both the ddb allocations, plane properties, and watermarks all in a single go. Until this is fixed however, we can improve things somewhat by adding a vblank wait after the third iteration

[PATCH v3 0/6] Finally fix watermarks

So unfortunately, this patch series fixes most of the underruns on Skylake, but not all of them. Even with this patchset we're still apt to potentially hitting underruns since we don't update the ddb allocations atomically as well yet. I'm planning to do this eventually when I get the chance, but

[PATCH v3 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[PATCH v3 0/6] Finally fix watermarks

So unfortunately, this patch series fixes most of the underruns on Skylake, but not all of them. Even with this patchset we're still apt to potentially hitting underruns since we don't update the ddb allocations atomically as well yet. I'm planning to do this eventually when I get the chance, but

[PATCH v3 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are actually changing; the values for

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

On Tue, 26 Jul 2016 09:19:15 -0400 Christopher Covington wrote: Hi Christopher, > Hi Marc, > > On 06/22/2016 09:34 PM, Hanjun Guo wrote: > > On 2016/6/22 22:51, Marc Zyngier wrote: > >> On 22/06/16 14:52, Tomasz Nowicki wrote: > >>> On 22.06.2016 15:25, Marc Zyngier

Re: [PATCH V7 1/8] ACPI: I/O Remapping Table (IORT) initial support

On Tue, 26 Jul 2016 09:19:15 -0400 Christopher Covington wrote: Hi Christopher, > Hi Marc, > > On 06/22/2016 09:34 PM, Hanjun Guo wrote: > > On 2016/6/22 22:51, Marc Zyngier wrote: > >> On 22/06/16 14:52, Tomasz Nowicki wrote: > >>> On 22.06.2016 15:25, Marc Zyngier wrote: > On

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