[00:05] ogasawara: The linux FTBFS on arm is, I assume because someone kept the abi/modules check on during an ABI change? ;) [00:05] (Which seems accidentally intentional, from the changelog) === BenC_ is now known as BenC [05:36] ... and bison. [06:30] Hello! Are there packages right to try lxde on BeagleBoard B4 - apt-get install lxdm lxde lxlauncher lubuntu-desktop - ? I know the board is ancient, but would like to try === smb` is now known as smb [07:51] moin [07:55] morning ppisati [07:59] ppisati: You may want to take over Tim's attempts to fix the ti-omap4 tools build with a test build in a clean chroot. ;) [08:00] ppisati: He added a flex build-dep, and now it fails cause it needs bison. [08:00] infinity: did he push it? [08:00] ppisati: He uploaded it, so I assume it's in git too. [08:01] ppisati: And if you're bored, sorting out the linux build failure on armel would be snazzy too. ;) [08:02] (Unsure if it's FTBFS because the modules check shouldn't be on, or if the missing/changed modules it reports are actually a bug) [08:02] infinity: i'll give it a shot [08:03] ppisati: <3 [08:03] ogasawara: Despite the armel build failure (which I hope you guys sort), I suspect it's time for a new linux-meta. [08:04] ogasawara: I'd upload one, but I get smacked for doing so without comitting to git, and I've never bothered to whine about zinc access. ;) [08:04] q/omap4 you mean? [08:05] ppisati: q/linux-ti-omap4 for the tools build issue (missing build-deps), q/linux for the armel failure (module checker sadness) [08:05] ok [08:05] ppisati: The former is the only real concern for me right now, armel can be fixed later. [08:05] but you wanted a new meta for... [08:05] But if you're bored, by all means, fix both. ;) [08:06] ppisati: Oh, new meta for linux. ti-omap4 didn't have an ABI bump. [08:06] nack [08:06] (Though, it would if you rebased, I suppose, which you probably should) :P [08:06] q/master wrt arm is broken ATM [08:06] i've a patch that restore usb* [08:06] and i'm trying to get the video back [08:06] Oh, fun. [08:08] ah, and btw, don't know if we care so much about armel... [08:08] No, but the breakage there looks obvious. :P [08:12] * infinity decides it's time for a nap. [09:19] Hey ogra_ [09:20] infinity: can't reproduce your build q/master build failure (cross compiling i got both armel and armhf 3.4.0-4.10) [09:23] ppisati: Weird. [09:47] I get bug 1008905 with Quantal A1 on a Mac Mini. Do you need more info than what's been automatically attached ? [09:47] Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [Undecided,Confirmed] https://launchpad.net/bugs/1008905 [09:49] jibel, I think this should be good enough [09:54] smb, k, thanks [10:16] morning guys, [10:17] smb and apw, did we discuss to use CFQ to replace deadline scheduler in our -server kernel before? [10:17] as we merge -server kernel with -generic together [10:17] actually i'm looking at this bug 1008400 [10:17] Launchpad bug 1008400 in linux "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,Confirmed] https://launchpad.net/bugs/1008400 [10:18] instead huh [10:19] cooloney, I am just on the run, but I think something about schedulers was discussed though I am not remembering the outcome. Would be a matter of command line to the kernel... [10:20] yeah, i also think about that. we can easily change that via sysfs. [10:20] but no sure about whether we change that to deadline in our server image [10:30] he seems to imply that was what it was in the -server images [11:20] apw, just spotted two issues with devel-config-tag, sent you two patches [11:20] cooloney, think we are already using deadline for server flavour [11:21] cooloney, ok - that was CONFIG_DEFAULT_IOSCHED [11:23] No we do not. At least not in Precise and Quantal. It would be a way to change the default to modify the kernel arguments [11:24] It is some sort of decision you have to make anyway when setting up a server. Beside of other things that one needs to adapt === yofel_ is now known as yofel [11:30] infinity: actually tools/perf is the same for x86 (i386 and amd64) and ti-omap4 [11:30] infinity: but in *86 chroot flex is installed, while it's not for omap4 [11:31] infinity: i think it's your problem now since we require it [11:33] ppisati, what about flex ? it built and is in the archive [11:34] if you actually require it for a package it needs to be a build-dep [11:34] ogra_: and it is [11:34] ogra_: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blobdiff;f=debian.ti-omap4/control.stub.in;h=4eedc6957c482c1b1c1a8e2739980b92ae349dd5;hp=f30e1962d3a382976949b9ec63362c047aaa84e0;hb=8debe7fa58d36bd9d1eb5b2fa90e5735c90239ef;hpb=20db486d4e826c21143ff2e875eb5209ba3216f8 [11:35] ogra_: isn't it enough? [11:36] are you sure that doesnt need to be libfl-dev ? [11:36] (what doe the other kernels have there as a b-dep ?) [11:36] *do [11:37] ogra_: hold on [11:38] ogra_: master has flex and bison [11:38] ogra_: but in our case, it chokes on fle [11:38] x [11:39] FLEX util/pmu-flex.c [11:39] /bin/sh: 1: flex: not found [11:39] https://launchpad.net/ubuntu/+source/flex/2.5.35-10ubuntu3 at least indicates that it is available for all arches so if it is a dep it should end up in the chroot [11:40] ogra_: yep, but infinity pointed the compilation failure to me like it was a kernel compilation problem [11:40] ogra_: while our side looks sane to me [11:41] infinity: ^^ [11:41] ouch [11:41] actually it needs bison too [11:41] so we have two problems [11:41] 1) chroots need flex [11:41] 2) we need to add bison to b-dep [11:45] i'm pretty sure chroots dont have flex and are not supposed to [11:45] this needs to come in through the deps [11:46] i just built two fresh Q chroot (amd64 and armhf) [11:46] and i confitm they don't have flex nor bison [11:46] right [11:46] but we need both of them for perf/tools [11:46] why would they [11:47] because upstream want it :) [11:47] hmm ? [11:47] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=tools/perf/Makefile;h=92271d32bc30b2056c472f273b1af6bed9847b31;hb=8debe7fa58d36bd9d1eb5b2fa90e5735c90239ef [11:47] look for perf and bison [11:47] sorry [11:47] flex and bison [11:47] we should break deboostrap for an upstream that doesnt want build deps in packages ? [11:48] i'm not a package expert, so i don't understand what you said here [11:49] let's take master kernels as an exam,ple [11:49] they have flex and bison listed as dependencies [11:49] isn;t it enough? [11:49] well, if xorg would say we need blah, would you hack debootstrap to have blah by default or would you fix xorgs build dependencies ? [11:50] i see what you mean, but we already do that [11:50] (note that if you would do that for every package a default chroot would become several gigabyte big) [11:50] i see what you mean [11:50] ok [11:50] but the linux kernel started to relies on them so, i don't think there's much we can do [11:50] what i mean is that it cant be a chroot problem but that something is wrong in your deps [11:50] and, btw, master already enforce them [11:51] i don't understand why we didn't hit this in *86 world [11:51] no idea [11:52] but its definitely a package side prob, not a chroot side one [11:53] probably a dep of flex is broken or missing and thus the package isnt installable, but then your linux build should forcefully fail [11:53] ogra_: imo flex and bison should be added to build-essential [11:53] ugh, why ? [11:54] ogra_: uhm, right [11:54] build-essential should only carry the most common denominator *all* packages need [11:54] (compiler, toolchain etc) [11:54] ogra_: should come as part of build-dep $linux [11:54] right [11:55] uhm no [11:55] apt-get build-dep linux doesn't list flex nor bison [11:56] weird, there is your prob then [11:56] right [11:56] but we clearly had these two packages in some chroots [11:56] since perf didn't break there [11:56] thats even more weird [11:57] but surely not caused by the chroots ... [11:57] the buildd chroots are empty by default and get freshly unpackaged on every build [11:58] from a tarball that only contains the minimal bits debootstrap puts in place [11:58] right, that was my question [11:58] iirc debootstrap has a cmdline option to create such a chroot ... and afaik it should be possible to actually download the actually used buildd chroots from LP somewhere [11:59] (dont ask me where though) [11:59] so you could inspect them [11:59] i'm using a fresh chroot, let's see if generic breaks here [12:00] * ogra_ wonders whom he saw talking about that recently, might have been Laney or tumbleweed [12:01] ok, while it builds i'm out to get some food [12:01] rtg should be here soon, i guess he'll find the culprit quicker than me [12:01] in the mean time, /me -> lunch [12:01] yeah, btw, there was a question from TI in #ubuntu-arm :) [12:01] (for after lunch indeed) [12:01] ogra_: ah, when? [12:41] infinity: meta uploaded, and I fixed the armel FTBS in the 3.4.0-4.10 upload [12:46] armel ? i thought you stopped building el [13:00] ogra_: wasn't me, but you can get it using the LP API [13:00] e.g. In [4]: lp.distributions['ubuntu'].current_series.getDistroArchSeries(archtag='armhf').chroot_url [13:00] Out[4]: u'http://launchpadlibrarian.net/106153668/chroot-ubuntu-quantal-armhf.tar.bz2' [13:00] (there may be an easier way) [13:01] ah, cute, good to know [13:02] ogasawara: when you are awake, can you explain me why 'apt-get build-dep linux' doesn't list flex and bison? [13:03] looking at the quantal-changes ML it seems like tim just did an upload with bison added [13:04] ti-omap4 or master? [13:04] linux-ti-omap4 (3.4.0-201.6) quantal; urgency=low [13:04] ... [13:04] * [Config] Added bison as a build dependency [13:04] ... [13:05] sneaky [13:16] ppisati: I assume you're referring to ti-omap4? and I thought tim added both flex and bison as build dependencies just recently [13:20] ogasawara: yes, he did, but i built two fresh chroot this morning and compilation of master/generic and ti-omap4 choked on perf/tools because "apt-get build-dep linux" doesn't listen flex nor bison as b-dep [13:22] ogasawara: so my question is more like "who is responsible for installing flex and bison? shouldn't apt-get build-dep linux do that?" [13:23] ppisati: assuming they're not already installed, yes I would assume that should do it. And assuming that the package actually lists them as build deps in the the control file (which I believe is also true at least with tim's latest changes). [13:24] ogasawara: yep, are listed in debian*/control, aren't present in chroot, but build-dep doesn't list them [13:25] ogasawara: btw isn't it a bit too early for you? :) [13:26] ppisati: nah, I usually start about 5:30am local time. [13:27] ok [13:29] ogasawara, any likelyhood we'll be able to get a fix for bug 1008905 today? or no amd64+mac images for A1? [13:29] Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,Confirmed] https://launchpad.net/bugs/1008905 [13:29] ppisati: and you're sure you're checking the build deps for the latest 3.4.0-201.6 kernel? [13:31] skaet: hrm, not aware of a fix at the moment. so won't be able to promise a fix by EOD. [13:31] skaet: but will try [13:32] thanks ogasawara, ok, will not block on waiting for next set of spins unless you flag a fix is imminent. [13:32] skaet: ack [13:33] ogasawara: http://paste.ubuntu.com/1025030/ [13:34] ogasawara: fresh q/amd64 chroot + apt-get install fakeroot build-essential crash kexec-tools makedumpfile kernel-wedge git libncurses5 libncurses5-dev libnewt-dev [13:34] ogasawara: but i've the same for master [13:36] ogasawara: builders don't complain about master's flex and bison dependencies so i'm probably doing something wrong with build-dep i guess [13:37] ppisati: what's the uname -a output? and I assume you need to do apt-get build-dep linux-image-3.4.0-4-generic [13:37] ppisati: or the omap4 equivalent [13:38] ogasawara: indeed, linux-image-$ver is the right invocation, thanks [13:39] ppisati: I assume you've seen though that tim's uploaded the latest 3.4.0-201.6 ti-omap4 kernel. it's currently building... [13:39] ogasawara: yep, few minutes ago [14:12] sforshee: does one of the macbooks or enablement machines you have in your possession have broadcom? was curious if you are able to reproduce 1008905? I looks to originate from an issue of missing firmware because the firmware it wants is in linux-firmware-nonfree which isn't on the install media [14:13] man bzr [14:14] -EFOCUS [14:14] ogasawara, I was just about to take a look at that one [14:14] I've got a couple of machines that are likely to be affected [14:14] but I fixed a missing firmware issue in b43 recently, so it may already be fixed [14:16] sforshee: I also saw the following patch http://www.mail-archive.com/b43-dev@lists.infradead.org/msg02461.html when digging around [14:18] apw, just curious how the symbols in CONFIGS-dump are generated, checking the source they are generated by zconfdump(), yet the invocation to that function is commented out [14:19] ericm|ubuntu: just fyi, apw is away on holiday today [14:19] ogasawara, ah [14:19] ogasawara, that definitely looks related. The fix I did was in the probe, not remove, so it is a different issue. [14:22] sforshee: could you let me know if you are able to reproduce with hw you have on hand? if so, could you see if that patch helps at least prevent the panic? [14:23] ogasawara, ack [14:29] ogasawara: is today last day to get something in for alpha1? [14:30] ppisati: it would be, and would likely need an ack by the release team at this point [14:30] ogasawara: ack [14:35] ogasawara: because a couple of days ago i sent a patch for q/master, and andy said he was going to handle it (since he was messing with config regen) [14:35] ogasawara: now, i saw all the config changes for highbank, but not my stuff for omap3 [14:35] ogasawara: shall i wait for him tomorrow or what? [14:36] ppisati: hrm :( I do remember seeing that email. if you have a patch, send it to me now and I'll get it applied. [14:36] ppisati: ah you've already sent it [14:37] ogasawara: that's a second one, the first one is missing too (the LPAE config change) [14:38] ppisati: ah, so both are necessary for Alpha1 [14:38] ogasawara: yep [14:38] * ogasawara nods [14:39] video is still broken (fb modules aren't loaded at boot time), but at least with them board boot up, and everything else should work [14:39] skaet: ^^ kernel config changes necessary for omap to even boot, when's the latest we can squeeze in an upload? [14:41] Hello! What is "display 0" in "Server is already active for display 0". I get that line on < sudo startx > on Ubuntu 11.10 Beagleboard B4 when attempting to start lxde [14:42] ppisati, erm, could we disable the penguins on boot please ? [14:42] (on omap4 that is) [14:42] ogra_: omap3 are off [14:42] ogra_: omap4 maybe? sorry, too late :) [14:42] right, i see them on the panda [14:42] yeah, not urgent [14:43] it seems to break plymouth [14:43] (at least i dont see a splash) [14:43] ?? [14:44] ogra_: i've splash off my boot args [14:44] ogra_: btw i don't even remeber the penguins... [14:44] well, you should at least occasionally switch it on [14:44] to see if it breaks the userspace :) [14:46] ogasawara, prep it up. Give me a bug number and we'll add it to the list of possible respin triggers. Just need to respin for arm? or all? [14:46] skaet, not important for A1, we can let that slip [14:46] skaet: ideally if we can confirm a fix for 1008905 I'd want to squeeze that in too which would then result in a respin for all [14:47] ppisati: can you get a bug filed for the config changes [14:47] oh, sorry, though leann stole my ping ;) [14:47] ogasawara: i'll do [14:48] ogasawara, ack. [14:48] skaet: but wanted to know the latest we'd be able to upload, 2100UTC today? [14:50] * ogasawara back in 10min [14:50] ogasawara, we'll block the next respin on your upload, sooner the better. [14:50] skaet: ack [14:52] ppisati, is there any reason to not build fb into the kernel ? [14:52] ogra_: nope, and did try that [14:53] ogra_: but we get a WARN() on boot and display doesn't work at all [14:53] ouch, k [14:53] ogra_: instead, being =m, if we load it later and restart lightdm, it works [14:53] oh, intresting [14:54] ppisati, ignore my penguin comment, seems my dd didnt work at all, i booted a TI experimental kernel apparently [14:54] (old cruft that was on the SD) [14:59] hi, folks. why does the precise kernel have the 3.2.0 numbering instead of follow upstream 3.2.x schema? [15:04] jwendell, I don't remember which exactly, but there were user-space programs and also some external module package expecting a three digit version number and the risk to not find them all compared to add an artificial 0 was too high (iirc) [15:05] ppisati: Which adapter are you using to get 5V 3.8A for BB B4? or its custom PSU? [15:05] orated_: a commont power adapter, nothing special [15:05] ppisati, hmpf, can we please put the leds back into the kernel on omap4 ? if i have a crashed screen by whatever reason i cant see that the board is alive at all until the module is loaded [15:06] ppisati: I mean the make of it ... [15:06] ppisati: Usually 5V adapters are never above 1A rating as they are commonly outputted for USB [15:07] orated_: any power adapter with 5v 1.5a+ output is good [15:07] Yes, [15:08] ogra_: iirc i had blinking leds [15:08] ppisati, cant be if the module isnt loaded [15:09] to elaborate, the resizing of the image before the gui installer starts happens from initrd ... usually there is plymouth output, apparently thats currently not working so you dont see that the board does anything at all [15:10] ogasawara, I've reproduced 1008905 on my mac mini [15:10] ppisati, oh, and is there a bug number for the omap3 config stuff ? release team would like to have it in the docs [15:11] sforshee: cool, keep me posted if the patch helps [15:15] ogra_: i'm opening it [15:16] ogra_: but i wanted to write down the exact message at boot time [15:17] k [15:18] ogra_: did you use a daily image? [15:19] ppisati, yes [15:19] the latest, testing for A1 [15:36] ppisati, i dont seem to be able to get any graphical output from the current quantal omap4 kernel here [15:36] ogra_: uhm? [15:37] neither on HDMI nor on DVI [15:37] i've the beagkexn attached now [15:37] can't switch board [15:37] k [15:38] it seems to hang in some loop or so, my monitor shows me alternating the "no signal" sign and then it behaves like something is connected for a second [15:39] ogra_: did you boot up with the monitor attached and turned on? [15:39] indeed i did :) [15:39] wait [15:42] aha, enabling tehj serial console gives more info [15:43] DISPC: error SYNC_LOST on channel tv [15:43] HDP irc request failed [15:43] err, IRQ [15:44] (thats whith HDMI attached, trying DVI now) [15:44] same error over and over [15:46] aha ! [15:47] booting without monitor attched gets me at least a 1024x786 screen when i attach the DVI port to HDMI later [15:47] weird, i never had any probs ever with this monitor (and its my default test screen for the panda since day one) [15:48] ogra_: monitor detection in P is from upstream [15:49] ogra_: they use a gpio and detect when you attach/detach a monitor [15:49] ppisati, eeek [15:49] ogra_: works very well [15:49] did you talk to andy about that ? [15:49] ogra_: in Q i used what i got from TI [15:49] oh, ok [15:49] ogra_: and it _seems_ to me [15:49] ogra_: they do a kind of... [15:49] ogra_: busy loop [15:49] yeah, apparently [15:49] ogra_: if they don't detect anything attached [15:50] it works fine if i attach the screen later [15:50] so it's not working really well [15:50] so at least there seems to be a fallback [15:50] good enough for A1 i guess if we release-note it [15:51] ogra_: wait wait [15:51] my panda is still booting [15:51] ... [15:51] todays image ? [15:51] nope [15:51] i havent tried my older panda yet [15:51] i wanted to see what i've on my disk [15:51] i still have a pre-ES around here [15:51] panda es here [15:52] fsck... [15:52] * ogra_ wonders why he has ugly scrollbars around the slideshow [15:53] video works ok here [15:53] but i've an older kernel... uhm... [15:53] let me try the last one [15:53] yeah [15:54] 3.4.0-201-omap4 #2~sndy [15:54] ~3.4.0-201-3 [15:54] i cant check atm, i'm in the middle of the install [15:55] btw [15:55] bug 1009061 [15:55] Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061 [15:55] is for omap3 [15:55] ah, thx [15:55] ogasawara: ^^ [15:56] ppisati: ack thanks. am building now on gomeisa, would you be able to test boot when it's finished? [15:56] ogasawara: yep [15:58] ppisati: just fyi, for the second patch to restore usb, I did an fdr updateconfigs after applying and it cleaned it up to a smaller patch, eg: [15:58] diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu [15:58] index 1da26ae..ea1b5f9 100644 [15:58] --- a/debian.master/config/config.common.ubuntu [15:58] +++ b/debian.master/config/config.common.ubuntu [15:58] @@ -3152,7 +3152,7 @@ CONFIG_MFD_INTEL_MSIC=y [15:58] CONFIG_MFD_JANZ_CMODIO=m [15:58] CONFIG_MFD_MC13783=m [15:58] CONFIG_MFD_MC13XXX=m [15:58] -# CONFIG_MFD_OMAP_USB_HOST is not set [15:58] +CONFIG_MFD_OMAP_USB_HOST=y [15:58] CONFIG_MFD_PCF50633=m [15:58] CONFIG_MFD_RC5T583=y [15:58] CONFIG_MFD_RDC321X=m [15:58] ogasawara: ouch [15:58] ah ok [15:58] uhm [15:59] it shouldn't harm [15:59] since MFD_OMAP_USB_HOST it's a #ifdef ... inside arch/arm/mach-omap2/usb-host.c [16:00] ppisati: I did a fdr genconfigs and checked it's only on for arm [16:00] :~/ubuntu-quantal/CONFIGS$ grep -rn "MFD_OMAP_USB_HOST" * [16:00] armel-config.flavour.omap:2789:CONFIG_MFD_OMAP_USB_HOST=y [16:00] armhf-config.flavour.omap:2789:CONFIG_MFD_OMAP_USB_HOST=y [16:02] good for me then [16:04] ** [16:04] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:04] ** [16:18] flag@flag-desktop:~$ uname -a [16:18] Linux flag-desktop 3.4.0-5-omap #11 Tue Jun 5 15:52:24 UTC 2012 armv7l armv7l armv7l GNU/Linux [16:19] ogasawara: good on my beagle [16:19] ppisati: cool, thanks [16:20] ogasawara: Thanks for tidying up linux/linux-meta. [16:20] ppisati: will try to get this uploaded shortly. just want to wait on feedback on the other issue 1008905 [16:21] infinity: no worries, it's my own stupid fault. sorry for the extra work it caused on your end. [16:21] ogasawara: Meh, pestering people isn't work. [16:21] *poke* [16:21] *poke* [16:21] heh [16:25] ppisati, ndec asked in #pandaboard which commit our current omap4 tree is based on [16:25] do you know that from the top of your head ? [16:28] sforshee: cool, seems from your bug comment the patch has helped. I can get it applied, care if I add your Ack? [16:29] ogasawara, feel free to add my ack [16:29] sforshee: will do, thanks for the testing [16:30] ogasawara: it's noted in the changelog [16:30] ops [16:30] ogra_: ^^ [16:30] wait [16:31] skaet: we have fixes for bugs 1008905 and 1009061, am getting them applied and will bupload. [16:31] Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,In progress] https://launchpad.net/bugs/1008905 [16:31] Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061 [16:31] ogra_: TI BSP @ 95a4fb91c8880200462e61662e55ed6f9011e74d [16:31] ogasawara, thanks. :) [16:31] thx [16:32] skaet: just fyi, it is an ABI bump so I'll follow up with a linux-meta upload [16:33] ogasawara, understood. thanks for flagging it. [16:34] ppisati, hmm, nicolas says thats pretty old [16:34] ogra_: a couple of weeks old [16:36] ogasawara: You could just slam both the kernel and meta at -proposed, and we can sort it out when it's all built. [16:37] infinity: cool, I'll do that [16:37] * infinity isn't fond of the -meta delay loop. ;) [16:38] * ogasawara neither, although it does save my ass sometimes [16:39] Heh. [16:44] flag@panda:~$ uname -a [16:44] Linux panda 3.4.0-201-omap4 #6 SMP PREEMPT Tue Jun 5 16:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux [16:44] ogra_: video works fine here [16:44] ogra_: my lcd picks it up every time i reboot the board [16:45] ogra_: can you try with a P kernel? [16:45] will do [16:48] ogra_: Could your issue be commandline related or something subtle like that? (assuming ppisati isn't using the new flash-kernel...) [16:49] infinity, the image still uses the hardcoded cmdline debian-cd sets ... [16:49] this is my cmdline [16:49] its definitely omapdss related [16:49] ro rootwait elevator=noop vram=32M root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef fixrtc console=ttyO2,115200n8 earlyprintk=ttyO2,115200n8 debug [16:49] ogra_: try P kernel first [16:49] ogra_: if would be in you, i won't rule out an hw issue [16:50] you should bump to vram=40M i was told for xorg [16:50] ogra_: or a dying hdmi port [16:50] ppisati, i seriously dont want you in me ! [16:50] :) [16:50] the ports work fine with the older image that ran until i started testing A1 [16:51] (which was precise) [17:06] ppisati, 3.2.0-1414 works fine but has the penguins [17:07] i.e. my monitor is fully up and running with it [17:07] so its a 3.4 issue [17:07] herton, you uploaded 3.2.0-1414 ... can you please disable the bootlogo (i see two penguins here) [17:08] (omap4 precise proposed that is) [17:08] ogra_, I pushed what ppisati gave me [17:08]