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: