| === cyphermox is now known as cyphermox_ | ||
| === cyphermox_ is now known as cyphermox | ||
| diwic | apw, ping | 06:41 |
|---|---|---|
| === LetoTheII is now known as LetoThe2nd | ||
| * apw yawns | 07:36 | |
| apw | diwic, hi | 07:36 |
| diwic | apw, you're the maintainer of checkpatch, aren't you? | 07:55 |
| diwic | or at least a frequent contributor | 07:55 |
| apw | diwic, indeed | 07:55 |
| diwic | apw, I'm getting what I think is a false positive | 07:55 |
| apw | diwic, you won't be the first :) | 07:56 |
| diwic | apw, could I send the patch to you to double check that I'm not completely stupid? | 07:56 |
| apw | of course | 07:56 |
| diwic | apw, sent | 07:57 |
| brendand | cking - hi | 08:24 |
| cking | brendand, hiya | 08:24 |
| brendand | cking, i just have a new data point for you in the fwts/suspend saga. you know the device-check can be foiled by xinput reordering the list of devices? | 08:25 |
| brendand | cking, everything's still there, but swapped around | 08:25 |
| brendand | to illustrate : http://paste.ubuntu.com/1062206/ | 08:26 |
| cking | brendand, nope, I didn't know that, I'll filed a bug and get that sorted out | 08:26 |
| cking | brendand, I suggest not using the --s3-device-check flag until the fix lands in V0.25.05 | 08:33 |
| brendand | cking - thanks for looking at it | 08:38 |
| cking | I'm working on a fix right now | 08:38 |
| cking | thanks for identifying this issue - looks like it's not been exercised much | 08:39 |
| brendand | cking, thanks for looking at it. one of the advantages of having such a wide variety of hardware at our disposal is that we have the 'privilege' of finding out about all the quirks | 09:08 |
| cking | yep, I've only tested it on ~5-10 machines here | 09:08 |
| apw | xinput reordering its inputs through suspend, fun ... i bet its usb things which move | 09:09 |
| cking | I overlooked this - doh | 09:09 |
| brendand | cking, to be honest, there's so much stuff going on that you can overlook that it's not worth worrying about | 09:10 |
| brendand | just have to take them as they come | 09:10 |
| cking | yep, thanks for spotting this, I've got a fix written now, just testing it.. | 09:11 |
| brendand | cking, what i don't understand is that the id stays the same, so why doesn't xinput just id order? | 09:14 |
| cking | because it likes to make our lives difficult? | 09:14 |
| brendand | cking, that's the correct answer! you win a prize | 09:14 |
| dhana013 | Hi Guys, I have doubt in 32 bit linux kernel and 64 bit linux kernel | 09:23 |
| dhana013 | my machine already working with 32 bit kernel. I have 64 bit kernel , I change my kernel as 64. | 09:23 |
| dhana013 | bit, it's possible do this. I can do install 64 bit packages | 09:24 |
| dhana013 | please guide me guys | 09:40 |
| apw | you can in theory install a 64 bit kernel on an i386 userspace if it has 64bit support in the CPU | 09:41 |
| apw | depending how much ram you have its not always a good idea though | 09:41 |
| apw | cking, does the 'you may wish to read the release notes' link for work you on the installer?n | 09:42 |
| cooloney | apw: hey, andy, i'm going to start to do config review for common ARM drivers | 09:53 |
| apw | cooloney, ok sounds "fun" | 09:54 |
| cooloney | apw: so a silly questions, actually what's common ARM drivers config or where is it? | 09:54 |
| cooloney | apw: is it the common config file for armel and armhf? | 09:54 |
| apw | heh ... thats a question, finding out whats 'h/w' specific options is pretty hard | 09:55 |
| apw | i have never approached commonising config from that side just for that reason | 09:55 |
| cooloney | apw: hah, i just start and found it's hard to find them indeed | 09:56 |
| cooloney | apw: but i saw your email several weeks about ARM config. | 09:56 |
| apw | well i was fighting arm configs which differed in non-arm things, things like filesystems, right ? | 09:57 |
| ppisati | cooloney: you'll find a lot of arm (and even omap-only) related crap even in config.common.ubuntu | 09:58 |
| dhana013 | apw, I have i5 processor in my machine how to configure custom kernel please guide | 09:59 |
| cooloney | ppisati: oh that's bad | 09:59 |
| cooloney | apw: i remember some USB host configs were mentioned in your email | 09:59 |
| dhana013 | how to utilize the hole hardware to my linux kernel | 10:00 |
| ppisati | cooloney: yes it is, unfortunately | 10:01 |
| ppisati | cooloney: it would be nice if we could push all the hw-agnostic stuff in config.common | 10:01 |
| ppisati | cooloney: and leave arm details in config/<arch>/config.* | 10:02 |
| ppisati | cooloney: but i think it's a lot of work, and a lot of shuffling stuff around | 10:02 |
| ogra_ | but it will make the future so much easier :) | 10:02 |
| ppisati | yes, but whenever i moved any option out of that file, it reappeared in all the arch specific config file after an updateconfigs | 10:03 |
| cooloney | i didn't imagine the work is so hard before | 10:04 |
| ppisati | i think the logic is someghing like "can i have that option? good, then i put it in config.common" | 10:04 |
| ppisati | "is that option any different in any ach specific config file? cool, then i remove it from config.common and push it one level down" | 10:05 |
| ppisati | i think the real problem is *why* arm and omap specific options are not binded to any CONFIG_ARCH_ARM or stuff like that | 10:05 |
| ppisati | in that case they won't appear in config.common i guess | 10:05 |
| ppisati | so the proper fix is to make an arch specific option depends on another arch specific option that only appear in an arch specific config file (this way updateconfigs won't push it inb the config.comm file) | 10:06 |
| ppisati | i hope i got it right... | 10:06 |
| ppisati | somehow... | 10:06 |
| cooloney | ppisati: oh wait, looks like this is an updateconfigs script issue | 10:07 |
| ppisati | cooloney: no no | 10:07 |
| ppisati | cooloney: wait, let me show you an example | 10:07 |
| cooloney | ppisati: yeah | 10:07 |
| ppisati | cooloney: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=blob;f=debian.master/config/config.common.ubuntu;h=40c77e1f9a2a8f7c8ac49edb19ac55cecdc19e82;hb=HEAD | 10:10 |
| ppisati | cooloney: take for example an omap option | 10:10 |
| ppisati | cooloney: like... | 10:10 |
| ppisati | cooloney: CRYPTO_DEV_OMAP_AES | 10:10 |
| ppisati | cooloney: it shouldn't be here | 10:10 |
| ppisati | since it's arm (and even omap in this case) specific | 10:11 |
| cooloney | ppisati: yeah | 10:11 |
| ppisati | so it should go in config/arm[hf|el]/config.flavour.omap | 10:11 |
| ppisati | now, if you move it here, ALL the other other configs file will get this option replicated | 10:11 |
| ppisati | let me try... | 10:12 |
| apw | cooloney, ppisati, the config optimiser takes no account of which arch something ocmes from as it does not really know | 10:12 |
| cooloney | ppisati: I know what you mean here now. | 10:12 |
| cooloney | i found 11 OMAP config in common.ubuntu config | 10:12 |
| apw | and its dangersous to try anyhow because armhf and armel are 'separate' configuration options | 10:12 |
| apw | s/options/arches | 10:13 |
| apw | but they need to be mostly common | 10:13 |
| apw | cooloney, any specific option being in common.ubuntu just means it has a common setting in all configurations for which it is present | 10:13 |
| apw | where something is in the config hierachy isn't important really, whats important is when its set it is set appropriatly | 10:13 |
| apw | which is where the configuration checker comes in | 10:14 |
| apw | https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha2 | 10:14 |
| apw | which is what we use to review and fix options normally | 10:14 |
| apw | CONFIG_CRYPTO_DEV_OMAP_AES if you look at that one for instance, it is m on omap and - on everything else, so that is ok and we don't care where it goes in the hierachy | 10:16 |
| cooloney | apw: right, so if an option is the same for all arches, it goes into top common config | 10:17 |
| apw | yes it will roll up to th | 10:17 |
| apw | to the top | 10:17 |
| cooloney | apw: and if is the same for all the armhf arch, it goes into common.armhf.config. | 10:18 |
| apw | if tis the same for all armhf configs but not for other arches, then yes its in common.armhf only | 10:18 |
| cooloney | ppisati: so as apw said, some OMAP configs in common.ubuntu.config show up because they are the same for all the arch configs | 10:18 |
| apw | right and that is expected, its a side effect of the algorithm | 10:19 |
| cooloney | apw: yeah, exactly | 10:19 |
| apw | to be honest its utilitity, the commonisation is less important now we have a proper config comparitor | 10:19 |
| apw | as the human can look at the rows in the wiki much better than understanding where in the config hierachy an option ended up | 10:19 |
| ppisati | what i wanted to say is that, it would be nice to have options separated by their usage: common non-arch specific options go in config.common, armhf specific go in armhf/config.common.armhf, omap-only options go in armhf/config.flavour.omap, ectect | 10:21 |
| ppisati | this way adding a new flavour equals adding a new config leaf | 10:21 |
| ppisati | file | 10:21 |
| apw | ppisati, that would be nice, but thats not quite how it works | 10:21 |
| ppisati | e.g. armhf/config.flavour.highbank | 10:21 |
| ppisati | apw: yes | 10:22 |
| apw | ppisati, generally to add a new flavour you can just dump a full config down in that file | 10:22 |
| apw | and fdr updateconfigs will clear out the common stuff and make a mess of the configs of course | 10:22 |
| cking | apw, re: installer, not yet got around to that, will be testing in 20 mins | 10:22 |
| ppisati | apw: i think i did during the omap4 review (and last omap3 config bisection) | 10:22 |
| ppisati | apw: and updateconfigs badly messed up the config | 10:23 |
| ppisati | anyway | 10:23 |
| ppisati | cooloney: in any way, have fun! :) | 10:23 |
| apw | ppisati, well yes if your config is differnt it has to change the balance to maintain your config | 10:23 |
| ppisati | cooloney: sun is shining, it's summer time, and all that solar crap... :) | 10:23 |
| apw | ppisati, it doesn't override any of the configs, which is what you want | 10:23 |
| ppisati | apw: i don't know, maybe i had a dream/nightmare | 10:24 |
| ppisati | apw: but during the... | 10:24 |
| apw | i have a bunch of overrides documented now though for next time, which i did to fix highbank up | 10:24 |
| ppisati | apw: 3.5 rebase, to me it looks like omap3 "imported" some options that weren't there before | 10:24 |
| apw | as from an ubuntu commonisation point of view its the non-arch crap i want right, the h/w stuff should be board specific | 10:24 |
| apw | ppisati, well if you took the non-3.5 config and used that yes, you should really have put the config a 3.5 tree and did make oldconfig on it first | 10:25 |
| apw | to get asked about the new things | 10:25 |
| apw | then used that one in the ubuntu tree | 10:25 |
| ppisati | IMVHO we could drop updateconfigs, and mantain config.common manually | 10:26 |
| ppisati | apw: could be, don't rememebr when i had that impression | 10:26 |
| ppisati | (but i know it won't happen) | 10:26 |
| apw | ppisati, the utility of updateconfigs for changing configs is less than it was | 10:27 |
| apw | now we also have OVERRIDES to inject changes across the board | 10:27 |
| apw | getting from where we are to where you suggest is very hard, but it would be a better place | 10:27 |
| ppisati | i know, a lot of shuffling around | 10:28 |
| ppisati | and you can't do that in one pass | 10:28 |
| ppisati | it's an iterative process | 10:28 |
| apw | ppisati, the biggest issue is there is hierachy we cannot express currently like | 10:28 |
| apw | ubuntu -> arm -> armel/armhf | 10:28 |
| ppisati | right | 10:28 |
| apw | and till we can do that its tricky, and the layout of the configs is tied to other layouts currently | 10:29 |
| ppisati | well, truth be told that's becasue we use ABIs instead of arch | 10:29 |
| ppisati | are we going to support... | 10:29 |
| apw | so its not easy. but i will think on it as what you want makes a lot of sense, its what we all want | 10:29 |
| ppisati | the 32/64 bit hybrid | 10:29 |
| ppisati | what was the name... | 10:30 |
| cooloney | apw and ppisati, i think basically i can start that from the URL for kernel config review. | 10:30 |
| ppisati | n32 | 10:30 |
| apw | "ubuntu needs X" "x86 needs Y" "x86/server needs Z" | 10:30 |
| apw | cooloney, yep anything you find out of sync _either_ needs making in sync, or you need to let me know so i can annotate it as correct | 10:30 |
| apw | for example arm needs vfat builtin and thats right, so it has an annotation | 10:31 |
| ppisati | no, it's not n32... | 10:31 |
| cooloney | apw: sure, i will and try to change the status of this task from TODO to IN PROGRESS | 10:31 |
| ppisati | x32! | 10:31 |
| cooloney | apw: and can never mark that as DONE. heh | 10:31 |
| apw | cooloney, which task? | 10:31 |
| cooloney | apw: review common drivers for ARM | 10:32 |
| ppisati | http://en.wikipedia.org/wiki/X32_ABI | 10:32 |
| ppisati | this one would use 64bit regs in a 32b address space | 10:32 |
| apw | cooloney, sounds good, and even a rough pass is better than nothing | 10:32 |
| ppisati | i don't think we are going to support it | 10:33 |
| apw | ppisati, yep its probabally what amd64 should have been | 10:33 |
| ppisati | but in case we do, we will find ourself in the same situation with armhf/armel | 10:33 |
| ppisati | with x32 and i386 | 10:33 |
| cooloney | apw: np, | 10:33 |
| apw | ppisati, indeed, well we already are, as i386/amd64 already has this commonality | 10:33 |
| * apw will play with that before sprint | 10:34 | |
| cooloney | ppisati: so the first one, why CONFIG_MSDOS_FS should be =y instead of =m for omap4? | 10:34 |
| apw | cooloney, we have vfat_fs set for the other arm ones but not msdos_fs, but only someone with the h/w would know if that is needed or not | 10:36 |
| ppisati | cooloney: because, for example, if you install a new kernel with same rev as the old one (3.5.0-666~foo will put modules in /lib/modules/3.5.0-666 just like the original 3.5.0-666 would do) | 10:37 |
| apw | ppisati, is that msdos or vfat though, we have vfat builtin on omap3 et al for that purpose, perhaps they are wrong? | 10:38 |
| ppisati | cooloney: but if the old one has no dos/8859-1 support compiled in, you will end up with modules overwritten (so no chacne to load msdos support) and no ability to mount /dev/mmcblk0p1 where uImage should be copied | 10:38 |
| cooloney | ppisati: but for omap3 we use =m as others | 10:39 |
| ppisati | cooloney: don't we have vfat set? | 10:40 |
| apw | ppisati, we have VFAT_FS set for all arm ports, we have MSDOS_FS set on ti-omap4 only | 10:40 |
| ppisati | ah | 10:40 |
| ppisati | so it's a mistake | 10:41 |
| apw | so i suspect we either need both on all or only vfat on all | 10:41 |
| cooloney | ppisati: VFAT=y for all arm stuff, | 10:41 |
| ppisati | cooloney: that should be... | 10:41 |
| cooloney | VFAT=m for others like i386 and amd64 | 10:41 |
| ppisati | btw | 10:41 |
| ppisati | so what's the diff between vfat and msdos? fat16 vs vat? | 10:41 |
| cooloney | so i think MSDOS_FS should be =m for omap4, right? | 10:42 |
| ppisati | i thought they were synonyms | 10:42 |
| apw | different drivers indeed. someone needs to investigate which we needed really on all of them | 10:42 |
| cooloney | ppisati: vfat will allow you to use long file names. | 10:44 |
| ppisati | cooloney: got for vfat then | 10:45 |
| cooloney | ppisati: yeah, i guess built in VFAT is enough, but not sure right now | 10:47 |
| apw | cking, smb, do the indicator menus look ok to you, about half of mine have wrong colours | 10:47 |
| apw | ppisati, can you not work out which one is in use by looking at the mount once mounted | 10:47 |
| smb | apw, not far enough yet to see them... | 10:47 |
| apw | smb, also got a jockey popup to offer me drivers, which appears to have done so to offer me 'pc speaker' | 10:48 |
| smb | apw, I assume you speak of quantal... | 10:48 |
| apw | smb, indeed is it not ISO testing day | 10:48 |
| smb | apw, It is. Just my alternate vm installs are not far enough for gfx | 10:49 |
| smb | The kubuntu on real hardware is doing bad enough not to be able to autoreport bus and the server install on that laptop fight s with enabling b44 | 10:49 |
| smb | Just one of these days... | 10:50 |
| cooloney | apw, smb, cking and ppisati, do you guys know where will we stay durning our portland sprint? | 10:50 |
| cooloney | or not decided yet | 10:50 |
| ppisati | cooloney: nope | 10:50 |
| ppisati | brb | 10:50 |
| smb | cooloney, We assume but do not know for sure | 10:51 |
| * ppisati -> out for lunch | 11:06 | |
| apw | ppisati, can you tell me which of the two hdmi ports on a panda is the right one? | 12:17 |
| apw | ppisati, have you tested the omap4 images for A2, i am struggling to get output from them, even though they seem to do the right kind of booting | 12:23 |
| apw | ppisati, also do i expect to see anything serial side? | 12:27 |
| ogra_ | apw, i have the same issue | 12:36 |
| apw | ogra_, ok so no output on hdmi then? which port is normally live | 12:36 |
| ogra_ | apw, bug 1010009 | 12:40 |
| ogra_ | no output at all on many monitors | 12:40 |
| ogra_ | i found a workaround for mine though | 12:40 |
| ubot2 | Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009 | 12:40 |
| apw | ogra_, not convinced i can plug it in later either | 12:41 |
| ogra_ | apw, works here | 12:41 |
| ogra_ | in the DVI port with hdmi->dvi cable here | 12:41 |
| ogra_ | ppisati, bah, the penguins are back ! | 12:42 |
| apw | ogra_, if i want to change the kernel comamnd line can i do that somewhere either on the image or the serial ? | 12:42 |
| ogra_ | on the SD | 12:43 |
| apw | oh oh where where | 12:43 |
| ogra_ | plug it into a PC, copy boot.scr from the first partition, open it with vi, remove the binary junk from the start and save it as boot.script | 12:43 |
| ogra_ | then run: sudo mkimage -A arm -O linux -T script -n 'Ubuntu Boot Script' -d boot.script /mnt/boot.scr | 12:44 |
| ogra_ | (given your SD was mounted on /mnt) | 12:44 |
| ogra_ | oh, and mkimage is in the u-boot-tools package | 12:44 |
| ogra_ | (for all arches available) | 12:44 |
| ogra_ | (note the binary stuff only spans half the first line, the rest are proper commands) | 12:45 |
| ppisati | apw: hdmi is the one close to the usb/eth thing | 12:46 |
| ogra_ | right | 12:46 |
| ogra_ | with the options i added to the bug i get proper output | 12:46 |
| ppisati | apw: copy the text part of boot.scr into a new file (boot.cmd) | 12:47 |
| ogra_ | well, usable ooutput | 12:47 |
| ppisati | apw: delete quiet and splash | 12:47 |
| ogra_ | proper would have been 1080p ;) | 12:47 |
| ppisati | apw: add console=ttyO2,115200n8 | 12:47 |
| ppisati | apw: then execute "mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Ubuntu 10.10" -d ./boot.cmd ./boot.scr" | 12:47 |
| ppisati | apw: next boot you'll get serial output | 12:48 |
| apw | ogra_, ok ... seems to be the same as yours then | 12:48 |
| apw | [ 64.306365] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays disabled | 12:48 |
| apw | [ 74.342163] omapdss error: HPD IRQ request failed | 12:48 |
| ogra_ | right | 12:48 |
| ppisati | apw: video is flaky | 12:48 |
| ppisati | apw: can you try booting with hdmi cable conncted on both ends | 12:48 |
| ogra_ | its stable if i add video=HDMI-A-1:1280x800@60 | 12:48 |
| ppisati | apw: and monitor turned on | 12:48 |
| ogra_ | but that doessnt mean it works for any other monitors | 12:49 |
| ogra_ | (and is no option for a default anyway) | 12:49 |
| ppisati | just booted today daily and it works here | 12:57 |
| ppisati | i mean video oiutput | 12:57 |
| ogra_ | yeah, you seem to be the only one :) | 12:57 |
| ogra_ | i wonder though ... | 12:57 |
| ogra_ | you always boot with console= set ? | 12:57 |
| ogra_ | on all images ? | 12:58 |
| ppisati | nope | 12:58 |
| ogra_ | ah, k | 12:58 |
| ppisati | this one is a plain daily | 12:58 |
| ppisati | i dd-ed to the sd card | 12:58 |
| ppisati | booted | 12:58 |
| ppisati | and that's it | 12:58 |
| ogra_ | i'm still wondering if there is a plymouth issue in the game as well | 12:58 |
| ppisati | now i'm on the Welcome screen | 12:58 |
| ogra_ | but if it works for you, it should be fine | 12:58 |
| ppisati | System configuration -> language, ectetc | 12:58 |
| ogra_ | hmpf | 12:59 |
| ogra_ | well, i havent found anyone else for whom it works yet | 12:59 |
| ppisati | benq 20" | 12:59 |
| ogra_ | your board or your monitor must be special :) | 12:59 |
| ppisati | monitor is an lcd from... | 12:59 |
| ppisati | 2005? | 12:59 |
| ppisati | maybe | 12:59 |
| ogra_ | though it used to work before here on the very same screen i use atm | 12:59 |
| ogra_ | and as you know downgrading to the precise kernel fixes it for me | 13:00 |
| ppisati | panda es? | 13:00 |
| * ogra_ just hopes for the next TILT dump | 13:00 | |
| ogra_ | yep ES | 13:00 |
| ppisati | uhm | 13:01 |
| ogra_ | well, the dvi.debug=7 cmdline option really helped here | 13:01 |
| ogra_ | and picking a mode from the debug output and forcing it on cmdline makes everything work | 13:02 |
| ppisati | uhm | 13:02 |
| ogra_ | i just cant seem to use 1080p | 13:02 |
| ogra_ | but i guess the driver defaults to 1080p since the monitor reports it wworking | 13:02 |
| ogra_ | so i wonder if its a video ram issue | 13:02 |
| ogra_ | but it doesnt seem to matter what i put into vram | 13:03 |
| ogra_ | ppisati, hmm, according to the ML you submitted the fix for the logo on june 6th ... why am i still seeing penguins | 13:12 |
| ogra_ | must be the drugs :P | 13:12 |
| === dileks is now known as Guest67607 | ||
| ogra_ | ppisati, argh, now i see ... your commit was on the 6th ... the last upload of the omap4 kernel was on the 5th though | 13:19 |
| ppisati | ogra_: yes, we are still using alpha1 kernel | 13:20 |
| ogra_ | ah, k | 13:20 |
| ppisati | ogra_: btw wait | 13:20 |
| ogra_ | so there cant be a kernel difference between live and preinstalled then | 13:20 |
| ogra_ | good | 13:21 |
| ppisati | ogra_: btw, i just booted another image | 13:21 |
| ppisati | ogra_: and it works here (video i mean) | 13:21 |
| ogra_ | well, what shall i say, it doesnt here :) | 13:22 |
| ppisati | ogra_: do you have abn installed system? | 13:22 |
| ogra_ | yup, but with the video= options added | 13:22 |
| ogra_ | *option | 13:22 |
| apw | man these heartbeat leads take some time to start, its all scarey | 13:25 |
| ogra_ | apw, yep, fixed in the tree already | 13:26 |
| ogra_ | (they are modular and initramfs-tools dont pull them into the initrd, so you only get them once the rootfs is there) | 13:27 |
| apw | ogra_, likely we should just build 'em in | 13:28 |
| apw | the board loooks sooooo dead without | 13:28 |
| ogra_ | yep, paolo already changed that | 13:28 |
| ogra_ | just not uploaded yet | 13:28 |
| * apw wonders how long he has to wait before ramming his HDMI in | 13:29 | |
| ogra_ | if the hearbeat is up, you should be fine | 13:30 |
| bjf | ikepanhc, do you know of more highbank patches coming? | 13:36 |
| ikepanhc | bjf: I do not know that yet. | 13:38 |
| ikepanhc | robher: any idea? I think you are the best man to answer this | 13:38 |
| robher | bjf, ikepanhc: there's always more coming ;) It should only be fixes at this point. | 13:41 |
| apw | we probabally errd having it in master | 13:41 |
| bjf | robher, though true, i was looking for a little more insite into what you know is actually in the pipeline heading our direction in the next 3 weeks | 13:46 |
| apw | ppisati, whats the URL to the working one for you | 13:47 |
| bjf | s/insite/insight/ | 13:47 |
| ppisati | apw: http://cdimage.ubuntu.com/daily-preinstalled/current/ | 13:47 |
| ppisati | apw: http://cdimage.ubuntu.com/daily-preinstalled/current/quantal-preinstalled-desktop-armhf+omap4.img.gz | 13:47 |
| ogra_ | http://cdimage.ubuntu.com/daily-live/current/ are the new images ... just FYI ... wont change a thing about the kernel issue | 13:48 |
| apw | ppisati, indeed the ones i tested, and not working at all for me | 13:48 |
| * ogra_ grabs his beagleXM and starts an omap test | 13:49 | |
| robher | bjf: There's 2 issues I'm working. I've figured out the root cause of "TEMP: force DMA buffers to non-bufferable on highbank", so this can be reverted/dropped. However, doing so breaks reboot cmd. The other issue is that power key driver doesn't really work because without a desktop, nothing in userspace will handle pwr key. On x86 it is handled by acpid... | 13:50 |
| ppisati | ogra_: leave your panda there | 13:52 |
| ogra_ | ppisati, i wont throw it away :) | 13:52 |
| brainsmoke | hi | 13:54 |
| brainsmoke | I would be really happy if https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=2e57ae0515124af45dd889bfbd4840fd40fcc07d | 13:54 |
| brainsmoke | oops | 13:54 |
| brainsmoke | could be backported to LTS | 13:55 |
| brainsmoke | since right now those are really handy non-ASLR gadgets exposed in every process | 13:56 |
| apw | brainsmoke, you are saying there are security ramifcations ? | 13:56 |
| ogra_ | ppisati, fyi, omap works :) | 13:57 |
| * ogra_ has screen output ... | 13:57 | |
| brainsmoke | It makes it easier to write an exploit, given that a program contains a bug | 13:57 |
| ogra_ | though the font is all blue | 13:57 |
| apw | sconklin, ^^ | 13:58 |
| brainsmoke | you basically only need one (or if you are lucky no) extra gadget for your return oriented programming exploit | 13:59 |
| brainsmoke | so I'd say it is an exploit mitigation patch | 14:00 |
| ppisati | ogra_: did you get an orange screen while booting? | 14:01 |
| ogra_ | yes, thats normal | 14:01 |
| ppisati | ok | 14:01 |
| ogra_ | hardcoded in u-boot | 14:01 |
| ogra_ | but it stopped booting with squashfs errors :( | 14:01 |
| apw | brainsmoke, yeah sounds something worth looking into, you could file a bug with that information in against linux package, and give me the number | 14:01 |
| apw | and i'll get it to the right people | 14:01 |
| ppisati | ogra_: ??? | 14:01 |
| apw | ogra_, damn this heap of crap is booted i recon and there is nothing enabled anywhere to let me login, this is stupid | 14:03 |
| ogra_ | ppisati, zlib infalte errors | 14:03 |
| ogra_ | *inflate | 14:03 |
| ogra_ | apw, the live image ? | 14:03 |
| apw | ogra_, any reason we don't ship serial.conf in the image? | 14:03 |
| apw | ogra_, yes | 14:03 |
| ogra_ | bug 702574 | 14:04 |
| ubot2 | ogra_: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable (https://launchpad.net/bugs/702574) | 14:04 |
| apw | i do not want to have to unpackage and rebuild this damn squashfs to debug this | 14:04 |
| ogra_ | and https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191 | 14:04 |
| ogra_ | its being discussed since 2 yeras | 14:04 |
| ogra_ | *years | 14:04 |
| apw | good god | 14:05 |
| * apw gives up, its just too hard | 14:05 | |
| apw | people who are willing to put up with this level of pain should not be allowed to produce software for others | 14:06 |
| === yofel_ is now known as yofel | ||
| ogra_ | apw, use a server image :) | 14:09 |
| ogra_ | doesnt need any screen, all serial | 14:09 |
| apw | ogra_, bad the tracker points to preinstalled images for server too | 14:10 |
| apw | frankly its too hard to help to do any testing on these images | 14:11 |
| ogra_ | apw, thats because Daviey is such a slacker | 14:11 |
| ogra_ | server stays preinstalled for now :) | 14:11 |
| ogra_ | until the x86 server images stzart using squashfs | 14:12 |
| ogra_ | ppisati, hmm, so i see the squashfs errors (and hang) every other boot here ... i now have a working installer on the screen, but that required a few reboots | 14:18 |
| ogra_ | (omap beagle XM that is) | 14:19 |
| ppisati | ogra_: image/ | 14:20 |
| ppisati | ogra_: ? | 14:20 |
| ogra_ | http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap.img | 14:20 |
| ogra_ | the most recent beagle one | 14:20 |
| ogra_ | seems like something is flakey with either the MMC or the squashfs driver | 14:21 |
| ppisati | ogra_: kernel version? | 14:23 |
| ogra_ | the latest as well | 14:23 |
| ogra_ | one sec | 14:23 |
| ogra_ | 3.5.0-2.2 | 14:23 |
| ogra_ | i think | 14:24 |
| ogra_ | yup, verified | 14:25 |
| pgraner | ppisati, yo man, omap4 and monitors wtf? | 14:43 |
| brainsmoke | apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018415 | 14:44 |
| ubot2 | Ubuntu bug 1018415 in linux "Backport vsyscall=emulate behaviour to 12.04 LTS as exploit mitigation measure" [Undecided,New] | 14:44 |
| ogra_ | pgraner, we will get a new code drop from TI that will fix it, not worth to put to much time of paolo into it | 14:44 |
| ogra_ | (there was hope to have that drop before A2 but apparently that failed) | 14:45 |
| pgraner | ogra_, when do we expect it to drop? | 14:45 |
| ogra_ | ask ppisati :) | 14:45 |
| * ogasawara back in 20 | 14:45 | |
| pgraner | ogra_, so the arm desktop image is not getting tested for A2? | 14:48 |
| ogra_ | it works fine here | 14:49 |
| ogra_ | with either changing the cdmline or booting without monitor plugged in | 14:49 |
| ogra_ | beyond that it has no issues at all it seems ... | 14:50 |
| ppisati | ogra_: actually for the next kernel we won't get any code drop from TI, we'll use vanilla + stuff from Linaro as needed | 15:04 |
| ppisati | pgraner: ^ | 15:04 |
| ogra_ | urgh, scary | 15:04 |
| ppisati | ogra_: there was an email circulating about it on the kernel ml | 15:04 |
| ppisati | ogra_: TI won't support 3.5 | 15:05 |
| ogra_ | well, what are they working on atm ? i thought there was a future kernel planned | 15:05 |
| ppisati | ogra_: they stay on 3.4 | 15:05 |
| ogra_ | beyond the rock solid 3.4 one that ndec's team has | 15:05 |
| ogra_ | oh | 15:05 |
| ogra_ | well, switching is pretty scary, did linaro actually tell that they will have no regressions wrt what we had in 12.04 ? | 15:06 |
| apw | cking, if those tests are easy to 'run' it might be worth comparing the P kernels too, to see if its broken in Q | 15:06 |
| cking | apw, it's easy but bloomin' time consuming | 15:07 |
| ppisati | ogra_: no no, we won't use linaro | 15:07 |
| ppisati | ogra_: i'm picking stuff from tilt, not the entire kernel | 15:07 |
| apw | ppisati, so we are running a head of ti ? | 15:07 |
| ogra_ | apw, ... and will suffer badly ... | 15:08 |
| ppisati | apw: if we want to have ti-omap4 on 3.5 | 15:08 |
| ppisati | apw: else it'll be another topic branch with a different kernel | 15:08 |
| pgraner | ppisati, can you or someone from the kernel team drop a bug number for the video issue in ubuntu-release and give skaet an eta on the fix pls. | 15:08 |
| ppisati | pgraner: did you tryu the image? because i've video output | 15:09 |
| ogra_ | bug 1010009 | 15:09 |
| ubot2 | Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009 | 15:09 |
| ogra_ | it is already tagged with iso-testing | 15:09 |
| apw | ppisati, oh i see our ti is 3.4 i missunderstood | 15:09 |
| ppisati | FWIW i've a 3.5 omap4 kernel here | 15:09 |
| ppisati | with working video | 15:09 |
| pgraner | ppisati, yes on 4 different monitors .... no video | 15:09 |
| ogra_ | ppisati, well, you should have uploaded it last week then :P | 15:10 |
| ppisati | ah | 15:10 |
| ogra_ | if you have it working already ... | 15:10 |
| * ppisati has the opnly monitor in the world where it works... | 15:10 | |
| ogra_ | yep | 15:10 |
| apw | do we want a 3.5, if tey arn't going to support us | 15:10 |
| ppisati | if not, it's another topic branch to mantain by ourself | 15:11 |
| ppisati | cve, sru, ectect | 15:11 |
| apw | bah rock meet hard place | 15:12 |
| ogra_ | ppisati, well, whats missing in your 3.5 ? | 15:13 |
| ppisati | ogra_: freq scaling | 15:13 |
| ppisati | ogra_: hdmi | 15:13 |
| ppisati | ogra_: didn't test the wifi tough | 15:14 |
| ppisati | ogra_: agreen has 1300+ commits on top of 3.4 | 15:14 |
| ppisati | to support omap4 and omap5 | 15:14 |
| ogra_ | ah, well, if we can get fixes for these and audio works too, then we'll be fine | 15:14 |
| ogra_ | though the alsa patching will be a pain i guess | 15:14 |
| ppisati | i'm doing freq scaling now | 15:14 |
| ppisati | /proc/asoud/cards reports 2 cards | 15:15 |
| ppisati | panda and hdmi | 15:15 |
| ppisati | didn;t test tough | 15:15 |
| ppisati | firs one should be ok | 15:15 |
| ppisati | secondo don't think so | 15:15 |
| ogra_ | yeah, i remember there were a bunch of patches that added UCM support | 15:15 |
| * ppisati has started today to assemble it... | 15:15 | |
| ogra_ | without it we wont have the devices in pulses gui | 15:15 |
| ogra_ | but there is enough time before release to fix that i suppose | 15:16 |
| skaet | ogra_, actually not... Based on the time it took yesterday, I think we're out of runway for A2. Getting it fixed and in the next set of dailies should be done. | 15:18 |
| ogra_ | skaet, if i say release i mean release ;) | 15:18 |
| ogra_ | not milestone ;) | 15:18 |
| ogra_ | the images we have atm look fine for A2, no need for respins or changes | 15:19 |
| skaet | ogra_ the workarounds are pretty ugly. | 15:20 |
| ogra_ | skaet, boot with no monitor attached until the LEDs blink wildly ? | 15:21 |
| ogra_ | (or you are sure that X is up) | 15:21 |
| ogra_ | i dont think thats to hard as a workaround | 15:21 |
| cking | arges, some rough notes on their way to you + a hacked version of jack_delay | 15:24 |
| kees | apw: please don't backport 2e57ae0515124af45dd889bfbd4840fd40fcc07d -- it doesn't play well with seccomp. | 15:31 |
| kees | apw: if anything, vsyscall should be "none" -- it's entirely deprecated. | 15:32 |
| skaet | ogra_, can you please add how this image needs to be worked around to the TechnicalOverview right now, and given where the issue is happening, we should probably add this to the notes on the top of the ISO tracker by these images at least. | 15:34 |
| ogra_ | skaet, will do, its noted in the bug along with another way that worked for me | 15:35 |
| bjf | kees, huh, can you comment on the bug? i was already working on it. | 15:35 |
| skaet | ogra_, yeah, but getting people to know about the bug an read it, as well as instructions for how they should interoperate with these new style images is going to be needed. | 15:36 |
| apw | bjf, i've referred that whole thing to security | 15:36 |
| bjf | apw, ack | 15:36 |
| ogra_ | skaet, indeed, though i expect the users to show up in #ubuntu-arm if they cant get along anyway :) | 15:36 |
| skaet | yeah, but give them some clues and pointing them there, is only polite ;) | 15:37 |
| apw | ogra_, for you if you plug hdmi in at the point when the flashies start and you are good ? | 15:37 |
| ogra_ | apw, right | 15:38 |
| apw | definatly does not work at all for me | 15:38 |
| ogra_ | i use an HDMI->DVI cable ... with the HDMI side attached to the HDMI port of the panda | 15:38 |
| apw | same as here | 15:38 |
| ogra_ | hmm, it cant really fail since booting without monitor forces it into a hardcoded mode | 15:39 |
| apw | ogra_, and what is the mode | 15:39 |
| ogra_ | unless your monitor cant do the 800x600 or 1024x786 or whatever that default is | 15:39 |
| apw | is a 1080p monitor, so it can emulate both of those, it did to my main box when i was fiddling just recently | 15:40 |
| ogra_ | apw, i have to boot into a broken setup again to find out, currently my beagle has all the stuff plugged in, will test the mode later | 15:40 |
| apw | diwic, ok that patch does have an = in the if so the report is valid, the form you have however is likely also valid so feel free to ignoew ir | 15:55 |
| ogra_ | RAAAH ! | 15:57 |
| * ogra_ goes mad ... who decided to add that silly microSD slot on the beagle at a place where i alwas accidentially rip it out of the slot | 15:58 | |
| * ogra_ starts the same install for the third time | 15:58 | |
| diwic | apw, aha, it does, I just didn't see it because it complained on another line than the actual = | 16:12 |
| apw | yeah you can ignore it, that construct is getting no simpler thats for sure | 16:15 |
| ogra_ | ppisati, so my omap install failed again and it looks to me like there are USB issues, i get lots of dropped event messages from the NIC driver and the copying of the OS to USB key fails at some point (sadly without any error) | 16:16 |
| ogra_ | oho ! | 16:17 |
| ogra_ | ubiquity: page allocation failure | 16:17 |
| ogra_ | there we go | 16:17 |
| apw | add more swap | 16:19 |
| ogra_ | heh | 16:21 |
| ogra_ | it has 700M | 16:22 |
| ppisati | ogra_: i'll try the omap image later | 16:29 |
| ogra_ | ppisati, k, not watching TV today ? | 16:31 |
| ogra_ | :) | 16:31 |
| ppisati | ogra_: who said i'm not going to watch the match? :) | 16:34 |
| ogra_ | heh | 16:34 |
| * ogra_ cant work if its an exciting one :) | 16:34 | |
| ppisati | well, spain vs portugal, who knows | 16:34 |
| ppisati | portugall will be covered for 90m + 30m | 16:35 |
| ogra_ | i guess spain will do it | 16:38 |
| ogra_ | tomorrow is more exciting though :) | 16:38 |
| ogra_ | germany never managed to beat italy ... | 16:38 |
| ppisati | ogra_: you will | 16:45 |
| ppisati | ogra_: first because your team is better this year | 16:45 |
| ogra_ | well, i fear our players are scared by the fact | 16:45 |
| ppisati | really? | 16:45 |
| ogra_ | and might make mistakes due to it | 16:45 |
| ogra_ | but yeah, they are better, but its football, its not always the better team that wins | 16:46 |
| ppisati | consider that Italy had just 3 days to recover from the previous match + prepare the new one | 16:46 |
| ppisati | right | 16:46 |
| ogra_ | and your guys still have an awesome talent to confuse the other team | 16:46 |
| ogra_ | so catching a goal or two is very likely for germany.... the question is how they handle that | 16:47 |
| ppisati | no no | 16:47 |
| ppisati | less rest | 16:47 |
| ppisati | less time to prepare | 16:47 |
| ppisati | a couiple of key players out (De Rossi and Chiellini) | 16:47 |
| ppisati | it'll be a suffering tomorrow | 16:47 |
| ogra_ | i doubt that, i think it will be an exciting game with well balanced out results | 16:48 |
| ppisati | well, we will see | 16:48 |
| ogra_ | i would be less worried to see them play against spain than against italy | 16:49 |
| ppisati | but i would be *really* surprised if Italy can make it | 16:49 |
| ppisati | really? | 16:49 |
| ogra_ | well, they made it this far | 16:49 |
| ppisati | you must be kidding | 16:49 |
| ppisati | i mean | 16:49 |
| ogra_ | spain is visibly in a very bad condition | 16:49 |
| ppisati | uh? | 16:49 |
| ppisati | are we watching the same stuff?!?!? :) | 16:49 |
| ppisati | i mean | 16:50 |
| ogra_ | they didnt deserve a single win they had this EURO | 16:50 |
| ppisati | well | 16:50 |
| ogra_ | they do their show etc but dont manage to shoot goals | 16:50 |
| ppisati | anyone playing against Spain should just pray they put in Torres | 16:50 |
| ppisati | he is so unable to score | 16:50 |
| ppisati | since he had that injury | 16:50 |
| ppisati | bah | 16:51 |
| ppisati | git am -s | 16:51 |
| ogra_ | heh | 16:51 |
| ppisati | wrong window | 16:51 |
| ppisati | ogra_: do you remember 2006 semifinal? | 16:52 |
| ppisati | ogra_: it was one of the "best" match i've ever seen | 16:52 |
| ppisati | ogra_: well balanced | 16:52 |
| ogra_ | ++ | 16:52 |
| ppisati | ogra_: and with a good ending :) | 16:52 |
| ogra_ | haha | 16:52 |
| ppisati | ogra_: don't worry, you'll get your revenge this time | 16:52 |
| ogra_ | we'll see, i will belive it tomorrow night | 16:53 |
| ogra_ | would be fun if portugal kicked out spain though | 16:53 |
| ppisati | i've a frind who bets against Italy | 16:53 |
| ppisati | so | 16:53 |
| ppisati | if Italy passes, he's kind of happy | 16:53 |
| ogra_ | heh | 16:53 |
| ppisati | if it looses, he's still happy! :) | 16:53 |
| ppisati | it's a win-win condition | 16:54 |
| ogra_ | i heard about betting on germany from several people | 16:54 |
| ogra_ | anyway, i need some food and then need to write some notes for kate before the game | 16:55 |
| * ogra_ is off for a bit | 16:55 | |
| === rtg is now known as rtg-lunch | ||
| cking | apw, the 3.2.0-23 low latency kernel has almost identical behaviour as the 3.5.0-1 low latency kernel, so no major screw ups there | 18:12 |
| kees | bjf: which bug number is it? I think I can solve both issues by setting vsyscall to "none". | 18:15 |
| bjf | kees, bug 1018415 | 18:16 |
| ubot2 | Launchpad bug 1018415 in linux "Backport vsyscall=emulate behaviour to 12.04 LTS as exploit mitigation measure" [High,Triaged] https://launchpad.net/bugs/1018415 | 18:16 |
| * cking --> EOD | 18:16 | |
| bjf | kees, apw said he has punted it to the security team | 18:17 |
| kees | bjf, apw, mdeslaur: I've added comments to 1018415. I think "= NONE" is the right way to go. | 18:26 |
| mdeslaur | kees: ah, interesting...thanks | 18:27 |
| mdeslaur | kees: watch, it's going to break java or something :) | 18:27 |
| kees | mdeslaur: well, if "none" doesn't work out, I still say that "emulate" isn't the right solution. | 18:29 |
| kees | mdeslaur: anyone concerned with it can just boot with vsyscall=whatever-they-want, too. :) | 18:29 |
| === rtg-lunch is now known as rtg | ||
| pgraner | apw, ping | 18:46 |
| pgraner | apw, ogra_ tells me your having the work around for the video issue fail on panda (bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1010009) | 18:46 |
| ubot2 | Ubuntu bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,Confirmed] | 18:46 |
| pgraner | apw, can you add some data about configs etc... to the bug | 18:46 |
| apw | pgraner, indeed, i have infinity's older board, the one we had at the release sprint | 19:24 |
| * rtg -> EOW | 19:33 | |
| vanhoof | pgraner: apw: have a panda-es running quantal in front of me, headless atm though if you'd like me to test something | 20:00 |
| apw | vanhoof, does the head work | 20:01 |
| pgraner | vanhoof, yea run todays desktop image and see if you get video out of hdmi | 20:02 |
| pgraner | vanhoof, if you don't try the workaround in bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1010009 | 20:02 |
| ubot2 | Ubuntu bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed] | 20:02 |
| pgraner | and comment in the bug with your results | 20:02 |
| vanhoof | pgraner: can I just dist-upgrade, or need to be a fresh install? | 20:02 |
| pgraner | vanhoof, fresh | 20:02 |
| pgraner | vanhoof, just an sd card bro go for it | 20:03 |
| vanhoof | pgraner: yeah got a few laying around here :) | 20:04 |
| vanhoof | pgraner: apw: no dice, will update the bug | 21:04 |
| hyperair | hmm, i don't seem to be seeing any autogroup-created cgroups in /sys/fs/cgroup/cpu. is it supposed to be invisible? | 21:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!