Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)

On Thu, Jan 17, 2019 at 01:05:35PM +0100, Hans de Goede wrote: > On 17-01-19 10:12, Dean Wallace wrote: > > On 17-01-19, Mogens Jensen wrote: > > > Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the > > > quirk seems to have fixed the problem caused by commit 648e921888ad > >

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach <j...@sig21.net> wrote: > > > > E.g. an audio codec could keep running > > while the i2c bus used to program its registers can be runtime suspende

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach wrote: > > > > E.g. an audio codec could keep running > > while the i2c bus used to program its registers can be runtime suspended. > > If this

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: > > On 20 September 2017 at 02:26, Rafael J. Wysocki wrote: > >> > >> Second, leaving devices in runtime suspend in the "suspend"

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: > On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: > > On 20 September 2017 at 02:26, Rafael J. Wysocki wrote: > >> > >> Second, leaving devices in runtime suspend in the "suspend" phase of system > >> suspend is fishy even

Re: [PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

On Tue, Aug 22, 2017 at 12:58:07PM +0200, Takashi Iwai wrote: > I updated the patches and now pushed to topic/dollar-cove-ti-4.13-v2 > branch. Will resubmit v2 (tomorrow or later) once after gathering > reviews. FWIW I tested current Linus's master + topic/dollar-cove-ti-4.13-v2 +

Re: [PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

On Tue, Aug 22, 2017 at 12:58:07PM +0200, Takashi Iwai wrote: > I updated the patches and now pushed to topic/dollar-cove-ti-4.13-v2 > branch. Will resubmit v2 (tomorrow or later) once after gathering > reviews. FWIW I tested current Linus's master + topic/dollar-cove-ti-4.13-v2 +

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote: > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > > > Is the model Asus E200HA? Something like this (sor

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote: > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > > > Is the model Asus E200HA? Something like this (sor

Re: Cherryview wake up events

On Fri, Feb 03, 2017 at 12:00:00PM +0200, Mika Westerberg wrote: > Just for book keeping purposes, can you file a kernel.org bugzilla bug > about this and add all the necessary information, and your patches > there? You can assign the bug directly to me. I filed it but cannot assign it, added you

Re: Cherryview wake up events

On Fri, Feb 03, 2017 at 12:00:00PM +0200, Mika Westerberg wrote: > Just for book keeping purposes, can you file a kernel.org bugzilla bug > about this and add all the necessary information, and your patches > there? You can assign the bug directly to me. I filed it but cannot assign it, added you

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote: > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > > > Is the model Asus E200HA? Something like this (sor

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote: > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > > > Is the model Asus E200HA? Something like this (sor

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > OK, I guess it is easier if I just order one of those machines here and > figure out how to get the PMIC driver working. Oh, I assumed the bottleneck is developer time, not lack of hardware... > Is the model Asus E200HA?

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote: > OK, I guess it is easier if I just order one of those machines here and > figure out how to get the PMIC driver working. Oh, I assumed the bottleneck is developer time, not lack of hardware... > Is the model Asus E200HA?

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 04:26:18PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 02:52:57PM +0100, Johannes Stezenbach wrote: > > Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from > > ProductionKernelQuilts, > > it doesn't seem hard to do the

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 04:26:18PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 02:52:57PM +0100, Johannes Stezenbach wrote: > > Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from > > ProductionKernelQuilts, > > it doesn't seem hard to do the

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 02:16:39PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 01:35:08PM +0200, Mika Westerberg wrote: > > On Thu, Feb 02, 2017 at 12:12:22PM +0100, Johannes Stezenbach wrote: > > > On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote: >

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 02:16:39PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 01:35:08PM +0200, Mika Westerberg wrote: > > On Thu, Feb 02, 2017 at 12:12:22PM +0100, Johannes Stezenbach wrote: > > > On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote: >

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote: > > OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100) > > Field (GPOP, ByteAcc, N

Re: Cherryview wake up events

On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote: > On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote: > > OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100) > > Field (GPOP, ByteAcc, N

Re: Cherryview wake up events

Hi Mika, On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote: > - Powerbutton driver seems simple enough, the only specialty > of the TI dcove PB driver is the workarond for lost button > press event after resume. However, I still don't see how > the PB would c

Re: Cherryview wake up events

Hi Mika, On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote: > - Powerbutton driver seems simple enough, the only specialty > of the TI dcove PB driver is the workarond for lost button > press event after resume. However, I still don't see how > the PB would c

Re: Cherryview wake up events

Hi Andy and Mika, On Tue, Jan 31, 2017 at 12:05:07AM +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach <j...@sig21.net> wrote: > > > > I checked the reference source code, my impression is the > > TI Dollar Cove and and AXP288 are co

Re: Cherryview wake up events

Hi Andy and Mika, On Tue, Jan 31, 2017 at 12:05:07AM +0200, Andy Shevchenko wrote: > On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach wrote: > > > > I checked the reference source code, my impression is the > > TI Dollar Cove and and AXP288 are completely different

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote: > On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote: > > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach <j...@sig21.net> wrote: > > > On Fri, Jan 27, 2017 at 12:56:53AM +020

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote: > On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote: > > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach wrote: > > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote: > &g

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote: > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach <j...@sig21.net> wrote: > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote: > > > And the same info is also in sysfs: > > > &

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote: > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach wrote: > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote: > > > And the same info is also in sysfs: > > > > # cat > > /s

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote: > > I'm reading your long thread about the issue. Thanks for taking the time! > > but excluded CONFIG_MFD_AXP20X based on \_SB.PIC0.I2C7.PMI1._STA returning > > 0 in acpidbg, > > but \_SB.PIC0.I2C7.PMI1._STA returns 0xf > > Did

Re: Cherryview wake up events

On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote: > > I'm reading your long thread about the issue. Thanks for taking the time! > > but excluded CONFIG_MFD_AXP20X based on \_SB.PIC0.I2C7.PMI1._STA returning > > 0 in acpidbg, > > but \_SB.PIC0.I2C7.PMI1._STA returns 0xf > > Did

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 04:28:29PM +0200, Andy Shevchenko wrote: > They probably release just almost all One Big Ugly patch from official > BSP, which by some reason, includes all Intel MID SoCs, Baytrail. > I think I know how Dollar Cove related code ended up there. But that > all stuff is a

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 04:28:29PM +0200, Andy Shevchenko wrote: > They probably release just almost all One Big Ugly patch from official > BSP, which by some reason, includes all Intel MID SoCs, Baytrail. > I think I know how Dollar Cove related code ended up there. But that > all stuff is a

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 01:14:16PM +0200, Andy Shevchenko wrote: > On Tue, Jan 24, 2017 at 11:41 AM, Johannes Stezenbach <j...@sig21.net> wrote: > > Meanwhile I found out the TI PMIC and power button drivers > > has been published as part of the Asus ZenFone Zoom (ZX551ML) &g

Re: Cherryview wake up events

On Tue, Jan 24, 2017 at 01:14:16PM +0200, Andy Shevchenko wrote: > On Tue, Jan 24, 2017 at 11:41 AM, Johannes Stezenbach wrote: > > Meanwhile I found out the TI PMIC and power button drivers > > has been published as part of the Asus ZenFone Zoom (ZX551ML) > > Android ke

Re: Cherryview wake up events

Hi, On Mon, Dec 05, 2016 at 01:06:08PM +0200, Mika Westerberg wrote: > On Sun, Dec 04, 2016 at 07:52:19PM +0100, Johannes Stezenbach wrote: > > On Wed, Oct 05, 2016 at 04:05:11PM +0300, Mika Westerberg wrote: > > > On Wed, Oct 05, 2016 at 02:46:48PM +0200, Johanne

Re: Cherryview wake up events

Hi, On Mon, Dec 05, 2016 at 01:06:08PM +0200, Mika Westerberg wrote: > On Sun, Dec 04, 2016 at 07:52:19PM +0100, Johannes Stezenbach wrote: > > On Wed, Oct 05, 2016 at 04:05:11PM +0300, Mika Westerberg wrote: > > > On Wed, Oct 05, 2016 at 02:46:48PM +0200, Johanne

Re: Cherryview wake up events

Hi, On Wed, Oct 05, 2016 at 04:05:11PM +0300, Mika Westerberg wrote: > On Wed, Oct 05, 2016 at 02:46:48PM +0200, Johannes Stezenbach wrote: > > On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > > > David (CC'd) is working on getting the Dollar Cove PMIC drive

Re: Cherryview wake up events

Hi, On Wed, Oct 05, 2016 at 04:05:11PM +0300, Mika Westerberg wrote: > On Wed, Oct 05, 2016 at 02:46:48PM +0200, Johannes Stezenbach wrote: > > On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > > > David (CC'd) is working on getting the Dollar Cove PMIC drive

Re: [PATCH v2 18/31] gp8psk: don't do DMA on stack

On Sun, Nov 06, 2016 at 11:51:14AM -0800, VDR User wrote: > I applied this patch to the 4.8.4 kernel driver (that I'm currently > running) and it caused nothing but "frontend 0/0 timed out while > tuning". Is there another patch that should be used in conjunction > with this? If not, this patch

Re: [PATCH v2 18/31] gp8psk: don't do DMA on stack

On Sun, Nov 06, 2016 at 11:51:14AM -0800, VDR User wrote: > I applied this patch to the 4.8.4 kernel driver (that I'm currently > running) and it caused nothing but "frontend 0/0 timed out while > tuning". Is there another patch that should be used in conjunction > with this? If not, this patch

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote: > --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c > +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c > @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); > > struct cinergyt2_state { > u8 rc_counter; > +

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote: > --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c > +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c > @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); > > struct cinergyt2_state { > u8 rc_counter; > +

Re: Problem with VMAP_STACK=y

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > { > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > - char state[3]; > + struct dvb_usb_device *d = adap->dev; > + struct

Re: Problem with VMAP_STACK=y

On Wed, Oct 05, 2016 at 06:04:50AM -0300, Mauro Carvalho Chehab wrote: > static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap) > { > - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION }; > - char state[3]; > + struct dvb_usb_device *d = adap->dev; > + struct

Re: Cherryview wake up events

On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > David (CC'd) is working on getting the Dollar Cove PMIC driver > upstreamed to the mainline kernel. May I ask when to expect a patch? I'm ready if you have something to test, even if it's not in shape for mainline yet. Thanks,

Re: Cherryview wake up events

On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > David (CC'd) is working on getting the Dollar Cove PMIC driver > upstreamed to the mainline kernel. May I ask when to expect a patch? I'm ready if you have something to test, even if it's not in shape for mainline yet. Thanks,

Re: Cherryview wake up events

On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > On Wed, Sep 21, 2016 at 11:16:35AM +0200, Johannes Stezenbach wrote: > > There is an ADBG ("TI_DCOVE") in PMI2._STA, so Dollar Cove > > sounds like a good guess. > > David (CC'd) is working on gett

Re: Cherryview wake up events

On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > On Wed, Sep 21, 2016 at 11:16:35AM +0200, Johannes Stezenbach wrote: > > There is an ADBG ("TI_DCOVE") in PMI2._STA, so Dollar Cove > > sounds like a good guess. > > David (CC'd) is working on gett

Re: Cherryview wake up events

On Wed, Sep 21, 2016 at 12:06:14PM +0300, Mika Westerberg wrote: > On Tue, Sep 20, 2016 at 11:11:53PM +0200, Johannes Stezenbach wrote: > > Or it is because the PNP0C40 device depends on GpioInt from PMIC > > which isn't available... > > > > Method (_CRS,

Re: Cherryview wake up events

On Wed, Sep 21, 2016 at 12:06:14PM +0300, Mika Westerberg wrote: > On Tue, Sep 20, 2016 at 11:11:53PM +0200, Johannes Stezenbach wrote: > > Or it is because the PNP0C40 device depends on GpioInt from PMIC > > which isn't available... > > > > Method (_CRS,

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 05:59:43PM +0200, Johannes Stezenbach wrote: > On Tue, Sep 20, 2016 at 01:40:14PM +0300, Mika Westerberg wrote: > > If yes, it probably does not have the normal Fixed power button but > > instead it has something called "Windows button array device

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 05:59:43PM +0200, Johannes Stezenbach wrote: > On Tue, Sep 20, 2016 at 01:40:14PM +0300, Mika Westerberg wrote: > > If yes, it probably does not have the normal Fixed power button but > > instead it has something called "Windows button array device

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 01:40:14PM +0300, Mika Westerberg wrote: > Can you check if you have: > > Hardware Reduced (V5) : 1 > > in that FADT table? Nope, it is "Hardware Reduced (V5) : 0". Now the FADT is also at https://linuxtv.org/~js/e200ha/ > If yes, it probably does not have the normal

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 01:40:14PM +0300, Mika Westerberg wrote: > Can you check if you have: > > Hardware Reduced (V5) : 1 > > in that FADT table? Nope, it is "Hardware Reduced (V5) : 0". Now the FADT is also at https://linuxtv.org/~js/e200ha/ > If yes, it probably does not have the normal

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 12:18:40PM +0300, Mika Westerberg wrote: > On Mon, Sep 19, 2016 at 10:36:22PM +0200, Johannes Stezenbach wrote: > > Now my question is, is this pin 0x004E the same as this > > in /proc/interrupts which fires on LID event? > > > > 158:

Re: Cherryview wake up events

On Tue, Sep 20, 2016 at 12:18:40PM +0300, Mika Westerberg wrote: > On Mon, Sep 19, 2016 at 10:36:22PM +0200, Johannes Stezenbach wrote: > > Now my question is, is this pin 0x004E the same as this > > in /proc/interrupts which fires on LID event? > > > > 158:

Re: Cherryview wake up events

On Mon, Sep 19, 2016 at 02:56:19PM +0300, Mika Westerberg wrote: > On Mon, Sep 19, 2016 at 01:21:17PM +0200, Johannes Stezenbach wrote: > > > > The LID causes a gpio irq: > > 158: 2 0 0 0 chv-gpio 43 ACPI:Event > > > > Howe

Re: Cherryview wake up events

On Mon, Sep 19, 2016 at 02:56:19PM +0300, Mika Westerberg wrote: > On Mon, Sep 19, 2016 at 01:21:17PM +0200, Johannes Stezenbach wrote: > > > > The LID causes a gpio irq: > > 158: 2 0 0 0 chv-gpio 43 ACPI:Event > > > > Howe

Cherryview wake up events

Hi, Mika, I've been reading the thread about pinctrl-cherryview interrupts, but I have some basic questions in understanding the hardware and the relationship between ACPI and Linux drivers, so I decided to start a new thread. https://lkml.kernel.org/g/20160909085832.gk15...@lahna.fi.intel.com I

Cherryview wake up events

Hi, Mika, I've been reading the thread about pinctrl-cherryview interrupts, but I have some basic questions in understanding the hardware and the relationship between ACPI and Linux drivers, so I decided to start a new thread. https://lkml.kernel.org/g/20160909085832.gk15...@lahna.fi.intel.com I

Re: [PATCH 4.7 000/143] 4.7.3-stable review

On Thu, Sep 08, 2016 at 08:52:32AM +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 07, 2016 at 04:59:37PM -0400, Levin, Alexander wrote: > > Hey Greg, > > > > For reference, I've generated a list of <=4.8-rc4 commits that look to me > > like stable material but are not in 4.7.3: > > > >

Re: [PATCH 4.7 000/143] 4.7.3-stable review

On Thu, Sep 08, 2016 at 08:52:32AM +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 07, 2016 at 04:59:37PM -0400, Levin, Alexander wrote: > > Hey Greg, > > > > For reference, I've generated a list of <=4.8-rc4 commits that look to me > > like stable material but are not in 4.7.3: > > > >

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > > > When you're back on 4.7, can you apply this patch[1] to see if it fixes > > the problem? I speculate that the new parallel di

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 08:11:36PM +0200, Johannes Stezenbach wrote: > On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > > > > When you're back on 4.7, can you apply this patch[1] to see if it fixes > > the problem? I speculate that the new parallel di

4.7.0: RCU stall in nf_conntrack

Hi, I just experienced network hangup with 4.7.0, it happened shortly after resume from hibernate: [201988.443552] INFO: rcu_preempt detected stalls on CPUs/tasks: [201988.443556] Tasks blocked on level-0 rcu_node (CPUs 0-3): P14563 [201988.443557] (detected by 3, t=18002

4.7.0: RCU stall in nf_conntrack

Hi, I just experienced network hangup with 4.7.0, it happened shortly after resume from hibernate: [201988.443552] INFO: rcu_preempt detected stalls on CPUs/tasks: [201988.443556] Tasks blocked on level-0 rcu_node (CPUs 0-3): P14563 [201988.443557] (detected by 3, t=18002

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > On Fri, Aug 05, 2016 at 12:35:44PM +0200, Johannes Stezenbach wrote: > > On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > > > I have just encountered a similar problem after I've recently upgrad

Re: 4.7.0-rc7 ext4 error in dx_probe

On Fri, Aug 05, 2016 at 10:02:28AM -0700, Darrick J. Wong wrote: > On Fri, Aug 05, 2016 at 12:35:44PM +0200, Johannes Stezenbach wrote: > > On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > > > I have just encountered a similar problem after I've recently upgrad

Re: 4.7.0-rc7 ext4 error in dx_probe

On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > I have just encountered a similar problem after I've recently upgraded to > 4.7.0: > [Wed Aug 3 11:08:57 2016] EXT4-fs error (device dm-1): dx_probe:740: inode > #13295: comm python: Directory index failed checksum > [Wed Aug 3

Re: 4.7.0-rc7 ext4 error in dx_probe

On Wed, Aug 03, 2016 at 05:50:26PM +0300, Török Edwin wrote: > I have just encountered a similar problem after I've recently upgraded to > 4.7.0: > [Wed Aug 3 11:08:57 2016] EXT4-fs error (device dm-1): dx_probe:740: inode > #13295: comm python: Directory index failed checksum > [Wed Aug 3

Re: 4.7.0-rc7 ext4 error in dx_probe

On Mon, Jul 18, 2016 at 04:17:23PM +0200, Johannes Stezenbach wrote: > On Mon, Jul 18, 2016 at 09:38:43AM -0400, Theodore Ts'o wrote: > > On Mon, Jul 18, 2016 at 12:57:07PM +0200, Johannes Stezenbach wrote: > > > > > > I'm running 4.7.0-rc7 with ext4 on lvm on dm

Re: 4.7.0-rc7 ext4 error in dx_probe

On Mon, Jul 18, 2016 at 04:17:23PM +0200, Johannes Stezenbach wrote: > On Mon, Jul 18, 2016 at 09:38:43AM -0400, Theodore Ts'o wrote: > > On Mon, Jul 18, 2016 at 12:57:07PM +0200, Johannes Stezenbach wrote: > > > > > > I'm running 4.7.0-rc7 with ext4 on lvm on dm

Re: 4.7.0-rc7 ext4 error in dx_probe

On Mon, Jul 18, 2016 at 09:38:43AM -0400, Theodore Ts'o wrote: > On Mon, Jul 18, 2016 at 12:57:07PM +0200, Johannes Stezenbach wrote: > > > > I'm running 4.7.0-rc7 with ext4 on lvm on dm-crypt on SSD > > and out of the blue on idle machine the following error

Re: 4.7.0-rc7 ext4 error in dx_probe

On Mon, Jul 18, 2016 at 09:38:43AM -0400, Theodore Ts'o wrote: > On Mon, Jul 18, 2016 at 12:57:07PM +0200, Johannes Stezenbach wrote: > > > > I'm running 4.7.0-rc7 with ext4 on lvm on dm-crypt on SSD > > and out of the blue on idle machine the following error

4.7.0-rc7 ext4 error in dx_probe

Hi, I'm running 4.7.0-rc7 with ext4 on lvm on dm-crypt on SSD and out of the blue on idle machine the following error message appeared: [373851.683131] EXT4-fs (dm-3): error count since last fsck: 1 [373851.683151] EXT4-fs (dm-3): initial error at time 1468438194: dx_probe:740: inode 22288562

4.7.0-rc7 ext4 error in dx_probe

Hi, I'm running 4.7.0-rc7 with ext4 on lvm on dm-crypt on SSD and out of the blue on idle machine the following error message appeared: [373851.683131] EXT4-fs (dm-3): error count since last fsck: 1 [373851.683151] EXT4-fs (dm-3): initial error at time 1468438194: dx_probe:740: inode 22288562

Re: 4.6.2 frequent crashes under memory + IO pressure

(adding back Cc:, just dropped it to send the logs) On Mon, Jun 27, 2016 at 01:35:14AM +0900, Tetsuo Handa wrote: > > It seems to me that GFP_NOIO allocation requests are depleting memory reserves > because they are passing ALLOC_NO_WATERMARKS to get_page_from_freelist(). > But I'm not familiar

Re: 4.6.2 frequent crashes under memory + IO pressure

(adding back Cc:, just dropped it to send the logs) On Mon, Jun 27, 2016 at 01:35:14AM +0900, Tetsuo Handa wrote: > > It seems to me that GFP_NOIO allocation requests are depleting memory reserves > because they are passing ALLOC_NO_WATERMARKS to get_page_from_freelist(). > But I'm not familiar

Re: 4.6.2 frequent crashes under memory + IO pressure

On Sun, Jun 26, 2016 at 02:04:40AM +0900, Tetsuo Handa wrote: > It seems to me that somebody is using ALLOC_NO_WATERMARKS (with possibly > __GFP_NOWARN), but I don't know how to identify such callers. Maybe print > backtrace from __alloc_pages_slowpath() when ALLOC_NO_WATERMARKS is used? Wouldn't

Re: 4.6.2 frequent crashes under memory + IO pressure

On Sun, Jun 26, 2016 at 02:04:40AM +0900, Tetsuo Handa wrote: > It seems to me that somebody is using ALLOC_NO_WATERMARKS (with possibly > __GFP_NOWARN), but I don't know how to identify such callers. Maybe print > backtrace from __alloc_pages_slowpath() when ALLOC_NO_WATERMARKS is used? Wouldn't

Re: 4.6.2 frequent crashes under memory + IO pressure

On Thu, Jun 23, 2016 at 08:26:35PM +0900, Tetsuo Handa wrote: > > Since you think you saw OOM messages with the older kernels, I assume that > the OOM > killer was invoked on your 4.6.2 kernel. The OOM reaper in Linux 4.6 and > Linux 4.7 > will not help if the OOM killed process was between

Re: 4.6.2 frequent crashes under memory + IO pressure

On Thu, Jun 23, 2016 at 08:26:35PM +0900, Tetsuo Handa wrote: > > Since you think you saw OOM messages with the older kernels, I assume that > the OOM > killer was invoked on your 4.6.2 kernel. The OOM reaper in Linux 4.6 and > Linux 4.7 > will not help if the OOM killed process was between

Re: 4.6.2 frequent crashes under memory + IO pressure

On Tue, Jun 21, 2016 at 08:47:51PM +0900, Tetsuo Handa wrote: > Johannes Stezenbach wrote: > > > > a man's got to have a hobby, thus I'm running Android AOSP > > builds on my home PC which has 4GB of RAM, 4GB swap. > > Apparently it is not really adequate for t

Re: 4.6.2 frequent crashes under memory + IO pressure

On Tue, Jun 21, 2016 at 08:47:51PM +0900, Tetsuo Handa wrote: > Johannes Stezenbach wrote: > > > > a man's got to have a hobby, thus I'm running Android AOSP > > builds on my home PC which has 4GB of RAM, 4GB swap. > > Apparently it is not really adequate for t

4.6.2 frequent crashes under memory + IO pressure

Hi, a man's got to have a hobby, thus I'm running Android AOSP builds on my home PC which has 4GB of RAM, 4GB swap. Apparently it is not really adequate for the job but used to work with a 4.4.10 kernel. Now I upgraded to 4.6.2 and it crashes usually within 30mins during compilation. The crash

4.6.2 frequent crashes under memory + IO pressure

Hi, a man's got to have a hobby, thus I'm running Android AOSP builds on my home PC which has 4GB of RAM, 4GB swap. Apparently it is not really adequate for the job but used to work with a 4.4.10 kernel. Now I upgraded to 4.6.2 and it crashes usually within 30mins during compilation. The crash

uas: order 7 page allocation failure in init_tag_map()

Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would be a pratical value that matches the capabilities of

uas: order 7 page allocation failure in init_tag_map()

Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would be a pratical value that matches the capabilities of

Re: Kernel docs: muddying the waters a bit

On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote: > On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote: > > > > I converted one of the big tables to CSV. At least now it recognized > > it as a table. Yet, the table was very badly formate

Re: Kernel docs: muddying the waters a bit

On Mon, Mar 07, 2016 at 12:29:08AM +0100, Johannes Stezenbach wrote: > On Sat, Mar 05, 2016 at 11:29:37PM -0300, Mauro Carvalho Chehab wrote: > > > > I converted one of the big tables to CSV. At least now it recognized > > it as a table. Yet, the table was very badly formate

Re: Kernel docs: muddying the waters a bit

availble for Python2 in Debian so it does not integrate with Sphinx. Johannes >From 61674b398e778bd5ff644ffd493d5ff1cfaca0ef Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach <j...@sig21.net> Date: Sun, 6 Mar 2016 23:55:19 +0100 Subject: [PATCH] some progress for html output --- _static

Re: Kernel docs: muddying the waters a bit

availble for Python2 in Debian so it does not integrate with Sphinx. Johannes >From 61674b398e778bd5ff644ffd493d5ff1cfaca0ef Mon Sep 17 00:00:00 2001 From: Johannes Stezenbach Date: Sun, 6 Mar 2016 23:55:19 +0100 Subject: [PATCH] some progress for html output --- _static/borderless.css

Re: Kernel docs: muddying the waters a bit

On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote: > > 3) I tried to use a .. cssclass, as Johannes suggested, but > I was not able to include the CSS file. I suspect that this is > easy to fix, but I want to see if the cssclass will also work for > the pdf output as well.

Re: Kernel docs: muddying the waters a bit

On Fri, Mar 04, 2016 at 09:59:50AM -0300, Mauro Carvalho Chehab wrote: > > 3) I tried to use a .. cssclass, as Johannes suggested, but > I was not able to include the CSS file. I suspect that this is > easy to fix, but I want to see if the cssclass will also work for > the pdf output as well.

Re: Kernel docs: muddying the waters a bit

On Fri, Mar 04, 2016 at 10:29:08AM +0200, Jani Nikula wrote: > On Fri, 04 Mar 2016, Mauro Carvalho Chehab wrote: > > > > If, on the other hand, we decide to use RST, we'll very likely need to > > patch it to fulfill our needs in order to add proper table support. > > I've

Re: Kernel docs: muddying the waters a bit

On Fri, Mar 04, 2016 at 10:29:08AM +0200, Jani Nikula wrote: > On Fri, 04 Mar 2016, Mauro Carvalho Chehab wrote: > > > > If, on the other hand, we decide to use RST, we'll very likely need to > > patch it to fulfill our needs in order to add proper table support. > > I've no idea how

Re: [PATCH 5/6] n_tty: Fix stuck write wakeup

On Sun, Dec 13, 2015 at 10:38:02AM -0800, Peter Hurley wrote: > On 12/13/2015 07:18 AM, Johannes Stezenbach wrote: > > > > There is a related bug that I meant to send a patch, but I > > never got around because the issue was found with proprietary > > userspace and

Re: [PATCH 5/6] n_tty: Fix stuck write wakeup

for new data. But in fact SIGIO is sent after every write. n_tty_write() should set TTY_DO_WRITE_WAKEUP only when not all data could be written to the buffer. Signed-off-by: Johannes Stezenbach --- drivers/char/n_tty.c.orig 2015-11-02 22:26:04.124227148 +0100 +++ drivers/char/n_tty.c2015-11

Re: [PATCH 1/6] n_tty: Always wake up read()/poll() if new input

Hi Peter, On Sat, Dec 12, 2015 at 02:16:34PM -0800, Peter Hurley wrote: > A read() in non-canonical mode when VMIN > 0 and VTIME == 0 does not > complete until at least VMIN chars have been read (or the user buffer is > full). In this infrequent read mode, n_tty_read() attempts to reduce >

  1   2   3   4   5   6   >