[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [!] 2.6.26 + vga=791

> From: David Witbrodt <dawitbro@sbcglobal.net>
> To: Hugo Vanwoerkom <hvw59601@care2.com>
> Sent: Saturday, August 2, 2008 11:41:47 AM
> Subject: Re: [!] 2.6.26 + vga=791
> > David Witbrodt wrote:
> > >>> So now I have to go item by item and investigate the diff in .config 
> > >>> files, which is vast because with my .config the kernel compiles in 12 
> > >>> minutes and with the Debian .config it takes 1 hour + 20 minutes!
> > >>   That is good news.  You may be getting close to a solution.
> > >>
> > >>   Might I suggestion the following incantation:
> > >>
> > >>     diff  -y      |  less
> > 
> > Good clue! But I am no closer and consider giving up: it would only be
> > useful if I found a kernel parameter for the cmdline to avoid being
> > without framebuffers.
> > 
> > Any other "fix" entails recompiling the Debian Kernel, e.g. in order to
> > install uvesfb you have to do that.
> > 
> > The last Debian kernel that ran with vga=791 was 2.6.24. So I did a diff
> > -y beteen that and 2.6.25 that does *not* allow vga=791. That file is here:
> > http://www.geocities.com/hugovanwoerkom/config-24-25-diff.txt
>   Well, from looking over your 'diff -y' output, it looks like the problem
> is either in some non-obvious config option, mostly likely before the
> section marked
>   # CPU Frequency scaling
> or in actual source code changes.  I remember trying to enable the faster
> "ywrap" feature of VESA FB, and ending up looking at the sources to find
> out why my boot parameter for "ywrap" was always rejected in favor of
> "redraw" -- and I discovered that drivers compiled 64-bits cannot talk
> to the 32-bit BIOS, so that VESA FB is unable to do mode changing or
> primitive acceleration (via BIOS calls) on "amd64" systems.  (This led
> me to trying UVESA FB, once it became available in the kernel, so that
> I could get my virtual terminals to run at a vertical refresh more
> suited to my monitor's health.
>   So, I know how you feel.  I just tried to compile the just-released
> 2.6.26-1 sources last night.  The resulting kernel runs fine on my desktop
> machine, but freezes early during the boot on the other machine.  I thought
> it was because I had enabled RAID drivers, so I can get software RAID to
> work, but disabling RAID did not help... and disabling LOTS of things
> has not helped.  When I installed the stock kernel (instead of building
> kernel after kernel myself) I discovered it wasn't a configuration problem
> at all -- the stock kernel was also freezing early in boot!  My 2.6.25
> kernels, stock and self-built, run just fine on exactly the same hardware,
> so it looks like some source code change between 2.6.25 and 2.6.26 rubs
> my hardware the wrong way.
> O.O
> '^'
>   I'm currently trying to isolate the problem so I can submit a useful
> bug report.  I see that kernel-archive.buildserver.net has a newer 
> snapshot to try, so I will spend the rest of my day off here trying to
> pin down the problem.  If all else fails, I can just remain at 2.6.25
> to have a perfectly working machine -- just like 2.6.24 is the one that
> works for you.
>   The big problem is that the DDs and kernel hackers don't have our
> hardware, and cannot reproduce our bugs.  They can see our bug reports,
> but without having our hardware where they can get their hands on it,
> sometimes all they can do is shrug and say, "Well, I can't reproduce
> the problem here.  Maybe someone else will fix it."  Your VESA FB 
> problem is particularly strange, and it would probably take a kernel
> hacker with 'gdb' less than 5 minutes to discover why "vga=791" is
> rejected, and maybe even fix it.
>   Bummer.
> Sorry I can't be of more help,
> Dave W.

Reply to: