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

On Sun, Feb 25, 2007 at 06:11:21AM EST, Ville Syrjälä wrote:
> 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:
[..]
> > 
> > 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.

This is why I assumed that there was an intervening patch (or patches)
between 2.6.18 and 2.6.20.  So I was not too happy about making the
change to the 2.6.18 source thinking that the changes brought about by
the intervening patch(es) might be needed for your new patch to work
correctly.

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

Oh, that it did .. but it was not so much mutt that broke the patch ..
more of a problem with our respective email encodings.  

But what I guessed regarding what "patch" was complaining about .. it
looked more like a problem with the line numbers -- the code is there
all right but the line numbers don't match.

But that's OK, since I have little HD space to spare and I don't plan
on maintaining a patched source tree alongside with the original.

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

A convincing argument.  I kinda suspected that, but then for all I knew,
it might set up things differently .. in ways that might resurface at a
later point in time.

> > So, as far as I am concerned, your patch fixes the problem.
> 
> Good. So that makes it three verified cases of fixing the bug.

Glad I could help.  

Being able to run the framebuffer console at my display's native
resolution made a world of difference and giving your patch a go was
the least I could do.

:-)

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

2.6.20 has some major problems with my pcmcia CD burner and I really do
not have the time to report/research them at this point.  And w/o the
CD burner I cannot back up my system.

So this is really excellent news.

Thank you very much for your help.

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