Re: git pull] drm for v4.1-rc1
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 -- 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: git pull] drm for v4.1-rc1
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 -- 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: git pull] drm for v4.1-rc1
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 -- 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: git pull] drm for v4.1-rc1
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 D945GCLF2.dmesg.gz Description: application/gzip pgpeIZABbWx4C.pgp Description: Digitale Signatur von OpenPGP
Re: git pull] drm for v4.1-rc1
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, &connector->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", &connector->base))
+ continue;
+
if (connector->base.encoder) {
connector->base.state->best_encoder =
connector->base.encoder;
--
2.3.6
--
Ville Syrjälä
Intel OTC
--
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 regression, Re: git pull] drm for v4.1-rc1
> 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-
Re: git pull] drm for v4.1-rc1
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 [] intel_modeset_update_conne
Re: git pull] drm for v4.1-rc1
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-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: git pull] drm for v4.1-rc1
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.garr...@coreos.com -- 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: git pull] drm for v4.1-rc1
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
--
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: git pull] drm for v4.1-rc1
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?
--
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: git pull] drm for v4.1-rc1
[+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
--
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: git pull] drm for v4.1-rc1
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 -- 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: git pull] drm for v4.1-rc1
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 -- 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/
