git pull] drm for v4.1-rc1

[Stefan Lippers-Hollmann]

Hi

On 2015-06-08, Ander Conselvan De Oliveira wrote:
> On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote:
> > On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> > > On 2015-06-07, Ville Syrjälä wrote:
> > > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > > > > On 2015-04-20, Dave Airlie wrote:
[...]
> > > > > > Ander Conselvan de Oliveira (28):
> > > > > [...]
> > > > > >   drm/i915: Allocate connector state together with the 
> > > > > > connectors
> > > > > [...]
> > > > > 
> > > > > This commit introduces a regression relative to v4.0 on an Intel 
> > > > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard 
> > > > > graphics 
> > > > > using its (only-) VGA connector for me.
> > > > > 
> > > > > v4.1-rc6-52-gff25ea8:
> > > > > [   13.265699] BUG: unable to handle kernel NULL pointer dereference 
> > > > > at 0010
> > > > > [   13.265723] IP: [] 
> > > > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> > > > 
> > > > Hmm. Smells like a connector with a NULL state pointer, and the bad
> > > > commit touched exactly the part that sets it up. I can't immediately
> > > > spot any place where we'd forget to set it up though.
> > > > 
> > > > Can you try with something like this so we'd at least find out which
> > > > connector(s) is/are at fault here?
> > > 
> > > With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even
> > > harder, so I had to switch to a serial console in order to fetch the 
> > > boot messages:
> > > 
> > > [   13.492784] connector = 880079bb8000
> > > [   13.910439] connector = 8800795b5800
> > > [   14.463114] connector = 8800795b6000
> > > [   14.700707] connector = 8800795b6800
> > > [   14.869418] connector = 8800795b7000
> > > [   14.923848] connector = 8800795b7000
> > > 
> > > Full, gzipped, bootlog attached - thanks a lot for your efforts.
> > 
> > Could you repeat the process with drm.debug=0xe in your kernel command
> > line and send the logs again?
> 
> Never mind, Ville's patch produced all the information necessary. Please
> give the patch I just sent a try.

Thanks a lot, as already reported as a response to your patch, your 
change "drm/i915: Allocate connector state together with the connectors"
fixes the problem for me.

Regards
Stefan Lippers-Hollmann

git pull] drm for v4.1-rc1

[Ander Conselvan De Oliveira]

On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote:
> On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> > Hi
> > 
> > On 2015-06-07, Ville Syrjälä wrote:
> > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > > > Hi
> > > > 
> > > > On 2015-04-20, Dave Airlie wrote:
> > > > [...]
> > > > > The following changes since commit 
> > > > > 09d51602cf84a1264946711dd4ea0dddbac599a1:
> > > > > 
> > > > >   Merge branch 'turbostat' of 
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 
> > > > > 14:31:41 -0700)
> > > > > 
> > > > > are available in the git repository at:
> > > > > 
> > > > >   git://people.freedesktop.org/~airlied/linux drm-next-merged
> > > > > 
> > > > > for you to fetch changes up to 
> > > > > 2c33ce009ca2389dbf0535d0672214d09738e35e:
> > > > > 
> > > > >   Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)
> > > > [...]
> > > > > Ander Conselvan de Oliveira (28):
> > > > [...]
> > > > >   drm/i915: Allocate connector state together with the connectors
> > > > [...]
> > > > 
> > > > This commit introduces a regression relative to v4.0 on an Intel 
> > > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics 
> > > > using its (only-) VGA connector for me.
> > > > 
> > > > v4.1-rc6-52-gff25ea8:
> > > > [   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
> > > > 0010
> > > > [   13.265723] IP: [] 
> > > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> > > 
> > > Hmm. Smells like a connector with a NULL state pointer, and the bad
> > > commit touched exactly the part that sets it up. I can't immediately
> > > spot any place where we'd forget to set it up though.
> > > 
> > > Can you try with something like this so we'd at least find out which
> > > connector(s) is/are at fault here?
> > 
> > With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even
> > harder, so I had to switch to a serial console in order to fetch the 
> > boot messages:
> > 
> > [   13.492784] connector = 880079bb8000
> > [   13.910439] connector = 8800795b5800
> > [   14.463114] connector = 8800795b6000
> > [   14.700707] connector = 8800795b6800
> > [   14.869418] connector = 8800795b7000
> > [   14.923848] connector = 8800795b7000
> > 
> > Full, gzipped, bootlog attached - thanks a lot for your efforts.
> 
> Could you repeat the process with drm.debug=0xe in your kernel command
> line and send the logs again?

Never mind, Ville's patch produced all the information necessary. Please
give the patch I just sent a try.

Thanks,
Ander

git pull] drm for v4.1-rc1

[Ander Conselvan De Oliveira]

