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