[08:10] ogra: morning! [i changed my nick to a shorter one...] [08:10] ogra: I tried the latest OMAP3 image on Zoom2. I don't have the USB issue anymore, but since display driver for Zoom2 is not upstream, there is no display support [08:11] ogra: i am trying to get a display driver, if I can find something that works i will let you know === hrw|gone is now known as hrw [08:14] morning [08:15] ndec, forward that to amitk then, he cares for kernel implementation [08:15] ndec: no usb? [08:15] amitk, no issues :) [08:15] aah, [08:15] * amitk is still waking up [08:16] * ogra also bumped compcache to 50%, i'll build an image later today that should run flawless on the C4 beagle [08:16] ogra: is there an official image available now? [08:16] amitk: well, i am not sure the boot goes fine. there is obviously no kernel panic. but since there is no display I can't see much. on the console I can see some services firing up such as APM, Pulse, ... [08:16] amitk, yes, but it will OOM without the new compcache setting [08:17] ndec, change boot.scr and add serialtty=ttyS3 [08:17] ndec, i have it happily booting with that to serial commandline prompt [08:18] ogra: with splash too, i presume? [08:18] amitk, hheh, hard to tell on the zoom :) [08:18] (without graphics driver) [08:18] right [08:18] i meant on beagle C4 [08:18] but i usually leave spalsh in place on the cmdline [08:18] c$ will have plymouth, yes [08:19] buut the graphics have some issues [08:19] *c$ [08:19] grr [08:19] *C4 [08:20] ther wallpaper has stripes and once X comesu up (before the desktop is drawn) i can wipe the wallpaper with my cursor [08:20] its a _feature_, a paint program at bootup [08:20] yeah, i thought the same :) [08:20] if you managed to wipe the entire screen, you get a prize [08:21] oh, i'll try that [08:21] what is the prize ? a surprise ? [08:22] ofcourse, what would be the fun otherwise [08:22] lool, "I would also prefer if we'd simply change the compcache check from 512 MiB to 256 MiB" can you elaborate what you meant with that ? you would prefer to make compcache to not be used at all ? [08:23] (thats how i read it) [08:24] ogra: with serialtty I also have the console... this is really slow, though [08:25] currently compcache is only used on systems > 256MiB (by definition we dont support anything less) < 512MiB (which the current check code achieves) [08:25] ndec, its a live image on a 256M board ... dont expect miracles [08:25] ndec: live images are usually slow [08:25] half of your FS lives in RAM [08:26] and on 256M half of that RAM is even compressed [08:27] ogra, amitk: ok. the problem with display is that the DSS2 panel driver is missing for the Zoom2 (it's a NEC display). we currently have panel driver for .32, which was before some important DSS2 rework. so i cannot easily merge the panel code. [08:27] ogra: I thought you cared to have it work with 256 MB as well? [08:27] lool, it will automatically work with 256M [08:28] amitk: for the record, the zoom2 panel driver is here https://patchwork.kernel.org/patch/83907/, but it needs rework [08:28] Ah well, the test is for > 512 M [08:28] lool, as long as RAM is less than 512M compcache kicks in, determines the actual RAM sice and takes $COMPCACHE_SIZE and compressed swap [08:29] with 256MB you end up with 384MB of actual usable RAM space [08:29] ogra: Anyway, what I meant is that I find it easier to change the defaults, but that has a much higher impact obviously [08:29] lool, as i said, we need to rework the world here anyway for maverick [08:29] the implementation changed completely [08:30] ? [08:30] so we can find something saner than the current implementation [08:30] lool, compcache went into mainline with .345 [08:30] *.34 [08:30] its in staging in .33 [08:30] and needs userspace tools that do all the setup now ... instead of module options [08:31] from hardy to today compcache lives in the ubuntu modules dir [08:31] with the older implementation [08:32] the userspace tools require us to reqork the initramfs hooks from scratch [08:32] *rework [08:32] ndec: is anybody working to upstream the panel driver? [08:32] ogra: BTWhow was the value <= 512 M chosen? [08:32] amitk: i guess so, i am checking. [08:32] ogra: I'm a bit surprized that we include 512 MB machine with compcache [08:33] lool, after discussion with cjwatson ... [08:34] if ram is issue and you provide SD card image then why not use dual partitions like beagleboard people usually do and have rootfs on mmcblk0p2? [08:34] the 25% value was chosen in hardy when we could boot with 256M + compcache and that gave us ~300M which prevented OOM [08:34] with lucid the requirements raised [08:34] What I find odd is that pretty much all discussions revolve arund 256 MB systems [08:35] Yet the check is against 512 MB [08:35] the check just means "if you are having 512M or more we dont want to use compcache at all since your ram suffices" [08:36] compccache is *just for preventing OOM on systems with less than 512M* [08:36] ogra: Note that it's turned on for 512 MiB [08:36] in 512M you can run desktop + ubiquity without hittig issues [08:36] its not :) [08:36] read the code you pasted in the bug :) [08:36] if [ "\${TOTAL_RAM}" -gt 524288 ]; then [08:36] exit 0 [08:36] right [08:37] Which means that if the RAM is strictly more than 512 MiB, the script is disabled [08:37] if you have more than 512M the code exits [08:37] <= [08:37] But if it's exactly 512 MiB it's not [08:37] ah, that you mean [08:37] well, feel free to make it 524287 [08:37] < vs. <= [08:37] Geez [08:37] We have -ge thankfully [08:38] if you find it that important [08:38] ogra: What I don't understand is that even with 524287 you can run the desktop [08:38] you can ... [08:38] why shouldnt you [08:38] What I would find logical, is that we turn it on only for x where x+50% = 512M [08:38] its just to prevent OOM === ndec is now known as ndec_ [08:38] you can run the desktop in 384M [08:39] so your formula should be x+50% = 384 [08:39] thats the bare minimum === ndec_ is now known as ndec [08:39] cjwatson simply wanted compcache up to 512 to have a savety net [08:39] *safety [08:40] ogra: there's a difference between x > 512 and x + 50% > 512 [08:41] yes, the latter raises the minimal reqs. [08:41] Err no, it's the other way around! we turn compcache on earlier [08:41] we used to have a minimal req of 256M ... short before hardy that raised to 384 [08:42] so the decision was to use compcache on all systems between 256 and 512M [08:42] and use 25% of the ram for compressed swap [08:42] that minimal req doesnt suffice anymore [08:42] guys... [08:42] so to run on 256M without hitting OOM you need 50% [08:42] which arm platform today has video which does not take part of system ram? [08:43] on omap3 you have 4-12MB for vram so 512MB system has <512MB ram [08:44] lool, so do you want the -ge change ? i'm fine doing that [08:44] (since i have the branch open anyway) [08:44] ogra: No, I think the math is wrong; the -ge versus -gt happens to include a larger number of systems to the compcache thing, but I would rather fix the math [08:44] hrw, that amount doesnt really matter much we use 12M on beagle C4 and it works fine with the 50% [08:45] hrw: Note that while the changes which triggered the discussion are needed for OMAP, the code is used on all platform including x86 systems [08:45] lool, well, then go ahead as long as you dont break it ... i dont have the time to work much more on that (there are still flash-kernel changes and partman i have to do before thu. and i need a working image from teh archive today) [08:46] Bah I don't want to bother cjwatson if you agreed to the current approach [08:46] lool, just take into account that there are tools in universe and debian that make use of compcache [08:47] ogra: I'm not sure what you mwan [08:47] lool, in case you remove variables or change their meaning these tools need transition [08:47] iirc there is at least one debconf frontend tool in debian to manually set compcache [08:48] which relies on the values [08:48] and variable naming [08:48] ok [08:48] lool, really, i wouldnt bother in the light that we have to redo it anyway next release [08:49] and in the light that the current approach works since hardy [08:50] The only thing which worries me is that compcache is turned on for all flavours [08:50] lool, thats wanted [08:50] Pretty much all vms will have it enabled [08:50] Even if they don't run the desktop [08:50] why would that be a bad thing [08:50] thats not true [08:50] compcache is in casper ... [08:51] and I can imagine that will mess up with things like kvm page sharing algorithms [08:51] do we use casper in vm images ? [08:51] Well that's the thing, it's an assumption of live image image => desktop [08:51] if so and if server people dont want compcache that should probably be adressed [08:52] it surely comes from a time where we definately only used casper in desktop live images [08:52] I guess it's unlikely that someone fiddles with the COMPCACHE settings on server images [08:52] if that changed someone should indeed change behavior [08:53] Anyway, I guess that if there was a class of affected users, we'd hear about it [08:53] when i implemented it i did that for calssmates with 256M only ... and cjwatson insisted back then (pre hardy) to have it on all arches/images [08:53] *classmates [08:53] its a cheap way to get more ram without much penalty [08:54] so even VMs might benefit [08:57] sigh, all builders are busy with big packages ... [08:58] i want my casper build ... damned ... [09:00] * ogra wonders if we have any example code for the 120min buildd timeout stuff ... libgphoto2 needs such a fix [09:01] err, 150min === XorA|gone is now known as XorA [09:03] * ogra goes to test a netinst image while waiting for casper [09:03] omap3 usb is now working? [09:04] yes [09:04] since last kernel upload [09:04] cool [09:08] [ 25.152954] Trying to unpack rootfs image as initramfs... [09:08] [ 25.154846] rootfs image is not initramfs (no cpio magic); looks like an initrd [09:08] GRRR ! [09:08] netinst still doesnt work [09:09] * ogra wonders why [09:09] persia persia!! seen this yet? http://www.wirefresh.com/sharp-introduces-the-is01-android-powered-smartbook/comment-page-1/ [09:09] ogra: On which platform is this? [09:09] lool, omap netinst [09:10] [ 26.649200] RAMDISK: gzip image found at block 0 [09:10] [ 26.762176] RAMDISK: incomplete write (4546 != 32768) [09:10] jussi01: sharp... argh [09:10] the same load values that work on all other setups dont seem to work for netinst [09:10] hrw: they are the only ones really doing anything near this at the moment though. [09:11] lool, and i really use very conservative values that should leave enough space [09:11] jussi01: I have only bad experience when it comes to sharp and linux [09:11] ogra: I'd check ramdisk size (you can override it on the cmdline) or it might be again our kernels being too big [09:11] lool, well, its only 3M and i leave about 10 with my load address [09:12] that shold suffice even with the unpacked kernel [09:20] ogra: I'm pretty sure it's the ramdisk size [09:20] It's at 4096 [09:20] ogra: Try passing ramdisk_size=16384 on the kernel cmdline [09:20] yeah, it fixes the corruption but i still cant get it to boot [09:20] ogra: Does it unpack the ramdisk correctly now? [09:21] amitk: Could you bump CONFIG_BLK_DEV_RAM_SIZE to 65536 as on the other kernels? [09:21] It's a lot for OMAP, but the memory is claimed back anyway [09:21] [ 26.690032] /build/buildd/linux-ti-omap-2.6.33/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [09:21] [ 26.699645] RAMDISK: gzip image found at block 0 [09:21] [ 26.844573] hub 1-2:1.0: USB hub found [09:22] so 16384 fixes the corruption [09:22] lool: ack [09:22] but it still panics [09:22] amitk: thanks [09:22] ogra: what's the panic? [09:22] [ 27.108520] VFS: Mounted root (ext2 filesystem) on device 1:0. [09:22] [ 27.136840] VFS: Cannot open root device "(null)" or unknown-block(0,0) [09:22] [ 27.143493] Please append a correct "root=" boot option; here are the available partitions: [09:22] ogra: What format is your initrd? ext2? [09:23] lool, no idea, what does d-i use for the netinst ones ? [09:23] ogra: depends of the image, usually ext2 [09:23] right, thats what i would expect [09:23] the cdrom initrd works flawless [09:23] INITRD_FS = ext2 in build/config/armel.cfg [09:24] its really only the netinst one [09:24] they should be identical format i think [09:24] cdrom uses INITRD_FS = initramfs [09:24] really ? [09:24] check build/config/armel/omap/cdrom.cfg [09:24] i thought d-i uses the same format all over the place to roll them [09:25] ogra: So did you pass root=/dev/ram0? [09:25] ok, but our kernel surely has ext2 builtin [09:25] no [09:25] I think you need that [09:25] i dont need to pass that on other arches [09:25] neither dove nor imx51 need it [09:25] * ogra tries [09:26] build/config/armel/imx51/netboot.cfg has INITRD_FS = initramfs, but not dove; I don't think we tested dove netboot images for a while though [09:26] lool, geez ! [09:27] works [09:27] thanks a lot ! [09:27] ogra: So it might make sense to move to initramfs instead [09:27] yeah [09:27] will do that [09:27] ogra: You might want to test the dove netboot initrd too; I'm pretty sure you need to pass root=/dev/ram0 there too [09:27] hrm, and it looks like d-i needs the ethernet modules [09:28] lool, i have no HW to test dove [09:28] only NCommander does [09:28] and GrueMaster [09:28] * ogra wonders which udeb has all the usb ETH modules and firmware [09:29] initramfs is the absolute default and probably we should switch armel to it [09:29] ogra: nic-modules [09:29] that also has the usb ones ? [09:29] firmwares are likely a separate one [09:29] I'm not sure about usb, but you might need another udeb for usb by itself [09:29] i thought usb nics are separate too [09:30] usb support is builtin [09:30] i need HID though [09:30] You want nic-usb and usb for USB ethernet adapters [09:30] plus the firmware udebs [09:31] ogra: just copy the list from some d-i build file [09:32] nic-usb-modules and usb-modules are there, but i dont see anything wrt firmware at https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.5/+build/1684225 [09:33] I dont think it's built from linux-ti-omap [09:33] its also not in linux-fsl-imx51 :& [09:34] :/ [09:34] it's the nic-firmware udeb [09:34] built from linux-firmware [09:34] hmm, nor on dove [09:35] oh, then i'm looking at the worng packages ... [09:35] aha ... its arch all [09:41] hrm, where is build/pkg-lists/netboot/arm/omap.cfg gone in the d-i tree [09:42] * ogra thought he added that [09:43] I don't see it [09:44] I'd copy imx51.cfg [09:44] just did :) [09:44] and fixed up the comment [09:44] * ogra also drops gzip compression form the initrd for netinst ... we dotn use it anywhere else in omap [09:45] (from mkimage) [09:45] ogra: You didn't copy it for netboot though? [09:45] lool, i just did in my tree [09:49] there we go [09:53] and uploaded :) [09:53] next d-i build should get us working netinst images ! [09:53] so only flash-kernel and partman are left on my list [09:53] \o/ [09:53] we're getting there :) [10:01] Hi all, does anyone know a way to inhibit the building of debug packages when building debs? [10:01] ...or to force the use of a compressor other than lzma [10:02] I'm having real problems building qt4-x11--- my board has been building debs for about 3-4 days and is swapping so much I can't log into it any more [10:03] ogra: on the BB, my mouse (USB) is not detected. where do you plug it? [10:04] ndec: are you using the OTG port? [10:05] no. host. but it does seem that proper drivers are there, right? [10:05] EHCI works for me, I'm working on OTG atm. [10:06] ndec: It doesn't work though powered hub? [10:06] dmart: It's a real -dbg? [10:06] dmart: or -dbgsym? [10:06] dmart: comment out the -Zlzma from debian/rules [10:07] suihkulokki: OK, great, thanks [10:07] lool: -dbg in this case [10:07] I've a nasty feeling /tmp is a tmpfs [10:07] which may be causing problems here [10:08] amitk: i don't have a powered USB hub with me, ATM [10:10] ndec: AFAIK, BB doesn't support Full speed devices on the EHCI port w/o a powered hub. (http://elinux.org/BeagleBoard#USB) [10:10] yes [10:10] ndec: since the port only supports high speed [10:10] ehci is 2.0 only [10:21] hrw: ogra: have anything to test the OTG port on the BB? [10:21] you mean usb-host cable [10:21] ? [10:22] hrw: right [10:23] I would have to dig for it as I do not remember when last time used [10:23] and definitelly not today [10:23] ok [10:23] amitk: will be easier to check in two weeks from now [10:23] amitk: thx. I need to find the adaptors/HUB [10:25] and today is not my day for work ;( [10:26] ndec: I've uploaded another kernel at http://people.canonical.com/~amitk/ti/ to test OTG configuration. Unfortunately, I don't have the usb-host cable to test (Need to go out and buy) [10:26] amitk: don't have it neither... [10:27] solder one - easier then buying new one usually [10:30] hrw: any ready pointers to convert an existing cable? [10:31] take miniusb->usb cable, unbreak miniusb one, solder two pins, add usba->usba gender changer [10:34] * amitk probably has enough mini->normal usb cables and gender changers. No time, though. :-/ [10:36] I have more then enough usb connectors [11:05] amitk, i only have a std adapter (several of them) but nothing with the shortened pins (as i told you on friday) [11:07] NCommander, can you bump the casper build a bit higher so it gets attempted at some point today ? https://launchpad.net/ubuntu/lucid/+source/casper/1.232 [11:08] * ogra doesnt understand why d-i just passed it even though it was uploaded hours later [11:08] they had the same score [11:10] any new arm notebooks? [11:11] a rival for ipad? when? [12:02] ipad? I would rather prefer rival for my dell d400 ;D [12:02] grmbl [12:03] so my NIC is seen by the netinst image but no firmware is loaded [12:04] aha, asix works [12:04] * ogra wonders why the other one doesnt [12:09] hrw: ipad is the more successfull arm device in the market (according to news) [12:09] hrw: in netbook context [12:09] zumbi: show me arm netbooks on market (other then touchbook) [12:11] amitk, hmm, it seems my installation attempts all break on usb-storage atm ... [12:11] hrw: sharp netwalker, alwaysinnovating, efikamx, ipad, not sure if amazon wikireader counts as arm netbook [12:11] so netwalker and efikamx only... [12:12] alwaysinnovating is a beagleboard [12:12] zumbi: I know what AI touchbook is [12:12] beagleboard + usb hub + display + usb keyboard [12:13] is it homemade? [12:13] netwalker pc-z1 reminds me nightmares [12:13] amitk, [ 212.130981] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000 shows up reliably when d-i is trying to detect disks [12:13] zumbi: touchbook design is based on beagleboard design/schematics but it is whole new device not BB+cables [12:14] zumbi: efikamx smartbook looks quite good but it is freescale... [12:15] I have bad experience with both sharp (from zaurus times and 8MB kernel diffs) and with freescale (again 8MB kernel diffs) [12:16] yes, i'd like to see imx51 in mainline with efikamx support [12:17] zumbi: 2.6.50 probably [12:17] is .50 guessed by a random function :) [12:18] so far i.mx support looks like in-kernel maintainer has own version based on code drops from freescale [12:18] yes, efika uses freescale SDK... :-/ [12:18] zumbi: 2.6.50 ~= never (or 'when people forgot that such thing existed) [12:19] Apr 12 11:18:47 main-menu[208]: INFO: Menu item 'partman-base' selected [12:19] Apr 12 11:18:48 kernel: [ 556.388214] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000 [12:19] Apr 12 11:18:48 main-menu[208]: (process:7234): Bus error [12:19] amitk, ^^^^ [12:24] hrw: /me is the maintainer of i.MX51 in mainline [12:24] phone... [12:25] ogra: ok, looking at it [12:25] amitk, cjwatson suggests its misaligned memory access [12:26] ogra: I am almost sure it has to do with clocks being turned off during module access [12:28] amitk: Oh you are [12:30] lool: huh? [12:32] amitk: Re: /me is the maintainer of i.MX51 in mainline; I didn't know that [12:32] amitk: congrats! [12:32] lool, since ages :) [12:33] I hadn't followed that change [12:33] It's not in our lucid kernel tree at least, so can't be that old! [12:33] 4th February [12:33] iirc it happened early lucid ... so .33 mainline [12:34] or beginning of .34 [12:34] .34 === dyfet` is now known as dyfet [12:35] amitk, how fast can we get a fix for the issue above ? since it blocks partman from starting i cant do any of the other image changes (which all happen after partman) [12:35] amitk, a test kernel for live would suffice [12:36] ogra: Do you have any serial console enabled? [12:36] lool, not by default [12:36] you need to change boot.scr [12:36] ogra: But did you turn them on? [12:37] Sometimes it triggers this issue [12:37] ogra: I'm looking.... can't tell you before I understand the problem [12:37] lool, it also happens on the live image without serial turned on [12:37] but i can try a d-i netinst one without right now [12:38] * ogra fiddles with boot.scr [12:38] I wonder whether partman would be attempting to touch the 3/4 possible SD cards which might not all be present on your card [12:38] amitk: great! :) [12:38] ogra: Would be interesting if you could identify which device access causes this problem; perhaps with ls-partitions or some other d-i command, or stracing partman [12:39] lool, already tried its /lib/partman/init.d/30parted but i cant get anything out of it with set -x [12:39] Hmm who's working on the qcm kernel? [12:40] lool, rtg afaik [12:40] Is any image expected for it?! [12:40] i dont think so [12:40] I wonder how tested that kernel is [12:40] Hi All [12:41] GoodEvening [12:41] lool: no image, minimal testing for qcm [12:41] Anybody can Suggest me some nice Window manager for ubuntu ARM [12:41] amitk: k thanks [12:43] GRRR [12:43] oh how i hate that you have to define omapfb crap on the console to get any video output *at all* [12:44] siji: This is not really specific to ARM; depends of your use case [12:45] lool, am looking for a handheld device [12:45] ogra: Speaking of which, did we sync both omap xorg drivers from Debian recently? [12:45] lool, a while ago [12:45] siji: You could checkout matchbox [12:45] I need some fancy Desktop [12:45] ogra: The two of them? [12:45] with smooth animations etc.. [12:46] lool, NEON and non NEON version, yep [12:46] sort of ubuntu-netbook launcher [12:46] siji, use ubuntu-netbook then [12:46] amitk: I did not knew [12:46] and possibly replace the panel with something lighter [12:47] siji, on armel it will default to use the efl version of the netbook launcher [12:47] ogra, ok [12:47] ogra: you can also ignore boot.scr, boot device to uboot and enter commands by hand/copypaste [12:47] I could only find the xf86-video-omapfb source, what's the other one?? [12:47] siji: how bug screen? [12:47] siji: and how big resolution [12:47] 7'' [12:48] LCD with touch screen [12:48] 800x480? [12:48] yes [12:48] I would use matchbox or something small/light [12:48] hrw, i'm way to lazy for that :P [12:48] * ogra <3 boot.scr [12:48] fluxbox, icewm, xfwm4 maybe [12:48] ok [12:49] lool, its the same source, two binaries [12:49] lool, one with and the other built without NEON [12:49] Ok just making sure [12:51] sigh [12:51] * ogra tries since 10min to get some video output from the beagel .... just to find i used the wrong HDMI cable [12:53] * hrw -> phone again [13:01] hrm, my kbd doesnt work [13:06] amitk, urgh ... [13:06] amitk, seems DSS2 doesnt properly work yet [13:07] i can switch consoles but the screen always shows tty1 === ogra_ is now known as ogra [14:02] dmart: hi [14:02] hi there [14:02] dmart: i think i need your input on xine-lib [14:02]