Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1

On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote: > ARMv8.1 increases the PMU event number space. Detect the > presence of this PMUv3 type and extend the event mask. > > The event mask is moved to struct arm_pmu so different event masks > can exist, depending on the PMU type. > >

Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1

On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote: > ARMv8.1 increases the PMU event number space. Detect the > presence of this PMUv3 type and extend the event mask. > > The event mask is moved to struct arm_pmu so different event masks > can exist, depending on the PMU type. > >

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

On Mon, Feb 15, 2016 at 11:36:13AM -0800, Greg Kroah-Hartman wrote: > On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote: > > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote: > > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote: > > > > On Sun, Feb

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

On Mon, Feb 15, 2016 at 11:36:13AM -0800, Greg Kroah-Hartman wrote: > On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote: > > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote: > > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote: > > > > On Sun, Feb

Re: [PATCH 00/33] Compile-time stack metadata validation

> > There are two ways to fix the warnings: > > > > 1. get rid of the thunks and call the C functions directly; or > > No. Not until gcc learns about per-function callibg conventions (so that it > can > be marked as not clobbering registers). It does already for static functions in 5.x (with

Re: [PATCH 00/33] Compile-time stack metadata validation

> > There are two ways to fix the warnings: > > > > 1. get rid of the thunks and call the C functions directly; or > > No. Not until gcc learns about per-function callibg conventions (so that it > can > be marked as not clobbering registers). It does already for static functions in 5.x (with

[Patch] media: ti-vpe: cal: Fix syntax check warnings

Fix the following sparse warnings: ti-vpe/cal.c:387:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:459:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:503:27: warning: incorrect type in argument 6 (different

Re: [PATCH 00/33] Compile-time stack metadata validation

On Mon, Feb 15, 2016 at 08:56:21AM -0800, Linus Torvalds wrote: > On Feb 15, 2016 8:31 AM, "Josh Poimboeuf" wrote: > > > > So is the goal to optimize for size? If I replace the calls to > > __preempt_schedule[_notrace]() with real C calls and remove the thunks, > > it only

[Patch] media: ti-vpe: cal: Fix syntax check warnings

Fix the following sparse warnings: ti-vpe/cal.c:387:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:459:26: warning: incorrect type in return expression (different address spaces) ti-vpe/cal.c:503:27: warning: incorrect type in argument 6 (different

Re: [PATCH 00/33] Compile-time stack metadata validation

On Mon, Feb 15, 2016 at 08:56:21AM -0800, Linus Torvalds wrote: > On Feb 15, 2016 8:31 AM, "Josh Poimboeuf" wrote: > > > > So is the goal to optimize for size? If I replace the calls to > > __preempt_schedule[_notrace]() with real C calls and remove the thunks, > > it only adds about 2k to

[PATCH v2] phy: marvell: Fix and unify reg-init behavior

For the Marvell 88E1510, marvell_of_reg_init was called too late, in the config_aneg function. Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"), this lead to the link not coming up at boot anymore, due to the phy state machine being stuck at waiting for interrupts (off by

[PATCH v2] phy: marvell: Fix and unify reg-init behavior

For the Marvell 88E1510, marvell_of_reg_init was called too late, in the config_aneg function. Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"), this lead to the link not coming up at boot anymore, due to the phy state machine being stuck at waiting for interrupts (off by

Re: [PATCH V6] netfilter: h323: avoid potential attack

On Tue, Feb 02, 2016 at 09:40:04PM +0800, Zhouyi Zhou wrote: > diff --git a/net/netfilter/nf_conntrack_h323_main.c > b/net/netfilter/nf_conntrack_h323_main.c > index 9511af0..8d24c4b 100644 > --- a/net/netfilter/nf_conntrack_h323_main.c > +++ b/net/netfilter/nf_conntrack_h323_main.c > @@ -110,6

Re: [PATCH V6] netfilter: h323: avoid potential attack

On Tue, Feb 02, 2016 at 09:40:04PM +0800, Zhouyi Zhou wrote: > diff --git a/net/netfilter/nf_conntrack_h323_main.c > b/net/netfilter/nf_conntrack_h323_main.c > index 9511af0..8d24c4b 100644 > --- a/net/netfilter/nf_conntrack_h323_main.c > +++ b/net/netfilter/nf_conntrack_h323_main.c > @@ -110,6

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

Hi, On Mon, Feb 15, 2016 at 08:50:48PM +0100, Heinrich Schuchardt wrote: > On 02/15/2016 08:40 PM, Aaro Koskinen wrote: > > On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: > >> flash-kernel has a database /usr/share/flash-kernel/db/all.db with > >> entries like: > >> > >>

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

Hi, On Mon, Feb 15, 2016 at 08:50:48PM +0100, Heinrich Schuchardt wrote: > On 02/15/2016 08:40 PM, Aaro Koskinen wrote: > > On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: > >> flash-kernel has a database /usr/share/flash-kernel/db/all.db with > >> entries like: > >> > >>

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

* Guenter Roeck <li...@roeck-us.net> [160215 11:41]: > On 02/15/2016 11:01 AM, Tony Lindgren wrote: > > > >https://kernelci.org/boot/all/job/next/kernel/next-20160215/ > > > >The SMP ones seem to fail with some regulator issues? > > > > There is anothe

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

* Guenter Roeck [160215 11:41]: > On 02/15/2016 11:01 AM, Tony Lindgren wrote: > > > >https://kernelci.org/boot/all/job/next/kernel/next-20160215/ > > > >The SMP ones seem to fail with some regulator issues? > > > > There is another problem, introd

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

* Guenter Roeck [160215 11:47]: > On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote: > > * Rafael J. Wysocki [160215 11:28]: > > > > > > Guenter, Tony, > > > > > > Below is a patch to try, on top of linux-next. > > > > Fixes the issue on UP

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

* Guenter Roeck [160215 11:47]: > On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote: > > * Rafael J. Wysocki [160215 11:28]: > > > > > > Guenter, Tony, > > > > > > Below is a patch to try, on top of linux-next. > > > > Fixes the issue on UP for me: > > > > Tested-by: Tony

Injection magnets for your Automation

Dear, Good day. May I have your attention?We are a professional manufacturer of magnet and magnetic products located in Shenzhen China,with two production line the annual capacity exceeds 1,000 tons. Thanks to skilled workers and engineers,some of them having more than 15 years

Injection magnets for your Automation

Dear, Good day. May I have your attention?We are a professional manufacturer of magnet and magnetic products located in Shenzhen China,with two production line the annual capacity exceeds 1,000 tons. Thanks to skilled workers and engineers,some of them having more than 15 years

Re: [PATCH v3 4/5] arm64/perf: Enable PMCR long cycle counter bit

On Wed, Feb 03, 2016 at 06:11:59PM +0100, Jan Glauber wrote: > With the long cycle counter bit (LC) disabled the cycle counter is not > working on ThunderX SOC (ThunderX only implements Aarch64). > Also, according to documentation LC == 0 is deprecated. > > To keep the code simple the patch does

Re: [PATCH v3 4/5] arm64/perf: Enable PMCR long cycle counter bit

On Wed, Feb 03, 2016 at 06:11:59PM +0100, Jan Glauber wrote: > With the long cycle counter bit (LC) disabled the cycle counter is not > working on ThunderX SOC (ThunderX only implements Aarch64). > Also, according to documentation LC == 0 is deprecated. > > To keep the code simple the patch does

Re: [PATCH] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Ganapathi, [auto build test WARNING on bluetooth-next/master] [also build test WARNING on v4.5-rc4 next-20160215] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/Bluetooth

Re: [PATCH] Bluetooth: hci_uart: Support firmware download for Marvell

Hi Ganapathi, [auto build test WARNING on bluetooth-next/master] [also build test WARNING on v4.5-rc4 next-20160215] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/Bluetooth

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

On 02/15/2016 08:40 PM, Aaro Koskinen wrote: > Hi, > > On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: >> flash-kernel has a database /usr/share/flash-kernel/db/all.db with >> entries like: >> >> Machine: LeMaker Banana Pi >> Kernel-Flavors: armmp armmp-lpae >>

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

On 02/15/2016 08:40 PM, Aaro Koskinen wrote: > Hi, > > On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: >> flash-kernel has a database /usr/share/flash-kernel/db/all.db with >> entries like: >> >> Machine: LeMaker Banana Pi >> Kernel-Flavors: armmp armmp-lpae >>

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote: > * Rafael J. Wysocki [160215 11:28]: > > > > Guenter, Tony, > > > > Below is a patch to try, on top of linux-next. > > Fixes the issue on UP for me: > > Tested-by: Tony Lindgren > > >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote: > * Rafael J. Wysocki [160215 11:28]: > > > > Guenter, Tony, > > > > Below is a patch to try, on top of linux-next. > > Fixes the issue on UP for me: > > Tested-by: Tony Lindgren > > > Please let me know if the problem is still

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215-2-g08cd608 #895 Hardware name: Generic OMAP4 (Flattened Device Tree) task: ee87 ti: ee85e000 task.ti: ee85e000 PC is at regulator_set_voltage+0x10/0x54 LR is at _set_opp_voltage+0x30/0x98 pc : []lr : []psr: 0113 sp

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

issue with SMP systems, see below. Regards, Tony 8< -- Unable to handle kernel NULL pointer dereference at virtual address 0030 pgd = c0204000 [0030] *pgd= Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-n

Re: [PATCH] pinctrl: coh901: fix initconst annotation

On Mon, Feb 8, 2016 at 3:29 PM, Arnd Bergmann wrote: > Clang correctly points out that the section attribute for u300_gpio_confdata > is in the wrong place: > > drivers/pinctrl/pinctrl-coh901.c:130:37: error: '__section__' attribute only > applies to functions and global

Re: [PATCH] pinctrl: coh901: fix initconst annotation

On Mon, Feb 8, 2016 at 3:29 PM, Arnd Bergmann wrote: > Clang correctly points out that the section attribute for u300_gpio_confdata > is in the wrong place: > > drivers/pinctrl/pinctrl-coh901.c:130:37: error: '__section__' attribute only > applies to functions and global variables > > This

Re: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events

On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote: > The implemented Cortex A57 events are not A57 specific. > They are recommended by ARM and can be found on other > ARMv8 SOCs like Cavium ThunderX too. Therefore move > these events to the common PMUv3 table. I can't find anything in

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

Hi, On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: > flash-kernel has a database /usr/share/flash-kernel/db/all.db with > entries like: > > Machine: LeMaker Banana Pi > Kernel-Flavors: armmp armmp-lpae > Boot-Script-Path: /boot/boot.scr > DTB-Id: sun7i-a20-bananapi.dtb >

Re: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events

On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote: > The implemented Cortex A57 events are not A57 specific. > They are recommended by ARM and can be found on other > ARMv8 SOCs like Cavium ThunderX too. Therefore move > these events to the common PMUv3 table. I can't find anything in

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

Hi, On Mon, Feb 15, 2016 at 08:21:33PM +0100, Heinrich Schuchardt wrote: > flash-kernel has a database /usr/share/flash-kernel/db/all.db with > entries like: > > Machine: LeMaker Banana Pi > Kernel-Flavors: armmp armmp-lpae > Boot-Script-Path: /boot/boot.scr > DTB-Id: sun7i-a20-bananapi.dtb >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

nor: Replace timers with utilization update callbacks' with next-20160215. An example crash log and bisect results are attached below. Please let me know if there is anything I can do to help tracking down the problem. It looks like we've uncovered some nastiness in the arch ARM code (see b

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

' with next-20160215. An example crash log and bisect results are attached below. Please let me know if there is anything I can do to help tracking down the problem. It looks like we've uncovered some nastiness in the arch ARM code (see below). [cut] [1.34] Unable to handle kernel NULL

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote: > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote: > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote: > > > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote: > > > > On Sun, Feb

Re: [PATCH 4.3 041/200] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

On Mon, Feb 15, 2016 at 12:50:41PM -0600, Michael Welling wrote: > On Mon, Feb 15, 2016 at 10:15:08AM -0800, Greg Kroah-Hartman wrote: > > On Sun, Feb 14, 2016 at 09:08:50PM -0600, Michael Welling wrote: > > > On Sun, Feb 14, 2016 at 03:17:36PM -0800, Greg Kroah-Hartman wrote: > > > > On Sun, Feb

[PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

omap3 overo boots crash with Unable to handle kernel NULL pointer dereference at virtual address 0030 pgd = c0204000 [0030] *pgd= Internal error: Oops: 17 [#1] SMP ARM ... [] (regulator_set_voltage) from [] (_set_opp_voltage+0x34/0x90) [] (_set_opp_voltage) from []

[PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator

omap3 overo boots crash with Unable to handle kernel NULL pointer dereference at virtual address 0030 pgd = c0204000 [0030] *pgd= Internal error: Oops: 17 [#1] SMP ARM ... [] (regulator_set_voltage) from [] (_set_opp_voltage+0x34/0x90) [] (_set_opp_voltage) from []

Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails

On Thu, 2016-02-11 at 15:05 +0530, Archit Taneja wrote: > component_master_add_with_match can fail if the master's bind op doesn't > go through successfully. In such a scenario, all the components in the > master's match array have their 'master' pointer set to the given master. > These pointers

Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails

On Thu, 2016-02-11 at 15:05 +0530, Archit Taneja wrote: > component_master_add_with_match can fail if the master's bind op doesn't > go through successfully. In such a scenario, all the components in the > master's match array have their 'master' pointer set to the given master. > These pointers

Re: [PATCH nf] netfilter: nfnetlink: correctly validate length of batch messages

On Tue, Feb 02, 2016 at 01:36:45PM -0500, phil.turnb...@oracle.com wrote: > From: Phil Turnbull > > If nlh->nlmsg_len is zero then an infinite loop is triggered because > 'skb_pull(skb, msglen);' pulls zero bytes. > > The calculation in nlmsg_len() underflows if

Re: [PATCH nf] netfilter: nfnetlink: correctly validate length of batch messages

On Tue, Feb 02, 2016 at 01:36:45PM -0500, phil.turnb...@oracle.com wrote: > From: Phil Turnbull > > If nlh->nlmsg_len is zero then an infinite loop is triggered because > 'skb_pull(skb, msglen);' pulls zero bytes. > > The calculation in nlmsg_len() underflows if 'nlh->nlmsg_len < >

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

t; >>>> Thanks for the report! > >>>> > >>>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: > >>>>> Replace > >>>>> timers with utilization update callbacks' with next-20160215. An exampl

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

ocki wrote: > >>>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck > >>>> wrote: > >>>>> Rafael, > >>>> > >>>> Hi, > >>>> > >>>> Thanks for the report! > >>>> > &g

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote: > On 15/02/16 18:54, Rafael J. Wysocki wrote: > > That would explain it, thanks. > > > > So it looks like we should always use irq_work_queue() on UP even if > > CONFIG_SMP is set, shouldn't we? > > Something like that, yes.

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote: > On 15/02/16 18:54, Rafael J. Wysocki wrote: > > That would explain it, thanks. > > > > So it looks like we should always use irq_work_queue() on UP even if > > CONFIG_SMP is set, shouldn't we? > > Something like that, yes.

Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC

2016-02-12 16:38+0100, Paolo Bonzini: > On 12/02/2016 14:59, Suravee Suthikulpanit wrote: >> +case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN: >> +kvm_lapic_reg_write(apic, APIC_ICR2, icrh); >> +kvm_lapic_reg_write(apic, APIC_ICR, icrl); > > Wouldn't this cause a double

Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC

2016-02-12 16:38+0100, Paolo Bonzini: > On 12/02/2016 14:59, Suravee Suthikulpanit wrote: >> +case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN: >> +kvm_lapic_reg_write(apic, APIC_ICR2, icrh); >> +kvm_lapic_reg_write(apic, APIC_ICR, icrl); > > Wouldn't this cause a double

Re: [PATCH] irqchip/ts4800: Make ts4800_ic_ops static const

On Sun, Feb 14, 2016 at 09:50:04PM +0800, Axel Lin wrote: > ts4800_ic_ops is only referenced in this driver, so make it static. > In additional, it's never get modified thus also make it const. > > Signed-off-by: Axel Lin Reviewed-by: Damien Riegel

Re: [PATCH] irqchip/ts4800: Make ts4800_ic_ops static const

On Sun, Feb 14, 2016 at 09:50:04PM +0800, Axel Lin wrote: > ts4800_ic_ops is only referenced in this driver, so make it static. > In additional, it's never get modified thus also make it const. > > Signed-off-by: Axel Lin Reviewed-by: Damien Riegel Thanks for catching this.

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

On 02/15/2016 07:38 PM, Aaro Koskinen wrote: > Hi, > > On Mon, Feb 15, 2016 at 06:52:20PM +0100, Heinrich Schuchardt wrote: >> On 02/15/2016 12:16 PM, Sergei Shtylyov wrote: >>> On 2/15/2016 8:26 AM, Heinrich Schuchardt wrote: Downstream packages like Debian flash-kernel rely on

Re: [PATCH 1/1] MIPS: DTS: cavium-octeon: provide model attribute

On 02/15/2016 07:38 PM, Aaro Koskinen wrote: > Hi, > > On Mon, Feb 15, 2016 at 06:52:20PM +0100, Heinrich Schuchardt wrote: >> On 02/15/2016 12:16 PM, Sergei Shtylyov wrote: >>> On 2/15/2016 8:26 AM, Heinrich Schuchardt wrote: Downstream packages like Debian flash-kernel rely on

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

On Fri, Feb 12, 2016 at 06:00:10PM +0100, Borislav Petkov wrote: > Something for me to try when I get a chance. Ok, so I wanted to know what happens in detail. Here's some ftracing (debug patch at the end). Now pay attention to this udevadm thing [3.816977] rcu_pree-7 0d..2 4058241us

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

On Fri, Feb 12, 2016 at 06:00:10PM +0100, Borislav Petkov wrote: > Something for me to try when I get a chance. Ok, so I wanted to know what happens in detail. Here's some ftracing (debug patch at the end). Now pay attention to this udevadm thing [3.816977] rcu_pree-7 0d..2 4058241us

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

; On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <li...@roeck-us.net> wrote: >>>>> Rafael, >>>> >>>> Hi, >>>> >>>> Thanks for the report! >>>> >>>>> I see crashes in various arm qemu tests due to 'cp

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

te: >>>>> Rafael, >>>> >>>> Hi, >>>> >>>> Thanks for the report! >>>> >>>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace >>>>> timers with utilization update callbacks' wi

Re: [PATCH] gpio/sysfs: Add ID parameter for GPIO lines

On Thu, Dec 17, 2015 at 5:48 PM, Ricardo Ribalda Delgado wrote: > On named GPIOs there is currently no find out their numerical id. > > Because of this, a GPIO pin named like: > /sys/class/gpio/PROG_B > > cannot be unexported by an application different than the one

Re: [PATCH] gpio/sysfs: Add ID parameter for GPIO lines

On Thu, Dec 17, 2015 at 5:48 PM, Ricardo Ribalda Delgado wrote: > On named GPIOs there is currently no find out their numerical id. > > Because of this, a GPIO pin named like: > /sys/class/gpio/PROG_B > > cannot be unexported by an application different than the one that > exported it. > > This

Re: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP

On Mon, Feb 15, 2016 at 05:46:56PM +, Will Deacon wrote: > On Thu, Feb 11, 2016 at 06:40:02PM +, Marc Zyngier wrote: > > With VHE, we place kernel {watch,break}-points at EL2 to get things > > like kgdb and "perf -e mem:..." working. > > > > This requires a bit of repainting in the

Re: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP

On Mon, Feb 15, 2016 at 05:46:56PM +, Will Deacon wrote: > On Thu, Feb 11, 2016 at 06:40:02PM +, Marc Zyngier wrote: > > With VHE, we place kernel {watch,break}-points at EL2 to get things > > like kgdb and "perf -e mem:..." working. > > > > This requires a bit of repainting in the

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:54:26PM +0100, Rafael J. Wysocki wrote: > On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote: > > Given that OMAP3 is a UP system, there is zero chance that it has > > registered the magic hook that delivers IPIs (its interrupt controller > > is

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:54:26PM +0100, Rafael J. Wysocki wrote: > On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote: > > Given that OMAP3 is a UP system, there is zero chance that it has > > registered the magic hook that delivers IPIs (its interrupt controller > > is not even capable of

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

On Thu, Feb 11, 2016 at 05:16:00PM -0800, Andy Lutomirski wrote: > Are you running 32-bit userspace by any chance? Sure, that's a 32-bit kernel testing partition. :) > I'm guessing you're hitting this in __fpu_restore_sig: Yeah, I was looking at that too. > fpu__drop(fpu); > if

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

On Thu, Feb 11, 2016 at 05:16:00PM -0800, Andy Lutomirski wrote: > Are you running 32-bit userspace by any chance? Sure, that's a 32-bit kernel testing partition. :) > I'm guessing you're hitting this in __fpu_restore_sig: Yeah, I was looking at that too. > fpu__drop(fpu); > if

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

gt;> Rafael, >>> >>> Hi, >>> >>> Thanks for the report! >>> >>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace >>>> timers with utilization update callbacks' with next-20160215. An example >>>> c

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

;>> Thanks for the report! >>> >>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace >>>> timers with utilization update callbacks' with next-20160215. An example >>>> crash log and bisect results are attached below. >>&

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:41:21PM +0100, Rafael J. Wysocki wrote: > Since this is ARM, arch_send_call_function_single_ipi() looks like this: > > void arch_send_call_function_single_ipi(int cpu) > { > smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE); > } > > so I'm not sure how the

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

On Mon, Feb 15, 2016 at 07:41:21PM +0100, Rafael J. Wysocki wrote: > Since this is ARM, arch_send_call_function_single_ipi() looks like this: > > void arch_send_call_function_single_ipi(int cpu) > { > smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE); > } > > so I'm not sure how the

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

Replace > > timers with utilization update callbacks' with next-20160215. An example > > crash log and bisect results are attached below. > > > > Please let me know if there is anything I can do to help tracking down > > the problem. > > It looks l

[PATCH v5 RESEND 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

This patch fixes the alignment issue reported by checkpatch.pl: CHECK: Alignment should match open parenthesis Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the following memcpy logic easier to read. Add a struct scatterlist *sg in the use_sg branch of

Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'

* Rafael J. Wysocki [160215 10:44]: > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > Rafael, > > Hi, > > Thanks for the report! > > > I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace > > timers with utilization

[PATCH v5 RESEND 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

This patch fixes the alignment issue reported by checkpatch.pl: CHECK: Alignment should match open parenthesis Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the following memcpy logic easier to read. Add a struct scatterlist *sg in the use_sg branch of

[PATCH v5 RESEND 5/8] Staging: rts5208: rtsx_transport.c: Remove extra newlines

This patch fixes the following issues in rtsx_transport.c as reported by checkpatch.pl: CHECK: Blank lines aren't necessary after an open brace '{' CHECK: Please don't use multiple blank lines Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 3 --- 1

[PATCH v5 RESEND 5/8] Staging: rts5208: rtsx_transport.c: Remove extra newlines

This patch fixes the following issues in rtsx_transport.c as reported by checkpatch.pl: CHECK: Blank lines aren't necessary after an open brace '{' CHECK: Please don't use multiple blank lines Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 3 --- 1 file changed, 3

[PATCH v5 RESEND 4/8] Staging: rts5208: rtsx_transport.c: Add spaces around -

This patch fixes the following styling issue in rtsx_transport.c as reported by checkpatch.pl: CHECK: spaces preferred around that '-' (ctx:VxV) Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v5 RESEND 4/8] Staging: rts5208: rtsx_transport.c: Add spaces around -

This patch fixes the following styling issue in rtsx_transport.c as reported by checkpatch.pl: CHECK: spaces preferred around that '-' (ctx:VxV) Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [lkp] [workqueue] 82607adcf9: BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 42s!

Hello, On Sun, Feb 14, 2016 at 09:07:04AM +0800, kernel test robot wrote: > FYI, we noticed the below changes on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 82607adcf9cdf40fb7b5331269780c8f70ec6e35 ("workqueue: implement lockup > detector") > > > [

Re: [lkp] [workqueue] 82607adcf9: BUG: workqueue lockup - pool cpus=0 flags=0x4 nice=0 stuck for 42s!

Hello, On Sun, Feb 14, 2016 at 09:07:04AM +0800, kernel test robot wrote: > FYI, we noticed the below changes on > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > commit 82607adcf9cdf40fb7b5331269780c8f70ec6e35 ("workqueue: implement lockup > detector") > > > [

[PATCH v5 RESEND 7/8] Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses

This patch removes all unnecessary parentheses found by checkpatch.pl. Signed-off-by: Shaun Ren --- Changes since v3 * Fixed patch conflicts due to commit 9a66d05d82db ("Staging: rts5208: fix check for dma mapping error"), and commit b3232842dbef ("Staging:

[PATCH v5 RESEND 7/8] Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses

This patch removes all unnecessary parentheses found by checkpatch.pl. Signed-off-by: Shaun Ren --- Changes since v3 * Fixed patch conflicts due to commit 9a66d05d82db ("Staging: rts5208: fix check for dma mapping error"), and commit b3232842dbef ("Staging: rts5208: remove unnecessary

[PATCH v5 RESEND 8/8] Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

This patch changes all comparsions to NULL with !..., as reported by checkpatch.pl. Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rts5208/rtsx_transport.c

[PATCH v5 RESEND 8/8] Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

This patch changes all comparsions to NULL with !..., as reported by checkpatch.pl. Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rts5208/rtsx_transport.c

[PATCH v5 RESEND 6/8] Staging: rts5208: rtsx_transport.c: Fix label naming convention

This patch fixes the following naming convention issue in rtsx_transport.c, as reported by checkpatch.pl: CHECK: Avoid CamelCase: Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v5 RESEND 6/8] Staging: rts5208: rtsx_transport.c: Fix label naming convention

This patch fixes the following naming convention issue in rtsx_transport.c, as reported by checkpatch.pl: CHECK: Avoid CamelCase: Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v5 RESEND 1/8] Staging: rts5208: rtsx_transport.c: Cleanup comments

This patch fixes all multiline comments to conform to the coding style, which states that multiline comments should start with "/*" and end with "*/" on a separate line. Also cleans up some comments to make them more clear and/or reflect what the code is doing. Signed-off-by: Shaun Ren

[PATCH v5 RESEND 1/8] Staging: rts5208: rtsx_transport.c: Cleanup comments

This patch fixes all multiline comments to conform to the coding style, which states that multiline comments should start with "/*" and end with "*/" on a separate line. Also cleans up some comments to make them more clear and/or reflect what the code is doing. Signed-off-by: Shaun Ren ---

[PATCH v5 RESEND 0/8] Staging: rts5208: Fix coding style

This set of patches fixes the coding style issues in rtsx_transport.c. Changes since v4 * Moved a declaration to the beginning of an if branch Changes since v3 * Removed the extraneous SCSI comment in the first patch * Removed the last patch (Staging: rts5208: Add missing dma_mapping_error)

[PATCH v5 RESEND 3/8] Staging: rts5208: rtsx_transport.c: Remove spaces after casts

This patch removes all spaces after casts in rtsx_transport.c, as reported by checkpatch.pl: CHECK: No space is necessary after a cast Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v5 RESEND 0/8] Staging: rts5208: Fix coding style

This set of patches fixes the coding style issues in rtsx_transport.c. Changes since v4 * Moved a declaration to the beginning of an if branch Changes since v3 * Removed the extraneous SCSI comment in the first patch * Removed the last patch (Staging: rts5208: Add missing dma_mapping_error)

[PATCH v5 RESEND 3/8] Staging: rts5208: rtsx_transport.c: Remove spaces after casts

This patch removes all spaces after casts in rtsx_transport.c, as reported by checkpatch.pl: CHECK: No space is necessary after a cast Signed-off-by: Shaun Ren --- drivers/staging/rts5208/rtsx_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] xfs: fix format specifier , should be %llx and not %llu

On Sat, Feb 13, 2016 at 08:26:22PM +, Colin King wrote: > From: Colin Ian King > > busyp->bno is printed with a %llu format specifier when the > intention is to print a hexadecimal value. Trivial fix to > use %llx instead. Found with smatch static analysis: > >

Re: [PATCH] xfs: fix format specifier , should be %llx and not %llu

On Sat, Feb 13, 2016 at 08:26:22PM +, Colin King wrote: > From: Colin Ian King > > busyp->bno is printed with a %llu format specifier when the > intention is to print a hexadecimal value. Trivial fix to > use %llx instead. Found with smatch static analysis: > > fs/xfs/xfs_discard.c:229

[PATCH] thermal: remove a pointless check

The state in devfreq_cooling_state2power is unsigned so removed the < 0 check. Signed-off-by: Alan Cox --- drivers/thermal/devfreq_cooling.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/devfreq_cooling.c

[PATCH] thermal: remove a pointless check

The state in devfreq_cooling_state2power is unsigned so removed the < 0 check. Signed-off-by: Alan Cox --- drivers/thermal/devfreq_cooling.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/devfreq_cooling.c b/drivers/thermal/devfreq_cooling.c index

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