**** BEGIN LOGGING AT Mon Apr 12 02:59:56 2010 Apr 12 07:10:17 ogra: morning! [i changed my nick to a shorter one...] Apr 12 07:10:54 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 Apr 12 07:11:15 ogra: i am trying to get a display driver, if I can find something that works i will let you know Apr 12 07:14:39 morning Apr 12 07:15:28 ndec, forward that to amitk then, he cares for kernel implementation Apr 12 07:15:31 ndec: no usb? Apr 12 07:15:38 amitk, no issues :) Apr 12 07:15:47 aah, Apr 12 07:15:53 * amitk is still waking up Apr 12 07:16:22 * ogra also bumped compcache to 50%, i'll build an image later today that should run flawless on the C4 beagle Apr 12 07:16:38 ogra: is there an official image available now? Apr 12 07:16:55 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, ... Apr 12 07:16:56 amitk, yes, but it will OOM without the new compcache setting Apr 12 07:17:16 ndec, change boot.scr and add serialtty=ttyS3 Apr 12 07:17:44 ndec, i have it happily booting with that to serial commandline prompt Apr 12 07:18:02 ogra: with splash too, i presume? Apr 12 07:18:19 amitk, hheh, hard to tell on the zoom :) Apr 12 07:18:26 (without graphics driver) Apr 12 07:18:33 right Apr 12 07:18:42 i meant on beagle C4 Apr 12 07:18:46 but i usually leave spalsh in place on the cmdline Apr 12 07:18:54 c$ will have plymouth, yes Apr 12 07:19:01 buut the graphics have some issues Apr 12 07:19:08 *c$ Apr 12 07:19:11 grr Apr 12 07:19:14 *C4 Apr 12 07:20:04 ther wallpaper has stripes and once X comesu up (before the desktop is drawn) i can wipe the wallpaper with my cursor Apr 12 07:20:36 its a _feature_, a paint program at bootup Apr 12 07:20:47 yeah, i thought the same :) Apr 12 07:20:57 if you managed to wipe the entire screen, you get a prize Apr 12 07:21:06 oh, i'll try that Apr 12 07:21:15 what is the prize ? a surprise ? Apr 12 07:22:28 ofcourse, what would be the fun otherwise Apr 12 07:22:50 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 ? Apr 12 07:23:52 (thats how i read it) Apr 12 07:24:34 ogra: with serialtty I also have the console... this is really slow, though Apr 12 07:25:12 currently compcache is only used on systems > 256MiB (by definition we dont support anything less) < 512MiB (which the current check code achieves) Apr 12 07:25:32 ndec, its a live image on a 256M board ... dont expect miracles Apr 12 07:25:38 ndec: live images are usually slow Apr 12 07:25:54 half of your FS lives in RAM Apr 12 07:26:16 and on 256M half of that RAM is even compressed Apr 12 07:27:02 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. Apr 12 07:27:32 ogra: I thought you cared to have it work with 256 MB as well? Apr 12 07:27:54 lool, it will automatically work with 256M Apr 12 07:28:36 amitk: for the record, the zoom2 panel driver is here https://patchwork.kernel.org/patch/83907/, but it needs rework Apr 12 07:28:37 Ah well, the test is for > 512 M Apr 12 07:28:40 lool, as long as RAM is less than 512M compcache kicks in, determines the actual RAM sice and takes $COMPCACHE_SIZE and compressed swap Apr 12 07:29:13 with 256MB you end up with 384MB of actual usable RAM space Apr 12 07:29:17 ogra: Anyway, what I meant is that I find it easier to change the defaults, but that has a much higher impact obviously Apr 12 07:29:35 lool, as i said, we need to rework the world here anyway for maverick Apr 12 07:29:50 the implementation changed completely Apr 12 07:30:08 ? Apr 12 07:30:15 so we can find something saner than the current implementation Apr 12 07:30:25 lool, compcache went into mainline with .345 Apr 12 07:30:27 *.34 Apr 12 07:30:37 its in staging in .33 Apr 12 07:30:57 and needs userspace tools that do all the setup now ... instead of module options Apr 12 07:31:30 from hardy to today compcache lives in the ubuntu modules dir Apr 12 07:31:39 with the older implementation Apr 12 07:32:28 the userspace tools require us to reqork the initramfs hooks from scratch Apr 12 07:32:32 *rework Apr 12 07:32:37 ndec: is anybody working to upstream the panel driver? Apr 12 07:32:41 ogra: BTWhow was the value <= 512 M chosen? Apr 12 07:32:53 amitk: i guess so, i am checking. Apr 12 07:32:58 ogra: I'm a bit surprized that we include 512 MB machine with compcache Apr 12 07:33:16 lool, after discussion with cjwatson ... Apr 12 07:34:28 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? Apr 12 07:34:30 the 25% value was chosen in hardy when we could boot with 256M + compcache and that gave us ~300M which prevented OOM Apr 12 07:34:50 with lucid the requirements raised Apr 12 07:34:54 What I find odd is that pretty much all discussions revolve arund 256 MB systems Apr 12 07:35:01 Yet the check is against 512 MB Apr 12 07:35:35 the check just means "if you are having 512M or more we dont want to use compcache at all since your ram suffices" Apr 12 07:36:02 compccache is *just for preventing OOM on systems with less than 512M* Apr 12 07:36:13 ogra: Note that it's turned on for 512 MiB Apr 12 07:36:27 in 512M you can run desktop + ubiquity without hittig issues Apr 12 07:36:33 its not :) Apr 12 07:36:45 read the code you pasted in the bug :) Apr 12 07:36:48 if [ "\${TOTAL_RAM}" -gt 524288 ]; then Apr 12 07:36:48 exit 0 Apr 12 07:37:00 right Apr 12 07:37:09 Which means that if the RAM is strictly more than 512 MiB, the script is disabled Apr 12 07:37:13 if you have more than 512M the code exits Apr 12 07:37:14 <= Apr 12 07:37:17 But if it's exactly 512 MiB it's not Apr 12 07:37:28 ah, that you mean Apr 12 07:37:41 well, feel free to make it 524287 Apr 12 07:37:48 Geez Apr 12 07:37:48 < vs. <= Apr 12 07:37:56 We have -ge thankfully Apr 12 07:38:02 if you find it that important Apr 12 07:38:08 ogra: What I don't understand is that even with 524287 you can run the desktop Apr 12 07:38:19 you can ... Apr 12 07:38:31 why shouldnt you Apr 12 07:38:36 What I would find logical, is that we turn it on only for x where x+50% = 512M Apr 12 07:38:37 its just to prevent OOM Apr 12 07:38:55 you can run the desktop in 384M Apr 12 07:39:10 so your formula should be x+50% = 384 Apr 12 07:39:20 thats the bare minimum Apr 12 07:39:47 cjwatson simply wanted compcache up to 512 to have a savety net Apr 12 07:39:53 *safety Apr 12 07:40:38 ogra: there's a difference between x > 512 and x + 50% > 512 Apr 12 07:41:11 yes, the latter raises the minimal reqs. Apr 12 07:41:35 Err no, it's the other way around! we turn compcache on earlier Apr 12 07:41:38 we used to have a minimal req of 256M ... short before hardy that raised to 384 Apr 12 07:42:03 so the decision was to use compcache on all systems between 256 and 512M Apr 12 07:42:18 and use 25% of the ram for compressed swap Apr 12 07:42:28 that minimal req doesnt suffice anymore Apr 12 07:42:40 guys... Apr 12 07:42:51 so to run on 256M without hitting OOM you need 50% Apr 12 07:42:57 which arm platform today has video which does not take part of system ram? Apr 12 07:43:29 on omap3 you have 4-12MB for vram so 512MB system has <512MB ram Apr 12 07:44:07 lool, so do you want the -ge change ? i'm fine doing that Apr 12 07:44:20 (since i have the branch open anyway) Apr 12 07:44: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 Apr 12 07:44:52 hrw, that amount doesnt really matter much we use 12M on beagle C4 and it works fine with the 50% Apr 12 07:45:46 hrw: Note that while the changes which triggered the discussion are needed for OMAP, the code is used on all platform including x86 systems Apr 12 07:45:56 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) Apr 12 07:46:31 Bah I don't want to bother cjwatson if you agreed to the current approach Apr 12 07:46:44 lool, just take into account that there are tools in universe and debian that make use of compcache Apr 12 07:47:00 ogra: I'm not sure what you mwan Apr 12 07:47:21 lool, in case you remove variables or change their meaning these tools need transition Apr 12 07:47:48 iirc there is at least one debconf frontend tool in debian to manually set compcache Apr 12 07:48:10 which relies on the values Apr 12 07:48:17 and variable naming Apr 12 07:48:18 ok Apr 12 07:48:41 lool, really, i wouldnt bother in the light that we have to redo it anyway next release Apr 12 07:49:12 and in the light that the current approach works since hardy Apr 12 07:50:11 The only thing which worries me is that compcache is turned on for all flavours Apr 12 07:50:26 lool, thats wanted Apr 12 07:50:33 Pretty much all vms will have it enabled Apr 12 07:50:38 Even if they don't run the desktop Apr 12 07:50:44 why would that be a bad thing Apr 12 07:50:52 thats not true Apr 12 07:50:57 compcache is in casper ... Apr 12 07:51:01 and I can imagine that will mess up with things like kvm page sharing algorithms Apr 12 07:51:04 do we use casper in vm images ? Apr 12 07:51:32 Well that's the thing, it's an assumption of live image image => desktop Apr 12 07:51:39 if so and if server people dont want compcache that should probably be adressed Apr 12 07:52:11 it surely comes from a time where we definately only used casper in desktop live images Apr 12 07:52:16 I guess it's unlikely that someone fiddles with the COMPCACHE settings on server images Apr 12 07:52:25 if that changed someone should indeed change behavior Apr 12 07:53:09 Anyway, I guess that if there was a class of affected users, we'd hear about it Apr 12 07:53:21 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 Apr 12 07:53:32 *classmates Apr 12 07:53:54 its a cheap way to get more ram without much penalty Apr 12 07:54:27 so even VMs might benefit Apr 12 07:57:52 sigh, all builders are busy with big packages ... Apr 12 07:58:05 i want my casper build ... damned ... Apr 12 08:00:53 * ogra wonders if we have any example code for the 120min buildd timeout stuff ... libgphoto2 needs such a fix Apr 12 08:01:16 err, 150min Apr 12 08:03:05 * ogra goes to test a netinst image while waiting for casper Apr 12 08:03:25 omap3 usb is now working? Apr 12 08:04:21 yes Apr 12 08:04:33 since last kernel upload Apr 12 08:04:58 cool Apr 12 08:08:25 [ 25.152954] Trying to unpack rootfs image as initramfs... Apr 12 08:08:26 [ 25.154846] rootfs image is not initramfs (no cpio magic); looks like an initrd Apr 12 08:08:28 GRRR ! Apr 12 08:08:37 netinst still doesnt work Apr 12 08:09:14 * ogra wonders why Apr 12 08:09:30 persia persia!! seen this yet? http://www.wirefresh.com/sharp-introduces-the-is01-android-powered-smartbook/comment-page-1/ Apr 12 08:09:51 ogra: On which platform is this? Apr 12 08:09:59 lool, omap netinst Apr 12 08:10:06 [ 26.649200] RAMDISK: gzip image found at block 0 Apr 12 08:10:06 [ 26.762176] RAMDISK: incomplete write (4546 != 32768) Apr 12 08:10:11 jussi01: sharp... argh Apr 12 08:10:23 the same load values that work on all other setups dont seem to work for netinst Apr 12 08:10:38 hrw: they are the only ones really doing anything near this at the moment though. Apr 12 08:11:13 lool, and i really use very conservative values that should leave enough space Apr 12 08:11:21 jussi01: I have only bad experience when it comes to sharp and linux Apr 12 08:11:25 ogra: I'd check ramdisk size (you can override it on the cmdline) or it might be again our kernels being too big Apr 12 08:11:56 lool, well, its only 3M and i leave about 10 with my load address Apr 12 08:12:08 that shold suffice even with the unpacked kernel Apr 12 08:20:01 ogra: I'm pretty sure it's the ramdisk size Apr 12 08:20:04 It's at 4096 Apr 12 08:20:14 ogra: Try passing ramdisk_size=16384 on the kernel cmdline Apr 12 08:20:24 yeah, it fixes the corruption but i still cant get it to boot Apr 12 08:20:37 ogra: Does it unpack the ramdisk correctly now? Apr 12 08:21:20 amitk: Could you bump CONFIG_BLK_DEV_RAM_SIZE to 65536 as on the other kernels? Apr 12 08:21:39 It's a lot for OMAP, but the memory is claimed back anyway Apr 12 08:21:56 [ 26.690032] /build/buildd/linux-ti-omap-2.6.33/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Apr 12 08:21:56 [ 26.699645] RAMDISK: gzip image found at block 0 Apr 12 08:21:56 [ 26.844573] hub 1-2:1.0: USB hub found Apr 12 08:22:06 so 16384 fixes the corruption Apr 12 08:22:08 lool: ack Apr 12 08:22:12 amitk: thanks Apr 12 08:22:12 but it still panics Apr 12 08:22:20 ogra: what's the panic? Apr 12 08:22:30 [ 27.108520] VFS: Mounted root (ext2 filesystem) on device 1:0. Apr 12 08:22:30 [ 27.136840] VFS: Cannot open root device "(null)" or unknown-block(0,0) Apr 12 08:22:30 [ 27.143493] Please append a correct "root=" boot option; here are the available partitions: Apr 12 08:22:49 ogra: What format is your initrd? ext2? Apr 12 08:23:05 lool, no idea, what does d-i use for the netinst ones ? Apr 12 08:23:19 ogra: depends of the image, usually ext2 Apr 12 08:23:29 right, thats what i would expect Apr 12 08:23:51 the cdrom initrd works flawless Apr 12 08:23:54 INITRD_FS = ext2 in build/config/armel.cfg Apr 12 08:24:06 its really only the netinst one Apr 12 08:24:17 they should be identical format i think Apr 12 08:24:31 cdrom uses INITRD_FS = initramfs Apr 12 08:24:42 really ? Apr 12 08:24:50 check build/config/armel/omap/cdrom.cfg Apr 12 08:24:55 i thought d-i uses the same format all over the place to roll them Apr 12 08:25:15 ogra: So did you pass root=/dev/ram0? Apr 12 08:25:20 ok, but our kernel surely has ext2 builtin Apr 12 08:25:23 no Apr 12 08:25:27 I think you need that Apr 12 08:25:31 i dont need to pass that on other arches Apr 12 08:25:45 neither dove nor imx51 need it Apr 12 08:25:47 * ogra tries Apr 12 08:26:43 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 Apr 12 08:26:59 lool, geez ! Apr 12 08:27:01 works Apr 12 08:27:05 thanks a lot ! Apr 12 08:27:14 ogra: So it might make sense to move to initramfs instead Apr 12 08:27:20 yeah Apr 12 08:27:27 will do that Apr 12 08:27:41 ogra: You might want to test the dove netboot initrd too; I'm pretty sure you need to pass root=/dev/ram0 there too Apr 12 08:27:51 hrm, and it looks like d-i needs the ethernet modules Apr 12 08:28:03 lool, i have no HW to test dove Apr 12 08:28:09 only NCommander does Apr 12 08:28:13 and GrueMaster Apr 12 08:28:38 * ogra wonders which udeb has all the usb ETH modules and firmware Apr 12 08:29:13 initramfs is the absolute default and probably we should switch armel to it Apr 12 08:29:22 ogra: nic-modules Apr 12 08:29:33 that also has the usb ones ? Apr 12 08:29:37 firmwares are likely a separate one Apr 12 08:29:50 I'm not sure about usb, but you might need another udeb for usb by itself Apr 12 08:29:51 i thought usb nics are separate too Apr 12 08:30:04 usb support is builtin Apr 12 08:30:23 i need HID though Apr 12 08:30:41 You want nic-usb and usb for USB ethernet adapters Apr 12 08:30:55 plus the firmware udebs Apr 12 08:31:07 ogra: just copy the list from some d-i build file Apr 12 08:32:26 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 Apr 12 08:33:17 I dont think it's built from linux-ti-omap Apr 12 08:33:58 its also not in linux-fsl-imx51 :& Apr 12 08:34:00 :/ Apr 12 08:34:00 it's the nic-firmware udeb Apr 12 08:34:04 built from linux-firmware Apr 12 08:34:47 hmm, nor on dove Apr 12 08:35:07 oh, then i'm looking at the worng packages ... Apr 12 08:35:42 aha ... its arch all Apr 12 08:41:36 hrm, where is build/pkg-lists/netboot/arm/omap.cfg gone in the d-i tree Apr 12 08:42:18 * ogra thought he added that Apr 12 08:43:55 I don't see it Apr 12 08:44:17 I'd copy imx51.cfg Apr 12 08:44:27 just did :) Apr 12 08:44:34 and fixed up the comment Apr 12 08:44:58 * ogra also drops gzip compression form the initrd for netinst ... we dotn use it anywhere else in omap Apr 12 08:45:07 (from mkimage) Apr 12 08:45:17 ogra: You didn't copy it for netboot though? Apr 12 08:45:28 lool, i just did in my tree Apr 12 08:49:58 there we go Apr 12 08:53:07 and uploaded :) Apr 12 08:53:20 next d-i build should get us working netinst images ! Apr 12 08:53:43 so only flash-kernel and partman are left on my list Apr 12 08:53:49 \o/ Apr 12 08:53:56 we're getting there :) Apr 12 09:01:46 Hi all, does anyone know a way to inhibit the building of debug packages when building debs? Apr 12 09:01:54 ...or to force the use of a compressor other than lzma Apr 12 09:02:30 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 Apr 12 09:03:51 ogra: on the BB, my mouse (USB) is not detected. where do you plug it? Apr 12 09:04:57 ndec: are you using the OTG port? Apr 12 09:05:23 no. host. but it does seem that proper drivers are there, right? Apr 12 09:05:58 EHCI works for me, I'm working on OTG atm. Apr 12 09:06:20 ndec: It doesn't work though powered hub? Apr 12 09:06:39 dmart: It's a real -dbg? Apr 12 09:06:45 dmart: or -dbgsym? Apr 12 09:06:49 dmart: comment out the -Zlzma from debian/rules Apr 12 09:07:09 suihkulokki: OK, great, thanks Apr 12 09:07:18 lool: -dbg in this case Apr 12 09:07:24 I've a nasty feeling /tmp is a tmpfs Apr 12 09:07:37 which may be causing problems here Apr 12 09:08:56 amitk: i don't have a powered USB hub with me, ATM Apr 12 09:10:12 ndec: AFAIK, BB doesn't support Full speed devices on the EHCI port w/o a powered hub. (http://elinux.org/BeagleBoard#USB) Apr 12 09:10:43 yes Apr 12 09:10:47 ndec: since the port only supports high speed Apr 12 09:10:47 ehci is 2.0 only Apr 12 09:21:22 hrw: ogra: have anything to test the OTG port on the BB? Apr 12 09:21:47 you mean usb-host cable Apr 12 09:21:48 ? Apr 12 09:22:43 hrw: right Apr 12 09:23:14 I would have to dig for it as I do not remember when last time used Apr 12 09:23:21 and definitelly not today Apr 12 09:23:32 ok Apr 12 09:23:41 amitk: will be easier to check in two weeks from now Apr 12 09:23:45 amitk: thx. I need to find the adaptors/HUB Apr 12 09:25:15 and today is not my day for work ;( Apr 12 09:26:06 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) Apr 12 09:26:37 amitk: don't have it neither... Apr 12 09:27:28 solder one - easier then buying new one usually Apr 12 09:30:40 hrw: any ready pointers to convert an existing cable? Apr 12 09:31:22 take miniusb->usb cable, unbreak miniusb one, solder two pins, add usba->usba gender changer Apr 12 09:34:35 * amitk probably has enough mini->normal usb cables and gender changers. No time, though. :-/ Apr 12 09:36:37 I have more then enough usb connectors Apr 12 10:05:08 amitk, i only have a std adapter (several of them) but nothing with the shortened pins (as i told you on friday) Apr 12 10:07:55 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 Apr 12 10:08:21 * ogra doesnt understand why d-i just passed it even though it was uploaded hours later Apr 12 10:08:31 they had the same score Apr 12 10:10:35 any new arm notebooks? Apr 12 10:11:13 a rival for ipad? when? Apr 12 11:02:07 ipad? I would rather prefer rival for my dell d400 ;D Apr 12 11:02:42 grmbl Apr 12 11:03:00 so my NIC is seen by the netinst image but no firmware is loaded Apr 12 11:04:38 aha, asix works Apr 12 11:04:58 * ogra wonders why the other one doesnt Apr 12 11:09:05 hrw: ipad is the more successfull arm device in the market (according to news) Apr 12 11:09:19 hrw: in netbook context Apr 12 11:09:38 zumbi: show me arm netbooks on market (other then touchbook) Apr 12 11:11:28 amitk, hmm, it seems my installation attempts all break on usb-storage atm ... Apr 12 11:11:32 hrw: sharp netwalker, alwaysinnovating, efikamx, ipad, not sure if amazon wikireader counts as arm netbook Apr 12 11:11:55 so netwalker and efikamx only... Apr 12 11:12:25 alwaysinnovating is a beagleboard Apr 12 11:12:40 zumbi: I know what AI touchbook is Apr 12 11:13:00 beagleboard + usb hub + display + usb keyboard Apr 12 11:13:14 is it homemade? Apr 12 11:13:17 netwalker pc-z1 reminds me nightmares Apr 12 11:13:33 amitk, [ 212.130981] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000 shows up reliably when d-i is trying to detect disks Apr 12 11:13:46 zumbi: touchbook design is based on beagleboard design/schematics but it is whole new device not BB+cables Apr 12 11:14:48 zumbi: efikamx smartbook looks quite good but it is freescale... Apr 12 11:15:21 I have bad experience with both sharp (from zaurus times and 8MB kernel diffs) and with freescale (again 8MB kernel diffs) Apr 12 11:16:23 yes, i'd like to see imx51 in mainline with efikamx support Apr 12 11:17:23 zumbi: 2.6.50 probably Apr 12 11:17:56 is .50 guessed by a random function :) Apr 12 11:18:08 so far i.mx support looks like in-kernel maintainer has own version based on code drops from freescale Apr 12 11:18:44 yes, efika uses freescale SDK... :-/ Apr 12 11:18:47 zumbi: 2.6.50 ~= never (or 'when people forgot that such thing existed) Apr 12 11:19:29 Apr 12 11:18:47 main-menu[208]: INFO: Menu item 'partman-base' selected Apr 12 11:19:29 Apr 12 11:18:48 kernel: [ 556.388214] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000 Apr 12 11:19:29 Apr 12 11:18:48 main-menu[208]: (process:7234): Bus error Apr 12 11:19:33 amitk, ^^^^ Apr 12 11:24:19 hrw: /me is the maintainer of i.MX51 in mainline Apr 12 11:24:34 phone... Apr 12 11:25:01 ogra: ok, looking at it Apr 12 11:25:36 amitk, cjwatson suggests its misaligned memory access Apr 12 11:26:01 ogra: I am almost sure it has to do with clocks being turned off during module access Apr 12 11:28:27 amitk: Oh you are Apr 12 11:30:54 lool: huh? Apr 12 11:32:18 amitk: Re: /me is the maintainer of i.MX51 in mainline; I didn't know that Apr 12 11:32:21 amitk: congrats! Apr 12 11:32:58 lool, since ages :) Apr 12 11:33:05 I hadn't followed that change Apr 12 11:33:15 It's not in our lucid kernel tree at least, so can't be that old! Apr 12 11:33:34 4th February Apr 12 11:33:38 iirc it happened early lucid ... so .33 mainline Apr 12 11:34:03 or beginning of .34 Apr 12 11:34:11 .34 Apr 12 11:35:34 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) Apr 12 11:35:48 amitk, a test kernel for live would suffice Apr 12 11:36:28 ogra: Do you have any serial console enabled? Apr 12 11:36:36 lool, not by default Apr 12 11:36:44 you need to change boot.scr Apr 12 11:36:50 ogra: But did you turn them on? Apr 12 11:37:01 Sometimes it triggers this issue Apr 12 11:37:20 ogra: I'm looking.... can't tell you before I understand the problem Apr 12 11:37:35 lool, it also happens on the live image without serial turned on Apr 12 11:37:46 but i can try a d-i netinst one without right now Apr 12 11:38:02 * ogra fiddles with boot.scr Apr 12 11:38:06 I wonder whether partman would be attempting to touch the 3/4 possible SD cards which might not all be present on your card Apr 12 11:38:40 amitk: great! :) Apr 12 11:38:52 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 Apr 12 11:39:34 lool, already tried its /lib/partman/init.d/30parted but i cant get anything out of it with set -x Apr 12 11:39:55 Hmm who's working on the qcm kernel? Apr 12 11:40:13 lool, rtg afaik Apr 12 11:40:25 Is any image expected for it?! Apr 12 11:40:32 i dont think so Apr 12 11:40:37 I wonder how tested that kernel is Apr 12 11:40:49 Hi All Apr 12 11:41:01 GoodEvening Apr 12 11:41:17 lool: no image, minimal testing for qcm Apr 12 11:41:23 Anybody can Suggest me some nice Window manager for ubuntu ARM Apr 12 11:41:26 amitk: k thanks Apr 12 11:43:36 GRRR Apr 12 11:43:56 oh how i hate that you have to define omapfb crap on the console to get any video output *at all* Apr 12 11:44:00 siji: This is not really specific to ARM; depends of your use case Apr 12 11:45:09 lool, am looking for a handheld device Apr 12 11:45:11 ogra: Speaking of which, did we sync both omap xorg drivers from Debian recently? Apr 12 11:45:23 lool, a while ago Apr 12 11:45:25 siji: You could checkout matchbox Apr 12 11:45:32 I need some fancy Desktop Apr 12 11:45:37 ogra: The two of them? Apr 12 11:45:40 with smooth animations etc.. Apr 12 11:46:02 lool, NEON and non NEON version, yep Apr 12 11:46:12 sort of ubuntu-netbook launcher Apr 12 11:46:34 siji, use ubuntu-netbook then Apr 12 11:46:44 amitk: I did not knew Apr 12 11:46:45 and possibly replace the panel with something lighter Apr 12 11:47:05 siji, on armel it will default to use the efl version of the netbook launcher Apr 12 11:47:26 ogra, ok Apr 12 11:47:38 ogra: you can also ignore boot.scr, boot device to uboot and enter commands by hand/copypaste Apr 12 11:47:44 I could only find the xf86-video-omapfb source, what's the other one?? Apr 12 11:47:48 siji: how bug screen? Apr 12 11:47:56 siji: and how big resolution Apr 12 11:47:58 7'' Apr 12 11:48:06 LCD with touch screen Apr 12 11:48:08 800x480? Apr 12 11:48:11 yes Apr 12 11:48:33 I would use matchbox or something small/light Apr 12 11:48:35 hrw, i'm way to lazy for that :P Apr 12 11:48:48 * ogra <3 boot.scr Apr 12 11:48:50 fluxbox, icewm, xfwm4 maybe Apr 12 11:48:58 ok Apr 12 11:49:28 lool, its the same source, two binaries Apr 12 11:49:42 lool, one with and the other built without NEON Apr 12 11:49:46 Ok just making sure Apr 12 11:51:03 sigh Apr 12 11:51:30 * ogra tries since 10min to get some video output from the beagel .... just to find i used the wrong HDMI cable Apr 12 11:53:14 * hrw -> phone again Apr 12 12:01:45 hrm, my kbd doesnt work Apr 12 12:06:30 amitk, urgh ... Apr 12 12:06:42 amitk, seems DSS2 doesnt properly work yet Apr 12 12:07:02 i can switch consoles but the screen always shows tty1 Apr 12 13:02:27 dmart: hi Apr 12 13:02:38 hi there Apr 12 13:02:44 dmart: i think i need your input on xine-lib Apr 12 13:02:53 what's up? Apr 12 13:02:54 it uses jit like thing for mov pc, lr Apr 12 13:03:00 one second Apr 12 13:03:20 oh sorry Apr 12 13:03:24 its upx... something Apr 12 13:03:25 let me find it Apr 12 13:04:05 dmart: src/stub/src/i386-linux.elf-main.c: hatch[1]= 0xe1a0f00e; // mov pc,lr Apr 12 13:04:19 whats the hexcode for bx lr ;) Apr 12 13:04:20 hehe Apr 12 13:04:24 err Apr 12 13:04:27 you know what i mean Apr 12 13:04:39 i guess you should check that file Apr 12 13:04:49 hold on, I'll take a look Apr 12 13:04:53 dmart: thats apt-get source upx-ucl Apr 12 13:05:03 dmart: where can i find a hexcode reference? ;) Apr 12 13:05:25 i looked at some disassemblers. but not sure where they got that info from Apr 12 13:06:01 You can look at the ARM ARM, or write a tiny .s file, assemble and disassemble it Apr 12 13:06:27 ARM ARM? Apr 12 13:06:30 But if the instruction in question might run as Thumb, it's broken anyway so we should take a closer look Apr 12 13:06:31 yes. thats what i figured Apr 12 13:06:38 ARM Architecture Reference Manual Apr 12 13:06:39 but thought there must be a documentation that has that info ;) Apr 12 13:06:51 ah ;) Apr 12 13:07:23 http://infocenter.arm.com/ -> ARM Architecture (if you don't have it already) Apr 12 13:07:27 yeah Apr 12 13:07:52 ok needs password it seems. anyway Apr 12 13:08:43 oh yuck Apr 12 13:08:46 hmm. Apr 12 13:09:12 that code is making a hand-codedXXX hand-assembled syscall Apr 12 13:09:39 it assumes the legacy syscall ABI which won't work on new kernels Apr 12 13:10:12 ~armarm Apr 12 13:10:14 yeah Apr 12 13:10:20 dmart: i am not so sure that is actually used Apr 12 13:10:30 at least the buildlog doesnt show it being touched Apr 12 13:10:42 so i guess we might need to do nothing, or fix the .S .h files Apr 12 13:10:43 asac: You just need to register/login and then you can download it Apr 12 13:10:46 but those i already tried to kill Apr 12 13:11:46 argh, it also pokes the instructions into some "handy" space in the ELF header e_ident field Apr 12 13:12:46 lool: they do not send CDs anymore? Apr 12 13:13:56 yeah. upx-ucl seems to do crazy stuff Apr 12 13:14:15 let me spin it ... lets see if the stub things are shipped in some package Apr 12 13:15:21 UPX will typically reduce the file size of programs and DLLs by around 50%-70%, thus Apr 12 13:17:38 Probably safest to build this package in ARM for now Apr 12 13:18:46 ...it's a plie of low-level hacks Apr 12 13:19:59 hrw: Never heard of that, did they? Apr 12 13:20:48 I have cd with arm documentation somewhere Apr 12 13:21:18 and got it from arm ltd Apr 12 13:23:26 dmart: ok will go for -marm then Apr 12 13:23:43 asac: I've got three concerns with upx-ucl: 1) I can't see where the decompressed program is entered. Can it handle an entry point in thumb? 2) Are caches flushed properly when entering the decompressed executable? 3) The hand-assembled code in i386 appears wrong in 3 ways - no cache flush, not thumb-aware and not compatible with EABI. Unfortunately, -marm will fix none of these Apr 12 13:24:36 ARM code in i386-* really confuses me too :P Apr 12 13:25:57 Do you know the maintainers for this? Maybe they could help us to understand how it works. Apr 12 13:26:29 dmart: yes. Apr 12 13:26:40 Robert Luberda Apr 12 13:26:40 ;) Apr 12 13:27:31 Would he be on IRC somewhere? Apr 12 13:29:36 dmart: sent a mail with you CCed Apr 12 13:29:45 let me see if i can find his nick Apr 12 13:30:50 lool, the CD shipped with the EVM did have all ARM docs iirc Apr 12 13:31:21 dmart: unfortunately he doesnt have his nick in db.debian.org ... one sec Apr 12 13:31:54 ok seems in debian-devel they dont know his nick either Apr 12 13:32:01 so lets wait for him to appear or answer the mail Apr 12 13:33:16 OK... I think the conclusion for now is that there's lots of assembler which was written for pre-Thumb days -> many assumptions, so we must build with -marm. Apr 12 13:33:47 Hi guys. Is there any reason that NFS works poorly? Apr 12 13:33:48 dmart: i can upload that for now Apr 12 13:33:51 But there may still be issues with the syscall ABI, cache flushing and compressing executables with a Thumb entry point (which would be the common case in lucid_ Apr 12 13:34:05 dmart: but as you said. we dont really think this will fix all Apr 12 13:34:16 I was told that you considered NFS in the build farm, but ditched it. I curious to why Apr 12 13:34:20 dmart: right. but this cache flushing etc. is not a regression, right? Apr 12 13:34:22 We need -marm anyway, so may as well do that and try it out. Apr 12 13:34:25 e.g. its aproblem across the board? Apr 12 13:34:32 dmart: ok uploading that for now Apr 12 13:34:44 hmm i get Apr 12 13:34:44 dpkg-shlibdeps: warning: debian/upx-ucl/usr/bin/upx-ucl contains an unresolvable reference to symbol __aeabi_unwind_cpp_pr1@GCC_3.5: it's probably a plugin. Apr 12 13:36:05 The cache flushing might be there, but I don't understand all the code yet. You often get away without the cache flushing when the caches are small, but you may hit problems on newer platforms. For ages, the linux kernel didn't invalidate the I-cache when loading executable pages... Apr 12 13:36:55 ok uploaded with -marm now Apr 12 13:37:56 ok Apr 12 14:18:18 ubuntu-netbook dependencies are broken again, right? Apr 12 14:26:03 ogra: Something you needed me to test? Apr 12 14:27:13 GrueMaster, i'm only doing beagle stuff atm Apr 12 14:27:22 do you have a beagle now ? Apr 12 14:27:33 You said something about dove earlier. Apr 12 14:28:27 oh, someone asked about dove ... Apr 12 14:28:36 (01:29:44 AM) lool: ogra: You might want to test the dove netboot initrd too; I'm pretty sure you need to pass root=/dev/ram0 there too Apr 12 14:28:36 (01:30:07 AM) ogra: lool, i have no HW to test dove Apr 12 14:28:36 (01:30:12 AM) ogra: only NCommander does Apr 12 14:28:36 (01:30:16 AM) ogra: and GrueMaster Apr 12 14:29:04 GrueMaster, right, there you have the issue Apr 12 14:30:10 If this is referring to dove netboot images not booting, this is not the fix. Whatever creates the netboot image for dove needs to change the entry point and address for the kernel wrapper. Apr 12 14:30:14 for uboot. Apr 12 14:31:01 GrueMaster, its referring to the way the dove images are built (not using initramfs but ext2 initrd) Apr 12 14:31:25 What is a decent seed for something like ubuntu-netbook? I want to test X and desktop and such. Apr 12 14:31:41 well, ubuntu-netbook :) Apr 12 14:32:08 ogra, but I get unmet dependencies unfortunately Apr 12 14:32:31 it worked tonight when i built images Apr 12 14:32:38 should only be tempoarary Apr 12 14:32:57 nosse1: gtk is going through a respin. It may be a few days for the churn to settle. Apr 12 14:33:07 GrueMaster, again ? Apr 12 14:33:17 it was done on saturday Apr 12 14:34:02 nah, it should all be fine Apr 12 14:34:05 Yea, someone checked in a bug fix on 4/8, which had a cascade effect. x86 is done rebuilding everything, but it took us 10 days to get through it last time. Apr 12 14:34:21 nosse1, wha are the actual probs you see (error message) Apr 12 14:34:52 In the danger of flood filling: Apr 12 14:35:01 ubuntu-netbook: Depends: gnome-applets but it is not going to be installed Apr 12 14:35:03 Depends: gnome-control-center but it is not going to be installed Apr 12 14:35:05 Depends: gnome-panel but it is not going to be installed Apr 12 14:35:07 Depends: gnome-session but it is not going to be installed Apr 12 14:35:08 ah Apr 12 14:35:08 Depends: indicator-applet-session but it is not going to be installed Apr 12 14:35:10 Depends: update-notifier but it is not going to be installed Apr 12 14:35:11 Recommends: hplip but it is not going to be installed Apr 12 14:35:14 g-c-c was uploaded today Apr 12 14:35:15 So yeah, gtk it is Apr 12 14:35:21 no, gtk is fine Apr 12 14:35:46 its gnome-control-center ... the others mostly depend on it directly or indirectly Apr 12 14:35:46 hmm. I'll try an update Apr 12 14:36:02 https://edge.launchpad.net/builders Apr 12 14:36:16 the builders are nearly all busy with multi day packages Apr 12 14:36:24 Havent been deployed yet it seems Apr 12 14:36:30 g-c-c likely still sits in the queue Apr 12 14:36:43 ogra: when gtk gets rebuilt, everything that depends on it gets rebuilt. That's where the cascade effect comes in. Apr 12 14:36:57 GrueMaster, yes, i know Apr 12 14:37:08 https://edge.launchpad.net/ubuntu/+source/gnome-control-center/1:2.30.0-0ubuntu4/+build/1687347 Apr 12 14:37:14 nosse1, thats your issue ^^^ Apr 12 14:37:31 GrueMaster, but that was done on saturday Apr 12 14:37:43 6 minutes ago. heh. Apr 12 14:38:08 GrueMaster, if someone takes actively care for gtk its less than a day to get it sorted ... i only got around to look at it on friday Apr 12 14:38:48 I was just referring to the last time this happened (3/23). Apr 12 14:38:54 nosse1, yeah, that will build for a while and then take 1-1.5h to be published ... if something of the other packages has a versioned dependency that needs to rebuild as well Apr 12 14:39:00 Of course, I'm not following all the change logs. Apr 12 14:39:11 GrueMaster, i usually do :) Apr 12 14:39:20 if i'm not in Nice :) Apr 12 14:39:45 On a more general note: Is there any reason for NFS misbehaving on the omap? Apr 12 14:39:57 misbehaving ? Apr 12 14:40:00 in what way ? Apr 12 14:40:18 * ogra didnt try NFS on omap at all yet Apr 12 14:40:24 Kernel oops all the time (when doing heavy fs activity) Apr 12 14:40:34 nosse1, file a bug Apr 12 14:40:47 nosse1, which kernel build is that? the latest one ? Apr 12 14:40:56 Someone told be that you considered using NFS for the buildfarm, but rejected it Apr 12 14:41:14 yes, its way slower than USB or SATA Apr 12 14:41:22 but has nothing to do with OMAP Apr 12 14:41:32 we dont have any omap buildds yet Apr 12 14:41:48 No I'm on a custom kernel, so I'm not trying to request support for it Apr 12 14:41:56 oh, ok Apr 12 14:42:02 i tought you used the ubuntu kernel Apr 12 14:42:06 The ti-omap does not work for the AM3517 as I've mentioned before Apr 12 14:42:25 ah, right, i remember Apr 12 14:45:01 ogra, so you are not building armel on any beagleboards then? Apr 12 14:46:10 not yet, our buildds require a lot of RAM ... Apr 12 14:46:32 256M simply doesnt cut it 512 is a minimal req. Apr 12 14:47:11 also our IS team wants to use supported ubuntu setups Apr 12 14:47:25 we didnt have omap support in ubuntu until shortly ago Apr 12 14:48:24 for maverick and with bigger beagles you will likely see some beagle based buildds appear Apr 12 14:48:38 or s/beagle/omap/ Apr 12 14:49:25 BTW: Can I force aptitude or apt-get to start pulling down the packages for ubuntu-netbook even with the broken dependecies. I.e. "downl. and install what you've can get" Apr 12 14:49:50 not easily ... just wait Apr 12 14:49:58 :D Apr 12 14:50:34 how much ram does your board have though Apr 12 14:50:57 below 512M ubuntu-netbook will definately be a pain Apr 12 14:51:28 the evm has 256M, but the final HW will have 512 Apr 12 14:52:11 well, add a lot of swap until you get more ram then ;) Apr 12 14:52:16 and dont expect speed Apr 12 14:53:18 we won't be running ubuntu-netbook anyway. It was just for playing around more than anything else. Apr 12 14:53:52 well, with 512M the efl version will run quite smooth Apr 12 15:01:57 ogra: did you check with lamont Apr 12 15:02:00 on builders? Apr 12 15:02:10 on what exactly ? Apr 12 15:03:20 ogra: that builders are lagging Apr 12 15:03:37 they are not lagging ... they are busy with huge packages Apr 12 15:03:44 ramzswap might be useful Apr 12 15:04:07 buttercup is done with kdeedu now so we have one back that builds "normal" packages Apr 12 15:04:25 cwillu_at_work, thats why we use it on live images since hardy :) Apr 12 15:04:39 oh really? Apr 12 15:04:40 didn't know that Apr 12 15:04:51 yep Apr 12 15:05:01 to make them work on 256M systems Apr 12 15:05:18 its a good way to prevent OOM Apr 12 15:06:08 i'm not sure it would trust it enough to use it on a constantly heavily loaded buildd though ... Apr 12 15:06:23 but we have 512M buildds so thats no issue anyway Apr 12 15:07:17 my arm builds are on a qemu with a gig of swap that's backed by a ramfs on the host Apr 12 15:07:21 helps Apr 12 15:08:28 well, our arm buildds are babbage boards with 800MHz, 512M and two gig of swap on disk Apr 12 15:08:41 memory backed swap would be faster :p Apr 12 15:08:56 er, nvm Apr 12 15:09:01 probably not faster than native Apr 12 15:09:15 yeah, but not sure how stable that stays if you really put heavy load on it Apr 12 15:09:27 like an OO.o build for example Apr 12 15:09:57 which, the ramfs swap? Apr 12 15:10:03 I just built firefox on it Apr 12 15:10:10 ramzswap (or compcache as its still called in ubuntu) is a slightly hackish way of replaying R/W to a virtual swap file Apr 12 15:10:48 not sure how the speed impact is if you constantly drive it under full system load Apr 12 15:11:06 its great as a safety net to avoid OOM ... Apr 12 15:11:19 but on loaded systems ... Apr 12 15:11:37 Is ramzswap dynamically sized Apr 12 15:11:39 ? Apr 12 15:11:42 nope Apr 12 15:11:52 at least not in the versio we currently have in ubuntu Apr 12 15:12:01 you have to define a value at module load time Apr 12 15:12:15 not sure how much it changed when it went into staging though Apr 12 15:12:18 I was just wondering how much extra space you tend to get, and what the performance impact is Apr 12 15:12:26 i know it is said to have changed a lot Apr 12 15:12:56 the performance penalty on a live image isnt really heavy ... Apr 12 15:13:17 but on live images you dont drive the system unbder full load all the time Apr 12 15:13:40 the compression/decompression will surely do some harm if your CPU is busy anyway Apr 12 15:13:59 It tends to roughly double the space allocated: so if one allocates 128M, one ends up with ~256M of swap (of course, this depends on swap contents, etc.) Apr 12 15:14:01 well, depends on the working set Apr 12 15:14:16 indeed Apr 12 15:14:32 if you're cpu bound, but the working set is small'ish, it could be an easy win Apr 12 15:14:33 Doesn't sounds like enough to avoid OOM on large package builds, but I can see it's useful for things like the live images. Apr 12 15:15:07 Can help with some classes of large package builds (for limited values of large). It's not really enough for e.g. boost. Apr 12 15:15:53 it might be a tad faster than using USB disk based swap though Apr 12 15:16:07 depending on your CPU load indeed Apr 12 15:17:19 cwillu_at_work, our beagle live image will use 128M of compcache on the Cx series beagles btw Apr 12 15:18:19 runs relatively smooth (if you think about the fact that nearly a full gnome desktop runs in the backend on top of an aufs'ed sqashfs image) Apr 12 15:29:24 ogra: does rootstock still get stuck on I: Extracting zlib1g.. Apr 12 15:29:25 ? Apr 12 15:29:37 * amitk forgets what the issue was.. Apr 12 15:35:54 amitk: The issue is that when unpacking large numbers of large packages in qemu, the emulated system hangs. Apr 12 15:36:59 persia: do you know if it still exists? Apr 12 15:38:14 I don't. I can start a rootstock run to see if you have issues doing it locally. Apr 12 15:38:45 I've tripped over that recently Apr 12 15:43:18 Why do you need to specify "BOOT=" in /etc/initramfs-tools/initramfs.conf. I'm sitting here swapping boots between NFS and local and would rather like to have it as an boot option... Apr 12 15:43:37 * nosse1 remebers that he can make two initrds... Apr 12 16:09:56 amitk, the zlib issue only exists with debian systems afaik, i have a fix i havent merged yet Apr 12 16:10:33 amitk, the issue persia mentioned still exists, install ubuntu-minimal and if you want a desktop system, do the rest on the real HW Apr 12 16:12:02 ogra, any idea what the root issue is re: hang on qemu? Apr 12 16:12:21 cwillu_at_work, if i would have any clue i would have fixed it :) Apr 12 16:12:26 :p Apr 12 16:12:37 its there since end of last year Apr 12 16:12:43 just on lucid though? Apr 12 16:12:47 yes Apr 12 16:12:56 just with a lucid target system actually Apr 12 16:13:00 any traces which you would like? Apr 12 16:13:09 doesnt show up if you build karmic or jaunty Apr 12 16:13:16 yep Apr 12 16:13:24 cwillu_at_work: Whichever one demonstrates the issue :) Apr 12 16:13:43 Bug 532733 Apr 12 16:13:45 Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 1 other project) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 3) (dups: 1) (heat: 26)" [High,Incomplete] https://launchpad.net/bugs/532733 Apr 12 16:13:47 cwillu_at_work, ^^^ Apr 12 16:14:01 strace of qemu may give some pointer, but I suspect that's not sufficient, as I expect it's internal to qemu, rather than being external. Apr 12 16:14:34 yes Apr 12 16:14:35 bug won't be in kvm Apr 12 16:15:01 thats just the name of the ubuntu qemu package Apr 12 16:15:23 since we use a different upstream to debian our package is called qemu-kvm Apr 12 16:15:30 ah, k Apr 12 16:16:06 i traced it down to apt hanging in a read() call but didnt get any further Apr 12 16:16:45 the lucid vm kernel? Apr 12 16:16:47 i assume the read() is a pipe to dpkg here ... but likely its neither apt's nor dpkg's fault but rather qemu or kernel Apr 12 16:16:50 yep Apr 12 16:17:35 its easy to reproduce if you follow the rootfs from scratch wikipage, build a minimal qemu image and then install ubuntu-netbook inside Apr 12 16:18:00 I've got a hacked up rootstock that demonstrates it whenever I switch it to lucid mode :p Apr 12 16:18:04 the fun stuff is that the issue goes away if you install the apt and dpkg dbgsym packages Apr 12 16:18:10 gonna try running it with karmic's kernel Apr 12 16:18:33 i tried different kernels and qemu binaries Apr 12 16:19:25 i also tried all variations of qemu images, filesystems and ways to connect to the image (even qemu-nbd which is very unstable) Apr 12 16:19:56 the only hint i got was the dbgsym packages that make the issue go away .... Apr 12 16:20:06 which doesnt help with debugging indeed :P Apr 12 16:21:46 well, I'm building it with karmic's kernel anyway :p Apr 12 16:28:15 anyway, its my turn with cooking today ... and i cant work on images anyway so i'm off Apr 12 16:28:39 * ogra vanishes to the kitchen Apr 12 16:41:59 GrueMaster: Just FYI, the load address of netboot images for dove hsa been fixed recently Apr 12 16:42:18 with version 20081029ubuntu96 of debian-installer Apr 12 16:42:23 From Friday Apr 12 16:42:37 I know. Have new images been spun with this? Apr 12 16:42:55 GrueMaster: they are spun at package build time Apr 12 16:43:14 GrueMaster: You can see the version of d-i used to build an image in the archive Apr 12 16:43:42 GrueMaster: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/ Apr 12 16:44:13 * cwillu_at_work fails at using qemu on root images which are concurrently loop-mounted on the host system Apr 12 16:44:33 cwillu_at_work: Don't do that Apr 12 16:44:41 cwillu_at_work: Can't work well Apr 12 16:44:42 lool, you think? Apr 12 16:44:43 I'll download and test them today. Thanks. Apr 12 16:44:54 lool, it's hilarious when the vm tries to fsck it Apr 12 16:45:16 Eh with some definition of hilarious "eats all your data" :) Apr 12 16:47:10 only data on it is an unpacked firefox source tree :p Apr 12 17:31:58 lool: What is the proper cmdline for booting the dove netboot image? I am currently booting with "quiet splash". Tried adding root=/dev/ram0, but that didn't work either. Apr 12 17:33:17 With imx51, the cmdline is "console=ttymxc0,115200 console=tty0", and it just works. Apr 12 18:03:59 GrueMaster: I'm afraid I have no idea; perhaps NCommander can help you Apr 12 18:04:09 GrueMaster: I would check the boot.script file from an installed system Apr 12 18:05:25 ok. The boot script from an installed system doesn't load the installer. And the live image is different from the netboot image. Guess I can check an alternate image from days back (we stopped building them). Apr 12 18:08:13 GrueMaster: I mean, just copy the arguments from the boot script Apr 12 18:08:34 Finding the right boot script is the key. Apr 12 18:08:58 The boot script from an installed system has root=UUID= Apr 12 18:09:19 And this is supposed to be for network booting and installing. Apr 12 18:10:04 The imx51 image of the same flavor (which works btw) only has console redirection on it, and would work without it. Apr 12 18:12:29 GrueMaster: So in theory it should be the same for dove Apr 12 18:12:46 GrueMaster: i.e. copy over the boot args from an installed system, but without root= or with root=/dev/ram0 Apr 12 18:12:47 Theory != reality in this case. Apr 12 18:12:52 If it doesn't work it's likely a bug Apr 12 18:13:06 GrueMaster: How far do you actually get? Apr 12 18:13:07 I tried that. That's why I asked if there was something I was missing. Apr 12 18:13:35 GrueMaster: Does it load kernel and initrd? Apr 12 18:14:05 kernel panic. Either no rootfs with "quiet splash" or no init with "quiet splash root=/dev/ram0" Apr 12 18:14:17 Yes, it now loads the kernel. Apr 12 18:14:30 Need to get beyond that. Apr 12 18:15:01 GrueMaster: So forget quiet and splash, root=/dev/ram0 says "no init"? Apr 12 18:15:04 GrueMaster: try init=/bin/sh Apr 12 18:15:05 And these kernel panic messages are appearing on the monitor, which indicates that the kernel is successfully initializing the system. Apr 12 18:15:16 Ok. Apr 12 18:20:31 fail. No init found. Apr 12 18:21:22 In theory, the initrd should be nearly identical to imx51. The only differences should be in modules. Apr 12 18:24:36 GrueMaster: ok, I unpacked the initrd and found /bin/sh in it. so it might be a problem with the initrd address or the uInitrd buikd Apr 12 18:24:41 GrueMaster: do you have a full dmesg? Apr 12 18:25:30 I have is a console log, if that is what you are referring to. Apr 12 18:26:43 http://pastebin.ubuntu.com/413250/ Apr 12 18:27:18 That's the relevant info (before that is device initilization output, and I didn't see any errors there). Apr 12 18:27:42 GrueMaster: ah [ 3.558370] RAMDISK: incomplete write (13368 != 32768) Apr 12 18:27:54 Yep. Saw that. Apr 12 18:27:56 GrueMaster: Could you try passing ramdisk_size=65536? Apr 12 18:28:08 Ok, one sec. Apr 12 18:28:21 odd I thought that was the case for dove hmm Apr 12 18:29:00 GrueMaster: so root=/dev/ram0 ramdisk_size=65536, and console= if you like Apr 12 18:29:31 Working on it. Apr 12 18:30:39 Bah it's definitely the problem Apr 12 18:30:41 CONFIG_BLK_DEV_RAM_SIZE=4096 tss Apr 12 18:31:06 Erm, fail. Apr 12 18:31:06 Bad fail. Apr 12 18:31:15 GrueMaster: what's the error? Apr 12 18:32:09 http://pastebin.ubuntu.com/413254/ Apr 12 18:32:51 GrueMaster: Odd; could you try with 16384 instead? Apr 12 18:33:09 ok Apr 12 18:33:22 * lool is off for the day Apr 12 18:33:48 GrueMaster: In any case, please file a bug against the kernel with our chat; I'm pretty sure the current value of 4096 can't work, but we need to find a good value and/or see which places need an update Apr 12 18:36:00 Same error with 16384 Apr 12 18:36:33 Is this a kernel bug or is it a corrupt initrd? The kernel "should" be the same as the live/installed kernel. Apr 12 18:38:08 I tried loop mounting the initrd from http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/20081029ubuntu97/images/dove/cdrom/ and it fails to mount on my desktop. Apr 12 21:58:11 does someone know available arm cortex a9 boards? Or when they will be available? Apr 12 21:59:32 videorechner: the tegra is available now but you have to register and be approved for your specific project, which they keep pretty tight Apr 12 21:59:50 videorechner: there are other platforms like the blaze from TI as well Apr 12 22:00:12 videorechner: but that too is somewhat restricted at this stage due to supply and demand Apr 12 22:00:14 mhm, any guesses, when it will be available for end users? Apr 12 22:01:20 videorechner: all the market hyped seems to indicate that there will be more available in the first quarter of next year Apr 12 22:01:58 the blaze or cortex a9 motherboards? Apr 12 22:02:31 videorechner: correct Apr 12 22:05:34 ?? **** ENDING LOGGING AT Tue Apr 13 02:59:56 2010