[00:58] * jjohansen steps away for a bit [02:20] !ops [02:20] Help! lamont, zul, T-Bone, mdz, or jdub [02:23] !ops [02:23] ban me [02:23] Help! lamont, zul, T-Bone, mdz, or jdub === _LibertyZero is now known as LibertyZero [06:39] anyone around? === _LibertyZero is now known as LibertyZero === smb` is now known as smb [09:06] Hi there, have just fixed a kernel bug and had a few questions [09:06] Is there a way to get Soyuz to build a kernel image to a PPA? [09:06] awilkins, you can upload modified kernles to PPAs yes [09:07] awilkins, if you need a quick test kernel it may be quicker to do a manual build, as that only builds fewer flavours [09:07] apw, Can you just upload debs, or do you need to upload source differences? [09:07] apw, I've got it built and running [09:07] awilkins, PPAs are identicle to the main archives [09:07] so you can upload source packages there too [09:08] awilkins, whats the bug, anything interesting? [09:08] bug #776964 [09:08] Launchpad bug 776964 in alsa-driver "p5n32e-plus HDA Nvidia AD1988B microphone input not working" [Undecided,Confirmed] https://launchpad.net/bugs/776964 [09:10] awilkins, if you just want some semi-official kernels with the patch i can spin some and shove those on people and link them to the bug [09:12] awilkins, is that of use ? [09:12] apw, I've got the amd64 one built here, but that would be useful to the other chap in the comment thread, I think. I'm not sure how many people have noticed this one... we can't be the only three people running Ubuntu on that motherboard though, and from the code, the bug may affect anyone with a AD1988 variant [09:12] awilkins, well the norm is to get testing on the bug ... for which i can provide kernels, and then push the patch into the kernel if it fixes things [09:12] i see you say the patch is accepted by alsa upstream? got a link to that [09:13] apw, I just got a mail from Takashi Iwai, not sure he's pushed his tree yet though [09:13] arggg bug trackers which need a login to _look_ at bugs ... no thanks you [09:13] awilkins, can you forward me the patch you sent him [09:14] and i can spin with the right patch then [09:14] Done [09:15] A variant of this problem has affected the kernel for several releases, but until now it was workaroundable [09:15] awilkins, well its good to get it fixed if its broken [09:15] That provoked me into actually looking at it... nothing like breaking something to make a geek try to fix it [09:16] bug #593018 Is the older variant of this bug that has a workaround [09:16] Launchpad bug 593018 in alsa-driver "nvidi p5n32e-plus Analog Devices AD1988B soundmax microphone only works after switching to another input setting and back" [Undecided,Confirmed] https://launchpad.net/bugs/593018 [09:17] It only worked by coincidence, reading the code from Maverick, it has a similar logic fault (comparing a type constant to an array index instead of the type value) [09:18] I don't know the policy for what constitutes an SRU worthy thing though [09:19] awilkins, small obvious and fixing a real user problem, generally those are valid [09:19] if they come via stable all the better, and if we get lots of testing we can help that happen too [09:21] I pulled the alsa-driver bzr branches for maverick and natty - they were useful for reference, do they actually get used to make the builds, because I get the impression the git repositories are the real sources? [09:22] awilkins, our master source is our git tree also, we make source packages from that and upload them [09:24] apw, Link to actual patch on mailing list http://thread.gmane.org/gmane.linux.alsa.devel/85204 # just in case that's helpful [09:25] awilkins, indeed so [09:26] awilkins, where are you testing, which release [09:27] apw, I'm on natty, testing on my normal working machine. I patched the tip of git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git [09:28] awilkins, cool [09:30] apw, maverick and lucid would need a slightly different patch [09:32] awilkins, we can worry about those later [09:45] awilkins, if you feel inclined you could port the patch and attach it to the bug for those releases [09:46] apw, :-) Also think this bug is replicated in some of the other patch-panel modules [09:46] There are quite a number of "my mike doesn't work" bugs in Launchpad, I was trolling through them to see which ones were AD1988 related [09:50] awilkins, good plan, once the test kernels are there we can perhaps get some testing on those other ones and pull the duplicates in [10:18] apw, Bah, I take it back, this is not the same problem as #593018, the code looks all right in <= maverick, on inspection. [10:19] awilkins, well thats good to know anyhow [10:19] awilkins, ok test kernels are in the bug [10:28] As expected, nothing has exploded and my mic still works. [10:30] indeedd, hopfully some of the other testers will chime in === thearchitect is now known as architect === architect is now known as thearchitect === thearchitect is now known as theunknown [13:06] here it says: 'NMI: PCI system error (SERR) for reason %02x' in traps.c (http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob;f=arch/x86/kernel/traps.c) [13:06] how do I find what's the reason (%02x) [13:06] in my case dmesg shows a5, sometimes b5 for %02x e.g.: NMI: PCI system error (SERR) for reason a5 on CPU 0 === LinkRage is now known as LinkRage-0ff [13:36] awilkins, could you comment in your own bug that you tested my kernels, that helps with the processing [13:52] LinkRage, at first glance (without looking) i'd say they sound like bus produces numbers, ie intel defines them [13:54] SERR# [13:54] System Error is for reporting address parity errors, data parity errors during a Special Cycle, or any other fatal system error. SERR# is shared among all PCI devices and is driven only as an open drain signal (it is driven low or tri-stated by PCI devices, but never driven high). It is activated synchronously to CLK, but when released will float high asynchronously through a pull-up resistor. [13:54] LinkRage, ^^ seems to imply a hardware error being reported [13:54] looks like [13:54] well I'm testing now... [13:55] the issue is caused by brand new (tested) pci sound card [13:56] I think I fixed it by disabled ECC error detection, PCI error detection and disallowed plug & play OS to touch the BIOS settings [13:56] now I'm booting ubuntu again to see what happens [13:57] well disabling error detextion on PCI likely will get rid of the SERR reports, but they are telling you something bad is occuring [14:01] hm, I guess you're right [14:01] I'm also thinking of removing all the other PCI component (HW raids etc - it old server from 2002) [14:10] <_ruben> server with soundcard? :P [14:12] yep, I'm going to give it to my father, since he's desktop is even older :) [14:13] ubuntu worked fine this time, now I enabled ECC and PCI detection, but left the plug & play OS: Disabled in BIOS, so let's see... [14:16] huh, PCI error checking is causing the issue when enabled [14:16] that makes sense as SERR is a PCI thing [14:16] :) [14:17] LinkRage: More likely that something else is causing it, but you only notice when you have PCI error checking turned on [14:17] I have 2 options here - either remove all the pci raid stuff, and try again, or disable error checking, I've no clue about third option :) [14:17] mjg59, good point [14:18] its not likely things are going to work well with that disabled, its trying to tell you something, something urgent enough that an NMI is warrented [14:19] kees, about? need to talk to you about a possible bug in Yama [14:19] well, I'll remove all the other PCI devices since I'm not sure if they are in so working condition [14:19] thanks for your advices btw :) [14:50] * apw bounces to test a kernel [14:58] apw: sure, what's up? [14:58] kees, hiay, the yama path check [14:58] it uses generic_permissions() [14:59] which in turn uses i_uid etc and those do not seem to be guarenteed valid [14:59] in the case where the filesystem supplies a permissions() op [14:59] i'll email you the patch i think yama needs [15:00] kees, ok dropped you a dirty copy ... see what you think [15:01] apw: ah, interesting, perhaps this is the origin of 729338 ? [15:01] bug #729338 [15:01] Launchpad bug 729338 in linux "yama hardlink restriction misbehaves under aufs" [Undecided,New] https://launchpad.net/bugs/729338 [15:01] I had been stratching my head over that one [15:01] kees, heh that likely is so, as its under overlayfs which tickles the same issue [15:02] i have a kernel here with aufs in and the patch so i could test [15:04] apw: why doesn't generic_permission do the i_op->permission check itself? [15:04] thats not what its for [15:04] generic_foo in general are for use as implementations when you don't have a foo op [15:05] if you wern't a security op i'd expect you to be using inode_permissions [15:05] but that in itself calls security which sounds loop tastic [15:05] kees, ^^ [15:06] kees, testing aufs for the same issue now [15:09] kees, is the hardlink stuff new in oneiric ? [15:10] kees, ok the same test case does not tickle aufs, but the error is the same [15:10] in your report as to what i was seeing in mine [15:12] kees, ahh ok managed to reproduce on aufs at least [15:15] apw: no, hardlink restrictions have always existed in Yama [15:15] odd that we've not seen th [15:15] this more often, or indeed that it only afffects the one case not all that affects overlayfs [15:16] not a lot of people use stacked FSes [15:16] Yama was first in 10.10 [15:16] kees, we use them all the time on all liveCDs [15:16] right, but with very few hardlinks :) [15:16] anyway, was the aufs issue the same thing? I wasn't clear on what you had said [15:17] kees will know shortly [15:17] have to reboot to confirm [15:21] kees, ok so this does not fix the aufs interaction [15:22] kees, the debug i have is useful however [15:22] apw: geh, bummer. [15:22] kees, i may as well have a look at it while i ma in the zone === EvilMTeck is now known as MTecknology === hallyn_afk is now known as hallyn === fairuz is now known as fairuz_ [16:19] hi how can i install gcc 3.4 in ubuntu 11.04 [16:21] Does anyone here closely follow netdev@? I'm trying to figure out if the patch whose discussion appears to end here http://kerneltrap.org/mailarchive/linux-netdev/2010/5/6/6276530 ever got picked back up in a new form === cmagina is now known as cmagina-lunch [17:28] hallyn, tim would be your man, but he is away [17:30] apw: ok, thanks. === cmagina-lunch is now known as cmagina [17:44] <-food time, back soon === elmo is now known as ihateyoutoo === ayan-afk is now known as ayan === hallyn is now known as hallyn_afk === hallyn_afk is now known as hallyn