Re: e1000e regression - 5.4rc1

[Tobias Klausmann]

Hi,

On 08.10.19 09:46, Kai-Heng Feng wrote:

Hi Tobias,


On Oct 5, 2019, at 03:52, Tobias Klausmann 
 wrote:

Hello,

On 04.10.19 19:36, Kai-Heng Feng wrote:

Hi Tobias


On Oct 4, 2019, at 18:34, Tobias Klausmann 
 wrote:

Hello all,

While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly 
having a timeout problem. While bisecting this i landed at the commit 
dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on 
hotplugging cable more reliable") as the first bad commit. And indeed just reverting 
the commit on top of 5.4rc1 resolves the problem. Let me know if you have further 
questions, or patches to test!

Is runtime PM enabled (i.e. "power/control" = auto)?


Yes it is set to auto.

Is something like TLP or `powertop --auto-tune` is in use?

Do you still see the issue when "power/control" keeps at "on"?



With "power/control" set to "on" it does still cycle between up and 
down. But yes i have upower and powerdevil running. After killing them 
the connection comes up with "power/control" set to "on", yet not with 
"auto".



Greetings,

Tobias




Kai-Heng




Also please attach full dmesg, thanks!

Attached,

Tobias


Kai-Heng


Greetings,

Tobias


lspci:

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network 
Connection (rev 06)
 DeviceName:  Onboard LAN
 Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

Re: e1000e regression - 5.4rc1

[Tobias Klausmann]

Hello,

On 04.10.19 19:36, Kai-Heng Feng wrote:

Hi Tobias


On Oct 4, 2019, at 18:34, Tobias Klausmann 
 wrote:

Hello all,

While testing the 5.4rc1 release, i noticed my Ethernet never coming fully up, seemingly 
having a timeout problem. While bisecting this i landed at the commit 
dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: Make speed detection on 
hotplugging cable more reliable") as the first bad commit. And indeed just reverting 
the commit on top of 5.4rc1 resolves the problem. Let me know if you have further 
questions, or patches to test!

Is runtime PM enabled (i.e. "power/control" = auto)?



Yes it is set to auto.



Also please attach full dmesg, thanks!


Attached,

Tobias



Kai-Heng


Greetings,

Tobias


lspci:

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network 
Connection (rev 06)
 DeviceName:  Onboard LAN
 Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- [0.00] microcode: microcode updated early to revision 0x42e, date = 
2019-03-14
[0.00] Linux version 5.3.0-desktop-saa716x+ (a@b) (gcc version 9.2.1 
20190820 [gcc-9-branch revision 274748] (SUSE Linux)) #25 SMP PREEMPT Wed Sep 
25 20:20:52 CEST 2019
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.3.0-desktop-saa716x+ 
root=UUID=25fa63a5-ffbc-4ea5-ade2-5c85298551ca 
resume=/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S12RNEACC48007K-part3 
radeon.si_support=0 amdgpu.si_support=1 radeon.cik_support=0 
amdgpu.cik_support=1 quiet mitigations=auto
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x0008] usable
[0.00] BIOS-e820: [mem 0x0009-0x00090fff] reserved
[0.00] BIOS-e820: [mem 0x00091000-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xbc1f1fff] usable
[0.00] BIOS-e820: [mem 0xbc1f2000-0xbc4d7fff] reserved
[0.00] BIOS-e820: [mem 0xbc4d8000-0xbc5f9fff] ACPI data
[0.00] BIOS-e820: [mem 0xbc5fa000-0xbc818fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbc819000-0xbd746fff] reserved
[0.00] BIOS-e820: [mem 0xbd747000-0xbd747fff] usable
[0.00] BIOS-e820: [mem 0xbd748000-0xbd7cdfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbd7ce000-0xbdc08fff] usable
[0.00] BIOS-e820: [mem 0xbdc09000-0xbdff3fff] reserved
[0.00] BIOS-e820: [mem 0xbdff4000-0xbdff] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x79e89018-0x79ea7057] usable ==> usable
[0.00] e820: update [mem 0x79e89018-0x79ea7057] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0fff] 
reserved
[0.00] reserve setup_data: [mem 0x1000-0x0008] 
usable
[0.00] reserve setup_data: [mem 0x0009-0x00090fff] 
reserved
[0.00] reserve setup_data: [mem 0x00091000-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0x79e89017] 
usable
[0.00] reserve setup_data: [mem 0x79e89018-0x79ea7057] 
usable
[0.00] reserve setup_data: [mem 0x79ea7058-0xbc1f1fff] 
usable
[0.00] reserve setup_data: [mem 0xbc1f2000-0xbc4d7fff] 
reserved
[0.00] reserve setup_data: [mem 0xbc4d8000-0xbc5f9fff] 
ACPI data
[0.00] reserve setup_data: [mem 0xbc5fa000-0xbc818fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0xbc819000-0xbd746fff] 
reserved
[0.00] reserve setup_data: [mem 0xbd747000-0xbd747fff] 
usable
[0.000

e1000e regression - 5.4rc1

[Tobias Klausmann]

Hello all,

While testing the 5.4rc1 release, i noticed my Ethernet never coming 
fully up, seemingly having a timeout problem. While bisecting this i 
landed at the commit dee23594d587386e9fda76732aa5f5a487709510 ("e1000e: 
Make speed detection on hotplugging cable more reliable") as the first 
bad commit. And indeed just reverting the commit on top of 5.4rc1 
resolves the problem. Let me know if you have further questions, or 
patches to test!


Greetings,

Tobias


lspci:

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network 
Connection (rev 06)

    DeviceName:  Onboard LAN
    Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
    Latency: 0
    Interrupt: pin A routed to IRQ 56
    Region 0: Memory at fbf0 (32-bit, non-prefetchable) [size=128K]
    Region 1: Memory at fbf28000 (32-bit, non-prefetchable) [size=4K]
    Region 2: I/O ports at f040 [size=32]
    Capabilities: [c8] Power Management version 2
    Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)

    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
    Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Address: fee00698  Data: 
    Capabilities: [e0] PCI Advanced Features
    AFCap: TP+ FLR+
    AFCtrl: FLR-
    AFStatus: TP-
    Kernel driver in use: e1000e
    Kernel modules: e1000e

Re: [PATCH v2] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

[Tobias Klausmann]

On 29.05.19 20:45, Joe Perches wrote:

On Wed, 2019-05-29 at 18:56 +0200, Tobias Klausmann wrote:

Refactor out the common parts of stv6110x_probe() and stv6110x_attach()
into separate functions.

This provides the needed functionality to use dvb_module_probe() instead
of dvb_attach()!

v2:
- Impovments based on comments by Sean Young
- Fix checkpatch.pl --strict errors

trivia:


diff --git a/drivers/media/dvb-frontends/stv6110x.c 
b/drivers/media/dvb-frontends/stv6110x.c

[]

@@ -333,6 +333,41 @@ static void stv6110x_release(struct dvb_frontend *fe)
kfree(stv6110x);
  }
  
+void st6110x_init_regs(struct stv6110x_state *stv6110x)

+{
+   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};

static const u8...


+
+   memcpy(stv6110x->regs, default_regs, 8);

memcpy(stv6110x->regs, default_regs, ARRAY_SIZE(default_regs));


+}
+
+void stv6110x_setup_divider(struct stv6110x_state *stv6110x)
+{
+   switch (stv6110x->config->clk_div) {
+   default:
+   case 1:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 0);
+   break;
+   case 2:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 1);
+   break;
+   case 4:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 2);
+   break;
+   case 8:
+   case 0:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 3);
+   break;
+   }
+}

Probably more sensible (and smaller object code) written using
an automatic like:

{
int div;

switch (stv6110x->config->clk_div) {
case 8:
div = 3;
break;
case 4:
div = 2;
break;
case 2:
div = 1;
break;
case 1:
default:
div = 0;
break;
}
STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, div);
}


diff --git a/drivers/media/dvb-frontends/stv6110x_priv.h 
b/drivers/media/dvb-frontends/stv6110x_priv.h

[]

@@ -54,11 +54,12 @@
  #define REFCLOCK_MHz  (stv6110x->config->refclk / 
