=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
[07:25] <smb> morning
[07:32] <smb> tseliot, You were the one doing i915_bdw (trying not to confuse the two people starting with t)... 
[07:32] <tseliot> smb: I think that was tjaalton
[07:32] <smb> dammit :-P
[07:32] <tseliot> ;)
[07:33] <smb> So maybe tjaalton might be interested to hear about duplicate symbols warnings... Maybe its already known, just noticed this morning when booting my server
[07:36] <smb> [   21.626511] i915_bdw: exports duplicate symbol i915_release_power_well (owned
[07:36] <smb>  by i915)
[07:36] <smb> [   21.643735] WARNING: CPU: 0 PID: 69 at /build/buildd/linux-3.13.0/drivers/gpu
[07:37] <smb>  /drm/i915/intel_pm.c:5817 i915_request_power_well+0x77/0x80 [i915]()
[07:37] <smb> Ok, the latter is something that the generic i915 has to deal with I guess
[07:46] <tjaalton> ah
[07:48] <tjaalton> nah the i915_bdw one just needs to be renamed
[08:04] <smb> tjaalton, The warning is in request_power_well and I think the haswell should use the stoack driver. So that part is right. Just something it does not like there which cannot be blamed on the _bdw I think
[08:04] <smb> the duplicate symbol is release not request
[08:09] <tjaalton> smb: well, hda_i915.c needs request/release, and since _bdw is newer it probably should have it's own symbol?
[08:09] <tjaalton> and do something like in ba92f7e81ff883212021c2614aea99681c156e9a
[08:14] <smb> tjaalton, I agree for the i915_release_power_well. Just wanted to say that the second thing comes from the i915 driver (not the bdw) and could be unrelated
[08:17] <smb> WARN_ON(!hsw_pwr) ... not sure this could be  the fault of i915_bdw defining release_power_well as well
[08:19] <tjaalton> I'm just grepping through the code
[08:20]  * apw looks grumpy and tired
[08:21] <smb> apw, What happened to you?
[08:21] <apw> morning?
[08:42] <tjaalton> smb: so yes i915 calls that but it's the audio driver where it'll be hit frequently when trying to use audio-over-hdmi(/dp)
[08:44] <smb> Ah, ok. And that machine has no hdmi cable anywhere near it. :)
[08:48] <tjaalton> yeah :)
[09:58] <freespirit-girl> Hello. I have a question .. I am trying to upgrade Ubuntu using the commandline.. When i get to tripwire i am asked to sign in using my tripwire passphrass.. 
[10:00] <freespirit-girl> so i enter in my root password.. Is the password different for tripwire than my root
[10:04] <apw> freespirit-girl, hmm, i am not sure i know anything about tripwire, you might ask on #ubuntu-server they may know
[10:06] <freespirit-girl> is Ubuntu server a trustworthy irc channel?
[10:06] <apw> freespirit-girl, #ubuntu-server is as trust-worthy as this one yes
[10:06] <freespirit-girl> thsnkyou
[10:07] <freespirit-girl> let me ask
[13:38] <rtg> smoser, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1309112/comments/11
[13:38] <ubot2> Launchpad bug 1309112 in linux (Ubuntu) "x120e does not resume from suspend" [Medium,Confirmed]
[13:41] <smoser> rtg, http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/8fuj10uc.txt
[13:41] <smoser> thats the changelog
[13:42] <smoser> and 1.16 does explicitly mention 'S3 sleep'
[13:42] <smoser> but i had exactly zero issue with saucy.
[13:45] <rtg> smoser, you know they weren't fixing S3 issues for Linux.
[13:45] <smoser> well, clearly.
[13:46] <smoser> is there some obvious way i'm missing of how i would download 1.16 ?
[13:46] <rtg> smoser, you mean 1.15 ? damned if I know. never done it myself.
[13:46] <smoser> i seem to have lost my local copy of that cd :)
[13:46] <smoser> yeah, i geuss i did mean 1.15
[13:47] <rtg> smoser, reach out to one of our HWE dudes ?
[13:47] <smoser> i really dont understand the problem. that link above very clearly says:
[13:47] <smoser> LIMITATIONS
[13:47] <smoser>   Nothing.
[13:47] <smoser> :)
[13:48] <smoser> i'll see if i can't dig something up. and maybe try going to 1.17.
[13:48] <rtg> smoser, I'm betting it was only tested against Windows.
[13:50] <smoser> well, yeah, i'm guessing then enabled windows 8.
[13:50] <smoser> as the changelog there says.
[13:51] <rtg> smrun fwts o it. you'll prolly come up with a zillion errors
[13:51] <rtg> smoser, run fwts on it. ^
[13:53] <smoser> fwts ?
[13:53] <smoser> ah. i see https://wiki.ubuntu.com/Kernel/Reference/fwts
[13:53] <rtg> smoser, firmware test suite developed by our very own cking
=== ming is now known as Guest7729
[14:15] <cking> and the kind folk in HWE too
[15:38] <rtg> apw, feel free to comment on https://lists.ubuntu.com/archives/kernel-team/2014-April/041938.html
=== sz0_ is now known as sz0`
=== sz0` is now known as sz0_
[16:39] <apw> rtg, ack
[16:48] <BenC> infinity: What’s the current bug for linux-ppc saucy update?
[16:50] <bjf> BenC, bug 1301501
[16:50] <ubot2> Launchpad bug 1301501 in Kernel SRU Workflow "linux-ppc: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1301501
[16:51] <BenC> bjf: Thanks
[16:51] <BenC> Odd that https://bugs.launchpad.net/ubuntu/+source/linux-ppc doesn’t show that bug
[16:52] <BenC> +bugs 
[16:55] <infinity> https://bugs.launchpad.net/ubuntu/saucy/+source/linux-ppc
[16:55] <infinity> Series-targetted bugs don't show up under just "ubuntu".  A misfeature, I'd say.
[17:02] <BenC> I’d agree
[17:10] <BenC> rtg: I may get you to redact that PAMU disable
[17:11] <rtg> ?
[17:11] <BenC> Newer PAMU requires different device-tree node for fsl-pamu, so I’m testing that, which would make it a hardware change for us, not a kernel change
[17:11] <rtg> ack
[17:11] <BenC> s/hardware/firmware/
[17:11] <rtg> just lemme know
[17:11] <BenC> Will do, thanks
[17:11] <rtg> soon
[17:19] <BenC> rtg: Rebooting now to test...
[17:20] <rtg> BenC, we just to resolve it before bjf turns the crank on the next SRU Q/A pass
[17:20] <bjf> rtg, BenC, that's next week
[17:21] <BenC> Well then I’ll be plenty early on this :)
[17:24] <BenC> bjf, rtg: Updates to device tree did not fix it, so leave it in, please.
[17:24] <rtg> thats easy enough :)
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== NoNameYet_xnox is now known as xnox