=== fta_ is now known as fta [00:22] mattman, ok X works it just doesnt seem to like using a DVI to VGA adapter also since its using a framebuffer you can't change the resolution [00:42] mattman, added some minor changes about the framebuffer device node and using DVI directly which fixes my X11 problems [00:43] mattman, should be sufficient now for someone to get an ubuntu desktop running on that board [00:44] ework: so what are the parameters you're passing into the frame buffer? [00:44] nothing just created the device node [00:44] it works at 1024x768x60 without any changes [00:44] ework: that's good to know [00:46] mattman, yah there should be enough tips and instructions there now to get ubuntu 10.04 installed from scratch [00:47] mattman, to the desktop [00:47] ework: great [00:48] mattman, thanks for your help I wouldn't have gotten this far without your pointers [00:50] Great. Now I am seeing soft lockups on cpu0. Very frustrating === fta_ is now known as fta [01:13] hquit === jcrigby is now known as ed_is_a_hoser === ed_is_a_hoser is now known as jcrigby === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta [03:05] GrueMaster: with beagle or panda? [03:09] the beanda [03:09] evening folks === fta_ is now known as fta === fta_ is now known as fta === fta_ is now known as fta === JaMa|Zz is now known as JaMa|Wrk === fta_ is now known as fta [06:47] rsalveti: Panda. And I'm out for the night. [06:47] GrueMaster: with the latest kernel? [06:47] * rsalveti also needs to get some sleep :-) [06:48] Not sure. 20100809 build + updates. Not your kernel. [06:48] Had to update to get the latest oem-config before filing a bug against it. [06:48] GrueMaster: hm, because 2.6.34-903-omap4 should be our latest [06:48] and we got an update to this version days ago [06:48] so it could be a regression [06:49] I think 902 is on the image. Not sure what was pulled with the update. === hrw is now known as hrw|gprs === hrw is now known as hrw|gprs [10:48] mythripk: ping [10:52] hi lag [10:54] Hey :) [10:55] I'd like to pull your (and robclark's) patches to make my Panda work [10:55] What commit shas do I need? [11:22] mythripk: ? [11:24] lag : do you want me tosend [11:24] the commit id's of mine and rob's patch ? [11:25] mythripk: Yes please [11:25] 1 sec [11:25] Thank you [11:32] http://dev.omapzoom.org/?p=axelcx/kernel-display.git;a=shortlog;h=refs/heads/display-next [11:32] from commit 0ec1de9609d2b42bf47f63f9e8a4a50de30b381e- Patch to Enable autodetect with EDID in HDMI [11:33] to b128c1648c6f0d39645f0424ac45a5c5b848bcc0 HDMI:Move the functions from HDMI Irq handler to work queue [11:37] grmpf [11:59] mythripk: Just those too? [12:00] entire set from the first commit [12:00] to the last one in that path === zyga is now known as zyga-afk [12:48] * ogra whacks d-bus [13:01] why the heck do i get an exec format error running a python app ... damned [13:04] ogra: stop compiling python apps :-p [13:05] amitk, heh, tell that to the oem-config guys [13:07] i dont think its python spilling the error but a subprocess it calls === Hrww is now known as hrw === asac_ is now known as asac === zyga-afk is now known as zyga [14:49] GrueMaster, do you have any beagle that boots the current image ? [14:49] GrueMaster, so that you could test if oem-config fails the same way on omap3 === hrw is now known as hrw|gprs === bjf is now known as __bjf [15:25] ogra: I had it doing upgrade testing, but will try it today. [15:27] Also, I had already filed a bug yesterday on oem-config yesterday. Bug 616581. [15:27] Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/616581 [15:29] ndec: Hi [16:03] lag: http://gitorious.org/ubuntu-experimental/kernel-maverick/commits/rsalveti-ti-omap4 [16:03] the patches I'm using for the monitor issue [16:03] the 9 patches I got from mythripk plus some more from robclark that I got to test the dvi support [16:04] lag: do you have any plan to merge any of these patches? [16:04] I know you have a similar monitor :-) [16:05] rsalveti: We have plans to [16:05] rsalveti: I'm looking at it right now [16:05] rsalveti: They should be in there by Testy Tiger [16:08] lag: I hope you aren't referring to an ubuntu release by that name. [16:09] GrueMaster: Yep [16:09] haha [16:09] Jesh. You aussies are slow... :P [16:09] =:-D [16:09] GrueMaster: Don't make me get personal [16:09] heh [16:10] lunch time :-) [16:10] The TI tree is a bit of a mess [16:10] We're discussing how we should move forward currently === JaMa|Wrk is now known as JaMa [16:26] Bah. Today's omap4 image hangs past checking rootfs with no indicators. [16:27] worked for me [16:27] sigh. [16:30] These things always work for the person how develops them ;) [16:37] well, i didnt do anything specific [16:38] the image behaves the exact same way for me as yesterday [16:38] (which was the 09 image i tested) [16:40] And the omap image fails oem-config. [16:43] GrueMaster, ok, thanks, thats what i wanted to know [16:43] can you check in the rootshell if dbus is running for you ? [16:44] I see dbus-daemon --system --fork in the ps ax output. [16:45] weird [16:45] i dont on omap4 [16:46] My omap4 doesn't get very far, unfortunately. [16:46] do you see anything in 7var/crash ? [16:46] ubiquity-dm [16:46] only that ? [16:46] i got some more files there on omap4 [16:50] My omap4 doesn't appear to have actually mounted rootfs. Last item is : [16:50] fsck from util-linux-ng 2.17.2 [16:50] /dev/mmcblk0p2: clean, 155074/1858304 files, 536382/3895762 blocks [16:51] thats after first reboot ? [16:51] yes. First boot succeeds. [16:52] very strange [16:52] Between boots, I have to stop and fix boot.scr to get video. But it is the same settings I have always used, so I don't think they have any influence. [16:55] nah, shouldnt [16:55] And I checked. Both today's and 0809 have the same kernel. [16:56] (it would be nice to have a manifest to do full image comparisons - hint hint). === JaMa is now known as JaMa|Sp [17:18] ogra_cmpc: Rebooted panda. Now I get X (still no oem-config). Not sure why it started hanging like this. Works fine with the Alpha 3 image. [17:19] Now it just hands randomly with today's image, or 0809 image manually updated. [17:20] GrueMaster: you doing any audio on the panda? [17:21] prpplague: Not yet. Still working on gettng a stable image. I can go back to Alpha 3 and do more testing there. === hrw is now known as hrw|gprs [18:22] ogra_cmpc: What would I file a bug against to note that the linux-headers-omap4 are not installed on the omap4 image? We have omap, dove, and imx51, but no omap4. [18:31] GrueMaster: the package is there, do you know who should depend on it? [18:33] Not really. I know the package is there. Also, I am running the Alpha 3 image at the moment and doing an update, but it doesn't see the linux-image-2.6.34-903-omap4_2.6.34-903.7_armel.deb kernel as an upgrade option, even with dist-upgrade. [18:33] And today's image isn't using it either. [18:34] GrueMaster: yep, that's what I saw now [18:34] the new package is there but the package linux-image-omap4 is depending on the older one [18:34] Depends: linux-image-2.6.34-902-omap4, linux-firmware [18:34] that should be the reason [18:35] yea, that would be it. sigh [18:35] now we need to know why it was not updated with the kernel update [18:40] hm, is just the meta package [18:40] yes. But why isn't it getting updated? Or is it stuck in the build queue? [18:41] GrueMaster: could be [18:42] Looks like 903.7 was built on the 7th. Should have had a meta package by now. [18:44] GrueMaster: but the meta package wasn't updated with the kernel package [18:44] or should it be automatically updated? [18:44] Not sure. Something for the kernel team. [18:44] let me try to understand how it works [18:44] argh, and we had the new kernel days ago and because of this you're testing an older version =\ [18:45] yep. [18:46] Of course the images, while building, are currently broken due to bug 616581. [18:46] Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/616581 [18:46] Which is why I am running A3 and updating. Very slowly updating. [18:46] yep, but at least the kernel issues you got could be fixed already [18:47] tell me about it [18:47] that's why for development I'm using a external usb hd [18:49] usb HD is faster than the SD? [18:49] I hadn't benchmarked it. [18:49] on omap3? [18:49] panda [18:49] probably same [18:49] it seems faster [18:49] on omap3 you get 5MB/s read from sd and 14MB/s from same sd in usb card reader [18:50] ouch [18:50] thats from my tests on beagleboard [18:50] I don't think the drive is the limiting factor. Pulling updates from ports.ubuntu.com is slow on a good day. [18:50] and I have 0.5$ worth card reader [18:51] Sounds like something plars could look into. He's into performance issues. [18:51] I am? [18:51] I'm mainly concerned with functionality atm. [18:52] I thought that was your focus this cycle. [18:53] hrw|gprs: that's interesting, haven't looked at it personally though [18:53] GrueMaster: technically, my focus is tools [18:54] ah. [18:54] which got turned into s/tools/infrastructure [18:54] heh. [18:55] would be a good thing for the landing teams to look at [18:55] it makes me wonder what the results of the same test would be on dove or babbage [18:55] and others [18:55] is this an arm thing, or a beagle specific thing [18:56] Right now, I am more concerned with getting a working image. How fast it fails is irrelevant. :P [18:56] arm or omap3 or a beagle [18:57] I have to check one day how fast beagleboard is with my 1.5TB sata harddrive when it is on usb bus. [18:57] over sata it does 110MB/s, over usb with sheevaplug it did 30MB/s without problems [18:58] hrw|gprs: what are you testing with? [18:59] it was simple 'hdparm -tT' [18:59] on beagle I used dd [19:00] rsalveti: omap4 meta package is being looked into. [19:00] GrueMaster: yep. ot [19:00] it's missing an update [19:00] I'll forward it to tgardner [19:00] helps having two kernel crunchers in my town. [19:01] I'm just updating it and will send to the kernel devs [19:01] argh, some io is killing my machine [19:01] and pulse get stuck everytime [19:02] but if you give me armv4t rootfs then I can do any set of strange tests [19:18] GrueMaster: ogasawara is updating the linux-meta package [19:18] we should get it updated soon [19:18] rsalveti: I know. I have a back channel to her and others in Portland. But thanks. [19:20] GrueMaster: oh, you cheated [19:20] :-) [19:20] Of course. [19:20] Something I learned at Intel. It is sometimes easier to use back channels to get things done quickly. [19:23] GrueMaster: sure [19:24] the kernel seems to be a little mess [19:24] you have to update the kernel and also update the meta package [19:24] they are at a git tree, and not bzr, so merge proposals don't basically work [19:26] and the meta package is with a wrong version [19:26] and wrong description [19:34] GrueMaster: at tomorrow's image you'll get the latest kernel :-) [19:34] Yes, I know. [19:34] with new fixes and hopefully without any other new bug [19:34] :-) [19:34] GrueMaster: yeah, why I'm talking with you, you must be cheating again [19:34] :P [19:36] * rsalveti starts looking for his beagle xm [19:37] GrueMaster: do you know what is the memory chip that we have issues with xm? [19:37] * rsalveti now needs to find about the xm known issues [19:37] I think it is a kingston, but not sure. I don't have an XM yet (next week). [19:55] rsalveti: Have you seen the issue with panda where the sd interface shuts down? I have this message: INFO: task mmcqd:46 blocked for more than 120 seconds. followed by other blocked tasks. [19:55] And it appears to be SD related. [19:56] I have mouse, but no keyboard. That means the USB is semi-functional. [19:58] GrueMaster: hm, never saw it [19:59] GrueMaster: how do you generally hits this issue? === andy_ is now known as andyj [19:59] I was running apt-get update. Just stopped during logrotate upgrade. [20:02] Unfortunately there are no log entries and nothing on serial console (beyond what I posted). [20:03] hm [20:03] GrueMaster: are you updating from alpha 3 to current? [20:03] if you can reproduce it, we could try with 903 [20:04] * GrueMaster patiently waits for the beagle to finish updating the highly needed voodo graphics drivers and other X drivers. [20:04] lol [20:04] * rsalveti hates that [20:04] I plan on it. Unfortunately, reproducing these types of bugs can be problematic at best. [20:05] * GrueMaster wonders if his flyswatter would be useful in this situation. === JaMa|Sp is now known as JaMa [21:36] mpoirier: Cool find on the mtd support issue for beagle. Let me know when you have a kernel you need me to test. [21:37] GrueMaster: Ok, I'll compile something toghether... [22:25] ahh... coffee [22:29] GrueMaster: http://gitorious.org/pandaboard/u-boot/commits/omap4_panda_es2.0 [22:30] GrueMaster: http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_es2.0 [22:30] rsalveti: Thanks. [22:30] http://gitorious.org/pandaboard/kernel-omap4/commits/L24.8_panda_es2.0 [22:30] New kernel as well? [22:31] GrueMaster: yea, it adds the EHCI support [22:31] hm [22:32] GrueMaster: I can grab the patches and generate a deb file for you, if needed [22:33] GrueMaster: http://people.canonical.com/~mpoirier/linux-image-2.6.35-15-omap_2.6.35-15.22_armel.deb [22:33] I have my dev environment setup already [22:33] GrueMaster: at least for kernel [22:33] rsalveti: I have a pbuilder environment on my dove. Decently fast native builds. [22:34] mpoirier: Thanks, will test today. [22:34] GrueMaster: cool, so np :-) === jkridner_ is now known as jkridner [22:34] dyfet: is https://bugs.launchpad.net/bugs/b608279 still valid ? [22:36] GrueMaster: do you know anything about https://bugs.launchpad.net/bugs/608279 [22:39] mpoirier: That was based on some really early testing I did with read-edid. dyfet should be actively involved with this issue. [22:40] GrueMaster: I was able to read the EDID from u-boot. [22:40] what user space tool did you use ? [22:41] read-edid. [22:41] ok, I'll try. [22:42] mpoirier: See https://blueprints.launchpad.net/ubuntu/+spec/mobile-m-omap-edid-autodetection. [22:43] got that thanks. === jldugger is now known as pwnguin === orbarron is now known as orbarron|OoO [23:55] rsalveti: I think you will need to build the required files. I am not setup for this type of build. I am setup for package building. [23:56] GrueMaster: np, I just wanted to know the es2 specific patches so I can put it my ubuntu tree for the moment [23:56] and build the package like any other ubuntu tree [23:56] let me take a look at it [23:59] * GrueMaster needs a break.