Hi spock, Using fbsplash-0.9.2-r5-2.6.15-rc1.patch (from 2.6.15-archck1, and with radeonfb), i couldn't get the silent splash screen work during the early steps of the boot process: it was briefly appearing, but immediatly disappearring, and then reappearing much later (when the progress bar starts moving). It seems to be because of the order in which FB and AGP drivers get initialized. It can be fixed by reordering them in drivers/Makefile (move char/ before video/), like it was actually done in your previous patches. The issue and the attached fix has been confirmed by several users on f.g.o, with various kernel patchsets (gentoo-sources, suspend2-sources), and has been included in archck2: https://forums.gentoo.org/viewtopic-p-3033279.html#3033279 https://forums.gentoo.org/viewtopic-t-423405.html https://forums.gentoo.org/viewtopic-p-3036902.html#3036902
Created attachment 77325 [details, diff] 2.6.15-fbsplash-fix_drivers_Makefile_order.patch
I can confirm that the patch works here. Daniel, can we have this patch included in genpatches until the fbsplash patch gets updated?
I know from speakup that messing with the order in this file sometimes brings unexpected results. Would prefer confirmation from Michal first.
Because of the speakup issue Daniel has reported, I have tried to make some more specific changes, moving only char/agp/ before video/ but keeping other char drivers at their original place. Unfortunatly, in this setup the silent splash also disappears as soon as it has appeared. So my original diagnostic is wrong: it seems that AGP coming too late is not the cause of this issue, and I don't know what a less intrusive fix could be... I will attach the significant part of a diff beetween the dmesg outputs of a kernel without this patch (with broken silent fbsplash) and with this patch (with working silent fbsplash), in case it can give you ideas.
Created attachment 78067 [details] dmesg.diff The diff i talked about in comment #4.
Hadn't thought of that before, but if the problem is with speakup only, a solution could be to remove the "speakup/" target from drivers/char/Makefile, and to add "char/speakup/" directly in drivers/Makefile instead, at a suitable place (where "char/" currently is).
I'm not sure if it's the same symptom, but having just upgraded from gentoo-sources-2.6.14-r5 to gentoo-sources-2.6.15-r1 without any config changes, early silent fbsplash stopped working. Also, general framebuffer speed is slow.
Hello, I confirm that 2.6.15 + K_GENPATCHES_VER="5" solves this issue. Validated against suspend2-sources.
501_fbsplash-early-splash-fix.patch (i.e. attachment 77325 [details, diff]) is genpatches 5 is preventing my system from booting with suspend2-sources-2.6.15-r5. The last message I see is: Freeing unused kernel memory: 596k freed It then looks like the display begins to scroll because the result is that this message appears twice at the bottom of the display. The system then hangs and MagicSysRq does nothing. I'm not using fbsplash.
Created attachment 78777 [details] boot hang kernel config
(In reply to comment #9) > 501_fbsplash-early-splash-fix.patch (i.e. attachment 77325 [details, diff] [edit]) is genpatches 5 is > preventing my system from booting with suspend2-sources-2.6.15-r5. Please try to reproduce this with latest gentoo-sources (2.6.15-r2).
*** Bug 121508 has been marked as a duplicate of this bug. ***
For what it's worth, I had a closer look at this problem and decided that moving char/ before video/ in the Makefile is the only reasonable way to make it work.
When will this be part of the general fbsplash patch for the gentoo-sources? For now the current gentoo-sources tree is suffering from this problem.
My mistake for not reading all my email, spock had responded: Fortunately, no digging should be needed anymore :) The problem is fixed in 2.6.15-r2.
fixed in genpatches 2.6.15 and in the new 2.6.16-rc1 patch
Created attachment 78912 [details] boot hang gentoo-sources-2.6.15-r2 config gentoo-sources 2.6.15-r2 and -r3 hang on boot also. I did not apply any kernel patches and used the kernel's default initramfs. The last line I see is VFS: mounted root (reiserfs filesystem) readonly repeated, apparently just as radeonfb first begins to scroll (but there are plenty of other things happening at that time).
Karl: gentoo-sources 2.6.14 was also using this Makefile reordering (checked on -r7), so i wonder: does it hang too?
Karl: since your problem seems to be related with scrolling somehow, you might want to try booting with the 'quiet' option in your kernel command line.
TGL: good point. 2.6.14 was working well with this reordering. Michal: quiet sounds a good way to determine whether scrolling is the issue. I'll try to remember that next time I reboot.
'quiet' enabled the system to boot fine, and then the fb scrolled successfully. I've opened Bug 122074 for this issue as it could be quite unrelated to the patch in this bug.
