=== josepht_ is now known as josepht
[08:49] <hrw> hi
[09:01] <hrw> linux/quantal contains debian/stamps/ directory but /usr/src/linux-3.4.0/debian/ from linux-source-3.4.0 does not
[09:01] <hrw> which patch will be more acceptable:
[09:02] <hrw> 1. add 'install -d $(stampdir)'
[09:02] <hrw> 2. add 'debian/stamps/' into linux-source-3.4.0
[09:02] <hrw> ?
[09:13] <hrw> reported as bug 1001172
[09:13] <ubot2> Launchpad bug 1001172 in linux "linux-source-3.4.0 does not contains debian/stamps/ directory" [Undecided,New] https://launchpad.net/bugs/1001172
=== yofel_ is now known as yofel
=== ayan_ is now known as ayan
[13:08] <tgardner> arges, linux-firmware-nonfree accepted into lucid and precise with the Beceem wimax firmware.
[13:08] <arges> tgardner, great. do I need to talk to the archive admins or do verification now?
[13:08] <tgardner> arges, nope, its a done deal
[13:08] <arges> tgardner, cool! thanks a ton
[13:29] <ogasawara> tgardner: can you refresh my memory, I thought there was a script which would help update the lts-backport-<release> branch.  what was it called again?
[13:30] <tgardner> ogasawara, I started the quantal one and pushed to precise
[13:30] <tgardner> looking...
[13:31] <henrix> ogasawara: are you looking for debian.oneiric/etc/update-from-oneiric-master ?
[13:31] <tgardner> ogasawara, ubuntu-precise/debian.quantal/etc/update-from-quantal-master in the lts-backport-quantal branch
[13:31] <ogasawara> tgardner, henrix: thanks
[13:32] <ogasawara> tgardner: was thinking that an additional step to uploading a new kernel to Quantal would be to run that script and shove the resulting backport kernel into the PPA bryceh pointed to
[13:33] <tgardner> ogasawara, I'm thinking Andy's daily build scripts will pick that up.
[13:34] <ogasawara> tgardner: ah, that's even better
[13:34] <tgardner> ogasawara, though I don't think we should turn on that machinery until the meta package and flavour carnage has settled.
[13:35] <cking> tyhicks, ping
[13:35] <tgardner> ogasawara, I'm finishing up with the quantal kernel mess, then I'll do the meta package. should have it all done today.
[13:35] <ogasawara> tgardner: ack
[13:35] <tyhicks> cking: hey - just picking my chin up off the floor after reading your email :)
[13:36] <cking> tyhicks, we could restructure the code so that the fp flags are stashed and restored outside the loop, but I think before I go any further I will contact intel
[13:37] <tyhicks> cking: I had just cracked open the code, so I don't have a good feeling for what is best yet
[13:37] <tyhicks> cking: Contacting intel is probably the thing to do though
[13:38] <cking> tyhicks, yep, will do, and while I am waiting for a response I will tweak the code to see if I can "improve" things ;-)
[13:39] <tyhicks> cking: When you say "outside of the loop", which function are you referring to?
[13:39] <tyhicks> cking: nvm, I see it in aes_encrypt() now
[13:42] <cking> tyhicks, crypto_cbc_encrypt() iterates over the data in 16 byte blocks, and each block wastes cycles doing the kernel_fpu_begin/end calls :-(
[13:43] <cking> it's just a problem to do with the way it has been abstracted
[13:44] <tyhicks> cking: I'm following along now. :) Nice find!
[13:45] <cking> just needed a little bit of digging and some accurate instrumentation
[13:48] <cking> tyhicks, I expect the userspace version of the code rocks because it does not have to mess around with the fpu state, hence the benchmarks on the code look good but nobody has instrumented it in-kernel
[13:48] <tyhicks> cking: Ack - I think you're right
[14:28] <arges> cking, this was it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1000913
[14:28] <ubot2> Launchpad bug 1000913 in linux "K43SA hangs on suspend" [Medium,Incomplete]
[14:32]  * ogasawara back in 20
[15:51] <tgardner> ogasawara, just sent an email explaining Quantal meta package carnage. please review.
[15:51] <ogasawara> tgardner: ack
[15:52]  * tgardner goes back to working on highbank and lowlatency
[16:03]  * ogasawara head just exploaded with meta packages
[16:03] <tgardner> ogasawara, but they are so orthogonal now
[16:06] <ogra_> the heads ? or the explosions ?
[16:17] <cking> tyhicks, it looks like restructuring the code means I add extra overhead to the non arch specific generic code, which is not going to be acceptable. I will see what Intel say 
[16:29] <tyhicks> cking: I'm a bit confused because some of aesni-intel_glue.c seems to be doing the right thing by putting the fpu restore on the outside of the loop
[16:29] <tyhicks> cking: cbc_encrypt(), for example
[16:29]  * cking looks
[16:30] <tyhicks> cking: I'm wondering if eCryptfs flows through a different path than dm-crypt, which may be why dm-crypt benefits from aes-ni
[16:31] <cking> tyhicks, aesni-intel_glue.c saves the fp state, does 16 bytes and restores the fp state
[16:32] <tyhicks> cking: I agree regarding aes_encrypt() in aesni-intel_glue.c, but that doesn't look to be true for cbc_encrypt() in aesni-intel_glue.c
[16:34] <tyhicks> cking: note that there are different drivers in aesni-intel_glue.c
[16:34] <cking> tyhicks, OK - I can see what you are getting at, I will re-examine this
[16:34] <cking> twisty maze of callbacks :-/
[16:35] <cking> [  509.765572] Call Trace:
[16:35] <cking> [  509.765574]  [<ffffffffa05e214c>] aes_encrypt+0x2c/0xf0 [aesni_intel]
[16:35] <cking> [  509.765577]  [<ffffffff812e80ef>] crypto_cbc_encrypt+0xcf/0x190
[16:35] <cking> [  509.765579]  [<ffffffffa05e2120>] ? aes_decrypt+0xf0/0xf0 [aesni_intel]
[16:35] <cking> [  509.765582]  [<ffffffff8126eed3>] encrypt_scatterlist+0xd3/0x1b0
[16:35] <cking> [  509.765585]  [<ffffffff8126f643>] ecryptfs_encrypt_extent+0x103/0x190
[16:35] <cking> [  509.765588]  [<ffffffff8126fc5d>] ecryptfs_encrypt_page+0xcd/0x190
[16:35] <cking> [  509.765591]  [<ffffffff8126d962>] ecryptfs_writepage+0x32/0x90
[16:36] <sforshee> ogasawara, I'm going to send a patch to disable CONFIG_B43_BCMA_EXTRA in quantal as it causes conflicts between b43 and brcmsmac. Do I also need to add a check in the enforcer?
[16:37] <ogasawara> sforshee: that'd be good so we don't accidentally flip it back on.  it also ensure's it get annotated in our config review for why it doesn't adhere to policy.
[16:37] <sforshee> ogasawara, ack. Guess I get to learn how to write enforcer rules :)
[16:42] <tyhicks> cking: Ok, so the question is how to get the crypto api to give us the "__driver-cbc-aes-aesni" driver rather than the "aes-aesni" driver
[16:43] <cking> tyhicks, that's what I'm trying to figure out right now, it's most curious
[16:44] <tyhicks> cking: The "aes-aesni" driver has a higher priority value, so it would obviously be selected first... but is it supposed to then use the "__driver-cbc-aes-aesni" driver if aes with cbc is used? Hmm...
[16:44] <cking> looks iffy to me
[16:48] <tgardner> tyhicks, cking: isn't some of this link order dependent? the most CPU specific drivers are supposed to register first.
[16:49] <tgardner> IIRC thats why we started building them in
[16:49] <tyhicks> tgardner: Yeah, that's right. But the highest priority driver for the aesni-intel code does the wrong thing. :)
[16:50] <tyhicks> tgardner: Then there's a lower priority, generic software-based driver that is next in the priority list. Then, there's *another* aesni-intel driver that is priority 0, but it does the right thing.
[16:50] <cking> unless I shove a load of debug in, it really is unclear to me at the moment why it is doing the wrong thing
[16:51] <tgardner> I assume you've looked at how dm-crypt registers ? (just flapping my gums here)
[16:51] <cking> that's a worthy point to pursue
[16:52] <tyhicks> tgardner: It has been a while since I've looked at that. But the way that one registers is just by registering the "cbc(aes)" driver. The crypto api is supposed to be smart enough to pick the best option.
[16:52] <tgardner> right,, thats what I remember
[16:52] <cking> evidently it isn't
[16:53] <tyhicks> cking: From your analysis, what it supposed to be the best option may just be poorly written :)
[16:53] <tyhicks> (or just a victim of a code refactoring that screwed things up)
[16:54] <cking> indeed, it's getting late in my day and I'm still foggy a bit from jet lag, so I will focus on this next week 
[16:54] <cking> i'm sure it be very evident once I work through the code methodically
[16:54] <tyhicks> cking: Understandable. I'll try to take a closer look in a couple hours. I'll email you if I come across anything useful.
[16:55] <cking> cool
[16:55] <cking> gotta go
[16:55] <tyhicks> bye cking
[16:55]  * cking -> EOW
[17:04] <sforshee> ogasawara, does this look right? seems to trip the config enforcer at least
[17:04] <sforshee> # Ensure CONFIG_B43_BCMA_EXTRA is disabled if CONFIG_BRCMSMAC is enabled. 
[17:04] <sforshee> # Otherwise b43 and brcmsmac will overlap in the hardware they claim to 
[17:04] <sforshee> # support. 
[17:04] <sforshee> (!exists CONFIG_BRCMSMAC | value CONFIG_BRCMSMAC n) | \ 
[17:04] <sforshee> ((value CONFIG_BRCMSMAC y | value CONFIG_BRCMSMAC m) & (value CONFIG_B43_BCMA_EXTRA n | !exists CONFIG_B43_BCMA_EXTRA)) 
[17:04]  * ogasawara parses
[17:06] <ogasawara> sforshee: looks correct
[17:07] <sforshee> ogasawara, thanks! I'll send the patch after lunch.
[17:07] <ogasawara> sforshee: ack
=== tgardner is now known as tgardner-lunch
[17:43] <hggdh> tgardner-lunch: when you are back -- I have been getting hardlocks on my laptop (precise, realtek SE wireless). Seems to be the realteck, and I have the backports-cw package installed
[17:44] <hggdh> tgardner-lunch: Pete asked me to ping you, it seems you would have a more up-to-date package to test
=== tgardner-lunch is now known as tgardner
[18:01] <tgardner> hggdh, I've been runnign the Quantal kernel. seems to be working OK
[18:17]  * bjf has swapped out
=== bjf is now known as bjf[swapped]
[18:19] <hggdh> tgardner: I will upgrade to quantal, then and try. Thank you
[18:19] <tgardner> sforshee, why don't we blacklist b43 instead of not building it ? It may still work well for some folks (or be their preferred option).
[18:19] <tgardner> hggdh, you don't have to upgrade completely. we'll have a PPA soon from which you can pull the Quantal LTS backport kernel
[18:20] <hggdh> tgardner: ack, I will wait, then. Thank you again :-)
[18:20] <tgardner> hggdh, in the meantime, you could pull the linux-image deb from the archive and install it by hand to see if it works any better.
[18:20] <hggdh> roj. Even better, I can check on it now
[18:36]  * ogasawara lunch
[20:36] <tgardner> ogasawara, I'm guilty of hoarding my bits, pull quantal master-next again
[20:36] <ogasawara> tgardner: ack
[20:39] <tgardner> ogasawara, also just pushed precise lts-backport-quantal. I'll finish it up next week when next you upload. waiting on a response from Michael Vogt to make sure we've not dome something we can't recover from.
[20:39] <ogasawara> tgardner: ack
[20:41]  * tgardner -> EOD