=== mfisch is now known as Guest6140 === Guest6140 is now known as mfisch [06:30] moin === smb` is now known as smb [07:27] morning [07:28] ciao Stef :) [07:31] Tach Paolo :) [08:05] have you ever tried to raise the compilation flags? it's an experience you'll never forget... never... [08:12] I am not sure I would even know what you mean to start with... but even if it sounds I would not want to do either... [08:15] but for what i'm doing it's panacea, i can't beleive some much shit pass unnoticed [08:15] i just hit a problem where a funcion in a patch was changed to accept a pointer to a struct instead of an uint [08:16] and guess what? the code still compiled, even with such a big change!!! [08:16] i mean, really, i want the compilation to break in such cases [08:17] so i went to raise the compiler flags to a simple "-Werror", hell, now i cleaning all kind of crap [08:17] Ah, good ol' -Werror [08:17] and i already got two bugs that would go unnoticed without stricter compilation [08:17] there was a variable that was used WITHOUT any initialization [08:17] i mean, something like val &= ... [08:18] Yeah, I guess it might be a good idea in general to grab the compile log once in a while and look at the warnings [08:18] again, i want the compilation to break in this case [10:10] brb [10:13] that's funny... i'm unable to clone ubuntu-hardy.git using as --reference a local mainline git tree. [10:13] for ex, in tangerine: [10:13] git clone --reference /usr3/ubuntu/linux.git/ git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git [10:13] this command hangs forever [10:15] <_ruben> heheh [10:15] <_ruben> err, wrong window had focus [10:15] * _ruben needs focus-follows-eyes feature [11:02] henrix, that is odd indeed [11:03] apw: yeah, but i was able to clone it [11:03] apw: it just takes a loooong time [11:03] apw: which is odd, as with other releases it's quite fast [11:03] ppisati, you may be able to raise specific warnings to error rather than all of them [11:04] henrix, strange indeed [11:04] perhaps it needs packaing [11:04] yep, that's probably the reason [11:05] smb, i thought it was that no cpu didn't have that feature ? [11:27] * henrix -> food === Ming is now known as Guest63579 [11:39] * ppisati -> food too [12:12] infinity: hey, adam, i'm going to build the package you listed on my imx6 board. [12:12] so i'm running apt-get install buildd [12:12] is that correct way to do that? [12:13] apw, Oh dear, what did I write now? [12:14] smb, i've replied to the email anyhow, it makes more sense there (the intel kvm one) [12:15] apw, Yeah, I would be replying there as well right now [12:15] apw, Of course itr was the other way [12:16] smb, i see now avi has said he is happy and sent it on, which is also good [12:16] apw, yep [12:16] apw, And it should read "every real cpu *has* the feature" [12:17] apw, Which makes much more sense [12:17] smb, yeah that was what i was trying to say also :) [12:17] Yeah, I apparently cannot do a !! today... :-P [12:19] heh ... it is very hot for not-not [12:26] cooloney: There's no buildd package in the archive, I'd hope. [12:26] cooloney: What you want is sbuild. [12:27] cooloney: apw can probable give you pointers on mk-sbuild and having two reasonably identical setups on your iMX6 and PandaES. [12:28] infinity: oh, it's installing 170M packages on my board after i ran "apt-get install buildd", sh*t [12:29] infinity: pandaES just supports SD card, i'm afraid i can't install too many packages, my largest SD card is just 16MB [12:29] cooloney: Oh, hey, we do have "buildd" in the archive, look at that. That's the Debian buildd, has nothing to do with how we do things. [12:29] cooloney: Err, what? [12:29] cooloney: "Just supports SD"? [12:30] cooloney: That's in direct contradiction of all of us who have Pandas with USB hard drives. And all the Panda buildds in the DC. [12:30] infinity: yeah, pandaES doesn't support SATA harddisk, only SD card [12:30] infinity: ok, i can setup USB hard drive on my panda ES [12:30] cooloney: And if we're not benchmarking this against a PandaES setup that's similar, there's no reason in running these benchmarks AT ALL. [12:30] cooloney: Cause it tells us nothing. [12:31] cooloney: In both cases, you should be running everything from the hard drives, nothing from SD. [12:31] infinity: got it. so i need to setup sbuild on both PandaES and imx6, right? [12:31] cooloney, yeah you want to use the 'kees' method so they get reset after each build [12:32] infinity: yeah, right now, I just boot from SD for loading kernel and run rootfs on SATA harddrive for my imx6 [12:33] cooloney: Right, same thing for Panda then, which is the setup you'd get by default if you run a netboot install. [12:33] apw: thanks, that recalls me i wrote a wiki section before about using sbuild for building kernel. [12:33] apw: The kees method? :P [12:33] apw: sbuild's default behaviour is that. [12:33] apw: Or do you mean hard-resetting the machines too? (which isn't a bad idea for benchmarking) [12:34] infinity: yeah, got it. my imx6 board is based on linaro precise system and our own 3.2 kernel. it's that ok? [12:34] infinity: for panda, i probably will use latest quantal image [12:34] cooloney: Everything important will be happening in a pure precise chroot anyway, thanks to mk-sbuild, I assume. [12:34] cooloney: So, as long as it's our kernel, the userspace doesn't matter too much. [12:35] cooloney: And no, benchmark precise versus precise, we're not going to be running quantal (or some Linaro thing, or whatever) in the DC. [12:42] cooloney: Also, can I get this magical Ubuntu 3.2 kernel for the mx6? It seems as though it never fell in my lap. [12:42] oh, there is a 3.2 for mx6 ? [12:42] * ogra_ wants that too [12:42] (i havent had the time yet to play with my mx6 though) [12:43] infinity and ogra_, please clone the branch http://kernel.ubuntu.com/git?p=rtg/ubuntu-precise.git;a=shortlog;h=refs/heads/imx6-sabre [12:44] and i just found latest building with latest gcc 4.7 will fail due to some GPU driver, as for our buildd usage, I just disable that GPU driver. but you guys can try that [12:45] Well, it wouldn't be built with gcc-4.7 for precise anyway... [12:45] henrix, bjf A heads up: I think I have a odd regression with current precise-proposed [12:45] smb: do you have a bug #? [12:46] henrix, Not yet, I was just closing in on the kernel part this morning (after ruling out some other changes) [12:47] smb: ok. let me know once you have a bug filed [12:47] smb: thanks [12:47] just on it [12:47] infinity: i'm running gcc-4.7 on quantal now. [12:48] cooloney: Yes... But the above is for precise, where kernels are built with 4.6 [12:49] infinity: yeah, i will rebuild the kernel on imx6 board right now [12:52] cooloney, on chinstrap.ubuntu.com:~apw/HINTS are my notes of how to setup chroots under sbuild correctly [12:53] cooloney, obviously for your purposes you want armel and armhf chroots [12:54] apw: thanks, that saves me lot of time. [12:55] infinity: do you need to test SSD? or just hard disk is enough [12:55] cooloney, we are talking about buildd comparisons here [12:55] cooloney, so you need to have the config which they have [12:56] cooloney, which is a USB disk in the existing setup i believe, and sata disk for the new one [12:56] cooloney: Rotary disks, no sane person runs a buildd on SSD, unless they hate themselves. [12:56] * apw pops out for some supplies [12:57] apw, got it. i just found a spare SATA HD, if you wanna SSD, i might need to order it in advance. [12:58] infinity: lol, ok, let me setup the sbuild and file the building on HD [12:58] henrix, bug 1034885 is filed but I just had another idea of what could be wrong beside the kernel... Unfortunately it is "this" machine I need to test on... [12:58] Launchpad bug 1034885 in linux "[precise] Proposed kernel does not automatically load usb-storage for card-reader" [Undecided,New] https://launchpad.net/bugs/1034885 [12:59] smb: let me take a look... [13:00] henrix, One of the things also changed is initramfs-tools config from most to dep... So it also could be that... [13:01] smb: It's almost certainly not the kernel, but something userspacey. Unless something's gone HORRIBLY wrong. [13:02] infinity, Yeah, I was already curious because there were no real changes in usb that could do that [13:04] smb: infinity: yeah that makes sense, there's nothing in the kernel changelog that caught my attention [13:04] but i just did a very quick look [13:05] * smb reboots with the full blown initrd [13:09] smb: please, satisfy my curiosity! :) [13:09] henrix, Bah, ok. It was the initrd [13:10] smb: ack, thanks :) [13:50] smb, interesting, we are clearly missing something we do need in 'dep' [13:51] apw, Maybe. I first want to make sure it was not a failing to rebuild after I reverted back from your kmod (which was not intended for that release anyway). [13:51] apw, But I wanted to leave that for another day (s reboot) [13:51] indeed [13:52] At least the kernel is not at fault. Which was the major concern. Of course it took me until I filed the bug to realize the initrd hint [14:33] bjf: failed Natty SRU, please see bug 1034930 [14:33] Launchpad bug 1034930 in linux "QRT failed on test_101_proc_fd_leaks (__main__.KernelSecurityTest)" [Critical,New] https://launchpad.net/bugs/1034930 [14:42] hggdh: i guess this test used to pass before, right? [14:43] hggdh: because there are only a few changes in natty, and none seem to be related... [14:43] hggdh: but i'll take a closer look [14:43] henrix: i'd expect a bad exit code rather than a traceback [14:44] 08/08 22:02:52 ERROR|base_utils:0114| [stderr] AssertionError: Got exit code 10. Looking for text " 0x" [14:44] bjf, it is complaining about a bad exit code [14:47] apw, i guess. i wouldn't throw an exception if i was checking for an exit code and know that i didn't get the one expected. but i'm odd i guess. [14:56] henrix: it used to pass, yes [14:56] hggdh: ack, thanks [14:59] ppisati, ping [15:00] ericm|ubuntu: pong [15:09] * ogasawara back in 20 [16:06] cooloney, hmm, i cant boot the mx6 kernel (just buiolt a package from your tree not changing anything and put the uImage in place of the original one on the mmc) [16:06] Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9). [16:06] Available machine support: [16:06] ID (hex) NAME [16:06] ffffffff Freescale i.MX6 Quad (Device Tree) [16:14] sforshee: Ok, I have working patches for gmux on the retina [16:15] sforshee: ...which is also lacking VBT, so I'll poke on that a little [16:17] mjg59, awesome. I'm still waiting for the retina to arrive [16:18] mjg59, I should get back to working on dealing with no vbt in i915 later today, if you make progress let me know [16:18] sforshee: http://fpaste.org/U05X/ and http://fpaste.org/WhLZ/ [16:21] mjg59, re the first patch, that might break some macs. You might ask Andreas about it, but some of the information I got from him indicated that breaking up the writes was necessary for some machines. [16:22] mjg59, and looks like an unrelated change to nouveau snuck in ;) [16:24] sforshee: It... does break up the writes? [16:24] sforshee: Also, the retina is edp and not lvds, so it's going to be separate fixes [16:24] Yeah, ignore the nouveau thing [16:25] mjg59, it changes the series of write8s to a write32 in gmux_update_status [16:25] sforshee: write32 breaks up the writes [16:25] It's not an outl [16:25] mjg59, okay, I obviously didn't really look at write32 [16:28] mjg59, so you used directhw to reverse engineer this? [16:28] sforshee: Partially, yeah [16:28] sforshee: But it turns out that the ACPI backlight uses the gmux [16:28] So I could work out most of the register writes from there [16:29] sforshee: [ 531.579739] [drm] bad panel power sequencing delays, disabling panel [16:29] sforshee: Yeah ok this is going to be more awkward [16:30] mjg59, yuck [16:31] mjg59, Did you try https://lkml.org/lkml/2012/8/8/410 for the nointremap issue? Just curious if it's the same issue. [16:32] sforshee: No, but I expect it will be [16:39] henrix, did you find anything with that natty qrt issue? [16:39] bjf: still looking. i'm able to reproduce it [17:11] sforshee: have you seen any status on the macbook-air wireless issue? (i have not) === kamal1 is now known as kamal [17:43] * smb -> EODish [17:52] bjf, no, I haven't seen any updates at all. I saw it one time last week, but once again couldn't reproduce it after that. [18:10] if I only install linux-image-3.5.1-030501-generic (amd64) I get wrong resolution (guess 1024x768), no working mouse and no networking. [18:11] installing appropriate linux-image-extra solves them all [18:11] for whom is the small linux-image good for :-)? [18:11] ...and the splitting into 2 packages [18:13] dileks: it is good for vms and cloud instances [18:14] dileks, we no longer have separate "virtual" and "server" flavours [18:14] everywhere the cloud [18:14] dileks: didn't you get the memo, PCs are dead [18:15] I remember painting network diagrams with "the Internet" as a cloud [18:15] decades ago [18:15] damn marketing asses [18:35] bug 1023566 [18:35] Launchpad bug 1023566 in linux-meta "Update Precise LBM to include v3.4 compat-wireless stack" [Medium,In progress] https://launchpad.net/bugs/1023566 [18:35] bjf, herton: ^^ just fyi, that's what I was looking at [19:29] * ogasawara lunch [20:02] sforshee: Yeah, your patch fixes nointremap [20:02] mjg59, thanks for letting me know. I suspected it was the same problem but it's good to know for sure. [20:03] hi. is grabbing the desired .debs from http://kernel.ubuntu.com/~kernel-ppa/mainline/ the correct way to test more recent kernels on 12.04? [20:18] bjf: hggdh: i finally root caused the natty failure [20:18] it looks like its a bug in the test itself [20:18] more specifically, in the qrt framework [20:19] heh [20:19] basically, the test checks if a kernel has a CVE fix by looking at the changelog [20:19] the prob is that the changelog is truncated [20:19] ugh [20:20] so, basically the CVE fix check has to be done in a different way [20:20] so the kernel does not have this fix? [20:20] or does it? [20:20] the kernel *has* the fix. but since the test fails to detect that, it inverts the pass/fail logic [20:21] better to point you to the code: [20:21] let me pastebin it [20:22] here: http://pastebin.ubuntu.com/1138451/ [20:24] i guess this has never triggered before because the changelog has just been truncated in the place where it contained the reference to CVE-2011-1020 :) [20:24] henrix: The proc filesystem implementation in the Linux kernel 2.6.37 and earlier does not restrict access to the /proc directory tree of a process after this process performs an exec of a setuid program, which allows local users to obtain sensitive information or cause a denial of service via open, lseek, read, and write system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1020) [20:26] ah, OK. Can you please add in your findings to the bug? [20:27] sure. will do that in a minute [20:27] I can then move it from failed to passed, and open a task for the QRT [20:27] sounds good to me [20:27] bjf ^ [20:30] adam_g: it is if you are wanting to test a more recent upstream vanilla kernel. If you want to try the latest Quantal in Precise, use the ubuntu-x-swat/q-lts-backport PPA [20:32] hggdh: comment added. let me know if you want more details [20:32] henrix: will do [20:47] henrix: tag updated, bug 1027821 is ready to resume work [20:47] Launchpad bug 1027821 in linux "linux: 2.6.38-15.65 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1027821 [20:48] hggdh: great, thanks. and this means EOD for me ;) [20:48] henrix: boas noites [20:49] hggdh: heh, ate amanha :) [21:55] should the rtc driver for a platform's rtc be statically linked normally? debugging an issue w/ highbank where system clock at boot is the epoch - looks like the rtc driver is a module, and not in the initramfs [21:56] (manual hwclock -s works fine later)