=== cyphermox is now known as cyphermox_ === cyphermox_ is now known as cyphermox [06:41] apw, ping === LetoTheII is now known as LetoThe2nd [07:36] * apw yawns [07:36] diwic, hi [07:55] apw, you're the maintainer of checkpatch, aren't you? [07:55] or at least a frequent contributor [07:55] diwic, indeed [07:55] apw, I'm getting what I think is a false positive [07:56] diwic, you won't be the first :) [07:56] apw, could I send the patch to you to double check that I'm not completely stupid? [07:56] of course [07:57] apw, sent [08:24] cking - hi [08:24] brendand, hiya [08:25] 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] cking, everything's still there, but swapped around [08:26] to illustrate : http://paste.ubuntu.com/1062206/ [08:26] brendand, nope, I didn't know that, I'll filed a bug and get that sorted out [08:33] brendand, I suggest not using the --s3-device-check flag until the fix lands in V0.25.05 [08:38] cking - thanks for looking at it [08:38] I'm working on a fix right now [08:39] thanks for identifying this issue - looks like it's not been exercised much [09:08] 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] yep, I've only tested it on ~5-10 machines here [09:09] xinput reordering its inputs through suspend, fun ... i bet its usb things which move [09:09] I overlooked this - doh [09:10] cking, to be honest, there's so much stuff going on that you can overlook that it's not worth worrying about [09:10] just have to take them as they come [09:11] yep, thanks for spotting this, I've got a fix written now, just testing it.. [09:14] cking, what i don't understand is that the id stays the same, so why doesn't xinput just id order? [09:14] because it likes to make our lives difficult? [09:14] cking, that's the correct answer! you win a prize [09:23] Hi Guys, I have doubt in 32 bit linux kernel and 64 bit linux kernel [09:23] my machine already working with 32 bit kernel. I have 64 bit kernel , I change my kernel as 64. [09:24] bit, it's possible do this. I can do install 64 bit packages [09:40] please guide me guys [09:41] you can in theory install a 64 bit kernel on an i386 userspace if it has 64bit support in the CPU [09:41] depending how much ram you have its not always a good idea though [09:42] cking, does the 'you may wish to read the release notes' link for work you on the installer?n [09:53] apw: hey, andy, i'm going to start to do config review for common ARM drivers [09:54] cooloney, ok sounds "fun" [09:54] apw: so a silly questions, actually what's common ARM drivers config or where is it? [09:54] apw: is it the common config file for armel and armhf? [09:55] heh ... thats a question, finding out whats 'h/w' specific options is pretty hard [09:55] i have never approached commonising config from that side just for that reason [09:56] apw: hah, i just start and found it's hard to find them indeed [09:56] apw: but i saw your email several weeks about ARM config. [09:57] well i was fighting arm configs which differed in non-arm things, things like filesystems, right ? [09:58] cooloney: you'll find a lot of arm (and even omap-only) related crap even in config.common.ubuntu [09:59] apw, I have i5 processor in my machine how to configure custom kernel please guide [09:59] ppisati: oh that's bad [09:59] apw: i remember some USB host configs were mentioned in your email [10:00] how to utilize the hole hardware to my linux kernel [10:01] cooloney: yes it is, unfortunately [10:01] cooloney: it would be nice if we could push all the hw-agnostic stuff in config.common [10:02] cooloney: and leave arm details in config//config.* [10:02] cooloney: but i think it's a lot of work, and a lot of shuffling stuff around [10:02] but it will make the future so much easier :) [10:03] yes, but whenever i moved any option out of that file, it reappeared in all the arch specific config file after an updateconfigs [10:04] i didn't imagine the work is so hard before [10:04] i think the logic is someghing like "can i have that option? good, then i put it in config.common" [10:05] "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] 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] in that case they won't appear in config.common i guess [10:06] 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] i hope i got it right... [10:06] somehow... [10:07] ppisati: oh wait, looks like this is an updateconfigs script issue [10:07] cooloney: no no [10:07] cooloney: wait, let me show you an example [10:07] ppisati: yeah [10:10] 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] cooloney: take for example an omap option [10:10] cooloney: like... [10:10] cooloney: CRYPTO_DEV_OMAP_AES [10:10] cooloney: it shouldn't be here [10:11] since it's arm (and even omap in this case) specific [10:11] ppisati: yeah [10:11] so it should go in config/arm[hf|el]/config.flavour.omap [10:11] now, if you move it here, ALL the other other configs file will get this option replicated [10:12] let me try... [10:12] cooloney, ppisati, the config optimiser takes no account of which arch something ocmes from as it does not really know [10:12] ppisati: I know what you mean here now. [10:12] i found 11 OMAP config in common.ubuntu config [10:12] and its dangersous to try anyhow because armhf and armel are 'separate' configuration options [10:13] s/options/arches [10:13] but they need to be mostly common [10:13] 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] where something is in the config hierachy isn't important really, whats important is when its set it is set appropriatly [10:14] which is where the configuration checker comes in [10:14] https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha2 [10:14] which is what we use to review and fix options normally [10:16] 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:17] apw: right, so if an option is the same for all arches, it goes into top common config [10:17] yes it will roll up to th [10:17] to the top [10:18] apw: and if is the same for all the armhf arch, it goes into common.armhf.config. [10:18] if tis the same for all armhf configs but not for other arches, then yes its in common.armhf only [10:18] 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:19] right and that is expected, its a side effect of the algorithm [10:19] apw: yeah, exactly [10:19] to be honest its utilitity, the commonisation is less important now we have a proper config comparitor [10:19] 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:21] 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] this way adding a new flavour equals adding a new config leaf [10:21] file [10:21] ppisati, that would be nice, but thats not quite how it works [10:21] e.g. armhf/config.flavour.highbank [10:22] apw: yes [10:22] ppisati, generally to add a new flavour you can just dump a full config down in that file [10:22] and fdr updateconfigs will clear out the common stuff and make a mess of the configs of course [10:22] apw, re: installer, not yet got around to that, will be testing in 20 mins [10:22] apw: i think i did during the omap4 review (and last omap3 config bisection) [10:23] apw: and updateconfigs badly messed up the config [10:23] anyway [10:23] cooloney: in any way, have fun! :) [10:23] ppisati, well yes if your config is differnt it has to change the balance to maintain your config [10:23] cooloney: sun is shining, it's summer time, and all that solar crap... :) [10:23] ppisati, it doesn't override any of the configs, which is what you want [10:24] apw: i don't know, maybe i had a dream/nightmare [10:24] apw: but during the... [10:24] i have a bunch of overrides documented now though for next time, which i did to fix highbank up [10:24] apw: 3.5 rebase, to me it looks like omap3 "imported" some options that weren't there before [10:24] 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:25] 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] to get asked about the new things [10:25] then used that one in the ubuntu tree [10:26] IMVHO we could drop updateconfigs, and mantain config.common manually [10:26] apw: could be, don't rememebr when i had that impression [10:26] (but i know it won't happen) [10:27] ppisati, the utility of updateconfigs for changing configs is less than it was [10:27] now we also have OVERRIDES to inject changes across the board [10:27] getting from where we are to where you suggest is very hard, but it would be a better place [10:28] i know, a lot of shuffling around [10:28] and you can't do that in one pass [10:28] it's an iterative process [10:28] ppisati, the biggest issue is there is hierachy we cannot express currently like [10:28] ubuntu -> arm -> armel/armhf [10:28] right [10:29] and till we can do that its tricky, and the layout of the configs is tied to other layouts currently [10:29] well, truth be told that's becasue we use ABIs instead of arch [10:29] are we going to support... [10:29] 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] the 32/64 bit hybrid [10:30] what was the name... [10:30] apw and ppisati, i think basically i can start that from the URL for kernel config review. [10:30] n32 [10:30] "ubuntu needs X" "x86 needs Y" "x86/server needs Z" [10:30] 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:31] for example arm needs vfat builtin and thats right, so it has an annotation [10:31] no, it's not n32... [10:31] apw: sure, i will and try to change the status of this task from TODO to IN PROGRESS [10:31] x32! [10:31] apw: and can never mark that as DONE. heh [10:31] cooloney, which task? [10:32] apw: review common drivers for ARM [10:32] http://en.wikipedia.org/wiki/X32_ABI [10:32] this one would use 64bit regs in a 32b address space [10:32] cooloney, sounds good, and even a rough pass is better than nothing [10:33] i don't think we are going to support it [10:33] ppisati, yep its probabally what amd64 should have been [10:33] but in case we do, we will find ourself in the same situation with armhf/armel [10:33] with x32 and i386 [10:33] apw: np, [10:33] ppisati, indeed, well we already are, as i386/amd64 already has this commonality [10:34] * apw will play with that before sprint [10:34] ppisati: so the first one, why CONFIG_MSDOS_FS should be =y instead of =m for omap4? [10:36] 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:37] 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:38] ppisati, is that msdos or vfat though, we have vfat builtin on omap3 et al for that purpose, perhaps they are wrong? [10:38] 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:39] ppisati: but for omap3 we use =m as others [10:40] cooloney: don't we have vfat set? [10:40] ppisati, we have VFAT_FS set for all arm ports, we have MSDOS_FS set on ti-omap4 only [10:40] ah [10:41] so it's a mistake [10:41] so i suspect we either need both on all or only vfat on all [10:41] ppisati: VFAT=y for all arm stuff, [10:41] cooloney: that should be... [10:41] VFAT=m for others like i386 and amd64 [10:41] btw [10:41] so what's the diff between vfat and msdos? fat16 vs vat? [10:42] so i think MSDOS_FS should be =m for omap4, right? [10:42] i thought they were synonyms [10:42] different drivers indeed. someone needs to investigate which we needed really on all of them [10:44] ppisati: vfat will allow you to use long file names. [10:45] cooloney: got for vfat then [10:47] ppisati: yeah, i guess built in VFAT is enough, but not sure right now [10:47] cking, smb, do the indicator menus look ok to you, about half of mine have wrong colours [10:47] ppisati, can you not work out which one is in use by looking at the mount once mounted [10:47] apw, not far enough yet to see them... [10:48] smb, also got a jockey popup to offer me drivers, which appears to have done so to offer me 'pc speaker' [10:48] apw, I assume you speak of quantal... [10:48] smb, indeed is it not ISO testing day [10:49] apw, It is. Just my alternate vm installs are not far enough for gfx [10:49] 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:50] Just one of these days... [10:50] apw, smb, cking and ppisati, do you guys know where will we stay durning our portland sprint? [10:50] or not decided yet [10:50] cooloney: nope [10:50] brb [10:51] cooloney, We assume but do not know for sure [11:06] * ppisati -> out for lunch [12:17] ppisati, can you tell me which of the two hdmi ports on a panda is the right one? [12:23] 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:27] ppisati, also do i expect to see anything serial side? [12:36] apw, i have the same issue [12:36] ogra_, ok so no output on hdmi then? which port is normally live [12:40] apw, bug 1010009 [12:40] no output at all on many monitors [12:40] i found a workaround for mine though [12:40] Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009 [12:41] ogra_, not convinced i can plug it in later either [12:41] apw, works here [12:41] in the DVI port with hdmi->dvi cable here [12:42] ppisati, bah, the penguins are back ! [12:42] ogra_, if i want to change the kernel comamnd line can i do that somewhere either on the image or the serial ? [12:43] on the SD [12:43] oh oh where where [12:43] 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:44] then run: sudo mkimage -A arm -O linux -T script -n 'Ubuntu Boot Script' -d boot.script /mnt/boot.scr [12:44] (given your SD was mounted on /mnt) [12:44] oh, and mkimage is in the u-boot-tools package [12:44] (for all arches available) [12:45] (note the binary stuff only spans half the first line, the rest are proper commands) [12:46] apw: hdmi is the one close to the usb/eth thing [12:46] right [12:46] with the options i added to the bug i get proper output [12:47] apw: copy the text part of boot.scr into a new file (boot.cmd) [12:47] well, usable ooutput [12:47] apw: delete quiet and splash [12:47] proper would have been 1080p ;) [12:47] apw: add console=ttyO2,115200n8 [12:47] 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:48] apw: next boot you'll get serial output [12:48] ogra_, ok ... seems to be the same as yours then [12:48] [ 64.306365] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays disabled [12:48] [ 74.342163] omapdss error: HPD IRQ request failed [12:48] right [12:48] apw: video is flaky [12:48] apw: can you try booting with hdmi cable conncted on both ends [12:48] its stable if i add video=HDMI-A-1:1280x800@60 [12:48] apw: and monitor turned on [12:49] but that doessnt mean it works for any other monitors [12:49] (and is no option for a default anyway) [12:57] just booted today daily and it works here [12:57] i mean video oiutput [12:57] yeah, you seem to be the only one :) [12:57] i wonder though ... [12:57] you always boot with console= set ? [12:58] on all images ? [12:58] nope [12:58] ah, k [12:58] this one is a plain daily [12:58] i dd-ed to the sd card [12:58] booted [12:58] and that's it [12:58] i'm still wondering if there is a plymouth issue in the game as well [12:58] now i'm on the Welcome screen [12:58] but if it works for you, it should be fine [12:58] System configuration -> language, ectetc [12:59] hmpf [12:59] well, i havent found anyone else for whom it works yet [12:59] benq 20" [12:59] your board or your monitor must be special :) [12:59] monitor is an lcd from... [12:59] 2005? [12:59] maybe [12:59] though it used to work before here on the very same screen i use atm [13:00] and as you know downgrading to the precise kernel fixes it for me [13:00] panda es? [13:00] * ogra_ just hopes for the next TILT dump [13:00] yep ES [13:01] uhm [13:01] well, the dvi.debug=7 cmdline option really helped here [13:02] and picking a mode from the debug output and forcing it on cmdline makes everything work [13:02] uhm [13:02] i just cant seem to use 1080p [13:02] but i guess the driver defaults to 1080p since the monitor reports it wworking [13:02] so i wonder if its a video ram issue [13:03] but it doesnt seem to matter what i put into vram [13:12] ppisati, hmm, according to the ML you submitted the fix for the logo on june 6th ... why am i still seeing penguins [13:12] must be the drugs :P === dileks is now known as Guest67607 [13:19] ppisati, argh, now i see ... your commit was on the 6th ... the last upload of the omap4 kernel was on the 5th though [13:20] ogra_: yes, we are still using alpha1 kernel [13:20] ah, k [13:20] ogra_: btw wait [13:20] so there cant be a kernel difference between live and preinstalled then [13:21] good [13:21] ogra_: btw, i just booted another image [13:21] ogra_: and it works here (video i mean) [13:22] well, what shall i say, it doesnt here :) [13:22] ogra_: do you have abn installed system? [13:22] yup, but with the video= options added [13:22] *option [13:25] man these heartbeat leads take some time to start, its all scarey [13:26] apw, yep, fixed in the tree already [13:27] (they are modular and initramfs-tools dont pull them into the initrd, so you only get them once the rootfs is there) [13:28] ogra_, likely we should just build 'em in [13:28] the board loooks sooooo dead without [13:28] yep, paolo already changed that [13:28] just not uploaded yet [13:29] * apw wonders how long he has to wait before ramming his HDMI in [13:30] if the hearbeat is up, you should be fine [13:36] ikepanhc, do you know of more highbank patches coming? [13:38] bjf: I do not know that yet. [13:38] robher: any idea? I think you are the best man to answer this [13:41] bjf, ikepanhc: there's always more coming ;) It should only be fixes at this point. [13:41] we probabally errd having it in master [13:46] 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:47] ppisati, whats the URL to the working one for you [13:47] s/insite/insight/ [13:47] apw: http://cdimage.ubuntu.com/daily-preinstalled/current/ [13:47] apw: http://cdimage.ubuntu.com/daily-preinstalled/current/quantal-preinstalled-desktop-armhf+omap4.img.gz [13:48] http://cdimage.ubuntu.com/daily-live/current/ are the new images ... just FYI ... wont change a thing about the kernel issue [13:48] ppisati, indeed the ones i tested, and not working at all for me [13:49] * ogra_ grabs his beagleXM and starts an omap test [13:50] 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:52] ogra_: leave your panda there [13:52] ppisati, i wont throw it away :) [13:54] hi [13:54] I would be really happy if https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=2e57ae0515124af45dd889bfbd4840fd40fcc07d [13:54] oops [13:55] could be backported to LTS [13:56] since right now those are really handy non-ASLR gadgets exposed in every process [13:56] brainsmoke, you are saying there are security ramifcations ? [13:57] ppisati, fyi, omap works :) [13:57] * ogra_ has screen output ... [13:57] It makes it easier to write an exploit, given that a program contains a bug [13:57] though the font is all blue [13:58] sconklin, ^^ [13:59] you basically only need one (or if you are lucky no) extra gadget for your return oriented programming exploit [14:00] so I'd say it is an exploit mitigation patch [14:01] ogra_: did you get an orange screen while booting? [14:01] yes, thats normal [14:01] ok [14:01] hardcoded in u-boot [14:01] but it stopped booting with squashfs errors :( [14:01] 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] and i'll get it to the right people [14:01] ogra_: ??? [14:03] 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] ppisati, zlib infalte errors [14:03] *inflate [14:03] apw, the live image ? [14:03] ogra_, any reason we don't ship serial.conf in the image? [14:03] ogra_, yes [14:04] bug 702574 [14:04] ogra_: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable (https://launchpad.net/bugs/702574) [14:04] i do not want to have to unpackage and rebuild this damn squashfs to debug this [14:04] and https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/add-serial-console/+merge/46191 [14:04] its being discussed since 2 yeras [14:04] *years [14:05] good god [14:05] * apw gives up, its just too hard [14:06] people who are willing to put up with this level of pain should not be allowed to produce software for others === yofel_ is now known as yofel [14:09] apw, use a server image :) [14:09] doesnt need any screen, all serial [14:10] ogra_, bad the tracker points to preinstalled images for server too [14:11] frankly its too hard to help to do any testing on these images [14:11] apw, thats because Daviey is such a slacker [14:11] server stays preinstalled for now :) [14:12] until the x86 server images stzart using squashfs [14:18] 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:19] (omap beagle XM that is) [14:20] ogra_: image/ [14:20] ogra_: ? [14:20] http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap.img [14:20] the most recent beagle one [14:21] seems like something is flakey with either the MMC or the squashfs driver [14:23] ogra_: kernel version? [14:23] the latest as well [14:23] one sec [14:23] 3.5.0-2.2 [14:24] i think [14:25] yup, verified [14:43] ppisati, yo man, omap4 and monitors wtf? [14:44] apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018415 [14:44] Ubuntu bug 1018415 in linux "Backport vsyscall=emulate behaviour to 12.04 LTS as exploit mitigation measure" [Undecided,New] [14:44] 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:45] (there was hope to have that drop before A2 but apparently that failed) [14:45] ogra_, when do we expect it to drop? [14:45] ask ppisati :) [14:45] * ogasawara back in 20 [14:48] ogra_, so the arm desktop image is not getting tested for A2? [14:49] it works fine here [14:49] with either changing the cdmline or booting without monitor plugged in [14:50] beyond that it has no issues at all it seems ... [15:04] 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] pgraner: ^ [15:04] urgh, scary [15:04] ogra_: there was an email circulating about it on the kernel ml [15:05] ogra_: TI won't support 3.5 [15:05] well, what are they working on atm ? i thought there was a future kernel planned [15:05] ogra_: they stay on 3.4 [15:05] beyond the rock solid 3.4 one that ndec's team has [15:05] oh [15:06] well, switching is pretty scary, did linaro actually tell that they will have no regressions wrt what we had in 12.04 ? [15:06] 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:07] apw, it's easy but bloomin' time consuming [15:07] ogra_: no no, we won't use linaro [15:07] ogra_: i'm picking stuff from tilt, not the entire kernel [15:07] ppisati, so we are running a head of ti ? [15:08] apw, ... and will suffer badly ... [15:08] apw: if we want to have ti-omap4 on 3.5 [15:08] apw: else it'll be another topic branch with a different kernel [15:08] 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:09] pgraner: did you tryu the image? because i've video output [15:09] bug 1010009 [15:09]