On Sat, Feb 17, 2007 at 12:14:25PM EST, 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);
>
> Thanks.
>
> I was planning on streamlining my new 2.6.18 kernel over the weekend so
> I should be able to report back to you by Monday.
Well I did succeed in streamlining my kernel+modules .. reducing the
size of the /usr/src/ tree from 600 Meg to about 275 .. but then it took
me two days and a night to get it to boot. I think the problem was
partly something that I inadvertently excluded or compiled as a module
in menuconfig .. with so many options that I modified it's easy to hit
the space bar one too many times .. and then I think I was mostly
getting confused by the "debian way" of compiling and installing new
kernels.
In any event, it's now 2:30 in the morning .. I have a kernel that takes
about 45 minutes to compile instead of four hours and doesn't panic ..
but I haven't found the time yet to apply your patch. The worst of it
is that I probably won't have another window of opportunity to work on
this for another two weeks or so.
It also looks like I may have to modify the patch for the 2.6.18 kernel.
I wouldn't mind giving 2.6.20 a shot but then some of the complementary
debian packages such as initrd-tools might not be in sync with the newer
version.
Regarding atyfb, I did have the time to notice two rather disturbing
things, though.
First of all since I was wasting a lot of time rebooting into my sarge
system or my fully-fledged, non-streamlined custom 2.6 kernel to bypass
the hang that the patch will address (*) .. I eventually figured I
should try to change the video=atyfb:1400x1050 to a vga= specification
on the fly by editing the grub "kernel" statement and much to my suprise
and though I got both the atyfb and then the vesafb messages on the
console it appears that atyfb "won" so to speak: although I had
specified vga=791 I was clearly switched to the 1400x1050 mode (rather
than 1024x768).
Then, since the "debian way" of installing new kernels automatically
updates your /boot/grub/menu.lst .. you have to remember to go and edit
it and add the "video=atyfb:1400x1050" manually every time you install a
new kernel. Now the weird thing is that at one point I accidentally
added the "atyfb" bit to the "title" statement instead of the "kernel"
statement. And yet atyfb guessed my "intentions" and automagically
switched me to 1400x1050.
So basically in both cases I was either telling the kernel/atyfb two
different things or not telling it anything at all and yet it appears to
have detected the native resolution of my display and enabled the
1400x1050 mode automatically.
Am I correct in assuming the above .. I mean .. is this how it works ..
Is this new with the current kernels & new versions of atyfb?
Thanks,
cga
(*) I boot a 2.6.18 kernel and reproduce the hang .. then say, I boot it
again .. I hang again as you would expect .. So, naturally I would then
boot the 2.4.27 kernel .. and then reboot the 2.6.18 kernel .. and this
time atyfb smoothly switches to the fb console as if nothing had
happened. In my case (fortunately ..) it seems to be systematic. No
idea whether this may be of interest or not.
|