[01:07] <lifeless> would love advice on upstream acceptance for my fix for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733
[01:07] <ubot2> Launchpad bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,Confirmed]
=== kamal1 is now known as kamal
[06:13] <BenC> lifeless: have you sent it to the dmraid/mdraid maintainers/lists?
[06:35] <lifeless> BenC: I was told that dm-devel is the relevant list, and yes - I linked to the post in my last comment to the bug
[06:35] <lifeless> BenC: so far (~1week) no comments/replies/nada
[06:36] <BenC> lifeless: I think linking to a bug report is not something most people will follow through on
[06:37] <BenC> lifeless: Have you sent a patch upstream?
[06:44] <fdr-> 'allo all. I'm a noob to kernel hacking and am trying to hack something into the memory manager, but don't quite know how to get my test cycle sorted out.
[06:45] <lifeless> BenC: I have, thats what I just said
[06:45] <BenC> Sorry, my mistake
[06:45] <lifeless> BenC: in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733/comments/16 I state that I've sent it upstream, and reference the url of the mailing list archive copy of the post I sent.
[06:45] <ubot2> Launchpad bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,Confirmed]
[06:46] <lifeless> BenC: no worries, must be awfully late for you.
[06:47] <BenC> Quite
[06:47] <lifeless> fdr-: What do you mean ?
[06:47] <BenC> lifeless: You may get a better response if you send it inline so it's not an attachment…send it as an actual commit email
[06:48] <lifeless> BenC: ah, really? I use gmail, so it will get line ending mangled doing that
[06:51] <BenC> lifeless: Configure a local ssmtp to use smtp.gmail.com and 'cat 0001-*.patch | sendmail dm-devel@….'
[06:51] <BenC> It's what I do at least
[06:53] <BenC> lifeless: You may also want to check your style conventions…use \t instead of 8 spaces
[06:54] <BenC> Believe it or not, these simple things will get your patch ignored by the people you really want to look at it
[06:56] <mjg59> git send-email will DTRT
[06:57] <abogani> DTRT?
[06:57] <diwic> Do The Right Thing?
[06:57] <mjg59> Yes
[06:58]  * BenC doesn't have a git send-email
[06:59] <diwic> BenC, sudo apt-get install git-email
[07:00]  * abogani needs coffee 
[07:12] <ppisati> moin
[07:28] <lifeless> mjg59: thanks
[07:48]  * smb tries to have coffee
[07:56]  * ppisati -> should get some more too
[08:06] <RAOF> Hey git geeks! Say I wanted to rebase a tree on a newer upstream tree, but that newer upstream has a commit that reindents (with a script I have access to) every file in the tree, so every single change is all conflicts.
[08:06] <RAOF> This sounds like something that there might be an obscure git tool to make less mindbogglingly painful.
[08:07]  * smb tries to think hard ...
[08:08] <smb> hm, there was something about ignore-space-change...
[08:10] <ppisati> git apply -C1 --ignore-space-change ...
[08:12] <smb> Yeah, not sure git merge can take the same... optionally I would git format my changes on top, then reset --hard and git am with -C1 and --ignore-space-change...
[08:13] <ppisati> and have a lot of fun... :)
[08:13]  * ppisati is looking for a netbook with a backlit keyb, but it seems it doesn't exist at all...
[08:14] <smb> ppisati, I definitely had when trying to cope with some patches coming from some arm vendors (when I had to)... :)
[08:14] <RAOF> And presumably --ignore-space-change won't actually fix the indentation on the *new* code.
[08:15] <RAOF> A mere 87 commits to rebase!
[08:16] <smb> RAOF, Hm, if I read the man correctly new lines would be "wrong" (like in the patch)
[08:19] <RAOF> I guess I could do one pass as --ignore-space-change, and then a second pass fixing the indentation.
[08:23] <RAOF> Bah, and it only ignores whitespace in the context lines, which is insufficient.
[08:45] <caribou> apw: ping
[08:51] <apw> RAOF, i would git format-patch the patches, apply the same algorithm to the patches, and then reapply them
[08:51] <apw> caribou, hi
[08:52] <RAOF> apw: Fiendish!
[08:54] <apw> RAOF, and then demand beer from the culprit
[08:55]  * RAOF wonders if indent handles diffs
[08:56] <apw> RAOF, hmmm, not sure, you would probabally need to 'move' the prefix off (perhaps to the end of the line) and then use it, then move them back, its going to be painful
[08:56] <caribou> apw: good morning how are you doing ?
[08:56] <apw> caribou, fine thanks, you ?
[08:56] <caribou> apw: I'm fine thanks. Trying to get people to understand why it is useful to upgrade to new kernels
[08:57] <caribou> apw: http://caribou.kamikamamak.com/2012/06/12/lucid-panics-after-208-days-dont-get-biten-by-that/
[08:57] <caribou> apw: any luck in building the ddebs ?
[08:57] <apw> caribou, heh if they cannot work out why they need securiyt one should not be doing business with them
[08:57] <apw> caribou, same place
[08:57] <caribou> apw: ok, I'll go fetch them, thanks a bunch
[08:59] <caribou> apw: I call this the Microsoft syndrome : people have been bitten so often by M$ telling them to upgrade systematically that they're worried to do so
[08:59] <apw> heh ... "thanks a bunch" is a negative construction :)
[08:59] <apw> caribou, yeah i can believe that
[08:59] <caribou> apw: coming from a french canadian you should expect those bizzareries ;-)
[09:00]  * smb feels that apw can find a negative in anything if he wants to
[09:00] <apw> caribou, heh thats why i assumed it was positive regardless ... but a common 'continental language native speaker' error indeed
[09:00] <apw> smb, heh, no but sarcasm allows everything to be so, and our langage was built for it
[09:02] <smb> apw, exactly and "if he wants to" specifically targets the relationship between mood and sarcasm seen ;)
[09:40]  * cking contemplates buying an Lenovo X230...
[10:24]  * cking finally does his belated laptop refresh
[14:57]  * ogasawara back in 20
[15:01] <manjo> henrix, any luck with gustavo ? 
[15:01] <henrix> manjo: nop, didn't got any answer from gustavo
[15:02] <manjo> sometimes they are a little slow to respond 
[15:02] <manjo> especially on the mailing list I have had ccing his email 
[15:02] <manjo> I have had better luck .. ^^
[15:03] <henrix> well, i;ll give him a couple more days before ping'ing him again...
[15:06] <manjo> cool :) 
[15:06] <manjo> hopefully you should be able to give him the info he wants to get that patch in 
[15:07] <manjo> funny thing is I have submitted 5 other patches to the same guy and he took it without asking additional Qs except on this one 
[15:07] <manjo> he came back with more Qs once I gave up the HW so I don't have a way to give him the info he wants 
[15:08] <henrix> but do you have any idea what sort of info he's looking for?
[15:09] <manjo> he wanted the output of usb-devices before and after the patch 
[15:09] <henrix> oh, ok.
[15:09] <manjo> I gave him the output after the patch ... did not think he will need one before caz the device won't show up without the patch 
[15:10] <henrix> ok, got it
[15:10] <manjo> so if you can send him that info ie ... output of usb-devices (showing missing device probably) and he might be happy 
[15:11] <henrix> well, the thing is i don't have the hw. i may ask it from a bug reporter, but i couldn't get him to test a kernel yet
[15:11] <henrix> i'll try to get that info
[15:39] <tjaalton> is the queue for 3.2.x at stable@v.k.o or elsewhere?
[15:40] <tgardner> tjaalton, git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[15:40] <tgardner> tjaalton, hmm, could be the incoming queue is elsewhere. herton could tell you.
[15:41] <smb> git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
[15:41] <smb> tjaalton, ^
[15:42] <herton> yep, this is the correct url
[15:42] <tjaalton> smb: yeah, I'm looking where to propose commits to the queue :)
[15:42] <herton> ah 3.2 is different, wait
[15:42] <herton> tjaalton, git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
[15:42] <smb> tjaalton, Proposal rather are done by sending emails to stable@vger.kernel.org
[15:43] <tgardner> see Documentation/stable_kernel_rules.txt
[15:44] <tjaalton> ok thanks, that was the question.. didn't know if 3.2.x used the same list
[15:44] <smb> herton, Oh, right, had not updated my work tree for quite a while it seems... 
[15:48] <herton> smb, tjaalton: the queue is different, since is ben maintaining it now, but everything else continues the same, regarding the stable rules/mailing list
[15:48] <tjaalton> herton: right, thanks
[15:49] <smb> herton, I would have known the queue is wrong if I would have stopped to think a bit longer. :-P  Knowing that Ben has taken over there.
[15:52]  * herton -> lunch
=== vankooch_ is now known as vankooch
=== vankooch_ is now known as vankooch
=== vankooch_ is now known as vankooch
[16:35] <smb`> apw, ogasawara Hm, could it be that the virtual-meta package is messed up somewhat in quantal? Somehow I would expect linux-virtual to depend on linux-image-virtual and not linux-generic...
[16:35] <apw> smb`, no that is right
[16:36] <apw> smb`, you were there when we discussed it!  we split linux-generic so you could use the first half as -virtual and both halves as -generic
[16:36] <apw> and save a build
[16:36] <smb`> apw, I know that, but by depending on the linux-generic meta package, don't you actually pull in both again
[16:37] <apw> smb`, oh you meant to say depend on linux-image-XXX-generic
[16:37] <apw> smb`, that would indeed sound right
[16:38] <smb`> apw, That might be the same result. I had the feeling it was sort of stacked linux-virtual -> linux-image-virtual -> linux-image-abi-generic
[16:38] <apw> smb`, ahh yes
[16:39] <smb`> apw,  So probably linux-image-extra-virtual should also point to linux-image-extra-abi-generic instead of linux-image-generic
[16:40] <apw> smb`, i think that sounds about right overall yes
[16:40] <smb`> apw, ok, will prepare a patch and send out
[16:42] <ogasawara> smb`: please do, I'll review and apply.  It does look like it's not quite what was intended.
[16:43] <smb`> ogasawara, Right, I sort of feared it may be after the discussion that just came up in the server-team meeting about unnessesary bloat...
[16:45] <apw> smb`, heh they noticed, i am supprised
[16:45] <smb`> apw, apparently 200M is enough for some reason... (not sure it is all because of the modules)
[16:46] <seb128> hi
[16:47] <seb128> I've an issue on precise and I'm wondering if that could be a kernel problem and what infos could be useful to debug it
[16:48] <seb128> often after build "big" packages (glib, gtk, ...) the system starts being really slow
[16:48] <jsalisbury> seb128, I'd suggest opening a bug.  You can run the following from a terminal:
[16:48] <jsalisbury> seb128, ubuntu-bug linux
[16:48] <seb128> it seems sluggish and memory usage seems quite high compared to what it should be
[16:49] <seb128> jsalisbury, well, I would first like to figure if that's a known sort of issue and if that could be the kernel ;-)
[16:49] <apw> seb128, memory usage should be 'full' always ... as the kernel will never empty a page unless it needs it for something
[16:50] <jsalisbury> seb128, And sluggish behavior doesn't sound normal.  Try running top when it is sluggish and see what is consuming the resources
[16:51] <jsalisbury> seb128, and it won't hurt to open a bug.  If it's an invalid kernel bug, we'll tell you so ;-)
[16:54] <seb128> apw, jsalisbury: nothing it showing in top, it's like my i5 ssd was turning to a pentium 3 with 128mb ram after big builds
[16:54] <seb128> then not recovering until power off
[16:54] <seb128> like I had the feeling last time it happened that it was still the same after restart
[16:55] <seb128> I wonder if it's overheating and the cpu is kicking is low frequency mode or something
[16:55] <apw> seb128, collect /proc/meminfo and /proc/slabinfo at boot and when the issue occurs
[16:55] <seb128> do you know how I could check that?
[16:55] <apw> seb128, if its a laptop i'd not be supprised if its heat, is it a lenovo ?
[16:56] <jsalisbury> seb128, if you open a bug with ubuntu-bug, we'll get a copy of your logs.  That will give you a place to add info we request as well.
[16:56] <seb128> apw, it's a dell latitude e6410
[16:56] <apw> seb128, you used to be able to have a temperature gagues on the top bar, bar thats not allowed now
[16:57] <apw> seb128, i've used sensors in the past to collect temperature information
[16:57] <apw> as for cirtain if its tooo hot it will throttle the cpu to protect it
[16:57] <seb128> apw, can I get the CPU state info from the kernel,system in some way?
[16:58] <apw> sensors can get it, you run sensors-detect first to get them working
[17:00] <seb128> apw, jsalisbury: thanks, I will watch for it and open a bug with the infos
[17:00] <seb128> it seems a bit better now
[17:00] <seb128> Core 0:       +48.0°C  (high = +95.0°C, crit = +105.0°C)
[17:00] <seb128> Core 2:       +50.0°C  (high = +95.0°C, crit = +105.0°C)
[17:00] <seb128> that's the sensors infos
[17:01] <seb128> but it might just that looking around and asking on IRC he went back to a reasonable temperature where it was hitting the limit before
[17:01] <seb128> the system seems to have mostly recovered performance while 
[17:01] <seb128> while->wise
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 12th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 19th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:28] <jsalisbury> tgardner, this was just reported: bug 1009553
[17:28] <ubot2> Launchpad bug 1009553 in ubuntu-meta "jeos install oversized" [Medium,Confirmed] https://launchpad.net/bugs/1009553
[17:39] <smb`> jsalisbury, That is just what I was referring to
[17:39] <smb`> jsalisbury, Just sent patch for it
[17:41] <smb`> ogasawara, Please have a good look. I am not sure I did not mess anything up given the time and the speed it was slapped together... ;)
[17:41] <ogasawara> smb`: ack
[17:44] <tgardner> ogasawara, smb`: I don't think it makes any real change, but I'm gonna go have lunch first before I say for sure.
=== tgardner is now known as tgardner-lunch
[17:44] <ogasawara> smb`: my initial thought is that by not redirecting to the generic meta package, we can never drop the virtual meta package from existence
[17:45]  * ogasawara needs to think this through again
[17:47] <smb`> ogasawara, I guess as long as there is some need for a small and bigger install probably not. Not sure whether there would be a way to have different names, virtual just was convenient...
[17:50] <smb`> tgardner-lunch, The main change is for linux-virtual not to depend on linux-generic, the other changes are probably more a subjective matter
[17:51]  * smb` looks for some dinner
=== smb` is now known as smb
[17:53] <BenC> tgardner-lunch: Can you (or someone) process my sub to kernel-team, please
[17:55] <ogasawara> smb: so I think what is needed is rather linux-virtual -> [linux-image-virtual, linux-headers-virtual]
[17:56] <ogasawara> smb: that doesn't resolve my hope to eventually drop the stub virtual meta package, but I believe that at least fixes the issue at hand
[17:57] <cking> tyhicks, I'm seeing large seeks (> 600M) on eCryptfs with xfs as a lower file system run really slowly on 3.4 kernels on some hardware. vmstat shows I/O running at only 340 blocks per second, were as I can write at tens of MB/sec to the lower fs. have you seen this behaviour before?
[17:58] <ogasawara> smb: I'd probably leave the other cross dependency meta package bits in place
[17:58] <ogasawara> smb: I'll send out a proposed v2 of your patch
[17:58] <smb> ogasawara, Right, the description part is not important and the two other dependencies are factually the same as before in the end
[17:59] <smb> ogasawara, ack
[17:59] <tyhicks> cking: What exactly are you doing? Seeking past the end of the file and then writing out data at that position?
[17:59]  * ogasawara is still pondering how to get to a place where I can remove the -virtual meta package entirely and everyone would transition to just -generic
[18:00] <cking> tyhicks, yep, it's the extend-file-random test in the eCryptfs tests
[18:01] <tyhicks> cking: That has always been a bit of a sore spot for eCryptfs performance because it has encrypt pages of zeroes to extend the file. I wouldn't expect it to be nearly that slow, though.
[18:01] <cking> tyhicks, on other H/W it runs significantly faster
[18:02] <tyhicks> cking: Strange. What's common among the hardware showing poor performance?
[18:03] <smb> ogasawara, That could prove quite hard as long as there is generic and generic (but please not too much) and some people for whom size does actually matter... ;/
[18:03] <cking> tyhicks, they are big iron boxes
[18:04] <tyhicks> cking: Do they have bigger than 4k page sizes?
[18:04] <cking> tyhicks, reckon so
[18:04]  * tyhicks thinks
[18:05] <tyhicks> cking: I'm wondering if we have some silly math in ecryptfs_write() that only shows up when PAGE_CACHE_SIZE is greater than 4k
[18:06] <cking> tyhicks, that's a good start, I can try to debug that path tomorrow
[18:07] <tyhicks> cking: Sounds good. Ping me if needed.
=== tgardner-lunch is now known as tgardner
[18:54] <blueyed> Have mainline builds for Precise stopped? I would like to use 3.4.2, but cannot find it on http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:56] <ogasawara> blueyed: looks like it's there, just using the quantal config for the build now -> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.2-quantal/
[19:00] <BenC> ogasawara: BTW, in regards to quantal kernel on precise, it at least works for me on powerpc
[19:01] <ogasawara> BenC: that's good news, I'm still a little gun shy to pull the tigger and upload
[19:01] <BenC> ogasawara: nuthin' to it but to do it
[19:01] <BenC> At least, so I've heard
[19:02] <ogasawara> BenC: hehe, it does work for here me and that's all that really matters right? :)
[19:02] <BenC> It's all about scope :)
[19:05] <cking> quality testing strategy
[19:17] <ogasawara> tgardner: I'm gonna upload linux-meta to get that fix released
[19:18] <tgardner> ogasawara, I'm just in the middle of it
[19:18] <ogasawara> tgardner: sweet, I'll leave it to you then
[19:20] <tgardner> ogasawara, uploaded
[19:20] <ogasawara> tgardner: awesome, thanks
=== BenC_ is now known as BenC
=== BenC_ is now known as BenC
[19:46]  * cking -> EOD
[20:40]  * tgardner -> EOD
[21:32] <thomi> Hi, I'm trying to PXE boot the precise live CD image, and I need to get the kernel to load the graphics drivers earlier. I think the way to do this is to add the appropriate drivers to /casper/initrd.lz but I can't seem to find any documentation on how to do that. Can anyone point me in the right direction?
[21:59] <BenC> thomi: That's a better question for #ubuntu
[21:59] <thomi> BenC: oh ok, thanks.
[22:17] <lifeless> BenC: thanks for your advice last night
[22:17] <BenC> lifeless: No problem…good luck on getting that accepted (no sarcasm intended)
[22:17] <lifeless> BenC: I'll tweak the patch to use tabs - 8 wide spacing, right ?
[22:17] <BenC> Correct
=== martinphone is now known as martinphone_
=== martinphone_ is now known as martinphone
=== martinphone is now known as lacrodde