[07:14]  * smb mornings
[07:14] <smb> diwic, Hm, could it be that something visually stole a lot of hda microphones?
[07:18] <diwic> smb, eh?
[07:20] <smb> diwic, Somehow I only realized this this morning, but somehow at least on two machines, the microphone isn't called microphone but capture. Which I don't mind, but the sound settings dialog seems not to accept those as input devices. Leaving inputs empty (or only containing other inputs)
[07:20] <diwic> smb, oh :-/
[07:20] <diwic> smb, isn't it called "Analog input" or something?
[07:21] <smb> Hm, Not in alsamixer
[07:21] <apw> morning
[07:21] <smb> apw, morning
[07:21] <diwic> smb, so there was a change yesterday which I hoped would help against a few usb inputs
[07:21] <diwic> not showing up in the UI
[07:21] <smb> diwic, It helped... sorto of :)
[07:22] <diwic> smb, so could you pastebin the output of "pacmd ls" on an affected machine, please?
[07:22] <smb> diwic, sure, just a sec
[07:24] <smb> diwic, http://paste.ubuntu.com/927534/
[07:25] <diwic> smb, so according to this output, you should only have one input in sound settings, and that's your webcam/internal mic, because nothing else is connected.
[07:26] <smb> diwic, Hm, probably not the best example. It used to show the microphone jack as well, but there is really nothing connected... Wait I get the same output from the other machine
[07:27] <smb> That one would have an internal microphone not showing
[07:28] <smb> http://paste.ubuntu.com/927537/
[07:29] <diwic> smb, ok, and the internal mic disappeared something like yesterday or today?
[07:30] <smb> diwic, The timeframe is bigger. I just installed that machine yesterday for some other testing.
[07:31] <smb> It has been idling around for a bit... Though I thought I had it on Precise before and not noticed the mic being gone
[07:31] <smb> But you know, you won't always look at the right place
[07:31] <diwic> smb, ok. so can you run "ubuntu-bug pulseaudio" from the latter machine and point me to the resulting bug?
[07:31] <smb> diwic, yes, sure
[07:36] <smb> diwic, bug 980565
[07:36] <ubot2> Launchpad bug 980565 in pulseaudio "Microphone gone from sound-settings while still usable for apps" [Undecided,New] https://launchpad.net/bugs/980565
[07:39] <diwic> smb, aha, it's colin guthrie's bug but for input...interesting
[07:40] <smb> diwic, Errrrr, well... ok, what? :)
[07:40] <diwic> the good news for me is that I don't have to revert my fix from yesterday, because this is something different *phew*
[07:41] <diwic> smb, so the kernel gives us no sign (no mixer control, or anything else)  that there is an internal mic present
[07:42] <apw> diwic, does that mean it should also be missing in alsamixer thing ?  to confirm that
[07:42] <smb> Well there is a control in alsamixer, its just called capture now... I think
[07:42] <smb> Likewise on the other machine which has capture and capture 1
[07:42] <diwic> apw, had there been something like "Internal Mic" or "Internal Mic Boost" in alsamixer, pulseaudio would have picked that up and known that you had an internal mic.
[07:43] <smb> apw, Maybe you should check whether the mic fairy stole yours too... :)
[07:44] <diwic> smb, just trying to determine the size of the problem here: can you still modify the gain of the mic in the sound indicator?
[07:45] <smb> diwic, While an application using it is running there is a slider present. 
[07:46] <diwic> smb, anyway the quick fix for you, is to modify /usr/share/pulseaudio/paths/analog-input-internal-mic.conf and comment out any line that starts with "required-any", then restart pulseaudio.
[07:46] <diwic> smb, is the slider working?
[07:46] <smb> diwic, and moving it does correspond to moving the capture slider in alsamixer
[07:46] <diwic> smb, ok. good.
[07:47] <smb> diwic, I don't think I need a quick fix. It is in the end more of a visual/usage limitation
[07:47] <diwic> smb, this is not one of those machines that has an inverted phase internal mic? 
[07:47] <smb> diwic, It is
[07:48] <smb> diwic, I muted the right capture channel through alsamixer
[07:48] <smb> It is a bit what started me looking because after a fresh install this is required to get the mic working
[07:48] <smb> Then I wondered, ok, but _where_ is the mic slider now...
[07:50] <smb> Then checked the desktop machine and I am pretty sure there was the web cam mic and the internal card mic there recently
[07:50] <smb> But you say that is intentional if there is nothing connected to it 
[07:50] <diwic> smb, a desktop machine with an internal mic?
[07:50] <smb> diwic, No, sound card has a mic jack (not connected to anything)
[07:51] <diwic> smb, ah, ok.
[07:51] <diwic> smb, yeah, it's anticipated that it does not show up when it's not connected.
[07:53] <diwic> smb, so given that this machine has the inverted internal mic problem as well, fixing that problem (in the kernel) will auto-fix the pulseaudio problem as well
[07:59] <smb> diwic, Would be a plus... I try to find anything I can try to connect to the desktop machine. Just curious to see what happens then...
[08:00] <apw> plug a speaker in :)
[08:00] <apw> or your headphones, they ahve the saem plug
[08:01] <smb> apw, yeah, yeah. theoretically every speaker is a bit of a microphone. but surely they have different impedance... :-P
[08:04] <apw> smb, i wasn
[08:05] <apw> smb, i wasnt expecting it work, just to trip the jack
[08:05] <apw> smb, i shove mine in the wrong way round often enough
[08:07] <smb> diwic, So I found some real mic to connect to the jack now. And looking in mumble (would never have dreamed to use that as a test ever) picks up something from the card... Still no show-up in the input sound-settings...
[08:08] <smb> apw, Ah right, yeah that would halfway work. Just wanted some pickup of sound as well, so I can verify it does read something
[08:09] <apw> smb, then i fail :)
[08:09]  * apw looks at compiz and unity updates in his 'inbox' and cries
[08:10] <diwic> smb, and this was the desktop machine with the webcam, right? Can you pastebin the output of "amixer contents"
[08:10] <smb> apw, :) No worries, I found a cheap mans headset in my box of rectractable gadgets...
[08:10] <smb> diwic, yes and yes
[08:11] <smb> diwic, http://paste.ubuntu.com/927575/
[08:12] <diwic> smb, ok, so the "mic jack" is "off" in that paste, which means that the problem is at the driver level
[08:13] <smb> diwic, Hm, I wonder how much you can expect jack detection on desktop machines...
[08:14] <smb> Just muted the web cam mic and still see audio activity picked up by mumble...
[08:14] <diwic> smb, well, your line-out is plugged in, so that part of the jack detection seems to be working
[08:15] <smb> diwic, Ok...
[08:16] <smb> diwic, Erm, which numid you see the mic jack not connected?
[08:16] <diwic> smb, the three topmost ones
[08:16] <diwic> smb, the third is "Mic Jack"
[08:17] <smb> and they all are =1
[08:17] <smb> oh 
[08:17] <smb> values
[08:17] <diwic> with values=off means not connected
[08:17] <diwic> values=1 I think means "the total count of values is 1"
[08:17] <smb> ah
[08:17] <smb> that was confusing me
[08:21] <smb> Somehow this feels a bit like that  change may make this day well worth its number... ;)
[08:23] <diwic> smb, if you're interested in continuing, the next step would be to run "sudo hda-jack-sense-test -a" with the mic plugged in, then with it unplugged to see if there's a difference
[08:24] <diwic> smb, where hda-jack-sense-test is available in the snd-hda-tools packages in ppa:diwic/hda
[08:24] <smb> diwic, sure, that would be on the desktop machine, right?
[08:24] <diwic> smb, yes.
[08:31] <smb> So amixer contents remains off all the times but hda-jack-sense-test toggles between yes and no for the mic
[08:32] <smb> diwic, ^ (forgot=
[08:33] <diwic> smb, ok, so looks like a driver bug to me. Next step, check if it's resolved upstream by https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
[08:42] <apw> diwic, how does hda-jack-sense-test get the info
[08:43] <diwic> apw, it sends a direct command to the codec asking for the current jack sense state
[08:43] <apw> diwic, oh it can get that low a level access ouch :)
[08:43] <diwic> apw, if that would have failed, it would probably have been a hardware error. 
[08:44] <apw> diwic, and how have you gotten a 'no signer' on your PPA uploads ?
[08:45] <diwic> apw, eh, where do you see that 'no signer' thing?
[08:45] <apw> https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-daily/+packages
[08:45] <diwic> apw, aha, those are recipe builds.
[08:46] <apw> hmm thats a little confusing, it should really say 'launchpad' or something else they sound unsigned
[08:48] <diwic> apw, hmm, https://code.launchpad.net/~diwic/+archive/hda/+packages does not show that column at all.
[08:48] <apw> smb, STOP IT HURTS
[08:49] <apw> smb, when you are loud it still breaks up
[08:50] <apw> cking, i am silent i assume ?
[08:50] <cking> apw, for once, yes ;-)
[08:50] <apw> smb, i hear you yes
[08:51] <mpt> Why do <https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Bug_Triage> and <https://wiki.ubuntu.com/Kernel/BugTriage/BugStates> both exist?
[08:52] <apw> diwic, ok i am in a situation where gnome input selector thingy is not switching my mic any more
[08:53] <diwic> apw, but the kernel still switches correctly?
[08:53] <diwic> apw, I mean, from where is it actually recording?
[08:54] <apw> diwic, erp ... all _i_ know is the indicator switches over and mumble continues to use the wrong one
[08:54] <apw> diwic, the input level on the external mic seem to work in the selector correctly
[08:55] <diwic> apw, first. what are you switching between? Internal and external mic on the same card, or an USB mic of some sort, or what?
[08:55] <apw> so the internal HDA card the external connector with a mic plugged into it, and that blue snowball usb device
[08:55] <apw> OH HANG ON
[08:56] <apw> diwic, ignore me till i reboot i bet its an update skew issue
[08:56] <diwic> apw, I don't think we've ever supported that type of switching.
[08:56] <apw> diwic, it worked yesterday ... and if we don't support switching in that dialog what is it for
[08:57] <diwic> apw, aha, you mean you manually switch in the GUI?
[08:57] <apw> diwic, right in the GUI i am clicking and its doing nothing
[08:57] <apw> but ... i have updated, so perhaps there is skew
[08:57] <mpt> ... they seem to be identical
[08:57] <diwic> apw, ok, rebooting might be worth a try
[08:58]  * smb reboots to get alsa-next
[09:05] <smb> diwic, Hm, not very positive it is fixed really. It is there now, but won't change to off when I am unplugging. So it seems to be static to whatever was the state on startup
[09:07] <diwic> smb, hmm, sounds like the unsol event handling is not coming in correctly then
[09:12] <diwic> smb, that's unusual, but I've seen it before. I guess the same would apply to the other jacks (line out and line in)?
[09:14] <smb> diwic, Yeah sounds like some event problem. Hm, not sure I want to do that to the line out right now... But let me try line in
[12:01]  * ppisati -> conf call
[12:01]  * cking -> lunch
[12:03]  * smb -> tired already
[13:32] <henrix> smb: tired? get a good laugh here: https://lkml.org/lkml/2012/4/13/66
[13:32] <henrix> :)
[13:33] <smb> lol
[13:34] <tgardner> ha ha
[13:36] <smb> We obviously need to record a show like "The big bug theory (solving kernel problems without looking)"... :-P
[13:37] <jsalisbury> "This bug is too big and boring, can you make a youtube video describing it" 
[13:40] <dileks> the answer by rostedt was more amusing
[13:40] <dileks> as I always say when doing 3rd level support
[13:41] <dileks> I can read the faq/wiki/doc for you... if it helps
[14:21]  * ppisati -> brb
[14:41]  * ogasawara back in 20
[14:56] <cking> bah, too many machines and too many updates, what a time sucker
[16:19] <tgardner> apw, re: bug #922906. are you gonna propose that patch suite for precise ? seems like you're getting positive test results.
[16:19] <ubot2> Launchpad bug 922906 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [Medium,In progress] https://launchpad.net/bugs/922906
[16:19] <tgardner> plus, its got a zillion dupes
[16:25] <apw> tgardner, ahh ok cool ... will let you see it and see if you whine :)
[16:25] <tgardner> apw, its gonna be bjf et all that whine :)
[16:28] <apw> tgardner, with only one responder, i am unsure how good two days is
[16:29] <tgardner> apw, get jsalisbury to hassle some of the owners of dupe bugs
[16:29] <apw> tgardner, don't they get a message too when the master is updated?
[16:29] <apw> jsalisbury, ^^ ?
[16:29] <tgardner> apw, dunno,. but you'd think so
[16:30] <henrix> apw: i may try to reproduce the issue myself as well. i remember i had a set of scripts that could trigger it on a VM
[16:30] <apw> henrix, sounds good
[16:30] <henrix> apw: i'll let you know if that works ok
[16:32] <apw> henrix, exceelent
[17:12] <apw> tgardner, ok so i finally got some feedback on the ata patch and they want a complete rewrite
[17:12] <apw> tgardner, and amazingly it works first time :)
[17:12] <tgardner> apw, this is for hvc ?
[17:12] <apw> tgardner, yeah this is moi trying to upstream the patch we have to ignore ATA drives
[17:13] <apw> tgardner, they want a more generic soln. which is fine.  so am testing the patches nwo
[17:13] <tgardner> apw, cool
[17:31]  * tgardner -> EOD
[17:32] <apw> cking, hey
[17:40] <henrix> apw: with your test kernel, i'm not able to reproduce the bug
[17:40] <pgraner> cking, you about?
[17:41] <cking> pgraner, just about
[17:41] <henrix> apw: i've been running the VM for a while now...
[17:41] <pgraner> cking, what does this mean
[17:41] <pgraner> Apr 13 13:40:33 x220 kernel: [  146.125226] Valid eCryptfs headers not found in file header region or xattr region, inode 5124144
[17:41] <pgraner> Apr 13 13:40:33 x220 kernel: [  146.125231] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
[17:41] <pgraner> Apr 13 13:40:33 x220 kernel: [  146.125250] Valid eCryptfs headers not found in file header region or xattr region, inode 5124144
[17:41] <pgraner> Apr 13 13:40:33 x220 kernel: [  146.125256] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
[17:41] <pgraner> I have thousands of them 
[17:42] <cking> pgraner, let's see if tyler can explain
[17:42] <tyhicks> pgraner: It means that there is a non-eCryptfs file in the lower filesystem and eCryptfs doesn't know what to do about it so it errors out of open(), stat(), etc., calls
[17:43] <pgraner> tyhicks, how do I fix it up then?
[17:43] <henrix> apw: anyway, i'll keep it running for some more time and post a comment on the bug report later on
[17:43] <tyhicks> `find ~/ -inum 5124144` will tell you what file it is
[17:43]  * henrix will be out for a while...
[17:43] <tyhicks> pgraner: ^
[17:44] <tyhicks> pgraner: It is probably an empty file. Verify that it has a size of 0 and then delete it.
[17:44] <pgraner> tyhicks, ok it found it, look like a chromium file of some sort
[17:44] <tyhicks> We really need to find a better way to handle this condition
[17:44]  * cking wonders how it got there in the first place
[17:45] <tyhicks> cking: Probably a kernel crash or hard power off. There is a small window between creating a file in the lower filesystem and writing out the appropriate eCryptfs headers to the lower file.
[17:46] <apw> henrix, thanks
[17:46] <pgraner> tyhicks, I ran out of space on my file system yesterday and I got all sorts of strange errors and file entries
[17:46] <henrix> apw: np. it still see the issue with older kernels, but not with your test kernel
[17:46] <pgraner> tyhicks, most cleared up after a reboot, except this one
[17:46] <tyhicks> pgraner: Well, that may be it, too. Maybe you had enough space to create an inode but then didn't have enough space to write out the eCryptfs metadata (8k of data total)
[17:47] <pgraner> tyhicks, prob happened while emacs was doing an autosave
[17:47] <cking> tyhicks, thats a "special" condition for sure.
[17:47] <pgraner> I had a script that was creating VMs and I didn't realize how many I had and ran it out of space
[17:48] <tyhicks> cking: We can't handle that situation any better from an eCryptfs standpoint, but we could possibly handle the situation of opening an empty file better.
[17:49]  * cking nods, yep, the error condition can appear rather worrying if one does not know how to interpret the error message
[17:50] <tyhicks> cking: I've kicked around the idea of having the ecryptfs_open() path turn an empty lower file into an appropriate eCryptfs file, but some folks have spoke out against that idea
[17:50] <tyhicks> (the code changes would be easy since ecryptfs_create() already does just that)
[17:51] <cking> tyhicks, so why are folk opposing that idea?
[17:52] <tyhicks> cking: See bug 911507
[17:52] <ubot2> Launchpad bug 911507 in ecryptfs "eCryptfs should initialize existing empty files at open()" [Medium,Triaged] https://launchpad.net/bugs/911507
[17:53] <tyhicks> cking: It looks like more users are speaking up for doing the conversion in open() than the one guy opposing it. I may try to fix this next week.
[17:54] <cking> tyhicks, it should be fixed for  the silent majority rather than one user who opposes it IMHO 
[17:55] <cking> could it be a default mount option so that the one whiner can switch it off it they want to
[17:57] <tyhicks> cking: That's certainly an option, but I'd prefer not to add more mount options as it widens the amount of testing needed.
[17:57] <tyhicks> cking: and I agree with your comment about fixing it for the silent majority
[17:58] <cking> I suppose if they don't want it they can revert the patch and build their own kernel ;-)
[17:58] <cking> tyhicks, yep, the less test paths the better
[18:03]  * cking --> EOD
[18:08]  * ogasawara lunch
[18:52] <jsalisbury> apw, the dup bugs for bug 922906 do get updates when a bug comment is added.  Do you want me to spam some of the dups to ask for testing?
[18:52] <ubot2> Launchpad bug 922906 in linux "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [Medium,In progress] https://launchpad.net/bugs/922906
[19:05] <apw> jsalisbury, if you can be bothered :)
[19:05] <jsalisbury> apw, no problem at all.  I'll request testing of your kernel in each of the dups
[19:17] <pgraner> ogasawara, just send an email to c-k-t about a pxe boot kernel hang  can you guys dig into it asap
[19:27] <ogasawara> pgraner: ack
[19:56] <jsalisbury> ogasawara, whoops, mid-air collision on the email thread :-)
[19:57] <ogasawara> :)