Re: [PATCH] HID: picolcd: remove unused variable

Hi Jiapeng, This is a dupe of a fix already sent two weeks ago by Lee Jones. see series "Rid W=1 warnings from HID". @Benjamin: At first glance the patch will not break anything. I've had no time though to check what struct hid_device_id.raw_event expects as

Re: [PATCH 1/2] HID: do not call hid_set_drvdata(hdev, NULL) in drivers

do it manually. > > Signed-off-by: Benjamin Tissoires For hid-picolcd_core.c: Acked-by: Bruno Prémont > --- > drivers/hid/hid-cougar.c | 6 ++ > drivers/hid/hid-gfrm.c | 7 --- > drivers/hid/hid-lenovo.c | 2 -- > drivers/hid/hid-picolcd_core.c | 7 +--

CGroup-v2: Memory: current impossibly high for empty cgroup

With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is considering itself as permanently over-limit and OOM-kill any process I try to move into it (it's currently empty!) I can't hand out a simple reproducer right now, but it seems during accounting the counter went "negative".

CGroup-v2: Memory: current impossibly high for empty cgroup

With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is considering itself as permanently over-limit and OOM-kill any process I try to move into it (it's currently empty!) I can't hand out a simple reproducer right now, but it seems during accounting the counter went "negative".

Re: CGroup-v2: Memory: current impossibly high for empty cgroup

On Thu, 15 Feb 2018 09:40:24 +0100 Bruno Prémont wrote: > With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is > considering itself as permanently over-limit and OOM-kill any process > I try to move into it (it's currently empty!) > > > I can't hand out a

Re: CGroup-v2: Memory: current impossibly high for empty cgroup

On Thu, 15 Feb 2018 09:40:24 +0100 Bruno Prémont wrote: > With 4.15.2 kernel I'm hitting a state where a given leaf v2 cgroup is > considering itself as permanently over-limit and OOM-kill any process > I try to move into it (it's currently empty!) > > > I can't hand out a

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sun, 12 Nov 2017 18:29:06 Bruno Prémont wrote: > On Sun, 12 November 2017 "Paul E. McKenney" wrote: > > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote: > > > On Sat, 11 November 2017 "Paul E. McKenney" wrote: > > > > On Sa

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sun, 12 Nov 2017 18:29:06 Bruno Prémont wrote: > On Sun, 12 November 2017 "Paul E. McKenney" wrote: > > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote: > > > On Sat, 11 November 2017 "Paul E. McKenney" wrote: > > > > On Sa

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sun, 12 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote: > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote: > > On Sat, 11 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> > > wrote: > > >

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sun, 12 November 2017 "Paul E. McKenney" wrote: > On Sun, Nov 12, 2017 at 12:09:28PM +0100, Bruno Prémont wrote: > > On Sat, 11 November 2017 "Paul E. McKenney" > > wrote: > > > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote:

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sat, 11 November 2017 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote: > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote: > > Hi, > > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall > > and so

Re: RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

On Sat, 11 November 2017 "Paul E. McKenney" wrote: > On Sat, Nov 11, 2017 at 08:38:32PM +0100, Bruno Prémont wrote: > > Hi, > > > > On a single-CPU KVM-based virtual machine I'm suffering from RCU stall > > and soft-lockup. 4.10.x kernels run fine (4.10.12)

RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

Hi, On a single-CPU KVM-based virtual machine I'm suffering from RCU stall and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent reason. All info I have is following console dump (from 4.13.11): [526415.290012]

RCU stall/SOFT-Lockup on 4.11.3/4.13.11 after multiple days uptime

Hi, On a single-CPU KVM-based virtual machine I'm suffering from RCU stall and soft-lockup. 4.10.x kernels run fine (4.10.12) but starting with 4.11.x (4.11.3, 4.13.11) I'm getting system freezes for no apparent reason. All info I have is following console dump (from 4.13.11): [526415.290012]

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset (was: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later)

On Mon, 6 Nov 2017 18:57:15 -0500 (EST) Mikulas Patocka wrote: > On Mon, 6 Nov 2017, Bruno Prémont wrote: > > On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote: > > > On Thu, Nov 02 2017 at 4:39pm -0400, Bruno Prémont wrote: > > > > Hi, > > > > > >

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset (was: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later)

On Mon, 6 Nov 2017 18:57:15 -0500 (EST) Mikulas Patocka wrote: > On Mon, 6 Nov 2017, Bruno Prémont wrote: > > On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote: > > > On Thu, Nov 02 2017 at 4:39pm -0400, Bruno Prémont wrote: > > > > Hi, > > > > > >

Re: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote: > On Thu, Nov 02 2017 at 4:39pm -0400, Bruno Prémont wrote: > > Hi, > > > > Between 4.11 and 4.12 I stopped being able to boot my system with root > > partition encrypted with dm-crypt (issue still present in 4.14-rc

Re: [Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

On Mon, 6 Nov 2017 11:18:09 Mike Snitzer wrote: > On Thu, Nov 02 2017 at 4:39pm -0400, Bruno Prémont wrote: > > Hi, > > > > Between 4.11 and 4.12 I stopped being able to boot my system with root > > partition encrypted with dm-crypt (issue still present in 4.14-rc

[Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

Hi, Between 4.11 and 4.12 I stopped being able to boot my system with root partition encrypted with dm-crypt (issue still present in 4.14-rc7). The system was able to open the dm-crypt device and read-only mount the XFS root partition on it. Later read-write remounting though caused XFS to

[Regression, Bisected] dm-crypt IO failures with active slub_debug in 4.12 and later

Hi, Between 4.11 and 4.12 I stopped being able to boot my system with root partition encrypted with dm-crypt (issue still present in 4.14-rc7). The system was able to open the dm-crypt device and read-only mount the XFS root partition on it. Later read-write remounting though caused XFS to

Re: [PATCH 7/7] HID: picoLCD: Replace two seq_printf() calls by seq_puts() in picolcd_debug_reset_show()

Acked-by: Bruno Prémont <bonb...@linux-vserver.org> On Mon, 24 Apr 2017 22:23:02 +0200 SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Mon, 24 Apr 2017 21:27:42 +0200 > > Strings which did not contain data format spec

Re: [PATCH 7/7] HID: picoLCD: Replace two seq_printf() calls by seq_puts() in picolcd_debug_reset_show()

Acked-by: Bruno Prémont On Mon, 24 Apr 2017 22:23:02 +0200 SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 24 Apr 2017 21:27:42 +0200 > > Strings which did not contain data format specifications should be put > into a sequence. Thus use the corresponding fun

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

Hi Geert, Jiri, Fine with me, Acked-by: Bruno Prémont <bonb...@linux-vserver.org> On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven <geert+rene...@glider.be> wrote: > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > Cc: Bruno Prémont <bonb...@lin

Re: [PATCH trivial 1/4] HID: picoLCD: Spelling s/REPORT_WRTIE_MEMORY/REPORT_WRITE_MEMORY/

Hi Geert, Jiri, Fine with me, Acked-by: Bruno Prémont On Fri, 17 Feb 2017 16:36:36 Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Cc: Bruno Prémont > Cc: linux-in...@vger.kernel.org > --- > drivers/hid/hid-picolcd_debugfs.c | 2 +- > 1 file changed,

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

On Mon, 11 Jul 2016 09:30:30 +0200 Thorsten Leemhuis wrote: > Bruno Prémont wrote on 11.07.2016 09:17: > > On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote: > >> Bruno Prémont wrote on 30.06.2016 17:00: > >> > In qla24xx_process_response_queue() rsp

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

On Mon, 11 Jul 2016 09:30:30 +0200 Thorsten Leemhuis wrote: > Bruno Prémont wrote on 11.07.2016 09:17: > > On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote: > >> Bruno Prémont wrote on 30.06.2016 17:00: > >> > In qla24xx_process_response_queue() rsp

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote: > Bruno Prémont wrote on 30.06.2016 17:00: > > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL > > pointer dereference when rsp->msix is NULL: > > […] > > The af

Re: [PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

On Fri, 8 Jul 2016 09:27:18 +0200 Thorsten Leemhuis wrote: > Bruno Prémont wrote on 30.06.2016 17:00: > > In qla24xx_process_response_queue() rsp->msix->cpuid may trigger NULL > > pointer dereference when rsp->msix is NULL: > > […] > > The af

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

On Tue, 5 Jul 2016 11:25:10 +0200 Maxime Ripard wrote: > On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote: > > > > > > 05.07.2016, 13:26, "Michael Haas" : > > > Hi, > > > > > > nice work! Is this in any way related to Bruno Prémonts driver for the > > >

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

On Tue, 5 Jul 2016 11:25:10 +0200 Maxime Ripard wrote: > On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote: > > > > > > 05.07.2016, 13:26, "Michael Haas" : > > > Hi, > > > > > > nice work! Is this in any way related to Bruno Prémonts driver for the > > > axp20x? > > > > > > I've

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

On Tue, 05 Jul 2016 16:47:38 +0800 Icenowy Zheng wrote: > I read the datasheet of axp20x, and then found that this driver does > not support backup RTC battery. > (But maybe backup battery do not need a driver -- at least on IBM PC > it has no driver) A driver is needed to enable/disable the RTC

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

On Tue, 05 Jul 2016 16:47:38 +0800 Icenowy Zheng wrote: > I read the datasheet of axp20x, and then found that this driver does > not support backup RTC battery. > (But maybe backup battery do not need a driver -- at least on IBM PC > it has no driver) A driver is needed to enable/disable the RTC

[PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

0fb:0: QLogic QLE2460 - PCI-Express Single Channel 4Gb Fibre Channel HBA. [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ :13:00.0 hdma+ host#=0 fw=7.03.00 (9496). [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps). CC: <sta...@vger.kernel.o

[PATCH] qla2xxx: Fix NULL pointer deref in QLA interrupt

0fb:0: QLogic QLE2460 - PCI-Express Single Channel 4Gb Fibre Channel HBA. [3.894207] qla2xxx [:13:00.0]-00fc:0: ISP2432: PCIe (2.5GT/s x4) @ :13:00.0 hdma+ host#=0 fw=7.03.00 (9496). [5.714774] qla2xxx [:13:00.0]-500a:0: LOOP UP detected (4 Gbps). CC: Signed-off-by: Bruno Pr

Re: [PATCH] HID-PICOLCD: Dummy hid-picolcd functions should return error code

Hi Arvind, I can only NACK this patch as it would cause the driver to refuse probe()ing if any of the features are disabled in kernel configuration. Have a look at the callers in hid-picolcd_code.c, if any of those functions does return an error the probe function aborts with an error. Your

Re: [PATCH] HID-PICOLCD: Dummy hid-picolcd functions should return error code

Hi Arvind, I can only NACK this patch as it would cause the driver to refuse probe()ing if any of the features are disabled in kernel configuration. Have a look at the callers in hid-picolcd_code.c, if any of those functions does return an error the probe function aborts with an error. Your

Re: piping core dump to a program escapes container

On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote: > Dongsheng Yang writes: > > > On 12/09/2015 10:26 AM, Dongsheng Yang wrote: > >> On 10/25/2015 05:54 AM, Shayan Pooya wrote: > >>> I noticed the following core_pattern behavior in my linux box while > >>> running docker containers.

Re: piping core dump to a program escapes container

On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote: > Dongsheng Yang writes: > > > On 12/09/2015 10:26 AM, Dongsheng Yang wrote: > >> On 10/25/2015 05:54 AM, Shayan Pooya wrote: > >>> I noticed the following core_pattern behavior in my linux box while >

Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

om vgaarb changes > 2015-03-18 (7 months ago), Bruno Prémont > > > On Thu, Oct 15, 2015 at 04:47:13AM +, bugzilla-dae...@bugzilla.kernel.org > wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=105051 > > > > Felipe Ortiz changed: > > > >

Re: [Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

om vgaarb changes > 2015-03-18 (7 months ago), Bruno Prémont <bonb...@linux-vserver.org> > > > On Thu, Oct 15, 2015 at 04:47:13AM +, bugzilla-dae...@bugzilla.kernel.org > wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=105051 > > &g

Re: [PATCH] HID-picoLCD: Deletion of unnecessary checks before three function calls

d.c > > index 89821c2..22dcbe1 100644 > > --- a/drivers/hid/hid-picolcd_lcd.c > > +++ b/drivers/hid/hid-picolcd_lcd.c > > @@ -92,8 +92,7 @@ void picolcd_exit_lcd(struct picolcd_data *data) > > struct lcd_device *ldev = data->lcd; > > > > data->lcd = NULL; > > - if

Re: [PATCH] HID-picoLCD: Deletion of unnecessary checks before three function calls

); } int picolcd_resume_lcd(struct picolcd_data *data) Would you like to integrate this update suggestion into another source code repository? Sorry for forgetting about this patch. Looks good to me: Reviewed-by: Bruno Prémont bonb...@linux-vserver.org Jiri, can you take it? Best

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

On Fri, 29 May 2015 18:36:50 +0200 Darren Hart wrote: > > Making sure to lock only the intel GPU when present and especially > > protecting > > against nvidia driver will be hard if legacy-IO is being processed by a > > hidden > > device! > > Ugh indeed. Worst case we can special case via dmi

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

On Fri, 29 May 2015 18:36:50 +0200 Darren Hart wrote: Making sure to lock only the intel GPU when present and especially protecting against nvidia driver will be hard if legacy-IO is being processed by a hidden device! Ugh indeed. Worst case we can special case via dmi strings. Is

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

On Tue, 26 May 2015 22:35:46 -0700 Michael Marineau wrote: > On Tue, May 26, 2015 at 9:47 PM, Darren Hart wrote: > > On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote: > >> FYI, this actually broke backlight controls on my MBP11,3 because the > >> assumption the patch makes that

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

Hi Michael, On Tue, 26 May 2015 21:47:49 -0700 Darren Hart wrote: > On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote: > > FYI, this actually broke backlight controls on my MBP11,3 because the > > assumption the patch makes that gmux is always loaded before graphics > > drivers

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

Hi Michael, On Tue, 26 May 2015 21:47:49 -0700 Darren Hart wrote: On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote: FYI, this actually broke backlight controls on my MBP11,3 because the assumption the patch makes that gmux is always loaded before graphics drivers didn't

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

On Tue, 26 May 2015 22:35:46 -0700 Michael Marineau wrote: On Tue, May 26, 2015 at 9:47 PM, Darren Hart dvh...@infradead.org wrote: On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote: FYI, this actually broke backlight controls on my MBP11,3 because the assumption the patch

[Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju Tested-by: Petri Hodju Cc: Bjorn Helgaas Cc: Matthew Garrett Signed-off-by: Bruno Prémont --- Resending v2 in the hope Darren won't hit quoted-printable. Also adding linux

[Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju petriho...@yahoo.com Tested-by: Petri Hodju petriho...@yahoo.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Matthew Garrett matthew.garr...@nebula.com Signed-off-by: Bruno Prémont

Re: [Patch v2 resend] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju Tested-by: Petri Hodju Cc: Bjorn Helgaas Cc: Matthew Garrett Signed-off-by: Bruno Prémont --- Resending v2 in the hope Darren won't hit quoted-printable. Also adding linux

Re: [Patch v2 resend] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju petriho...@yahoo.com Tested-by: Petri Hodju petriho...@yahoo.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Matthew Garrett matthew.garr...@nebula.com Signed-off-by: Bruno Prémont

Re: [Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

On Fri, 06 March 2015 Darren Hart wrote: > On Thu, Mar 05, 2015 at 11:20:38PM +0100, Bruno Prémont wrote: > > As GMUX depends on IO for iGP to be enabled and active, lock the IO at > > vgaarb level. This should prevent GPU driver for dGPU to disable IO for > > iGP while it tr

Re: [Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

On Fri, 06 March 2015 Darren Hart dvh...@infradead.org wrote: On Thu, Mar 05, 2015 at 11:20:38PM +0100, Bruno Prémont wrote: As GMUX depends on IO for iGP to be enabled and active, lock the IO at vgaarb level. This should prevent GPU driver for dGPU to disable IO for iGP while it tries

[Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju Tested-by: Petri Hodju Cc: Bjorn Helgaas Cc: Matthew Garrett Signed-off-by: Bruno Prémont --- Respinning, fixing Darren's nit. Changes since v1: - Dropped repeat of gmux

[Patch v2] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju petriho...@yahoo.com Tested-by: Petri Hodju petriho...@yahoo.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Matthew Garrett matthew.garr...@nebula.com Signed-off-by: Bruno Prémont

[Patch] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju Tested-by: Petri Hodju Cc: Bjorn Helgaas Cc: Matthew Garrett Signed-off-by: Bruno Prémont --- drivers/platform/x86/apple-gmux.c | 43

[Patch] apple-gmux: lock iGP IO to protect from vgaarb changes

: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121 Reported-by: Petri Hodju petriho...@yahoo.com Tested-by: Petri Hodju petriho...@yahoo.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Matthew Garrett matthew.garr...@nebula.com Signed-off-by: Bruno Prémont

Re: Logitech G-series drivers

On Sat, 21 February 2015 Ciprian Ciubotariu wrote: > Hi. Only now I realized you wrote some instructions. Below are my (quite > lengthy) responses. > > On Thursday 19 February 2015 10:48:27 Bruno Prémont wrote: > > Hi Ciprian, > > > > Adding linux-input a

Re: Logitech G-series drivers

On Sat, 21 February 2015 Ciprian Ciubotariu cheepe...@gmx.net wrote: Hi. Only now I realized you wrote some instructions. Below are my (quite lengthy) responses. On Thursday 19 February 2015 10:48:27 Bruno Prémont wrote: Hi Ciprian, Adding linux-input and Jiri (HID maintainer) to CC

Re: Logitech G-series drivers

Hi Ciprian, Adding linux-input and Jiri (HID maintainer) to CC. On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote: > I would like to submit to your attention for inclusion in the mainline kernel > a series of drivers for a set of Logitech keybord devices. I forked the > sources under

Re: Logitech G-series drivers

Hi Ciprian, Adding linux-input and Jiri (HID maintainer) to CC. On Sun, 15 Feb 2015 23:17:27 +0200 Ciprian Ciubotariu wrote: I would like to submit to your attention for inclusion in the mainline kernel a series of drivers for a set of Logitech keybord devices. I forked the sources under a

Re: Ethernet: how to disable gigabit support

On Fri, 06 February 2015 Pavel Machek wrote: > On Thu 2015-02-05 14:44:55, Florian Fainelli wrote: > > On 05/02/15 12:25, Pavel Machek wrote: > > > This happened on more than one project: there's gigabit-capable chip, > > > but the connector is not designed for gigabit speed. > > > > > > I'd like

Re: Ethernet: how to disable gigabit support

On Fri, 06 February 2015 Pavel Machek wrote: On Thu 2015-02-05 14:44:55, Florian Fainelli wrote: On 05/02/15 12:25, Pavel Machek wrote: This happened on more than one project: there's gigabit-capable chip, but the connector is not designed for gigabit speed. I'd like to have speed

Re: Linux 3.19-rc5

On Thu, 29 January 2015 Linus Torvalds wrote: > On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote: > > > > The WARN() was already changed to a WARN_ONCE(). > > Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up > always happening. > > So I think the right fix is to: > > -

Re: Linux 3.19-rc5

On Thu, 29 January 2015 Linus Torvalds wrote: On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote: The WARN() was already changed to a WARN_ONCE(). Oh, but I notice that the __set_current_state(TASK_RUNNING) ends up always happening. So I think the right fix is to: - warn once

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote: > On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote: > > On Fri, 30 January 2015 Trond Myklebust wrote: > > > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: > > > > On Sun, Jan 25, 2015 a

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Fri, 30 January 2015 Trond Myklebust wrote: > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: > > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote: > > > On a system running home-brown container (mntns, utsns, pidns, netns) > > > with N

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Fri, 30 January 2015 Trond Myklebust wrote: On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote: On a system running home-brown container (mntns, utsns, pidns, netns) with NFS mount-point bind-mounted into the container I hit

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote: On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote: On Fri, 30 January 2015 Trond Myklebust wrote: On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote: On a system running

Re: Linux 3.19-rc5

On Thu, 29 Jan 2015 17:25:07 Linus Torvalds wrote: > On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote: > > > > The WARN() was already changed to a WARN_ONCE(). > > Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up > always happening. > > So I think the right fix is to: >

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Fri, 30 Jan 2015 18:49:21 Trond Myklebust wrote: > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: > > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont > > wrote: > > > On a system running home-brown container (mntns, utsns, pidns, > > > netns)

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

On Fri, 30 Jan 2015 18:49:21 Trond Myklebust trond.mykleb...@primarydata.com wrote: On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote: On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont bonb...@linux-vserver.org wrote: On a system running home-brown container (mntns, utsns, pidns

Re: Linux 3.19-rc5

On Thu, 29 Jan 2015 17:25:07 Linus Torvalds wrote: On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote: The WARN() was already changed to a WARN_ONCE(). Oh, but I notice that the __set_current_state(TASK_RUNNING) ends up always happening. So I think the right fix is to: - warn

[Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

trace b701b037bc457620 ]--- [51398.058223] Fixing recursive fault but reboot is needed! The code executed in rpc_new_client() tries to dereference the struct new_utsname * returned by utsname() which has already been released at this time. Cc: # 3.18 Signed-off-by: Bruno Prémont --- I've seen this

[Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

already been released at this time. Cc: sta...@vger.kernel.org # 3.18 Signed-off-by: Bruno Prémont bonb...@linux-vserver.org --- I've seen this trace on 3.18.x as well as 3.19-rc. This patch fixes the NULL dereference but I'm not sure this is the right fix. Should init uts_ns be referred to or what

Re: Linux 3.19-rc5

On Wed, 21 January 2015 Bruno Prémont wrote: > On Tue, 20 January 2015 Linus Torvalds wrote: > > On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote: > > > > > > No idea yet which rc is the offender (nor exact patch), but on my not > > > so recent UP laptop

Re: Linux 3.19-rc5

On Tue, 20 January 2015 Linus Torvalds wrote: > On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote: > > > > No idea yet which rc is the offender (nor exact patch), but on my not > > so recent UP laptop with a pccard slot I have 2 pccardd kernel threads > > convert

Re: Linux 3.19-rc5

On Wed, 21 January 2015 Bruno Prémont wrote: On Tue, 20 January 2015 Linus Torvalds wrote: On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote: No idea yet which rc is the offender (nor exact patch), but on my not so recent UP laptop with a pccard slot I have 2 pccardd kernel threads

Re: Linux 3.19-rc5

On Tue, 20 January 2015 Linus Torvalds wrote: On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote: No idea yet which rc is the offender (nor exact patch), but on my not so recent UP laptop with a pccard slot I have 2 pccardd kernel threads converting my laptop into a heater. lspci

Re: Linux 3.19-rc5

On Sun, 18 January 2015 Linus Torvalds wrote: > Another week, another -rc. > > Fairly normal release, although I'd wish that by rc5 we'd have calmed > down even further. But no, with some of the driver tree merges in > particular, this is actually larger than rc4 was. > > That said, it's not

Re: Linux 3.19-rc5

On Sun, 18 January 2015 Linus Torvalds torva...@linux-foundation.org wrote: Another week, another -rc. Fairly normal release, although I'd wish that by rc5 we'd have calmed down even further. But no, with some of the driver tree merges in particular, this is actually larger than rc4 was.

Re: [PATCH] input: Add soft kill switch for input devices

On Sat, 03 January 2015 Tristan Lelong wrote: > This adds a sysfs attribute named 'mute' to all input devices. > It allows to disable them by software in a generic way. > > It can be set to 0 or 1: > echo 1 > /sys/class/input/inputX/mute: will set all the input_events() call > to return

Re: [PATCH] input: Add soft kill switch for input devices

On Sat, 03 January 2015 Tristan Lelong tris...@lelong.xyz wrote: This adds a sysfs attribute named 'mute' to all input devices. It allows to disable them by software in a generic way. It can be set to 0 or 1: echo 1 /sys/class/input/inputX/mute: will set all the input_events() call to

[PATCH 3/3] netconsole: New console flag to dump full log buffer

setup happens rather late during system boot. The big advantage of netconsole over syslog for this task is that it usually allow catching much more messages when system crashes/panics. This causes dynamic netconsoles to request full kernel log when first enabled. Signed-off-by: Bruno Prémont

[PATCH 2/3] netconsole: make loglevel configurable per target

for synamic netconsole consoles. Signed-off-by: Bruno Prémont --- Note: only configuration via configfs has been runtime-tested. Documentation/networking/netconsole.txt | 11 ++- drivers/net/netconsole.c| 114 +++- 2 files changed, 94 insertions

[PATCH 1/3] printk: Use a flag to indicate console-private loglevel

In order to set loglevel for a given console that is not affected by global loglevel as adjusted via syslog(2), add a flag to the console and choose the level to match against msg level depending on this flag. Signed-off-by: Bruno Prémont --- This depends on Daniel's patch "printk: ad

Re: [PATCH] printk: add per console loglevel

On Tue, 23 December 2014 dwal...@fifo99.com wrote: > On Sun, Dec 21, 2014 at 07:47:53PM +0100, Bruno Prémont wrote: > > On Sat, 20 December 2014 dwal...@fifo99.com wrote: > > > This adds to to the console= command line options allowing the > > > addition of a pe

Re: [PATCH] printk: add per console loglevel

On Tue, 23 December 2014 dwal...@fifo99.com wrote: On Sun, Dec 21, 2014 at 07:47:53PM +0100, Bruno Prémont wrote: On Sat, 20 December 2014 dwal...@fifo99.com wrote: This adds to to the console= command line options allowing the addition of a per console log level setting. examples

[PATCH 1/3] printk: Use a flag to indicate console-private loglevel

In order to set loglevel for a given console that is not affected by global loglevel as adjusted via syslog(2), add a flag to the console and choose the level to match against msg level depending on this flag. Signed-off-by: Bruno Prémont bonb...@linux-vserver.org --- This depends on Daniel's

[PATCH 2/3] netconsole: make loglevel configurable per target

for synamic netconsole consoles. Signed-off-by: Bruno Prémont bonb...@linux-vserver.org --- Note: only configuration via configfs has been runtime-tested. Documentation/networking/netconsole.txt | 11 ++- drivers/net/netconsole.c| 114 +++- 2 files

[PATCH 3/3] netconsole: New console flag to dump full log buffer

setup happens rather late during system boot. The big advantage of netconsole over syslog for this task is that it usually allow catching much more messages when system crashes/panics. This causes dynamic netconsoles to request full kernel log when first enabled. Signed-off-by: Bruno Prémont bonb

Re: [PATCH] printk: add per console loglevel

On Sat, 20 December 2014 dwal...@fifo99.com wrote: > This adds to to the console= command line options allowing the > addition of a per console log level setting. > > examples, > > console=ttyS0,ll4 > console=tty0,ll6 > > This can be used on systems which have multiple serial

Re: [PATCH] printk: add per console loglevel

On Sat, 20 December 2014 dwal...@fifo99.com wrote: This adds to to the console= command line options allowing the addition of a per console log level setting. examples, console=ttyS0,ll4 console=tty0,ll6 This can be used on systems which have multiple serial consoles, but

Re: need help to clear kernel (2.6.16.17) cached memory

Hi, On Sat, 13 December 2014 Manish Yadav wrote: > on my system (based on 2.6.16.17), i am trying to clear the cached > memory but it is not being cleared. > > mars# free -m > total used free sharedbuffers cached > Mem: 925459465

Re: need help to clear kernel (2.6.16.17) cached memory

Hi, On Sat, 13 December 2014 Manish Yadav kmanish@gmail.com wrote: on my system (based on 2.6.16.17), i am trying to clear the cached memory but it is not being cleared. mars# free -m total used free sharedbuffers cached Mem: 925

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

uration does > not reflect this, which leads to a hard-to-find bug when FB_EFI is > configured without VGA_ARB. Add a select clause to remedy this. > > Cc: Bruno Prémont > Signed-off-by: Henrik Rydberg > --- > drivers/video/fbdev/Kconfig | 1 + > 1 file changed, 1 insertion(+) >

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

; no VGA_ARB arbitration). So it would need to at least be select VGA_ARB if (PCI && !S390) in order to not have broken kernel configuration (in more or less exotic cases) while depends on VGA_ARB would be the only correct option if the rule 'select only allowed for leafs' is enforced. B

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

to at least be select VGA_ARB if (PCI !S390) in order to not have broken kernel configuration (in more or less exotic cases) while depends on VGA_ARB would be the only correct option if the rule 'select only allowed for leafs' is enforced. Bruno Cc: Bruno Prémont bonb...@linux-vserver.org

Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device

is configured without VGA_ARB. Add a select clause to remedy this. Cc: Bruno Prémont bonb...@linux-vserver.org Signed-off-by: Henrik Rydberg rydb...@euromail.se --- drivers/video/fbdev/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video

  1   2   3   >