| Summary: | initramfs generated from uncommon size pictures for gensplash crashes kernel | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | okay_awright <j> |
| Component: | [OLD] Core system | Assignee: | Michal Januszewski (RETIRED) <spock> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2004.2 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
okay_awright
2004-10-31 11:29:56 UTC
Can you try booting into 768x576 without any initramfs images and then manually enabling fbsplash (/etc/init.d/splash start) to see if this produces any unexpected behaviour? One more thing - what is the effect of using the initramfs image (ie. keeping the initrd line in grub.conf), but removing the splash= parameter from the kernel command line? I'll do this ASAP (max. few hours). Regarding the first comment, and as far as I can recall (and if i quite understand what you want), I've already tried something similar: when no initramfs is attached and the splash initialisation script is enabled, splash screen appears "on time" (I mean a few seconds after framebuffer drivers are loaded and fs are mounted) and while I'm logged (splash script launched) I can switch between virtual consoles with the correct background images assigned. No errors logged on start. Do you want me to disable splash init.d script on start and manually loading it? I'll keep you informed from what you asked. I've done what you requested. Concerning your first comment: I was/recalled wrong. The splash screen is displayed after the whole kernel stuff is loaded but once the userspace thingies are done and I try to start /etc/init.d/splash by hand I get a crash dump output (with the console theme in background it seems). Regarding your second one: the system loads flawlessly until the end but of course without any splash screen (if splash is part of the initialisation scripts to be charged then, obviously, it tells me that it cannot find the theme file /etc/splash/default/768x576.cfg but that's about everything) Crash dump? As in a kernel oops message? Could you save it to a file and post it here? It could be very helpful in determining what exactly is going wrong with fbsplash. sorry for the annoyance but I can't find (google) any info regarding any savecore emerge package. BTW I'm not fluent w/ the ebuild system yet, I'm a brand new gentoo user (only few days old). If you can help me on this specific point then I'll be glad to give you the full dump quickly. Nevertheless, and for the moment, I'll just try to copy this output by hand and post it here ASAP. What I'm asking is whether the error/crash dump/whatever messages you're seeing
look similar to this:
Oops: 0002 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in: r8169
CPU: 0
EIP: 0060:[<c01253d8>] Not tainted VLI
EFLAGS: 00010086 (2.6.9-rc4-mm1)
EIP is at profile_hit+0x28/0x30
eax: 0001aa2c ebx: da730aa0 ecx: 00000000 edx: 00000000
esi: c06abe60 edi: ffffffea ebp: da7f5f84 esp: da7f5f84
ds: 007b es: 007b ss: 0068
Process named (pid: 5773, threadinfo=da7f4000 task=da730aa0)
Stack: da7f5fbc c011ee4a 00000002 c0106cb3 00000004 da7f4000 de963d20 fffbfeef
fffffffe 00000082 00000000 0000168d bf7ffbe0 00000000 da7f4000 c0106cb3
0000168d 00000000 bf7ffcf8 bf7ffbe0 00000000 bf7ffbcc 0000009c 0000007b
Call Trace:
[<c0107bbf>] show_stack+0x7f/0xa0
[<c0107d5a>] show_registers+0x15a/0x1c0
[<c0107fc4>] die+0x164/0x2e0
If they do, it's a kernel oops, and assuming that your system remains operational, you can save the messages to a file by doing `dmesg > file` (you can then attach it to this bug or paste it in a comment). If it is not a kernel oops, please just copy any error messages you notice.
sorry for the misunderstanding, in fact this is a real kernel oops (similar in the form to this output). The resulting kernel is then really badly hung and unusable, no way to proceed to simple userland error dumping technics. I'm not currently in front of this box that's why i can't give you what you need for the moment. I'll post this as soon as i will be able to. thanks Ok, seems like you will have to just write some stuff down. To save the unnecessary work, here are the pieces of the oops that I actually need: 1) what caused the oops (this should be at the very top of the oops) Unable to handle kernel paging request at virtual address 0001aa2c printing eip: 2) what function was being executed when the oops happened EIP is at profile_hit+0x28/0x30 3) call trace [<c0107bbf>] show_stack+0x7f/0xa0 [<c0107d5a>] show_registers+0x15a/0x1c0 [<c0107fc4>] die+0x164/0x2e0 [<c011bcaf>] do_page_fault+0x34f/0x65e ... Oops: 0000 [#1] PREEMPT Modules linked in: mga_vid tda9887 tuner saa7134 video_buf ir_common CPU: 0 EIP: 0060:[<c024e38a>] Not tatinted VLI EFLAGS: 00010202 (2.6.9-gentoo-r1-freevo) EIP is at fbsplash_renderc+0x30a/0x3e0 eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000 esi: 00000000 edi: d2b33ffd ebp: d09c3ffd esp: cfba5d44 Process splash_util (pid: 8122, threadinfo=cfba5000 task=cfba4aa0) Stack: 00000300 00000018 00000900 c011530c cf243b20 cfbdf660 00000003 0000000f 00000007 014f9cc0 00000008 000002f8 ffffffff c1207000 c024e5c4 c04f9cc0 00000230 000002f8 00000010 00000008 cef1c220 00aaaaaa 00000000 00000001 Call Trace: [<c011530c>] do_page_fault+0x39c/0x599 [<c024e5c4>] fbsplash_putcs+0x164/0x1c0 [<c024ed6c>] splashfill+0x7c/0x90 [<c0247b99>] accel_putcs+0x709/0x740 [<c0247d36>] accel_clear_margins+0x166/0x170 [<c024ff1b>] fb_pan_display+0x5b/0x90 [<c025349c>] fb_set_cmap+0xbc/0xf0 [<c0248b36>] fbcon_putcs+0x96/0xb0 [<c023a770>] do_update_region+0x120/0x190 [<c023b4da>] redraw_screen+0x14a/0x250 [<c024d6c6>] fbsplash_enable+0xc6/0x110 [<c024deac>] splash_ioctl+0x1cc/0x210 [<c0233704>] inotify_dentry_parent_queue_event+0x64/0xa0 [<c016865f>] sys_ioctl+0xef/0x290 [<c010621b>] syscall_call+0x7/0xb Code: 83 dc fd ff ff f6 44 24 20 07 75 0c 8b 44 24 50 0f b6 08 40 59 44 24 50 84 c9 8b 44 24 54 One more thing - please post the output of `fbset -i`. mode "768x576-60"
# D: 38.313 MHz, H: 36.839 kHz, V: 59.999 Hz
geometry 768 576 768 7281 24
timings 26101 144 16 28 6 112 4
accel true
rgba 8/16,8/8,8/0,0/0
endmode
Frame buffer device information:
Name : MATROX
Address : 0xdc000000
Size : 16777216
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 2304
MMIO Address: 0xdfefc000
MMIO Size : 16384
Accelerator : Matrox G400
Have you tried activating fbsplash in 768x576 with a different-than-24bpp color depth (32bpp, 16bpp)? If you haven't, please try it and let me know of the results. sorry, this was something i didn't specify yet. If I use an initramfs in 768x576, no matter which color depth i'm using, the kernel hangs, still shouting that VFS can not open root device. Surprisingly, this doesn't happen in 1024x768 or 800x600 i.e. If I don't use an initramfs, boot splash is displayed but kernel crashes while the splash init script is called in 24bpp, whereas it works flawlessly in 16bpp or 32bpp. Only 24bpp is faulty (in 768x576) when virtual screens are being "decorated" using fbsplash. hope it'll help a little bit. This bug hasn't seen any activity for half a year now and I've just released a new version of splashutils that includes fixes for various bugs that could have been causing the 'unable to mount root fs' problem. I'm closing the bug with TEST-REQUEST. |
