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