On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2015-06-07, Ville Syrjälä wrote:
> > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > > Hi
> > > 
> > > On 2015-04-20, Dave Airlie wrote:
> > > [...]
> > > > The following changes since commit 
> > > > 09d51602cf84a1264946711dd4ea0dddbac599a1:
> > > > 
> > > >   Merge branch 'turbostat' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 
> > > > 14:31:41 -0700)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://people.freedesktop.org/~airlied/linux drm-next-merged
> > > > 
> > > > for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e:
> > > > 
> > > >   Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)
> > > [...]
> > > > Ander Conselvan de Oliveira (28):
> > > [...]
> > > >   drm/i915: Allocate connector state together with the connectors
> > > [...]
> > > 
> > > This commit introduces a regression relative to v4.0 on an Intel 
> > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics 
> > > using its (only-) VGA connector for me.
> > > 
> > > v4.1-rc6-52-gff25ea8:
> > > [   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
> > > 0010
> > > [   13.265723] IP: [] 
> > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> > 
> > Hmm. Smells like a connector with a NULL state pointer, and the bad
> > commit touched exactly the part that sets it up. I can't immediately
> > spot any place where we'd forget to set it up though.
> > 
> > Can you try with something like this so we'd at least find out which
> > connector(s) is/are at fault here?
> 
> With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even
> harder, so I had to switch to a serial console in order to fetch the 
> boot messages:
> 
> [   13.492784] connector = 880079bb8000
> [   13.910439] connector = 8800795b5800
> [   14.463114] connector = 8800795b6000
> [   14.700707] connector = 8800795b6800
> [   14.869418] connector = 8800795b7000
> [   14.923848] connector = 8800795b7000
> 
> Full, gzipped, bootlog attached - thanks a lot for your efforts.

Could you repeat the process with drm.debug=0xe in your kernel command
line and send the logs again?

Thanks,
Ander

i915 regression, Re: git pull] drm for v4.1-rc1

[Dave Airlie]

> This commit introduces a regression relative to v4.0 on an Intel
> D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics
> using its (only-) VGA connector for me.
>

Jani any ideas/plans?

Dave.

