[Bug 48424] Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Kenneth Graunke changed: What|Removed |Added Priority|medium |low --- Comment #1 from Kenneth Graunke 2012-04-07 12:55:28 PDT --- Thanks for running this! Looks like a neat tool. Here's a false positive: Logic errorAssigned value is garbage or undefinedmesa /drivers /dri /i965 /brw_vec4_visitor.cpp13833 or: report-3rwkCp.html#EndPath -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 48422] Radeon KMS fails on Radeon X850XT (R480) graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=48422 --- Comment #1 from Jonathan Nieder 2012-04-07 12:16:24 PDT --- Context: http://bugs.debian.org/667799 which mentions that the system is still usable using ssh after the failed modeset. Looks like the log with drm.debug=0x6 overflowed the kernel buffer so it's cut off at the beginning. Does /var/log/dmesg have more? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 48424] New: Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Bug #: 48424 Summary: Fix warnings/errors reported by clang's scan-build tool Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) URL: https://gitorious.org/jobermayr/scan-build-mesa OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev at lists.freedesktop.org ReportedBy: johannesobermayr at gmx.de CC: dri-devel at lists.freedesktop.org, nouveau at lists.freedesktop.org https://gitorious.org/jobermayr/scan-build-mesa ~ 8 MB to download, 680 MB on disk. Please report false positives here. I will forward them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 48422] New: Radeon KMS fails on Radeon X850XT (R480) graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=48422 Bug #: 48422 Summary: Radeon KMS fails on Radeon X850XT (R480) graphics card Classification: Unclassified Product: DRI Version: XOrg 6.7.0 Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: mike at coruscant.demon.co.uk Created attachment 59628 --> https://bugs.freedesktop.org/attachment.cgi?id=59628 Dmesg output from boot Video output fails completely (apparently due to a KMS regression) on all kernels >= 3.2, rendering the system unusable as a desktop. Access via SSH over network is unaffected. Steps to reproduce: Boot any recent kernel. This has been encountered with Debian, and the kernel versions in question are:- linux-image-3.0.0-2-amd64 3.0.0-5 functions as expected linux-image-3.2.0-1-amd64 3.2.7-1 fails linux-image-3.2.0-2-amd64 3.2.13-1 fails linux-image-3.3.0-trunk-amd64 3.3-1~experimental.1 fails Expected behaviour:- At system boot, initial kernel output appears on the VGA console, until the drm driver is loaded, when the kernel switches the output font and resolution. Boot continues until a subsequent switch (I believe when the kernel attempts to modeswitch the card), at which point the font visibly changes at this point and boot continues, with further console output until the X desktop appears. Actual behaviour with failing kernels:- Boot starts normally until the modeswitch happens, at which point video output ceases, and the monitor shows no signal on the DVI input. Graphics hardware details from lspci is:- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI R480 [Radeon X850XT (PCIE)] (Primary) 01:00.1 Display controller: Advanced Micro Devices [AMD] nee ATI R480 [Radeon X850XT (PCIE)] (Secondary) Attached file is dmesg output from booting the 3.3 kernel with drm.debug=0x6 passed as a kernel parameter. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46713] HDMI audio played back at a wrong rate
https://bugs.freedesktop.org/show_bug.cgi?id=46713 --- Comment #25 from Vincenzov 2012-04-07 09:51:19 PDT --- Hi i can't patch a kernel 3.4.0-rc1 i can't patch a kernel 3.3.0 :-( error radeon display -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
?? iPad?? ??
2012. 4. 6. ?? 4:43 Ville Syrj?l? ??:
> On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
>> Hi Ville,
>>
>>> -Original Message-
>>> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
>>> Sent: Friday, April 06, 2012 3:14 AM
>>> To: airlied at redhat.com
>>> Cc: inki.dae at samsung.com; kyungmin.park at samsung.com; dri-
>>> devel at lists.freedesktop.org; Seung-Woo Kim
>>> Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
>>> add multi plane formats
>>>
>>> On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrj?l? wrote:
On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
> Multi buffer plane pixel formats are added as like kernel header.
>
> Signed-off-by: Seung-Woo Kim
> ---
> include/drm/drm_fourcc.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0..7cfd95a 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -107,6 +107,10 @@
> #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /*
>>> 2x1 subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
>>> 2x1 subsampled Cb:Cr plane */
>
> +/* 2 non contiguous plane YCbCr */
> +#define DRM_FORMAT_NV12Mfourcc_code('N', 'M', '1', '2') /* 2x2
>>> subsampled Cr:Cb plane */
NAK. DRM_FORMAT_NV12 handles this just fine.
>>>
>>> And I just realized that I was already too late with my NAK since this a
>>> libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
>>> via some backdoor without review. Sigh.
>>>
>>
>> We had already requested review for it. for this you can refer to link
>> below:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
>
> I see. I couldn't find it in my work mailbox for some reason, and I
> don't remember having seen the patch before. I suppose I just missed it
> due to Christmas vacations, and was too blind to see it in my mailbox.
> Also google decicded to filter my search results too much, so I didn't
> spot it via the web archives either. I'm sorry for the false accusation.
>
>>> So they're now in Linus's tree. But looks like format_check() was never
>>> updated to accept them, so there's no way anyone could actually be using
>>> them. So Dave, can we still remove them from the kernel header?
>>>
>>
>> Yes, right. these formats aren't used for any SoCs except Exynos series yet
>> but just we are first. I think they should be added because anyone may use
>> them someday at least possible.
>
> Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
> in adding it (similarly for YUV420M vs. YUV420).
>
but with this way, user and device driver should understand NV12M format and
how gem handles should send to driver and also how the driver should decide
whether these handles mean NV12M or NV12. I think these things are unnecessary
codes. with such theory, maybe current some fourcc formats couldn't be removed
because we can identify desired format if we add some codes for it. as you
mentioned, it's important to avoid such duplicated formats but also to consider
user and device driver. so I think it's not good for user and driver should
understand and decide them. Please give me your opinion.
thanks,
Inki Dae
> --
> Ville Syrj?l?
> syrjala at sci.fi
> http://www.sci.fi/~syrjala/
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48305] llpp gets segfault in r600g_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=48305 --- Comment #9 from myxol 2012-04-07 07:28:42 PDT --- I tried 3 gcc versions. Flags: -march=native -O2 -ftree-vectorize -ggdb -pipe 4.4.7 - build fails 4.5.3 - original bugreport 4.6.2 - same problem as with 4.5.3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 48424] Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Johannes Obermayr changed: What|Removed |Added See Also||http://llvm.org/bugs/show_b ||ug.cgi?id=12491 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 46713] HDMI audio played back at a wrong rate
https://bugs.freedesktop.org/show_bug.cgi?id=46713 --- Comment #26 from Vincenzov 2012-04-07 11:16:54 UTC --- Error when compiling. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915_driver_irq_handler: irq 42: nobody cared [generic IRQ handling broken?]
On Fri, 6 Apr 2012, Jiri Slaby wrote: > On 03/30/2012 02:24 PM, Chris Wilson wrote: > > On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote: > >> On 03/30/2012 12:45 PM, Chris Wilson wrote: > >>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby wrote: > I don't know what to dump more, because iir is obviously zero too. What > other sources of interrupts are on the (G33) chip? > >>> > >>> IIR is the master interrupt, with chained secondary interrupt statuses. > >>> If IIR is 0, the interrupt wasn't raised by the GPU. > >> > >> This does not make sense, the handler does something different. Even if > >> IIR is 0, it still takes a look at pipe stats. > > > > That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close > > a race where the pipestat triggered an interrupt after we processed the > > secondary registers and before reseting the primary. > > > > But the basic premise that we should only enter the interrupt handler > > with IIR!=0 holds (presuming non-shared interrupt lines such as MSI). > > Ok, this behavior is definitely new. I get several "nobody cared" about > this interrupt a week. This never used to happen. And something weird > emerges in /proc/interrupts when this happens: > 42:10032921212890 PCI-MSI-edge ???s::00:02.0 > instead of > 42:10067151218472 PCI-MSI-edge i915 at pci::00:02.0 > > It very looks like the generic IRQ handling code is broken. Like it > frees/corrupts irq_desc and ... OMG, your problem analyzing skills are amazing. If irq_desc would have been freed, then it wouldn't print the numbers and the irq type. And irq_desc is not corrupted either, otherwise the whole thing would explode in your face. The printout of the name is done via action->name. The irq action merily holds a pointer to the device name string, which is handed over with request_irq. So you are saying that the core code corrupts the memory which was handed in via a pointer by the driver? So now that's really an amazing core feature: It corrupts the memory with weird characters and still maintains the PCI bus number correct. So it not only corrupts memory it also moves the PCI part of the string a few characters to the end. If the pointer in the irq action would have been corrupted, then you would see a few weird characters and then the full string, not a random thing which is half correct and shifted by a few bytes. The pointer which is handed in is dev->devname, which gets allocated and filled in drm_pci_set_busid(). > ... then as well calls random handlers. Which random handlers would be called? The core code only calls handlers which are associated to an particular interrupt. And only when that particular interrupt is raised and not because the CPU pulls interrupt events out of thin air. And it calls the stupid i915 handler and not something else, otherwise you would not observe the IIR=0 printk or whatever you put there for debugging. > Suspend/resume cycle helps in this case and "i915 at pci::00:02.0" is > back in /proc/interrupts as can be seen above. That's proving what? That the irq core code magically restores the correct string, right? And probably it stops calling random handlers as well. Brilliant deduction. You know what? suspend calls free_irq() via i915_drm_freeze() -> drm_irq_uninstall() and the resume code calls request_irq() again. free_irq() removes the action and request_irq installs it fresh. So now the interesting part is that free_irq() checks the dev_id cookie for a match, which is also stored in the irq action. So we are dealing with a magic corrupt only action->name and action->handler problem. Pretty realistic. What the heck makes you assume that the irq core code is broken? Core code, which works on a gazillion of machines and different device drivers and does not corrupt anything except that i915 thingy? Come on, you need to provide better evidence than weird ass guessing. If you're still convinced that the irq core is messing with your device string, then simply hand in a NULL pointer when requesting the interrupt. That will make the core code explode nicely when it tries to modify that memory. Thanks, tglx
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #67 from Rafael ?vila de Esp?ndola 2012-04-06 17:22:46 PDT --- Created attachment 59612 --> https://bugs.freedesktop.org/attachment.cgi?id=59612 dmesg with bios booting and kernel 3.3.0 Results are similar to 3.2 :-( This is an imac 11,1. Let me know if there any additional debugging I could do. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915_driver_irq_handler: irq 42: nobody cared [generic IRQ handling broken?]
On 03/30/2012 02:24 PM, Chris Wilson wrote: > On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby wrote: >> On 03/30/2012 12:45 PM, Chris Wilson wrote: >>> On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby wrote: I don't know what to dump more, because iir is obviously zero too. What other sources of interrupts are on the (G33) chip? >>> >>> IIR is the master interrupt, with chained secondary interrupt statuses. >>> If IIR is 0, the interrupt wasn't raised by the GPU. >> >> This does not make sense, the handler does something different. Even if >> IIR is 0, it still takes a look at pipe stats. > > That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close > a race where the pipestat triggered an interrupt after we processed the > secondary registers and before reseting the primary. > > But the basic premise that we should only enter the interrupt handler > with IIR!=0 holds (presuming non-shared interrupt lines such as MSI). Ok, this behavior is definitely new. I get several "nobody cared" about this interrupt a week. This never used to happen. And something weird emerges in /proc/interrupts when this happens: 42:10032921212890 PCI-MSI-edge ?s::00:02.0 instead of 42:10067151218472 PCI-MSI-edge i915 at pci::00:02.0 It very looks like the generic IRQ handling code is broken. Like it frees/corrupts irq_desc and then as well calls random handlers. Suspend/resume cycle helps in this case and "i915 at pci::00:02.0" is back in /proc/interrupts as can be seen above. Running 3.3.0-next-20120326_64+ now. thanks, -- js suse labs
Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
나의 iPad에서 보냄
2012. 4. 6. 오후 4:43 Ville Syrjälä syrj...@sci.fi 작성:
On Fri, Apr 06, 2012 at 03:05:36PM +0900, Inki Dae wrote:
Hi Ville,
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Friday, April 06, 2012 3:14 AM
To: airl...@redhat.com
Cc: inki@samsung.com; kyungmin.p...@samsung.com; dri-
de...@lists.freedesktop.org; Seung-Woo Kim
Subject: Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to
add multi plane formats
On Fri, Mar 30, 2012 at 01:12:58PM +0300, Ville Syrjälä wrote:
On Fri, Mar 30, 2012 at 11:54:50AM +0900, Seung-Woo Kim wrote:
Multi buffer plane pixel formats are added as like kernel header.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
---
include/drm/drm_fourcc.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 85facb0..7cfd95a 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -107,6 +107,10 @@
#define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /*
2x1 subsampled Cr:Cb plane */
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
2x1 subsampled Cb:Cr plane */
+/* 2 non contiguous plane YCbCr */
+#define DRM_FORMAT_NV12Mfourcc_code('N', 'M', '1', '2') /* 2x2
subsampled Cr:Cb plane */
NAK. DRM_FORMAT_NV12 handles this just fine.
And I just realized that I was already too late with my NAK since this a
libdrm patch. Apparently the kernel drm_fourcc.h changes were snuck in
via some backdoor without review. Sigh.
We had already requested review for it. for this you can refer to link
below:
http://lists.freedesktop.org/archives/dri-devel/2011-December/017654.html
I see. I couldn't find it in my work mailbox for some reason, and I
don't remember having seen the patch before. I suppose I just missed it
due to Christmas vacations, and was too blind to see it in my mailbox.
Also google decicded to filter my search results too much, so I didn't
spot it via the web archives either. I'm sorry for the false accusation.
So they're now in Linus's tree. But looks like format_check() was never
updated to accept them, so there's no way anyone could actually be using
them. So Dave, can we still remove them from the kernel header?
Yes, right. these formats aren't used for any SoCs except Exynos series yet
but just we are first. I think they should be added because anyone may use
them someday at least possible.
Since DRM_FORMAT_NV12M is _identical_ to DRM_FORMAT_NV12, I see no point
in adding it (similarly for YUV420M vs. YUV420).
but with this way, user and device driver should understand NV12M format and
how gem handles should send to driver and also how the driver should decide
whether these handles mean NV12M or NV12. I think these things are unnecessary
codes. with such theory, maybe current some fourcc formats couldn't be removed
because we can identify desired format if we add some codes for it. as you
mentioned, it's important to avoid such duplicated formats but also to consider
user and device driver. so I think it's not good for user and driver should
understand and decide them. Please give me your opinion.
thanks,
Inki Dae
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: update drm/drm_fourcc.h from kernel to add multi plane formats
On 03/30/2012 01:09 PM, Marcus Lorentzon wrote:
On 03/30/2012 12:12 PM, Ville Syrjälä wrote:
+#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
subsampled Cr:Cb plane 64x32 macroblocks */
This one is more difficult. Until now tiling was always handled in
driver specific manner. OTOH if this format is really supported by
different devices from multiple vendors, then it would probably
make sense to add it as a standard format.
What about adding a DRM_FORMAT_PRIV_NV12MT and force vendor to add
detailed documentation about this new format. Because if the format is
not defined and documented, how will we ever discover if vendors have
similar formats? And if we document all these MB formats everyone
uses, then maybe we can get HW vendors to unify on a de facto standard.
It would be nice to have an efficient format supported by everyone,
instead of having to fallback to old linear formats every time you
interact with another device.
Just for the record, documentation of this tiled macro-block format
can be found here:
http://linuxtv.org/downloads/v4l-dvb-apis/re27.html
--
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915_driver_irq_handler: irq 42: nobody cared [generic IRQ handling broken?]
On Fri, 6 Apr 2012, Jiri Slaby wrote: On 03/30/2012 02:24 PM, Chris Wilson wrote: On Fri, 30 Mar 2012 14:11:47 +0200, Jiri Slaby jsl...@suse.cz wrote: On 03/30/2012 12:45 PM, Chris Wilson wrote: On Fri, 30 Mar 2012 11:59:28 +0200, Jiri Slaby jsl...@suse.cz wrote: I don't know what to dump more, because iir is obviously zero too. What other sources of interrupts are on the (G33) chip? IIR is the master interrupt, with chained secondary interrupt statuses. If IIR is 0, the interrupt wasn't raised by the GPU. This does not make sense, the handler does something different. Even if IIR is 0, it still takes a look at pipe stats. That was introduced in 05eff845a28499762075d3a72e238a31f4d2407c to close a race where the pipestat triggered an interrupt after we processed the secondary registers and before reseting the primary. But the basic premise that we should only enter the interrupt handler with IIR!=0 holds (presuming non-shared interrupt lines such as MSI). Ok, this behavior is definitely new. I get several nobody cared about this interrupt a week. This never used to happen. And something weird emerges in /proc/interrupts when this happens: 42:10032921212890 PCI-MSI-edge ???s::00:02.0 instead of 42:10067151218472 PCI-MSI-edge i915@pci::00:02.0 It very looks like the generic IRQ handling code is broken. Like it frees/corrupts irq_desc and ... OMG, your problem analyzing skills are amazing. If irq_desc would have been freed, then it wouldn't print the numbers and the irq type. And irq_desc is not corrupted either, otherwise the whole thing would explode in your face. The printout of the name is done via action-name. The irq action merily holds a pointer to the device name string, which is handed over with request_irq. So you are saying that the core code corrupts the memory which was handed in via a pointer by the driver? So now that's really an amazing core feature: It corrupts the memory with weird characters and still maintains the PCI bus number correct. So it not only corrupts memory it also moves the PCI part of the string a few characters to the end. If the pointer in the irq action would have been corrupted, then you would see a few weird characters and then the full string, not a random thing which is half correct and shifted by a few bytes. The pointer which is handed in is dev-devname, which gets allocated and filled in drm_pci_set_busid(). ... then as well calls random handlers. Which random handlers would be called? The core code only calls handlers which are associated to an particular interrupt. And only when that particular interrupt is raised and not because the CPU pulls interrupt events out of thin air. And it calls the stupid i915 handler and not something else, otherwise you would not observe the IIR=0 printk or whatever you put there for debugging. Suspend/resume cycle helps in this case and i915@pci::00:02.0 is back in /proc/interrupts as can be seen above. That's proving what? That the irq core code magically restores the correct string, right? And probably it stops calling random handlers as well. Brilliant deduction. You know what? suspend calls free_irq() via i915_drm_freeze() - drm_irq_uninstall() and the resume code calls request_irq() again. free_irq() removes the action and request_irq installs it fresh. So now the interesting part is that free_irq() checks the dev_id cookie for a match, which is also stored in the irq action. So we are dealing with a magic corrupt only action-name and action-handler problem. Pretty realistic. What the heck makes you assume that the irq core code is broken? Core code, which works on a gazillion of machines and different device drivers and does not corrupt anything except that i915 thingy? Come on, you need to provide better evidence than weird ass guessing. If you're still convinced that the irq core is messing with your device string, then simply hand in a NULL pointer when requesting the interrupt. That will make the core code explode nicely when it tries to modify that memory. Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48305] llpp gets segfault in r600g_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=48305 --- Comment #9 from myxol my...@lavabit.com 2012-04-07 07:28:42 PDT --- I tried 3 gcc versions. Flags: -march=native -O2 -ftree-vectorize -ggdb -pipe 4.4.7 - build fails 4.5.3 - original bugreport 4.6.2 - same problem as with 4.5.3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46713] HDMI audio played back at a wrong rate
https://bugs.freedesktop.org/show_bug.cgi?id=46713 --- Comment #26 from Vincenzov vincenzo...@hotmail.com 2012-04-07 11:16:54 UTC --- Error when compiling. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48424] New: Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Bug #: 48424 Summary: Fix warnings/errors reported by clang's scan-build tool Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) URL: https://gitorious.org/jobermayr/scan-build-mesa OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-...@lists.freedesktop.org ReportedBy: johannesoberm...@gmx.de CC: dri-devel@lists.freedesktop.org, nouv...@lists.freedesktop.org https://gitorious.org/jobermayr/scan-build-mesa ~ 8 MB to download, 680 MB on disk. Please report false positives here. I will forward them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48422] Radeon KMS fails on Radeon X850XT (R480) graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=48422 --- Comment #1 from Jonathan Nieder jrnie...@gmail.com 2012-04-07 12:16:24 PDT --- Context: http://bugs.debian.org/667799 which mentions that the system is still usable using ssh after the failed modeset. Looks like the log with drm.debug=0x6 overflowed the kernel buffer so it's cut off at the beginning. Does /var/log/dmesg have more? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48424] Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Kenneth Graunke kenn...@whitecape.org changed: What|Removed |Added Priority|medium |low --- Comment #1 from Kenneth Graunke kenn...@whitecape.org 2012-04-07 12:55:28 PDT --- Thanks for running this! Looks like a neat tool. Here's a false positive: Logic errorAssigned value is garbage or undefinedmesa /drivers /dri /i965 /brw_vec4_visitor.cpp13833 or: report-3rwkCp.html#EndPath -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48424] Fix warnings/errors reported by clang's scan-build tool
https://bugs.freedesktop.org/show_bug.cgi?id=48424 Johannes Obermayr johannesoberm...@gmx.de changed: What|Removed |Added See Also||http://llvm.org/bugs/show_b ||ug.cgi?id=12491 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48422] Radeon KMS fails on Radeon X850XT (R480) graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=48422 --- Comment #2 from Mike B m...@coruscant.demon.co.uk 2012-04-07 17:07:13 PDT --- Created attachment 59633 -- https://bugs.freedesktop.org/attachment.cgi?id=59633 Dmesg output from boot (no drm debug) Attached file is the dmesg output from booting 3.3 without the drm debug parameter set. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45366] Radeon gpu lockups
https://bugs.freedesktop.org/show_bug.cgi?id=45366 --- Comment #7 from Ernst Sjöstrand ern...@gmail.com 2012-04-07 22:05:43 PDT --- Now this happened to me during login! :-( [ 188.237505] radeon :01:00.0: GPU lockup CP stall for more than 10008msec [ 188.237511] GPU lockup (waiting for 0x0E47 last fence id 0x0E46) [ 188.238681] radeon :01:00.0: GPU softreset [ 188.238684] radeon :01:00.0: GRBM_STATUS=0xB2703828 [ 188.238687] radeon :01:00.0: GRBM_STATUS_SE0=0x1C07 [ 188.238689] radeon :01:00.0: GRBM_STATUS_SE1=0x0807 [ 188.238692] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 188.238704] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 188.238806] radeon :01:00.0: GRBM_STATUS=0x3828 [ 188.238809] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 188.238811] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 188.238814] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 188.239811] radeon :01:00.0: GPU reset succeed [ 188.262214] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 188.262326] radeon :01:00.0: WB enabled [ 188.278447] [drm] ring test succeeded in 2 usecs [ 188.278456] [drm] ib test succeeded in 2 usecs [ 199.622493] radeon :01:00.0: GPU lockup CP stall for more than 10020msec [ 199.622498] GPU lockup (waiting for 0x0E63 last fence id 0x0E60) [ 199.623667] radeon :01:00.0: GPU softreset [ 199.623670] radeon :01:00.0: GRBM_STATUS=0xB2701828 [ 199.623673] radeon :01:00.0: GRBM_STATUS_SE0=0x1C03 [ 199.623675] radeon :01:00.0: GRBM_STATUS_SE1=0x0803 [ 199.623678] radeon :01:00.0: SRBM_STATUS=0x2AC0 [ 199.623689] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 199.623792] radeon :01:00.0: GRBM_STATUS=0x3828 [ 199.623794] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 199.623797] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 199.623800] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 199.624796] radeon :01:00.0: GPU reset succeed [ 199.647176] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 199.647279] radeon :01:00.0: WB enabled [ 199.901376] [drm] ring test succeeded in 3 usecs [ 199.901393] [drm] ib test succeeded in 3 usecs [ 210.619789] radeon :01:00.0: GPU lockup CP stall for more than 10004msec [ 210.619794] GPU lockup (waiting for 0x0F19 last fence id 0x0F18) [ 210.620964] radeon :01:00.0: GPU softreset [ 210.620967] radeon :01:00.0: GRBM_STATUS=0xB2701828 [ 210.620970] radeon :01:00.0: GRBM_STATUS_SE0=0x0803 [ 210.620973] radeon :01:00.0: GRBM_STATUS_SE1=0x1C03 [ 210.620975] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 210.620987] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 210.621089] radeon :01:00.0: GRBM_STATUS=0x3828 [ 210.621092] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 210.621094] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 210.621097] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 210.622094] radeon :01:00.0: GPU reset succeed [ 210.644468] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 210.644581] radeon :01:00.0: WB enabled [ 210.660703] [drm] ring test succeeded in 2 usecs [ 210.660712] [drm] ib test succeeded in 2 usecs [ 225.864992] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 225.864997] GPU lockup (waiting for 0x0F2C last fence id 0x0F2B) [ 225.866169] radeon :01:00.0: GPU softreset [ 225.866172] radeon :01:00.0: GRBM_STATUS=0xB2701828 [ 225.866175] radeon :01:00.0: GRBM_STATUS_SE0=0x1C03 [ 225.866177] radeon :01:00.0: GRBM_STATUS_SE1=0x0803 [ 225.866180] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 225.866191] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 225.866294] radeon :01:00.0: GRBM_STATUS=0x3828 [ 225.866297] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [ 225.866299] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [ 225.866302] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 225.867299] radeon :01:00.0: GPU reset succeed [ 225.889664] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 225.889767] radeon :01:00.0: WB enabled [ 225.906004] [drm] ring test succeeded in 3 usecs [ 225.906016] [drm] ib test succeeded in 3 usecs [ 260.351552] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 260.352714] GPU lockup (waiting for 0x0F3A last fence id 0x0F39) [ 260.353886] radeon :01:00.0: GPU softreset [ 260.353889] radeon :01:00.0: GRBM_STATUS=0xB2701828 [ 260.353892] radeon :01:00.0: GRBM_STATUS_SE0=0x0803 [ 260.353895] radeon :01:00.0: GRBM_STATUS_SE1=0x1C03 [ 260.353898] radeon :01:00.0: SRBM_STATUS=0x20C0 [ 260.353909] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [ 260.354012] radeon :01:00.0: GRBM_STATUS=0x3828 [
