Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
Re: [git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
Re: [git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm for rc1
Am 10.01.2011 23:59, schrieb Dave Airlie: > > Hi Linus, > > non-drm changes: > one kref change we needed that went on list with no comments > > New hardware: > radeon: add support for Fusion APUs and Radeon HD6xxx chipsets > nouveau: Fermi acceleration support (requires external fw for now) > > Highlights: > core/drivers: add support for high precision vblank timestamps > radeon: pageflipping support, Gen2 PCIE support > nouveau: reworked VRAM and VM support > intel: better ILK/SNB powersaving support, Full GTT support > > There are also some switcheroo patches to further improve it, though I > have a later patch blocking on an x86 platform driver for the nvidia/intel > switcher. > > Dave. Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) During startup the framebuffer shows only stripes and a blank screen after suspend/resume. I also see lots of TRAP messages. (see below). X11 seems to work fine though... $ dmesg | grep drm [0.520906] [drm] Initialized drm 1.1.0 20060810 [0.521200] [drm] radeon defaulting to kernel modesetting. [0.521416] [drm] radeon kernel modesetting enabled. [0.522179] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! [0.536664] [drm] nouveau :01:00.0: Detected an NV50 generation card (0x084c00a2) [0.556998] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [0.641884] [drm] nouveau :01:00.0: ... appears to be valid [0.642058] [drm] nouveau :01:00.0: BIT BIOS found [0.642227] [drm] nouveau :01:00.0: Bios version 60.84.51.00 [0.642400] [drm] nouveau :01:00.0: TMDS table version 2.0 [0.642567] [drm] nouveau :01:00.0: BIT table 'd' not found [0.642736] [drm] nouveau :01:00.0: Found Display Configuration Block version 4.0 [0.642969] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000323 00010034 [0.643141] [drm] nouveau :01:00.0: Raw DCB entry 1: 02811300 0028 [0.643315] [drm] nouveau :01:00.0: Raw DCB entry 2: 02822312 00010030 [0.643490] [drm] nouveau :01:00.0: Raw DCB entry 3: 000e [0.643662] [drm] nouveau :01:00.0: DCB connector table: VHER 0x40 5 14 2 [0.643836] [drm] nouveau :01:00.0: 0: 0x0040: type 0x40 idx 0 tag 0xff [0.644089] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff [0.644317] [drm] nouveau :01:00.0: 2: 0x1231: type 0x31 idx 2 tag 0x07 [0.644543] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [0.688140] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [0.724028] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [0.724264] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [0.732117] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [0.732345] [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0xEFDF [0.756029] [drm] nouveau :01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [0.775483] [drm] nouveau :01:00.0: 3 available performance level(s) [0.775663] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 1150mV fanspeed 100% [0.775900] [drm] nouveau :01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 1150mV fanspeed 100% [0.776165] [drm] nouveau :01:00.0: 2: memory 702MHz core 475MHz shader 950MHz voltage 1200mV fanspeed 100% [0.776419] [drm] nouveau :01:00.0: c: memory 302MHz core 275MHz shader 550MHz voltage 1150mV [0.777232] [drm] nouveau :01:00.0: Detected 256MiB VRAM [0.817893] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [0.889393] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [0.889565] [drm] No driver support for vblank timestamp query. [0.904293] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [1.071762] [drm] nouveau :01:00.0: allocated 1920x1200 fb: 0x6000, bo 88013af63400 [1.071842] [drm] nouveau
[git pull] drm for rc1
Am 12.01.2011 00:28, schrieb Linus Torvalds: > On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger > wrote: >> >> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA >> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1)) >> During startup the framebuffer shows only stripes and a blank >> screen after suspend/resume. >> I also see lots of TRAP messages. (see below). >> X11 seems to work fine though... > > Can you try to bisect? dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit commit dfe63bb0ad9810db13aab0058caba97866e0a681 Author: James Simmons Date: Thu Dec 23 16:40:37 2010 + drm: Update fbdev fb_fix_screeninfo Reverting this on top of todays git also fixes my problem. Christian
[git pull] drm for rc1
Am 12.01.2011 13:49, schrieb James Simmons: > I see the problem. Nouveau for some hardware does a accelerated > clearing of the screen before we register the framebuffer. The above patch > does fix a real issue so please don't revert it. Can you try this patch. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..4ef24d6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,8 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ Hmm, does not seem to work. Any more initialization missing?
[git pull] drm for rc1
Am 12.01.2011 14:32, schrieb James Simmons: > Okay. The nouveau driver also uses the pitch as well. It > really should be using the pitch field from drm_framebuffer instead of the > line_length from fb_fix_screeninfo. This patch is just to make sure this > is the issue. I will submit another patch later that uses > drm_fb_framebuffer's pitch field. As for the visual unfortunely their is > no real mapping between drm and fbdev. > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > index a26d047..de3b067 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c > @@ -359,6 +359,9 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev, > info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo); > info->screen_size = size; > > + info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR : > +FB_VISUAL_TRUECOLOR; > + info->fix.line_length = fb->pitch; > drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, > sizes->fb_height); > > /* Set aperture base/size for vesafb takeover */ That fixes _my_ nouveau frame buffer regression.
[git pull] drm for rc1
Am 12.01.2011 14:45, schrieb James Simmons: >> I tested the revert: the boot screen did change the resolution >> (without it don't), but my PC still hangs. (using an nvidia 8800GT). > > Try my most recent patch. Where does it hang at? Any logs? FYI, I just want to mention that with the latest git+the fix X11 sometimes consumes 100% cpu for a long time. Dont know if this is a related problem or not. Christian
