[Bug 28082] New: r300g: Commit b0427be breaks 7 piglit tests
https://bugs.freedesktop.org/show_bug.cgi?id=28082 Summary: r300g: Commit b0427be breaks 7 piglit tests Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: tstellar at gmail.com Using the R300 Gallium driver on my RV370 card, commit b0427bedde80e3189524651a327235bdfddbc613 breaks the following piglit tests: fp-abs-01 fp-set-01 glsl-lod-bias glsl-reload-source glsl-routing vp-arl-constant-array-huge vp-arl-constant-array-huge-offset -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
No subject
versions of libdrm from 2.4.18 on. I suppose this means that the Arch Linux people must have patched their version of Linux kernel 2.6.33.3, otherwise it should not have worked with that version of libdrm? Finally, there is the xf86-video-nouveau package, which now is version 0.0.15_git20100314-1. This time, I cloned the git repository of the Nouveau sources with this command: "git clone --depth 1 git://anongit.freedesktop.org/nouveau/linux-2.6", which turned out to be version 2.6.34-rc5 of the Linux kernel. The patch utility refused to apply the mwk patch, as they were already there. So I tried that kernel as is, and this time X segfaulted, dropping the computer back to the 80x50 text screen. Should I build different versions of libdrm, or xf86-video-nouveau? Attached is the Xorg.0.log resulting from this combination of Nouveau kernel 2.6.34-rc5, libdrm 2.4.19-2, and xf86-video-nouveau 0.0.15_git20100314-1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris, On Wed, May 12, 2010 at 7:20 PM, Chris Wilson wrote: > On Wed, 12 May 2010 18:45:55 +0530, Jaswinder Singh Rajput gmail.com> wrote: >> Hello Chris, >> >> With this patch after XWindows freezes, I get : > [snip] >> freeze dmesg : >> http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634_chris_hang.txt >> >> freeze Xorg.log : >> http://userweb.kernel.org/~jaswinder/acer_netbook/Xorg_log.txt > > Jaswinder can you also upload the /sys/kernel/debug/dri/0/i915_error_state > following a freeze as well, please. If your /sys/kernel/debug is empty, > you will need to "mount -tdebugfs debug /sys/kernel/debug". > i915_error_state : http://userweb.kernel.org/~jaswinder/acer_netbook/i915_error_state.txt Thanks, -- Jaswinder Singh.
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris, On Wed, May 12, 2010 at 1:23 AM, Chris Wilson wrote: > On Wed, 12 May 2010 01:08:23 +0530, Jaswinder Singh Rajput gmail.com> wrote: >> Hello Chris and Andrew, >> >> I did further testing and noticed that this patch fixes the boot >> errors and warnings and I get the XWindows. >> >> But XWindows freezes after some time. > > The BUG you were hitting before is on the error collection path which > presumably is still being triggered during boot by a GPU error. > Can you check to see if /sys/kernel/debug/dri/0/i915_error_state has > recorded anything? And if not, wait until it freezes and then please file > a bug report at bugs.freedesktop.org with the i915_error_state, Xorg.0.log > and dmesg. > With this patch after XWindows freezes, I get : [ 70.433064] wlan0: no IPv6 routers present [ 227.490064] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 227.490098] [ cut here ] [ 227.490124] WARNING: at mm/highmem.c:453 debug_kmap_atomic+0xa9/0x11e() [ 227.490135] Hardware name: Aspire one [ 227.490143] Modules linked in: nf_conntrack_ftp ath9k ath9k_common ath9k_hw battery [last unloaded: scsi_wait_scan] [ 227.490183] Pid: 0, comm: swapper Not tainted 2.6.34-rc7-netbook #8 [ 227.490193] Call Trace: [ 227.490214] [] warn_slowpath_common+0x65/0x7c freeze dmesg : http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634_chris_hang.txt freeze Xorg.log : http://userweb.kernel.org/~jaswinder/acer_netbook/Xorg_log.txt So it means this patches shifted the BUG and warning messages after some time. So I can only work on XWindows for few minutes with this patch. Andrew patch is in linus git tree. Can you please update your patch above Andrew patch. So that I can do further testing. Thanks, -- Jaswinder Singh.
[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info V2
Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm
crtc id. Bump the minor version so userspace can enable conditionaly
features depend on this.
V2 use num_crtc and avoid DRM_ERROR
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 18 ++
include/drm/radeon_drm.h|1 +
3 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index b3749d4..df96ace 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -44,9 +44,10 @@
* - 2.1.0 - add square tiling interface
* - 2.2.0 - add r6xx/r7xx const buffer support
* - 2.3.0 - add MSPOS + 3D texture + r500 VAP regs
+ * - 2.4.0 - add crtc id query
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 3
+#define KMS_DRIVER_MINOR 4
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index d3657dc..9df2427 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -98,11 +98,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
{
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info;
+ struct radeon_mode_info *minfo = >mode_info;
uint32_t *value_ptr;
uint32_t value;
+ struct drm_crtc *crtc;
+ int i, found;
info = data;
value_ptr = (uint32_t *)((unsigned long)info->value);
+ value = *value_ptr;
switch (info->request) {
case RADEON_INFO_DEVICE_ID:
value = dev->pci_device;
@@ -116,6 +120,20 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
case RADEON_INFO_ACCEL_WORKING:
value = rdev->accel_working;
break;
+ case RADEON_INFO_CRTC_FROM_ID:
+ for (i = 0, found = 0; i < rdev->num_crtc; i++) {
+ crtc = (struct drm_crtc *)minfo->crtcs[i];
+ if (crtc && crtc->base.id == value) {
+ value = i;
+ found = 1;
+ break;
+ }
+ }
+ if (!found) {
+ DRM_INFO("unknown crtc id %d\n", value);
+ return -EINVAL;
+ }
+ break;
default:
DRM_DEBUG("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 81e614b..3ff9fc0 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -902,6 +902,7 @@ struct drm_radeon_cs {
#define RADEON_INFO_NUM_GB_PIPES 0x01
#define RADEON_INFO_NUM_Z_PIPES0x02
#define RADEON_INFO_ACCEL_WORKING 0x03
+#define RADEON_INFO_CRTC_FROM_ID 0x04
struct drm_radeon_info {
uint32_trequest;
--
1.7.0.1
[Bug 27211] endless PROTECTION_FAULT logs, Nouveau drm, TNT card
https://bugs.freedesktop.org/show_bug.cgi?id=27211 --- Comment #10 from Brent 2010-05-12 15:01:37 PDT --- I built a custom kernel with the source of 2.6.33.3 from kernel.org, not from an Arch Linux package. I patched it with the above mwk patch. That resulted in the error I gave in the previous comment. I am not clear on what all parts of Nouveau are what. The nouveau-drm package seems to be only kernel modules. When I built my custom kernel, I made sure it had its own Nouveau modules. I am not sure what is in libdrm (/usr/lib/libdrm_nouveau.so), but Pacman reports a version number of 2.4.19-2.
[Bug 27211] endless PROTECTION_FAULT logs, Nouveau drm, TNT card
https://bugs.freedesktop.org/show_bug.cgi?id=27211 --- Comment #9 from Brent 2010-05-12 14:59:26 PDT --- Created an attachment (id=35601) --> (https://bugs.freedesktop.org/attachment.cgi?id=35601) Xorg log (1.7.6-3, 0.0.15_git20100314-1, 2.4.19-2, 2.6.34-rc5) xorg-server 1.7.6-3 xf86-video-nouveau 0.0.15_git20100314-1 libdrm 2.4.19-2 kernel 2.6.34-rc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Record error batch buffers using iomem
On Wed, 12 May 2010 18:45:55 +0530, Jaswinder Singh Rajput wrote: > Hello Chris, > > With this patch after XWindows freezes, I get : [snip] > freeze dmesg : > http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634_chris_hang.txt > > freeze Xorg.log : > http://userweb.kernel.org/~jaswinder/acer_netbook/Xorg_log.txt Jaswinder can you also upload the /sys/kernel/debug/dri/0/i915_error_state following a freeze as well, please. If your /sys/kernel/debug is empty, you will need to "mount -tdebugfs debug /sys/kernel/debug". > So it means this patches shifted the BUG and warning messages after > some time. So I can only work on XWindows for few minutes with this > patch. > Andrew patch is in linus git tree. Can you please update your patch > above Andrew patch. So that I can do further testing. What is in the tree is adequate for the time being. It will capture the batch buffer into the error state. My follow-on patch only increases the level of paranoia. Thanks for testing. -- Chris Wilson, Intel Open Source Technology Centre
[Bug 28069] maniadrive - smooth play with LIBGL_ALWAYS_INDIRECT=true, (almost) unplayable otherwise
https://bugs.freedesktop.org/show_bug.cgi?id=28069 Paulo C?sar Pereira de Andrade changed: What|Removed |Added Attachment #35599|LIBGL_ALWAYS_INDIRECT=true |LIBGL_ALWAYS_INDIRECT=true description|glxinfo.txt |glxinfo --- Comment #4 from Paulo C?sar Pereira de Andrade 2010-05-12 13:16:49 PDT --- (From update of attachment 35599) description is command line used -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28069] maniadrive - smooth play with LIBGL_ALWAYS_INDIRECT=true, (almost) unplayable otherwise
https://bugs.freedesktop.org/show_bug.cgi?id=28069 --- Comment #3 from Paulo C?sar Pereira de Andrade 2010-05-12 13:16:12 PDT --- Created an attachment (id=35600) --> (https://bugs.freedesktop.org/attachment.cgi?id=35600) glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28069] maniadrive - smooth play with LIBGL_ALWAYS_INDIRECT=true, (almost) unplayable otherwise
https://bugs.freedesktop.org/show_bug.cgi?id=28069 --- Comment #2 from Paulo C?sar Pereira de Andrade 2010-05-12 13:15:36 PDT --- Created an attachment (id=35599) --> (https://bugs.freedesktop.org/attachment.cgi?id=35599) LIBGL_ALWAYS_INDIRECT=true glxinfo.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25997] libdrm builds programs only used during `make check` in `make all`
https://bugs.freedesktop.org/show_bug.cgi?id=25997 Kristian H?gsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Kristian H?gsberg 2010-05-12 10:57:44 PDT --- Fixed, thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 25881] drm.h , drm_mode.h and _drm.h use types defined stdint.h but do not include stdint.h
https://bugs.freedesktop.org/show_bug.cgi?id=25881 Kristian H?gsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Kristian H?gsberg 2010-05-12 10:44:21 PDT --- drm.h and drm_mode.h are fixed in git now. If the use of stdint in $driver_drm.h breaks anything, please file bugs against those drivers to get them to use __u32 etc. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26994] xf86-video-openchrome does not build against >=libdrm-2.4.17
https://bugs.freedesktop.org/show_bug.cgi?id=26994 Kristian H?gsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kristian H?gsberg 2010-05-12 10:42:18 PDT --- Fixed in git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DRM Error on Acer Aspire One
On Wed, May 12, 2010 at 8:56 AM, Andrew Morton wrote: > On Wed, 12 May 2010 08:51:05 +1000 > Dave Airlie wrote: > >> On Wed, May 12, 2010 at 8:32 AM, Andrew Morton >> wrote: >> > On Wed, 12 May 2010 08:22:49 +1000 >> > Dave Airlie wrote: >> > >> >> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson > >> chris-wilson.co.uk> wrote: >> >> > On Tue, 11 May 2010 12:10:01 -0700, Andrew Morton > >> > linux-foundation.org> wrote: >> >> >> On Tue, 11 May 2010 19:52:31 +0100 >> >> >> Chris Wilson wrote: >> >> >> >> >> >> > On Tue, 11 May 2010 11:35:55 -0400, Andrew Morton > >> >> > linux-foundation.org> wrote: >> >> >> > > No, io_mapping_map_atomic_wc() cannot be used from [soft]irq >> >> >> > > context: >> >> >> > > it hardwires use of KM_USER0. __I suggest that >> >> >> > > io_mapping_create_wc(), >> >> >> > > io_mapping_map_atomic_wc() etc be changed so that the caller >> >> >> > > passes in the >> >> >> > > KM_foo kmap slot index. >> >> >> > >> >> >> > Argh, sorry for the noise, read the mail in the wrong order. Thanks >> >> >> > for >> >> >> > the review. It would be sensible to go with your simpler patch whilst >> >> >> > io_mapping_map_atomic_wc() is improved. >> >> >> >> >> >> OK. __I'll be sending a bunch of fixes Linuswards in an hour or two. >> >> >> Should I include this? >> >> > >> >> > Yes. >> >> > >> >> > Acked-by: Chris Wilson >> >> > >> >> >> >> I'm not sure pushing this in at this point is a good idea, if I'm >> >> reading it correctly we've no idea what KM_IRQ is being used for, >> > >> > It's used for taking kmaps from IRQ contexts. >> > >> >> and >> >> this codepath is called from non-irq contexts just as much as irq >> >> contexts. >> > >> > That's fine. __As long as we do a local_irq_disable(), KM_IRQ0 can be >> > used from both irq- and non-irq contexts. __All we need to do is to >> > ensure that some interrupt cannot come along on this CPU and corrupt >> > the slot. >> >> I don't think we do that in a lot of places, and I'd rather not add >> that in to fix this problem at this point in the release cycle, as >> we've no idea what it might break/regress. > > What is "that"? ?The switch to irq-protected KM_IRQ0? ?That won't break > anything. > disabling local cpu irqs around all these kmap mappings. Dave.
DRM Error on Acer Aspire One
On Wed, May 12, 2010 at 8:32 AM, Andrew Morton wrote: > On Wed, 12 May 2010 08:22:49 +1000 > Dave Airlie wrote: > >> On Wed, May 12, 2010 at 5:57 AM, Chris Wilson >> wrote: >> > On Tue, 11 May 2010 12:10:01 -0700, Andrew Morton > > linux-foundation.org> wrote: >> >> On Tue, 11 May 2010 19:52:31 +0100 >> >> Chris Wilson wrote: >> >> >> >> > On Tue, 11 May 2010 11:35:55 -0400, Andrew Morton > >> > linux-foundation.org> wrote: >> >> > > No, io_mapping_map_atomic_wc() cannot be used from [soft]irq context: >> >> > > it hardwires use of KM_USER0. __I suggest that io_mapping_create_wc(), >> >> > > io_mapping_map_atomic_wc() etc be changed so that the caller passes >> >> > > in the >> >> > > KM_foo kmap slot index. >> >> > >> >> > Argh, sorry for the noise, read the mail in the wrong order. Thanks for >> >> > the review. It would be sensible to go with your simpler patch whilst >> >> > io_mapping_map_atomic_wc() is improved. >> >> >> >> OK. __I'll be sending a bunch of fixes Linuswards in an hour or two. >> >> Should I include this? >> > >> > Yes. >> > >> > Acked-by: Chris Wilson >> > >> >> I'm not sure pushing this in at this point is a good idea, if I'm >> reading it correctly we've no idea what KM_IRQ is being used for, > > It's used for taking kmaps from IRQ contexts. > >> and >> this codepath is called from non-irq contexts just as much as irq >> contexts. > > That's fine. ?As long as we do a local_irq_disable(), KM_IRQ0 can be > used from both irq- and non-irq contexts. ?All we need to do is to > ensure that some interrupt cannot come along on this CPU and corrupt > the slot. I don't think we do that in a lot of places, and I'd rather not add that in to fix this problem at this point in the release cycle, as we've no idea what it might break/regress. Its easier to just disable the hangcheck copy and try again for 2.6.35 with a workqueue or slow work. Dave > >> I'd rather we just backout the hangcheck stuff touching copies at all >> at this point, and try again doing it properly with a slow work or >> something for later. >> >> Dave. >
DRM Error on Acer Aspire One
On Wed, May 12, 2010 at 5:57 AM, Chris Wilson wrote: > On Tue, 11 May 2010 12:10:01 -0700, Andrew Morton linux-foundation.org> wrote: >> On Tue, 11 May 2010 19:52:31 +0100 >> Chris Wilson wrote: >> >> > On Tue, 11 May 2010 11:35:55 -0400, Andrew Morton > > linux-foundation.org> wrote: >> > > No, io_mapping_map_atomic_wc() cannot be used from [soft]irq context: >> > > it hardwires use of KM_USER0. ?I suggest that io_mapping_create_wc(), >> > > io_mapping_map_atomic_wc() etc be changed so that the caller passes in >> > > the >> > > KM_foo kmap slot index. >> > >> > Argh, sorry for the noise, read the mail in the wrong order. Thanks for >> > the review. It would be sensible to go with your simpler patch whilst >> > io_mapping_map_atomic_wc() is improved. >> >> OK. ?I'll be sending a bunch of fixes Linuswards in an hour or two. >> Should I include this? > > Yes. > > Acked-by: Chris Wilson > I'm not sure pushing this in at this point is a good idea, if I'm reading it correctly we've no idea what KM_IRQ is being used for, and this codepath is called from non-irq contexts just as much as irq contexts. I'd rather we just backout the hangcheck stuff touching copies at all at this point, and try again doing it properly with a slow work or something for later. Dave.
No subject
started with the kernel configuration for Arch Linux, but ended up removing many modules as otherwise that 350 MHz Pentium II needed 6 hours to compile. I updated the system before I tried the patch. These are the current versions for Arch Linux: nouveau-drm 0.0.16_20100313-2 xf86-video-nouveau 0.0.15_git20100314-1 kernel26 2.6.33.3-2 Here is the tail of Xorg.0.log: (II) Module nouveau: vendor="X.Org Foundation" compiled for 1.7.5.902, module version = 0.0.15 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) NOUVEAU driver (II) NOUVEAU driver for NVIDIA chipset families : RIVA TNT(NV04) RIVA TNT2 (NV05) GeForce 256 (NV10) GeForce 2 (NV11, NV15) GeForce 4MX (NV17, NV18) GeForce 3 (NV20) GeForce 4Ti (NV25, NV28) GeForce FX (NV3x) GeForce 6 (NV4x) GeForce 7 (G7x) GeForce 8 (G8x) (II) Primary Device is: PCI 01 at 00:00:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (EE) [drm] failed to open device (EE) No devices detected. Fatal server error: no screens found -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28069] maniadrive - smooth play with LIBGL_ALWAYS_INDIRECT=true, (almost) unplayable otherwise
https://bugs.freedesktop.org/show_bug.cgi?id=28069 --- Comment #1 from Michel D?nzer 2010-05-12 04:50:42 PDT --- Please attach (as opposed to paste) the output of glxinfo with and without LIBGL_ALWAYS_INDIRECT. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris, On Wed, May 12, 2010 at 1:35 AM, Jaswinder Singh Rajput wrote: > Hello Chris, > > On Wed, May 12, 2010 at 1:23 AM, Chris Wilson > wrote: >> On Wed, 12 May 2010 01:08:23 +0530, Jaswinder Singh Rajput > at gmail.com> wrote: >>> Hello Chris and Andrew, >>> >>> I did further testing and noticed that this patch fixes the boot >>> errors and warnings and I get the XWindows. >>> >>> But XWindows freezes after some time. >> >> The BUG you were hitting before is on the error collection path which >> presumably is still being triggered during boot by a GPU error. > > No, I am not getting any bug with your patch. > > dmesg with your patch : > http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634-rc7-chris.txt > I did more testing. And test pass 80% of time. I get the bugs with cold boot : [ 40.090295] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 40.090318] [ cut here ] [ 40.090338] WARNING: at mm/highmem.c:453 debug_kmap_atomic+0xa9/0x11e() [ 40.090345] Hardware name: Aspire one [ 40.090351] Modules linked in: nf_conntrack_ftp ath9k ath9k_common battery ath9k_hw [last unloaded: scsi_wait_scan] [ 40.090378] Pid: 0, comm: swapper Not tainted 2.6.34-rc7-netbook #8 [ 40.090385] Call Trace: [ 40.090402] [] warn_slowpath_common+0x65/0x7c [ 40.090415] [] ? debug_kmap_atomic+0xa9/0x11e [ 40.090428] [] warn_slowpath_null+0xd/0x10 [ 40.090440] [] debug_kmap_atomic+0xa9/0x11e [ 40.090454] [] kmap_atomic_prot_pfn+0x1d/0x5e [ 40.090465] [] iomap_atomic_prot_pfn+0x23/0x26 [ 40.090479] [] i915_error_object_create+0x110/0x17c [ 40.090492] [] i915_handle_error+0x4a2/0x9ba [ 40.090506] [] i915_hangcheck_elapsed+0x9f/0xdf [ 40.090518] [] run_timer_softirq+0x1c9/0x269 [ 40.090531] [] ? i915_hangcheck_elapsed+0x0/0xdf [ 40.090543] [] __do_softirq+0xc6/0x186 [ 40.090553] [] do_softirq+0x26/0x2b [ 40.090564] [] irq_exit+0x29/0x66 [ 40.090576] [] smp_apic_timer_interrupt+0x6e/0x7c [ 40.090591] [] apic_timer_interrupt+0x2a/0x30 [ 40.090605] [] ? ftrace_raw_event_signal_generate+0x6d/0xd4 [ 40.090618] [] ? acpi_idle_enter_simple+0x13b/0x168 [ 40.090633] [] cpuidle_idle_call+0x6b/0xda [ 40.090645] [] cpu_idle+0x44/0x74 [ 40.090657] [] start_secondary+0x1b2/0x1b7 [ 40.090666] ---[ end trace 5e47c395a6f397dc ]--- [ 40.090862] [ cut here ] dmesg with this patch with cold boot : http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634-rc7-chris-cold.txt Thanks, -- Jaswinder Singh.
[Bug 27211] endless PROTECTION_FAULT logs, Nouveau drm, TNT card
https://bugs.freedesktop.org/show_bug.cgi?id=27211 --- Comment #8 from Xavier 2010-05-12 02:45:17 PDT --- I am not sure I understood, but if you built a custom kernel, you need to rebuild the external modules for your custom kernel : nouveau-drm 0.0.16_20100313-2 Because this package only provides modules built for Arch kernel. Check list of installed files with pacman -Ql nouveau-drm. It's also in nouveau-drm (external modules) that you need to apply the patch. Did you apply the patch to a 2.6.33 kernel, and were trying to use the nouveau module shipped with the kernel ? If so, that will give you abi 0.0.15. So you also need to downgrade both libdrm and xf86-video-nouveau to the previous version to match the abi. Imo the simplest way is to just follow the instructions here to fetch the kernel from git, then apply mwk patch with git am, then build : http://nouveau.freedesktop.org/wiki/InstallDRM If you insist on using a package, you could try : http://aur.archlinux.org/packages.php?ID=30158 By getting it from git, you will have nouveau 0.0.16 which will work with your current libdrm and xf86-video-nouveau. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris, On Wed, May 12, 2010 at 1:23 AM, Chris Wilson wrote: > On Wed, 12 May 2010 01:08:23 +0530, Jaswinder Singh Rajput gmail.com> wrote: >> Hello Chris and Andrew, >> >> I did further testing and noticed that this patch fixes the boot >> errors and warnings and I get the XWindows. >> >> But XWindows freezes after some time. > > The BUG you were hitting before is on the error collection path which > presumably is still being triggered during boot by a GPU error. No, I am not getting any bug with your patch. dmesg with your patch : http://userweb.kernel.org/~jaswinder/acer_netbook/dmesg_2634-rc7-chris.txt > Can you check to see if /sys/kernel/debug/dri/0/i915_error_state has > recorded anything? No. > And if not, wait until it freezes and then please file > a bug report at bugs.freedesktop.org with the i915_error_state, Xorg.0.log > and dmesg. > Ok. Thanks, -- Jaswinder Singh.
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris and Andrew,
I did further testing and noticed that this patch fixes the boot
errors and warnings and I get the XWindows.
But XWindows freezes after some time.
Thanks,
--
Jaswinder Singh.
On Wed, May 12, 2010 at 12:52 AM, Jaswinder Singh Rajput
wrote:
> Hello Chris and Andrew,
>
> On Tue, May 11, 2010 at 11:52 PM, Chris Wilson
> wrote:
>> Directly read the GTT mapping for the contents of the batch buffers
>> rather than relying on possibly stale CPU caches. Also for completeness
>> scan the flushing/inactive lists for the current buffers - we are
>> collecting error state after all.
>>
>> Signed-off-by: Chris Wilson
>
> Yes, I have tested this patch.
>
> I booted 3 times, and this patch fixes the DRM as well as softirq
> warnings and I am getting Xwindows with this patch.
>
> I am still doing more testing.
>
> Thanks,
> --
> Jaswinder Singh.
>> ---
>> ?drivers/gpu/drm/i915/i915_irq.c | ? 64
>> ++
>> ?1 files changed, 57 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 87113da..14301a4 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -441,9 +441,11 @@ static struct drm_i915_error_object *
>> ?i915_error_object_create(struct drm_device *dev,
>> ? ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *src)
>> ?{
>> + ? ? ? drm_i915_private_t *dev_priv = dev->dev_private;
>> ? ? ? ?struct drm_i915_error_object *dst;
>> ? ? ? ?struct drm_i915_gem_object *src_priv;
>> ? ? ? ?int page, page_count;
>> + ? ? ? u32 reloc_offset;
>>
>> ? ? ? ?if (src == NULL)
>> ? ? ? ? ? ? ? ?return NULL;
>> @@ -458,14 +460,23 @@ i915_error_object_create(struct drm_device *dev,
>> ? ? ? ?if (dst == NULL)
>> ? ? ? ? ? ? ? ?return NULL;
>>
>> + ? ? ? reloc_offset = src_priv->gtt_offset;
>> ? ? ? ?for (page = 0; page < page_count; page++) {
>> - ? ? ? ? ? ? ? void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
>> + ? ? ? ? ? ? ? void __iomem *s;
>> + ? ? ? ? ? ? ? void *d;
>> +
>> + ? ? ? ? ? ? ? d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
>> ? ? ? ? ? ? ? ?if (d == NULL)
>> ? ? ? ? ? ? ? ? ? ? ? ?goto unwind;
>> - ? ? ? ? ? ? ? s = kmap_atomic(src_priv->pages[page], KM_USER0);
>> - ? ? ? ? ? ? ? memcpy(d, s, PAGE_SIZE);
>> - ? ? ? ? ? ? ? kunmap_atomic(s, KM_USER0);
>> +
>> + ? ? ? ? ? ? ? s = io_mapping_map_atomic_wc(dev_priv->mm.gtt_mapping,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?reloc_offset);
>> + ? ? ? ? ? ? ? memcpy_fromio(d, s, PAGE_SIZE);
>> + ? ? ? ? ? ? ? io_mapping_unmap_atomic(s);
>> +
>> ? ? ? ? ? ? ? ?dst->pages[page] = d;
>> +
>> + ? ? ? ? ? ? ? reloc_offset += PAGE_SIZE;
>> ? ? ? ?}
>> ? ? ? ?dst->page_count = page_count;
>> ? ? ? ?dst->gtt_offset = src_priv->gtt_offset;
>> @@ -621,18 +632,57 @@ static void i915_capture_error_state(struct drm_device
>> *dev)
>>
>> ? ? ? ? ? ? ? ?if (batchbuffer[1] == NULL &&
>> ? ? ? ? ? ? ? ? ? ?error->acthd >= obj_priv->gtt_offset &&
>> - ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size &&
>> - ? ? ? ? ? ? ? ? ? batchbuffer[0] != obj)
>> + ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
>> ? ? ? ? ? ? ? ? ? ? ? ?batchbuffer[1] = obj;
>>
>> ? ? ? ? ? ? ? ?count++;
>> ? ? ? ?}
>> + ? ? ? /* Scan the other lists for completeness for those bizarre errors. */
>> + ? ? ? if (batchbuffer[0] == NULL || batchbuffer[1] == NULL) {
>> + ? ? ? ? ? ? ? list_for_each_entry(obj_priv, _priv->mm.flushing_list,
>> list) {
>> + ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *obj = obj_priv->obj;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] == NULL &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr >= obj_priv->gtt_offset &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr < obj_priv->gtt_offset + obj->size)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[0] = obj;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[1] == NULL &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd >= obj_priv->gtt_offset &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[1] = obj;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] && batchbuffer[1])
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
>> + ? ? ? ? ? ? ? }
>> + ? ? ? }
>> + ? ? ? if (batchbuffer[0] == NULL || batchbuffer[1] == NULL) {
>> + ? ? ? ? ? ? ? list_for_each_entry(obj_priv, _priv->mm.inactive_list,
>> list) {
>> + ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *obj = obj_priv->obj;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] == NULL &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr >= obj_priv->gtt_offset &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr < obj_priv->gtt_offset + obj->size)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[0] = obj;
>> +
>> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[1] == NULL &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd >= obj_priv->gtt_offset &&
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[1] = obj;
>> +
>> + ?
[PATCH] drm/i915: Record error batch buffers using iomem
Hello Chris and Andrew,
On Tue, May 11, 2010 at 11:52 PM, Chris Wilson
wrote:
> Directly read the GTT mapping for the contents of the batch buffers
> rather than relying on possibly stale CPU caches. Also for completeness
> scan the flushing/inactive lists for the current buffers - we are
> collecting error state after all.
>
> Signed-off-by: Chris Wilson
Yes, I have tested this patch.
I booted 3 times, and this patch fixes the DRM as well as softirq
warnings and I am getting Xwindows with this patch.
I am still doing more testing.
Thanks,
--
Jaswinder Singh.
> ---
> ?drivers/gpu/drm/i915/i915_irq.c | ? 64 ++
> ?1 files changed, 57 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 87113da..14301a4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -441,9 +441,11 @@ static struct drm_i915_error_object *
> ?i915_error_object_create(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *src)
> ?{
> + ? ? ? drm_i915_private_t *dev_priv = dev->dev_private;
> ? ? ? ?struct drm_i915_error_object *dst;
> ? ? ? ?struct drm_i915_gem_object *src_priv;
> ? ? ? ?int page, page_count;
> + ? ? ? u32 reloc_offset;
>
> ? ? ? ?if (src == NULL)
> ? ? ? ? ? ? ? ?return NULL;
> @@ -458,14 +460,23 @@ i915_error_object_create(struct drm_device *dev,
> ? ? ? ?if (dst == NULL)
> ? ? ? ? ? ? ? ?return NULL;
>
> + ? ? ? reloc_offset = src_priv->gtt_offset;
> ? ? ? ?for (page = 0; page < page_count; page++) {
> - ? ? ? ? ? ? ? void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> + ? ? ? ? ? ? ? void __iomem *s;
> + ? ? ? ? ? ? ? void *d;
> +
> + ? ? ? ? ? ? ? d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> ? ? ? ? ? ? ? ?if (d == NULL)
> ? ? ? ? ? ? ? ? ? ? ? ?goto unwind;
> - ? ? ? ? ? ? ? s = kmap_atomic(src_priv->pages[page], KM_USER0);
> - ? ? ? ? ? ? ? memcpy(d, s, PAGE_SIZE);
> - ? ? ? ? ? ? ? kunmap_atomic(s, KM_USER0);
> +
> + ? ? ? ? ? ? ? s = io_mapping_map_atomic_wc(dev_priv->mm.gtt_mapping,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?reloc_offset);
> + ? ? ? ? ? ? ? memcpy_fromio(d, s, PAGE_SIZE);
> + ? ? ? ? ? ? ? io_mapping_unmap_atomic(s);
> +
> ? ? ? ? ? ? ? ?dst->pages[page] = d;
> +
> + ? ? ? ? ? ? ? reloc_offset += PAGE_SIZE;
> ? ? ? ?}
> ? ? ? ?dst->page_count = page_count;
> ? ? ? ?dst->gtt_offset = src_priv->gtt_offset;
> @@ -621,18 +632,57 @@ static void i915_capture_error_state(struct drm_device
> *dev)
>
> ? ? ? ? ? ? ? ?if (batchbuffer[1] == NULL &&
> ? ? ? ? ? ? ? ? ? ?error->acthd >= obj_priv->gtt_offset &&
> - ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size &&
> - ? ? ? ? ? ? ? ? ? batchbuffer[0] != obj)
> + ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
> ? ? ? ? ? ? ? ? ? ? ? ?batchbuffer[1] = obj;
>
> ? ? ? ? ? ? ? ?count++;
> ? ? ? ?}
> + ? ? ? /* Scan the other lists for completeness for those bizarre errors. */
> + ? ? ? if (batchbuffer[0] == NULL || batchbuffer[1] == NULL) {
> + ? ? ? ? ? ? ? list_for_each_entry(obj_priv, _priv->mm.flushing_list,
> list) {
> + ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *obj = obj_priv->obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] == NULL &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr >= obj_priv->gtt_offset &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr < obj_priv->gtt_offset + obj->size)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[0] = obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[1] == NULL &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd >= obj_priv->gtt_offset &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[1] = obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] && batchbuffer[1])
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> + ? ? ? if (batchbuffer[0] == NULL || batchbuffer[1] == NULL) {
> + ? ? ? ? ? ? ? list_for_each_entry(obj_priv, _priv->mm.inactive_list,
> list) {
> + ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *obj = obj_priv->obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] == NULL &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr >= obj_priv->gtt_offset &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? bbaddr < obj_priv->gtt_offset + obj->size)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[0] = obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[1] == NULL &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd >= obj_priv->gtt_offset &&
> + ? ? ? ? ? ? ? ? ? ? ? ? ? error->acthd < obj_priv->gtt_offset + obj->size)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? batchbuffer[1] = obj;
> +
> + ? ? ? ? ? ? ? ? ? ? ? if (batchbuffer[0] && batchbuffer[1])
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
>
> ? ? ? ?/* We need to copy these to an anonymous buffer as the simplest
> ? ? ? ? * method to avoid being overwritten by userpace.
> ? ? ? ? */
> ? ? ? ?error->batchbuffer[0] = i915_error_object_create(dev, batchbuffer[0]);
> - ? ? ? error->batchbuffer[1] =
DRM Error on Acer Aspire One
Hello Andrew,
On Tue, May 11, 2010 at 8:18 PM, Andrew Morton
wrote:
> On Tue, 11 May 2010 17:10:53 +0100 Chris Wilson
> wrote:
>
>> On Tue, 11 May 2010 20:30:07 +0530, Jaswinder Singh Rajput > at gmail.com> wrote:
>> > Hello,
>> >
>> > With latest git kernel, I am getting following DRM error and not
>> > getting XWindows :
>>
>> [snip]
>>
>> Hmm, there are still patches for capturing error state that haven't gone
>> upstream, shame on me.
>>
>> That error is a secondary issue to the GPU hang that is being reported. If
>> it is a regression caused by a kernel update it would be very useful if
>> you could bisect to the erroneous commit.
>
> It helps if one reads the code and the trace...
>
> i915_error_object_create() is using KM_USER0 from softirq context.
> That's a bug, and a pretty serious one. ?If some innocent civilian is
> writing highmem data to disk and this timer interrupt fires and trashes
> his KM_USER0 slot, the disk contents will be corrupted.
>
> Something like this...
>
> --- a/drivers/gpu/drm/i915/i915_irq.c~a
> +++ a/drivers/gpu/drm/i915/i915_irq.c
> @@ -456,11 +456,15 @@ i915_error_object_create(struct drm_devi
>
> ? ? ? ?for (page = 0; page < page_count; page++) {
> ? ? ? ? ? ? ? ?void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> + ? ? ? ? ? ? ? unsigned long flags;
> +
> ? ? ? ? ? ? ? ?if (d == NULL)
> ? ? ? ? ? ? ? ? ? ? ? ?goto unwind;
> - ? ? ? ? ? ? ? s = kmap_atomic(src_priv->pages[page], KM_USER0);
> + ? ? ? ? ? ? ? local_irq_save(flags);
> + ? ? ? ? ? ? ? s = kmap_atomic(src_priv->pages[page], KM_IRQ0);
> ? ? ? ? ? ? ? ?memcpy(d, s, PAGE_SIZE);
> - ? ? ? ? ? ? ? kunmap_atomic(s, KM_USER0);
> + ? ? ? ? ? ? ? kunmap_atomic(s, KM_IRQ0);
> + ? ? ? ? ? ? ? local_irq_restore(flags);
> ? ? ? ? ? ? ? ?dst->pages[page] = d;
> ? ? ? ?}
> ? ? ? ?dst->page_count = page_count;
> _
>
> Please let's get a tested fix for this into 2.6.34.
>
I tested your patch with latest linus git and it works, it fixes the
softirq error.
Now I am only getting DRM errors :
[ 42.276059] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
elapsed... GPU hung
[ 42.276398] render error detected, EIR: 0x
[ 42.276460] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request
returns -5 (awaiting 18 at 17)
Thanks,
--
Jaswinder Singh.
DRM Error on Acer Aspire One
On Wed, 12 May 2010 08:22:49 +1000, Dave Airlie wrote: > I'd rather we just backout the hangcheck stuff touching copies at all > at this point, and try again doing it properly with a slow work or > something for later.
[Bug 27211] endless PROTECTION_FAULT logs, Nouveau drm, TNT card
https://bugs.freedesktop.org/show_bug.cgi?id=27211 --- Comment #7 from Brent 2010-05-11 23:35:47 PDT --- Tried the above patch against the stock 2.6.33.3 kernel, with acceleration turned on, and got "(EE) [drm] failed to open device" in Xorg.0.log. But it did give me a 80x50 text console, so it seems the framebuffer works. And it is no longer filling the logs with error messages. So that's something.
DRM Error on Acer Aspire One
Hello Chris, On Tue, May 11, 2010 at 9:40 PM, Chris Wilson wrote: > On Tue, 11 May 2010 20:30:07 +0530, Jaswinder Singh Rajput gmail.com> wrote: >> Hello, >> >> With latest git kernel, I am getting following DRM error and not >> getting XWindows : > > [snip] > > Hmm, there are still patches for capturing error state that haven't gone > upstream, shame on me. > > That error is a secondary issue to the GPU hang that is being reported. If > it is a regression caused by a kernel update it would be very useful if > you could bisect to the erroneous commit. > Earlier I was using Moblin, I switched to Fedora and start getting this error. I have also tested different kernel versions but getting same error, so I do not think this is a regression. moblin dmesg : http://userweb.kernel.org/~jaswinder/moblin/dmesg-moblin_2633rc5.txt Thanks, -- Jaswinder Singh.
