=== bjf is now known as bjf-afk [08:22] ogra: I'm -pretty sure- I tried 2.6.31-100 already with that eth issue, but I'll double check tomorrow [08:23] ok, the bug only mentions -5-imx51 or so [08:23] which was definately not a complete imx51 merge [08:24] hmm [08:24] -5- is wrong, I wonder if i typo'd that [08:24] one sec [08:25] -100 might have other ethernet probs though [08:25] i know amitk is working on the NIC driver [08:26] hmm, -5- might have been correct; regardless, I'll verify with -100 [08:27] I haven't had a chance to set up a cross compile env yet, but I'll do that and instrument the fec driver with some debug printks as well, see where it's dying [08:27] cool [08:27] it's probably something relatively simple [12:04] usplash ! [12:05] What? it works now? [12:06] if i run it manually from vt it does [12:06] *but* it needs to have the resolution from cmdline in usplash.conf [12:07] if there is none or a different one, the board dies [12:07] (babbage that is) [12:08] i guess we can add something to casper that reads cmdline for mxcfb and creates a usplash.conf [12:12] given that there is no way to use xrandr and there is no DDC detection either at least [12:19] ogra: Perhaps we just need to fix that crash? [12:24] well, you wont be able to display 800x600 on a 1024x768 framebuffer i guess [12:24] at least with the mxcfb driver [12:25] lets see if i can run it from initramfs as well if usplash.conf exists [12:27] bah, setting break=top doesnt work ... [12:27] * ogra changes to break=bottom to have usbhid [12:32] WHOPEEEE !!! [12:32] works ! [12:33] * ogra has a boot with usplash, xsplash and all working in the current babbage live image [12:33] lool, the bug is in mxcfb not in usplash, thats tricky to fix i think [12:33] ogra: is it that you were able to have xorg in a qemu emulated environment ? [12:34] mxcfb currently doesnt even display anything if it doesnt get the resolution from cmdline [12:34] ogra: sorry for my absence after my patch, but i've been busy with my degree [12:34] goshawk, i havent used qemu-system-arm for ages, last time i used it X worked though [12:35] lool, the only way i see with the current driver is to add another case statement for mxcfb to the usplash script in initramfs [12:36] err s/usplash/framebuffer/ [12:37] lool, /usr/share/initramfs-tools/scripts/init-top/framebuffer along the matroxfb and uvesafb special cases [13:02] ogra: Well depends of the change [13:02] call ? [13:02] Right [13:03] i would just export xres and yres from the OPTS [13:03] usplash will pick that up === cbrake_away is now known as cbrake [13:45] lool, the usplash script in initramfs has just: [13:45] if [ ! -d /sys/class/drm/card0/device/graphics/fb0 ] && \ [13:45] [ "$xres" ] && [ "$xres" != 0 ] && \ [13:45] [ "$yres" ] && [ "$yres" != 0 ]; then [13:45] /sbin/usplash -p -c -x "$xres" -y "$yres" $varg & [13:46] Yes [13:46] Sorry which OPTS? [13:46] so if the framebuffer script extracts xres and yres from the video= line for mxcfb and we export these values it should work [13:46] it seems to me usplash gets the resolution properly from the kernel when using other backends, cant we fix it to use the current resolution instead of hardcoding it? [13:47] at least that seems to be the issue to me [13:47] no, because the kernel doesnt know the resolution at all [13:47] thats the main prob with mxcfb [13:47] How come? [13:47] It doesn't support the relevant fb API? [13:47] you *have to* hardcode the res. on cmdline for it to display anythng at all [13:48] all i know from amitk is that it has no fallback mode and no way to detect the monitor [13:48] and i dont expect a fix from FSL [13:48] which is why we hardcoded video=mxcfb:1024x768@60 on the cmdline atm [13:48] if you remember (during the sprint) [13:49] ogra: You have to hardcode the res in the commandline because the kernel driver is not able to negociate it with the hardware, right? [13:49] yes [13:49] and has no fallback mode [13:49] I dont see why that relates to *userspace* misdetecting the resolution from the kernel [13:49] Cause the kernel certainly knows it was told to set 1024x768@60 [13:49] the old driver had 800x600 as fallback, but the driver was rewritten from scratch for DVI [13:50] userspace (usplash) only uses what is in usplash.conf [13:50] ogra: usplash.conf is empty on my laptop [13:50] usplash.conf values are written by xrandr [13:50] Yes, so after the boot [13:50] *if* you have a res set in xorg.conf [13:50] Which isn't the case [13:50] no [13:51] it calls xrandr after the boot as far as i'm aware [13:51] ogra: Xorg manages to find out at which res the fb is, right? So why wouldn't usplash? [13:51] not xorg.conf [13:51] cjwatson told me xres/yres was set from xorg.conf [13:51] Anyway we dont care, usplash.conf is empty on first boot [13:51] xorg.conf is empty on karmic [13:51] Yes [13:51] Which is why my usplash.conf is empty... [13:52] xfbdev has *no* xrandr support at all [13:52] resolutions are determined by xrandr [13:52] ogra: How does Xorg determine the resolution? [13:52] xrandr [13:53] That seems wrong [13:53] xrandr is a Xorg protocol [13:53] xorg does a lot more indeed ... like DDC probing etc [13:53] Xorg talks to the monitor which mxcfb cant [13:53] for framebuffer devices Xorg looks up the framebuffer resolution from /proc [13:53] Are you sure it does DDC probing? I thought it was using the fb device as such and wasn't reconfiguring it [13:54] Good so let's fix the usplash fb backend to properly read the res from /proc [13:54] Xorg currently even fails to start on headless devices [13:54] we cant [13:54] ... [13:54] why cant we? [13:54] (Am I supposed to fill the dialogue?) [13:54] ;) [13:55] oh, wait, we can, /usr/share/initramfs-tools/scripts/init-top/framebuffer runs before usplash [13:55] so fbdev exists [13:55] usplash wont run in initramfs in a couple of weeks [13:55] sorry, brainfart [13:55] well, given that booting babbage from SD takes a minute i doubt we can drop it [13:56] beyond that i'm pretty sure we'll keep it on all live images since they are slow [13:56] unless there is a way to start X in initramfs which i'm not aware of yet [13:56] the changes casper does take very long on a livecd boot [13:57] ogra: So we agree that parsing cmdline to set usplash res is wrong? [13:57] i dont agree, no [13:57] i agree that there might be a way to do it differently and more elegant [13:57] ogra: The kernel cmdline is for the kernel; it's enough that we hardcode the res in this place already (we shouldn't have to at all) [13:58] but after all the fb resolution comes from cmdline in any case and we have code to handle it already [13:58] Instead of kernel cmdline -> usplash, it should be kernel cmdline -> kernel -> usplash which is the expected way for usplash to work in all supported cases [13:58] right, we shouldnt have to, but i dont expect a fix for that in karmic [13:58] I dont want to add another kludge which hides the bug in usplash that it doesn't get the res from the kernel [13:58] well, it gets the res on all other graphics drivers [13:59] Yes, so what's wrong here? That's a bug! [13:59] all i can do is make it read from /proc [13:59] Let's fix it [13:59] its just moving the hack to a different level ... to work around a bug in the driver [13:59] No [14:00] You didn't prove it's a bug in the driver yet [14:00] It could as well be a bug in some fb or usplash code under armel [14:00] the driver doesnt work at all without hardcoding a res [14:00] thats the initial bug we suffer from [14:00] Yes, that's an issue between the driver and hardware [14:00] NOT between kernel and userpace [14:01] I agree there's a bug in the driver in that it should detect the res automatically [14:01] well, no point discussing that further, i'll look into how to make usplash read from proc [14:01] ogra: BTW does it work in qemu? [14:01] not that i know of [14:03] But qemu doesn't use that mx driver [14:03] i havent booted any graphical ui in qemu since mid jaunty [14:03] ogra: Might be worth checking it out? [14:03] sigh, ok [14:03] That might help pointing out whether it's a bug in the kernel driver or not [14:04] ogra: Why sigh? Tell me a better way [14:04] add five lines to /usr/share/initramfs-tools/scripts/init-top/framebuffer we remove once mxcfb is fixed [14:04] ogra: I'm not going to accept "This driver has one bug with resolution setting, so because I see another bug with resolution setting it must be in the driver" [14:05] yes, i see that [14:05] ogra: Again, for me the bugs dont relate at all [14:05] It might very well be that the driver is broken, but the logic you presented so far is flawed [14:05] If you prove that the driver is broken in this way too, I'm happy to just call it a kernel bug and use your initramfs workaround until it's fixed [14:06] the sigh was just about having a huge effort to get qemu going btw [14:06] i dont have any rootfs around, we dont have a working karmic kernel ... [14:07] but i'll do it just takes extra time [14:07] ogra: Well if you find a better way than qemu use it [14:07] heh [14:07] ogra: I dont really care how you debug the bug; I do care that you call it a bug in a driver when we dont really know, that's all [14:07] among the many arm devices that support usplash around me you mean ? :P [14:08] ogra: I'm happy to help with the logic or debbugging though [14:08] well, usplash might be able to just read /sys/class/graphics/fb0/mode ... prob is that sys isnt mouonted when it starts [14:08] ogra: Well yeah, if it's quicker for you to work on beagleboard and it uses the same usplash backend, it might be worth trying out on that hardware [14:08] Albeit the output on beagle is quite different [14:09] i dont even think the kernel has everything i need on the beagle [14:09] and its surely not quicker to build a kernel [14:09] ogra: That's interesting, try mounting /sys before starting? You could use break=top and mount it manually [14:09] ogra: Ok; so I dont know what the quickest way is [14:09] it boils down to the same i guess [14:10] i need kernels for both ... [14:10] Eh I dont know how to make it quicker [14:10] You could try on dove [14:11] doesnt have initramfs support at all yet [14:11] though afaik the latest kernel in NEW has support for it [14:12] anyway, i'll dig deeper, i was hoping you are fine with a temporary babbge specific solution ... but lets fix it proper [14:13] \o/ [14:13] That's the attitude! [14:16] heh [14:49] lool, looking at usplash code it just relies on the fact that the framebuffer can handle the lowest resolution theme and uses that if no res is set at all [14:50] ogra: Oh it doesn't scan for res? [14:50] so i guess our bug is simply that mxcfb cant handle anything else than the cmdline res while other systems can [14:50] I thought I saw a loop going over all themes trying to match the res [14:50] /* If xres or yres is 0, use the resolution from the config file. */ [14:50] if (xres == 0 || yres == 0) { [14:51] thats libusplash [14:51] the comment refers to the commandline options of usplash [14:51] Why would these be zero? [14:51] Isn't there a call to detect the current res just before that? [14:51] (That's from memory) [14:51] if no commandline options are handed over the are unset = 0 [14:51] I thought if nothing was set it was detecting the current one [14:52] right below there is: [14:52] } [14:52] } else { [14:52] /* Pick the first one, which by convention is [14:52] the lowest resolution one. */ [14:52] xres = usplash_theme_width(theme); [14:52] yres = usplash_theme_height(theme); [14:52] so in case of mxcfb it tries to show 640x480 [14:52] which breaks the dirver hard and locks up the board [14:54] that is why you dont get a 1920x1200 theme on your big screen under kms ... but a very small logo and bar in the center [14:54] it uses 640x480 and just centers it properly [14:55] and thats why i get a completely streched theme on my 1280x800 laptop screen if i dont specify a widescreen res in usplash.conf [14:56] and looking closer into proc, there is no info about the frambuffer mode anymore, the only thing i can find info about it is /sys/class/graphics/fb0/mode but thats not available in initramfs at that point [14:57] ogra: Could you extract the usplash call into a test case to hand the kernel team? [14:57] Like "run this and it crashes the board" [14:57] sure [14:57] Thanks [14:57] in a bug ? === bjf-afk is now known as bjf === ian_brasil is now known as IAO [15:11] lool, bug 420555 [15:11] Launchpad bug 420555 in linux-fsl-imx51 "mxcfb framebuffer driver crashes the board hard on attempt to use a different resolution than the one specified on cmdline" [Undecided,New] https://launchpad.net/bugs/420555 [15:11] lool, should i assign it to the kernel team and see what they do about it ? [15:12] i dont expect any fixes for mxcfb at all though, neither from them nor from FSL [15:12] ogra: Hey didnt you get sound on the babbage earlier? [15:12] with todays liveimage [15:12] so can you close https://bugs.launchpad.net/ubuntu/karmic/+source/linux-fsl-imx51/+bug/420447 ? [15:13] Launchpad bug 420447 in linux-fsl-imx51 "no sound devices on babbage board with linux-image-2.6.31-100-imx51" [High,New] [15:13] oh, misread, no i didnt get any sound [15:13] ogra: Did you confirm the board is dead when running usplash? I mean no serial console or pings? [15:14] Or is it just freezing the current VT? [15:14] there are no devices compiled in and as i know the imx kernel it has issues with loading the sound device mods dynamically, FSL usually compiles in everything we often see things not work right once they are modularized [15:14] lool, its hardlocked [15:14] ogra: Ok thanks [15:14] no network pings at least i havent checked serial yet [15:14] ogra: Do implement that idea you had in initramfs please :) [15:14] For the usplash workaround [15:14] yep :) [15:14] ogra: Ideally, open a task/bug to revert that when this bug is fixed [15:15] * ogra checks serial too, i can probably capture an oops [15:15] ogra: Hmm dont you have anything smaller than usplash -c for the kernel team to run? [15:15] I guess that's ok [15:15] smaller ? [15:15] Yeah like a C file to build [15:15] usplash isd on the daily image [15:15] To point them at the problematic syscal [15:15] l [15:15] its the easiest thing to repro [15:16] hmm [15:16] ouch, we really need to have serial console setup in upstart for our live images during development :/ [15:17] i wonder why we have it on the cmdline ... it wont work anyway without upstart setup [15:19] hmm, no kernel messages on the serial console [15:20] NCommander: What's that bug for the kernel config change again on dove? [15:20] ogra: The one on the command line is for the kernel [15:20] ogra: The one in upstart is to start an userspace process [15:20] lool, i know [15:20] it doesnt gain us much though [15:21] So the two are different, even if we dont have an userspace getty [15:21] Well its better than nothing [15:21] indeed [15:21] we have tty output after uncompressing though [15:21] but yes, it may help kernel debugging [15:22] ogra: Are the workitems up to date on your freescale spec? [15:22] should be, let me check [15:23] Status: Waiting on d-i changes to build, then new livefs builds [15:23] yup [15:23] well, what should i change it to ... pending for next alpha ? [15:24] "livefs testing in progress" ? [15:24] or "daily livefs testing in progress" ? [15:35] ogra: that's fine === goshawk_ is now known as goshawk [17:34] ogra, good morning [17:34] hey tlee [17:35] I am try to git clone the dove kernel in your server. Do u have the url handy? [17:35] the #ubuntu-kernel channel would be better for that kind of question :) [17:36] i dont do muh kernel development [17:36] *much [17:36] ok. [17:36] Thx [17:37] tlee: ubuntu:ubuntu/ubuntu-karmic.git mvl-dove branch [17:37] ubuntu: being git://kernel.ubuntu.com/ === bjf is now known as bjf-afk === cbrake is now known as cbrake_away [23:49] so, i bought a larger SD card to run ubuntu-arm on my htc wizard [23:49] seems to be running quite well but my keymap is messed up and unusable [23:50] it works ok with a simple busybox rootfs [23:51] so where should i be looking to fix this?