=== kamalmostafa is now known as kamal === nickde is now known as Guest69444 [06:01] Oh, bah. Stupid broken mainline builds. [06:55] * smb crawls in [07:15] * RAOF waits to ambush apw. [07:15] RAOF, He probably saw that. :) [07:16] smb: I know. You need to properly prime the target for a psychological ambush. [07:17] Giving time to don all armor does not seem like a good move before attacking... :-P [07:18] No. Now, apw will dread the moment he needs to say something in #ubuntu-kernel, premtively flinching for the pile of work that will be dropped upon him! [07:18] Reminds me of the rumors about a 24hrs notice before committing a crime to the victim (unverified to be thought of or done in TX) [07:20] RAOF, On the "good" side, we should have a whole bunch of QA analysts in London this week. :-P [07:20] Ah, really? What sprint's happening there? [07:20] Something with QA [07:21] CoP and DA [07:21] wth [07:59] morning [08:08] ppisati: morning [09:21] * smb wonders into which hole apw fell... [09:25] apw: Could you give the drm-intel kernel builds a kick? I'm mainly interested in 1519b9956eb, ed10fca9c351c83, and de842eff410. [09:29] RAOF, will have a look [09:29] smb, in the office is all [09:31] apw, Ah, that explains mumble (and the general silence as there is probably a queue of broken laptops as usual) [09:31] heh :) === Guest15357 is now known as lag === lag is now known as Guest98318 === yofel_ is now known as yofel === nickde is now known as Guest47227 [11:44] does anyone know how to include some custom files in the linux-headers package after building a kernel with ubuntu-package ? I have some extra .so files build under tools/gcc (gcc plugins) but they don't get included in the headers .deb so I have to move them from the build dir manually after installing it. How can I include them in the package? [11:46] * ppisati -> out to get some foood [12:50] apw, hi [13:16] hi all [13:16] am trying to build 2.6.38-omap kernel (ubuntu natty) [13:16] for Touchscreen support (ads7846) [13:16] And downloaded the source code from ubuntu [13:17] but while doing menuconfig , this driver is not visible [13:17] then I have added this driver manually in .config [13:17] but its not building the module [13:18] any one can tell me where am wrong ? [13:20] http://paste.debian.net/126389/ [13:20] my .config file is there [13:22] siji, When you use the ubuntu source you should do a "debian/rules editconfigs" That modifies the config in debian.ti-omap4 which is used for the builds [13:26] smb, if am building only specific module then ? [13:26] same method have to follow ? [13:32] siji, Not exactly. But on the other hand it might be better to do complete builds because that gives you a package to install which can have a unique version number, too. Also it makes sure the module version matches up with the rest of the kernel. But I know that at least building on arm is not that quick [13:33] sconklin, herton: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813026/comments/2 [13:33] Ubuntu bug 813026 in linux "CVE-2011-1020" [Undecided,Fix committed] [13:34] ya i got your point , cose of the time am trying to build only the module [13:36] tgardner: hmm ok, may be we have to revert the fix on lucid and everyone else. I'll mark the tracking bug with the regression found [13:36] herton, I pushed the revert for Lucid. I don't know that its required on newer kernels. [13:37] ok [14:17] tgardner: maverick-proposed needs the revert as well, bug 827198 [14:17] Launchpad bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,Confirmed] https://launchpad.net/bugs/827198 [14:17] jwi, noted.\ [14:19] I guess 827208 & 825207 are dups [14:23] jwi, hmm, dunno about 825207. its possible. [14:33] tgardner, did i break it [14:33] tgardner, and if you are reverting, be nice if they are Reverts: [14:34] apw, it certainly did on Lucid. still working on Maverick [14:41] tgardner, bah ... [14:42] apw, I had a clean bisect on Lucid, so I'm reasonably sure its the right commit. [14:43] tgardner, fair enough indeed. i'll have to test that the reverts do the right thing [14:44] apw, lucid master-next has the revert. I built that kernel as well as the bisect kernel with that reverted. both fixed the lockup. [14:46] tgardner, sheet ... will have a look [14:59] ## [14:59] ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting [14:59] ## [15:00] tgardner, apw: hardy update has the same cve fix, because of the regression we put it on hold now (bug 823912) [15:00] Launchpad bug 823912 in linux "linux: 2.6.24-29.93 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/823912 [15:01] herton, does chromium even run on Hardy ? [15:02] tgardner: no idea. is this specific to chromium, or more a general issue? [15:03] herton, its likely generic, but chromium appears to be the most commonly used reproducer. [15:15] * ogasawara back in 20 [15:35] ogasawara: is it normal makedumpfile fails on the ubuntu-p kernel? i had to set no_dumpfile=1 to build it [15:36] Sarvatt: I had to do the same. it appears makedumpfile doesn't like the newer kernel version, but I haven [15:36] 't dug much deeper into it [15:53] maint-startnewrelease is failing for me [15:53] http://pastebin.ubuntu.com/667427/ [15:54] i think it cannot find linux-image-3.0.0-1201-omap4_3.0.0-1201.5_armel.deb [15:54] any way to force it? [15:54] (got a new BSP update from agreen so so i was rebasing...) [15:54] ppisati, can you just run 'fdr startnewrelease' ? [15:55] tgardner: good idea :) [16:10] sforshee, awesome work on alps! [16:10] cnd, thanks! [16:11] I want to ask you about your possibilities for reporting [16:11] still got a lot of work to do to get everything in shape [16:11] I think I understand what alps is reporting [16:11] and I understand option 1 [16:11] but I can't figure out what option 2 is [16:11] could you restate it? [16:12] so you understand that the projection of a touch point could set multiple bits in each of the bitfields? [16:12] yeah [16:12] I could estimate the width by counting the number of bits that are set [16:13] and estimate the touch point to be in the middle of the range of set bits [16:13] does that make more sense? [16:13] you could do that if there's only one touch [16:13] but what if there are multiple? [16:14] then there are multiple groupings of set bits, as long as the fingers aren't too close together [16:14] yeah [16:14] if they are too close together, I have to do a little guessing, like assuming the contacts are of equal size [16:15] oh, I think I see what you are saying [16:15] I know how many contact points are represented in the bitmaps [16:15] you'll try to figure out the center positions [16:15] and the widths [16:15] yep [16:15] and that's how it's different than option 1? [16:15] yes, for option 1 I'd only take the extremities and use that to create points for a bounding box [16:15] ok [16:16] sforshee, what do you get with three touches? [16:16] do you get three sets of X and Y bits set? [16:16] potentially up to three, that is [16:16] I still need to experiment with that, but that's my assumption [16:17] ok [16:17] I think any bits that are "covered", so to speak, will be set [16:17] yeah [16:17] that makes sense [16:17] so how to report that best... [16:18] sforshee, I think you should use SEMI_MT [16:18] and report only the min and max X and Y values [16:18] but try to get the "center" of the extreme bits [16:18] so option 1 then? [16:18] ah, halfway between 1 and 2 [16:18] yeah [16:19] so if you have an X axis like: 00110000111000 [16:19] if I'm doing that work I might as well report width though, as I'll already have it [16:19] then report half way between the first two '1's and in the middle of the second group of '1's [16:19] sure [16:19] well... [16:19] actually, I wouldn't [16:19] because of the tricky aspect of SEM_MT [16:19] you don't know which bits correspond to which touches [16:20] if you have two groups in both the X and Y directions [16:20] you don't know if the touches are in corners 1 and 3 or 2 and 4 [16:20] yes, that's true, unless I'm able to figure it out from the absolute position data in the first packet, but I'm still unsure about that [16:21] and evdev reports widths in a circular sense, so unless you can match up the X and Y directions the widths may not be correct [16:21] yeah, I wouldn't try to figure it out [16:21] okay, makes sense [16:21] that's too much to be doing in the driver [16:21] at least at first :) [16:21] and userspace could potentially do it [16:21] though width values couldn't be calculated after the fact in userspace [16:22] but as soon as you go from two to three touches, then you're screwed [16:22] all right, that's what I'll do then [16:22] thanks! [16:22] you could match up one position [16:22] but you don't have enough info for the other two [16:22] sforshee, I'm so glad we're getting alps going! [16:22] yeah, it would only work for 2 fingers anyway [16:23] cnd, I'm not sure what's going to happen when we start trying this on more hardware though [16:23] the initialization is still pretty opaque [16:23] sforshee, when you report values, I would linearly multiply the low-res stuff up to the high-res range [16:23] it may not be right for all hardware of this type [16:23] yeah, that was my plan [16:23] so it's the same range between ABS_X and ABS_MT_POSITION_X [16:23] yeah [16:24] sforshee, I would suggest making a dkms and trolling for testers in one of the ALPS bugs on LP [16:24] will do [16:24] they're like a honeypot, and you'll be treated like a king :) [16:24] you'd think, but I've only had a few testers for the elantech stuff [16:24] really... [16:25] that surprises me [16:25] me too [16:25] people are happy to complain, not so happy to test it seems [16:25] did elantech have anything better than PS/2 emulation? [16:25] before you worked on it? [16:25] not for the third-generation of their hardware [16:26] k [16:26] I'm going to send those patches to linux-input in the next couple of days [16:27] awesome! [16:27] sforshee, please CC me when you do [16:27] not a big deal if you forget though [16:27] I'll try to remember :) [16:27] I'm subscribed and I'll see them one way or another [16:50] ## [16:50] ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting [16:50] ## [16:59] meeting's about to start ... [17:02] ppisati: There were a few server arm issues raised last week.. are you the contact for that? [17:02] Daviey: ah, the lxc stuff? sorry, i just came back from vacation [17:03] Daviey: i'll queue it up for the next arm report [17:03] btw, my usb stopped working... cool... [17:03] ppisati: There was iscsi support being missing aswell, which was a concern [17:03] Daviey: stefan had lxc running on an arm kernel at the sprint [17:03] jjohansen: Oh great! via libvirt? [17:04] jjohansen: yep, he told me but i forgot to say it in the report :P [17:04] he said the kernel was good but there where some user space issues [17:04] eek, i should have kept quiet [17:04] Daviey: I don't think it was via libvirt [17:08] Not sure what lxc-tools using [17:08] Stephane was the one doing the user-space side [17:08] smb: yep [17:08] And as far as I know the issues there are resolved [17:09] hrmm, well hopefully, though I that he was using lxc-exec instead of lxc-start [17:09] but I could be wrong [17:10] Hm, thought both [17:10] sconklin: going forward for the meetings, would you prefer to just combine the "Status: Stable Kernel Team" and "Security & bugfix kernels" topics? [17:10] last time i check, lxc-config (??? don't remember the name of the user land tool that checks lxc kernel compatibility) complained about a deprecated option [17:10] Cause he pulled in a whole chroot env [17:10] smb: oh maybe, I remember catching the bit about lxc-exec and then finding some of the problems so by the end maybe [17:10] s/check/checked/ [17:11] smb: ah I missed that [17:12] ppisati, When we tried (with some other options enabled) there was only config_cgroup_freeze missing [17:12] and the userland tool crashed [17:12] because of a personality check [17:12] ogasawara: yeah, there's no sense in breaking out a one-line link as a separate agenda item [17:12] sconklin: agreed. [17:13] smb: uhm ok [17:13] bjf: ^^ might want to update your runes file for the meetings... [17:13] ppisati, Well anyway, next kernel should be ok and lxc tools saw several uploads last week :) [17:14] Beside of running with one cpu was faster than with two, things looked promising so far... [17:15] smb: the smp looks really nasty [17:15] smp bug [17:15] * ppisati is really tired... [17:15] * smb nods [17:15] ppisati, And all the useful tools seem to be missing on arm [17:15] Like perf or latencytop... [17:16] that's not fun [17:18] ppisati, Someone (jjohansen you remember his name? rob something?) noted that cache invalidation may be a problem... [17:19] smb: imo it could be everything [17:19] smb: from affinity, to timers, to $whatever... [17:20] * smb thinks we need someone with a jtag and not being afraid to use it [17:20] smb: no I don't remember but he was the Calxeda guy [17:20] i've jtag and i know how to use it [17:21] he said that the smp cache snoop/invalidate on A8 and A9 where extremely slow [17:21] jjohansen, Rob Herring ? [17:21] Could be. At least I think I remember the Rob part [17:22] yeah I think that was it [17:22] yep, it was [17:24] ppisati: one way you could test that theory is do some parallel compute, and for one test make sure its hitting different areas of mem/cache alignment and for another shared data [17:25] * jjohansen doubts that the slow cache is the responsible for the problem [17:26] it's one of those bugs that you need to figure out a way to exercise it and then use JTAG to see what's really going on [17:26] jjohansen: sounds like a time-attack [17:27] ppisati: yeah [17:27] imo it's something simpler but yes, trimming it down to the simplest case is the first step [17:28] so i can follow the code/call path and see what's different in the single vs dual cpu case [17:29] Though the hdparm run is quite simple, I guess there is still multiple things involved [17:30] yep [17:38] uhm [17:39] but if the bug is still there even when a cpu is hotplugged, how can it be an smp scheduling bug? [17:39] ppisati, I was suspecting the way or what timers are used [17:40] a good trace could be to see what's the difference between single cpu and smp-with-one-cpu only [17:40] Even when hut-unplugging one cpu, it is different from what is used when starting only with one [17:40] yep, but nothing is scheduled on the second cpu [17:40] right [17:40] because it's not there anymore (modulus bug) [17:41] well /proc/interrupts does look different (in the ipi section) [17:41] which still shows two entries... [17:42] ah [17:48] Is it possible to use virtualbox or any other vm tools to boot entire SATA drives in a VM? I have a machine with a swappable SATA drive bay, and I'd like to be able to boot entire test disks [17:48] anyone know? [17:54] sconklin: look for pci device passthrough for kvm [17:54] jjohansen: thanks [17:54] sconklin: I know its possible just haven't done it myself [17:55] That's just the kind of pointer I was looking for [17:55] sconklin: I did do it years ago with vmware so I know its possible there too [17:55] Yeah, I'm done it with VMWare in the past [17:57] have you tried: qemu -hda /dev/hdb [17:57] er.. [17:57] sconklin: http://www.virtualbox.org/manual/ch09.html#rawdisk indicates its possible with virtualbox, too. [17:57] have you tried: qemu -hda /dev/sdb [17:58] haha typical Linux "there are three ways to do it" response. Thanks! [17:59] sconklin: hehe, you get to pick your poison. :-) [17:59] sbeattie: Oh, I like any option that warns me about total loss of data in a Big Red Box! [18:00] herton, the mystery deepens: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/827198/comments/4 [18:00] Ubuntu bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,In progress] [18:01] * tgardner is back in an hour or so === tgardner is now known as tgardner-afk [18:02] tgardner-afk: strange indeed [18:05] sconklin: from #qemu: balrog-k1n: i've done something like this many times, but usually added -snapshot to avoid the VM writing to the physical disk [18:06] CarlFK: ok, I'll check that also [18:06] thanks [18:07] welcome [18:25] tgardner-afk: checking here commits, I suspect we need also "76597cd proc: fix oops on invalid /proc//maps access" backported to maverick and others [18:39] I'm starting to sense something fishy with kernel-package's `make-kpkg` in 11.04. The headers package it generates is behaving inconsistently. [18:55] * ogasawara lunch === Guest98318 is now known as lag === lag is now known as Guest67514 === tgardner-afk is now known as tgardner [19:36] herton, while we may need 76597cd, I'm not sure its related to the chromium hangs. [19:40] sforshee, fuuuuuuuuuuuuuuuuuu [19:40] more 1 year to solve the bug :( [19:40] +1 year* [19:41] anyone happen to know how to parse the MODALIAS strings in the output of udevadm info --export-db? [19:41] tgardner: indeed. but other guy came in the bug reporting a oops that I think 76597cd will fix. I think would be worth giving them a test build with it, and we should have that backported anyway [19:41] herton, ack. [19:42] mfilipe, every time there's a patch that fixes it something else gets broken, and that's a big part of why it's taken so long [19:43] herton, ok, I'll have a look at backporting that commit and getting some test kernels advertised. [19:44] ok, cool [19:47] sforshee, thanks again for you effort to fix the problem but I think that it will get some months again :( [20:01] ogasawara, you might as well clone P into the ubuntu directory on zinc. that way we won't have to change [20:01] sources later [20:25] tgardner: ack [21:01] rebooting === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan [23:33] hello is there anyone that can explain me this? [23:34] man 3 va_end in /va_dcl [23:35] apw, can you help me? [23:45] is there anyone there? [23:45] txomon, past EOD for most kernel folk I think [23:46] Its about a strange C syntax, that I can't understand.. [23:46] do you know what it means? [23:47] !EOD [23:47] Factoid 'EOD' not found [23:48] bryceh, do you know what it means? [23:50] txomon, "End of Day" i.e. they're not in work hours [23:51] ah xD ok ty [23:54] most kernel guys are in US or European time zones [23:55] txomon: va_end is weird [23:56] txomon: what are you looking for? [23:57] im looking for the meaning of that va_dcl there in the middle [23:58] C syntax