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