> v4.1-rc6-52-gff25ea8:
> [   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
> 0010
> [   13.265723] IP: [] 
> intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> [   13.265803] PGD 0
> [   13.265810] Oops: 0002 [#1] PREEMPT SMP
> [   13.265820] Modules linked in: iTCO_wdt i915(+) iTCO_vendor_support 
> snd_hda_codec_realtek snd_hda_codec_generic coretemp gpio_ich pcspkr lpc_ich 
> mfd_core video i2c_algo_bit drm_kms_helper snd_hda_intel drm 
> snd_hda_controller i2c_i801 i2c_core evdev snd_hda_codec psmouse sg serio_raw 
> intel_agp intel_gtt rng_core snd_hda_core snd_hwdep snd_pcm snd_timer snd 
> soundcore floppy(+) 8250_fintek acpi_cpufreq button processor fuse parport_pc 
> ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache dm_mod sr_mod cdrom sd_mod 
> ata_generic pata_acpi ata_piix libata scsi_mod uhci_hcd ehci_pci ehci_hcd 
> usbcore usb_common r8169 mii
> [   13.265958] CPU: 0 PID: 211 Comm: systemd-udevd Not tainted 
> 4.1.0-rc6-aptosid-amd64 #1 aptosid 4.1~rc6-1~git65.slh.1
> [   13.265971] Hardware name:  /D945GCLF2, BIOS 
> LF94510J.86A.0278.2010.0414.2000 04/14/2010
> [   13.265999] task: 8800372f65c0 ti: 88007958c000 task.ti: 
> 88007958c000
> [   13.266005] RIP: 0010:[]  [] 
> intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> [   13.266005] RSP: 0018:88007958f820  EFLAGS: 00010246
> [   13.266005] RAX: 88007b0ba800 RBX: 8810b378 RCX: 
> 88003738c000
> [   13.266005] RDX:  RSI: 88003738b408 RDI: 
> 8810b330
> [   13.266005] RBP: 88007c01 R08: 88007c01 R09: 
> 88003738b000
> [   13.266005] R10: 0292 R11: 0020 R12: 
> 8810b348
> [   13.266005] R13: 8810b000 R14: 88007c018688 R15: 
> 
> [   13.266005] FS:  7f4af014a880() GS:88007f20() 
> knlGS:
> [   13.266005] CS:  0010 DS:  ES:  CR0: 80050033
> [   13.266005] CR2: 0010 CR3: 371b2000 CR4: 
> 07f0
> [   13.266005] Stack:
> [   13.266005]  a05709d0 8802 88007c01 
> 8810b330
> [   13.266005]  79f44a80 8810b348 8810b378 
> 8810b000
> [   13.266005]  a00f7949 8810b000 8800 
> 880079f44a80
> [   13.266005] Call Trace:
> [   13.266005]  [] ? 
> intel_modeset_setup_hw_state+0x7e0/0xdb0 [i915]
> [   13.266005]  [] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 
> [drm]
> [   13.266005]  [] ? intel_modeset_init+0x8f4/0x1700 [i915]
> [   13.266005]  [] ? gen2_read32+0x1b/0x30 [i915]
> [   13.266005]  [] ? i915_driver_load+0xe6f/0x13d0 [i915]
> [   13.266005]  [] ? __wake_up+0x2f/0x50
> [   13.266005]  [] ? netlink_broadcast_filtered+0x130/0x380
> [   13.266005]  [] ? kobj_ns_drop+0x50/0x50
> [   13.266005]  [] ? kobject_uevent_env+0xfc/0x400
> [   13.266005]  [] ? get_device+0x12/0x30
> [   13.266005]  [] ? klist_add_tail+0x1f/0x50
> [   13.266005]  [] ? device_add+0x21d/0x650
> [   13.266005]  [] ? drm_dev_register+0x9c/0xf0 [drm]
> [   13.266005]  [] ? drm_get_pci_dev+0x84/0x1f0 [drm]
> [   13.266005]  [] ? __pm_runtime_resume+0x47/0x60
> [   13.266005]  [] ? local_pci_probe+0x3a/0xa0
> [   13.266005]  [] ? pci_match_device+0xe4/0x110
> [   13.266005]  [] ? pci_device_probe+0xe8/0x140
> [   13.266005]  [] ? driver_probe_device+0x179/0x2f0
> [   13.266005]  [] ? __driver_attach+0x7b/0x80
> [   13.266005]  [] ? __device_attach+0x50/0x50
> [   13.266005]  [] ? bus_for_each_dev+0x6b/0xc0
> [   13.266005]  [] ? bus_add_driver+0x178/0x230
> [   13.266005]  [] ? 0xa022b000
> [   13.266005]  [] ? driver_register+0x5e/0xf0
> [   13.266005]  [] ? do_one_initcall+0x98/0x1f0
> [   13.266005]  [] ? do_init_module+0x50/0x1b0
> [   13.266005]  [] ? load_module+0x1ae3/0x2010
> [   13.266005]  [] ? __symbol_put+0x70/0x70
> [   13.266005]  [] ? copy_module_from_fd.isra.55+0xdd/0x170
> [   13.266005]  [] ? SyS_finit_module+0x8d/0xa0
> [   13.266005]  [] ? system_call_fastpath+0x12/0x71
> [   13.266005] Code: 03 00 00 48 8b 49 40 48 89 4a 08 48 8b 50 18 48 39 d7 48 
> 8d 42 e8 74 3a 48 8b 90 b8 02 00 00 48 85 d2 75 c6 48 8b 90 70 03 00 00 <48> 
> c7 42 10 00 00 00 00 48 8b 90 70 03 00 00 48 c7 42 08 00 00
> [   13.266005] RIP  [] 
> intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> [   13.266005]  RSP 
> [   13.266005] CR2: 0010
> [   13.267502] ---[ end trace 365d8347f4bc917c ]---
>
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
> Graphics Controller (rev 02) (prog-if 00 [VGA controller])
> Subsystem: Intel Corporation Device 464c
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 

git pull] drm for v4.1-rc1

[Stefan Lippers-Hollmann]

Hi

On 2015-06-07, Ville Syrjälä wrote:
> On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> > Hi
> > 
> > On 2015-04-20, Dave Airlie wrote:
> > [...]
> > > The following changes since commit 
> > > 09d51602cf84a1264946711dd4ea0dddbac599a1:
> > > 
> > >   Merge branch 'turbostat' of 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 
> > > 14:31:41 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://people.freedesktop.org/~airlied/linux drm-next-merged
> > > 
> > > for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e:
> > > 
> > >   Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)
> > [...]
> > > Ander Conselvan de Oliveira (28):
> > [...]
> > >   drm/i915: Allocate connector state together with the connectors
> > [...]
> > 
> > This commit introduces a regression relative to v4.0 on an Intel 
> > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics 
> > using its (only-) VGA connector for me.
> > 
> > v4.1-rc6-52-gff25ea8:
> > [   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
> > 0010
> > [   13.265723] IP: [] 
> > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
> 
> Hmm. Smells like a connector with a NULL state pointer, and the bad
> commit touched exactly the part that sets it up. I can't immediately
> spot any place where we'd forget to set it up though.
> 
> Can you try with something like this so we'd at least find out which
> connector(s) is/are at fault here?

With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even
harder, so I had to switch to a serial console in order to fetch the 
boot messages:

[   13.492784] connector = 880079bb8000
[   13.910439] connector = 8800795b5800
[   14.463114] connector = 8800795b6000
[   14.700707] connector = 8800795b6800
[   14.869418] connector = 8800795b7000
[   14.923848] connector = 8800795b7000

Full, gzipped, bootlog attached - thanks a lot for your efforts.

Regards
Stefan Lippers-Hollmann
-- next part --
A non-text attachment was scrubbed...
Name: D945GCLF2.dmesg.gz
Type: application/gzip
Size: 15935 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale Signatur von OpenPGP
URL: 

git pull] drm for v4.1-rc1

