[07:41] <apw> smb, morning ... this amd quirk, can you remind me of the bug for that one
[07:43] <ricotz> apw, hello, could a patch like this be considered for inclusion? https://patchwork.kernel.org/patch/244201/
[07:45] <apw> ricotz, is the patch upstream yet?  and in part the answer depends on where you are looking to put it
[07:47] <ricotz> apw, this patch isnt upstream, and the current natty kernel (38rc6) breaks the usage of my dvb card, including this patch solved it for me
[07:49] <apw> the patch doesn't claim for fix anything, just speed things up ... so thats a little unexpected
[07:49]  * apw drop for a few mins
[07:51] <ricotz> apw, yes, the current driver gives me timeouts when switching channels/transponders mostly everytime, so this "speed-up" patch solved it for me
[09:28]  * apw sighs ... 
[09:29] <cking> wassup?
[09:29] <cking> more plumbing probs?
[09:29]  * cking has to reboot
[09:29] <apw> heh ... no this is the 'fix' for the problems
[09:30] <cking> ah
[09:30] <apw> but the plumber was late, so i was waiting around like a lost puppy
[09:30] <smb> apw, Though we thought they *had* been fixed already
[09:30] <cking> that are a law to themselves
[09:30] <apw> no _i_ bodged it till it could be fixed
[09:31] <smb> Hm, old plumbers law: first it bodges then it comes off
[09:42] <apw> smb, something like that :)
[10:36] <ara> Hello all!
[10:37] <ara> does the regression found in the -proposed kernel for ec2 invalidates this kernel in -proposed?
[10:37] <ara> https://bugs.launchpad.net/bugs/723335
[10:37] <ubot2> Launchpad bug 723335 in linux "linux: 2.6.35-27.48 -proposed tracker" [Medium,Triaged]
[10:37] <ara> apw, ^ ?
[10:38] <smb> ara, Hm, is that another one than bug 725089?
[10:38] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[10:38] <ara> smb, no, that one
[10:38] <ara> smb, the one above is the tracker, the bug is the one you mention
[10:38] <smb> ara, I will try to get to the bottom of that today
[10:39] <ara> smb, cool, if the regression is confirmed, then the linux (not linux-ec2) package will also be dropped?
[10:39] <smb> I looked at it on Friday and was not sure what could have caused it. Actually it seemed that the kernel before that may already have been causing issues
[10:41] <smb> ara, Unfortunately for Maverick there is no ec2 package
[10:41] <apw> smb, so would that be -virtual which has failed then ?
[10:41] <smb> We use the virtual image generated from the normal linux package
[10:41] <smb> In some way yes.
[10:42] <smb> But I am not sure one can fail virtual without failing the main package.
[11:07] <apw> smb, indeed if -virtual is toast they all are
[12:31] <nusch> I'm trying to examine some regression with alsa or kernel, what is fastest way of finding it, shoud I install different kernels from packages or compiling from source? I read it can be done with git bisect but could I use git with ubuntu kernels compiled like this https://help.ubuntu.com/community/Kernel/Compile? Or should I use this method  https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[12:41] <apw> nusch, i would start by picking the pre-build kerenls from launchpad
[12:42] <apw> to narrow it as much as possible, then probabally try the mainline builds for finer bisection in between
[12:42] <apw> nusch, which release as this appeared and when?
[12:47] <fairuz> dma_addr_t dma_map_single (struct device * dev, void * cpu_addr, size_t size, enum dma_data_direction dir);  .. is cpu_addr a physical addr?
[12:49] <apw> fairuz, looks like a kernel virtual addy to me
[12:51] <nusch> apw: I'm talking about this bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009 and somebody already found this was broken between 2.6.33  and 2.6.35
[12:52] <ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
[12:52] <nusch> so I wanted to examine it deeper
[12:52] <apw> nusch, so i would seee if .33 and .35 mainline builds show the same pattern
[12:52] <apw> and then use the -rc builds in the mainline archive to find a finer location
[12:52] <apw> quicker than building ones own
[12:53] <nusch> Could you provide m with some details how to do that?
[12:53] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[12:53] <apw> that has the docs on where to find them and how to instal them etc
[12:56] <nusch> ok and should I install also new alsa package like this from ppa linux-headers-alsa-driver-2.6.35-25-generic with kernel version included or get rid of it and use standard ubuntu ones ?
[12:57] <apw> i'd not expect the headers to make any difference to a sound issue
[12:57] <nusch> sory I meant linux-alsa-driver-modules-2.6.35-25-generic
[12:58] <nusch> those are from ppa:ubuntu-audio-dev/ppa
[12:58] <apw> well that only applies to 35-25, so as long as you arn't booting that you won't be using it
[13:00] <nusch> I'm saying about whole set of packages from ppa:ubuntu-audio-dev/ppa which has version number included in name, so It will need installing new alsa with every kernel, or should I uninstall it and allow system use standard packages
[13:00] <diwic_afk> nusch, when you're git bisecting, make sure this package from ubuntu-audio-dev is NOT installed.
[13:01] <apw> if you are looking for a general bug in the kernel, you don't want any unecesary packages like that
[13:01] <apw> they just add variables you don't need
[13:01] <nusch> But I'm not sure the problem exists in kernel or alsa modules
[13:02] <apw> well from a kernel point of view, it includes alsa, and its that one we care if it works or not
[13:03] <nusch> ok thx, I'll inform you after testing
[13:05] <jk-> apw: any thoughts on the baseCommitRegex stuff?
[13:07] <apw> ?
[13:07] <apw> jk-, where?
[13:07] <jk-> kernel-team
[13:08] <smb> apw, In those rfc mails you tend to ignore ... ;-P
[13:08] <apw> nthing with that in the title
[13:08] <jk-> [RFC, PATCH 0/2] UBUNTU: lucid: allow printchanges to accept varying release commit messages
[13:08] <jk-> smb :)
[13:09] <smb> jk-, Not that I did much more response. I think the only thing I had was that if we start to change it should be Natty and then potentially go back, but that was already said
[13:09] <apw> well i don't see any inherant issue with them, though what form are you using thats not being picked up
[13:10] <jk-> smb: yeah, that's fine; I was starting with lucid because that's the kernel I was most recently working with
[13:11] <jk-> apw: "UBUNTU: (Release) 2.6.35-6.11 for <project>"
[13:12] <apw> so if you used "UBUNTU: <project> release 2.6.35-6.11" it would work as it is
[13:12] <apw> so if you used "UBUNTU: <project> release Ubuntu-2.6.35-6.11" it would work as it is
[13:13] <jk-> I'll check with Ike about why he's used the different format
[13:16] <apw> jk-, but overall nothing bad in there.  i've replied as such and mentioned the flexibility we do have with the current pattern
[13:16] <jk-> apw: ok, cheers. I'll sort out our commit conventions and get back to you
[13:20] <apw> jk-, it doesn't seem like a bad change overall ... the branch specific file could be useful without your use
[13:20] <apw> might simplify some of our existing stuff
[15:48] <_ruben> any clues on how i could persue this issue: http://pastebin.ubuntu.com/573509/ .. apparently using "local my.ip.ad.dr" when creating a sit tunnel "breaks" the link local (/128 instead of /64)
[16:29] <smb> sconklin, Hm, I found one line on irc from Thursday where jj mentions regressions for Lucid and Maverick. But not which those are. I cannot remember anything about Lucid (beside some load accounting problems maybe which seem to come and go). But we should ask him when he comes online.
[16:29] <sconklin> ok, thanks!
[16:30] <sconklin> by the way all - high winds and bad wx here, so if I drop offline that's why
[16:50] <JFo> bjf, you have likely noticed by now, but I got your nominations done on bug 723945
[16:50] <ubot2> Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945
[16:50] <bjf> JFo, heh, thanks!
[16:50] <JFo> bjf, my pleasure
[17:03] <smb> jjohansen, Hey sconklin refreshed my memory today about you mentioning regressions on ec2 in Lucid and Maverick. But I cannot remember what the regression in Lucid was. Do you still remember?
[17:05] <jjohansen> smb: yeah, just a sec I am looking up the bug #
[17:11] <jjohansen> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725310
[17:11] <ubot2> Launchpad bug 725310 in linux "Lucid 2.6.32-29.58 /dev/mem is readable (dup-of: 725308)" [Undecided,New]
[17:11] <ubot2> Launchpad bug 725308 in linux "Lucid 2.6.32-29.58 /dev/mem is readable" [Undecided,New]
[17:11] <jjohansen> and I have really started looking at it yet
[17:11] <smb> not? :)
[17:12] <jjohansen> smb: yes NOT
[17:12] <jjohansen> :)
[17:12] <jjohansen> smb: I did start looking into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725089
[17:12] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New]
[17:13] <jjohansen> which is the maverick bug
[17:13] <smb> jjohansen, I did sort of do that too
[17:13] <jjohansen> smb: ah okay :)
[17:13] <smb> jjohansen, Seems I was able to boot the latest proposed kernel there
[17:13] <smb> Though I think I discovered another regression (but that is old)
[17:14] <jjohansen> smb: oh which regression is that
[17:15] <jjohansen> oh nm its in your bug comment
[17:15] <smb> jjohansen, I noted in the bug report. But it seems running "reboot" in the instance does not work
[17:15] <smb> yeah
[17:15] <smb> Or I am not patient enough for it
[17:16] <smb> But it seems to be consistent with what I see on my local test system
[17:16] <smb> For a Lucid image I can do a "xm shutdown" and the domU goes away
[17:17] <smb> For a Maverick image I do the same and it stays around until I do a "xm destroy"
[17:17]  * smb thinks the reboot / halt vectors may probably need better handling
[17:18] <jjohansen> hrmm, yeah
[17:18] <smb> But as said, this is something that probably came with the change from Lucid to Maverick
[17:18] <jjohansen> apw: any reports of wireless just dying with the newest kernels
[17:18] <apw> jjohansen, no that have reached me no
[17:19] <jjohansen> apw: hrmm, I have had my wireless just die a couple times since upgrading friday
[17:19] <apw> what h/w you got ?
[17:20] <jjohansen> intel 4965
[17:21] <apw> hrm pretty common
[17:21] <apw> i wonder if you got some upgraded firmware recently
[17:22] <jjohansen> hrmm, unlikely I haven't upgraded the firmware package
[17:22] <sconklin> smb, jjohansen: so is it correct that we should not hold the maverick kernel for ec2, and that we should Lucid until further notice from jj?
[17:23] <jjohansen> apw: it could have an anomally, if it happens again I will file a bug
[17:23] <jjohansen> sconklin: uh no give a little bit more with maverick, I want to double check
[17:23] <herton> apw, one more bug I noted to be marked as fixed by latest natty rebase: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722925
[17:23] <ubot2> Launchpad bug 722925 in linux "bug on fs/inode.c:1422" [High,Triaged]
[17:23] <smb> sconklin, jjohansen The Lucid thing could just be again something that never was working in ec2 (due to the duplicate files)
[17:23] <apw> jjohansen, icirtianly worth watching, not someting i have heard from anyone else yet
[17:23] <herton> apw, same reporter confirmed the fix at upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=29792
[17:23] <ubot2> bugzilla.kernel.org bug 29792 in Block Layer "BUG: fs/inode.c:1422 when deleting device-mapper devices" [Normal,Closed: duplicate]
[17:24] <jjohansen> smb: all of qrt was definitely passing on lucid and maverick, the question is when kees added the test that is failing last year
[17:25] <jjohansen> smb: I couldn't remember, so the failure could have always been there
[17:25] <jjohansen> I was going to boot an older instance to test if it was there
[17:25] <jjohansen> to determine whether it was a regression or not
[17:25] <sconklin> smb, jjohansen: could you please send me an email with as detailed a status as you have - I need to keep everyone informed on this, as we're slipping until this is resolved. I've forwarded Stefan's earlier status to you so you can build on that
[17:25] <smb> jjohansen, Yeah, sounds good. Let me check something quick
[17:26] <apw> herton, thanks for the pointer ... helpfiul
[17:27] <apw> herton, marked in the changelog
[17:27] <herton> cool
[17:27] <apw> herton, bug -> Fix Committed
[17:28]  * apw notes herton is reading a lot of bugs :)
[17:28] <herton> great, thanks
[17:28] <herton> yeah, trying to follow them :)
[17:40] <kees> jjohansen: let me know if I can help with the qrt thingy
[17:40] <jjohansen> kees: will do
[17:42] <kees> jjohansen: fwiw, the SECCOMP test was added roughly in May 2009
[17:43] <smb> Question would be whether we ever saw it ok with xen... Or just went meh...
[17:44] <smb> ... seems to check devmem_is_allowed and that is defined in init.c... for which xen has a copy...
[17:47] <kees> which bug is thiat? devmem not working or seccomp killing it?
[17:48] <smb> kees, jjohansen So there is a difference here. The x86 code says "if (!page_is_ram(pagenr)) -> ok" while xen has something like if the page is beyond the given pages, then it is ok"
[17:49] <smb> if (mfn_to_local_pfn(pagenr) >= max_pfn)
[17:49] <jjohansen> smb: hrmmm, interesting
[17:53] <kees> smb: the devmem checks we never validated on Xen, that's for sure. and those were added in Oct 2010
[17:55] <jjohansen> kees, smb: yeah I think we haven't run qrt since devmem checks were added
[17:55] <jjohansen> err that is on lucid
[17:56]  * jjohansen isn't sure because he does remember running qrt last fall for some other bugs around that time frame
[17:56] <kees> jjohansen: yeah, I don't think the devmem test was run on Xen. again, it's likely my test sucks. :)
[17:57] <kees> jjohansen: I'm trying to work up a more definitive test. right now it's a bit "just try a whole range of addresses"
[17:57] <smb> Well at least it may not take into account xen strangeness or xen needs some tweaking
[17:57] <jjohansen> kees:  is brute forcing the address space again :)
[17:57] <smb> But either way. I also thought to have seen something fail on Lucid before
[17:58] <kees> jjohansen: hehe
[17:58] <jjohansen> smb: really, my recollections of xen qrt are that it was clean
[17:58] <jjohansen> that is one of the things we made sure of before the release
[17:59] <jjohansen> but there have been a few tests added since then, and those recollection are a lot more fuzzy
[18:00] <smb> jjohansen, The only thing one can be sure of is that one cannot be sure...
[18:01] <jjohansen> smb: yep
[18:01] <smb> Probably we quickly can check that with a current ec2 instance for Lucid. The latest kernel should not be in there. If the test fails too, then its at least not a new regression
[18:01] <smb> And the SECCOMP thing seems to be something that not always happens too. But feel free to get it a second try
[18:07] <apw> smoser, hey ... you have a bug open which is getting dogpiled, and as reporter i'd like your feedback: bug #625364
[18:07] <ubot2> Launchpad bug 625364 in pm-utils "lenovo/thinkpad R500/T6x/T400[s]/T500/W500/W700/X60/X200 suspend fails" [Undecided,Confirmed] https://launchpad.net/bugs/625364
[18:07] <smoser> apw, i think there are 2 bugs there in the dogpile
[18:07] <smoser> one is the tpm bug
[18:07] <smoser> one is, i think intel video related
[18:08] <apw> smoser, tend to agree.  if you are working though i want to close out the tpm bit you were suffereing
[18:08] <apw> so i can get them to make new ones
[18:08] <jjohansen> smb: that is what I am doing, I fired up some fresh instances and am giving it another test
[18:08] <smoser> my T400 was suspending and resuming fine in natty.
[18:08] <kees> smb: oh, also note that I disabled the /dev/mem check on ec2 for the time being
[18:08] <smoser> i was sufffering i think from the intel video bit.
[18:08] <smoser> i haven't suspended and resumed a lot in several upgrades on natty
[18:09] <smoser> but it *was* working when i originally jumped to natty
[18:09] <apw> yeah we've had a number of bugs come and go
[18:09] <apw> cking, did you find that patch ?
[18:10] <cking> apw, the S4 one?
[18:12] <apw> cking, yeah
[18:56] <nusch> I asked afternoon about searching for regresions in kernel, I'm working with bug https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/662009
[18:56] <nusch> I tested it on my Y530, and last working kernel-ppa version is 2.6.34.7-maverick and in 2.6.35-rc2-maverick which is next it's already broken - I hear music very silent when I connect external speakers and set them to full volume. What next, should I download git version of those or test vanilia kernel?
[18:56] <ubot2> Launchpad bug 662009 in alsa-driver "[Lenovo Y530 - Realtek ALC888] Regression from 10.04: No sound with snd_hda_intel model=lenovo-sky" [Undecided,Triaged]
[20:46] <jjohansen> bjf, sconklin: neither are regressions release the kernels
[20:46] <sconklin> jjohansen: ok, thanks. Are they bugs which are not regressions?
[20:47] <jjohansen> sconklin: correct I sent an email with a little more detail
[20:47] <jjohansen> very little more
[20:47] <sconklin> jjohansen: thanks much! We'll crank the machine back up ;)
[20:48] <jjohansen> sorry it took so long the one really did look like a regression, passed on old first time I tried failed, on new started bisecting and then it just got weird
[21:24] <bjf> JFo, if you could bless bug #726796, i'd be so grateful 
[21:24] <ubot2> Launchpad bug 726796 in linux "linux: 2.6.35-28.49 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/726796
[21:26] <apw> bjf, approved
[21:26] <bjf> apw, thanks