Understood. I agree that not completely breaking virtual machines in some hypervisors is important. While I'm required to use bare-metal installs on these systems, I depend on VMs as much as the next person. There has to be an alternate solution.
Are you suggesting there's a kernel change needed that shouldn't load vesafb until later? Or are you saying I should set GRUB_TERMINAL=console and do something once it's booted? I can't modprobe vesafb now after all. Sorry if I'm a bit slow on the uptake here -- this is my first rodeo. I am primarily a C++ developer but I have not spent any time in the kernel before. Unfortunately I can't change the config in any way that would cause regression in production. That includes lowering the resolution or just using 80x24. They're pretty strict on both regression and security here. Also, there is no SSH to these boxes so any interaction I have with them is sitting physically in front of them. I got some more dmesg outputs and checked /proc/fb on each. 12.04 3.2 and 12.04 3.13 SYSFB=N displayed the same: 0 VESA VGA 12.04 3.13 SYSFB=Y was: 0 simple -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1434581 Title: Console extremely slow with 3.13 and newer kernels for certified servers with Matrox G200er2 or similar To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434581/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
