[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #19 from Bob Ham 2011-05-21 19:55:50 PDT --- I recalled that I had played Warzone 2100 (a GL game) some time ago. Looking at the time stamps on the save game files, I found which kernel I was using at the time (2.6.36). From there, I've done a git bisect using Linus' tree. This is the output: rah at myrtle:/usr/src/linus$ git bisect good 6f34be50bd1bdd2ff3c955940e033a80d05f248a is the first bad commit commit 6f34be50bd1bdd2ff3c955940e033a80d05f248a Author: Alex Deucher Date: Sun Nov 21 10:59:01 2010 -0500 drm/radeon/kms: add pageflip ioctl support (v3) This adds support for dri2 pageflipping. v2: precision updates from Mario Kleiner. v3: Multihead fixes from Mario Kleiner; missing crtc offset add note about update pending bit on pre-avivo chips Signed-off-by: Alex Deucher Signed-off-by: Mario Kleiner Signed-off-by: Dave Airlie :04 04 e5e9b7c6860a5ebba78346f3396791520a7842a4 2e9d672e24e579dc56c8f25b0ff883d88c09b7c4 M drivers -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[regression] blank screen with radeondrmfb on iMac G5 (ALS)
On 05/21/11 17:14, Alex Deucher wrote:
> On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
> wrote:
>> Hello,
>>
>> I found a regression in Linux 2.6.37.2 - I know this report comes quite
>> late, but I had no time to investigate until now. And I found that this
>> still persists up to 2.6.39 :(
>>
>> When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
>> with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
>> Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
>> remained blank.
>>
>> There were only a few Radeon specific changes between these two versions, so
>> that I could quickly identify the cause. It's commit
>> ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
>> (9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
>> with a simple patch, it works properly again:
>>
>> --- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
>> +++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
>> @@ -1515,11 +1515,6 @@
>>(rdev->pdev->subsystem_device == 0x4a48)) {
>> /* Mac X800 */
>> rdev->mode_info.connector_table = CT_MAC_X800;
>> - } else if ((rdev->pdev->device == 0x4150)&&
>> - (rdev->pdev->subsystem_vendor == 0x1002)&&
>> - (rdev->pdev->subsystem_device == 0x4150)) {
>> - /* Mac G5 9600 */
>> - rdev->mode_info.connector_table = CT_MAC_G5_9600;
>> } else
>> #endif /* CONFIG_PPC_PMAC */
>> #ifdef CONFIG_PPC64
>>
>>
>> This is a diff from the dmesg [without my patch] -> [with my patch]:
>>
>> [drm] ring test succeeded in 0 usecs
>> [drm] radeon: ib pool ready.
>> [drm] ib test succeeded in 0 usecs
>> -[drm] Connector Table: 12 (mac g5 9600)
>> -[drm] No valid Ext TMDS info found in BIOS
>> -[drm] No TV DAC info found in BIOS
>> +[drm] Connector Table: 1 (generic)
>> [drm] No TMDS info found in BIOS
>> +[drm] No TV DAC info found in BIOS
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm] DVI-I
>> [drm] HPD1
>> [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
>> [drm] Encoders:
>> -[drm] DFP2: INTERNAL_DVO1
>> +[drm] DFP1: INTERNAL_TMDS1
>> [drm] CRT2: INTERNAL_DAC2
>> [drm] Connector 1:
>> -[drm] DVI-I
>> -[drm] HPD2
>> +[drm] VGA
>> [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
>> [drm] Encoders:
>> -[drm] DFP1: INTERNAL_TMDS1
>> [drm] CRT1: INTERNAL_DAC1
>> [drm] Connector 2:
>> [drm] S-video
>>
>>
>> On which kind of machines was the original commit tested/supposed to work?
>> Do you see a possibility to fix this in a proper way upstream?
>
> It was a 9600 from a G5, I don't recall which one. Thank apple for
> making multiple systems all wired up differently with the same pci
> ids. I suppose to fix it properly we'll need some way of identifying
> the specific machine. Are there specific ids for each g5 for
> of_machine_is_compatible()?
>
> Alex
>
Thanks for your fast reply! FYI, this is what /proc/cpuinfo tells:
platform: PowerMac
model : PowerMac8,2
machine : PowerMac8,2
motherboard : PowerMac8,2 MacRISC4 Power Macintosh
But instead of excluding this model, it's probably better to only include
the model the patch was originally written for - in case there are other
systems which got broken ;)
>>
>> Thanks and regards,
>> Joachim Henke
[regression] blank screen with radeondrmfb on iMac G5 (ALS)
On Sam, 2011-05-21 at 11:14 -0400, Alex Deucher wrote:
> On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
> wrote:
> > Hello,
> >
> > I found a regression in Linux 2.6.37.2 - I know this report comes quite
> > late, but I had no time to investigate until now. And I found that this
> > still persists up to 2.6.39 :(
> >
> > When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
> > with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
> > Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
> > remained blank.
> >
> > There were only a few Radeon specific changes between these two versions, so
> > that I could quickly identify the cause. It's commit
> > ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
> > (9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
> > with a simple patch, it works properly again:
> >
> > --- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
> > +++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
> > @@ -1515,11 +1515,6 @@
> > (rdev->pdev->subsystem_device == 0x4a48)) {
> >/* Mac X800 */
> >rdev->mode_info.connector_table = CT_MAC_X800;
> > - } else if ((rdev->pdev->device == 0x4150) &&
> > - (rdev->pdev->subsystem_vendor == 0x1002) &&
> > - (rdev->pdev->subsystem_device == 0x4150)) {
> > - /* Mac G5 9600 */
> > - rdev->mode_info.connector_table = CT_MAC_G5_9600;
> >} else
> > #endif /* CONFIG_PPC_PMAC */
> > #ifdef CONFIG_PPC64
> >
> >
> > This is a diff from the dmesg [without my patch] -> [with my patch]:
> >
> > [drm] ring test succeeded in 0 usecs
> > [drm] radeon: ib pool ready.
> > [drm] ib test succeeded in 0 usecs
> > -[drm] Connector Table: 12 (mac g5 9600)
> > -[drm] No valid Ext TMDS info found in BIOS
> > -[drm] No TV DAC info found in BIOS
> > +[drm] Connector Table: 1 (generic)
> > [drm] No TMDS info found in BIOS
> > +[drm] No TV DAC info found in BIOS
> > [drm] Radeon Display Connectors
> > [drm] Connector 0:
> > [drm] DVI-I
> > [drm] HPD1
> > [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> > [drm] Encoders:
> > -[drm] DFP2: INTERNAL_DVO1
> > +[drm] DFP1: INTERNAL_TMDS1
> > [drm] CRT2: INTERNAL_DAC2
> > [drm] Connector 1:
> > -[drm] DVI-I
> > -[drm] HPD2
> > +[drm] VGA
> > [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
> > [drm] Encoders:
> > -[drm] DFP1: INTERNAL_TMDS1
> > [drm] CRT1: INTERNAL_DAC1
> > [drm] Connector 2:
> > [drm] S-video
> >
> >
> > On which kind of machines was the original commit tested/supposed to work?
> > Do you see a possibility to fix this in a proper way upstream?
>
> It was a 9600 from a G5, I don't recall which one.
Probably a tower.
> Thank apple for making multiple systems all wired up differently with the
> same pci
> ids. I suppose to fix it properly we'll need some way of identifying
> the specific machine. Are there specific ids for each g5 for
> of_machine_is_compatible()?
Yeah, they should have distinct identifiers, visible on
the /proc/cpuinfo model/machine/motherboard lines.
--
Earthling Michel D?nzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #21 from Michel D?nzer 2011-05-21 16:58:59 --- Would also be interesting if one of you guys could attach dmesg with agpmode=1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #20 from Michel D?nzer 2011-05-21 16:47:10 --- Created an attachment (id=58922) --> (https://bugzilla.kernel.org/attachment.cgi?id=58922) Allow forcing on all GPU clocks (In reply to comment #17) > > Has either of you tried agpmode=1 dynclks=1? Does that increase stability at > > all? > > I will try those. But with which kernel? 2.6.38 should be fine for this test. But at some point it'll probably be useful for you to be able to try kernel patches. Once you've built a kernel, building the radeon module with a patch shouldn't take long. E.g., you guys could try this patch, and booting with radeon.dynclks=0, which should force on all GPU clocks. Does that increase stability with agpmode=1 or agpmode=-1? > BTW, would you mind sharing your .config? My .config still takes 1-2 hours to build on this 1.6 GHz PowerBook. If that could help you, please ask for it on the debian-powerpc list. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Major 2.6.38 regression ignored?
On Sat, 21 May 2011 11:23:53 -0400, "Luke-Jr" wrote: > On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote: > > On Fri, 20 May 2011 11:08:56 -0700, Ray Lee wrote: > > > [ Adding Chris Wilson (author of the problematic patch) and Rafael > > > Wysocki to the message ] > > > > > > On Fri, May 20, 2011 at 10:06 AM, Luke-Jr wrote: > > > > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month > > > > ago against 2.6.38. Now 2.6.39 was just released without the > > > > regression being addressed. This bug makes the system unusable... Some > > > > guys on IRC suggested I > > > > email, so here it is. > > > > > > See the bugzilla entry for the bisection history. > > > > Which has nothing to do with Luke's bug. Considering the thousand things > > that can go wrong during X starting, without a hint as to which it is nigh > > on impossible to debug except by trial and error. If you set up > > netconsole, does the kernel emit an OOPS with it's last dying breath? > > Why assume it's a different bug? I would almost wonder if it might affect > all Sandy Bridge GPUs. In any case, I no longer have the original > motherboard (it was recalled, as I said in the first post), nor even the > revision of it (it had other issues that weren't being fixed). I *assume* I > will have the same problem with my new motherboard (Intel DQ67SW), but I > haven't verified that yet. I'll be sure to try a netconsole when I have to > reboot next and get a chance to try the most recent 2.6.38 and .39 kernels, > but at the moment it seems reasonable to address the problem bisected in the > bug, even if it turns out to be different. The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate locking between release and IRQ and so is prone to such races as befell Kirill should not surprise anyone. As neither UMS nor DRI supported SNB, I can quite confidently state they are separate bugs. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #19 from Rog?rio Brito 2011-05-21 15:42:21 --- (In reply to comment #18) > apples sells VGA to s-video adapters, so we list both connectors in the > driver. Oh, sorry for the ignorance. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #18 from Alex Deucher 2011-05-21 15:38:57 --- apples sells VGA to s-video adapters, so we list both connectors in the driver. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #17 from Rog?rio Brito 2011-05-21 15:34:37 --- Hi, Michel. Thank you very much for the attention. (In reply to comment #16) > When the kernel radeon driver fails to initialize acceleration, there's no > point in trying any functionality that needs acceleration, such as XVideo. OK. > I don't think there's any point doing any more tests with 2.6.39-rc7, as it's > obviously suffering from additional issues which only occurred intermittently > during the 2.6.39 cycle. Right. > Well, I'm afraid less quantity but more quality would be better... It's > becoming rather difficult and time-consuming to find the relevant pieces of > information in this mass. Indeed, it is getting out of hand pretty quickly. Do you want me to give you some SSH access to this notebook? Or, if that's not feasible/useful, what would you like me to test as the next step, so that I avoid flooding you with so much data? > Has either of you tried agpmode=1 dynclks=1? Does that increase stability at > all? I will try those. But with which kernel? I have been avoiding compiling a kernel nowadays, since they take ages on this notebook, but I can set up a cross-compilation environment, if necessary. BTW, would you mind sharing your .config? > I thought there was some kind of multimedia adapter for the external output. The only external adapter is one to a VGA port. No traces of S-video here. > But really, we need to focus on one problem per bug report as much as > possible, > or things are getting out of hand. OK, I can file a separate bug for this S-Video issue, then. Thank you so much for your patience, Rog?rio Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Major 2.6.38 regression ignored?
On Saturday, May 21, 2011 11:40:17 AM Chris Wilson wrote: > The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate > locking between release and IRQ and so is prone to such races as befell > Kirill should not surprise anyone. As neither UMS nor DRI supported SNB, > I can quite confidently state they are separate bugs. Unfortunately, I cannot help troubleshoot that bug any further, as I no longer have the affected motherboard. I was unable to reproduce it on my Intel DQ67SW. However, I did encounter a new regression, which I have reported as: https://bugzilla.kernel.org/show_bug.cgi?id=35552 This one is related to Intel HD Audio, not Graphics.
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #16 from Michel D?nzer 2011-05-21 14:54:25 --- (In reply to comment #15) > With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: > > * XV is not available to mplayer or other applications. When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. (In reply to comment #12) > BTW, I hope that you don't mind me providing copious amounts of > testing here (and their results) in the hope to get this fixed... :-) Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. (In reply to comment #11) > Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + > dynclks=1 still locks up the GPU when I play a video with mplayer. Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? > Besides that, like Andreas, with dynclks=1 the resolution is reduced > to be 800x600. I didn't have the opportunity to read the X logs > regarding the S-Video port, but, at least for the user, iBooks > (differently from PowerBooks) don't have user-accessible S-Video ports > (but this doesn't prevent Apple from having inutilized them somehow). I thought there was some kind of multimedia adapter for the external output. Anyway, it should be possible to override the incorrect output detection, either on the kernel command line with something like video=S-video-1:d or later in xorg.conf or during X runtime with something like xrandr. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. (In reply to comment #9) > So, I am not quite sure if it would be the case of bisecting or, at > least, what would be a good starting point. No, there's no point in bisecting, as that problem should be gone with 2.6.39 final. > > Note that you should boot with radeon.no_wb=1 as well for > > OK. I can try no_wb=1 with agpmode=-1 and report back in a few > moments, to see if the lockups are still there or not. no_wb=1 would only have been important for bisecting, to avoid the writeback endianness bug interfering. P.S. beware of Debian package udev version 169-1: IME an initrd generated with that installed prevents the radeon module from being loaded automatically, and when trying to load it manually, it fails to load the CP microcode and consequently fails to initialize acceleration. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[regression] blank screen with radeondrmfb on iMac G5 (ALS)
Hello,
I found a regression in Linux 2.6.37.2 - I know this report comes quite
late, but I had no time to investigate until now. And I found that this
still persists up to 2.6.39 :(
When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
remained blank.
There were only a few Radeon specific changes between these two versions, so
that I could quickly identify the cause. It's commit
ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
(9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
with a simple patch, it works properly again:
--- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
+++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1515,11 +1515,6 @@
(rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev->pdev->device == 0x4150) &&
- (rdev->pdev->subsystem_vendor == 0x1002) &&
- (rdev->pdev->subsystem_device == 0x4150)) {
- /* Mac G5 9600 */
- rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
#endif /* CONFIG_PPC_PMAC */
#ifdef CONFIG_PPC64
This is a diff from the dmesg [without my patch] -> [with my patch]:
[drm] ring test succeeded in 0 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
-[drm] Connector Table: 12 (mac g5 9600)
-[drm] No valid Ext TMDS info found in BIOS
-[drm] No TV DAC info found in BIOS
+[drm] Connector Table: 1 (generic)
[drm] No TMDS info found in BIOS
+[drm] No TV DAC info found in BIOS
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I
[drm] HPD1
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
-[drm] DFP2: INTERNAL_DVO1
+[drm] DFP1: INTERNAL_TMDS1
[drm] CRT2: INTERNAL_DAC2
[drm] Connector 1:
-[drm] DVI-I
-[drm] HPD2
+[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
-[drm] DFP1: INTERNAL_TMDS1
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 2:
[drm] S-video
On which kind of machines was the original commit tested/supposed to work?
Do you see a possibility to fix this in a proper way upstream?
Thanks and regards,
Joachim Henke
Major 2.6.38 regression ignored?
On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote: > On Fri, 20 May 2011 11:08:56 -0700, Ray Lee wrote: > > [ Adding Chris Wilson (author of the problematic patch) and Rafael > > Wysocki to the message ] > > > > On Fri, May 20, 2011 at 10:06 AM, Luke-Jr wrote: > > > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month > > > ago against 2.6.38. Now 2.6.39 was just released without the > > > regression being addressed. This bug makes the system unusable... Some > > > guys on IRC suggested I > > > email, so here it is. > > > > See the bugzilla entry for the bisection history. > > Which has nothing to do with Luke's bug. Considering the thousand things > that can go wrong during X starting, without a hint as to which it is nigh > on impossible to debug except by trial and error. If you set up > netconsole, does the kernel emit an OOPS with it's last dying breath? Why assume it's a different bug? I would almost wonder if it might affect all Sandy Bridge GPUs. In any case, I no longer have the original motherboard (it was recalled, as I said in the first post), nor even the revision of it (it had other issues that weren't being fixed). I *assume* I will have the same problem with my new motherboard (Intel DQ67SW), but I haven't verified that yet. I'll be sure to try a netconsole when I have to reboot next and get a chance to try the most recent 2.6.38 and .39 kernels, but at the moment it seems reasonable to address the problem bisected in the bug, even if it turns out to be different.
[regression] blank screen with radeondrmfb on iMac G5 (ALS)
On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
wrote:
> Hello,
>
> I found a regression in Linux 2.6.37.2 - I know this report comes quite
> late, but I had no time to investigate until now. And I found that this
> still persists up to 2.6.39 :(
>
> When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
> with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
> Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
> remained blank.
>
> There were only a few Radeon specific changes between these two versions, so
> that I could quickly identify the cause. It's commit
> ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
> (9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
> with a simple patch, it works properly again:
>
> --- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
> +++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -1515,11 +1515,6 @@
> ? ? ? ? ? ? ? ? ? ? ? ? ? (rdev->pdev->subsystem_device == 0x4a48)) {
> ? ? ? ? ? ? ? ? ? ? ? ?/* Mac X800 */
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->mode_info.connector_table = CT_MAC_X800;
> - ? ? ? ? ? ? ? } else if ((rdev->pdev->device == 0x4150) &&
> - ? ? ? ? ? ? ? ? ? ? ? ? ?(rdev->pdev->subsystem_vendor == 0x1002) &&
> - ? ? ? ? ? ? ? ? ? ? ? ? ?(rdev->pdev->subsystem_device == 0x4150)) {
> - ? ? ? ? ? ? ? ? ? ? ? /* Mac G5 9600 */
> - ? ? ? ? ? ? ? ? ? ? ? rdev->mode_info.connector_table = CT_MAC_G5_9600;
> ? ? ? ? ? ? ? ?} else
> ?#endif /* CONFIG_PPC_PMAC */
> ?#ifdef CONFIG_PPC64
>
>
> This is a diff from the dmesg [without my patch] -> [with my patch]:
>
> ?[drm] ring test succeeded in 0 usecs
> ?[drm] radeon: ib pool ready.
> ?[drm] ib test succeeded in 0 usecs
> -[drm] Connector Table: 12 (mac g5 9600)
> -[drm] No valid Ext TMDS info found in BIOS
> -[drm] No TV DAC info found in BIOS
> +[drm] Connector Table: 1 (generic)
> ?[drm] No TMDS info found in BIOS
> +[drm] No TV DAC info found in BIOS
> ?[drm] Radeon Display Connectors
> ?[drm] Connector 0:
> ?[drm] ? DVI-I
> ?[drm] ? HPD1
> ?[drm] ? DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> ?[drm] ? Encoders:
> -[drm] ? ? DFP2: INTERNAL_DVO1
> +[drm] ? ? DFP1: INTERNAL_TMDS1
> ?[drm] ? ? CRT2: INTERNAL_DAC2
> ?[drm] Connector 1:
> -[drm] ? DVI-I
> -[drm] ? HPD2
> +[drm] ? VGA
> ?[drm] ? DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
> ?[drm] ? Encoders:
> -[drm] ? ? DFP1: INTERNAL_TMDS1
> ?[drm] ? ? CRT1: INTERNAL_DAC1
> ?[drm] Connector 2:
> ?[drm] ? S-video
>
>
> On which kind of machines was the original commit tested/supposed to work?
> Do you see a possibility to fix this in a proper way upstream?
It was a 9600 from a G5, I don't recall which one. Thank apple for
making multiple systems all wired up differently with the same pci
ids. I suppose to fix it properly we'll need some way of identifying
the specific machine. Are there specific ids for each g5 for
of_machine_is_compatible()?
Alex
>
> Thanks and regards,
> Joachim Henke
>
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #15 from Rog?rio Brito 2011-05-21 09:56:33 --- With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: * I don't get the Oopsen. * the resolution is restricted to 800x600. * XV is not available to mplayer or other applications. I think the XV extension not working is something that has always happened with 2.6.39 kernels. Thanks, Rog?rio Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #14 from Rog?rio Brito 2011-05-21 09:50:35 --- Created an attachment (id=58902) --> (https://bugzilla.kernel.org/attachment.cgi?id=58902) X log with 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #13 from Rog?rio Brito 2011-05-21 09:47:45 --- Created an attachment (id=58892) --> (https://bugzilla.kernel.org/attachment.cgi?id=58892) dmesg log with 2.6.39-rc7 with KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #12 from Rog?rio Brito 2011-05-21 09:42:12 --- On Sat, May 21, 2011 at 09:34, wrote: > On Sat, May 21, 2011 at 09:23, ? > wrote: >> On Sat, May 21, 2011 at 09:16, ? >> wrote: >>> OK. I can try no_wb=1 with agpmode=-1 and report back in a few >>> moments, to see if the lockups are still there or not. >> >> Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still >> locks up the GPU when I play a video with mplayer. Wooow! Oopsen galore with 2.6.39 with KMS + agpmode=-1 + no_wb=1... Five in a row. OK, probably only the first one matters. Then, it stays there and doesn't load the system... Actually, as I am writing this thing, after about 180 seconds, the boot process is continuing and X is being loaded, but with the wrong colors (the "endianness issue"). I will try to see if the network is available and attach here what I get from dmesg. BTW, I hope that you don't mind me providing copious amounts of testing here (and their results) in the hope to get this fixed... :-) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Major 2.6.38 regression ignored?
On Fri, 20 May 2011 11:08:56 -0700, Ray Lee wrote: > [ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki > to the message ] > > On Fri, May 20, 2011 at 10:06 AM, Luke-Jr wrote: > > > I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago > > against 2.6.38. Now 2.6.39 was just released without the regression being > > addressed. This bug makes the system unusable... Some guys on IRC suggested > > I > > email, so here it is. > > > > See the bugzilla entry for the bisection history. Which has nothing to do with Luke's bug. Considering the thousand things that can go wrong during X starting, without a hint as to which it is nigh on impossible to debug except by trial and error. If you set up netconsole, does the kernel emit an OOPS with it's last dying breath? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #11 from Rog?rio Brito 2011-05-21 09:34:20 --- Another test. On Sat, May 21, 2011 at 09:23, wrote: > On Sat, May 21, 2011 at 09:16, ? > wrote: >> OK. I can try no_wb=1 with agpmode=-1 and report back in a few >> moments, to see if the lockups are still there or not. > > Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still > locks up the GPU when I play a video with mplayer. Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + dynclks=1 still locks up the GPU when I play a video with mplayer. Besides that, like Andreas, with dynclks=1 the resolution is reduced to be 800x600. I didn't have the opportunity to read the X logs regarding the S-Video port, but, at least for the user, iBooks (differently from PowerBooks) don't have user-accessible S-Video ports (but this doesn't prevent Apple from having inutilized them somehow). Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #10 from Rog?rio Brito 2011-05-21 09:23:27 --- Hi there. On Sat, May 21, 2011 at 09:16, wrote: > OK. I can try no_wb=1 with agpmode=-1 and report back in a few > moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. I will try with 2.6.39 with the same settings. Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #9 from Rog?rio Brito 2011-05-21 09:16:28 --- Hi, Michel. On Fri, May 20, 2011 at 12:11, wrote: > --- Comment #6 from Michel D?nzer ?2011-05-20 > 12:11:38 --- > (In reply to comment #1) >> Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39 >> the kernel doesn't even get the colors correctly---everything that should be >> red becomes blue and so forth (any kind of endianness problem?). > > That's probably nothing to do with the kernel directly but endianness bugs in > the X driver when acceleration is not available. OK, then that's a separate issue. Good to know. > It would be interesting if you could bisect what broke acceleration with > radeon.agpmode=-1. Oooh, I guess that I made some mess in your head here, taking into account the other messages of us. To clear things up: When I use 2.6.38, it works mostly OK if I use radeon.agpmode=-1. It is sufficiently stable to the point that I told you that this setting was OK. But, in fact, if I play a video with mplayer, then it always (so far, 100% reproducible) causes those GPU lockups, but the computer is still accessible via the network, so that I can take the logs etc. If, instead, I use 1 instead of -1, then, even with kernel 2.6.38, I get those lysergide-like :-) pictures that I put on my homepage (but, for documentation purposes, I am thinking of uploading here as attachments, as I am quite short of space there). With kernel 2.6.39, I have not been able to get anything working, whether or not I pass any option to the kernel. Summary: * 2.6.38 with KMS and agpmode=-1: OK, up to me trying to play some video, then GPU lockups. * 2.6.38 with KMS and agpmode=1: GPU lockups a few seconds after X loads (it *does* show up, but locks up a few seconds latter). * 2.6.39 with KMS and agpmode=-1: Not OK, even if I don't use anything accelerated (problems with colors and software rendering). So, I am not quite sure if it would be the case of bisecting or, at least, what would be a good starting point. I can, though, try to boot with many other kernels to see if I can (provided that udev doesn't stop me). > Note that you should boot with radeon.no_wb=1 as well for OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. > this, as CP writeback was only fixed during the 2.6.39 cycle (in commit > dc66b325f161bb651493c7d96ad44876b629cf6a). Right. Thanks for that fix of yours (just read the commit). Regards, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel -> i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #19 from Ville Syrjala 2011-05-21 04:32:55 PDT --- Created an attachment (id=46972) View: https://bugs.freedesktop.org/attachment.cgi?id=46972 Review: https://bugs.freedesktop.org/review?bug=29787=46972 possible i2-algo-bit preempt fix -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel -> i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #18 from Ville Syrjala 2011-05-21 04:31:35 PDT --- (In reply to comment #15) > (In reply to comment #14) > > Grumble. So, how will this be fixed? Sprinkle the code with > > preempt_disable()/enable() pairs? Advise all users (well, me) to disable > > preemption? Change the code so it no longer acts on intermittent EDID > > failures? > > Ask your colleagues to design sane hardware that doesn't rely on software > > interaction for timing-critical operations ;) ? > > > > FWIW, I'm perfectly happy to disable preemption in my kernel, haven't run a > > distro-provided kernel since 2.6.27. But your explanation sounds like this > > could bite a lot more users than just me. > > It has nothing to do with the hw, it's the nature of i2c. All drivers that > use > bit banging i2c (hwmon, v4l, lots of embedded stuff) would potentially be > affected. If the EEPROM supports clock stretching I see no reason why bit banging would fail. I got these timeout errors on one system at some point. I had an idea for a possible fix, but I never got around to testing it. I'll attach the patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel -> i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #17 from Stratos Zolotas 2011-05-21 03:35:11 PDT --- Created an attachment (id=46971) --> (https://bugs.freedesktop.org/attachment.cgi?id=46971) dmesg output I'm experiencing a similar error (with more info on dmesg). I'm on x86_64 and running 2.6.39 kernel. I could provide more info if you tell me where to look. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Major 2.6.38 regression ignored?
On Fri, 20 May 2011 11:08:56 -0700, Ray Lee ray...@madrabbit.org wrote: [ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki to the message ] On Fri, May 20, 2011 at 10:06 AM, Luke-Jr l...@dashjr.org wrote: I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago against 2.6.38. Now 2.6.39 was just released without the regression being addressed. This bug makes the system unusable... Some guys on IRC suggested I email, so here it is. See the bugzilla entry for the bisection history. Which has nothing to do with Luke's bug. Considering the thousand things that can go wrong during X starting, without a hint as to which it is nigh on impossible to debug except by trial and error. If you set up netconsole, does the kernel emit an OOPS with it's last dying breath? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #9 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:16:28 --- Hi, Michel. On Fri, May 20, 2011 at 12:11, bugzilla-dae...@bugzilla.kernel.org wrote: --- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-05-20 12:11:38 --- (In reply to comment #1) Anyway, things are *way* better with 2.6.38 than with 2.6.39, as with 2.6.39 the kernel doesn't even get the colors correctly---everything that should be red becomes blue and so forth (any kind of endianness problem?). That's probably nothing to do with the kernel directly but endianness bugs in the X driver when acceleration is not available. OK, then that's a separate issue. Good to know. It would be interesting if you could bisect what broke acceleration with radeon.agpmode=-1. Oooh, I guess that I made some mess in your head here, taking into account the other messages of us. To clear things up: When I use 2.6.38, it works mostly OK if I use radeon.agpmode=-1. It is sufficiently stable to the point that I told you that this setting was OK. But, in fact, if I play a video with mplayer, then it always (so far, 100% reproducible) causes those GPU lockups, but the computer is still accessible via the network, so that I can take the logs etc. If, instead, I use 1 instead of -1, then, even with kernel 2.6.38, I get those lysergide-like :-) pictures that I put on my homepage (but, for documentation purposes, I am thinking of uploading here as attachments, as I am quite short of space there). With kernel 2.6.39, I have not been able to get anything working, whether or not I pass any option to the kernel. Summary: * 2.6.38 with KMS and agpmode=-1: OK, up to me trying to play some video, then GPU lockups. * 2.6.38 with KMS and agpmode=1: GPU lockups a few seconds after X loads (it *does* show up, but locks up a few seconds latter). * 2.6.39 with KMS and agpmode=-1: Not OK, even if I don't use anything accelerated (problems with colors and software rendering). So, I am not quite sure if it would be the case of bisecting or, at least, what would be a good starting point. I can, though, try to boot with many other kernels to see if I can (provided that udev doesn't stop me). Note that you should boot with radeon.no_wb=1 as well for OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. this, as CP writeback was only fixed during the 2.6.39 cycle (in commit dc66b325f161bb651493c7d96ad44876b629cf6a). Right. Thanks for that fix of yours (just read the commit). Regards, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #10 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:23:27 --- Hi there. On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. I will try with 2.6.39 with the same settings. Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #11 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:34:20 --- Another test. On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + dynclks=1 still locks up the GPU when I play a video with mplayer. Besides that, like Andreas, with dynclks=1 the resolution is reduced to be 800x600. I didn't have the opportunity to read the X logs regarding the S-Video port, but, at least for the user, iBooks (differently from PowerBooks) don't have user-accessible S-Video ports (but this doesn't prevent Apple from having inutilized them somehow). Thanks, -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #12 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:42:12 --- On Sat, May 21, 2011 at 09:34, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:23, bugzilla-dae...@bugzilla.kernel.org wrote: On Sat, May 21, 2011 at 09:16, bugzilla-dae...@bugzilla.kernel.org wrote: OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. Just for the record, 2.6.38 with KMS + agpmode=-1 + no_wb=1 still locks up the GPU when I play a video with mplayer. Wooow! Oopsen galore with 2.6.39 with KMS + agpmode=-1 + no_wb=1... Five in a row. OK, probably only the first one matters. Then, it stays there and doesn't load the system... Actually, as I am writing this thing, after about 180 seconds, the boot process is continuing and X is being loaded, but with the wrong colors (the endianness issue). I will try to see if the network is available and attach here what I get from dmesg. BTW, I hope that you don't mind me providing copious amounts of testing here (and their results) in the hope to get this fixed... :-) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #13 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:47:45 --- Created an attachment (id=58892) -- (https://bugzilla.kernel.org/attachment.cgi?id=58892) dmesg log with 2.6.39-rc7 with KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #14 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:50:35 --- Created an attachment (id=58902) -- (https://bugzilla.kernel.org/attachment.cgi?id=58902) X log with 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #15 from Rogério Brito rbr...@ime.usp.br 2011-05-21 09:56:33 --- With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: * I don't get the Oopsen. * the resolution is restricted to 800x600. * XV is not available to mplayer or other applications. I think the XV extension not working is something that has always happened with 2.6.39 kernels. Thanks, Rogério Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel - i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #17 from Stratos Zolotas str...@gmail.com 2011-05-21 03:35:11 PDT --- Created an attachment (id=46971) -- (https://bugs.freedesktop.org/attachment.cgi?id=46971) dmesg output I'm experiencing a similar error (with more info on dmesg). I'm on x86_64 and running 2.6.39 kernel. I could provide more info if you tell me where to look. -- 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 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel - i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #18 from Ville Syrjala syrj...@sci.fi 2011-05-21 04:31:35 PDT --- (In reply to comment #15) (In reply to comment #14) Grumble. So, how will this be fixed? Sprinkle the code with preempt_disable()/enable() pairs? Advise all users (well, me) to disable preemption? Change the code so it no longer acts on intermittent EDID failures? Ask your colleagues to design sane hardware that doesn't rely on software interaction for timing-critical operations ;) ? FWIW, I'm perfectly happy to disable preemption in my kernel, haven't run a distro-provided kernel since 2.6.27. But your explanation sounds like this could bite a lot more users than just me. It has nothing to do with the hw, it's the nature of i2c. All drivers that use bit banging i2c (hwmon, v4l, lots of embedded stuff) would potentially be affected. If the EEPROM supports clock stretching I see no reason why bit banging would fail. I got these timeout errors on one system at some point. I had an idea for a possible fix, but I never got around to testing it. I'll attach the patch. -- 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 29787] [RADEON:KMS::EDID] i2c bit banging + preempt kernel - i2c failure (random XRandR failures)
https://bugs.freedesktop.org/show_bug.cgi?id=29787 --- Comment #19 from Ville Syrjala syrj...@sci.fi 2011-05-21 04:32:55 PDT --- Created an attachment (id=46972) View: https://bugs.freedesktop.org/attachment.cgi?id=46972 Review: https://bugs.freedesktop.org/review?bug=29787attachment=46972 possible i2-algo-bit preempt fix -- 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 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #16 from Michel Dänzer mic...@daenzer.net 2011-05-21 14:54:25 --- (In reply to comment #15) With 2.6.39-rc7 + KMS + agpmode=-1 + no_wb=1 + dynclks=1: * XV is not available to mplayer or other applications. When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. (In reply to comment #12) BTW, I hope that you don't mind me providing copious amounts of testing here (and their results) in the hope to get this fixed... :-) Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. (In reply to comment #11) Just for the record #2, 2.6.38 with KMS + agpmode=-1 + no_wb=1 + dynclks=1 still locks up the GPU when I play a video with mplayer. Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? Besides that, like Andreas, with dynclks=1 the resolution is reduced to be 800x600. I didn't have the opportunity to read the X logs regarding the S-Video port, but, at least for the user, iBooks (differently from PowerBooks) don't have user-accessible S-Video ports (but this doesn't prevent Apple from having inutilized them somehow). I thought there was some kind of multimedia adapter for the external output. Anyway, it should be possible to override the incorrect output detection, either on the kernel command line with something like video=S-video-1:d or later in xorg.conf or during X runtime with something like xrandr. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. (In reply to comment #9) So, I am not quite sure if it would be the case of bisecting or, at least, what would be a good starting point. No, there's no point in bisecting, as that problem should be gone with 2.6.39 final. Note that you should boot with radeon.no_wb=1 as well for OK. I can try no_wb=1 with agpmode=-1 and report back in a few moments, to see if the lockups are still there or not. no_wb=1 would only have been important for bisecting, to avoid the writeback endianness bug interfering. P.S. beware of Debian package udev version 169-1: IME an initrd generated with that installed prevents the radeon module from being loaded automatically, and when trying to load it manually, it fails to load the CP microcode and consequently fails to initialize acceleration. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [regression] blank screen with radeondrmfb on iMac G5 (ALS)
On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
j...@users.sourceforge.net wrote:
Hello,
I found a regression in Linux 2.6.37.2 - I know this report comes quite
late, but I had no time to investigate until now. And I found that this
still persists up to 2.6.39 :(
When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
remained blank.
There were only a few Radeon specific changes between these two versions, so
that I could quickly identify the cause. It's commit
ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
(9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
with a simple patch, it works properly again:
--- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
+++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1515,11 +1515,6 @@
(rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev-pdev-device == 0x4150)
- (rdev-pdev-subsystem_vendor == 0x1002)
- (rdev-pdev-subsystem_device == 0x4150)) {
- /* Mac G5 9600 */
- rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
#endif /* CONFIG_PPC_PMAC */
#ifdef CONFIG_PPC64
This is a diff from the dmesg [without my patch] - [with my patch]:
[drm] ring test succeeded in 0 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
-[drm] Connector Table: 12 (mac g5 9600)
-[drm] No valid Ext TMDS info found in BIOS
-[drm] No TV DAC info found in BIOS
+[drm] Connector Table: 1 (generic)
[drm] No TMDS info found in BIOS
+[drm] No TV DAC info found in BIOS
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I
[drm] HPD1
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
-[drm] DFP2: INTERNAL_DVO1
+[drm] DFP1: INTERNAL_TMDS1
[drm] CRT2: INTERNAL_DAC2
[drm] Connector 1:
-[drm] DVI-I
-[drm] HPD2
+[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
-[drm] DFP1: INTERNAL_TMDS1
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 2:
[drm] S-video
On which kind of machines was the original commit tested/supposed to work?
Do you see a possibility to fix this in a proper way upstream?
It was a 9600 from a G5, I don't recall which one. Thank apple for
making multiple systems all wired up differently with the same pci
ids. I suppose to fix it properly we'll need some way of identifying
the specific machine. Are there specific ids for each g5 for
of_machine_is_compatible()?
Alex
Thanks and regards,
Joachim Henke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #17 from Rogério Brito rbr...@ime.usp.br 2011-05-21 15:34:37 --- Hi, Michel. Thank you very much for the attention. (In reply to comment #16) When the kernel radeon driver fails to initialize acceleration, there's no point in trying any functionality that needs acceleration, such as XVideo. OK. I don't think there's any point doing any more tests with 2.6.39-rc7, as it's obviously suffering from additional issues which only occurred intermittently during the 2.6.39 cycle. Right. Well, I'm afraid less quantity but more quality would be better... It's becoming rather difficult and time-consuming to find the relevant pieces of information in this mass. Indeed, it is getting out of hand pretty quickly. Do you want me to give you some SSH access to this notebook? Or, if that's not feasible/useful, what would you like me to test as the next step, so that I avoid flooding you with so much data? Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? I will try those. But with which kernel? I have been avoiding compiling a kernel nowadays, since they take ages on this notebook, but I can set up a cross-compilation environment, if necessary. BTW, would you mind sharing your .config? I thought there was some kind of multimedia adapter for the external output. The only external adapter is one to a VGA port. No traces of S-video here. But really, we need to focus on one problem per bug report as much as possible, or things are getting out of hand. OK, I can file a separate bug for this S-Video issue, then. Thank you so much for your patience, Rogério Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #18 from Alex Deucher alexdeuc...@gmail.com 2011-05-21 15:38:57 --- apples sells VGA to s-video adapters, so we list both connectors in the driver. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Major 2.6.38 regression ignored?
On Sat, 21 May 2011 11:23:53 -0400, Luke-Jr l...@dashjr.org wrote: On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote: On Fri, 20 May 2011 11:08:56 -0700, Ray Lee ray...@madrabbit.org wrote: [ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki to the message ] On Fri, May 20, 2011 at 10:06 AM, Luke-Jr l...@dashjr.org wrote: I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago against 2.6.38. Now 2.6.39 was just released without the regression being addressed. This bug makes the system unusable... Some guys on IRC suggested I email, so here it is. See the bugzilla entry for the bisection history. Which has nothing to do with Luke's bug. Considering the thousand things that can go wrong during X starting, without a hint as to which it is nigh on impossible to debug except by trial and error. If you set up netconsole, does the kernel emit an OOPS with it's last dying breath? Why assume it's a different bug? I would almost wonder if it might affect all Sandy Bridge GPUs. In any case, I no longer have the original motherboard (it was recalled, as I said in the first post), nor even the revision of it (it had other issues that weren't being fixed). I *assume* I will have the same problem with my new motherboard (Intel DQ67SW), but I haven't verified that yet. I'll be sure to try a netconsole when I have to reboot next and get a chance to try the most recent 2.6.38 and .39 kernels, but at the moment it seems reasonable to address the problem bisected in the bug, even if it turns out to be different. The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate locking between release and IRQ and so is prone to such races as befell Kirill should not surprise anyone. As neither UMS nor DRI supported SNB, I can quite confidently state they are separate bugs. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [regression] blank screen with radeondrmfb on iMac G5 (ALS)
On Sam, 2011-05-21 at 11:14 -0400, Alex Deucher wrote:
On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
j...@users.sourceforge.net wrote:
Hello,
I found a regression in Linux 2.6.37.2 - I know this report comes quite
late, but I had no time to investigate until now. And I found that this
still persists up to 2.6.39 :(
When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
remained blank.
There were only a few Radeon specific changes between these two versions, so
that I could quickly identify the cause. It's commit
ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
(9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
with a simple patch, it works properly again:
--- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
+++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1515,11 +1515,6 @@
(rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev-pdev-device == 0x4150)
- (rdev-pdev-subsystem_vendor == 0x1002)
- (rdev-pdev-subsystem_device == 0x4150)) {
- /* Mac G5 9600 */
- rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
#endif /* CONFIG_PPC_PMAC */
#ifdef CONFIG_PPC64
This is a diff from the dmesg [without my patch] - [with my patch]:
[drm] ring test succeeded in 0 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
-[drm] Connector Table: 12 (mac g5 9600)
-[drm] No valid Ext TMDS info found in BIOS
-[drm] No TV DAC info found in BIOS
+[drm] Connector Table: 1 (generic)
[drm] No TMDS info found in BIOS
+[drm] No TV DAC info found in BIOS
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I
[drm] HPD1
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
-[drm] DFP2: INTERNAL_DVO1
+[drm] DFP1: INTERNAL_TMDS1
[drm] CRT2: INTERNAL_DAC2
[drm] Connector 1:
-[drm] DVI-I
-[drm] HPD2
+[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
-[drm] DFP1: INTERNAL_TMDS1
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 2:
[drm] S-video
On which kind of machines was the original commit tested/supposed to work?
Do you see a possibility to fix this in a proper way upstream?
It was a 9600 from a G5, I don't recall which one.
Probably a tower.
Thank apple for making multiple systems all wired up differently with the
same pci
ids. I suppose to fix it properly we'll need some way of identifying
the specific machine. Are there specific ids for each g5 for
of_machine_is_compatible()?
Yeah, they should have distinct identifiers, visible on
the /proc/cpuinfo model/machine/motherboard lines.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Major 2.6.38 regression ignored?
I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago against 2.6.38. Now 2.6.39 was just released without the regression being addressed. This bug makes the system unusable... Some guys on IRC suggested I email, so here it is. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Major 2.6.38 regression ignored?
[ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki to the message ] On Fri, May 20, 2011 at 10:06 AM, Luke-Jr l...@dashjr.org wrote: I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago against 2.6.38. Now 2.6.39 was just released without the regression being addressed. This bug makes the system unusable... Some guys on IRC suggested I email, so here it is. See the bugzilla entry for the bisection history. ~r. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Major 2.6.38 regression ignored?
2011/5/20 Rafael J. Wysocki r...@sisk.pl It is on the list of known regressions from 2.6.37, but we're not tracking them any more now that 2.6.39 is out. Hopefully Chris is still tracking them, even if you aren't. Chris? What other information can the affected person provide, or what tests can he run to help close this out? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[regression] blank screen with radeondrmfb on iMac G5 (ALS)
Hello,
I found a regression in Linux 2.6.37.2 - I know this report comes quite
late, but I had no time to investigate until now. And I found that this
still persists up to 2.6.39 :(
When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
remained blank.
There were only a few Radeon specific changes between these two versions, so
that I could quickly identify the cause. It's commit
ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
(9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
with a simple patch, it works properly again:
--- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
+++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1515,11 +1515,6 @@
(rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev-pdev-device == 0x4150)
- (rdev-pdev-subsystem_vendor == 0x1002)
- (rdev-pdev-subsystem_device == 0x4150)) {
- /* Mac G5 9600 */
- rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
#endif /* CONFIG_PPC_PMAC */
#ifdef CONFIG_PPC64
This is a diff from the dmesg [without my patch] - [with my patch]:
[drm] ring test succeeded in 0 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
-[drm] Connector Table: 12 (mac g5 9600)
-[drm] No valid Ext TMDS info found in BIOS
-[drm] No TV DAC info found in BIOS
+[drm] Connector Table: 1 (generic)
[drm] No TMDS info found in BIOS
+[drm] No TV DAC info found in BIOS
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I
[drm] HPD1
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
-[drm] DFP2: INTERNAL_DVO1
+[drm] DFP1: INTERNAL_TMDS1
[drm] CRT2: INTERNAL_DAC2
[drm] Connector 1:
-[drm] DVI-I
-[drm] HPD2
+[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
-[drm] DFP1: INTERNAL_TMDS1
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 2:
[drm] S-video
On which kind of machines was the original commit tested/supposed to work?
Do you see a possibility to fix this in a proper way upstream?
Thanks and regards,
Joachim Henke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Major 2.6.38 regression ignored?
On Saturday, May 21, 2011 4:41:45 AM Chris Wilson wrote: On Fri, 20 May 2011 11:08:56 -0700, Ray Lee ray...@madrabbit.org wrote: [ Adding Chris Wilson (author of the problematic patch) and Rafael Wysocki to the message ] On Fri, May 20, 2011 at 10:06 AM, Luke-Jr l...@dashjr.org wrote: I submitted https://bugzilla.kernel.org/show_bug.cgi?id=33662 a month ago against 2.6.38. Now 2.6.39 was just released without the regression being addressed. This bug makes the system unusable... Some guys on IRC suggested I email, so here it is. See the bugzilla entry for the bisection history. Which has nothing to do with Luke's bug. Considering the thousand things that can go wrong during X starting, without a hint as to which it is nigh on impossible to debug except by trial and error. If you set up netconsole, does the kernel emit an OOPS with it's last dying breath? Why assume it's a different bug? I would almost wonder if it might affect all Sandy Bridge GPUs. In any case, I no longer have the original motherboard (it was recalled, as I said in the first post), nor even the revision of it (it had other issues that weren't being fixed). I *assume* I will have the same problem with my new motherboard (Intel DQ67SW), but I haven't verified that yet. I'll be sure to try a netconsole when I have to reboot next and get a chance to try the most recent 2.6.38 and .39 kernels, but at the moment it seems reasonable to address the problem bisected in the bug, even if it turns out to be different. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #20 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:47:10 --- Created an attachment (id=58922) -- (https://bugzilla.kernel.org/attachment.cgi?id=58922) Allow forcing on all GPU clocks (In reply to comment #17) Has either of you tried agpmode=1 dynclks=1? Does that increase stability at all? I will try those. But with which kernel? 2.6.38 should be fine for this test. But at some point it'll probably be useful for you to be able to try kernel patches. Once you've built a kernel, building the radeon module with a patch shouldn't take long. E.g., you guys could try this patch, and booting with radeon.dynclks=0, which should force on all GPU clocks. Does that increase stability with agpmode=1 or agpmode=-1? BTW, would you mind sharing your .config? My .config still takes 1-2 hours to build on this 1.6 GHz PowerBook. If that could help you, please ask for it on the debian-powerpc list. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34772] [radeon] [R300] GPU lockups with when KMS is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=34772 --- Comment #21 from Michel Dänzer mic...@daenzer.net 2011-05-21 16:58:59 --- Would also be interesting if one of you guys could attach dmesg with agpmode=1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Major 2.6.38 regression ignored?
On Saturday, May 21, 2011 11:40:17 AM Chris Wilson wrote: The bisection is into an old DRI1 bug on 945GM. That DRI has inadequate locking between release and IRQ and so is prone to such races as befell Kirill should not surprise anyone. As neither UMS nor DRI supported SNB, I can quite confidently state they are separate bugs. Unfortunately, I cannot help troubleshoot that bug any further, as I no longer have the affected motherboard. I was unable to reproduce it on my Intel DQ67SW. However, I did encounter a new regression, which I have reported as: https://bugzilla.kernel.org/show_bug.cgi?id=35552 This one is related to Intel HD Audio, not Graphics. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [regression] blank screen with radeondrmfb on iMac G5 (ALS)
On 05/21/11 17:14, Alex Deucher wrote:
On Sat, May 21, 2011 at 8:21 AM, Joachim Henke
j...@users.sourceforge.net wrote:
Hello,
I found a regression in Linux 2.6.37.2 - I know this report comes quite
late, but I had no time to investigate until now. And I found that this
still persists up to 2.6.39 :(
When I upgraded from 2.6.37 to 2.6.37.3, after reboot my machine came up
with a blank/black screen (backlight on). It's an iMac G5 (Ambient Light
Sensor) with a Radeon 9600 (RV350). After Xorg had started, the screen
remained blank.
There were only a few Radeon specific changes between these two versions, so
that I could quickly identify the cause. It's commit
ce9eb2c297f918be46e36dd86b7e88cabdc3e22df
(9fad321ac6bedd96f449754a1a25289ea1789a49 upstream). After reverting this
with a simple patch, it works properly again:
--- linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c.orig
+++ linux-2.6.39/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1515,11 +1515,6 @@
(rdev-pdev-subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev-mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev-pdev-device == 0x4150)
- (rdev-pdev-subsystem_vendor == 0x1002)
- (rdev-pdev-subsystem_device == 0x4150)) {
- /* Mac G5 9600 */
- rdev-mode_info.connector_table = CT_MAC_G5_9600;
} else
#endif /* CONFIG_PPC_PMAC */
#ifdef CONFIG_PPC64
This is a diff from the dmesg [without my patch] - [with my patch]:
[drm] ring test succeeded in 0 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
-[drm] Connector Table: 12 (mac g5 9600)
-[drm] No valid Ext TMDS info found in BIOS
-[drm] No TV DAC info found in BIOS
+[drm] Connector Table: 1 (generic)
[drm] No TMDS info found in BIOS
+[drm] No TV DAC info found in BIOS
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] DVI-I
[drm] HPD1
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
-[drm] DFP2: INTERNAL_DVO1
+[drm] DFP1: INTERNAL_TMDS1
[drm] CRT2: INTERNAL_DAC2
[drm] Connector 1:
-[drm] DVI-I
-[drm] HPD2
+[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
-[drm] DFP1: INTERNAL_TMDS1
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 2:
[drm] S-video
On which kind of machines was the original commit tested/supposed to work?
Do you see a possibility to fix this in a proper way upstream?
It was a 9600 from a G5, I don't recall which one. Thank apple for
making multiple systems all wired up differently with the same pci
ids. I suppose to fix it properly we'll need some way of identifying
the specific machine. Are there specific ids for each g5 for
of_machine_is_compatible()?
Alex
Thanks for your fast reply! FYI, this is what /proc/cpuinfo tells:
platform: PowerMac
model : PowerMac8,2
machine : PowerMac8,2
motherboard : PowerMac8,2 MacRISC4 Power Macintosh
But instead of excluding this model, it's probably better to only include
the model the patch was originally written for - in case there are other
systems which got broken ;)
Thanks and regards,
Joachim Henke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #19 from Bob Ham r...@bash.sh 2011-05-21 19:55:50 PDT --- I recalled that I had played Warzone 2100 (a GL game) some time ago. Looking at the time stamps on the save game files, I found which kernel I was using at the time (2.6.36). From there, I've done a git bisect using Linus' tree. This is the output: rah@myrtle:/usr/src/linus$ git bisect good 6f34be50bd1bdd2ff3c955940e033a80d05f248a is the first bad commit commit 6f34be50bd1bdd2ff3c955940e033a80d05f248a Author: Alex Deucher alexdeuc...@gmail.com Date: Sun Nov 21 10:59:01 2010 -0500 drm/radeon/kms: add pageflip ioctl support (v3) This adds support for dri2 pageflipping. v2: precision updates from Mario Kleiner. v3: Multihead fixes from Mario Kleiner; missing crtc offset add note about update pending bit on pre-avivo chips Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de Signed-off-by: Dave Airlie airl...@redhat.com :04 04 e5e9b7c6860a5ebba78346f3396791520a7842a4 2e9d672e24e579dc56c8f25b0ff883d88c09b7c4 M drivers -- 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
