Re: atyfb - system hangs at bootup prior to enabling framebuffer console -- linux 2.6.18

On Sat, Feb 24, 2007 at 02:35:57PM -0500, cga2000 wrote:
> On Sat, Feb 17, 2007 at 08:19:12AM EST, Ville Syrjälä wrote:
> > On Fri, Feb 16, 2007 at 06:37:31PM -0500, cga2000 wrote:
> > > More than 50% of the time my laptop hangs when booting with 
> > > 
> > > ... video=atyfb:1400x1050.
> > > 
> > > I have seen similar occurrences reported here and there with recent 2.6
> > > kernels but nothing very clear as to whether this is a known problem or
> > > whether a patch or workaround has already been provided.
> > 
> > I was just able to reproduce the problem by switching from drivers/ide 
> > to libata. In my case the laptop would hang on every boot. Apparently 
> > using libata changed the timing enough to trigger the bug.
> > 
> > Try this patch:
> > 
> > ---
> >  drivers/video/aty/mach64_ct.c |    9 +++------
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> > 
> > Index: linux-2.6.20/drivers/video/aty/mach64_ct.c
> > ===================================================================
> > --- linux-2.6.20.orig/drivers/video/aty/mach64_ct.c
> > +++ linux-2.6.20/drivers/video/aty/mach64_ct.c
> > @@ -598,7 +598,6 @@ static void aty_resume_pll_ct(const stru
> >  	struct atyfb_par *par = info->par;
> >  
> >  	if (par->mclk_per != par->xclk_per) {
> > -		int i;
> >  		/*
> >  		* This disables the sclk, crashes the computer as reported:
> >  		* aty_st_pll_ct(SPLL_CNTL2, 3, info);
> > @@ -609,12 +608,10 @@ static void aty_resume_pll_ct(const stru
> >  		aty_st_pll_ct(SCLK_FB_DIV, pll->ct.sclk_fb_div, par);
> >  		aty_st_pll_ct(SPLL_CNTL2, pll->ct.spll_cntl2, par);
> >  		/*
> > -		 * The sclk has been started. However, I believe the first clock
> > -		 * ticks it generates are not very stable. Hope this primitive loop
> > -		 * helps for Rage Mobilities that sometimes crash when
> > -		 * we switch to sclk. (Daniel Mantione, 13-05-2003)
> > +		 * The sclk has been started. Wait for the PLL to lock. 5 ms
> > +		 * should be enough according to mach64 programmers guide.
> >  		 */
> > -		for (i=0;i<=0x1ffff;i++);
> > +		mdelay(5);
> >  	}
> >  
> >  	aty_st_pll_ct(PLL_REF_DIV, pll->ct.pll_ref_div, par);
> 
> I managed to make some progress on this issue.
> 
> 1. I tried to apply the patch to the 2.6.18 kernel and but it failed.
> 
> 2. I took a look at the source and it looks like there was at least one
>    intervening patch between 2.6.18 and 2.6.20. The .. par->mclk_per !=
>    .. test appears to have been reversed: 
> 
>    '.. mclk_per == par->xclk_per) .. instead of '.. != par->xclk_per' 
>                 ^                                   ^

The test has been reversed because in 2.6.18 the busy loop is in the 
'else' branch and in 2.6.20 it's in the 'if' branch.

> 3. I downloaded kernels 2.6.20 and 2.6.20.1 but patching failed on both
>    hunks.

IIRC I made the patch against 2.6.20 so it shouldn't have failed. Maybe 
your mail program corrupted the patch.

> 4. On the other hand, with these new versions, I was able to locate the
>    code in mach64_ct.c and manually made the changes.
>    
> 5. With your changes applied I rebooted at least a half a dozen times
>    and I never again experienced the hang.
> 
> 6. I obviously have not run the modified code for any length of time but
>    as far as I can tell the changes do not seem to cause any adverse
>    side-effects.

There should be no side effects as this code is only executed when the 
driver is initialized.

> So, as far as I am concerned, your patch fixes the problem.

Good. So that makes it three verified cases of fixing the bug.

> Now, since I have run into unrelated problems with the newer 2.6.20
> kernels I would much rather stick with 2.6.18 for now.
> 
> Are you aware of any intervening patches to mach64_ct.c that I could
> apply so as to bring the 2.6.18 code up to the more current level and
> then make your recommended changes, or is there more to it than just
> patching this particular program?

The changes to mach64_ct.c were due to my patch that fixed resume from 
suspend-to-ram. There were also other patches applied at the same time 
but none were critical in any sense. You can stick with 2.6.18 + the 
mdelay() fix.

-- 
Ville Syrjälä
[email protected]
http://www.sci.fi/~syrjala/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV