I've just built 3.15.0-rc2 on this box, and discovered that I get a
blank screen. The boot appears to complete (it sends me information
from SMART which is from my last bootscript), and it responds to
MagicSysRQ to reboot. I tried to login and run startx, but that
didn't seem to make any difference - possibly something went wrong,
it wasn't in my history when I booted a good kernel.
This machine uses a regular old VGA cable to connect it, the
following lines in dmesg make me think it has chosen the wrong
connector:
Apr 21 19:32:45 bluesbreaker kernel: [ 1.273246]
[drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed
Apr 21 19:32:45 bluesbreaker kernel: [ 1.273247]
[drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
Apr 21 19:32:45 bluesbreaker kernel: [ 1.295116] Console:
switching to colour frame buffer device 85x34
On a boot with 3.14.0 and earlier I get a different console size -
Apr 21 20:42:44 bluesbreaker kernel: [ 1.445992] Console:
switching to colour frame buffer device 133x54
My console font is 12x22, and my screen is 1600x1200 but it looks
as if 3.15-rc2 has fallen back to trying to use 1024x768.
I'm attaching what look like the relevant parts of the messages
from the system logs for 3.15-rc2 and 3.14.0.
Any ideas, please ? This is an AMD A4-5300 APU and not the world's
fastest machine for bisecting :-(
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
On Mon, Apr 21, 2014 at 4:32 PM, Ken Moffat <[email protected]> wrote:
> I've just built 3.15.0-rc2 on this box, and discovered that I get a
> blank screen. The boot appears to complete (it sends me information
> from SMART which is from my last bootscript), and it responds to
> MagicSysRQ to reboot. I tried to login and run startx, but that
> didn't seem to make any difference - possibly something went wrong,
> it wasn't in my history when I booted a good kernel.
>
> This machine uses a regular old VGA cable to connect it, the
> following lines in dmesg make me think it has chosen the wrong
> connector:
VGA is implemented as a DP to VGA bridge on APUs.
>
> Apr 21 19:32:45 bluesbreaker kernel: [ 1.273246]
> [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed
> Apr 21 19:32:45 bluesbreaker kernel: [ 1.273247]
> [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
> Apr 21 19:32:45 bluesbreaker kernel: [ 1.295116] Console:
> switching to colour frame buffer device 85x34
>
> On a boot with 3.14.0 and earlier I get a different console size -
> Apr 21 20:42:44 bluesbreaker kernel: [ 1.445992] Console:
> switching to colour frame buffer device 133x54
>
> My console font is 12x22, and my screen is 1600x1200 but it looks
> as if 3.15-rc2 has fallen back to trying to use 1024x768.
>
> I'm attaching what look like the relevant parts of the messages
> from the system logs for 3.15-rc2 and 3.14.0.
>
> Any ideas, please ? This is an AMD A4-5300 APU and not the world's
> fastest machine for bisecting :-(
I'd guess it's either the pll rework patches or the switch to the
common dp helper code patches. It would be helpful if you could
bisect.
Alex
On Mon, Apr 21, 2014 at 04:54:15PM -0400, Alex Deucher wrote:
> On Mon, Apr 21, 2014 at 4:32 PM, Ken Moffat <[email protected]> wrote:
> > I've just built 3.15.0-rc2 on this box, and discovered that I get a
> > blank screen. The boot appears to complete (it sends me information
> > from SMART which is from my last bootscript), and it responds to
> > MagicSysRQ to reboot. I tried to login and run startx, but that
> > didn't seem to make any difference - possibly something went wrong,
> > it wasn't in my history when I booted a good kernel.
> >
> > This machine uses a regular old VGA cable to connect it, the
> > following lines in dmesg make me think it has chosen the wrong
> > connector:
>
> VGA is implemented as a DP to VGA bridge on APUs.
>
> >
> > Apr 21 19:32:45 bluesbreaker kernel: [ 1.273246]
> > [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed
> > Apr 21 19:32:45 bluesbreaker kernel: [ 1.273247]
> > [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
> > Apr 21 19:32:45 bluesbreaker kernel: [ 1.295116] Console:
> > switching to colour frame buffer device 85x34
> >
> > On a boot with 3.14.0 and earlier I get a different console size -
> > Apr 21 20:42:44 bluesbreaker kernel: [ 1.445992] Console:
> > switching to colour frame buffer device 133x54
> >
> > My console font is 12x22, and my screen is 1600x1200 but it looks
> > as if 3.15-rc2 has fallen back to trying to use 1024x768.
> >
> > I'm attaching what look like the relevant parts of the messages
> > from the system logs for 3.15-rc2 and 3.14.0.
> >
> > Any ideas, please ? This is an AMD A4-5300 APU and not the world's
> > fastest machine for bisecting :-(
>
> I'd guess it's either the pll rework patches or the switch to the
> common dp helper code patches. It would be helpful if you could
> bisect.
>
> Alex
OK, I guess I can do the builds on a faster machine.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote:
[ resending, somehow lkml dropped out of the Cc. ]
> On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote:
> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
>
> > > Ken,
> > >
> > > You might want to try reverting:
> > >
> > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
> > > Author: Alex Deucher <[email protected]>
> > > Date: Mon Apr 7 10:33:46 2014 -0400
> > >
> > > drm/radeon/dp: switch to the common i2c over aux code
> > >
> > > Provides a nice cleanup in radeon.
> > >
> > > Signed-off-by: Alex Deucher <[email protected]>
> > > Signed-off-by: Christian König <[email protected]>
> > >
> > > This fixed a similar problem here (see the drm pull thread for rc1)
> > >
> > > Thanks
> > > Ed Tomlinson
> >
> > Tried reverting that from rc2, but it didn't help. Thanks anyway.
> >
>
> Well, I *believed* I had created a patch for that commit, and
> reverted it from -rc2 with patch -R. But I've now bisected through
> drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection
> pointed to that same commit, so I guess I did something wrong.
>
> There were a couple of other issues along the way (mounting nfs
> hung on one commit, startx hung on several of the commits, but I've
> marked those as "good" because I had a display, even if the system
> was not usable).
>
> I've now gone back to linus' tree that I cloned a few hours ago,
> i.e.
> commit c089b229dfdd09d59a11d8bc2344bf8196d575ce
> Merge: 9ac03675010a 0565103d1adb
> Author: Linus Torvalds <[email protected]>
> Date: Mon Apr 21 10:05:35 2014 -0700
>
> Merge branch 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
>
> created a branch, and *definitely* reverted
> 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that
> branch. And this version works fine.
>
> So belatedly I see that I seem to have the same problem as Ed. Or
> at least that the same commit is causing both our problems.
>
> Alex - do you need any more information from me to help with this ?
>
> ĸen
> --
> das eine Mal als Tragödie, dieses Mal als Farce
--
das eine Mal als Tragödie, dieses Mal als Farce
On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat <[email protected]> wrote:
> On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote:
>
> [ resending, somehow lkml dropped out of the Cc. ]
>
>> On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote:
>> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
>>
>> > > Ken,
>> > >
>> > > You might want to try reverting:
>> > >
>> > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
>> > > Author: Alex Deucher <[email protected]>
>> > > Date: Mon Apr 7 10:33:46 2014 -0400
>> > >
>> > > drm/radeon/dp: switch to the common i2c over aux code
>> > >
>> > > Provides a nice cleanup in radeon.
>> > >
>> > > Signed-off-by: Alex Deucher <[email protected]>
>> > > Signed-off-by: Christian König <[email protected]>
>> > >
>> > > This fixed a similar problem here (see the drm pull thread for rc1)
>> > >
>> > > Thanks
>> > > Ed Tomlinson
>> >
>> > Tried reverting that from rc2, but it didn't help. Thanks anyway.
>> >
>>
>> Well, I *believed* I had created a patch for that commit, and
>> reverted it from -rc2 with patch -R. But I've now bisected through
>> drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection
>> pointed to that same commit, so I guess I did something wrong.
>>
>> There were a couple of other issues along the way (mounting nfs
>> hung on one commit, startx hung on several of the commits, but I've
>> marked those as "good" because I had a display, even if the system
>> was not usable).
>>
>> I've now gone back to linus' tree that I cloned a few hours ago,
>> i.e.
>> commit c089b229dfdd09d59a11d8bc2344bf8196d575ce
>> Merge: 9ac03675010a 0565103d1adb
>> Author: Linus Torvalds <[email protected]>
>> Date: Mon Apr 21 10:05:35 2014 -0700
>>
>> Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
>>
>> created a branch, and *definitely* reverted
>> 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that
>> branch. And this version works fine.
>>
>> So belatedly I see that I seem to have the same problem as Ed. Or
>> at least that the same commit is causing both our problems.
>>
>> Alex - do you need any more information from me to help with this ?
The attached patch should fix it.
Thanks,
Alex
On Tuesday 22 April 2014 01:54:01 Alex Deucher wrote:
> On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat <[email protected]> wrote:
> > On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote:
> >
> > [ resending, somehow lkml dropped out of the Cc. ]
> >
> >> On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote:
> >> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
> >>
> >> > > Ken,
> >> > >
> >> > > You might want to try reverting:
> >> > >
> >> > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
> >> > > Author: Alex Deucher <[email protected]>
> >> > > Date: Mon Apr 7 10:33:46 2014 -0400
> >> > >
> >> > > drm/radeon/dp: switch to the common i2c over aux code
> >> > >
> >> > > Provides a nice cleanup in radeon.
> >> > >
> >> > > Signed-off-by: Alex Deucher <[email protected]>
> >> > > Signed-off-by: Christian König <[email protected]>
> >> > >
> >> > > This fixed a similar problem here (see the drm pull thread for rc1)
> >> > >
> >> > > Thanks
> >> > > Ed Tomlinson
> >> >
> >> > Tried reverting that from rc2, but it didn't help. Thanks anyway.
> >> >
> >>
> >> Well, I *believed* I had created a patch for that commit, and
> >> reverted it from -rc2 with patch -R. But I've now bisected through
> >> drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection
> >> pointed to that same commit, so I guess I did something wrong.
> >>
> >> There were a couple of other issues along the way (mounting nfs
> >> hung on one commit, startx hung on several of the commits, but I've
> >> marked those as "good" because I had a display, even if the system
> >> was not usable).
> >>
> >> I've now gone back to linus' tree that I cloned a few hours ago,
> >> i.e.
> >> commit c089b229dfdd09d59a11d8bc2344bf8196d575ce
> >> Merge: 9ac03675010a 0565103d1adb
> >> Author: Linus Torvalds <[email protected]>
> >> Date: Mon Apr 21 10:05:35 2014 -0700
> >>
> >> Merge branch 'for-linus' of
> >> git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
> >>
> >> created a branch, and *definitely* reverted
> >> 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that
> >> branch. And this version works fine.
> >>
> >> So belatedly I see that I seem to have the same problem as Ed. Or
> >> at least that the same commit is causing both our problems.
> >>
> >> Alex - do you need any more information from me to help with this ?
>
> The attached patch should fix it.
And it does here (on bonaire, r7 260x). You can add my tested by
Tested-by: Ed Tomlinson <[email protected]>
Thanks,
Ed Tomlinson
On Tue, Apr 22, 2014 at 01:54:01AM -0400, Alex Deucher wrote:
>
> The attached patch should fix it.
>
> Thanks,
>
> Alex
> From 9cd764fd57bb2a4e5f618d0f8a64c8154a820688 Mon Sep 17 00:00:00 2001
> From: Alex Deucher <[email protected]>
> Date: Tue, 22 Apr 2014 01:49:28 -0400
> Subject: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
>
Sorry, my default mailbox (the one where personal mail ends up)
overflowed (the old "procmail thinks it cannot write to it" issue)
and I've been reading mail on my netbook with a short 24-line term,
didn't notice that my overflow mailbox had appeared because it was
on the next screen. So, sorry for not replying.
And then when I did notice, I accidentally sent a personal reply
only to Ed.
The good news is that -rc3 obviously has the fix, and is working
fine. Thanks.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce