[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> > Daniel,
> >
> > I am not quite sure I understand what you want me to test?
> > Do you want me to try it without:
> >
> > > > + if (ret == 0) {
> > > > + ret = do_unregister_con_driver(&vga_con);
>
> Below the diff of what I mean.
> -Daniel
>
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5e583a1838f8..bd8517151479 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1466,12 +1466,13 @@ static int i915_kick_out_vgacon(struct
> drm_i915_private *dev_priv)
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> - int ret;
> + int ret = 0;
>
> DRM_INFO("Replacing VGA console driver\n");
>
> console_lock();
> - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (con_is_bound(&vga_con))
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1,
> 1);
> if (ret == 0) {
> ret = do_unregister_con_driver(&vga_con);
>
>
[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
Just to be sure. The intel card here should not be claiming the real console.
It does
not have an output device and the bios set set so the radeon is the primary
device.
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
> > On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> > >
> > > Resend without html krud which causes list to bounce the message.
> > >
> > > > Hi
> > > >
> > > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > > with 3.16-git. Reverting it lets the boot proceed.
> > > >
> > > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > > primary console. The i915 is initialized
> > > > but does not have a physical display attached.
> > > >
> > > > With the patch applied the boot stops at the messages:
> > > >
> > > > [drm] Memory usable by graphics device = 2048M
> > > > [drm] Replacing VGA console driver
> >
> > The issue looks like that we are ripping out the radeon fb_con whilst it
> > is active and that upsets everyone. In which case, I think the
> > compromise is:
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5f44581..4915f1d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> > drm_i915_private *dev_priv)
> > #else
> > static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > {
> > - int ret;
> > + int ret = 0;
> >
> > DRM_INFO("Replacing VGA console driver\n");
> >
> > console_lock();
> > - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> > - if (ret == 0) {
> > - ret = do_unregister_con_driver(&vga_con);
> > -
> > - /* Ignore "already unregistered". */
> > - if (ret == -ENODEV)
> > - ret = 0;
> > + if (con_is_bound(&vga_con)) {
> > + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES -
> > 1, 1);
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(&vga_con);
>
> Hm, we should only conditionalize the take_over_console - unregistering
> vga_con is kinda the point to make sure it's gone for real. Ed, can you
> please retest with the if (con_is_bound) check just for the
> do_take_over_console call?
>
> Still puzzled wtf is going on here since as David says this should be a
> no-op.
>
> Thanks, Daniel
> > +
> > + /* Ignore "already unregistered". */
> > + if (ret == -ENODEV)
> > + ret = 0;
> > + }
> > }
> > console_unlock();
> >
> > -Chris
> >
>
>
[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Daniel,
I am not quite sure I understand what you want me to test?
Do you want me to try it without:
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(&vga_con);
Thanks
Ed
On Monday 07 July 2014 10:48:26 Daniel Vetter wrote:
> On Mon, Jun 30, 2014 at 07:59:55AM +0100, Chris Wilson wrote:
> > On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> > >
> > > Resend without html krud which causes list to bounce the message.
> > >
> > > > Hi
> > > >
> > > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > > with 3.16-git. Reverting it lets the boot proceed.
> > > >
> > > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > > primary console. The i915 is initialized
> > > > but does not have a physical display attached.
> > > >
> > > > With the patch applied the boot stops at the messages:
> > > >
> > > > [drm] Memory usable by graphics device = 2048M
> > > > [drm] Replacing VGA console driver
> >
> > The issue looks like that we are ripping out the radeon fb_con whilst it
> > is active and that upsets everyone. In which case, I think the
> > compromise is:
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5f44581..4915f1d 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> > drm_i915_private *dev_priv)
> > #else
> > static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > {
> > - int ret;
> > + int ret = 0;
> >
> > DRM_INFO("Replacing VGA console driver\n");
> >
> > console_lock();
> > - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> > - if (ret == 0) {
> > - ret = do_unregister_con_driver(&vga_con);
> > -
> > - /* Ignore "already unregistered". */
> > - if (ret == -ENODEV)
> > - ret = 0;
> > + if (con_is_bound(&vga_con)) {
> > + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES -
> > 1, 1);
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(&vga_con);
>
> Hm, we should only conditionalize the take_over_console - unregistering
> vga_con is kinda the point to make sure it's gone for real. Ed, can you
> please retest with the if (con_is_bound) check just for the
> do_take_over_console call?
>
> Still puzzled wtf is going on here since as David says this should be a
> no-op.
>
> Thanks, Daniel
> > +
> > + /* Ignore "already unregistered". */
> > + if (ret == -ENODEV)
> > + ret = 0;
> > + }
> > }
> > console_unlock();
> >
> > -Chris
> >
>
>
[git pull] drm fixes
Hi Dave, This is NOT fixing problems with a stalled boot due to VGA problems as reported in thread: [PATCH 5/5] drm/i915: Kick out vga console It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803 or applying the patch from Chris Wilson which can be found as a reply to my report. Thanks Ed Tomlinson On Saturday 05 July 2014 23:13:27 Dave Airlie wrote: > > Hi Linus, > > i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA > connectors, along with some fixes for the tda998x from Russell fixing some > modesetting problems > > (still on holidays, but got a spare moment to find these). > > Dave. > > The following changes since commit e1a08b855f56d6528e7f85aae9ca8123f4c3ae04: > > Merge tag 'arm64-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2014-07-05 > 10:12:52 -0700) > > are available in the git repository at: > > > git://people.freedesktop.org/~airlied/linux drm-fixes > > for you to fetch changes up to dfd7aecfd6d227831d77719379d4c7137f444fee: > > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel (2014-07-06 07:49:59 +1000) > > > > Dave Airlie (3): > Merge branch 'tda998x-fixes' of > git://ftp.arm.linux.org.uk/~rmk/linux-cubox > Merge branch 'vmwgfx-fixes-3.16' of > git://people.freedesktop.org/~thomash/linux > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel > > Deepak S (1): > drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin > > Guido Mart?nez (1): > drm/i2c: tda998x: move drm_i2c_encoder_destroy call > > Jesse Barnes (1): > drm/i915: only apply crt_present check on VLV > > Russell King (2): > drm/i2c: tda998x: faster polling for edid > drm/i2c: tda998x: add some basic mode validation > > Thomas Hellstrom (1): > drm/vmwgfx: Fix incorrect write to read-only register v2: > > Ville Syrj?l? (1): > drm/i915: Wait for vblank after enabling the primary plane on BDW > > drivers/gpu/drm/i2c/tda998x_drv.c| 12 +--- > drivers/gpu/drm/i915/intel_display.c | 27 ++- > drivers/gpu/drm/i915/intel_pm.c | 8 > drivers/gpu/drm/i915/intel_sprite.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 - > 5 files changed, 51 insertions(+), 5 deletions(-)
[PATCH 5/5] drm/i915: Kick out vga console
Hi Chris,
I had to rediff to get a patch that applies... I am not hanging with this
applied - it
does look like the i915 is starting is initialization later boot the new kernel.
[2.389796] [drm] Radeon Display Connectors
[2.389798] [drm] Connector 0:
[2.389799] [drm] DP-1
[2.389799] [drm] HPD2
[2.389801] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c
0x653c
[2.389802] [drm] Encoders:
[2.389803] [drm] DFP1: INTERNAL_UNIPHY2
[2.389804] [drm] Connector 1:
[2.389805] [drm] HDMI-A-1
[2.389805] [drm] HPD3
[2.389806] [drm] DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c
0x655c
[2.389807] [drm] Encoders:
[2.389808] [drm] DFP2: INTERNAL_UNIPHY2
[2.389809] [drm] Connector 2:
[2.389810] [drm] DVI-D-1
[2.389811] [drm] HPD1
[2.389812] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
0x656c
[2.389813] [drm] Encoders:
[2.389814] [drm] DFP3: INTERNAL_UNIPHY1
[2.389815] [drm] Connector 3:
[2.389815] [drm] DVI-I-1
[2.389816] [drm] HPD6
[2.389817] [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c
0x658c
[2.389818] [drm] Encoders:
[2.389819] [drm] DFP4: INTERNAL_UNIPHY
[2.389820] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[2.435689] raid6: avx2x2 24564 MB/s
[2.435691] Switched to clocksource tsc
[2.489087] usb 1-8: new low-speed USB device number 7 using xhci_hcd
[2.492403] raid6: avx2x4 34887 MB/s
[2.492404] raid6: using algorithm avx2x4 (34887 MB/s)
[2.492405] raid6: using avx2x2 recovery algorithm
[2.492789] xor: automatically using best checksumming function:
[2.502557] Adding 5779452k swap on /dev/sdb2. Priority:-2 extents:1
across:5779452k FS
[2.511532] [drm] fb mappable at 0xE098E000
[2.511536] [drm] vram apper at 0xE000
[2.511538] [drm] size 9216000
[2.511539] [drm] fb depth is 24
[2.511541] [drm]pitch is 7680
[2.511590] fbcon: radeondrmfb (fb0) is primary device
[2.516691] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[2.525778]avx : 41474.400 MB/sec
[2.532408] Console: switching to colour frame buffer device 240x75
[2.535567] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[2.535567] radeon :01:00.0: registered panic notifier
[2.544968] Btrfs loaded
[2.545276] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 1
transid 308068 /dev/sdc1
[2.545739] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 2
transid 308068 /dev/sdb1
[2.552946] [drm] Initialized radeon 2.39.0 20080528 for :01:00.0 on
minor 0
[2.553248] [drm] Memory usable by graphics device = 2048M
[2.553273] [drm] Replacing VGA console driver
[2.572539] i915 :00:02.0: irq 46 for MSI/MSI-X
[2.572546] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.572565] [drm] Driver supports precise vblank timestamp query.
If you are happy with this you can give this patch my tested by.
Thanks
Ed Tomlinson
On Monday 30 June 2014 07:59:55 Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> >
> > Resend without html krud which causes list to bounce the message.
> >
> > > Hi
> > >
> > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot
> > > with 3.16-git. Reverting it lets the boot proceed.
> > >
> > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the
> > > primary console. The i915 is initialized
> > > but does not have a physical display attached.
> > >
> > > With the patch applied the boot stops at the messages:
> > >
> > > [drm] Memory usable by graphics device = 2048M
> > > [drm] Replacing VGA console driver
>
> The issue looks like that we are ripping out the radeon fb_con whilst it
> is active and that upsets everyone. In which case, I think the
> compromise is:
>
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5f44581..4915f1d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct
> drm_i915_private *dev_priv)
> #else
> static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> {
> - int ret;
> + int ret = 0;
>
> DRM_INFO("Replacing VGA console driver\n");
>
> console_lock();
> - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> - if (ret == 0) {
> - ret = do_unregister_con_driver(&vga_con);
> -
> - /* Ignore "already unre
[PATCH 5/5] drm/i915: Kick out vga console
On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote: Resend without html krud which causes list to bounce the message. > Hi > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot with > 3.16-git. Reverting it lets the boot proceed. > > I have an i7 with a built-in i915 and an pcie r7 260x. The R7 is the primary > console. The i915 is initialized > but does not have a physical display attached. > > With the patch applied the boot stops at the messages: > > [drm] Memory usable by graphics device = 2048M > [drm] Replacing VGA console driver > > and I need to interrupt or power off the box to get it back. > > (I did not notice messages about the R7 but they could have easily been > missed - this box does not have a serial console) > > Without the patch I get: > > Jun 28 14:53:54 localhost kernel: [2.075351] e1000e: Intel(R) PRO/1000 > Network Driver - 2.3.2-k > Jun 28 14:53:54 localhost kernel: [2.075796] [drm] Initialized drm 1.1.0 > 20060810 > Jun 28 14:53:54 localhost kernel: [2.075958] microcode: CPU0 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077289] microcode: CPU1 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077299] microcode: CPU2 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077307] microcode: CPU3 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077315] microcode: CPU4 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077325] microcode: CPU5 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077335] microcode: CPU6 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077342] microcode: CPU7 sig=0x306c3, > pf=0x2, revision=0x17 > Jun 28 14:53:54 localhost kernel: [2.077378] microcode: Microcode Update > Driver: v2.00 , Peter Oruba > Jun 28 14:53:54 localhost kernel: [2.079726] input: PC Speaker as > /devices/platform/pcspkr/input/input4 > Jun 28 14:53:54 localhost kernel: [2.083930] e1000e: Copyright(c) 1999 - > 2014 Intel Corporation. > Jun 28 14:53:54 localhost kernel: [2.084787] ACPI Warning: SystemIO range > 0xf040-0xf05f conflicts with OpRegion > 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) > (20140424/utaddress-258) > Jun 28 14:53:54 localhost kernel: [2.084788] ACPI: If an ACPI driver is > available for this device, you should use it instead of the native driver > Jun 28 14:53:54 localhost kernel: [2.084894] e1000e :00:19.0: > Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode > Jun 28 14:53:54 localhost kernel: [2.084905] e1000e :00:19.0: irq 44 > for MSI/MSI-X > Jun 28 14:53:54 localhost kernel: [2.096721] iTCO_vendor_support: > vendor-support=0 > Jun 28 14:53:54 localhost kernel: [2.096780] AVX2 version of gcm_enc/dec > engaged. > Jun 28 14:53:54 localhost kernel: [2.098512] iTCO_wdt: Intel TCO WatchDog > Timer Driver v1.11 > Jun 28 14:53:54 localhost kernel: [2.099042] iTCO_wdt: Found a Lynx Point > TCO device (Version=2, TCOBASE=0x1860) > Jun 28 14:53:54 localhost kernel: [2.099561] iTCO_wdt: initialized. > heartbeat=30 sec (nowayout=0) > Jun 28 14:53:54 localhost kernel: [2.100401] [drm] radeon kernel > modesetting enabled. > Jun 28 14:53:54 localhost kernel: [2.100918] checking generic (e000 > 30) vs hw (e000 1000) > Jun 28 14:53:54 localhost kernel: [2.100919] fb: switching to radeondrmfb > from simple > Jun 28 14:53:54 localhost kernel: [2.101372] Console: switching to colour > dummy device 80x25 > Jun 28 14:53:54 localhost kernel: [2.101527] [drm] initializing kernel > modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). > Jun 28 14:53:54 localhost kernel: [2.101534] [drm] register mmio base: > 0xF080 > Jun 28 14:53:54 localhost kernel: [2.101535] [drm] register mmio size: > 262144 > Jun 28 14:53:54 localhost kernel: [2.101540] [drm] doorbell mmio base: > 0xF000 > Jun 28 14:53:54 localhost kernel: [2.101541] [drm] doorbell mmio size: > 8388608 > Jun 28 14:53:54 localhost kernel: [2.101579] ATOM BIOS: Bonaire > Jun 28 14:53:54 localhost kernel: [2.101627] radeon :01:00.0: VRAM: > 2048M 0x - 0x7FFF (2048M used) > Jun 28 14:53:54 localhost kernel: [2.101629] radeon :01:00.0: GTT: > 1024M 0x8000 - 0xBFFF > Jun 28 14:53:54 localhost kernel: [2.101630] [drm] Detected VRAM > RAM=2048M, BAR=256M > Jun 28 14:53:54 localhost kernel: [2.101631] [drm] RAM width 128bits
[PATCH 5/5] drm/i915: Kick out vga console
e :00:19.0: irq 50
for MSI/MSI-X
Jun 28 14:53:54 localhost kernel: [2.546018] IPv6: ADDRCONF(NETDEV_UP):
eth0: link is not ready
Jun 28 14:53:54 localhost kernel: [2.619122] usb 1-8: ep 0x81 - rounding
interval to 512 microframes, ep desc says 800 microframes
Jun 28 14:53:54 localhost kernel: [2.759949] i915 :00:02.0: fb1:
inteldrmfb frame buffer device
Jun 28 14:53:54 localhost kernel: [2.760226] [drm] Initialized i915 1.6.0
20080730 for :00:02.0 on minor 1
Jun 28 14:53:54 localhost kernel: [2.779511] usb 1-14: new high-speed USB
device number 8 using xhci_hcd
I am willing to try patches.
Please fix or revert this commit.
Thanks,
Ed Tomlinson
On Thursday 05 June 2014 16:58:28 Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbcon.
>
> Also, we want this to make I915_FBDEV=n safe.
>
> v2: Rebase and pimp commit message.
>
> v3: We also need to unregister the vga console, otherwise the unbind
> of the fb console before module unload might resurrect it again.
>
> v4: Ignore errors when the vga console is already unregistered - this
> can happen when e.g. reloading i915.ko.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jani Nikula
> Signed-off-by: Chris Wilson (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 43
> +++-
> drivers/video/console/dummycon.c | 1 +
> drivers/video/console/vgacon.c | 1 +
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 27fe65ac5940..bcb66ddd649e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -36,6 +36,8 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct
> drm_i915_private *dev_priv)
> }
> #endif
>
> +#if !defined(CONFIG_VGA_CONSOLE)
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return 0;
> +}
> +#elif !defined(CONFIG_DUMMY_CONSOLE)
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return -ENODEV;
> +}
> +#else
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + int ret;
> +
> + DRM_INFO("Replacing VGA console driver\n");
> +
> + console_lock();
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (ret == 0) {
> + ret = do_unregister_con_driver(&vga_con);
> +
> + /* Ignore "already unregistered". */
> + if (ret == -ENODEV)
> + ret = 0;
> + }
> + console_unlock();
> +
> + return ret;
> +}
> +#endif
> +
> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
> {
> const struct intel_device_info *info = &dev_priv->info;
> @@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> if (ret)
> goto out_regs;
>
> - if (drm_core_check_feature(dev, DRIVER_MODESET))
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + ret = i915_kick_out_vgacon(dev_priv);
> + if (ret) {
> + DRM_ERROR("failed to remove conflicting VGA console\n");
> + goto out_gtt;
> + }
> +
> i915_kick_out_firmware_fb(dev_priv);
> + }
>
> pci_set_master(dev->pdev);
>
> diff --git a/drivers/video/console/dummycon.c
> b/drivers/video/console/dummycon.c
> index b63860f7beab..40bec8d64b0a 100644
> --- a/drivers/video/console/dummycon.c
> +++ b/drivers/video/console/dummycon.c
> @@ -77,3 +77,4 @@ const struct consw dummy_con = {
> .con_set_palette = DUMMY,
> .con_scrolldelta = DUMMY,
> };
> +EXPORT_SYMBOL_GPL(dummy_con);
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index 9d8feac67637..84acd6223dc5 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
> .con_build_attr = vgacon_build_attr,
> .con_invert_region = vgacon_invert_region,
> };
> +EXPORT_SYMBOL(vga_con);
>
> MODULE_LICENSE("GPL");
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140628/0333e1fb/attachment-0001.html>
[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi It seems the follow on message with the panic's as an attachment did not make it. Here is a link with the jpg: https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986&oid=108244876431105742323[1] Thanks Ed On Friday 27 June 2014 09:17:08 Ed Tomlinson wrote: > Hi > > Got the following panic runing 16-rc2 + git. The latest commit was: > > commit d91d66e88ea95b6dd21958834414009614385153 > Merge: 07f4695 6663a4f > Author: Linus Torvalds > Date: Wed Jun 25 05:44:17 2014 -0700 > > I was not doing anything interesting (displaying a photo from facebook with > firefox) > when this happened. The distribution is arch at is up to date as of june > 26th. > > Thanks > Ed Tomlinson [1] https://plus.google.com/u/0/photos/108244876431105742323/albums/6029631260384977873/6029631269719723986?pid=6029631269719723986&oid=108244876431105742323 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140627/911f527d/attachment.html>
[PANIC] at drivers/drm/drm_irq.c:976 with 3.16-rc2+git
Hi Got the following panic runing 16-rc2 + git. The latest commit was: commit d91d66e88ea95b6dd21958834414009614385153 Merge: 07f4695 6663a4f Author: Linus Torvalds Date: Wed Jun 25 05:44:17 2014 -0700 I was not doing anything interesting (displaying a photo from facebook with firefox) when this happened. The distribution is arch at is up to date as of june 26th. Thanks Ed Tomlinson
[git pull] drm fixes
On Wednesday 23 April 2014 07:54:17 Dave Airlie wrote: > On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds > wrote: > > Dave, mind sending me a pull request for drm fixes? > > > > There's now at least these two: > > > > - "drm/radeon/aux: fix hpd assignment for aux bus" > > - "drm/radeon: use fixed PPL ref divider if needed" > > > > that look like fairly fatal regressions when they affect somebody. > > > > The fact that we already had *two* independent bugs be reported within > > days of that last out-of-merge-window pull request makes me very > > unhappy with the state of drm pulls. > > > > So please make sure that future fixes really are *fixes*. For > > regressions only. No more games like this. > > The pll fallout is fixes for the initial feature that was in the merge window, > Tuning plls for monitors is always a pain in the ass, the previous algorithm > took a couple of kernels a few years back to get where it was, unfortunately > HDMI came along and showed up a bunch of its shortcomings. I'm happy > Alex and Christian are on top of things in terms of tracking regressions > and making sure they get fixed, > > the AUX fix yes I'm a bit pissed off about myself, but I missed a pull > from a few > weeks ago, felt guilty, and maybe should have chosen the other path and let it > wait a merge, > > Christian just sent me a -fixes pull with all of these in it and I'll > send it on to you > in a few mins. Hi Given the fun I had with rc1 I decided to try this pull before rc2 and its working fine here. Thanks! Ed Tomlinson
[git pull] drm fixes
On Monday 21 April 2014 17:26:15 Ed Tomlinson wrote: > On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: > > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > > > like, but I included a patch that just moves code from one file to > > > > > another > > > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > > > seem > > > > > worse than it is, > > > > > > > > > Christian K?nig (2): > > > > > drm/radeon: apply more strict limits for PLL params v2 > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > > > Author: Christian K?nig > > > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > > > The commit above causes my monitor to just stay blank after boot. > > > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. > > Reverting > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef > Author: Alex Deucher > Date: Mon Apr 7 10:33:46 2014 -0400 > > drm/radeon/dp: switch to the common i2c over aux code > > Provides a nice cleanup in radeon. > > Signed-off-by: Alex Deucher > Signed-off-by: Christian K?nig > > Restores the display - no more i2c errors This fixed here without reverts by the patch from Alex Deucher attached in the thread: "Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display" Thanks Ed > > > I have the same symptoms with rc2 and a r7 260x using display port. I > > > cannot > > > seem to get a dmesg of a failure (I _really_ need to figure out how to add > > > a serial console). I'll try reverting once I figure out how to get > > > pacman to > > > do a revert when building from git. > > > > Neither reverting the above patch or add the fix from > > "https://bugs.freedesktop.org/show_bug.cgi?id=77673"; > > helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major > > difference has to do with i2c. On the > > 14.1 kernel I see:
[git pull] drm fixes
On Monday 21 April 2014 15:08:24 Ed Tomlinson wrote: > On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > > like, but I included a patch that just moves code from one file to > > > > another > > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > > seem > > > > worse than it is, > > > > > > > Christian K?nig (2): > > > > drm/radeon: apply more strict limits for PLL params v2 > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > > Author: Christian K?nig > > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > > > The commit above causes my monitor to just stay blank after boot. > > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. Reverting commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef Author: Alex Deucher Date: Mon Apr 7 10:33:46 2014 -0400 drm/radeon/dp: switch to the common i2c over aux code Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher Signed-off-by: Christian K?nig Restores the display - no more i2c errors I have dmesgs of all three tests if anyone wants them. Thanks Ed Tomlinson > > I have the same symptoms with rc2 and a r7 260x using display port. I > > cannot > > seem to get a dmesg of a failure (I _really_ need to figure out how to add > > a serial console). I'll try reverting once I figure out how to get pacman > > to > > do a revert when building from git. > > Neither reverting the above patch or add the fix from > "https://bugs.freedesktop.org/show_bug.cgi?id=77673"; > helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major > difference has to do with i2c. On the > 14.1 kernel I see: > > [2.679029] [drm] ib test on ring 5 succeeded > [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack > [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack > [2.699535] [drm] Radeon Display Connectors > [2.699536] [drm] Connector 0: > [2.699537] [drm] DP-1 > [2.699537] [drm] HPD2 > [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c > 0x653c > [2.699538] [drm] Encoders: > [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 > > skipping the rest of the connectors > [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, > devices 0008, acti > ve_devices > [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, > devices 0080, acti > ve_devices > [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, > devices 0200, acti > ve_devices > [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, > devices 0400, acti > ve_devices > [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, > devices 0001, acti > ve_devices > [2.706746] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:19:DP-1] > [2.712729] [drm:radeon_dp_getdpcd], DPCD: > [2.712731] [drm:radeon_dp_getdpcd], 11 > [2.712732] [drm:radeon_dp_getdpcd], 0a > [2.712733] [drm:radeon_dp_getdpcd], 84 > [2.712733] [drm:radeon_dp_getdpcd], 00 > [2.712734] [drm:radeon_dp_getdpcd], 01 > [2.712735] [drm:radeon_dp_getdpcd], 00 > [2.712735] [drm:radeon_dp_getdpcd], 00 > [2.712736] [drm:radeon_dp_getdpcd], 00 > [2.712736] [drm:radeon_dp_getdpcd], 00 > [2.712737] [drm:radeon_dp_getdpcd], 00 > [2.712738] [drm:radeon_dp_getdpcd], 00 > [2.712739] [drm:radeon_dp_getdpcd], 00 > [2.712739] [drm:radeon_dp_getdpcd], 00 > [2.712740] [drm:radeon_dp_getdpcd], 00 > [2.712741] [drm:radeon_dp_getdpcd], 00 > [2.712741] [drm:radeon_dp_getdpcd], > [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected > [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [2.770907] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:19:DP-1] probed modes : > [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:"1920x1200"
[git pull] drm fixes
On Monday 21 April 2014 10:25:25 Ed Tomlinson wrote: > On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > > like, but I included a patch that just moves code from one file to > > > another > > > and I'd like to avoid merge conflicts with that later, so it makes it > > > seem > > > worse than it is, > > > > > Christian K?nig (2): > > > drm/radeon: apply more strict limits for PLL params v2 > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > Author: Christian K?nig > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > The commit above causes my monitor to just stay blank after boot. > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. > > I have the same symptoms with rc2 and a r7 260x using display port. I cannot > seem to get a dmesg of a failure (I _really_ need to figure out how to add > a serial console). I'll try reverting once I figure out how to get pacman to > do a revert when building from git. Neither reverting the above patch or add the fix from "https://bugs.freedesktop.org/show_bug.cgi?id=77673"; helps here. I managed to get dmesg(s) from 14.1 and 15-rc2. The major difference has to do with i2c. On the 14.1 kernel I see: [2.679029] [drm] ib test on ring 5 succeeded [2.699317] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699478] [drm:radeon_dp_i2c_aux_ch], aux_i2c nack [2.699535] [drm] Radeon Display Connectors [2.699536] [drm] Connector 0: [2.699537] [drm] DP-1 [2.699537] [drm] HPD2 [2.699538] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.699538] [drm] Encoders: [2.699539] [drm] DFP1: INTERNAL_UNIPHY2 skipping the rest of the connectors [2.699647] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0008, acti ve_devices [2.699648] [drm:radeon_atom_encoder_dpms], encoder dpms 33 to mode 3, devices 0080, acti ve_devices [2.699649] [drm:radeon_atom_encoder_dpms], encoder dpms 32 to mode 3, devices 0200, acti ve_devices [2.699650] [drm:radeon_atom_encoder_dpms], encoder dpms 30 to mode 3, devices 0400, acti ve_devices [2.699651] [drm:radeon_atom_encoder_dpms], encoder dpms 21 to mode 3, devices 0001, acti ve_devices [2.706746] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] [2.712729] [drm:radeon_dp_getdpcd], DPCD: [2.712731] [drm:radeon_dp_getdpcd], 11 [2.712732] [drm:radeon_dp_getdpcd], 0a [2.712733] [drm:radeon_dp_getdpcd], 84 [2.712733] [drm:radeon_dp_getdpcd], 00 [2.712734] [drm:radeon_dp_getdpcd], 01 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712735] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712736] [drm:radeon_dp_getdpcd], 00 [2.712737] [drm:radeon_dp_getdpcd], 00 [2.712738] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712739] [drm:radeon_dp_getdpcd], 00 [2.712740] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], 00 [2.712741] [drm:radeon_dp_getdpcd], [2.712746] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected [2.713618] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.738573] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770849] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 [2.770907] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:19:DP-1] probed modes : [2.770908] [drm:drm_mode_debug_printmodeline], Modeline 28:"1920x1200" 60 154000 1920 1968 2 000 2080 1200 1203 1209 1235 0x48 0x9 And on the 15-rc2 kernel [2.580468] [drm] ib test on ring 4 succeeded in 0 usecs [2.601369] [drm] ib test on ring 5 succeeded [2.622309] [drm] ib test on ring 6 succeeded [2.623058] [drm] ib test on ring 7 succeeded [2.623449] [drm] Radeon Display Connectors [2.623452] [drm] Connector 0: [2.623453] [drm] DP-1 [2.623455] [drm] HPD2 [2.623457] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [2.623459] [drm] Encoders: [2.623461] [drm] DFP1: INTERNAL_UNIPHY2 (connectors skipped) [2.623618] [drm:radeon_atom_encoder_dpms] encoder dpms 33 to mode 3, devices 0080, activ e_devices [2.623620] [drm:radeon_atom_encoder_dpms] encoder dpms 32 to mode 3, devices 0200, activ e_devices [2.623621] [drm:rad
[git pull] drm fixes
On Saturday 19 April 2014 21:03:05 Markus Trippelsdorf wrote: > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > > > > Unfortunately this contains no easter eggs, its a bit larger than I'd > > like, but I included a patch that just moves code from one file to another > > and I'd like to avoid merge conflicts with that later, so it makes it seem > > worse than it is, > > > Christian K?nig (2): > > drm/radeon: apply more strict limits for PLL params v2 > > drm/radeon: improve PLL params if we don't match exactly v2 > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > Author: Christian K?nig > Date: Wed Apr 16 11:54:21 2014 +0200 > > drm/radeon: improve PLL params if we don't match exactly v2 > > The commit above causes my monitor to just stay blank after boot. > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. I have the same symptoms with rc2 and a r7 260x using display port. I cannot seem to get a dmesg of a failure (I _really_ need to figure out how to add a serial console). I'll try reverting once I figure out how to get pacman to do a revert when building from git. Thanks, Ed Tomlinson
[BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: > On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > > Hi, > > > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > > its supposed work much better with 14-rc. > > > This is not the case. My system is unstable without radeon.dpm=0 which > > > was the default in .13. Here are some extracts > > > from the logs of the latest fun with dpm enabled: > > omitted > > > > The above type of errors repeat hundreds of times and eventually the > > > display freezes (this box does not have a serial console and it did not > > > check with ssh) > > > > > > When X started I did notice some corruption. There are sets of two > > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a > > > second > > > about a cm below. The often occurs in chomium especially when scrolling. > > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > > programs also produce the above problems and eventually stall. > > > > > > The problem is reproducible - I am not that familiar with gpu problems > > > though, what else will help debug this? > > > > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > > Component: DRM/Radeon) and attach your dmesg output and xorg log. > > Filed as bug 75992 > > Let me know if you want me to test anything or if more info is needed. This still occurrs with rc7. With dpm enabled X is not usable. It stalls, sometimes with nasty screen corruption, after a few minute. With dpm disabled its much better (not perfect though). Ed Tomlinson
[BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote: > On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > > Hi, > > > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > > its supposed work much better with 14-rc. > > > This is not the case. My system is unstable without radeon.dpm=0 which > > > was the default in .13. Here are some extracts > > > from the logs of the latest fun with dpm enabled: > > omitted > > > > The above type of errors repeat hundreds of times and eventually the > > > display freezes (this box does not have a serial console and it did not > > > check with ssh) > > > > > > When X started I did notice some corruption. There are sets of two > > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a > > > second > > > about a cm below. The often occurs in chomium especially when scrolling. > > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > > programs also produce the above problems and eventually stall. > > > > > > The problem is reproducible - I am not that familiar with gpu problems > > > though, what else will help debug this? > > > > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > > Component: DRM/Radeon) and attach your dmesg output and xorg log. > > Filed as bug 75992 > > Let me know if you want me to test anything or if more info is needed. This bug also occurs with rc7. My system is not useable when booted without radeon.dpm=0 - X stalls after a minute or two of use. Thanks Ed Tomlinson
[BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > Hi, > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > its supposed work much better with 14-rc. > > This is not the case. My system is unstable without radeon.dpm=0 which was > > the default in .13. Here are some extracts > > from the logs of the latest fun with dpm enabled: omitted > > The above type of errors repeat hundreds of times and eventually the > > display freezes (this box does not have a serial console and it did not > > check with ssh) > > > > When X started I did notice some corruption. There are sets of two > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a second > > about a cm below. The often occurs in chomium especially when scrolling. > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > programs also produce the above problems and eventually stall. > > > > The problem is reproducible - I am not that familiar with gpu problems > > though, what else will help debug this? > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. TIA Ed
[BUG] 3.14-rc6 problems with an R7 260X
alhost kernel: [ 231.782399] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x The above type of errors repeat hundreds of times and eventually the display freezes (this box does not have a serial console and it did not check with ssh) When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. The problem is reproducible - I am not that familiar with gpu problems though, what else will help debug this? TIA Ed Tomlinson
Re: Regression 2.6.34+ -> 2.6.34-rc5: radeon KMS rs780 problems
On Monday 19 July 2010 10:34:20 Michel Dänzer wrote: > On Sam, 2010-07-17 at 18:56 -0400, Ed Tomlinson wrote: > > > > My 790gx chipset supplies an rs780. With .34+ all is ok. > > With .35-rc5 basic function seems ok (kde works) but games like > > extreme tux racer have problems. The cursor does not display when on > > the tux racer window and various objects flicker on and off as I > > attempt to play the game. > > Sounds like it might be > https://bugs.freedesktop.org/show_bug.cgi?id=28341 . Does the X driver > patch attached there fix the problem? Michel, xf86-video-ati git from today fails. Applying the revert patch in the above message fixes the problem. Its an interesting bug in that the kernel change triggers the driver bug. Might be a good idea to get this fixed, one way or another, before -35 gets released? Let me know if you want me to test anything. Thanks, Ed Tomlinson ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression 2.6.34+ -> 2.6.34-rc5: radeon KMS rs780 problems
On Monday 19 July 2010 10:34:20 Michel D?nzer wrote: > On Sam, 2010-07-17 at 18:56 -0400, Ed Tomlinson wrote: > > > > My 790gx chipset supplies an rs780. With .34+ all is ok. > > With .35-rc5 basic function seems ok (kde works) but games like > > extreme tux racer have problems. The cursor does not display when on > > the tux racer window and various objects flicker on and off as I > > attempt to play the game. > > Sounds like it might be > https://bugs.freedesktop.org/show_bug.cgi?id=28341 . Does the X driver > patch attached there fix the problem? Michel, xf86-video-ati git from today fails. Applying the revert patch in the above message fixes the problem. Its an interesting bug in that the kernel change triggers the driver bug. Might be a good idea to get this fixed, one way or another, before -35 gets released? Let me know if you want me to test anything. Thanks, Ed Tomlinson
Regression 2.6.34+ -> 2.6.34-rc5: radeon KMS rs780 problems
Hi, My 790gx chipset supplies an rs780. With .34+ all is ok. With .35-rc5 basic function seems ok (kde works) but games like extreme tux racer have problems. The cursor does not display when on the tux racer window and various objects flicker on and off as I attempt to play the game. Here is what .34+ detects (think this kernel has a drm-radeon-testing from may or early june) [1.370735] [drm] Initialized drm 1.1.0 20060810 [1.376014] [drm] radeon defaulting to kernel modesetting. [1.382041] [drm] radeon kernel modesetting enabled. [1.387560] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [1.395205] radeon :01:05.0: setting latency timer to 64 [1.397347] [drm] initializing kernel modesetting (RS780 0x1002:0x9614). [1.404961] [drm] register mmio base: 0xFE9F [1.410036] [drm] register mmio size: 65536 [1.415328] ATOM BIOS: B27722 [1.418612] [drm] Clocks initialized ! [1.422740] [drm] 3 Power State(s) [1.426486] [drm] State 0 Default (default) [1.431081] [drm]1 Clock Mode(s) [1.434831] [drm]0 engine: 30 [1.438773] [drm] State 1 Performance [1.442897] [drm]1 Clock Mode(s) [1.446648] [drm]0 engine: 50 [1.450589] [drm] State 2 Default [1.454344] [drm]1 Clock Mode(s) [1.458093] [drm]0 engine: 50 [1.462038] [drm] radeon: power management initialized [1.467705] radeon :01:05.0: VRAM: 256M 0xC000 - 0xCFFF (256M used) [1.475724] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [1.485117] [drm] Detected VRAM RAM=256M, BAR=256M [1.490391] [drm] RAM width 32bits DDR [1.494785] [TTM] Zone kernel: Available graphics memory: 3956838 kiB. [1.502042] [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [1.509465] [drm] radeon: 256M of VRAM memory ready [1.514825] [drm] radeon: 512M of GTT memory ready. [1.520236] [drm] radeon: irq initialized. [1.524739] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.532253] [drm] Loading RS780 Microcode with .35-rc5 it finds a different ammount of VRAM. Hardware wise there is 128M of sideport ram. [1.361622] [drm] Initialized drm 1.1.0 20060810 [1.366843] [drm] radeon defaulting to kernel modesetting. [1.372863] [drm] radeon kernel modesetting enabled. [1.378371] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [1.386003] radeon :01:05.0: setting latency timer to 64 [1.388242] [drm] initializing kernel modesetting (RS780 0x1002:0x9614). [1.395870] [drm] register mmio base: 0xFE9F [1.400940] [drm] register mmio size: 65536 [1.406238] ATOM BIOS: B27722 [1.409531] [drm] Clocks initialized ! [1.413688] radeon :01:05.0: VRAM: 384M 0xC000 - 0xD7FF (384M used) [1.421706] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [1.429481] [drm] Detected VRAM RAM=384M, BAR=256M [1.436429] [drm] RAM width 32bits DDR [1.440829] [TTM] Zone kernel: Available graphics memory: 3956866 kiB. [1.448096] [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [1.455348] [TTM] Initializing pool allocator. [1.460471] [drm] radeon: 384M of VRAM memory ready [1.465824] [drm] radeon: 512M of GTT memory ready. [1.471255] [drm] radeon: irq initialized. [1.475760] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.483280] [drm] Loading RS780 Microcode User space/firmware/bios is the same in both cases. Idea? Ed Tomlinson ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression 2.6.34+ -> 2.6.34-rc5: radeon KMS rs780 problems
Hi, My 790gx chipset supplies an rs780. With .34+ all is ok. With .35-rc5 basic function seems ok (kde works) but games like extreme tux racer have problems. The cursor does not display when on the tux racer window and various objects flicker on and off as I attempt to play the game. Here is what .34+ detects (think this kernel has a drm-radeon-testing from may or early june) [1.370735] [drm] Initialized drm 1.1.0 20060810 [1.376014] [drm] radeon defaulting to kernel modesetting. [1.382041] [drm] radeon kernel modesetting enabled. [1.387560] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [1.395205] radeon :01:05.0: setting latency timer to 64 [1.397347] [drm] initializing kernel modesetting (RS780 0x1002:0x9614). [1.404961] [drm] register mmio base: 0xFE9F [1.410036] [drm] register mmio size: 65536 [1.415328] ATOM BIOS: B27722 [1.418612] [drm] Clocks initialized ! [1.422740] [drm] 3 Power State(s) [1.426486] [drm] State 0 Default (default) [1.431081] [drm]1 Clock Mode(s) [1.434831] [drm]0 engine: 30 [1.438773] [drm] State 1 Performance [1.442897] [drm]1 Clock Mode(s) [1.446648] [drm]0 engine: 50 [1.450589] [drm] State 2 Default [1.454344] [drm]1 Clock Mode(s) [1.458093] [drm]0 engine: 50 [1.462038] [drm] radeon: power management initialized [1.467705] radeon :01:05.0: VRAM: 256M 0xC000 - 0xCFFF (256M used) [1.475724] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [1.485117] [drm] Detected VRAM RAM=256M, BAR=256M [1.490391] [drm] RAM width 32bits DDR [1.494785] [TTM] Zone kernel: Available graphics memory: 3956838 kiB. [1.502042] [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [1.509465] [drm] radeon: 256M of VRAM memory ready [1.514825] [drm] radeon: 512M of GTT memory ready. [1.520236] [drm] radeon: irq initialized. [1.524739] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.532253] [drm] Loading RS780 Microcode with .35-rc5 it finds a different ammount of VRAM. Hardware wise there is 128M of sideport ram. [1.361622] [drm] Initialized drm 1.1.0 20060810 [1.366843] [drm] radeon defaulting to kernel modesetting. [1.372863] [drm] radeon kernel modesetting enabled. [1.378371] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [1.386003] radeon :01:05.0: setting latency timer to 64 [1.388242] [drm] initializing kernel modesetting (RS780 0x1002:0x9614). [1.395870] [drm] register mmio base: 0xFE9F [1.400940] [drm] register mmio size: 65536 [1.406238] ATOM BIOS: B27722 [1.409531] [drm] Clocks initialized ! [1.413688] radeon :01:05.0: VRAM: 384M 0xC000 - 0xD7FF (384M used) [1.421706] radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [1.429481] [drm] Detected VRAM RAM=384M, BAR=256M [1.436429] [drm] RAM width 32bits DDR [1.440829] [TTM] Zone kernel: Available graphics memory: 3956866 kiB. [1.448096] [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [1.455348] [TTM] Initializing pool allocator. [1.460471] [drm] radeon: 384M of VRAM memory ready [1.465824] [drm] radeon: 512M of GTT memory ready. [1.471255] [drm] radeon: irq initialized. [1.475760] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.483280] [drm] Loading RS780 Microcode User space/firmware/bios is the same in both cases. Idea? Ed Tomlinson