[Ville Syrjälä]

On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2015-04-20, Dave Airlie wrote:
> [...]
> > The following changes since commit 09d51602cf84a1264946711dd4ea0dddbac599a1:
> > 
> >   Merge branch 'turbostat' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 
> > 14:31:41 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://people.freedesktop.org/~airlied/linux drm-next-merged
> > 
> > for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e:
> > 
> >   Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)
> [...]
> > Ander Conselvan de Oliveira (28):
> [...]
> >   drm/i915: Allocate connector state together with the connectors
> [...]
> 
> This commit introduces a regression relative to v4.0 on an Intel 
> D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics 
> using its (only-) VGA connector for me.
> 
> v4.1-rc6-52-gff25ea8:
> [   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
> 0010
> [   13.265723] IP: [] 
> intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]

Hmm. Smells like a connector with a NULL state pointer, and the bad
commit touched exactly the part that sets it up. I can't immediately
spot any place where we'd forget to set it up though.

Can you try with something like this so we'd at least find out which
connector(s) is/are at fault here?

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3007b44..c10f423 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -918,6 +918,8 @@ int drm_connector_init(struct drm_device *dev,

connector->debugfs_entry = NULL;

+   WARN(1, "connector = %p\n", connector);
+
 out_put:
if (ret)
drm_mode_object_put(dev, >base);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d0f3cbc..dd8ced7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10332,6 +10332,10 @@ static void 
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
struct intel_connector *connector;

for_each_intel_connector(dev, connector) {
+   if (WARN(!connector->base.state,
+"connector = %p\n", >base))
+   continue;
+
if (connector->base.encoder) {
connector->base.state->best_encoder =
connector->base.encoder;
-- 
2.3.6

-- 
Ville Syrjälä
Intel OTC

git pull] drm for v4.1-rc1

[Stefan Lippers-Hollmann]

Hi

On 2015-04-20, Dave Airlie wrote:
[...]
> The following changes since commit 09d51602cf84a1264946711dd4ea0dddbac599a1:
> 
>   Merge branch 'turbostat' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 14:31:41 
> -0700)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~airlied/linux drm-next-merged
> 
> for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e:
> 
>   Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)
[...]
> Ander Conselvan de Oliveira (28):
[...]
>   drm/i915: Allocate connector state together with the connectors
[...]

This commit introduces a regression relative to v4.0 on an Intel 
D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics 
using its (only-) VGA connector for me.

