[08:22] <vlad> ogra: I'm -pretty sure- I tried 2.6.31-100 already with that eth issue, but I'll double check tomorrow
[08:23] <ogra> ok, the bug only mentions -5-imx51 or so
[08:23] <ogra> which was definately not a complete imx51 merge
[08:24] <vlad> hmm
[08:24] <vlad> -5- is wrong, I wonder if i typo'd that
[08:24] <vlad> one sec
[08:25] <ogra> -100 might have other ethernet probs though
[08:25] <ogra> i know amitk is working on the NIC driver
[08:26] <vlad> hmm, -5- might have been correct; regardless, I'll verify with -100
[08:27] <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
[12:04] <ogra> usplash !
[12:05] <lool> What?  it works now?
[12:06] <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:07] <ogra> if there is none or a different one, the board dies
[12:07] <ogra> (babbage that is)
[12:08] <ogra> i guess we can add something to casper that reads cmdline for mxcfb and creates a usplash.conf
[12:12] <ogra> given that there is no way to use xrandr and there is no DDC detection either at least
[12:19] <lool> ogra: Perhaps we just need to fix that crash?
[12:24] <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:25] <ogra> lets see if i can run it from initramfs as well if usplash.conf exists
[12:27] <ogra> bah, setting break=top doesnt work ...
[12:27]  * ogra changes to break=bottom to have usbhid 
[12:32] <ogra> WHOPEEEE !!!
[12:32] <ogra> works !
[12:33]  * 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:34] <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:35] <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:36] <ogra> err s/usplash/framebuffer/
[12:37] <ogra> lool, /usr/share/initramfs-tools/scripts/init-top/framebuffer along the matroxfb and uvesafb special cases
[13:02] <lool> ogra: Well depends of the change
[13:02] <ogra> call ?
[13:02] <lool> Right
[13:03] <ogra> i would just export xres and yres from the OPTS
[13:03] <ogra> usplash will pick that up
[13:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[14:00] <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:01] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <ogra> doesnt have initramfs support at all yet
[14:11] <ogra> though afaik the latest kernel in NEW has support for it
[14:12] <ogra> anyway, i'll dig deeper, i was hoping you are fine with a temporary babbge specific solution ... but lets fix it proper
[14:13] <lool> \o/
[14:13] <lool> That's the attitude!
[14:16] <ogra> heh
[14:49] <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:50] <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:51] <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:52] <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:54] <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:55] <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:56] <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:57] <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 ?
[15:11] <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:12] <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:13] <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:14] <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:15]  * 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:16] <ogra> hmm
[15:16] <ogra> ouch, we really need to have serial console setup in upstart for our live images during development :/
[15:17] <ogra> i wonder why we have it on the cmdline ... it wont work anyway without upstart setup
[15:19] <ogra> hmm, no kernel messages on the serial console
[15:20] <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:21] <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:22] <lool> ogra: Are the workitems up to date on your freescale spec?
[15:22] <ogra> should be, let me check
[15:23] <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:24] <ogra> "livefs testing in progress" ?
[15:24] <ogra> or "daily livefs testing in progress" ?
[15:35] <lool> ogra: that's fine
[17:34] <tlee> ogra, good morning
[17:34] <ogra> hey tlee
[17:35] <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:36] <ogra> i dont do muh kernel development
[17:36] <ogra> *much
[17:36] <tlee> ok.
[17:36] <tlee> Thx
[17:37] <lool> tlee: ubuntu:ubuntu/ubuntu-karmic.git mvl-dove branch
[17:37] <lool> ubuntu: being git://kernel.ubuntu.com/
[23:49] <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:50] <ali1234> it works ok with a simple busybox rootfs
[23:51] <ali1234> so where should i be looking to fix this?