> From: David Witbrodt <[EMAIL PROTECTED]> > To: Hugo Vanwoerkom <[EMAIL PROTECTED]> > 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.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