100)
  
  struct stv6110x_state {

+   struct dvb_frontend *frontend;
struct i2c_adapter  *i2c;
const struct stv6110x_config*config;
u8  regs[8];

Perhaps this 8 should be a define?




Hi,

thanks for the comments! If really desired i can change the code 
further, adapting to your comments, but note that the code was 
essentially just moved around to cater to both _probe() and attach(), 
intentionally leaving it as it was before the patch!


Greetings,

Tobias

[PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv090x

[Tobias Klausmann]

Move common code into a new function.

This provides the needed functionality to use dvb_module_probe() instead
of dvb_attach()!

Signed-off-by: Tobias Klausmann 
---
 drivers/media/dvb-frontends/stv090x.c  | 198 +++--
 drivers/media/dvb-frontends/stv090x.h  |   3 +
 drivers/media/dvb-frontends/stv090x_priv.h |   2 +-
 3 files changed, 150 insertions(+), 53 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv090x.c 
b/drivers/media/dvb-frontends/stv090x.c
index d1261571dbe4..b7fdb48f4f14 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -4889,6 +4889,67 @@ static int stv090x_set_gpio(struct dvb_frontend *fe, u8 
gpio, u8 dir,
return stv090x_write_reg(state, STV090x_GPIOxCFG(gpio), reg);
 }
 
+int stv090x_setup_compound(struct stv090x_state *state)
+{
+   struct stv090x_dev *temp_int;
+
+   temp_int = find_dev(state->i2c,
+   state->config->address);
+
+   if (temp_int && state->demod_mode == STV090x_DUAL) {
+   state->internal = temp_int->internal;
+   state->internal->num_used++;
+   dprintk(FE_INFO, 1, "Found Internal Structure!");
+   } else {
+   state->internal = kmalloc(sizeof(*state->internal), GFP_KERNEL);
+   if (!state->internal)
+   goto error;
+   temp_int = append_internal(state->internal);
+   if (!temp_int) {
+   kfree(state->internal);
+   goto error;
+   }
+   state->internal->num_used = 1;
+   state->internal->mclk = 0;
+   state->internal->dev_ver = 0;
+   state->internal->i2c_adap = state->i2c;
+   state->internal->i2c_addr = state->config->address;
+   dprintk(FE_INFO, 1, "Create New Internal Structure!");
+
+   mutex_init(>internal->demod_lock);
+   mutex_init(>internal->tuner_lock);
+
+   if (stv090x_setup(>frontend) < 0) {
+   dprintk(FE_ERROR, 1, "Error setting up device");
+   goto err_remove;
+   }
+   }
+
+   if (state->internal->dev_ver >= 0x30)
+   state->frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
+   /* workaround for stuck DiSEqC output */
+   if (state->config->diseqc_envelope_mode)
+   stv090x_send_diseqc_burst(>frontend, SEC_MINI_A);
+
+   state->config->set_gpio = stv090x_set_gpio;
+
+   dprintk(FE_ERROR, 1, "Probing %s demodulator(%d) Cut=0x%02x",
+   state->device == STV0900 ? "STV0900" : "STV0903",
+   state->config->demod,
+   state->internal->dev_ver);
+
+   return 0;
+
+error:
+   kfree(state);
+   return -ENOMEM;
+err_remove:
+   remove_dev(state->internal);
+   kfree(state->internal);
+   return -ENODEV;
+}
+
 static const struct dvb_frontend_ops stv090x_ops = {
.delsys = { SYS_DVBS, SYS_DVBS2, SYS_DSS },
.info = {
@@ -4921,85 +4982,118 @@ static const struct dvb_frontend_ops stv090x_ops = {
.read_snr   = stv090x_read_cnr,
 };
 
+static struct dvb_frontend *stv090x_get_dvb_frontend(struct i2c_client *client)
+{
+   struct stv090x_state *state = i2c_get_clientdata(client);
 
-struct dvb_frontend *stv090x_attach(struct stv090x_config *config,
-   struct i2c_adapter *i2c,
-   enum stv090x_demodulator demod)
+   dev_dbg(>dev, "\n");
+
+   return >frontend;
+}
+
+static int stv090x_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
 {
+   int ret = 0;
+   struct stv090x_config *config = client->dev.platform_data;
+
struct stv090x_state *state = NULL;
-   struct stv090x_dev *temp_int;
 
-   state = kzalloc(sizeof (struct stv090x_state), GFP_KERNEL);
-   if (state == NULL)
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state) {
goto error;
+   ret = -ENOMEM;
+   }
 
state->verbose  = 
state->config   = config;
-   state->i2c  = i2c;
+   state->i2c  = client->adapter;
state->frontend.ops = stv090x_ops;
state->frontend.demodulator_priv= state;
-   state->demod= demod;
-   state->demod_mode   = config->demod_mode; /* Single 
or Dual mode */
+   state->demod 

[PATCH v2] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

[Tobias Klausmann]

Refactor out the common parts of stv6110x_probe() and stv6110x_attach()
into separate functions.

This provides the needed functionality to use dvb_module_probe() instead
of dvb_attach()!

v2:
- Impovments based on comments by Sean Young
- Fix checkpatch.pl --strict errors

Signed-off-by: Tobias Klausmann 
---
 drivers/media/dvb-frontends/stv6110x.c  | 135 
 drivers/media/dvb-frontends/stv6110x.h  |   3 +
 drivers/media/dvb-frontends/stv6110x_priv.h |   3 +-
 3 files changed, 118 insertions(+), 23 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv6110x.c 
b/drivers/media/dvb-frontends/stv6110x.c
index 0126cfae2e03..f2368ed20bc1 100644
--- a/drivers/media/dvb-frontends/stv6110x.c
+++ b/drivers/media/dvb-frontends/stv6110x.c
@@ -333,6 +333,41 @@ static void stv6110x_release(struct dvb_frontend *fe)
kfree(stv6110x);
 }
 
+void st6110x_init_regs(struct stv6110x_state *stv6110x)
+{
+   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
+
+   memcpy(stv6110x->regs, default_regs, 8);
+}
+
+void stv6110x_setup_divider(struct stv6110x_state *stv6110x)
+{
+   switch (stv6110x->config->clk_div) {
+   default:
+   case 1:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 0);
+   break;
+   case 2:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 1);
+   break;
+   case 4:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 2);
+   break;
+   case 8:
+   case 0:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2],
+ CTRL2_CO_DIV,
+ 3);
+   break;
+   }
+}
+
 static const struct dvb_tuner_ops stv6110x_ops = {
.info = {
.name = "STV6110(A) Silicon Tuner",
@@ -342,7 +377,7 @@ static const struct dvb_tuner_ops stv6110x_ops = {
.release= stv6110x_release
 };
 
-static const struct stv6110x_devctl stv6110x_ctl = {
+static struct stv6110x_devctl stv6110x_ctl = {
.tuner_init = stv6110x_init,
.tuner_sleep= stv6110x_sleep,
.tuner_set_mode = stv6110x_set_mode,
@@ -356,48 +391,104 @@ static const struct stv6110x_devctl stv6110x_ctl = {
.tuner_get_status   = stv6110x_get_status,
 };
 
+void stv6110x_set_frontend_opts(struct stv6110x_state *stv6110x)
+{
+   stv6110x->frontend->tuner_priv  = stv6110x;
+   stv6110x->frontend->ops.tuner_ops   = stv6110x_ops;
+}
+
+static struct stv6110x_devctl *stv6110x_get_devctl(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   dev_dbg(>dev, "\n");
+
+   return stv6110x->devctl;
+}
+
+static int stv6110x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+   struct stv6110x_config *config = client->dev.platform_data;
+
+   struct stv6110x_state *stv6110x;
+
+   stv6110x = kzalloc(sizeof(*stv6110x), GFP_KERNEL);
+   if (!stv6110x)
+   return -ENOMEM;
+
+   stv6110x->frontend  = config->frontend;
+   stv6110x->i2c   = client->adapter;
+   stv6110x->config= config;
+   stv6110x->devctl= _ctl;
+
+   st6110x_init_regs(stv6110x);
+   stv6110x_setup_divider(stv6110x);
+   stv6110x_set_frontend_opts(stv6110x);
+
+   dev_info(>i2c->dev, "Probed STV6110x\n");
+
+   i2c_set_clientdata(client, stv6110x);
+
+   /* setup callbacks */
+   config->get_devctl = stv6110x_get_devctl;
+
+   return 0;
+}
+
+static int stv6110x_remove(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   stv6110x_release(stv6110x->frontend);
+   return 0;
+}
+
 const struct stv6110x_devctl *stv6110x_attach(struct dvb_frontend *fe,
const struct stv6110x_config *config,
struct i2c_adapter *i2c)
 {
struct stv6110x_state *stv6110x;
-   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
 
-   stv6110x = kzalloc(sizeof (struct stv6110x_state), GFP_KERNEL);
+   stv6110x = kzalloc(sizeof(*stv6110x), GFP_KERNEL);
if (!stv6110x)
return NULL;
 
+   stv6110x->frontend  = fe;
stv6110x->i2c   = i2c;
stv6110x->config= config;
stv6110x->devctl= _ctl;
-   memcpy(stv6110x->regs, default

Re: [PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

[Tobias Klausmann]

Hello,

answers, if appropriate, inline!


On 26.05.19 11:33, Sean Young wrote:

Hi Tobias,

On Sun, May 12, 2019 at 04:53:06PM +0200, Tobias Klausmann wrote:

Ping,

comments for this patch are appreciated!

Sorry for not back to you earlier.


No problem, thanks for reviewing!



Please run script/checkpatch.pl --strict on your patch. There are several
cosmetic changes needed.


Will do!


Thanks,

Tobias


On 09.05.19 21:51, Tobias Klausmann wrote:

Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into
separate functions.

This provides the needed functionality to use dvb_module_probe() instead of
dvb_attach()!

The lines shouldn't be longer than 75 characters.

This is a great improvement. It would be nice to see an actual driver use
dvb_module_probe() rather than dvb_attach(), so that the new code paths
are used. Do you have hardware to test this?


I have hardware for a driver living out of tree (sadly): saa716x. So 
that driver was used to test the new functionality provided by this 
patch. I could convert the drivers in-tree to use the new 
dvb_module_probe(), yet without actually testing it.





Signed-off-by: Tobias Klausmann 
---
   drivers/media/dvb-frontends/stv6110x.c  | 125 
   drivers/media/dvb-frontends/stv6110x.h  |   3 +
   drivers/media/dvb-frontends/stv6110x_priv.h |   3 +-
   3 files changed, 109 insertions(+), 22 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv6110x.c 
b/drivers/media/dvb-frontends/stv6110x.c
index 82c002d3833a..17bc7adf3771 100644
--- a/drivers/media/dvb-frontends/stv6110x.c
+++ b/drivers/media/dvb-frontends/stv6110x.c
@@ -345,6 +345,33 @@ static void stv6110x_release(struct dvb_frontend *fe)
kfree(stv6110x);
   }
+void st6110x_init_regs(struct stv6110x_state *stv6110x)
+{
+   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
+
+   memcpy(stv6110x->regs, default_regs, 8);
+}
+
+void stv6110x_setup_divider(struct stv6110x_state *stv6110x)
+{
+   switch (stv6110x->config->clk_div) {
+   default:
+   case 1:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
0);
+   break;
+   case 2:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
1);
+   break;
+   case 4:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
2);
+   break;
+   case 8:
+   case 0:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
3);
+   break;
+   }
+}
+
   static const struct dvb_tuner_ops stv6110x_ops = {
.info = {
.name = "STV6110(A) Silicon Tuner",
@@ -354,7 +381,7 @@ static const struct dvb_tuner_ops stv6110x_ops = {
.release= stv6110x_release
   };
-static const struct stv6110x_devctl stv6110x_ctl = {
+static struct stv6110x_devctl stv6110x_ctl = {
.tuner_init = stv6110x_init,
.tuner_sleep= stv6110x_sleep,
.tuner_set_mode = stv6110x_set_mode,
@@ -368,39 +395,77 @@ static const struct stv6110x_devctl stv6110x_ctl = {
.tuner_get_status   = stv6110x_get_status,
   };
+void stv6110x_set_frontend_opts(struct stv6110x_state *stv6110x)
+{
+   stv6110x->frontend->tuner_priv= stv6110x;
+   stv6110x->frontend->ops.tuner_ops = stv6110x_ops;
+}
+
+static struct stv6110x_devctl *stv6110x_get_devctl(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   dev_dbg(>dev, "\n");
+
+   return stv6110x->devctl;
+}
+
+static int stv6110x_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct stv6110x_config *config = client->dev.platform_data;
+
+   struct stv6110x_state *stv6110x;
+
+   stv6110x = kzalloc(sizeof(struct stv6110x_state), GFP_KERNEL);

This should be:
stv6110x = kzalloc(sizeof(*stv6110x), GFP_KERNEL);


+   if (!stv6110x)
+   return -ENOMEM;
+
+   stv6110x->frontend   = config->frontend;
+   stv6110x->i2c= client->adapter;
+   stv6110x->config = config;
+   stv6110x->devctl = _ctl;
+
+   st6110x_init_regs(stv6110x);
+   stv6110x_setup_divider(stv6110x);
+   stv6110x_set_frontend_opts(stv6110x);
+
+   printk(KERN_INFO "%s: Probed STV6110x\n", __func__);

Please use dev_info().


+
+   i2c_set_clientdata(client, stv6110x);
+
+   /* setup callbacks */
+   config->get_devctl = stv6110x_get_devctl;
+
+   return 0;
+}
+
+static int stv6110x_remove(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   stv6110x_release(stv6110x->frontend);
+   return 0;
+}
+
   const struct stv6110x_devctl *stv6110x_atta

Re: [PATCH] drivers/media/dvb-frontends: Implement probe/remove for stv6110x

[Tobias Klausmann]

Ping,

comments for this patch are appreciated!

Thanks,

Tobias


On 09.05.19 21:51, Tobias Klausmann wrote:

Refactor out the common parts of stv6110x_probe() and stv6110x_attach() into
separate functions.

This provides the needed functionality to use dvb_module_probe() instead of
dvb_attach()!

Signed-off-by: Tobias Klausmann 
---
  drivers/media/dvb-frontends/stv6110x.c  | 125 
  drivers/media/dvb-frontends/stv6110x.h  |   3 +
  drivers/media/dvb-frontends/stv6110x_priv.h |   3 +-
  3 files changed, 109 insertions(+), 22 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv6110x.c 
b/drivers/media/dvb-frontends/stv6110x.c
index 82c002d3833a..17bc7adf3771 100644
--- a/drivers/media/dvb-frontends/stv6110x.c
+++ b/drivers/media/dvb-frontends/stv6110x.c
@@ -345,6 +345,33 @@ static void stv6110x_release(struct dvb_frontend *fe)
kfree(stv6110x);
  }
  
+void st6110x_init_regs(struct stv6110x_state *stv6110x)

+{
+   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
+
+   memcpy(stv6110x->regs, default_regs, 8);
+}
+
+void stv6110x_setup_divider(struct stv6110x_state *stv6110x)
+{
+   switch (stv6110x->config->clk_div) {
+   default:
+   case 1:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
0);
+   break;
+   case 2:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
1);
+   break;
+   case 4:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
2);
+   break;
+   case 8:
+   case 0:
+   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
3);
+   break;
+   }
+}
+
  static const struct dvb_tuner_ops stv6110x_ops = {
.info = {
.name = "STV6110(A) Silicon Tuner",
@@ -354,7 +381,7 @@ static const struct dvb_tuner_ops stv6110x_ops = {
.release= stv6110x_release
  };
  
-static const struct stv6110x_devctl stv6110x_ctl = {

+static struct stv6110x_devctl stv6110x_ctl = {
.tuner_init = stv6110x_init,
.tuner_sleep= stv6110x_sleep,
.tuner_set_mode = stv6110x_set_mode,
@@ -368,39 +395,77 @@ static const struct stv6110x_devctl stv6110x_ctl = {
.tuner_get_status   = stv6110x_get_status,
  };
  
+void stv6110x_set_frontend_opts(struct stv6110x_state *stv6110x)

+{
+   stv6110x->frontend->tuner_priv= stv6110x;
+   stv6110x->frontend->ops.tuner_ops = stv6110x_ops;
+}
+
+static struct stv6110x_devctl *stv6110x_get_devctl(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   dev_dbg(>dev, "\n");
+
+   return stv6110x->devctl;
+}
+
+static int stv6110x_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct stv6110x_config *config = client->dev.platform_data;
+
+   struct stv6110x_state *stv6110x;
+
+   stv6110x = kzalloc(sizeof(struct stv6110x_state), GFP_KERNEL);
+   if (!stv6110x)
+   return -ENOMEM;
+
+   stv6110x->frontend   = config->frontend;
+   stv6110x->i2c= client->adapter;
+   stv6110x->config = config;
+   stv6110x->devctl = _ctl;
+
+   st6110x_init_regs(stv6110x);
+   stv6110x_setup_divider(stv6110x);
+   stv6110x_set_frontend_opts(stv6110x);
+
+   printk(KERN_INFO "%s: Probed STV6110x\n", __func__);
+
+   i2c_set_clientdata(client, stv6110x);
+
+   /* setup callbacks */
+   config->get_devctl = stv6110x_get_devctl;
+
+   return 0;
+}
+
+static int stv6110x_remove(struct i2c_client *client)
+{
+   struct stv6110x_state *stv6110x = i2c_get_clientdata(client);
+
+   stv6110x_release(stv6110x->frontend);
+   return 0;
+}
+
  const struct stv6110x_devctl *stv6110x_attach(struct dvb_frontend *fe,
const struct stv6110x_config *config,
struct i2c_adapter *i2c)
  {
struct stv6110x_state *stv6110x;
-   u8 default_regs[] = {0x07, 0x11, 0xdc, 0x85, 0x17, 0x01, 0xe6, 0x1e};
  
-	stv6110x = kzalloc(sizeof (struct stv6110x_state), GFP_KERNEL);

+   stv6110x = kzalloc(sizeof(struct stv6110x_state), GFP_KERNEL);
if (!stv6110x)
return NULL;
  
+	stv6110x->frontend	= fe;

stv6110x->i2c= i2c;
stv6110x->config = config;
stv6110x->devctl = _ctl;
-   memcpy(stv6110x->regs, default_regs, 8);
  
-	/* setup divider */

-   switch (stv6110x->config->clk_div) {
-   default:
-   case 1:
-   STV6110x_SETFIELD(stv6110x->regs[STV6110x_CTRL2], CTRL2_CO_DIV, 
0);
-   break;
-   case 2:
- 

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

[Tobias Klausmann]

On 12/18/17 7:06 PM, Mike Galbraith wrote:

Greetings,

Kernel bound workloads seem to trigger the below for whatever reason.
  I only see this when beating up NFS.  There was a kworker wakeup
latency issue, but with a bandaid applied to fix that up, I can still
trigger this.



Hi,

i have seen this one as well with my system, but i could not find an 
easy way to trigger it for bisecting purpose. If you can trigger it 
conveniently, a bisect would be nice!


Greetings,

Tobias




[ 1313.811031] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 1313.811035] swiotlb: coherent allocation failed for device :01:00.0 
size=2097152
[ 1313.811038] CPU: 6 PID: 3026 Comm: Xorg Tainted: GE
4.15.0.g1291a0d5-master #355
[ 1313.811040] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 
09/23/2013
[ 1313.811041] Call Trace:
[ 1313.811049]  dump_stack+0x7c/0xb6
[ 1313.811053]  swiotlb_alloc_coherent+0x13f/0x150
[ 1313.811060]  ttm_dma_pool_alloc_new_pages+0x106/0x3c0 [ttm]
[ 1313.811066]  ttm_dma_pool_get_pages+0x10a/0x1e0 [ttm]
[ 1313.811070]  ttm_dma_populate+0x21f/0x2f0 [ttm]
[ 1313.811075]  ttm_tt_bind+0x2f/0x60 [ttm]
[ 1313.811079]  ttm_bo_handle_move_mem+0x51f/0x580 [ttm]
[ 1313.811084]  ? ttm_bo_handle_move_mem+0x5/0x580 [ttm]
[ 1313.811088]  ttm_bo_validate+0x10c/0x120 [ttm]
[ 1313.811092]  ? ttm_bo_validate+0x5/0x120 [ttm]
[ 1313.811106]  ? drm_mode_setcrtc+0x20e/0x540 [drm]
[ 1313.811109]  ttm_bo_init_reserved+0x290/0x490 [ttm]
[ 1313.84]  ttm_bo_init+0x52/0xb0 [ttm]
[ 1313.811141]  ? nv10_bo_put_tile_region+0x60/0x60 [nouveau]
[ 1313.811163]  nouveau_bo_new+0x465/0x5e0 [nouveau]
[ 1313.811184]  ? nv10_bo_put_tile_region+0x60/0x60 [nouveau]
[ 1313.811203]  nouveau_gem_new+0x66/0x110 [nouveau]
[ 1313.811223]  ? nouveau_gem_new+0x110/0x110 [nouveau]
[ 1313.811241]  nouveau_gem_ioctl_new+0x48/0xc0 [nouveau]
[ 1313.811249]  drm_ioctl_kernel+0x64/0xb0 [drm]
[ 1313.811257]  drm_ioctl+0x2a4/0x360 [drm]
[ 1313.811276]  ? nouveau_gem_new+0x110/0x110 [nouveau]
[ 1313.811285]  ? drm_ioctl+0x5/0x360 [drm]
[ 1313.811304]  nouveau_drm_ioctl+0x50/0xb0 [nouveau]
[ 1313.811308]  do_vfs_ioctl+0x90/0x690
[ 1313.811311]  ? do_vfs_ioctl+0x5/0x690
[ 1313.811313]  SyS_ioctl+0x3b/0x70
[ 1313.811316]  entry_SYSCALL_64_fastpath+0x1f/0x91
[ 1313.811320] RIP: 0033:0x7f3234746227
[ 1313.811321] RSP: 002b:7ffc3ace0408 EFLAGS: 3246 ORIG_RAX: 
0010
[ 1313.811324] RAX: ffda RBX: 025515d0 RCX: 7f3234746227
[ 1313.811325] RDX: 7ffc3ace0460 RSI: c0306480 RDI: 000b
[ 1313.811326] RBP: 00824120 R08: 02548f80 R09: 025490d0
[ 1313.811328] R10:  R11: 3246 R12: 093d
[ 1313.811329] R13: 02aff74c R14: 00824150 R15: 

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

[Tobias Klausmann]

On 12/18/17 7:06 PM, Mike Galbraith wrote:

Greetings,

Kernel bound workloads seem to trigger the below for whatever reason.
  I only see this when beating up NFS.  There was a kworker wakeup
latency issue, but with a bandaid applied to fix that up, I can still
trigger this.



Hi,

i have seen this one as well with my system, but i could not find an 
easy way to trigger it for bisecting purpose. If you can trigger it 
conveniently, a bisect would be nice!


Greetings,

Tobias




[ 1313.811031] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[ 1313.811035] swiotlb: coherent allocation failed for device :01:00.0 
size=2097152
[ 1313.811038] CPU: 6 PID: 3026 Comm: Xorg Tainted: GE
4.15.0.g1291a0d5-master #355
[ 1313.811040] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 
09/23/2013
[ 1313.811041] Call Trace:
[ 1313.811049]  dump_stack+0x7c/0xb6
[ 1313.811053]  swiotlb_alloc_coherent+0x13f/0x150
[ 1313.811060]  ttm_dma_pool_alloc_new_pages+0x106/0x3c0 [ttm]
[ 1313.811066]  ttm_dma_pool_get_pages+0x10a/0x1e0 [ttm]
[ 1313.811070]  ttm_dma_populate+0x21f/0x2f0 [ttm]
[ 1313.811075]  ttm_tt_bind+0x2f/0x60 [ttm]
[ 1313.811079]  ttm_bo_handle_move_mem+0x51f/0x580 [ttm]
[ 1313.811084]  ? ttm_bo_handle_move_mem+0x5/0x580 [ttm]
[ 1313.811088]  ttm_bo_validate+0x10c/0x120 [ttm]
[ 1313.811092]  ? ttm_bo_validate+0x5/0x120 [ttm]
[ 1313.811106]  ? drm_mode_setcrtc+0x20e/0x540 [drm]
[ 1313.811109]  ttm_bo_init_reserved+0x290/0x490 [ttm]
[ 1313.84]  ttm_bo_init+0x52/0xb0 [ttm]
[ 1313.811141]  ? nv10_bo_put_tile_region+0x60/0x60 [nouveau]
[ 1313.811163]  nouveau_bo_new+0x465/0x5e0 [nouveau]
[ 1313.811184]  ? nv10_bo_put_tile_region+0x60/0x60 [nouveau]
[ 1313.811203]  nouveau_gem_new+0x66/0x110 [nouveau]
[ 1313.811223]  ? nouveau_gem_new+0x110/0x110 [nouveau]
[ 1313.811241]  nouveau_gem_ioctl_new+0x48/0xc0 [nouveau]
[ 1313.811249]  drm_ioctl_kernel+0x64/0xb0 [drm]
[ 1313.811257]  drm_ioctl+0x2a4/0x360 [drm]
[ 1313.811276]  ? nouveau_gem_new+0x110/0x110 [nouveau]
[ 1313.811285]  ? drm_ioctl+0x5/0x360 [drm]
[ 1313.811304]  nouveau_drm_ioctl+0x50/0xb0 [nouveau]
[ 1313.811308]  do_vfs_ioctl+0x90/0x690
[ 1313.811311]  ? do_vfs_ioctl+0x5/0x690
[ 1313.811313]  SyS_ioctl+0x3b/0x70
[ 1313.811316]  entry_SYSCALL_64_fastpath+0x1f/0x91
[ 1313.811320] RIP: 0033:0x7f3234746227
[ 1313.811321] RSP: 002b:7ffc3ace0408 EFLAGS: 3246 ORIG_RAX: 
0010
[ 1313.811324] RAX: ffda RBX: 025515d0 RCX: 7f3234746227
[ 1313.811325] RDX: 7ffc3ace0460 RSI: c0306480 RDI: 000b
[ 1313.811326] RBP: 00824120 R08: 02548f80 R09: 025490d0
[ 1313.811328] R10:  R11: 3246 R12: 093d
[ 1313.811329] R13: 02aff74c R14: 00824150 R15: 

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/24/17 4:35 PM, Christian König wrote:

Am 24.11.2017 um 16:17 schrieb Tobias Klausmann:


On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott <labb...@redhat.com> 
wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute 
bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4

nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec 
irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm 
soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 
8021q garp

mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul 
crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring 
virtio

ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 
1996), BIOS

1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 
44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 
fe ff ff

<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: 
a7818222bba8

[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 




Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc 
huge

dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this 
cycle with

ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only 
show when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are 
enable. Thanks Dave for pointing me to that!


Yeah, sorry for that. I missed to handle the DMA32 case with 
tran

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/24/17 4:35 PM, Christian König wrote:

Am 24.11.2017 um 16:17 schrieb Tobias Klausmann:


On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:
On 23 November 2017 at 11:17, Laura Abbott  
wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT 
nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute 
bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 
ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4

nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec 
irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm 
bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm 
soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 
8021q garp

mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul 
crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring 
virtio

ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 
1996), BIOS

1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 
44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 
fe ff ff

<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: 
a7818222bba8

[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0 




Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc 
huge

dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this 
cycle with

ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only 
show when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are 
enable. Thanks Dave for pointing me to that!


Yeah, sorry for that. I missed to handle the DMA32 case with 
transparent huge page support.

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott <labb...@redhat.com> wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this cycle with
ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only show 
when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are enable. 
Thanks Dave for pointing me to that!



Greetings,

Tobias



Greetings,

Tobias


[1]:


[  404.918139] [ cut here ]
[  404.918147] kernel BUG at mm/shmem.c:4334!
[  404.918152] invalid opcode:  [#2]

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/24/17 3:54 PM, Daniel Vetter wrote:

On Thu, Nov 23, 2017 at 03:24:38PM +0100, Tobias Klausmann wrote:

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott  wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.


Hi Dave,

fyi only: It looks like this is not the only regression in this cycle with
ttm, novueau seems to suffer as well [1].

Adding ttm folks. Might be useful if we have an entry for ttm in
MAINTAINERS ...
-Daniel



A bit more of investigation for the nouveau regression: This only show 
when Transparent Hugepages (CONFIG_TRANSPARENT_HUGEPAGE) are enable. 
Thanks Dave for pointing me to that!



Greetings,

Tobias



Greetings,

Tobias


[1]:


[  404.918139] [ cut here ]
[  404.918147] kernel BUG at mm/shmem.c:4334!
[  404.918152] invalid opcode:  [#2] PREEMPT SMP
[  404.

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott  wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.



Hi Dave,

fyi only: It looks like this is not the only regression in this cycle 
with ttm, novueau seems to suffer as well [1].


Greetings,

Tobias


[1]:


[  404.918139] [ cut here ]
[  404.918147] kernel BUG at mm/shmem.c:4334!
[  404.918152] invalid opcode:  [#2] PREEMPT SMP
[  404.918157] Modules linked in: rfcomm af_packet bnep uvcvideo 
videobuf2_vmalloc videobuf2_memops rtsx_usb_ms videobuf2_v4l2 memstick 
videodev videobuf2_core btusb btrtl btbcm arc4 msr snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 
nls_cp437 hid_multitouch vfat fat iTCO_wdt iTCO_vendor_support 
intel_rapl x86_pkg_temp_thermal intel_powerclamp ath10k_pci 

Re: Regression in TTM driver w/Linus' master

[Tobias Klausmann]

On 11/23/17 2:58 AM, Dave Airlie wrote:

On 23 November 2017 at 11:17, Laura Abbott  wrote:

Hi,

Fedora QA testing reported a panic when booting up VMs
using qmeu vga drivers
(https://paste.fedoraproject.org/paste/498yRWTCJv2LKIrmj4EliQ)

[   30.108507] [ cut here ]
[   30.108920] kernel BUG at ./include/linux/gfp.h:408!
[   30.109356] invalid opcode:  [#1] SMP
[   30.109700] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack devlink ip_set nfnetlink ebtable_nat ebtable_broute bridge
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
snd_hda_codec_generic kvm_intel kvm snd_hda_intel snd_hda_codec irqbypass
ppdev snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm bochs_drm ttm
joydev drm_kms_helper virtio_balloon snd_timer snd parport_pc drm soundcore
parport i2c_piix4 nls_utf8 isofs squashfs zstd_decompress xxhash 8021q garp
mrp stp llc virtio_net
[   30.115605]  virtio_console virtio_scsi crct10dif_pclmul crc32_pclmul
crc32c_intel ghash_clmulni_intel serio_raw virtio_pci virtio_ring virtio
ata_generic pata_acpi qemu_fw_cfg sunrpc scsi_transport_iscsi loop
[   30.117425] CPU: 0 PID: 1347 Comm: gnome-shell Not tainted
4.15.0-0.rc0.git6.1.fc28.x86_64 #1
[   30.118141] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-2.fc27 04/01/2014
[   30.118866] task: 923a77e03380 task.stack: a78182228000
[   30.119366] RIP: 0010:__alloc_pages_nodemask+0x35e/0x430
[   30.119810] RSP: :a7818222bba8 EFLAGS: 00010202
[   30.120250] RAX: 0001 RBX: 014382c6 RCX:
0006
[   30.120840] RDX:  RSI: 0009 RDI:

[   30.121443] RBP: 923a760d6000 R08:  R09:
0006
[   30.122039] R10: 0040 R11: 0300 R12:
923a729273c0
[   30.122629] R13:  R14:  R15:
923a7483d400
[   30.123223] FS:  7fe48da7dac0() GS:923a7cc0()
knlGS:
[   30.123896] CS:  0010 DS:  ES:  CR0: 80050033
[   30.124373] CR2: 7fe457b73000 CR3: 78313000 CR4:
06f0
[   30.124968] Call Trace:
[   30.125186]  ttm_pool_populate+0x19b/0x400 [ttm]
[   30.125578]  ttm_bo_vm_fault+0x325/0x570 [ttm]
[   30.125964]  __do_fault+0x19/0x11e
[   30.126255]  __handle_mm_fault+0xcd3/0x1260
[   30.126609]  handle_mm_fault+0x14c/0x310
[   30.126947]  __do_page_fault+0x28c/0x530
[   30.127282]  do_page_fault+0x32/0x270
[   30.127593]  async_page_fault+0x22/0x30
[   30.127922] RIP: 0033:0x7fe48aae39a8
[   30.128225] RSP: 002b:7ffc21c4d928 EFLAGS: 00010206
[   30.128664] RAX: 7fe457b73000 RBX: 55cd4c1041a0 RCX:
7fe457b73040
[   30.129259] RDX: 0030 RSI:  RDI:
7fe457b73000
[   30.129855] RBP: 0300 R08: 000c R09:
0001
[   30.130457] R10: 0001 R11: 0246 R12:
55cd4c1041a0
[   30.131054] R13: 55cd4bdfe990 R14: 55cd4c104110 R15:
0400
[   30.131648] Code: 11 01 00 0f 84 a9 00 00 00 65 ff 0d 6d cc dd 44 e9 0f
ff ff ff 40 80 cd 80 e9 99 fe ff ff 48 89 c7 e8 e7 f6 01 00 e9 b7 fe ff ff
<0f> 0b 0f ff e9 40 fd ff ff 65 48 8b 04 25 80 d5 00 00 8b 40 4c
[   30.133245] RIP: __alloc_pages_nodemask+0x35e/0x430 RSP: a7818222bba8
[   30.133836] ---[ end trace d4f1deb60784f40a ]---

This is based off of Linus' master branch at
c8a0739b185d11d6e2ca7ad9f5835841d1cfc765
Configs are at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/commit/?h=rawhide=0be14662c54f49b4e640868b9d67df18d39edff0


Looks like a TTM regression due to:

0284f1ead87463bc17cf5e81a24fc65c052486f3
drm/ttm: add transparent huge page support for cached allocations v2

If the driver requests dma32 pages, we can end up trying to alloc huge
dma32 pages which triggers the oops. The bochs driver always requests
dma32 here.

I'll send a rough patch once I boot it.

Dave.



Hi Dave,

fyi only: It looks like this is not the only regression in this cycle 
with ttm, novueau seems to suffer as well [1].


Greetings,

Tobias


[1]:


[  404.918139] [ cut here ]
[  404.918147] kernel BUG at mm/shmem.c:4334!
[  404.918152] invalid opcode:  [#2] PREEMPT SMP
[  404.918157] Modules linked in: rfcomm af_packet bnep uvcvideo 
videobuf2_vmalloc videobuf2_memops rtsx_usb_ms videobuf2_v4l2 memstick 
videodev videobuf2_core btusb btrtl btbcm arc4 msr snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 
nls_cp437 hid_multitouch vfat fat iTCO_wdt iTCO_vendor_support 
intel_rapl x86_pkg_temp_thermal intel_powerclamp ath10k_pci coretemp 
ath10k_core ath 

Re: [PATCH 17/29] drm/nouveau: switch to drm_*{get,put} helpers

[Tobias Klausmann]

Looks good to me!

Reviewed-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>


On 8/3/17 1:58 PM, Cihangir Akturk wrote:
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() adn should not be
> used by new code. So convert all users of compatibility functions to use
> the new APIs.
>
> Signed-off-by: Cihangir Akturk <cakt...@gmail.com>
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_abi16.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c |  8 
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++---
>  drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
>  6 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 4b4b0b4..18b4be1 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1019,7 +1019,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
> drm_file *file_priv,
>   nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
>   nv_crtc->cursor.show(nv_crtc, true);
>  out:
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index f98f800..3e9db5a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -136,7 +136,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
>   if (chan->ntfy) {
>   nouveau_bo_vma_del(chan->ntfy, >ntfy_vma);
>   nouveau_bo_unpin(chan->ntfy);
> - drm_gem_object_unreference_unlocked(>ntfy->gem);
> + drm_gem_object_put_unlocked(>ntfy->gem);
>   }
>  
>   if (chan->heap.block_size)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 8d1df56..a68fe1a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -206,7 +206,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer 
> *drm_fb)
>   struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
>  
>   if (fb->nvbo)
> - drm_gem_object_unreference_unlocked(>nvbo->gem);
> + drm_gem_object_put_unlocked(>nvbo->gem);
>  
>   drm_framebuffer_cleanup(drm_fb);
>   kfree(fb);
> @@ -267,7 +267,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>   if (ret == 0)
>   return >base;
>  
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return ERR_PTR(ret);
>  }
>  
> @@ -947,7 +947,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, 
> struct drm_device *dev,
>   return ret;
>  
>   ret = drm_gem_handle_create(file_priv, >gem, >handle);
> - drm_gem_object_unreference_unlocked(>gem);
> + drm_gem_object_put_unlocked(>gem);
>   return ret;
>  }
>  
> @@ -962,7 +962,7 @@ nouveau_display_dumb_map_offset(struct drm_file 
> *file_priv,
>   if (gem) {
>   struct nouveau_bo *bo = nouveau_gem_object(gem);
>   *poffset = drm_vma_node_offset_addr(>bo.vma_node);
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return 0;
>   }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index 2665a07..6c9e1ec 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -451,7 +451,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct 
> nouveau_fbdev *fbcon)
>   nouveau_bo_vma_del(nouveau_fb->nvbo, _fb->vma);
>   nouveau_bo_unmap(nouveau_fb->nvbo);
>   nouveau_bo_unpin(nouveau_fb->nvbo);
> - drm_framebuffer_unreference(_fb->base);
> + drm_framebuffer_put(_fb->base);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 2170534..653425c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -281,7 +281,7 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
>   }
>  
>   /* drop reference from allocate - 

Re: [PATCH 17/29] drm/nouveau: switch to drm_*{get,put} helpers

[Tobias Klausmann]

Looks good to me!

Reviewed-by: Tobias Klausmann 


On 8/3/17 1:58 PM, Cihangir Akturk wrote:
> drm_*_reference() and drm_*_unreference() functions are just
> compatibility alias for drm_*_get() and drm_*_put() adn should not be
> used by new code. So convert all users of compatibility functions to use
> the new APIs.
>
> Signed-off-by: Cihangir Akturk 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_abi16.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c |  8 
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++---
>  drivers/gpu/drm/nouveau/nv50_display.c|  2 +-
>  6 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 4b4b0b4..18b4be1 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1019,7 +1019,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
> drm_file *file_priv,
>   nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
>   nv_crtc->cursor.show(nv_crtc, true);
>  out:
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index f98f800..3e9db5a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -136,7 +136,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
>   if (chan->ntfy) {
>   nouveau_bo_vma_del(chan->ntfy, >ntfy_vma);
>   nouveau_bo_unpin(chan->ntfy);
> - drm_gem_object_unreference_unlocked(>ntfy->gem);
> + drm_gem_object_put_unlocked(>ntfy->gem);
>   }
>  
>   if (chan->heap.block_size)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 8d1df56..a68fe1a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -206,7 +206,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer 
> *drm_fb)
>   struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
>  
>   if (fb->nvbo)
> - drm_gem_object_unreference_unlocked(>nvbo->gem);
> + drm_gem_object_put_unlocked(>nvbo->gem);
>  
>   drm_framebuffer_cleanup(drm_fb);
>   kfree(fb);
> @@ -267,7 +267,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>   if (ret == 0)
>   return >base;
>  
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return ERR_PTR(ret);
>  }
>  
> @@ -947,7 +947,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, 
> struct drm_device *dev,
>   return ret;
>  
>   ret = drm_gem_handle_create(file_priv, >gem, >handle);
> - drm_gem_object_unreference_unlocked(>gem);
> + drm_gem_object_put_unlocked(>gem);
>   return ret;
>  }
>  
> @@ -962,7 +962,7 @@ nouveau_display_dumb_map_offset(struct drm_file 
> *file_priv,
>   if (gem) {
>   struct nouveau_bo *bo = nouveau_gem_object(gem);
>   *poffset = drm_vma_node_offset_addr(>bo.vma_node);
> - drm_gem_object_unreference_unlocked(gem);
> + drm_gem_object_put_unlocked(gem);
>   return 0;
>   }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index 2665a07..6c9e1ec 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -451,7 +451,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct 
> nouveau_fbdev *fbcon)
>   nouveau_bo_vma_del(nouveau_fb->nvbo, _fb->vma);
>   nouveau_bo_unmap(nouveau_fb->nvbo);
>   nouveau_bo_unpin(nouveau_fb->nvbo);
> - drm_framebuffer_unreference(_fb->base);
> + drm_framebuffer_put(_fb->base);
>   }
>  
>   return 0;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
> b/drivers/gpu/drm/nouveau/nouveau_gem.c
> index 2170534..653425c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
> @@ -281,7 +281,7 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
>   }
>  
>   /* drop reference from allocate - handle holds it now */
> - drm_gem_object_unreference_un

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

[Tobias Klausmann]

Mh ok,

paper over in nouveau_display_fini until Ben comes up with a better idea
then?!


Greetings,

Tobias


On 7/20/17 10:13 AM, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote:
>> I believe the solution is to not call drm_crtc_vblank_off for atomic
>> modesetting in nouveau_display_fini. I think Ben's working on it.
> Yes, the goal of vblank_on/off was very much to not paper over driver bugs
> with clever tricks like these. If the driver cant keep track of its
> vblank, something has gone wrong, and the core should _not_ fix it up.
> Otherwise we're back to the old style vblank horror show.
>
> Thanks, Daniel
>
>> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann
>> <tobias.johannes.klausm...@mni.thm.de> wrote:
>>> mimic the behavior of vblank_disable_fn(), another caller of
>>> drm_vblank_disable_and_save().
>>>
>>> This avoids oopsing, while trying to disable vblank on a not connected 
>>> display:
>>>
>>> [   12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 
>>> drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
>>> [   12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc 
>>> uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops 
>>> videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 
>>> snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 
>>> hid_multitouch nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp 
>>> vfat coretemp fat kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass 
>>> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc 
>>> aesni_intel ath10k_pci snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec 
>>> crypto_simd ath glue_helper cryptd snd_hda_core mac80211 snd_hwdep snd_pcm 
>>> pcspkr r8169 cfg80211 mii snd_timer acer_wmi snd sparse_keymap wmi_bmof 
>>> idma64 hci_uart virt_dma mei_me soundcore i2c_i801 mei btbcm shpchp 
>>> intel_lpss_pci intel_pch_thermal
>>> [   12.768130]  serdev btqca ucsi_acpi btintel typec_ucsi thermal typec 
>>> bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill 
>>> intel_lpss_acpi pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 
>>> mxm_wmi ttm i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect 
>>> sysimgblt xhci_hcd fb_sys_fops usbcore drm i2c_hid wmi video button sg 
>>> efivarfs
>>> [   12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 
>>> 4.12.0-desktop-debug-drm+ #2
>>> [   12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 
>>> 03/30/2017
>>> [   12.768164] Workqueue: pm pm_runtime_work
>>> [   12.768166] task: 889bf1627040 task.stack: 9541013e4000
>>> [   12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 
>>> [drm]
>>> [   12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086
>>> [   12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 
>>> 0004
>>> [   12.768184] RDX: 8004 RSI: 87a2d952 RDI: 
>>> 
>>> [   12.768186] RBP: 9541013e7b90 R08: 0001 R09: 
>>> 039f
>>> [   12.768187] R10: c05fe530 R11:  R12: 
>>> 
>>> [   12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 
>>> 889bf0426000
>>> [   12.768190] FS:  () GS:889bfec0() 
>>> knlGS:
>>> [   12.768191] CS:  0010 DS:  ES:  CR0: 80050033
>>> [   12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 
>>> 003406f0
>>> [   12.768193] Call Trace:
>>> [   12.768198]  ? enqueue_task_fair+0x64/0x600
>>> [   12.768211]  ? drm_get_last_vbltimestamp+0x47/0x70 [drm]
>>> [   12.768223]  ? drm_update_vblank_count+0x65/0x240 [drm]
>>> [   12.768227]  ? pci_pm_runtime_resume+0xa0/0xa0
>>> [   12.768238]  ? drm_vblank_disable_and_save+0x55/0xc0 [drm]
>>> [   12.768250]  ? drm_crtc_vblank_off+0xa9/0x1e0 [drm]
>>> [   12.768253]  ? pci_pm_runtime_resume+0xa0/0xa0
>>> [   12.768299]  ? nouveau_display_fini+0x56/0xd0 [nouveau]
>>> [   12.768339]  ? nouveau_display_suspend+0x51/0x110 [nouveau]
>>> [   12.768378]  ? nouveau_do_suspend+0x76/0x1c0 [nouveau]
>>> [   12.768413]  ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau]
>>> [   12.768416]  ? pci_pm_runtime_suspend+0x5c/0x160
>>> [   12.768419]  ? __rpm_callback+0xb6/0x1e0
>>

Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled

[Tobias Klausmann]

Mh ok,

paper over in nouveau_display_fini until Ben comes up with a better idea
then?!


Greetings,

Tobias


On 7/20/17 10:13 AM, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote:
>> I believe the solution is to not call drm_crtc_vblank_off for atomic
>> modesetting in nouveau_display_fini. I think Ben's working on it.
> Yes, the goal of vblank_on/off was very much to not paper over driver bugs
> with clever tricks like these. If the driver cant keep track of its
> vblank, something has gone wrong, and the core should _not_ fix it up.
> Otherwise we're back to the old style vblank horror show.
>
> Thanks, Daniel
>
>> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann
>>  wrote:
>>> mimic the behavior of vblank_disable_fn(), another caller of
>>> drm_vblank_disable_and_save().
>>>
>>> This avoids oopsing, while trying to disable vblank on a not connected 
>>> display:
>>>
>>> [   12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 
>>> drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
>>> [   12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc 
>>> uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops 
>>> videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 
>>> snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 
>>> hid_multitouch nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp 
>>> vfat coretemp fat kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass 
>>> crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc 
>>> aesni_intel ath10k_pci snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec 
>>> crypto_simd ath glue_helper cryptd snd_hda_core mac80211 snd_hwdep snd_pcm 
>>> pcspkr r8169 cfg80211 mii snd_timer acer_wmi snd sparse_keymap wmi_bmof 
>>> idma64 hci_uart virt_dma mei_me soundcore i2c_i801 mei btbcm shpchp 
>>> intel_lpss_pci intel_pch_thermal
>>> [   12.768130]  serdev btqca ucsi_acpi btintel typec_ucsi thermal typec 
>>> bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill 
>>> intel_lpss_acpi pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 
>>> mxm_wmi ttm i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect 
>>> sysimgblt xhci_hcd fb_sys_fops usbcore drm i2c_hid wmi video button sg 
>>> efivarfs
>>> [   12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 
>>> 4.12.0-desktop-debug-drm+ #2
>>> [   12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 
>>> 03/30/2017
>>> [   12.768164] Workqueue: pm pm_runtime_work
>>> [   12.768166] task: 889bf1627040 task.stack: 9541013e4000
>>> [   12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 
>>> [drm]
>>> [   12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086
>>> [   12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 
>>> 0004
>>> [   12.768184] RDX: 8004 RSI: 87a2d952 RDI: 
>>> 
>>> [   12.768186] RBP: 9541013e7b90 R08: 0001 R09: 
>>> 039f
>>> [   12.768187] R10: c05fe530 R11:  R12: 
>>> 
>>> [   12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 
>>> 889bf0426000
>>> [   12.768190] FS:  () GS:889bfec0() 
>>> knlGS:
>>> [   12.768191] CS:  0010 DS:  ES:  CR0: 80050033
>>> [   12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 
>>> 003406f0
>>> [   12.768193] Call Trace:
>>> [   12.768198]  ? enqueue_task_fair+0x64/0x600
>>> [   12.768211]  ? drm_get_last_vbltimestamp+0x47/0x70 [drm]
>>> [   12.768223]  ? drm_update_vblank_count+0x65/0x240 [drm]
>>> [   12.768227]  ? pci_pm_runtime_resume+0xa0/0xa0
>>> [   12.768238]  ? drm_vblank_disable_and_save+0x55/0xc0 [drm]
>>> [   12.768250]  ? drm_crtc_vblank_off+0xa9/0x1e0 [drm]
>>> [   12.768253]  ? pci_pm_runtime_resume+0xa0/0xa0
>>> [   12.768299]  ? nouveau_display_fini+0x56/0xd0 [nouveau]
>>> [   12.768339]  ? nouveau_display_suspend+0x51/0x110 [nouveau]
>>> [   12.768378]  ? nouveau_do_suspend+0x76/0x1c0 [nouveau]
>>> [   12.768413]  ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau]
>>> [   12.768416]  ? pci_pm_runtime_suspend+0x5c/0x160
>>> [   12.768419]  ? __rpm_callback+0xb6/0x1e0
>>> [   12.768423]  ? kobject_uevent_env+0x111/0x5e0
>>

[PATCH] drm: disable vblank only if it got previously enabled

[Tobias Klausmann]

mimic the behavior of vblank_disable_fn(), another caller of
drm_vblank_disable_and_save().

This avoids oopsing, while trying to disable vblank on a not connected display:

[   12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 
drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc 
uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops 
videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 hid_multitouch 
nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp vfat coretemp fat 
kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel ath10k_pci 
snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec crypto_simd ath glue_helper 
cryptd snd_hda_core mac80211 snd_hwdep snd_pcm pcspkr r8169 cfg80211 mii 
snd_timer acer_wmi snd sparse_keymap wmi_bmof idma64 hci_uart virt_dma mei_me 
soundcore i2c_i801 mei btbcm shpchp intel_lpss_pci intel_pch_thermal
[   12.768130]  serdev btqca ucsi_acpi btintel typec_ucsi thermal typec 
bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill intel_lpss_acpi 
pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 mxm_wmi ttm 
i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect sysimgblt xhci_hcd 
fb_sys_fops usbcore drm i2c_hid wmi video button sg efivarfs
[   12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 
4.12.0-desktop-debug-drm+ #2
[   12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 
03/30/2017
[   12.768164] Workqueue: pm pm_runtime_work
[   12.768166] task: 889bf1627040 task.stack: 9541013e4000
[   12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086
[   12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 0004
[   12.768184] RDX: 8004 RSI: 87a2d952 RDI: 
[   12.768186] RBP: 9541013e7b90 R08: 0001 R09: 039f
[   12.768187] R10: c05fe530 R11:  R12: 
[   12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 889bf0426000
[   12.768190] FS:  () GS:889bfec0() 
knlGS:
[   12.768191] CS:  0010 DS:  ES:  CR0: 80050033
[   12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 003406f0
[   12.768193] Call Trace:
[   12.768198]  ? enqueue_task_fair+0x64/0x600
[   12.768211]  ? drm_get_last_vbltimestamp+0x47/0x70 [drm]
[   12.768223]  ? drm_update_vblank_count+0x65/0x240 [drm]
[   12.768227]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768238]  ? drm_vblank_disable_and_save+0x55/0xc0 [drm]
[   12.768250]  ? drm_crtc_vblank_off+0xa9/0x1e0 [drm]
[   12.768253]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768299]  ? nouveau_display_fini+0x56/0xd0 [nouveau]
[   12.768339]  ? nouveau_display_suspend+0x51/0x110 [nouveau]
[   12.768378]  ? nouveau_do_suspend+0x76/0x1c0 [nouveau]
[   12.768413]  ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau]
[   12.768416]  ? pci_pm_runtime_suspend+0x5c/0x160
[   12.768419]  ? __rpm_callback+0xb6/0x1e0
[   12.768423]  ? kobject_uevent_env+0x111/0x5e0
[   12.768425]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768427]  ? rpm_callback+0x1f/0x70
[   12.768429]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768431]  ? rpm_suspend+0x11f/0x640
[   12.768441]  ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper]
[   12.768447]  ? output_poll_execute+0x17b/0x1a0 [drm_kms_helper]
[   12.768449]  ? pm_runtime_work+0x64/0xa0
[   12.768453]  ? process_one_work+0x1db/0x410
[   12.768456]  ? worker_thread+0x47/0x3d0
[   12.768459]  ? process_one_work+0x410/0x410
[   12.768461]  ? kthread+0x117/0x130
[   12.768463]  ? kthread_create_on_node+0x40/0x40
[   12.768466]  ? ret_from_fork+0x25/0x30
[   12.768468] Code: 80 3d 26 f3 01 00 00 0f 85 ad fd ff ff 48 8b 43 20 48 c7 
c7 31 a2 20 c0 c6 05 0e f3 01 00 01 48 8b b0 60 01 00 00 e8 75 2e ec c6 <0f> ff 
e9 88 fd ff ff 31 f6 44 88 55 b0 e8 38 fa ed c6 44 0f b6
[   12.768508] ---[ end trace d9bb853af3659bd5 ]---

Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
---
 drivers/gpu/drm/drm_vblank.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index a233a6be934a..4a21756bf2bd 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1140,8 +1140,11 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
 
/* Avoid redundant vblank disables without previous
 * drm_crtc_vblank_on(). */
-   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset)
+   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || (!vblank->inmodeset &&
+

[PATCH] drm: disable vblank only if it got previously enabled

[Tobias Klausmann]

mimic the behavior of vblank_disable_fn(), another caller of
drm_vblank_disable_and_save().

This avoids oopsing, while trying to disable vblank on a not connected display:

[   12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 
drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc 
uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops 
videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 hid_multitouch 
nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp vfat coretemp fat 
kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel ath10k_pci 
snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec crypto_simd ath glue_helper 
cryptd snd_hda_core mac80211 snd_hwdep snd_pcm pcspkr r8169 cfg80211 mii 
snd_timer acer_wmi snd sparse_keymap wmi_bmof idma64 hci_uart virt_dma mei_me 
soundcore i2c_i801 mei btbcm shpchp intel_lpss_pci intel_pch_thermal
[   12.768130]  serdev btqca ucsi_acpi btintel typec_ucsi thermal typec 
bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill intel_lpss_acpi 
pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 mxm_wmi ttm 
i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect sysimgblt xhci_hcd 
fb_sys_fops usbcore drm i2c_hid wmi video button sg efivarfs
[   12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 
4.12.0-desktop-debug-drm+ #2
[   12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 
03/30/2017
[   12.768164] Workqueue: pm pm_runtime_work
[   12.768166] task: 889bf1627040 task.stack: 9541013e4000
[   12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086
[   12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 0004
[   12.768184] RDX: 8004 RSI: 87a2d952 RDI: 
[   12.768186] RBP: 9541013e7b90 R08: 0001 R09: 039f
[   12.768187] R10: c05fe530 R11:  R12: 
[   12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 889bf0426000
[   12.768190] FS:  () GS:889bfec0() 
knlGS:
[   12.768191] CS:  0010 DS:  ES:  CR0: 80050033
[   12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 003406f0
[   12.768193] Call Trace:
[   12.768198]  ? enqueue_task_fair+0x64/0x600
[   12.768211]  ? drm_get_last_vbltimestamp+0x47/0x70 [drm]
[   12.768223]  ? drm_update_vblank_count+0x65/0x240 [drm]
[   12.768227]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768238]  ? drm_vblank_disable_and_save+0x55/0xc0 [drm]
[   12.768250]  ? drm_crtc_vblank_off+0xa9/0x1e0 [drm]
[   12.768253]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768299]  ? nouveau_display_fini+0x56/0xd0 [nouveau]
[   12.768339]  ? nouveau_display_suspend+0x51/0x110 [nouveau]
[   12.768378]  ? nouveau_do_suspend+0x76/0x1c0 [nouveau]
[   12.768413]  ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau]
[   12.768416]  ? pci_pm_runtime_suspend+0x5c/0x160
[   12.768419]  ? __rpm_callback+0xb6/0x1e0
[   12.768423]  ? kobject_uevent_env+0x111/0x5e0
[   12.768425]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768427]  ? rpm_callback+0x1f/0x70
[   12.768429]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768431]  ? rpm_suspend+0x11f/0x640
[   12.768441]  ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper]
[   12.768447]  ? output_poll_execute+0x17b/0x1a0 [drm_kms_helper]
[   12.768449]  ? pm_runtime_work+0x64/0xa0
[   12.768453]  ? process_one_work+0x1db/0x410
[   12.768456]  ? worker_thread+0x47/0x3d0
[   12.768459]  ? process_one_work+0x410/0x410
[   12.768461]  ? kthread+0x117/0x130
[   12.768463]  ? kthread_create_on_node+0x40/0x40
[   12.768466]  ? ret_from_fork+0x25/0x30
[   12.768468] Code: 80 3d 26 f3 01 00 00 0f 85 ad fd ff ff 48 8b 43 20 48 c7 
c7 31 a2 20 c0 c6 05 0e f3 01 00 01 48 8b b0 60 01 00 00 e8 75 2e ec c6 <0f> ff 
e9 88 fd ff ff 31 f6 44 88 55 b0 e8 38 fa ed c6 44 0f b6
[   12.768508] ---[ end trace d9bb853af3659bd5 ]---

Signed-off-by: Tobias Klausmann 
---
 drivers/gpu/drm/drm_vblank.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index a233a6be934a..4a21756bf2bd 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1140,8 +1140,11 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
 
/* Avoid redundant vblank disables without previous
 * drm_crtc_vblank_on(). */
-   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset)
+   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || (!vblank->inmodeset &&
+   vblank->enabled)) {
+   DRM_DEBUG(&q

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

The conversion is a nice catch, but i'd like to have a bit more context, 
see below!


With a better description:

Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>


On 7/14/17 5:10 PM, Karol Herbst wrote:

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?

Reviewed-By: Karol Herbst <karolher...@gmail.com>

On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
<tobias.johannes.klausm...@mni.thm.de> wrote:

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

   All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
   drivers/gpu/drm/drm_vblank.c |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
  */
 if (mode->crtc_clock == 0) {
 DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n",
pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report
me.\n",


"report me" seems a bit odd, maybe just uninitialized mode?



+ dev->driver->name);
 return false;
 }



Hey,

confirmed this helps saving the box, but we still have to find the root
cause! Backtrace with the above fix applied (and the one which came in with
the latest drm-fixes merge)!


[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias
Reviewed-By: Karol Herbst <karolher...@gmail.com>
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

The conversion is a nice catch, but i'd like to have a bit more context, 
see below!


With a better description:

Tobias Klausmann 


On 7/14/17 5:10 PM, Karol Herbst wrote:

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
usage we could convert to WARN_ONCE?

Reviewed-By: Karol Herbst 

On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann
 wrote:

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

   All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
   drivers/gpu/drm/drm_vblank.c |3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
  */
 if (mode->crtc_clock == 0) {
 DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n",
pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report
me.\n",


"report me" seems a bit odd, maybe just uninitialized mode?



+ dev->driver->name);
 return false;
 }



Hey,

confirmed this helps saving the box, but we still have to find the root
cause! Backtrace with the above fix applied (and the one which came in with
the latest drm-fixes merge)!


[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias
Reviewed-By: Karol Herbst 
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

  All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
  drivers/gpu/drm/drm_vblank.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report me.\n",
+ dev->driver->name);
  
  		return false;

}



Hey,

confirmed this helps saving the box, but we still have to find the root 
cause! Backtrace with the above fix applied (and the one which came in 
with the latest drm-fixes merge)!



[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

On 7/14/17 3:41 PM, Mike Galbraith wrote:

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:

  All DRM did was to slip a
WARN_ON_ONCE() that nouveau triggers into a kernel module where such
things no longer warn, they blow the box out of the water.

BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c
into a WARN_ONCE(), and all is peachy, you get the warning, box lives.

---
  drivers/gpu/drm/drm_vblank.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -605,7 +605,8 @@ bool drm_calc_vbltimestamp_from_scanoutp
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
-   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+   WARN_ONCE(drm_drv_uses_atomic_modeset(dev), "%s: report me.\n",
+ dev->driver->name);
  
  		return false;

}



Hey,

confirmed this helps saving the box, but we still have to find the root 
cause! Backtrace with the above fix applied (and the one which came in 
with the latest drm-fixes merge)!



[1] https://hastebin.com/uyoqifijed.http

Thanks,

Tobias

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

On 7/12/17 7:19 PM, Mike Galbraith wrote:

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith  wrote:

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:

Some display stuff did change for 4.13 for GM20x+ boards. If it's not
too much trouble, a bisect would be pretty useful.

Bisection seemingly went fine, but the result is odd.

e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit

But it really really is bad.  Looking at gitk fork in the road leading
to it...

52d9d38c183b drm/sti:fix spelling mistake: "compoment" -> "component" - good
e4e818cc2d7c drm: make drm_panel.h self-contained - good
9cf8f5802f39 drm: add missing declaration to drm_blend.h  - good

Before the git highway splits, all is well.  The lane with commits
works fine at both ends, but e98c58e55f68 is busted.  Merge arfifact?

Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
any point. The last backmerge from Linus as far as I can tell was
v4.11-rc7. Could be an interaction with some out-of-tree change.

FWIW, checking out the fingered commit then..

git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting
the lot helped not at all.

Checking out 6b7781b42dc9 and reverting the fingered commit did.  Given
the nouveau bits reverted are mostly the vblank changes, CC to Daniel,
maybe he'll know why both GTX 980 and GeForce 8600 GT get all upset.

Either I'm damn lucky, both of my nvidia equipped boxen going boom 100%
repeatably, or there are a lot of folks out there who haven't yet tried
suspend with our latest/greatest kernel.  I suspect the later.

-Mike



I should have had a look at my inbox, would have save me a log of work 
bisecting. Yet i come to the same conclusion:


# first bad commit: [e98c58e55f68f8785aebfab1f8c9a03d8de0afe1] Merge tag 
'drm-misc-next-2017-05-16' of git://anongit.freedesktop.org/git/drm-misc 
into drm-next



I suspect it is some vblank change as it shows up in every trace i have 
seen while bisecting, but that is just a wild guess...


Greetings,

Tobias

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Tobias Klausmann]

On 7/12/17 7:19 PM, Mike Galbraith wrote:

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith  wrote:

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:

Some display stuff did change for 4.13 for GM20x+ boards. If it's not
too much trouble, a bisect would be pretty useful.

Bisection seemingly went fine, but the result is odd.

e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit

But it really really is bad.  Looking at gitk fork in the road leading
to it...

52d9d38c183b drm/sti:fix spelling mistake: "compoment" -> "component" - good
e4e818cc2d7c drm: make drm_panel.h self-contained - good
9cf8f5802f39 drm: add missing declaration to drm_blend.h  - good

Before the git highway splits, all is well.  The lane with commits
works fine at both ends, but e98c58e55f68 is busted.  Merge arfifact?

Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
any point. The last backmerge from Linus as far as I can tell was
v4.11-rc7. Could be an interaction with some out-of-tree change.

FWIW, checking out the fingered commit then..

git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting
the lot helped not at all.

Checking out 6b7781b42dc9 and reverting the fingered commit did.  Given
the nouveau bits reverted are mostly the vblank changes, CC to Daniel,
maybe he'll know why both GTX 980 and GeForce 8600 GT get all upset.

Either I'm damn lucky, both of my nvidia equipped boxen going boom 100%
repeatably, or there are a lot of folks out there who haven't yet tried
suspend with our latest/greatest kernel.  I suspect the later.

-Mike



I should have had a look at my inbox, would have save me a log of work 
bisecting. Yet i come to the same conclusion:


# first bad commit: [e98c58e55f68f8785aebfab1f8c9a03d8de0afe1] Merge tag 
'drm-misc-next-2017-05-16' of git://anongit.freedesktop.org/git/drm-misc 
into drm-next



I suspect it is some vblank change as it shows up in every trace i have 
seen while bisecting, but that is just a wild guess...


Greetings,

Tobias

Re: [PULL REQUEST] i2c for 4.12

[Tobias Klausmann]

If you find the time, please push it out to master for testing purpose! 
(my touchpad is broken as well: 9d6408433019bfae15e2d0d5f4498c4ff70b86c0 
- i2c: designware: don't infer timings described by ACPI from clock rate)



Thanks,

Tobias Klausmann


On 5/22/17 11:04 PM, Wolfram Sang wrote:

Confirmed. Initializing those fields to zero fixes it.

Thanks!

Re: [PULL REQUEST] i2c for 4.12

[Tobias Klausmann]

If you find the time, please push it out to master for testing purpose! 
(my touchpad is broken as well: 9d6408433019bfae15e2d0d5f4498c4ff70b86c0 
- i2c: designware: don't infer timings described by ACPI from clock rate)



Thanks,

Tobias Klausmann


On 5/22/17 11:04 PM, Wolfram Sang wrote:

Confirmed. Initializing those fields to zero fixes it.

Thanks!

Re: Question about DEC Alpha memory ordering

[Tobias Klausmann]

Hi! 

On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > can real DEC Alpha hardware end up with both instances of "r1"
> > > having the value 1?
> > 
> > I thought this question reminded me of something, so I found this:
> > > https://www.kernel.org/doc/Documentation/memory-barriers.txt
> > 
> > and I pasted in the content - David Howells is one of the authors and
> > maybe that is why the question sort of reminded me.
> > 
> > Maybe someone has an update but this is what was said then.
> 
> Well, thank you for pointing me to this, but my question was intended to
> check whether or not the words I helped to write in memory-barriers.txt
> are in fact accurate.  So if you have an SMP DEC Alpha system that you
> could provide remote access to, that would be very helpful!

I have a 4-cpu ES40. Send me a test program and I'll gladly run
it for you.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
Stargazer Sober Counsel (Zetetic Elench)

Re: Question about DEC Alpha memory ordering

[Tobias Klausmann]

Hi! 

On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > can real DEC Alpha hardware end up with both instances of "r1"
> > > having the value 1?
> > 
> > I thought this question reminded me of something, so I found this:
> > > https://www.kernel.org/doc/Documentation/memory-barriers.txt
> > 
> > and I pasted in the content - David Howells is one of the authors and
> > maybe that is why the question sort of reminded me.
> > 
> > Maybe someone has an update but this is what was said then.
> 
> Well, thank you for pointing me to this, but my question was intended to
> check whether or not the words I helped to write in memory-barriers.txt
> are in fact accurate.  So if you have an SMP DEC Alpha system that you
> could provide remote access to, that would be very helpful!

I have a 4-cpu ES40. Send me a test program and I'll gladly run
it for you.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
Stargazer Sober Counsel (Zetetic Elench)

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

[Tobias Klausmann]

On 18.12.2016 20:57, Valo, Kalle wrote:

Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> writes:


A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)

It's here:

https://patchwork.kernel.org/patch/9472709/


Good to know!



Hopefully Kalle will include it in one of his upcoming pull requests.

Yes, I'll try to get it to 4.10-rc2.


Thanks for the update!

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

[Tobias Klausmann]

On 18.12.2016 20:57, Valo, Kalle wrote:

Tobias Klausmann  writes:


A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)

It's here:

https://patchwork.kernel.org/patch/9472709/


Good to know!



Hopefully Kalle will include it in one of his upcoming pull requests.

Yes, I'll try to get it to 4.10-rc2.


Thanks for the update!

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

[Tobias Klausmann]

Hi,

A patch for this is already floating on the ML for a while now latest: 
(ath9k: do not return early to fix rcu unlocking)


Hopefully Kalle will include it in one of his upcoming pull requests.

Greetings,

Tobias


On 18.12.2016 16:59, Paul E. McKenney wrote:

On Sun, Dec 18, 2016 at 02:52:48PM +0100, Gabriel C wrote:

Hello,

while testing kernel 4.9 I run into a weird issue with the ath9k driver.

I can boot the box in console mode and it stay up sometime but is not usable.

Looks to me like someone forgot an rcu_read_unlock() somewhere.  Given that
the unmatched rcu_read_lock() appears in ath_tx_edma_tasklet(), perhaps
that is also where the missing rcu_read_unlock() is.  And sure enough,
in the middle of this function we have the following:

fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
return;
}

This will of course return while still in an RCU read-side critical
section.  The caller cannot tell the difference between a return here
and falling off the end of the function, so this is likely the bug.
Or one of the bugs, anyway.  Copying the author and committer for
their thoughts.

Please try the patch at the end of this email.

Thanx, Paul


from dmesg :

===
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G  I
---
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
  #0:  (rcu_read_lock){..}, at: [] 
ath_tx_edma_tasklet+0x0/0x460 [ath9k]

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G  I 4.9-fw1 #1
Hardware name: FUJITSU  PRIMERGY TX200 S5 
/D2709, BIOS 6.00 Rev. 1.14.2709  02/04/2013
  88043ee03f38 812cf0f3 81a11540 0001
  88043ee03f68 810b7865 81a55d58 88043efcedc0
  88083cb1ca00 00d1 88043ee03f88 810dbfe8
Call Trace:
  
  [] dump_stack+0x86/0xc3
  [] lockdep_rcu_suspicious+0xc5/0x100
  [] rcu_eqs_enter_common.constprop.62+0x128/0x130
  [] rcu_irq_exit+0x38/0x70
  [] irq_exit+0x74/0xd0
  [] do_IRQ+0x71/0x130
  [] common_interrupt+0x8c/0x8c
  
  [] ? cpuidle_enter_state+0x156/0x220
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x11d/0x210
  [] rest_init+0x12c/0x140
  [] start_kernel+0x40f/0x41c
  [] ? early_idt_handler_array+0x120/0x120
  [] x86_64_start_reservations+0x2a/0x2c
  [] x86_64_start_kernel+0xeb/0xf8



commit 5a16fed76936184a7ac22e466cf39bd8bb5ee65e
Author: Paul E. McKenney 
Date:   Sun Dec 18 07:49:00 2016 -0800

 drivers/ath: Add missing rcu_read_unlock() to ath_tx_edma_tasklet()
 
 Commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")

 added rcu_read_lock() and rcu_read_unlock() around the body of
 ath_tx_edma_tasklet(), but failed to add the needed rcu_read_unlock()
 before a "return" in the middle of this function.  This commit therefore
 adds the missing rcu_read_unlock().
 
 Reported-by: Gabriel C 

 Signed-off-by: Paul E. McKenney 
 Cc: Felix Fietkau 
 Cc: Kalle Valo 
 Cc: QCA ath9k Development 
 Cc: 

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();
return;
}
  

Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section

[Tobias Klausmann]

Hi,

A patch for this is already floating on the ML for a while now latest: 
(ath9k: do not return early to fix rcu unlocking)


Hopefully Kalle will include it in one of his upcoming pull requests.

Greetings,

Tobias


On 18.12.2016 16:59, Paul E. McKenney wrote:

On Sun, Dec 18, 2016 at 02:52:48PM +0100, Gabriel C wrote:

Hello,

while testing kernel 4.9 I run into a weird issue with the ath9k driver.

I can boot the box in console mode and it stay up sometime but is not usable.

Looks to me like someone forgot an rcu_read_unlock() somewhere.  Given that
the unmatched rcu_read_lock() appears in ath_tx_edma_tasklet(), perhaps
that is also where the missing rcu_read_unlock() is.  And sure enough,
in the middle of this function we have the following:

fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
return;
}

This will of course return while still in an RCU read-side critical
section.  The caller cannot tell the difference between a return here
and falling off the end of the function, so this is likely the bug.
Or one of the bugs, anyway.  Copying the author and committer for
their thoughts.

Please try the patch at the end of this email.

Thanx, Paul


from dmesg :

===
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G  I
---
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
  #0:  (rcu_read_lock){..}, at: [] 
ath_tx_edma_tasklet+0x0/0x460 [ath9k]

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G  I 4.9-fw1 #1
Hardware name: FUJITSU  PRIMERGY TX200 S5 
/D2709, BIOS 6.00 Rev. 1.14.2709  02/04/2013
  88043ee03f38 812cf0f3 81a11540 0001
  88043ee03f68 810b7865 81a55d58 88043efcedc0
  88083cb1ca00 00d1 88043ee03f88 810dbfe8
Call Trace:
  
  [] dump_stack+0x86/0xc3
  [] lockdep_rcu_suspicious+0xc5/0x100
  [] rcu_eqs_enter_common.constprop.62+0x128/0x130
  [] rcu_irq_exit+0x38/0x70
  [] irq_exit+0x74/0xd0
  [] do_IRQ+0x71/0x130
  [] common_interrupt+0x8c/0x8c
  
  [] ? cpuidle_enter_state+0x156/0x220
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x11d/0x210
  [] rest_init+0x12c/0x140
  [] start_kernel+0x40f/0x41c
  [] ? early_idt_handler_array+0x120/0x120
  [] x86_64_start_reservations+0x2a/0x2c
  [] x86_64_start_kernel+0xeb/0xf8



commit 5a16fed76936184a7ac22e466cf39bd8bb5ee65e
Author: Paul E. McKenney 
Date:   Sun Dec 18 07:49:00 2016 -0800

 drivers/ath: Add missing rcu_read_unlock() to ath_tx_edma_tasklet()
 
 Commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")

 added rcu_read_lock() and rcu_read_unlock() around the body of
 ath_tx_edma_tasklet(), but failed to add the needed rcu_read_unlock()
 before a "return" in the middle of this function.  This commit therefore
 adds the missing rcu_read_unlock().
 
 Reported-by: Gabriel C 

 Signed-off-by: Paul E. McKenney 
 Cc: Felix Fietkau 
 Cc: Kalle Valo 
 Cc: QCA ath9k Development 
 Cc: 

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();
return;
}
  

[PATCH v2] ath9k: do not return early to fix rcu unlocking

[Tobias Klausmann]

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:

 ===
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 ---
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){..}
 , at:
 [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  88025efc3f38 8132b1e5 88017ede4540 0001
  88025efc3f68 810a25f7 88025efcee60 88017edebdd8
  88025eeb5400 0091 88025efc3f88 810c3cd4
 Call Trace:
  
  [] dump_stack+0x68/0x93
  [] lockdep_rcu_suspicious+0xd7/0x110
  [] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [] rcu_irq_exit+0x44/0xa0
  [] irq_exit+0x61/0xd0
  [] do_IRQ+0x65/0x110
  [] common_interrupt+0x89/0x89
  
  [] ? cpuidle_enter_state+0x151/0x200
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x146/0x220
  [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Cc: <sta...@vger.kernel.org> # v4.9

---
v2: break instead of unlock (rename patch) [Felix Fietkau],
fix reference to commit [Kalle Valo]
---
 drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..e47286bf378e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,7 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
-   return;
+   break;
}
 
bf = list_first_entry(fifo_list, struct ath_buf, list);
-- 
2.11.0

[PATCH v2] ath9k: do not return early to fix rcu unlocking

[Tobias Klausmann]

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:

 ===
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 ---
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){..}
 , at:
 [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  88025efc3f38 8132b1e5 88017ede4540 0001
  88025efc3f68 810a25f7 88025efcee60 88017edebdd8
  88025eeb5400 0091 88025efc3f88 810c3cd4
 Call Trace:
  
  [] dump_stack+0x68/0x93
  [] lockdep_rcu_suspicious+0xd7/0x110
  [] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [] rcu_irq_exit+0x44/0xa0
  [] irq_exit+0x61/0xd0
  [] do_IRQ+0x65/0x110
  [] common_interrupt+0x89/0x89
  
  [] ? cpuidle_enter_state+0x151/0x200
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x146/0x220
  [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann 
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Cc:  # v4.9

---
v2: break instead of unlock (rename patch) [Felix Fietkau],
fix reference to commit [Kalle Valo]
---
 drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..e47286bf378e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,7 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
-   return;
+   break;
}
 
bf = list_first_entry(fifo_list, struct ath_buf, list);
-- 
2.11.0

Re: [PATCH] ath9k: unlock rcu read when returning early

[Tobias Klausmann]

On 13.12.2016 11:41, Felix Fietkau wrote:

On 2016-12-12 19:50, Tobias Klausmann wrote:

Starting with ath9k: use ieee80211_tx_status_noskb where possible
[d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() &&
rcu_read_unlock() yet on returning early in ath_tx_edma_tasklet() the unlock is
missing leading to stalls and suspicious RCU usage:

  ===
  [ INFO: suspicious RCU usage. ]
  4.9.0-rc8 #11 Not tainted
  ---
  kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

  other info that might help us debug this:

  RCU used illegally from idle CPU!
  rcu_scheduler_active = 1, debug_locks = 0
  RCU used illegally from extended quiescent state!
  1 lock held by swapper/7/0:
  #0:
   (
  rcu_read_lock
  ){..}
  , at:
  [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

  stack backtrace:
  CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
  Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
   88025efc3f38 8132b1e5 88017ede4540 0001
   88025efc3f68 810a25f7 88025efcee60 88017edebdd8
   88025eeb5400 0091 88025efc3f88 810c3cd4
  Call Trace:
   
   [] dump_stack+0x68/0x93
   [] lockdep_rcu_suspicious+0xd7/0x110
   [] rcu_eqs_enter_common.constprop.85+0x154/0x200
   [] rcu_irq_exit+0x44/0xa0
   [] irq_exit+0x61/0xd0
   [] do_IRQ+0x65/0x110
   [] common_interrupt+0x89/0x89
   
   [] ? cpuidle_enter_state+0x151/0x200
   [] cpuidle_enter+0x12/0x20
   [] call_cpuidle+0x1e/0x40
   [] cpu_startup_entry+0x146/0x220
   [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
---
  drivers/net/wireless/ath/ath9k/xmit.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();

Technically this is fine as well, but I'd prefer a fix where you replace
the 'return' with 'break', thus avoiding the duplication of
rcu_read_unlock()


Actually if you want to avoid it, maybe skipping over the rest is better 
(as originally intended):


...

ath_txq_unlock(sc, txq);


goto unlock;
}
...

unlock:
rcu_read_unlock();

Thanks,
Tobias


Thanks,

- Felix

Re: [PATCH] ath9k: unlock rcu read when returning early

[Tobias Klausmann]

On 13.12.2016 11:41, Felix Fietkau wrote:

On 2016-12-12 19:50, Tobias Klausmann wrote:

Starting with ath9k: use ieee80211_tx_status_noskb where possible
[d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() &&
rcu_read_unlock() yet on returning early in ath_tx_edma_tasklet() the unlock is
missing leading to stalls and suspicious RCU usage:

  ===
  [ INFO: suspicious RCU usage. ]
  4.9.0-rc8 #11 Not tainted
  ---
  kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

  other info that might help us debug this:

  RCU used illegally from idle CPU!
  rcu_scheduler_active = 1, debug_locks = 0
  RCU used illegally from extended quiescent state!
  1 lock held by swapper/7/0:
  #0:
   (
  rcu_read_lock
  ){..}
  , at:
  [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

  stack backtrace:
  CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
  Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
   88025efc3f38 8132b1e5 88017ede4540 0001
   88025efc3f68 810a25f7 88025efcee60 88017edebdd8
   88025eeb5400 0091 88025efc3f88 810c3cd4
  Call Trace:
   
   [] dump_stack+0x68/0x93
   [] lockdep_rcu_suspicious+0xd7/0x110
   [] rcu_eqs_enter_common.constprop.85+0x154/0x200
   [] rcu_irq_exit+0x44/0xa0
   [] irq_exit+0x61/0xd0
   [] do_IRQ+0x65/0x110
   [] common_interrupt+0x89/0x89
   
   [] ? cpuidle_enter_state+0x151/0x200
   [] cpuidle_enter+0x12/0x20
   [] call_cpuidle+0x1e/0x40
   [] cpu_startup_entry+0x146/0x220
   [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann 
---
  drivers/net/wireless/ath/ath9k/xmit.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();

Technically this is fine as well, but I'd prefer a fix where you replace
the 'return' with 'break', thus avoiding the duplication of
rcu_read_unlock()


Actually if you want to avoid it, maybe skipping over the rest is better 
(as originally intended):


...

ath_txq_unlock(sc, txq);


goto unlock;
}
...

unlock:
rcu_read_unlock();

Thanks,
Tobias


Thanks,

- Felix

[PATCH] ath9k: unlock rcu read when returning early

[Tobias Klausmann]

Starting with ath9k: use ieee80211_tx_status_noskb where possible
[d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() &&
rcu_read_unlock() yet on returning early in ath_tx_edma_tasklet() the unlock is
missing leading to stalls and suspicious RCU usage:

 ===
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 ---
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){..}
 , at:
 [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  88025efc3f38 8132b1e5 88017ede4540 0001
  88025efc3f68 810a25f7 88025efcee60 88017edebdd8
  88025eeb5400 0091 88025efc3f88 810c3cd4
 Call Trace:
  
  [] dump_stack+0x68/0x93
  [] lockdep_rcu_suspicious+0xd7/0x110
  [] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [] rcu_irq_exit+0x44/0xa0
  [] irq_exit+0x61/0xd0
  [] do_IRQ+0x65/0x110
  [] common_interrupt+0x89/0x89
  
  [] ? cpuidle_enter_state+0x151/0x200
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x146/0x220
  [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();
return;
}
 
-- 
2.11.0

[PATCH] ath9k: unlock rcu read when returning early

[Tobias Klausmann]

Starting with ath9k: use ieee80211_tx_status_noskb where possible
[d94a461d7a7df68991fb9663531173f60ef89c68] the driver uses rcu_read_lock() &&
rcu_read_unlock() yet on returning early in ath_tx_edma_tasklet() the unlock is
missing leading to stalls and suspicious RCU usage:

 ===
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 ---
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){..}
 , at:
 [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  88025efc3f38 8132b1e5 88017ede4540 0001
  88025efc3f68 810a25f7 88025efcee60 88017edebdd8
  88025eeb5400 0091 88025efc3f88 810c3cd4
 Call Trace:
  
  [] dump_stack+0x68/0x93
  [] lockdep_rcu_suspicious+0xd7/0x110
  [] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [] rcu_irq_exit+0x44/0xa0
  [] irq_exit+0x61/0xd0
  [] do_IRQ+0x65/0x110
  [] common_interrupt+0x89/0x89
  
  [] ? cpuidle_enter_state+0x151/0x200
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x146/0x220
  [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = >txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+   rcu_read_unlock();
return;
}
 
-- 
2.11.0

Re: ATH9 driver issues on ARM64

[Tobias Klausmann]

Hello there,

as this is a thread about ath9k and ARM64, i'm not sure if i should 
answer here or not, but i have similar "stalls" with ath9k on x86_64 
(starting with 4.9rc), stack trace is posted down below where the 
original ARM64 stall traces are.


Greetings,

Tobias


On 08.12.2016 18:36, Kalle Valo wrote:

Bharat Kumar Gogada  writes:


  > [+cc Kalle, ath9k list]

Thanks, but please also CC linux-wireless. Full thread below for the
folks there.


On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote:

Hi,

Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
on ARM64.  The end point is TP link wifi card with which supports
only legacy interrupts.

If it works on other arches and the arm64 PCI enumeration works, my
first guess would be an INTx issue, e.g., maybe the driver is waiting
for an interrupt that never arrives.

We are not sure for now.

We are trying to test it on ARM64 with
(drivers/pci/host/pcie-xilinx-nwl.c) as root port.

EP is getting enumerated and able to link up.

But when we start scan system gets hanged.

When you say the system hangs when you start a scan, I assume you mean
a wifi scan, not the PCI enumeration.  A problem with a wifi scan
might cause a *process* to hang, but it shouldn't hang the entire
system.


Yes wifi scan.

When we took trace we see that after we start scan assert message is
sent but there is no de assert from end point.

Are you talking about a trace from a PCIe analyzer?  Do you see an
Assert_INTx PCIe message on the link?


Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening when we 
do interface link up.
When we have less debug prints in Atheros driver, and do wifi scan we see 
Assert_INTx but never Deassert_INTx,

What might cause end point not sending de assert ?

If the endpoint doesn't send a Deassert_INTx message, I expect that
would mean the driver didn't service the interrupt and remove the
condition that caused the device to assert the interrupt in the first
place.

If the driver didn't receive the interrupt, it couldn't service it, of
course.  You could add a printk in the ath9k interrupt service
routine to see if you ever get there.


The interrupt behavior is changing w.r.t amount of debug prints we add. (I kept 
many prints to aid debug)
root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
[   83.064675] ath9k: ath9k_iowrite32 ff800a400024
[   83.069486] ath9k: ath9k_ioread32 ff800a400024
[   83.074257] ath9k_hw_kill_interrupts  793
[   83.078260] ath9k: ath9k_iowrite32 ff800a400024
[   83.083107] ath9k: ath9k_ioread32 ff800a400024
[   83.087882] ath9k_hw_kill_interrupts  793
[   83.095450] ath9k_hw_enable_interrupts821
[   83.099557] ath9k_hw_enable_interrupts825
[   83.103721] ath9k_hw_enable_interrupts832
[   83.107887] ath9k: ath9k_iowrite32 ff800a400024
[   83.112748] AR_SREV_9100 0
[   83.115438] ath9k_hw_enable_interrupts848
[   83.119607] ath9k: ath9k_ioread32 ff800a400024
[   83.124389] ath9k_hw_intrpend 762
[   83.127761] (AR_SREV_9340(ah) val 0
[   83.131234] ath9k_hw_intrpend 767
[   83.134628] ath_isr   603
[   83.137134] ath9k: ath9k_iowrite32 ff800a400024
[   83.141995] ath9k: ath9k_ioread32 ff800a400024
[   83.146771] ath9k_hw_kill_interrupts  793
[   83.150864] ath9k_hw_enable_interrupts821
[   83.154971] ath9k_hw_enable_interrupts825
[   83.159135] ath9k_hw_enable_interrupts832
[   83.163300] ath9k: ath9k_iowrite32 ff800a400024
[   83.168161] AR_SREV_9100 0
[   83.170852] ath9k_hw_enable_interrupts848
[   83.170855] ath9k_hw_intrpend 762
[   83.178398] (AR_SREV_9340(ah) val 0
[   83.181873] ath9k_hw_intrpend 767
[   83.185265] ath_isr   603
[   83.187773] ath9k: ath9k_iowrite32 ff800a400024
[   83.192635] ath9k: ath9k_ioread32 ff800a400024
[   83.197411] ath9k_hw_kill_interrupts  793
[   83.201414] ath9k: ath9k_ioread32 ff800a400024
[   83.206258] ath9k_hw_enable_interrupts821
[   83.210368] ath9k_hw_enable_interrupts825
[   83.214531] ath9k_hw_enable_interrupts832
[   83.218698] ath9k: ath9k_iowrite32 ff800a400024
[   83.223558] AR_SREV_9100 0
[   83.226243] ath9k_hw_enable_interrupts848
[   83.226246] ath9k_hw_intrpend 762
[   83.233794] (AR_SREV_9340(ah) val 0
[   83.237268] ath9k_hw_intrpend 767
[   83.240661] ath_isr   603
[   83.243169] ath9k: ath9k_iowrite32 ff800a400024
[   83.248030] ath9k: ath9k_ioread32 ff800a400024
[   83.252806] ath9k_hw_kill_interrupts  793
[   83.256811] ath9k: ath9k_ioread32 ff800a400024
[   83.261651] ath9k_hw_enable_interrupts821
[   83.265753] ath9k_hw_enable_interrupts825
[   83.269919] ath9k_hw_enable_interrupts832
[   83.274083] ath9k: ath9k_iowrite32 ff800a400024
[   83.278945] AR_SREV_9100 0
[   83.281630] ath9k_hw_enable_interrupts848
[   83.281633] 

Re: ATH9 driver issues on ARM64

[Tobias Klausmann]

Hello there,

as this is a thread about ath9k and ARM64, i'm not sure if i should 
answer here or not, but i have similar "stalls" with ath9k on x86_64 
(starting with 4.9rc), stack trace is posted down below where the 
original ARM64 stall traces are.


Greetings,

Tobias


On 08.12.2016 18:36, Kalle Valo wrote:

Bharat Kumar Gogada  writes:


  > [+cc Kalle, ath9k list]

Thanks, but please also CC linux-wireless. Full thread below for the
folks there.


On Thu, Dec 08, 2016 at 01:49:42PM +, Bharat Kumar Gogada wrote:

Hi,

Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
on ARM64.  The end point is TP link wifi card with which supports
only legacy interrupts.

If it works on other arches and the arm64 PCI enumeration works, my
first guess would be an INTx issue, e.g., maybe the driver is waiting
for an interrupt that never arrives.

We are not sure for now.

We are trying to test it on ARM64 with
(drivers/pci/host/pcie-xilinx-nwl.c) as root port.

EP is getting enumerated and able to link up.

But when we start scan system gets hanged.

When you say the system hangs when you start a scan, I assume you mean
a wifi scan, not the PCI enumeration.  A problem with a wifi scan
might cause a *process* to hang, but it shouldn't hang the entire
system.


Yes wifi scan.

When we took trace we see that after we start scan assert message is
sent but there is no de assert from end point.

Are you talking about a trace from a PCIe analyzer?  Do you see an
Assert_INTx PCIe message on the link?


Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening when we 
do interface link up.
When we have less debug prints in Atheros driver, and do wifi scan we see 
Assert_INTx but never Deassert_INTx,

What might cause end point not sending de assert ?

If the endpoint doesn't send a Deassert_INTx message, I expect that
would mean the driver didn't service the interrupt and remove the
condition that caused the device to assert the interrupt in the first
place.

If the driver didn't receive the interrupt, it couldn't service it, of
course.  You could add a printk in the ath9k interrupt service
routine to see if you ever get there.


The interrupt behavior is changing w.r.t amount of debug prints we add. (I kept 
many prints to aid debug)
root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
[   83.064675] ath9k: ath9k_iowrite32 ff800a400024
[   83.069486] ath9k: ath9k_ioread32 ff800a400024
[   83.074257] ath9k_hw_kill_interrupts  793
[   83.078260] ath9k: ath9k_iowrite32 ff800a400024
[   83.083107] ath9k: ath9k_ioread32 ff800a400024
[   83.087882] ath9k_hw_kill_interrupts  793
[   83.095450] ath9k_hw_enable_interrupts821
[   83.099557] ath9k_hw_enable_interrupts825
[   83.103721] ath9k_hw_enable_interrupts832
[   83.107887] ath9k: ath9k_iowrite32 ff800a400024
[   83.112748] AR_SREV_9100 0
[   83.115438] ath9k_hw_enable_interrupts848
[   83.119607] ath9k: ath9k_ioread32 ff800a400024
[   83.124389] ath9k_hw_intrpend 762
[   83.127761] (AR_SREV_9340(ah) val 0
[   83.131234] ath9k_hw_intrpend 767
[   83.134628] ath_isr   603
[   83.137134] ath9k: ath9k_iowrite32 ff800a400024
[   83.141995] ath9k: ath9k_ioread32 ff800a400024
[   83.146771] ath9k_hw_kill_interrupts  793
[   83.150864] ath9k_hw_enable_interrupts821
[   83.154971] ath9k_hw_enable_interrupts825
[   83.159135] ath9k_hw_enable_interrupts832
[   83.163300] ath9k: ath9k_iowrite32 ff800a400024
[   83.168161] AR_SREV_9100 0
[   83.170852] ath9k_hw_enable_interrupts848
[   83.170855] ath9k_hw_intrpend 762
[   83.178398] (AR_SREV_9340(ah) val 0
[   83.181873] ath9k_hw_intrpend 767
[   83.185265] ath_isr   603
[   83.187773] ath9k: ath9k_iowrite32 ff800a400024
[   83.192635] ath9k: ath9k_ioread32 ff800a400024
[   83.197411] ath9k_hw_kill_interrupts  793
[   83.201414] ath9k: ath9k_ioread32 ff800a400024
[   83.206258] ath9k_hw_enable_interrupts821
[   83.210368] ath9k_hw_enable_interrupts825
[   83.214531] ath9k_hw_enable_interrupts832
[   83.218698] ath9k: ath9k_iowrite32 ff800a400024
[   83.223558] AR_SREV_9100 0
[   83.226243] ath9k_hw_enable_interrupts848
[   83.226246] ath9k_hw_intrpend 762
[   83.233794] (AR_SREV_9340(ah) val 0
[   83.237268] ath9k_hw_intrpend 767
[   83.240661] ath_isr   603
[   83.243169] ath9k: ath9k_iowrite32 ff800a400024
[   83.248030] ath9k: ath9k_ioread32 ff800a400024
[   83.252806] ath9k_hw_kill_interrupts  793
[   83.256811] ath9k: ath9k_ioread32 ff800a400024
[   83.261651] ath9k_hw_enable_interrupts821
[   83.265753] ath9k_hw_enable_interrupts825
[   83.269919] ath9k_hw_enable_interrupts832
[   83.274083] ath9k: ath9k_iowrite32 ff800a400024
[   83.278945] AR_SREV_9100 0
[   83.281630] ath9k_hw_enable_interrupts848
[   83.281633] ath9k_hw_intrpend 762
[   83.281634] 

Re: 4.9.0-rc6+ boot problem

[Tobias Klausmann]

Hello,

I can confirm certain wireless networks cause hangs (stalls - mostly 
swapper/n). This only happens with one network here, others are fine. I 
tried to bisect it but never came to an presentable result.


Greetings,

Tobias


On 01.12.2016 17:10, Radim Krčmář wrote:

2016-11-30 14:20-0800, Kui Zhang:

this result seem to result same panic
+CONFIG_CFG80211=y

I still can't reproduce, sorry, and the attached panic is yet another
thing ... you mentioned that it regressed between v4.9-rc5 and v4.9-rc7;
please run git bisect on it.

Re: 4.9.0-rc6+ boot problem

[Tobias Klausmann]

Hello,

I can confirm certain wireless networks cause hangs (stalls - mostly 
swapper/n). This only happens with one network here, others are fine. I 
tried to bisect it but never came to an presentable result.


Greetings,

Tobias


On 01.12.2016 17:10, Radim Krčmář wrote:

2016-11-30 14:20-0800, Kui Zhang:

this result seem to result same panic
+CONFIG_CFG80211=y

I still can't reproduce, sorry, and the attached panic is yet another
thing ... you mentioned that it regressed between v4.9-rc5 and v4.9-rc7;
please run git bisect on it.

Re: Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

[Tobias Klausmann]

On 05.11.2016 23:38, Gabriel C wrote:

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C


Hi,
i'm witnessing stalls as well (with different stack traces though: [1], 
[2], [3], [4]). Silly enough this seems to happen _only_ at my 
university with wifi enabled (works fine with older kernels: tested 
4.8.4 and older ones as they were recent).


Best Regards,
Tobias Klausmann

[1]: https://homepages.thm.de/~tjkl80/dmesg4.txt
[2]: https://homepages.thm.de/~tjkl80/dmesg3.txt
[3]: https://homepages.thm.de/~tjkl80/dmesg2.txt
[4]: https://homepages.thm.de/~tjkl80/dmesg.txt

Re: Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

[Tobias Klausmann]

On 05.11.2016 23:38, Gabriel C wrote:

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C


Hi,
i'm witnessing stalls as well (with different stack traces though: [1], 
[2], [3], [4]). Silly enough this seems to happen _only_ at my 
university with wifi enabled (works fine with older kernels: tested 
4.8.4 and older ones as they were recent).


Best Regards,
Tobias Klausmann

[1]: https://homepages.thm.de/~tjkl80/dmesg4.txt
[2]: https://homepages.thm.de/~tjkl80/dmesg3.txt
[3]: https://homepages.thm.de/~tjkl80/dmesg2.txt
[4]: https://homepages.thm.de/~tjkl80/dmesg.txt

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 26.11.2014 21:29, Michael Marineau wrote:

On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst
 wrote:

Hey,

Op 22-11-14 om 21:16 schreef Michael Marineau:

On Nov 22, 2014 11:45 AM, "Michael Marineau"  wrote:

On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" <

maarten.lankho...@canonical.com> wrote:

Hey,

Op 22-11-14 om 01:19 schreef Michael Marineau:

On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
 wrote:

Op 20-11-14 om 05:06 schreef Michael Marineau:

On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
 wrote:

Hey,

On 19-11-14 07:43, Michael Marineau wrote:

On 3.18-rc kernel's I have been intermittently experiencing GPU
lockups shortly after startup, accompanied with one or both of the
following errors:

nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
nouveau E[ DRM] GPU lockup - switching to software fbcon

I was able to trace the issue with bisect to commit
809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
fences for readable objects". The lockups appear to have cleared

up

since reverting that and a few related followup commits:

809e9447: "drm/nouveau: use shared fences for readable objects"
055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
e3be4c23: "drm/nouveau: specify if interruptible wait is desired

in

nouveau_fence_sync"
15a996bb: "drm/nouveau: assign fence_chan->name correctly"

Weird. I'm not sure yet what causes it.



http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2

Building a kernel from that commit gives me an entirely new

behavior:

X hangs for at least 10-20 seconds at a time with brief moments of
responsiveness before hanging again while gitk on the kernel repo
loads. Otherwise the system is responsive. The head of that
fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared
fences for readable objects" commit I originally bisected to does
feature the complete lockups I was seeing before.

Ok for the sake of argument lets just assume they're separate bugs,

and we should look at xorg

hanging first.

Is there anything in the dmesg when the hanging happens?

And it's probably 15 seconds, if it's called through

nouveau_fence_wait.

Try changing else if (!ret) to else if (WARN_ON(!ret)) in that

function, and see if you get some dmesg spam. :)

Adding the WARN_ON to 86be4f21 repots the following:

[ 1188.676073] [ cut here ]
[ 1188.676161] WARNING: CPU: 1 PID: 474 at
drivers/gpu/drm/nouveau/nouveau_fence.c:359
nouveau_fence_wait.part.9+0x33/0x40 [nouveau]()
[ 1188.676166] Modules linked in: rndis_host cdc_ether usbnet mii bnep
ecb btusb bluetooth rfkill bridge stp llc hid_generic usb_storage
joydev mousedev hid_apple usbhid bcm5974 nls_iso8859_1 nls_cp437 vfat
fat nouveau snd_hda_codec_hdmi coretemp x86_pkg_temp_thermal
intel_powerclamp kvm_intel kvm iTCO_wdt crct10dif_pclmul
iTCO_vendor_support crc32c_intel evdev aesni_intel mac_hid aes_x86_64
lrw glue_helper ablk_helper applesmc snd_hda_codec_cirrus cryptd
input_polldev snd_hda_codec_generic mxm_wmi led_class wmi microcode
hwmon snd_hda_intel ttm snd_hda_controller lpc_ich i2c_i801 mfd_core
snd_hda_codec i2c_algo_bit snd_hwdep drm_kms_helper snd_pcm sbs drm
apple_gmux i2ccore snd_timer snd agpgart mei_me soundcore sbshc mei
video xhci_hcd usbcore usb_common apple_bl button battery ac efivars
autofs4
[ 1188.676300]  efivarfs
[ 1188.676308] CPU: 1 PID: 474 Comm: Xorg Tainted: GW
3.17.0-rc2-nvtest+ #147
[ 1188.676313] Hardware name: Apple Inc.
MacBookPro11,3/Mac-2BD1B31983FE1663, BIOS
MBP112.88Z.0138.B11.1408291503 08/29/2014
[ 1188.676316]  0009 88045daebce8 814f0c09

[ 1188.676325]  88045daebd20 8104ea5d 88006a6c1468
fff0
[ 1188.676333]    88006a6c1000
88045daebd30
[ 1188.676341] Call Trace:
[ 1188.676356]  [] dump_stack+0x4d/0x66
[ 1188.676369]  [] warn_slowpath_common+0x7d/0xa0
[ 1188.676377]  [] warn_slowpath_null+0x1a/0x20
[ 1188.676439]  []
nouveau_fence_wait.part.9+0x33/0x40 [nouveau]
[ 1188.676496]  [] nouveau_fence_wait+0x16/0x30

[nouveau]

[ 1188.676552]  []
nouveau_gem_ioctl_cpu_prep+0xef/0x1f0 [nouveau]
[ 1188.676578]  [] drm_ioctl+0x1ec/0x660 [drm]
[ 1188.676590]  [] ?

_raw_spin_unlock_irqrestore+0x36/0x70

[ 1188.676600]  [] ? trace_hardirqs_on+0xd/0x10
[ 1188.676655]  [] nouveau_drm_ioctl+0x54/0xc0

[nouveau]

[ 1188.676663]  [] do_vfs_ioctl+0x300/0x520
[ 1188.676671]  [] ? sysret_check+0x22/0x5d
[ 1188.676677]  [] SyS_ioctl+0x41/0x80
[ 1188.676683]  [] system_call_fastpath+0x16/0x1b
[ 1188.676688] ---[ end trace 6f7a510865b4674f ]---

Here are the fence events that fired during that particular

fence_wait:

 Xorg   474 [004]  1173.667645: fence:fence_wait_start:
driver=nouveau timeline=Xorg[474] context=2 seqno=56910
 Xorg   474 [004]  1173.667647: 

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 26.11.2014 21:29, Michael Marineau wrote:

On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:

Hey,

Op 22-11-14 om 21:16 schreef Michael Marineau:

On Nov 22, 2014 11:45 AM, Michael Marineau m...@marineau.org wrote:

On Nov 22, 2014 8:56 AM, Maarten Lankhorst 

maarten.lankho...@canonical.com wrote:

Hey,

Op 22-11-14 om 01:19 schreef Michael Marineau:

On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:

Op 20-11-14 om 05:06 schreef Michael Marineau:

On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:

Hey,

On 19-11-14 07:43, Michael Marineau wrote:

On 3.18-rc kernel's I have been intermittently experiencing GPU
lockups shortly after startup, accompanied with one or both of the
following errors:

nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
nouveau E[ DRM] GPU lockup - switching to software fbcon

I was able to trace the issue with bisect to commit
809e9447b92ffe1346b2d6ec390e212d5307f61c drm/nouveau: use shared
fences for readable objects. The lockups appear to have cleared

up

since reverting that and a few related followup commits:

809e9447: drm/nouveau: use shared fences for readable objects
055dffdf: drm/nouveau: bump driver patchlevel to 1.2.1
e3be4c23: drm/nouveau: specify if interruptible wait is desired

in

nouveau_fence_sync
15a996bb: drm/nouveau: assign fence_chan-name correctly

Weird. I'm not sure yet what causes it.



http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisectid=86be4f216bbb9ea3339843a5658d4c21162c7ee2

Building a kernel from that commit gives me an entirely new

behavior:

X hangs for at least 10-20 seconds at a time with brief moments of
responsiveness before hanging again while gitk on the kernel repo
loads. Otherwise the system is responsive. The head of that
fixed-fences-for-bisect branch (1c6aafb5) which is the use shared
fences for readable objects commit I originally bisected to does
feature the complete lockups I was seeing before.

Ok for the sake of argument lets just assume they're separate bugs,

and we should look at xorg

hanging first.

Is there anything in the dmesg when the hanging happens?

And it's probably 15 seconds, if it's called through

nouveau_fence_wait.

Try changing else if (!ret) to else if (WARN_ON(!ret)) in that

function, and see if you get some dmesg spam. :)

Adding the WARN_ON to 86be4f21 repots the following:

[ 1188.676073] [ cut here ]
[ 1188.676161] WARNING: CPU: 1 PID: 474 at
drivers/gpu/drm/nouveau/nouveau_fence.c:359
nouveau_fence_wait.part.9+0x33/0x40 [nouveau]()
[ 1188.676166] Modules linked in: rndis_host cdc_ether usbnet mii bnep
ecb btusb bluetooth rfkill bridge stp llc hid_generic usb_storage
joydev mousedev hid_apple usbhid bcm5974 nls_iso8859_1 nls_cp437 vfat
fat nouveau snd_hda_codec_hdmi coretemp x86_pkg_temp_thermal
intel_powerclamp kvm_intel kvm iTCO_wdt crct10dif_pclmul
iTCO_vendor_support crc32c_intel evdev aesni_intel mac_hid aes_x86_64
lrw glue_helper ablk_helper applesmc snd_hda_codec_cirrus cryptd
input_polldev snd_hda_codec_generic mxm_wmi led_class wmi microcode
hwmon snd_hda_intel ttm snd_hda_controller lpc_ich i2c_i801 mfd_core
snd_hda_codec i2c_algo_bit snd_hwdep drm_kms_helper snd_pcm sbs drm
apple_gmux i2ccore snd_timer snd agpgart mei_me soundcore sbshc mei
video xhci_hcd usbcore usb_common apple_bl button battery ac efivars
autofs4
[ 1188.676300]  efivarfs
[ 1188.676308] CPU: 1 PID: 474 Comm: Xorg Tainted: GW
3.17.0-rc2-nvtest+ #147
[ 1188.676313] Hardware name: Apple Inc.
MacBookPro11,3/Mac-2BD1B31983FE1663, BIOS
MBP112.88Z.0138.B11.1408291503 08/29/2014
[ 1188.676316]  0009 88045daebce8 814f0c09

[ 1188.676325]  88045daebd20 8104ea5d 88006a6c1468
fff0
[ 1188.676333]    88006a6c1000
88045daebd30
[ 1188.676341] Call Trace:
[ 1188.676356]  [814f0c09] dump_stack+0x4d/0x66
[ 1188.676369]  [8104ea5d] warn_slowpath_common+0x7d/0xa0
[ 1188.676377]  [8104eb3a] warn_slowpath_null+0x1a/0x20
[ 1188.676439]  [c04dd523]
nouveau_fence_wait.part.9+0x33/0x40 [nouveau]
[ 1188.676496]  [c04ddfe6] nouveau_fence_wait+0x16/0x30

[nouveau]

[ 1188.676552]  [c04e598f]
nouveau_gem_ioctl_cpu_prep+0xef/0x1f0 [nouveau]
[ 1188.676578]  [c01c2f4c] drm_ioctl+0x1ec/0x660 [drm]
[ 1188.676590]  [814f9026] ?

_raw_spin_unlock_irqrestore+0x36/0x70

[ 1188.676600]  [81094f6d] ? trace_hardirqs_on+0xd/0x10
[ 1188.676655]  [c04da5b4] nouveau_drm_ioctl+0x54/0xc0

[nouveau]

[ 1188.676663]  [811a8950] do_vfs_ioctl+0x300/0x520
[ 1188.676671]  [814f9e55] ? sysret_check+0x22/0x5d
[ 1188.676677]  [811a8bb1] SyS_ioctl+0x41/0x80
[ 1188.676683]  [814f9e29] 

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:

...
On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx->base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);

...


Added the above on top of your "fixed-fences-for-bisect" branch and 
guessed it would work, but did not :/
Anyway, as this "initializes" the fence to a known state, maybe you 
should consider pushing that.


Going to compile the kernel with trace events (lets see how) ...

Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:

Hey,

On 19-11-14 07:43, Michael Marineau wrote:

On 3.18-rc kernel's I have been intermittently experiencing GPU
lockups shortly after startup, accompanied with one or both of the
following errors:

nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
nouveau E[ DRM] GPU lockup - switching to software fbcon

I was able to trace the issue with bisect to commit
809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
fences for readable objects". The lockups appear to have cleared up
since reverting that and a few related followup commits:

809e9447: "drm/nouveau: use shared fences for readable objects"
055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
nouveau_fence_sync"
15a996bb: "drm/nouveau: assign fence_chan->name correctly"

Weird. I'm not sure yet what causes it.

http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2

On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx->base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);

If that fails you should compile your kernel with trace events, to get some 
debugging info from the fences. I'll post debugging info if this does not fix 
it.

~Maarten


Hey,
as mentioned in IRC the new fencing hangs my GPU for a while as well (nve7).
Bisected back to  86be4f216bbb9ea3339843a5658d4c21162c7ee2
, EDITED

from the fixed-fences-for-bisect branch mentioned above.

Original bisect on linus brach brought me to:
29ba89b2371d466ca68973525816cf10debc2655
drm/nouveau: rework to new fence interface

Michael if you are going to bisect the "fixed-fences-for-bisect" branch, 
maybe take a closer look if you come anywhere near that commit, if that 
does or does not trigger the GPU hangs for you!


Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:

Hey,

On 19-11-14 07:43, Michael Marineau wrote:

On 3.18-rc kernel's I have been intermittently experiencing GPU
lockups shortly after startup, accompanied with one or both of the
following errors:

nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
nouveau E[ DRM] GPU lockup - switching to software fbcon

I was able to trace the issue with bisect to commit
809e9447b92ffe1346b2d6ec390e212d5307f61c drm/nouveau: use shared
fences for readable objects. The lockups appear to have cleared up
since reverting that and a few related followup commits:

809e9447: drm/nouveau: use shared fences for readable objects
055dffdf: drm/nouveau: bump driver patchlevel to 1.2.1
e3be4c23: drm/nouveau: specify if interruptible wait is desired in
nouveau_fence_sync
15a996bb: drm/nouveau: assign fence_chan-name correctly

Weird. I'm not sure yet what causes it.

http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisectid=86be4f216bbb9ea3339843a5658d4c21162c7ee2

On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx-base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv-bo, chan-chid * 16/4, 0x);

If that fails you should compile your kernel with trace events, to get some 
debugging info from the fences. I'll post debugging info if this does not fix 
it.

~Maarten


Hey,
as mentioned in IRC the new fencing hangs my GPU for a while as well (nve7).
Bisected back to  86be4f216bbb9ea3339843a5658d4c21162c7ee2
, EDITED

from the fixed-fences-for-bisect branch mentioned above.

Original bisect on linus brach brought me to:
29ba89b2371d466ca68973525816cf10debc2655
drm/nouveau: rework to new fence interface

Michael if you are going to bisect the fixed-fences-for-bisect branch, 
maybe take a closer look if you come anywhere near that commit, if that 
does or does not trigger the GPU hangs for you!


Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:

...
On the EDITED patch from fixed-fences-for-bisect, can you do the following:

In nouveau/nv84_fence.c function nv84_fence_context_new, remove

fctx-base.sequence = nv84_fence_read(chan);

and add back

nouveau_bo_wr32(priv-bo, chan-chid * 16/4, 0x);

...


Added the above on top of your fixed-fences-for-bisect branch and 
guessed it would work, but did not :/
Anyway, as this initializes the fence to a known state, maybe you 
should consider pushing that.


Going to compile the kernel with trace events (lets see how) ...

Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] x86: reboot doesn't reboot

[Tobias Klausmann]

On 04.04.2014 17:45, Matthew Garrett wrote:

On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:

On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett  wrote:

Production hardware should never require CF9.

That's total BS.

The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems. A huge swath of Dell machines in particular for some
reason (laptops, desktops, _and_ now there's tablet reports).

Which is almost certainly because the other reboot methods are trapping
into SMI and hitting some hardware that we've left in a different state
to Windows. CF9 may work around that, but the actual fix is to figure
out why the firmware is wedging and fix it. Otherwise we're going to
spend the rest of our lives maintaining a giant DMI list that's still
going to be missing entries and users are going to be sad.


The keyboard controller is sadly unreliable too, although I really
don't understand why. Even when a legacy keyboard controller exists
(which isn't as universal as you'd think, even though the *hardware*
is pretty much guaranteed to be there in the chipset, it can be
disabled) there seem to be machines where the reset line isn't hooked
up. Don't ask me why. Same goes for the triple fault failure case.

See: SMI. Or in the triple fault case, because there's some early init
code that has the same issue. As far as I can tell Windows never triple
faults, so again I think this is our fault at some level.


It would be interesting if somebody can figure out *exactly* what
Windows does, because the fact that a lot of Dell machines need quirks
almost certainly means that it's _us_ doing something wrong. Dell
doesn't generally do lots of fancy odd things. I pretty much guarantee
it's because we've done something odd that Windows doesn't do.

Windows hits the keyboard controller and then tries the ACPI vector. It
then sleeps for a short period, then tries the keyboard controller again
and the ACPI vector again. This means that systems which put cf9 in the
ACPI vector tend to work because of the second write, which is obviously
not what the spec envisaged but here we are. The only time it hits CF9
is when the ACPI tables tell it to.



Hi,
sorry to  get into the discussion at this random point, not at the 
starting point, but with the latest Linus Tree my system needs several 
minutes to reboot instead of some seconds, so this may be related. If I 
can help in any way, let me konw!


Thanks,
Tobias Klausmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] x86: reboot doesn't reboot

[Tobias Klausmann]

On 04.04.2014 17:45, Matthew Garrett wrote:

On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:

On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett mj...@srcf.ucam.org wrote:

Production hardware should never require CF9.

That's total BS.

The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems. A huge swath of Dell machines in particular for some
reason (laptops, desktops, _and_ now there's tablet reports).

Which is almost certainly because the other reboot methods are trapping
into SMI and hitting some hardware that we've left in a different state
to Windows. CF9 may work around that, but the actual fix is to figure
out why the firmware is wedging and fix it. Otherwise we're going to
spend the rest of our lives maintaining a giant DMI list that's still
going to be missing entries and users are going to be sad.


The keyboard controller is sadly unreliable too, although I really
don't understand why. Even when a legacy keyboard controller exists
(which isn't as universal as you'd think, even though the *hardware*
is pretty much guaranteed to be there in the chipset, it can be
disabled) there seem to be machines where the reset line isn't hooked
up. Don't ask me why. Same goes for the triple fault failure case.

See: SMI. Or in the triple fault case, because there's some early init
code that has the same issue. As far as I can tell Windows never triple
faults, so again I think this is our fault at some level.


It would be interesting if somebody can figure out *exactly* what
Windows does, because the fact that a lot of Dell machines need quirks
almost certainly means that it's _us_ doing something wrong. Dell
doesn't generally do lots of fancy odd things. I pretty much guarantee
it's because we've done something odd that Windows doesn't do.

Windows hits the keyboard controller and then tries the ACPI vector. It
then sleeps for a short period, then tries the keyboard controller again
and the ACPI vector again. This means that systems which put cf9 in the
ACPI vector tend to work because of the second write, which is obviously
not what the spec envisaged but here we are. The only time it hits CF9
is when the ACPI tables tell it to.



Hi,
sorry to  get into the discussion at this random point, not at the 
starting point, but with the latest Linus Tree my system needs several 
minutes to reboot instead of some seconds, so this may be related. If I 
can help in any way, let me konw!


Thanks,
Tobias Klausmann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

On 09.09.2013 00:29, Dave Airlie wrote:

On Mon, Sep 9, 2013 at 8:01 AM, Tobias Klausmann
 wrote:

On 08.09.2013 23:33, Dave Airlie wrote:

Looks like you have Optimus (intel + nvidia), and the backtrace has
runtime pm in it, which is something new Dave added for 3.12, adding
him in explicitly. The simplest explanation is that disp->init is
NULL. And it seems like there are no outputs from the earlier nouveau
init prints. I guess that the call to nouveau_display_resume from
nouveau_pmops_runtime_resume should be guarded by a if
(dev->mode_config.num_crtc) like it is everywhere else.

-ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Does it look like this one?

Dave.

No, mine was quick and dirty, reverted it and took yours. But i'm a little
bit confused that this is a suspend/resume problem, i booted the kernel for
the first time while seeing the oops. But anyway i tested it and it works.

It's runtime suspend/resume - so it turns the nvidia gpu off at boot since it
isn't being used.

you should see longer battery life.
Dave.

Ah thanks for the explanation.
Can we see the state in /sys somewhere? I looked around but did not find 
something to determine the state?
/sys/bus/pci/drivers/nouveau/:01:00.0/drm/card0/power/runtime_status 
gives me "unsupported".
But i suspect thats because of nouveaus lack to properly reclock my 
nvidia gpu. Anyway i'm better of asking you for the right anyswer.

Thanks for your time,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

On 08.09.2013 23:33, Dave Airlie wrote:

Looks like you have Optimus (intel + nvidia), and the backtrace has
runtime pm in it, which is something new Dave added for 3.12, adding
him in explicitly. The simplest explanation is that disp->init is
NULL. And it seems like there are no outputs from the earlier nouveau
init prints. I guess that the call to nouveau_display_resume from
nouveau_pmops_runtime_resume should be guarded by a if
(dev->mode_config.num_crtc) like it is everywhere else.

   -ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Does it look like this one?

Dave.
No, mine was quick and dirty, reverted it and took yours. But i'm a 
little bit confused that this is a suspend/resume problem, i booted the 
kernel for the first time while seeing the oops. But anyway i tested it 
and it works.


Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Bail in nouveau_display_resume() if there are no output available!

[Tobias Klausmann]

---
 drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d2712e6..a4ba734 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -452,7 +452,12 @@ void
 nouveau_display_resume(struct drm_device *dev)
 {
struct drm_crtc *crtc;
-   nouveau_display_init(dev);
+   int ret;
+   if (dev->mode_config.num_crtc) {
+   ret = nouveau_display_init(dev);
+   if (ret)
+   nouveau_display_destroy(dev);
+   }
 
/* Force CLUT to get re-loaded during modeset */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

> Looks like you have Optimus (intel + nvidia), and the backtrace has
> runtime pm in it, which is something new Dave added for 3.12, adding
> him in explicitly. The simplest explanation is that disp->init is
> NULL. And it seems like there are no outputs from the earlier nouveau
> init prints. I guess that the call to nouveau_display_resume from
> nouveau_pmops_runtime_resume should be guarded by a if
> (dev->mode_config.num_crtc) like it is everywhere else.
> 
>   -ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Thanks,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

 Looks like you have Optimus (intel + nvidia), and the backtrace has
 runtime pm in it, which is something new Dave added for 3.12, adding
 him in explicitly. The simplest explanation is that disp-init is
 NULL. And it seems like there are no outputs from the earlier nouveau
 init prints. I guess that the call to nouveau_display_resume from
 nouveau_pmops_runtime_resume should be guarded by a if
 (dev-mode_config.num_crtc) like it is everywhere else.
 
   -ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Thanks,
Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Bail in nouveau_display_resume() if there are no output available!

[Tobias Klausmann]

---
 drivers/gpu/drm/nouveau/nouveau_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d2712e6..a4ba734 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -452,7 +452,12 @@ void
 nouveau_display_resume(struct drm_device *dev)
 {
struct drm_crtc *crtc;
-   nouveau_display_init(dev);
+   int ret;
+   if (dev-mode_config.num_crtc) {
+   ret = nouveau_display_init(dev);
+   if (ret)
+   nouveau_display_destroy(dev);
+   }
 
/* Force CLUT to get re-loaded during modeset */
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

On 08.09.2013 23:33, Dave Airlie wrote:

Looks like you have Optimus (intel + nvidia), and the backtrace has
runtime pm in it, which is something new Dave added for 3.12, adding
him in explicitly. The simplest explanation is that disp-init is
NULL. And it seems like there are no outputs from the earlier nouveau
init prints. I guess that the call to nouveau_display_resume from
nouveau_pmops_runtime_resume should be guarded by a if
(dev-mode_config.num_crtc) like it is everywhere else.

   -ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Does it look like this one?

Dave.
No, mine was quick and dirty, reverted it and took yours. But i'm a 
little bit confused that this is a suspend/resume problem, i booted the 
kernel for the first time while seeing the oops. But anyway i tested it 
and it works.


Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] 3.12rc1-pre Nouveau? oops

[Tobias Klausmann]

On 09.09.2013 00:29, Dave Airlie wrote:

On Mon, Sep 9, 2013 at 8:01 AM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:

On 08.09.2013 23:33, Dave Airlie wrote:

Looks like you have Optimus (intel + nvidia), and the backtrace has
runtime pm in it, which is something new Dave added for 3.12, adding
him in explicitly. The simplest explanation is that disp-init is
NULL. And it seems like there are no outputs from the earlier nouveau
init prints. I guess that the call to nouveau_display_resume from
nouveau_pmops_runtime_resume should be guarded by a if
(dev-mode_config.num_crtc) like it is everywhere else.

-ilia

Your guess was right, this (hopefully attached patch) fixes it for me!

Does it look like this one?

Dave.

No, mine was quick and dirty, reverted it and took yours. But i'm a little
bit confused that this is a suspend/resume problem, i booted the kernel for
the first time while seeing the oops. But anyway i tested it and it works.

It's runtime suspend/resume - so it turns the nvidia gpu off at boot since it
isn't being used.

you should see longer battery life.
Dave.

Ah thanks for the explanation.
Can we see the state in /sys somewhere? I looked around but did not find 
something to determine the state?
/sys/bus/pci/drivers/nouveau/:01:00.0/drm/card0/power/runtime_status 
gives me unsupported.
But i suspect thats because of nouveaus lack to properly reclock my 
nvidia gpu. Anyway i'm better of asking you for the right anyswer.

Thanks for your time,
Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I915 DRI_PRIME Bug Resend

[Tobias Klausmann]

Hello there,
while testing my "Optimus" Notebook i saw a stack trace in my logs, 
maybe someone is interested!
I can easily reproduce this any time. It happens when offloading a GL 
app, here Unigine Heaven 3.0 to the nvidia card. To be more exactly: 
When starting Unigine the window stays black. To get something useful i 
have to minimize and maximize the window. Exactly when maximizing the 
window the trace happens.


Hope this helps anyway!

[ cut here ]
WARNING: CPU: 7 PID: 718 at drivers/gpu/drm/i915/i915_gem.c:3967 
i915_gem_free_object+0x124/0x150 [i915]()
Modules linked in: af_packet bnep fuse snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath3k btusb bluetooth 
uvcvideo snd_hwdep videobuf2_core videodev videobuf2_vmalloc 
videobuf2_memops snd_pcm snd_seq snd_timer arc4 ath9k snd_seq_device 
mac80211 ath9k_common ath9k_hw ath snd iTCO_wdt sdhci_pci sdhci mmc_core 
sr_mod sg tg3 ptp pps_core iTCO_vendor_support cfg80211 lpc_ich i2c_i801 
pcspkr joydev acer_wmi sparse_keymap rfkill cdrom soundcore 
snd_page_alloc mperf battery ac autofs4 i915 xhci_hcd processor 
scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh nouveau ttm 
drm_kms_helper drm i2c_algo_bit mxm_wmi video thermal_sys wmi button

CPU: 7 PID: 718 Comm: Xorg Not tainted 3.11.0-rc5-desktop+ #27
Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V1.13 10/09/2012
  0009 81568703 
 81047f81 88021cf1ab00 88024f1d 88025e421930
 88021c7bcd40 8802540f2da0 a0210a44 88021cf1ab00
Call Trace:
 [] ? dump_stack+0x50/0x80
 [] ? warn_slowpath_common+0x81/0xb0
 [] ? i915_gem_free_object+0x124/0x150 [i915]
 [] ? i915_gem_dmabuf_release+0x80/0x90 [i915]
 [] ? dma_buf_release+0x23/0x80
 [] ? __fput+0xcd/0x230
 [] ? task_work_run+0x97/0xd0
 [] ? do_notify_resume+0x79/0xa0
 [] ? int_signal+0x12/0x17
---[ end trace 99a0c147e69ddcd1 ]---

Thanks,
Tobias Klausmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I915 DRI_PRIME Bug Resend

[Tobias Klausmann]

Hello there,
while testing my Optimus Notebook i saw a stack trace in my logs, 
maybe someone is interested!
I can easily reproduce this any time. It happens when offloading a GL 
app, here Unigine Heaven 3.0 to the nvidia card. To be more exactly: 
When starting Unigine the window stays black. To get something useful i 
have to minimize and maximize the window. Exactly when maximizing the 
window the trace happens.


Hope this helps anyway!

[ cut here ]
WARNING: CPU: 7 PID: 718 at drivers/gpu/drm/i915/i915_gem.c:3967 
i915_gem_free_object+0x124/0x150 [i915]()
Modules linked in: af_packet bnep fuse snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath3k btusb bluetooth 
uvcvideo snd_hwdep videobuf2_core videodev videobuf2_vmalloc 
videobuf2_memops snd_pcm snd_seq snd_timer arc4 ath9k snd_seq_device 
mac80211 ath9k_common ath9k_hw ath snd iTCO_wdt sdhci_pci sdhci mmc_core 
sr_mod sg tg3 ptp pps_core iTCO_vendor_support cfg80211 lpc_ich i2c_i801 
pcspkr joydev acer_wmi sparse_keymap rfkill cdrom soundcore 
snd_page_alloc mperf battery ac autofs4 i915 xhci_hcd processor 
scsi_dh_alua scsi_dh_hp_sw scsi_dh_emc scsi_dh_rdac scsi_dh nouveau ttm 
drm_kms_helper drm i2c_algo_bit mxm_wmi video thermal_sys wmi button

CPU: 7 PID: 718 Comm: Xorg Not tainted 3.11.0-rc5-desktop+ #27
Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V1.13 10/09/2012
  0009 81568703 
 81047f81 88021cf1ab00 88024f1d 88025e421930
 88021c7bcd40 8802540f2da0 a0210a44 88021cf1ab00
Call Trace:
 [81568703] ? dump_stack+0x50/0x80
 [81047f81] ? warn_slowpath_common+0x81/0xb0
 [a0210a44] ? i915_gem_free_object+0x124/0x150 [i915]
 [a02574d0] ? i915_gem_dmabuf_release+0x80/0x90 [i915]
 [813761c3] ? dma_buf_release+0x23/0x80
 [8113e4dd] ? __fput+0xcd/0x230
 [81063167] ? task_work_run+0x97/0xd0
 [81002ab9] ? do_notify_resume+0x79/0xa0
 [8156f92a] ? int_signal+0x12/0x17
---[ end trace 99a0c147e69ddcd1 ]---

Thanks,
Tobias Klausmann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 22.07.2013 15:08, Rafael J. Wysocki wrote:

On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote:

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...

   (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.


This pach finally fixes my backlight control!

Yes, it fixes that for a number of people, which is the reason why I send
the pull request in the first place, but it also turns out to break things
for some people and therefore it'll have to be reverted.

We're still going to work on that, though.

Thanks,
Rafael


If you have new patches ready for this and you want them to be tested, 
let me know!


Thanks,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 22.07.2013 15:08, Rafael J. Wysocki wrote:

On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote:

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...

   (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.


This pach finally fixes my backlight control!

Yes, it fixes that for a number of people, which is the reason why I send
the pull request in the first place, but it also turns out to break things
for some people and therefore it'll have to be reverted.

We're still going to work on that, though.

Thanks,
Rafael


If you have new patches ready for this and you want them to be tested, 
let me know!


Thanks,
Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...


  (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.



This pach finally fixes my backlight control!

Thanks!
Tobias Klausmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...


  (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.



This pach finally fixes my backlight control!

Thanks!
Tobias Klausmann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On a whim, I tried fiddling with ALPHA_LEGACY_START_ADDRESS.
While this necessitates switching the system type  to
GENERIC_ALPHA, it makes the whole thing work. I suspect the
change in segment size shifted stuff around enough to make the
DP264 layout a "legacy" one. 

Regards,
Tobias


-- 
Sent from aboard the Culture ship
ROU (Killer-class) Trade Surplus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On a whim, I tried fiddling with ALPHA_LEGACY_START_ADDRESS.
While this necessitates switching the system type  to
GENERIC_ALPHA, it makes the whole thing work. I suspect the
change in segment size shifted stuff around enough to make the
DP264 layout a legacy one. 

Regards,
Tobias


-- 
Sent from aboard the Culture ship
ROU (Killer-class) Trade Surplus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On Tue, 26 Mar 2013, Michael Cree wrote:

> On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote:
> > On Mon, 25 Mar 2013, Will Deacon wrote:
> >> Any news on these? I've included an updated version of the first  
> >> patch, with
> >> the Tested-by-tag and a tweaked commit message below.
> >
> > As a data point, I tried vanilla 3.8.4 on the weekend. With my
> > usual config on a UP1500, it will fail at build time with
> > relocation errors. If I remove -msmall-data (or replace it with
> > ~big~), the machine hangs hard immediatly after aboot telling me
> > it's starting it.
> 
> You probably want the "alpha: Add irongate_io to to PCI bus resources"  
> patch posted by Matt Turner in the linux-alpha forum.  Looks like it  
> has not been sent to Linus.

Tried that, same effect. Interestingly, rebooting without a full
init cycle crashes differently:

aboot: loading uncompressed vmlinuz-3.8.4...
aboot: loading compressed vmlinuz-3.8.4...  
aboot: PHDR 0 vaddr 0xfc31 offset 0x100 size 0x59e4ac
aboot: bss at 0xfc8ae4ac, size 0x1814dc  
aboot: zero-filling 1578204 bytes at 0xfc8ae4ac
aboot: starting kernel vmlinuz-3.8.4 with arguments root=/dev/md0 console=tty1 
console=ttyS0 rootfstype=ext4

halted CPU 0

halt code = 5
HALT instruction executed
PC = fc8b4e40
IrqVectorSet 60  
Adding Vector ffe0 b
impure halt code 5  
>>>

Without the irongate patch, the same (HALT on soft reboot, hard
crash on full init) happens. 

Any hints on making the whole thing more debuggable are
appreciated.

Regards,
Tobias


-- 
One of the main causes of the fall of the roman empire was that, lacking zero,
they had no way to indicate successful termination of their C programs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On Tue, 26 Mar 2013, Michael Cree wrote:

 On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote:
  On Mon, 25 Mar 2013, Will Deacon wrote:
  Any news on these? I've included an updated version of the first  
  patch, with
  the Tested-by-tag and a tweaked commit message below.
 
  As a data point, I tried vanilla 3.8.4 on the weekend. With my
  usual config on a UP1500, it will fail at build time with
  relocation errors. If I remove -msmall-data (or replace it with
  ~big~), the machine hangs hard immediatly after aboot telling me
  it's starting it.
 
 You probably want the alpha: Add irongate_io to to PCI bus resources  
 patch posted by Matt Turner in the linux-alpha forum.  Looks like it  
 has not been sent to Linus.

Tried that, same effect. Interestingly, rebooting without a full
init cycle crashes differently:

aboot: loading uncompressed vmlinuz-3.8.4...
aboot: loading compressed vmlinuz-3.8.4...  
aboot: PHDR 0 vaddr 0xfc31 offset 0x100 size 0x59e4ac
aboot: bss at 0xfc8ae4ac, size 0x1814dc  
aboot: zero-filling 1578204 bytes at 0xfc8ae4ac
aboot: starting kernel vmlinuz-3.8.4 with arguments root=/dev/md0 console=tty1 
console=ttyS0 rootfstype=ext4

halted CPU 0

halt code = 5
HALT instruction executed
PC = fc8b4e40
IrqVectorSet 60  
Adding Vector ffe0 b
impure halt code 5  


Without the irongate patch, the same (HALT on soft reboot, hard
crash on full init) happens. 

Any hints on making the whole thing more debuggable are
appreciated.

Regards,
Tobias


-- 
One of the main causes of the fall of the roman empire was that, lacking zero,
they had no way to indicate successful termination of their C programs.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On Mon, 25 Mar 2013, Will Deacon wrote:
> Any news on these? I've included an updated version of the first patch, with
> the Tested-by-tag and a tweaked commit message below.

As a data point, I tried vanilla 3.8.4 on the weekend. With my
usual config on a UP1500, it will fail at build time with
relocation errors. If I remove -msmall-data (or replace it with
~big~), the machine hangs hard immediatly after aboot telling me
it's starting it. I'll take a closer look later today, but there
seems to be a very fundamental thing wrong with the startup code
in these scenarios.

Regards,
Tobias

-- 
"Brain, konban wa nani o shimashitai?"
"Your Japanese is terrible, Pinky."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds

[Tobias Klausmann]

Hi! 

On Mon, 25 Mar 2013, Will Deacon wrote:
 Any news on these? I've included an updated version of the first patch, with
 the Tested-by-tag and a tweaked commit message below.

As a data point, I tried vanilla 3.8.4 on the weekend. With my
usual config on a UP1500, it will fail at build time with
relocation errors. If I remove -msmall-data (or replace it with
~big~), the machine hangs hard immediatly after aboot telling me
it's starting it. I'll take a closer look later today, but there
seems to be a very fundamental thing wrong with the startup code
in these scenarios.

Regards,
Tobias

-- 
Brain, konban wa nani o shimashitai?
Your Japanese is terrible, Pinky.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

[Tobias Klausmann]

Hi! 

On Mon, 10 Sep 2012, Frederic Weisbecker wrote:
> > AFAICT, schedule_preempt_disabled() was only introduced in 3.4
> > and thus needs to be backported for 3.3.
> 
> Please try with this instead:
> 
>   preempt_enable_no_resched();
>   schedule();
>   preempt_disable();
> 
> Thanks.

While it does compile, it hits the usual Alpha snag (3.3 onwards)
on boot:

PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x-0x]
pci_bus :00: root bus resource [mem 0x-0x]
pci :00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci :00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
Unable to handle kernel paging request at virtual address 
swapper(1): Oops 1
pc = []  ra = []  ps = Not tainted
pc is at nautilus_init_pci+0xd4/0x218
ra is at nautilus_init_pci+0xac/0x218
v0 = 0001  t0 =   t1 = 
t2 =   t3 = fc896810  t4 = 0100
t5 = 0008  t6 = 0fff  t7 = fc00bf89
s0 = fc00bf8b4800  s1 = 00ff  s2 = 0007fffa
s3 =   s4 =   s5 = 2ab5
s6 = 58000701
a0 = fc896b88  a1 =   a2 = 
a3 = 0e00  a4 = 0200  a5 = 0001
t8 =   t9 =   t10= 0001
t11=   pv = fc32bdc0  at = 0d0e4600
gp = fc8e34a8  sp = fc00bf893e28
Disabling lock debugging due to kernel taint
Trace:
[] do_one_initcall+0x38/0x200
[] kernel_thread+0x28/0x90

This is not an RCU problem, though. AFAICT.

I tried the patches with 3.2.28 (the latest vanilla kernel that
works on this machine _at all_) but those don't have an RCU
implementation and thus, the compile fails:

  CC  arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:59: error: implicit declaration of function 
'rcu_idle_enter'
arch/alpha/kernel/process.c:63: error: implicit declaration of function 
'rcu_idle_exit'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2


Regards,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

[Tobias Klausmann]

Hi! 

On Mon, 10 Sep 2012, Frederic Weisbecker wrote:
  AFAICT, schedule_preempt_disabled() was only introduced in 3.4
  and thus needs to be backported for 3.3.
 
 Please try with this instead:
 
   preempt_enable_no_resched();
   schedule();
   preempt_disable();
 
 Thanks.

While it does compile, it hits the usual Alpha snag (3.3 onwards)
on boot:

PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x-0x]
pci_bus :00: root bus resource [mem 0x-0x]
pci :00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci :00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
Unable to handle kernel paging request at virtual address 
swapper(1): Oops 1
pc = [fc8667bc]  ra = [fc866794]  ps = Not tainted
pc is at nautilus_init_pci+0xd4/0x218
ra is at nautilus_init_pci+0xac/0x218
v0 = 0001  t0 =   t1 = 
t2 =   t3 = fc896810  t4 = 0100
t5 = 0008  t6 = 0fff  t7 = fc00bf89
s0 = fc00bf8b4800  s1 = 00ff  s2 = 0007fffa
s3 =   s4 =   s5 = 2ab5
s6 = 58000701
a0 = fc896b88  a1 =   a2 = 
a3 = 0e00  a4 = 0200  a5 = 0001
t8 =   t9 =   t10= 0001
t11=   pv = fc32bdc0  at = 0d0e4600
gp = fc8e34a8  sp = fc00bf893e28
Disabling lock debugging due to kernel taint
Trace:
[fc310088] do_one_initcall+0x38/0x200
[fc311338] kernel_thread+0x28/0x90

This is not an RCU problem, though. AFAICT.

I tried the patches with 3.2.28 (the latest vanilla kernel that
works on this machine _at all_) but those don't have an RCU
implementation and thus, the compile fails:

  CC  arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:59: error: implicit declaration of function 
'rcu_idle_enter'
arch/alpha/kernel/process.c:63: error: implicit declaration of function 
'rcu_idle_exit'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2


Regards,
Tobias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

[Tobias Klausmann]

Hi! 

On Sat, 25 Aug 2012, Paul E. McKenney wrote:
> Both Alpha patches should apply as-is back to 3.3, and should also fix
> the problem.  Could you please check this on the versions of interest?

I just now tried them on top of 3.3.8 from linux-stable.git.
While they apply cleanly, I get a compile failure:

  CC  arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:64: error: implicit declaration of function 
'schedule_preempt_disabled'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2

AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.

Regards,
Tobias

-- 
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/11] rcu: Add missing RCU idle APIs on idle loop v2

[Tobias Klausmann]

Hi! 

On Sat, 25 Aug 2012, Paul E. McKenney wrote:
 Both Alpha patches should apply as-is back to 3.3, and should also fix
 the problem.  Could you please check this on the versions of interest?

I just now tried them on top of 3.3.8 from linux-stable.git.
While they apply cleanly, I get a compile failure:

  CC  arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:64: error: implicit declaration of function 
'schedule_preempt_disabled'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2

AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.

Regards,
Tobias

-- 
panic(%s: CORRUPTED BTREE OR SOMETHING, __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/