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

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' 
                ^                                   ^

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

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.

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

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?

I will take a look at the change logs but since I am not a professional
kernel maintainainer by a long way, I would greatly appreciate if you
could advise on the best course of action.

Thank you very much indeed for your help.

cga



-------------------------------------------------------------------------
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