v4.1-rc6-52-gff25ea8:
[   13.265699] BUG: unable to handle kernel NULL pointer dereference at 
0010
[   13.265723] IP: [] 
intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
[   13.265803] PGD 0 
[   13.265810] Oops: 0002 [#1] PREEMPT SMP 
[   13.265820] Modules linked in: iTCO_wdt i915(+) iTCO_vendor_support 
snd_hda_codec_realtek snd_hda_codec_generic coretemp gpio_ich pcspkr lpc_ich 
mfd_core video i2c_algo_bit drm_kms_helper snd_hda_intel drm snd_hda_controller 
i2c_i801 i2c_core evdev snd_hda_codec psmouse sg serio_raw intel_agp intel_gtt 
rng_core snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore floppy(+) 
8250_fintek acpi_cpufreq button processor fuse parport_pc ppdev lp parport 
autofs4 ext4 crc16 jbd2 mbcache dm_mod sr_mod cdrom sd_mod ata_generic 
pata_acpi ata_piix libata scsi_mod uhci_hcd ehci_pci ehci_hcd usbcore 
usb_common r8169 mii
[   13.265958] CPU: 0 PID: 211 Comm: systemd-udevd Not tainted 
4.1.0-rc6-aptosid-amd64 #1 aptosid 4.1~rc6-1~git65.slh.1
[   13.265971] Hardware name:  /D945GCLF2, BIOS 
LF94510J.86A.0278.2010.0414.2000 04/14/2010
[   13.265999] task: 8800372f65c0 ti: 88007958c000 task.ti: 
88007958c000
[   13.266005] RIP: 0010:[]  [] 
intel_modeset_update_connector_atomic_state+0x61/0x90 [i915]
[   13.266005] RSP: 0018:88007958f820  EFLAGS: 00010246
[   13.266005] RAX: 88007b0ba800 RBX: 8810b378 RCX: 88003738c000
[   13.266005] RDX:  RSI: 88003738b408 RDI: 8810b330
[   13.266005] RBP: 88007c01 R08: 88007c01 R09: 88003738b000
[   13.266005] R10: 0292 R11: 0020 R12: 8810b348
[   13.266005] R13: 8810b000 R14: 88007c018688 R15: 
[   13.266005] FS:  7f4af014a880() GS:88007f20() 
knlGS:
[   13.266005] CS:  0010 DS:  ES:  CR0: 80050033
[   13.266005] CR2: 0010 CR3: 371b2000 CR4: 07f0
[   13.266005] Stack:
[   13.266005]  a05709d0 8802 88007c01 
8810b330
[   13.266005]  79f44a80 8810b348 8810b378 
8810b000
[   13.266005]  a00f7949 8810b000 8800 
880079f44a80
[   13.266005] Call Trace:
[   13.266005]  [] ? intel_modeset_setup_hw_state+0x7e0/0xdb0 
[i915]
[   13.266005]  [] ? drm_modeset_lock_all_crtcs+0xa9/0xc0 
[drm]
[   13.266005]  [] ? intel_modeset_init+0x8f4/0x1700 [i915]
[   13.266005]  [] ? gen2_read32+0x1b/0x30 [i915]
[   13.266005]  [] ? i915_driver_load+0xe6f/0x13d0 [i915]
[   13.266005]  [] ? __wake_up+0x2f/0x50
[   13.266005]  [] ? netlink_broadcast_filtered+0x130/0x380
[   13.266005]  [] ? kobj_ns_drop+0x50/0x50
[   13.266005]  [] ? kobject_uevent_env+0xfc/0x400
[   13.266005]  [] ? get_device+0x12/0x30
[   13.266005]  [] ? klist_add_tail+0x1f/0x50
[   13.266005]  [] ? device_add+0x21d/0x650
[   13.266005]  [] ? drm_dev_register+0x9c/0xf0 [drm]
[   13.266005]  [] ? drm_get_pci_dev+0x84/0x1f0 [drm]
[   13.266005]  [] ? __pm_runtime_resume+0x47/0x60
[   13.266005]  [] ? local_pci_probe+0x3a/0xa0
[   13.266005]  [] ? pci_match_device+0xe4/0x110
[   13.266005]  [] ? pci_device_probe+0xe8/0x140
[   13.266005]  [] ? driver_probe_device+0x179/0x2f0
[   13.266005]  [] ? __driver_attach+0x7b/0x80
[   13.266005]  [] ? __device_attach+0x50/0x50
[   13.266005]  [] ? bus_for_each_dev+0x6b/0xc0
[   13.266005]  [] ? bus_add_driver+0x178/0x230
[   13.266005]  [] ? 0xa022b000
[   13.266005]  [] ? driver_register+0x5e/0xf0
[   13.266005]  [] ? do_one_initcall+0x98/0x1f0
[   13.266005]  [] ? do_init_module+0x50/0x1b0
[   13.266005]  [] ? load_module+0x1ae3/0x2010
[   13.266005]  [] ? __symbol_put+0x70/0x70
[   13.266005]  [] ? copy_module_from_fd.isra.55+0xdd/0x170
[   13.266005]  [] ? SyS_finit_module+0x8d/0xa0
[   13.266005]  [] ? system_call_fastpath+0x12/0x71
[   13.266005] Code: 03 00 00 48 8b 49 40 48 89 4a 08 48 8b 50 18 48 39 d7 48 
8d 42 e8 74 3a 48 8b 90 b8 02 00 00 48 85 d2 75 c6 48 8b 90 70 03 00 00 <48> c7 
42 10 00 00 00 00 48 8b 90 70 03 00 00 48 c7 42 08 00 00 
[   13.266005] RIP  [] 

git pull] drm for v4.1-rc1

[Alex Deucher]

On Thu, Apr 23, 2015 at 5:30 PM, Bjorn Helgaas  wrote:
> [+cc Matthew]
>
> On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
>> Hmm. The odd Intel PCI resource mess is back.
>>
>> Or maybe it never went away.
>>
>> I get these when suspending. Things *work*, but it's really spamming
>> my logs a fair bit:
>>
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   pci_bus :01: Allocating resources
>>   pci_bus :02: Allocating resources
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>>
>> That resource is complete garbage. "flags 0x2" is not even a valid
>> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
>> that is valid, then it should also have have had the IORESOURCE_MEM
>> bit, and it doesn't.
>
> Your i915 does not have a ROM BAR in hardware.  If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
> shadow ROM image at 0xC.  Is there a shadow image even if the
> device itself doesn't have a ROM BAR?

Very likely yes.  With integrated APUs and mobile dGPUs, the vbios
image is often stored as part of the system rom rather than as a
dedicated rom for the GPU.  The vbios image is then copied to the
shadow location during sbios init to provide OS access to the rom.

Alex

>
> We could fabricate a resource even if the BAR doesn't exist, e.g.,
> "flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
> would be ugly and error-prone in other places that use the ROM.
>
> Matthew added dev->rom for ROM images supplied by the platform
> (84c1b80e3263 ("PCI: Add support for non-BAR ROMs")).  A shadow
> image seems like a similar thing.  I think it would be cleaner to get
> rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
> 0xC" if there's a shadow image, e.g.:
>
>   int pcibios_add_device(struct pci_dev *dev)
>   {
> if (dev-is-default-vga-device) {
>   dev->rom = 0xC;
>   dev->romlen = 0x2;
> }
>
> pa_data = boot_params.hdr.setup_data;
> while (pa_data) {
>   ...
>   if (data->type == SETUP_PCI) {
> rom = (struct pci_setup_rom *)data;
>
> if (dev-is-rom-dev) {
>   dev->rom = ...
>   dev->romlen = rom->pcilen;
> }
>   }
> }
>
> But the rules for figuring out which image to use seem ...
> complicated.
>
> Bjorn
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

git pull] drm for v4.1-rc1

[Bjorn Helgaas]

[+cc Matthew]

On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
> 
> Or maybe it never went away.
> 
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
> 
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   pci_bus :01: Allocating resources
>   pci_bus :02: Allocating resources
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
> 
> That resource is complete garbage. "flags 0x2" is not even a valid
> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
> that is valid, then it should also have have had the IORESOURCE_MEM
> bit, and it doesn't.

Your i915 does not have a ROM BAR in hardware.  If the default video
device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
even though the resource flags are zero because the BAR itself doesn't
exist.

If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
shadow ROM image at 0xC.  Is there a shadow image even if the
device itself doesn't have a ROM BAR?

We could fabricate a resource even if the BAR doesn't exist, e.g.,
"flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
would be ugly and error-prone in other places that use the ROM.

Matthew added dev->rom for ROM images supplied by the platform
(84c1b80e3263 ("PCI: Add support for non-BAR ROMs")).  A shadow
image seems like a similar thing.  I think it would be cleaner to get
rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
0xC" if there's a shadow image, e.g.:

  int pcibios_add_device(struct pci_dev *dev)
  {
if (dev-is-default-vga-device) {
  dev->rom = 0xC;
  dev->romlen = 0x2;
}

pa_data = boot_params.hdr.setup_data;
while (pa_data) {
  ...
  if (data->type == SETUP_PCI) {
rom = (struct pci_setup_rom *)data;

if (dev-is-rom-dev) {
  dev->rom = ...
  dev->romlen = rom->pcilen;
}
  }
}

But the rules for figuring out which image to use seem ...
complicated.

Bjorn

git pull] drm for v4.1-rc1

[Matthew Garrett]

On Thu, Apr 23, 2015 at 3:47 PM, Linus Torvalds
 wrote:

> I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
> yes, if what this is all about is the magic video ROM at 0xc, then

It's used in the PCI layer to say "Read from 0xc rather than the
ROM BAR" and then ends up as a shorthand for "Was this the boot video
device" in various places because we're bad at software.

> There is no way to see that from the PCI device state, because as
> mentioned, quite often the "ROM" is entirely fake, and is not just
> some shadowed copy of a real underlying hardware ROM, but is
> fundamentally just a RAM image decompressed from some other source and
> then marked read-only.

If only - nvidias used to rewrite their image at runtime.

-- 
Matthew Garrett | matthew.garrett at coreos.com

git pull] drm for v4.1-rc1

[Linus Torvalds]

On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
 wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas  wrote:
>>
>>   int pcibios_add_device(struct pci_dev *dev)
>>   {
>> if (dev-is-default-vga-device) {
>>   dev->rom = 0xC;
>>   dev->romlen = 0x2;
>> }
>
> I don't know what we want to do here. This is, at some level,
> fundamentally wrong - however, it also wouldn't surprise me if this is
> also the only copy of the video ROM we have on some UEFI systems,
> especially since I believe that Windows 7 still required that there be
> a legacy ROM it could use for bootloader modesetting on UEFI
> platforms. So simply making this conditional on BIOS may break
> existing machines. But if there *is* a ROM there then we should be
> able to id it from the usual video ROM signature?

I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
yes, if what this is all about is the magic video ROM at 0xc, then

 (a) it should have nothing what-so-ever to do with the actual PCI
BAR, since it's been *ages* since people actually had an expansion rom
like that, and it's much more common that the video ROM comes as part
of the system BIOS on laptops etc.

 (b) yes, the sane thing to do would be to just look for the ROM
signature, 0x55 0xaa at 2kB incrementing headers (and checking the
proper checksum too).

There is no way to see that from the PCI device state, because as
mentioned, quite often the "ROM" is entirely fake, and is not just
some shadowed copy of a real underlying hardware ROM, but is
fundamentally just a RAM image decompressed from some other source and
then marked read-only.

   Linus

git pull] drm for v4.1-rc1

[Matthew Garrett]

On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas  wrote:

> Your i915 does not have a ROM BAR in hardware.  If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
> shadow ROM image at 0xC.  Is there a shadow image even if the
> device itself doesn't have a ROM BAR?

On UEFI systems, there's no special reason to believe that there's
anything at 0xc - it depends on whether a CSM got loaded or not.
Everything is awful. So...

>   int pcibios_add_device(struct pci_dev *dev)
>   {
> if (dev-is-default-vga-device) {
>   dev->rom = 0xC;
>   dev->romlen = 0x2;
> }

I don't know what we want to do here. This is, at some level,
fundamentally wrong - however, it also wouldn't surprise me if this is
also the only copy of the video ROM we have on some UEFI systems,
especially since I believe that Windows 7 still required that there be
a legacy ROM it could use for bootloader modesetting on UEFI
platforms. So simply making this conditional on BIOS may break
existing machines. But if there *is* a ROM there then we should be
able to id it from the usual video ROM signature?

git pull] drm for v4.1-rc1

[Bjorn Helgaas]

On Tue, Apr 21, 2015 at 11:07 AM, Linus Torvalds
 wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   pci_bus :01: Allocating resources
>   pci_bus :02: Allocating resources
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>   i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
>
> That resource is complete garbage. "flags 0x2" is not even a valid
> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
> that is valid, then it should also have have had the IORESOURCE_MEM
> bit, and it doesn't.
>
> (The low 8 bits of the resource flags depend on the high bits, which
> is why I say that I'm "guessing" at that ROM_SHADOW bit. It could be
> something else, like a IORESOURCE_MEM_CACHEABLE PnP bit - but that
> should not show up for PCI, and "BAR 6" is normally the ROM resource,
> so the ROM_SHADOW bit makes some sense.
>
> The only place that sets IORESOURCE_ROM_SHADOW that I find is the x86
> pci_fixup_video() function. That one checks for PCI_COMMAND_IO |
> PCI_COMMAND_MEMORY in the PCI command word, though. Why are the other
> bits not set?
>
> Both i915/dri people and PCI people on the Cc. This warning does *not*
> happen at bootup, but only at suspend time. So my suspicion is that
> somebody messes with the PCI ROM resource, and disables it or
> something, but the IORESOURCE_ROM_SHADOW never gets cleared. And then
> because res->flags is non-zero, the PCI scanning code doesn't ignore
> the resource.
>
> Just before the whole bogus alignment check, the PCI code does
>
> if (!(r->flags) || r->parent)
> continue;
>
> (don't ask me about the odd parenthesis) which *should* have
> triggered, but that IORESOURCE_ROM_SHADOW bit screws things up.
>
> Anybody?

I'll look into this.  It's been around a long time, but hasn't
percolated to the top of my list until now.

https://bugzilla.kernel.org/show_bug.cgi?id=16063 says "echo 1
>/sys/bus/pci/rescan" is also a reproducer.

Bjorn

git pull] drm for v4.1-rc1

[Linus Torvalds]

Hmm. The odd Intel PCI resource mess is back.

Or maybe it never went away.

I get these when suspending. Things *work*, but it's really spamming
my logs a fair bit:

  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  pci_bus :01: Allocating resources
  pci_bus :02: Allocating resources
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment
  i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment

That resource is complete garbage. "flags 0x2" is not even a valid
flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
that is valid, then it should also have have had the IORESOURCE_MEM
bit, and it doesn't.

(The low 8 bits of the resource flags depend on the high bits, which
is why I say that I'm "guessing" at that ROM_SHADOW bit. It could be
something else, like a IORESOURCE_MEM_CACHEABLE PnP bit - but that
should not show up for PCI, and "BAR 6" is normally the ROM resource,
so the ROM_SHADOW bit makes some sense.

The only place that sets IORESOURCE_ROM_SHADOW that I find is the x86
pci_fixup_video() function. That one checks for PCI_COMMAND_IO |
PCI_COMMAND_MEMORY in the PCI command word, though. Why are the other
bits not set?

Both i915/dri people and PCI people on the Cc. This warning does *not*
happen at bootup, but only at suspend time. So my suspicion is that
somebody messes with the PCI ROM resource, and disables it or
something, but the IORESOURCE_ROM_SHADOW never gets cleared. And then
because res->flags is non-zero, the PCI scanning code doesn't ignore
the resource.

Just before the whole bogus alignment check, the PCI code does

if (!(r->flags) || r->parent)
continue;

(don't ask me about the odd parenthesis) which *should* have
triggered, but that IORESOURCE_ROM_SHADOW bit screws things up.

Anybody?

Linus

git pull] drm for v4.1-rc1

[Dave Airlie]

Hi Linus,

First up, this tree contains a backmerge of your tree, as it merges cleanly
but then fails to build on ARM due to an API change, I've included the
fixed up patch in the merge commit.

The unmerged, unfixed tree is in my drm-next branch if you want to confirm
things. The fixup is 3 trivial ^regulator_set_optimum_mode^regulator_set_load
in drivers/gpu/drm/msm/dsi/dsi_host.c.

I've also been delayed waiting for Grant's tree to merge, but that is in
now so I'm not dragging in stuff from that any longer.

Highlights:

Core:
Virtual GEM layer merged, this has been around for a long time,
and it provides a software backed device that allows userspace to
use it as a GEM shared memory handler. This makes it a lot easier
to do certain things when you have no GPU but still have to deal with
DRI expectations.

atomic helper updates.
framebuffer modifier interface added.
i2c over auxch displayport fixes.
fb width/height confusion fixes.

new driver for ps8622/ps8625 bridge chips
lots of new panels

i915:
more plane atomic conversion
vGPU guest support for XenGT
Skylake workarounds and fixes
Y-tiling support
work on dynamic pagetable allocation
EU count report param for gen9+
CHV fixes (no longer prelim)
remove ilk rc6
frontbuffer tracking for fbc
Displayport link rate refactoring
sprite colorkey refactor

radeon:
Displayport MST support (not enabled by default)
non-ATOM native hw auxch support (DCE5+)
output csc support
new queries for userspace debug support
new VCE packet

nouveau:
gk20a iommu support
gm107 graphics support
more gm20x bringup (waiting on signed nvidia fw).

amdkfd:
multiple kgd instance support
use 64-bit time accessors

msm:
stolen memory support
DSI and dual-DSI support
snapdragon 410 support

exynos:
cleanups for atomic and pageflip

imx-drm:
more media-bus formats
TV output prep
drm panel support

tegra:
hw vblank counter using host1x syncpoints

omap:
universal plane support
prep work for atomic modesetting

rcar-du:
ported to atomic modesetting

atmel-hlcdc:
ported to atomic modesetting
added suspend/resume support

sti:
ported to atomic modesetting

dwhdmi:
more compliant audio support
update rockchip phy support

tda998x:
DT probing for attached crtcs
simplified EDID reading

rockchip:
fixes
adv7511:
fixes

Dave.

The following changes since commit 09d51602cf84a1264946711dd4ea0dddbac599a1:

  Merge branch 'turbostat' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 14:31:41 
-0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next-merged

for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e:

  Merge Linus master into drm-next (2015-04-20 13:05:20 +1000)


Akash Goel (12):
  drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
  drm/i915/skl: Added new macros
  drm/i915/skl: Updated intel_gpu_freq() and intel_freq_opcode()
  drm/i915/skl: Updated the gen6_init_rps_frequencies function
  drm/i915/skl: Updated the gen6_set_rps function
  drm/i915/skl: Restructured the gen6_set_rps_thresholds function
  drm/i915/skl: Updated the gen6_rps_limits function
  drm/i915/skl: Updated the gen9_enable_rps function
  drm/i915/skl: Updated the act_freq_mhz_show sysfs function
  drm/i915/skl: Updated the i915_frequency_info debugfs function
  drm/i915/skl: Enabling processing of Turbo interrupts
  drm/i915/skl: Enable the RPS interrupts programming

Alex Deucher (27):
  drm/radeon: add an output_csc property
  drm/radeon: implement output csc property for DCE5+
  drm/radeon: setup quantization_range in AVI infoframe
  drm/radeon: add INFO query for GPU temperature
  drm/radeon/dpm: add new callbacks to get the current sclk/mclk
  drm/radeon/rs780: implement get_current_sclk/mclk
  drm/radeon/rv6xx: implement get_current_sclk/mclk
  drm/radeon/rv7xx/eg: implement get_current_sclk/mclk
  drm/radeon/btc: implement get_current_sclk/mclk
  drm/radeon: remove some rv7xx leftovers from btc dpm code
  drm/radeon/ni: implement get_current_sclk/mclk
  drm/radeon/si: implement get_current_sclk/mclk
  drm/radeon/ci: implement get_current_sclk/mclk
  drm/radeon/sumo: implement get_current_sclk/mclk
  drm/radeon/tn: implement get_current_sclk/mclk
  drm/radeon/kv: implement get_current_sclk/mclk
  drm/radeon: add INFO query for current sclk/mclk
  drm/radeon: add new callback for info ioctl register accessor