=== zequence_ is now known as zequence
[11:23] <apw> diwic, hey ... i seem to have lost sound on my main "desktop" with 3.15, and i wondered how i could figure that out
[11:24] <diwic> apw, are all outputs affected?
[11:25] <apw> diwic, all internal ones, i have external USB connected speakers which work
[11:25] <diwic> apw, if you run "ubuntu-bug audio" and go through the sound test, is any of the sound tests working?
[11:27] <apw> is it complaining about mixer settings
[11:28] <apw> though the command it asks me to run is wrong
[11:30] <diwic> apw, okay...could you be more precise?
[11:30] <apw> ok found the card by hand and the mixer setting it whines about (speaker volume) was 0% and fixing that has fixed sound
[11:31] <apw> the command was "alsamixer -D hw:intel" which didnt work
[11:31] <diwic> apw, it's usually big "I" in "Intel"
[11:31] <diwic> apw, but send me your alsa-info and I'll have a look
[11:32] <apw> yeah big I finds it, perhaps i missread the prompt, yep missread, it is in a stupid font which looks like a little i, sigh
[11:32] <apw> ok, anyhow, i assume this is lost alsa settings on upgrade thing?
[11:32] <apw> do you still want my alsa-info ?
[11:33] <diwic> apw, well the question is more like, why didn't pulseaudio change the speaker setting to something reasonable. Or, if you don't have any internal speakers, why do you have such a mixer setting at all
[11:34] <diwic> (you said it was a desktop rather than a laptop)
[11:35] <apw> diwic, ahh this is a laptop in a desktop environment, monitors attached etc, so its not mobile ever, but it is a lappy, hense the "desktop"
[11:35] <apw> it has something plugged in each and every possible port :)
[11:36] <diwic> apw, what port is selected in PulseAudio ( what line is selected in sound settings -> output )
[11:37] <apw> diwic, when i am testing the speakers it is on "Speakers"
[11:38] <diwic> apw, well, then just changing the volume in pulseaudio would also change the speaker volume
[11:38] <apw> as that is the setting it has to be on to use the headphone sockets, i switch it there to the USB speakers for the rest of the time
[11:38] <apw> diwic, ok so the speaker volume was set to a normal value and was working on the USB ones
[11:39] <apw> when i switched internal it was silent, until i used alsa mixer to fix the volume
[11:39] <apw> "speaker volume" meaning pulse's one on the top bar
[11:40] <apw> and switching from one to the other swaps the volume to the per channel volume in pulse too
[11:40] <apw> very odd
[11:40] <apw> very odd that it could be out of sync until i did the adjustment
[11:41] <diwic> apw, yeah, switching to internal should update alsa's speaker volume to something reasonable
[11:42] <apw> diwic, ok, if i watch alsamixer and change pulses volume when on internal
[11:42] <apw> then pulse is changing "master" and not "speaker"
[11:42] <diwic> apw, sure, but if you set alsa's speaker to something and then move pulse's slider, alsa's speaker is moved to maximum
[11:43] <apw> diwic, yes it does, hmmm, oh of course i may not have changed volume, on internal ever
[11:43] <apw> since the issue appeared, presumably in a kernel update lose of settings
[11:44] <apw> as i would switch to USB, find volume works, move to internal, find it broke, whine
[11:44]  * apw notes that the order of his audio devices in alsa-mixer seems different today, in that the internal is not card 0
[11:44] <diwic> apw, anyway - if you find a way to reproduce the error let me know. Otherwise I'll just let it slip.
[11:45] <apw> diwic, yep, as i am running a devel kernel i think that is most appropriate :)  thanks for the help, i have more tools to work it out next time
[11:45] <diwic> apw, btw, while I have you around - I'm seeing some bluetooth headset errors and most of them seem to be a userspace bug I'm currently trying to track down,
[11:46] <diwic> apw, but at least one or two had some weird dmesg errors, let me find them 
[11:46] <apw> ack
[11:47] <diwic> apw, in bug 1283003, "Bluetooth: re-auth of legacy device is not possible." "Protocol not supported (93)"
[11:47] <ubot5> bug 1283003 in gnome-bluetooth (Ubuntu) "[Bluetooth + 14.04] Bluetooth headsets are not working after last couple of updates" [Undecided,Confirmed] https://launchpad.net/bugs/1283003
[11:48] <diwic> apw, the latter one is from userspace, the first one from kernel
[11:50] <apw> there is only one bug number there
[11:51] <diwic> apw, yeah, it's the "we report all people in one big bug" story
[11:51] <apw> DOG-PILE
[11:52] <diwic> apw, but for the "re-auth of legacy device is not possible" part, is there anything we should/could do about that? 
[11:54] <apw> diwic, well that code seems similar in 13.10 as it does in 14.04, so it is not clear it is that which is at fault
[11:54] <diwic> apw, okau
[11:55] <apw> Voyager bluetoothd[716]: Protocol not supported (93)
[11:55] <apw> how does bluetoothd think that is a reasonable error
[11:55] <apw> what the hell was it doing when it got errno = 93
[11:57] <diwic> apw, okay, let's fix blueman first and see how far that gets us w r t resolving the bugs. 
[11:59] <apw> diwic, so it seems we have limited ways that bluetooth can say that, and may imply we have a module missing, will check
[12:03] <apw> diwic, ok everything i would expect is enabled so, hard to be sure, we really need to get bluetoothd to tell us what i was doing if it still fails
[12:03] <diwic> apw, okay. Thanks for the look
[12:04] <apw> diwic, as for the errors and their order, i suspect they try and auth the device, the device is of a type which cannot, so bluetoothd closes and reopens it some differnt way and that fails
[12:04] <apw> but ... what ... harder to say
[12:09] <apw> diwic, it is generally good at reporting what caused the error, though there are one or two places
[12:11] <apw> diwic, then again it uses the saem internal errors ... so for example if a device says HCI_UNSUPPORTED_REMOTE_FEATURE then it switches that to errno 93
[12:11] <apw> which ... could mean it is not kernel at all ... ugle
[12:11] <diwic> apw, hmm, okay...the reason I thought it was kernel was mostly because the kernel dmesg was first
[12:12] <apw> diwic, yeah, it is not clear that that is a fatal thing, as it it might be a normal process connecting and reconnecting in dumber modes
[12:13] <apw> and we had the same basic code before, though if they can down grade just the kerenl and it changes then there is a kernel component
[12:14] <apw> diwic, ok that "error" is informational only and says that we failed to encrypt the link, but the link remains
[12:15] <diwic> ok
[12:18] <diwic> btw, is the hwe backport stuff going to work (in general) like it did for 12.04? I e 14.04.2 will ship with utopic kernel and x stack
[12:22] <bjf> diwic, i can't really speak for anything other than the kernel but yes, there will be a series of lts-<series> kernels for trusty which will also be the defaults for the future point releases
[12:24] <diwic> bjf, ok, good to know
[12:32] <pkern> Could somebody take up https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1323165? Patch committed upstream to remove the BUG_ON.
[12:32] <ubot5> Ubuntu bug 1323165 in linux (Ubuntu) "[HP ProLiant DL380p Gen8] kernel BUG at /build/buildd/linux-3.13.0/mm/memory.c:3756!" [Medium,Confirmed]
[12:53] <rtg> pkern, patch sent to the k-team list
[12:55] <pkern> rtg: thanks!
[14:30] <vmlintu> Hi, I'm trying to understand the 3.13 kernel maintenance process. How the patches end up there? The tree here has seen no activity for some time: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog  Am I looking at the right place?
[14:31] <vmlintu> What I'm trying to figure out if this patch marked for stable is on its way to Ubuntu's kernel or if something needs to be done for it to end up there: http://www.spinics.net/lists/netdev/msg282079.html
[14:32] <rtg> vmlintu, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
[14:35] <vmlintu> rtg: ok, I'm cloning that.. is that the Ubuntu flavoured kernel?
[14:36] <rtg> yup
[14:38] <vmlintu> Is git://kernel.ubuntu.com/ubuntu/linux.git going to get updates or should I follow only the ubuntu-trusty.git repo on updates?
[14:40] <rtg> vmlintu, linux.git is where updates for the stable kernels that we maintain are kept. ubuntu-trusty.git is where those updates go before the kernel is built and published.
[14:45] <vmlintu> ok, it looks like the patch is not there in master-next
[15:00] <vmlintu> Is something needed for the stable patches to be merged? The breaking patch was introduced in 3.13 and the fix went in stable kernel 3.14.5. Should I send mail to the kernel-team mailing list?
[15:02] <rtg> vmlintu, you should send an email to stable@vger.kernel.org requesting that the patch be included in 3.13 stable.
[15:06] <vmlintu> rtg: thanks, I'll do that. I haven't really gotten myself familiar with the 3.13 stable process after Ubuntu kernel team took over it.
[15:06] <rtg> vmlintu, it is largely the same, just different maintainers
[15:08] <vmlintu> rtg: ok, that's good to know. Thanks for help!
[15:16] <jsalisbury> **
[15:16] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:16] <jsalisbury> **
[15:19] <rtg> jsalisbury, I suggest we cancel today's meeting as it conflicts with Mark's keynote.
[15:19] <jsalisbury> rtg, ok, will do.
[15:22] <jsalisbury> ##
[15:22] <jsalisbury> ## Kernel team meeting Canceled today
[15:22] <jsalisbury> ##
[15:51] <dsmythies> Hi, I wonder if anyone can help me. I am investigating an issue where (it appears as though) deferrable timers are being
[15:51] <dsmythies> deferred for to long (sometimes much too long) and to often.
[15:51] <dsmythies> What I have done is compiled with CONFIG_DEBUG_OBJECTS_TIMERS and I vaquely read somewhere that I also need my grub line
[15:51] <dsmythies> to include ignore_loglevel, which I have. However, I am not seeing any additional information anywhere, including dmesg.
[15:51] <dsmythies> Where would I find the additional information, if it is being generated? Or, what am I missing to generate it?
[16:38] <lim-ladm> hello, has anyone experience over  the e1000 bug with dropped packages on a intel 82574L Gigabit NIC?
[16:49] <shadeslayer> hi \o
[16:49] <jsalisbury> shadeslayer, o/
[16:51] <shadeslayer> jsalisbury: re https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310402 , would it be possible to change the scheduler to cfq?
[16:51] <ubot5> Ubuntu bug 1310402 in linux (Ubuntu) "Userland depends on ionice idle but default scheduler is "deadline". " [Wishlist,Triaged]
[16:51] <shadeslayer> or maybe even change it for Kubuntu? ( in which case, what kind of issues could we be facing )
[16:54] <jsalisbury> shadeslayer, there is allot of testing and discussion to decide on which scheduler to use by default.  You do have the ability to change the scheduler for your particular system.
[16:55] <shadeslayer> I understand that, but deadline doesn't work out for the needs of Kubuntu/KDE since the file indexer uses features such as io niceness which are not available via deadline
[16:58] <vHanda> jsalisbury: do you any data to backup why the change was made for the deskop?
[16:58] <jsalisbury> shadeslayer, we can request that the default scheduler be changed for the current or next development release, but I'm not so sure we could have it changed for any stable releases.
[17:00] <jsalisbury> vHanda, it was discussed at a prior UDS and should be in the minutes/notes from UDS.  
[17:01] <shadeslayer> jsalisbury: right, and any ideas on whether changing it specifically for Kubuntu would mess up anything else in foundations?
[17:01] <shadeslayer> i.e. is there stuff in foundations that expects the scheduler to be deadline
[17:02] <jsalisbury> shadeslayer, that's a good question.  I really don't know the answer off hand.  apw or cking do you happen to know ^^^  If not, it's something that would have to be researched.
[17:03] <vHanda> I had only found this - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1008400/comments/16
[17:03] <shadeslayer> roger
[17:03] <ubot5> Ubuntu bug 1008400 in linux (Ubuntu) "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,In progress]
[17:04] <apw> shadeslayer, so that was performance related, that cfq was not performing well and got switched to deadline generally
[17:04] <cking> but it is useful to know the corner cases where deadline may suck
[17:04] <apw> cking, sunds like it is not feature compatible with cfq
[17:04] <apw> shadeslayer, as this can be changed on the fly, i assume we can just change it at boot time
[17:04] <vHanda> apw: cfq was not performing well for desktop use or server?
[17:05] <apw> desktop, never has for server according to the server folk
[17:05] <apw> it was a key contributer to the going unresponsive for a long time issues we were seeing back at the change
[17:06] <cking> like all "defaults", it tries to do the best for most classes of use cases
[17:07] <vHanda> Could you please point me to some documentation regarding these "use cases" and data showing it was not performing well.
[17:08] <apw> vHanda, it was a fair time ago, iirc the graphs etc were sent to the kernel-team@ list and should be in the archives
[17:08] <vHanda> I have users complaining about the file indexer using a decent amount of IO and without niceness it renders there system quite slugish.
[17:08] <apw> vHanda, so change the default at boot time on kubuntu ?
[17:08] <apw> and be happy
[17:09] <apw> it is runtime configurable after all
[17:09] <shadeslayer> apw: right, for that, do you know if kubuntu can switch out deadline for cfq and things won't break apart ?
[17:10] <vHanda> I see this - https://lists.ubuntu.com/archives/kernel-team/2013-July/030360.html
[17:10] <apw> shadeslayer, you can change it at any time even under load and it should just work
[17:10] <vHanda> which is completely right but disregards mechanical rotational medium
[17:10] <vHanda> anyway, I'll look more
[17:10] <cking> vHanda, it's older than that, that was for a phone config
[17:11] <shadeslayer> apw: ack
[17:12] <shadeslayer> I'll have a look and try it get changed for 14.10
[17:12] <shadeslayer> for Kubuntu
[17:15] <shadeslayer> apw: btw is there a way to set the default scheduler as a config file ( as opposed to passing it at boot time )
[17:19]  * cking wonders if a udev rule will suffice, as mentioned in http://askubuntu.com/questions/78682/how-do-i-change-to-the-noop-scheduler
=== ivan\_ is now known as ivan\
[19:01] <apw> cking, yeah that is a good basis for changing it long term
[19:26] <ekarlso> any idea on when there will be a newer kernel out for 14.04 ? 
[19:28] <apw> ekarlso, newer as in more bug fixes or a later upstream version ?
[19:28] <ekarlso> apw: both would be nice...
[19:29] <apw> ekarlso, we issue bug fix updates about every 3 weeks, we will liklely backport the U kernel to 14.04 when that releases
[19:31] <ekarlso> apw: I keep seeing kernel panics with ovs and gre / vxlan because of forwarding on a openstack network node
[19:32] <apw> ekarlso, have you filed a bug about it?
[19:32] <ekarlso> apw: I have for the GRE stuff yes
[19:32] <smitty> The kernels newer than 3.13.0.24-generic will not recognize the Playstation 3 gamepad. 3.13.0.27-generic and 3.13.0.29-generic fail during boot with a dmesg error of "sony 0003:054C:0268.0003: can't set operational mode" and then "sony: probe of 0003:054C:0268.0003 failed with error -38".
[19:33] <apw> if you could throw the bug # in here in the discussion so i can pass it on to interested parties
[19:33] <ekarlso> but it sucks getting info on it because the trace is to long to record...
[19:33] <bjf> smitty, have you filed a bug? if it's a regression then you can work with jsalisbury and he'll help you find the bad commit
[19:34] <jsalisbury> smitty, I'll keep and eye out for the bug and help you with a bisect.
[19:34] <ekarlso> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591
[19:34] <ubot5> Ubuntu bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [High,Incomplete]
[19:35] <smitty> Thanks! I haven't filed a bug report as it seems a bit complicated. I've had to stick with the 3.13.0.24-generic kernel.
[19:36] <apw> smitty, you should be able to run "ubuntu-bug linux" to file a basic bug
[19:36] <bjf> ekarlso, it looks like that bug is waiting for you to test a kernel
[19:36] <bjf> ekarlso, see comment #6
[19:41] <smitty> apw, I suppose I have to be running the affected kernel right? I uninstalled it but I suppose I can reinstall it. "ubuntu-bug linux" does not seem to have a mechanism to add my own report to it. It just scans my system and goes directly to upload.
=== hatch__ is now known as hatch
[20:17] <smitty_> apw, I used "ubuntu-bug linux" to file a bug report. After several errors the process has completed. I couldn't continue to use an old kernel.
[20:22] <ekarlso> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591
[20:22] <ubot5> Ubuntu bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [High,Incomplete]
[20:22] <ekarlso> updated..
[20:22] <ekarlso> I've tested the 3.14 with GRE and VXLAN and also on 3.13 
[20:22] <ekarlso> it seems to panic on all 4 scenarios
[20:27] <ekarlso> apw: anything I can try ?
[20:27] <smitty_> jsalisbury, I filed a report bug #1328673 for the playstation 3 gamepad. Apparently it was a waste of time as someone beat me to it. Oops... maybe not.
[20:27] <ubot5> bug 1328673 in linux (Ubuntu) "Playstation 3 gamepad does not get a device created" [Undecided,New] https://launchpad.net/bugs/1328673
[20:34] <ekarlso> bjf: there it is...
[20:34] <bjf> ekarlso, thanks
[20:34] <ekarlso> bjf: any later kernel I can tset ?
[20:34] <ekarlso> 3.15 ? 
[20:35] <ekarlso> this is getting pretty annoyin
[20:35] <bjf> ekarlso, you certainly could try a utopic kernel
[20:35] <ekarlso> is that installable on trusty ? 
[20:35] <bjf> ekarlso, the kernel is, yes. you need to pull down the .debs and use dpkg to install them
[20:36] <bjf> ekarlso, amd64?
[20:37] <ekarlso> bjf: yes
[20:37] <bjf> ekarlso, https://launchpad.net/ubuntu/+source/linux/3.15.0-5.10/+build/6062393
[20:37] <ekarlso> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/ ;)
[20:38] <bjf> ekarlso, you can try that also
[20:38] <bjf> ekarlso, that would actually be better
=== DalekSec_ is now known as DalekSec
=== halfie_ is now known as halfie
=== neunon_ is now known as neunon
[21:15] <ekarlso> bjf: so obviously the thing that helps is setting gro / gso off on the NIC that is the -o interface in iptables for the masquerade
[21:16] <bjf> ekarlso, that "fixes" it for you as well?
[21:17] <bjf> ekarlso, the 3.15 kernel didn't help ?
[21:17] <ekarlso> bjf: yah, I was doing it for the wrong iface
[21:17] <ekarlso> bjf: nop