Very early on after the kernel loads, it switches the console resolution, presumably using KMS. With the Mageia 3 kernel, this works fine. With the Mageia 4 kernel, viewing the screen physically locally, it looks like it's frozen (just the one line about initializing the SAS adapter stays at the top), even though it's actually booting just fine. dmidecode says it has an embedded Matrox G200 Video card in the server. Reproducible: Steps to Reproduce:
Component: Release (media or process) => RPM Packages
Pasting specs from bug 13264 Dell PowerEdge R610 Intel Xeon X5670, 2 6-core CPUs with hyperthreading Intel ICH9 chipset Matrox G200eW WPCM450
Card:Matrox Millennium G series (single head): Matrox Electronics Systems Ltd.|MGA G200eW WPCM450 [DISPLAY_VGA] (vendor:102b device:0532 subv:1028 subd:0236) (rev: 0a)
Can you also attach a dmesg from that system
Created attachment 5134 [details] dmesg output
These lines look relevant: [ 4.574462] [drm:mga_vram_init] *ERROR* can't reserve VRAM [ 4.574467] mgag200 0000:06:03.0: Fatal error during GPU init: -6 I also see those with the 3.14.17 in updates_testing.
is uvesafb loaded on that system ? if so, does it help to blacklist it ?
It is not loaded.
Can you provide attach output of lsmod
Created attachment 5422 [details] lsmod output from Dell server
I just built 3.11.2 from our kernel package SVN revision 487545 and it works fine.
Ok, so there is minimal changes in the gpu code between 3.11 and 3.12, so maybe this is not really the gpu code that has been broken, but some acpi/mm/mtrr code change... Can you get a dmesg and lsmod from running the 3.11 kernel too
Created attachment 5423 [details] lsmod from 3.11.2
Created attachment 5424 [details] dmesg from 3.11.2
Not having luck booting the first kernel I built in the bisect process. When grub selects it, the screen immediately goes completely black, and then a minute later dracut prints a bunch of errors about devices not existing (UUIDs which correspond to my swap, /, and /usr partitions). Usually the first message is about the megasas raid adapter, so I'm guessing the one I built is failing to initialize the hardware raid adapter properly. I have no idea why, as I tried starting with the configs from both 3.11.2 and 3.12-rc5, which both at least do boot. My process for building and installing the kernel was extracted from our kernel spec, so maybe you can find some flaw in my process here, but it looks right to me. git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux git bisect start git bisect bad v3.12-rc5 git bisect good v3.11 cp /boot/config-3.12.0-desktop-0.rc5.1.mga4 .config make oldconfig make -j 24 -s all KernelVer=3.11.0 # based on the contents of the Makefile currently install -m 644 System.map /home/admin/bisect/boot/System.map-$KernelVer install -m 644 .config /home/admin/bisect/boot/config-$KernelVer xz -c Module.symvers > /home/admin/bisect/boot/symvers-$KernelVer.xz cp -f arch/x86/boot/bzImage /home/admin/bisect/boot/vmlinuz-$KernelVer make INSTALL_MOD_PATH=/home/admin/bisect KERNELRELEASE=$KernelVer modules_install rm -rf /home/admin/bisect/lib/firmware find /home/admin/bisect/lib/modules -name "*.ko" | xargs -P 24 xz -6e rm -f /home/admin/bisect/lib/modules/{build,source} pushd /home/admin/bisect/lib/modules /sbin/depmod -ae -b /home/admin/bisect -F /home/admin/bisect/boot/System.map-$KernelVer $KernelVer pushd $KernelVer modules=`find . -name "*.ko.[g,x]z"` echo $modules | xargs -P 24 /sbin/modinfo | perl -lne 'print "$name\t$1" if $name && /^description:\s*(.*)/; $name = $1 if m!^filename:\s*(.*)\.k?o!; $name =~ s!.*/!!' > modules.description popd popd pushd /home/admin/bisect tar -cvf ../${KernelVer}.tar lib/modules/$KernelVer boot/* popd su - cd / tar -xvf /home/admin/${KernelVer}.tar /sbin/installkernel $KernelVer
This really doesn't make sense. I thought maybe the upstream kernel just didn't work and it was some patch in the Mageia kernel that made it work, but kernel-linus 3.12 from mga4 boots. So, I don't understand why the one I built in Comment 14 won't boot. Regardless, I found a convoluted way to create a patch from 3.11.0 to the current contents of my git bisect and integrate that into our RPM build procedure, so I managed to build a kernel in an RPM that boots and works. So, step 1 => git bisect good.
I made it all the way through the git bisect and all of the kernels came up good. So, the issue was caused by a config change in our package, namely here: http://svnweb.mageia.org/packages/cauldron/kernel/current/PATCHES/configs/i386.config?r1=496716&r2=496715&pathrev=496716
Can you try to disable: CONFIG_FB_SIMPLE
(In reply to Thomas Backlund from comment #17) > Can you try to disable: CONFIG_FB_SIMPLE I've played with that option as well as CONFIG_X86_SYSFB. X86_SYSFB = n, FB_SIMPLE = n, works X86_SYSFB = y, FB_SIMPLE = y, doesn't work X86_SYSFB = y, FB_SIMPLE = n, doesn't work X86_SYSFB = n, FB_SIMPLE = y, works So the issue is actually X86_SYSFB, a new option that was added during 3.12 development, that when set to yes, breaks our server's console. FB_SIMPLE does have a slight noticeable impact, with it set to y, I can at least see that megasas adapter initialization message at the beginning, with FB_SIMPLE set to n, I can't even see that. So it appears FB_SIMPLE is better off staying as yes.
I rebuilt the mga4 updates_testing kernel with X86_SYSFB = n, and the display works again :D
See also https://forums.mageia.org/en/viewtopic.php?f=7&t=8450
(In reply to claire robinson from comment #20) > See also https://forums.mageia.org/en/viewtopic.php?f=7&t=8450 I haven't tried to run X on it. I would think that would be a different issue.
@David: There is now a kernel-3.14.19-1.mga4 building with X86_SYSFB disabled and also the interesting vfs fix I mentioned on irc X86_SYSFB is also disabled in Cauldron in the upcoming 3.17-rc7 kernel
Thanks Thomas! This is now running on our production Squid server.
Depends on: (none) => 14301
Fixed in http://advisories.mageia.org/MGASA-2014-0453.html
Status: NEW => RESOLVEDResolution: (none) => FIXED