[08:54] <apw> moin
[08:56] <smb> mornings
[08:56] <cking> morning
[08:57] <smb> (kernel devs crawling out from under their rocks)
[08:58] <cking> copious amounts of strong coffee required today
[08:58] <apw> are you dissing my rock?
[08:58] <apw> cking, and some _heat_ it is cold
[08:59] <apw> there is ice on my grass
[08:59] <cking> 'tis cold ere too
[09:01]  * cking has a audio issues today, I was faffing around with a new MIDI USB dongle and managed to kill audio
[09:02] <smb> sound waves are frozen?
[09:03] <smb> apw, No we all love our rocks
[09:03] <tseliot> I have a stupid question: if the driver fails to bind, it is the driver's fault, right? (linux 3.8) It's unlikely that there's a bug in the local_pci_probe() call, right?
[09:04] <apw> tseliot, it sounds unlikely for sure, drivers like to fail to bind, it is their modus operandi, as they are commonly offered everything
[09:05] <tseliot> apw: right, and we're talking about the broadcom driver here...
[09:06] <apw> oh man, man o man
[09:06] <apw> that thing exhibits a manevolance i have only seen else in (sci-fi) extra-terestrials
[09:07] <tseliot> :D
[09:09]  * smb also wonders what exactly fails to bind means (where, what call, return code?)
[09:13] <tseliot> smb: https://launchpadlibrarian.net/155781369/for-comment-21-lp-bug-1247712.log
[09:15]  * smb was hoping for some higher level describtion that apport vommit... *sigh*
[09:15] <tseliot> and the bug report https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1247712
[09:15] <ubot2> Launchpad bug 1247712 in linux-lts-raring (Ubuntu Precise) "Unable to install Broadcom STA wireless dirver on 3.8.0-33 / 3.8.0-29 kernel via jockey-gtk" [Undecided,New]
[09:16] <tseliot> smb: basically jockey writes to the sysfs tree to unbind and then rebind the driver after the driver installation
[09:19] <smb> tseliot, Supposedly that is "simpler" than unloading the other broadcom modules after blacklisting them? 
[09:20] <tseliot> smb: I'm not sure, as I didn't design that part of Jockey
[09:20] <smb> So it could be that its a problem with the other driver and unbinding. But who knows. (and not sure I want to).
[09:20] <tseliot> hehe
[09:20] <smb> Feels like the only two relevant error messages are 
[09:20] <apw> tseliot, which driver does it try and unbind when brcmwl is loaded
[09:20] <smb> [  526.263040] ERROR @wl_dev_intvar_get : error (-1)
[09:20] <smb>  [  526.263045] ERROR @wl_cfg80211_get_tx_power : error (-1)
[09:21] <tseliot> apw: I'm not sure as I have no device with that driver here but the log reports "[last unloaded: bcma]"
[09:22] <smb> Yeah, the lspci also shows those two as possible alternatives (wl and bcma)
[09:23] <apw> ok so there isn't a third or anything, the world of brcm is complicated these days
[09:23] <tseliot> smb: right, and that (wl_dev_intvar_get, etc.) should be caused by "wl" (I assume)
[09:24] <smb> apw, Yeah, I don't know like that other thing you get with b43
[09:25] <smb> ... ssb I think
[09:26] <tseliot> I should probably upload a new broadcom driver and see what happens
[09:26] <tseliot> after all, we have a stable release now
[09:29] <apw> tseliot, ok the EIP is 'somewhere else' not in a bit we have symbols for, so it is most likely we moved on from pci_probe_local
[09:31] <apw> smb, does one of you or me have a 4313, i know i have a 4312 somewhere, was it you who had the 13 /
[09:31] <apw> ?
[09:32] <smb> apw, If I could remember...
[09:32] <apw> perhaps in your previous travel lappy ?
[09:32] <smb> It certainly had to use wl but...
[09:34] <smb> Ok, it says 4312, too
[09:38] <tseliot> I'm still looking for a device for local testing
[09:39] <tseliot> I wish it were easier to find one
=== fmasi_afk is now known as fmasi
[10:10] <brendand> cking, just a quick question - if updating /sys/class/backlight/acpi_video0/brightness doesn't do anything, does that sound like busted firmware, or could it be a kernel bug too?
[10:10] <cking> brendand, it's hard to tell w/o more info really
[10:11] <brendand> cking, that's all i've got right now
[10:12] <cking> brendand, i guess the best bet is file a bug and it can be investigated
[10:12] <cking> but I guess it's more likely a firmware bug than anything
[10:27] <mjg59> brendand: Kernel bug
[10:27] <mjg59> brendand: Especially if it's Intel graphics
[10:27] <mjg59> The ACPI video interface shouldn't be used on Windows 8 systems
[10:29] <brendand> mjg59, but the kernel docs say that the firmware interface should be used when available?
[10:30] <brendand> mjg59, which happens to be acpi_video0
[10:31] <mjg59> brendand: Yes. The kernel shouldn't be exposing that interface on Windows 8 systems. But there are bugs in the i915 backlight driver and Intel haven't fixed them.
[10:31] <brendand> mjg59, most interesting
[10:31] <brendand> mjg59, so it's still correct to use the interface where it exists
[10:31] <brendand> mjg59, and the bug is that it does?
[10:33] <zyga> mjg59: hi
[10:33] <zyga> mjg59: is there anything that should be added to the kernel documentation on backlight to make this issue cleaer?
[10:35] <mjg59> brendand: Correct
[10:35] <mjg59> zyga: No, the bug should just be fixed
[10:40] <mjg59> But that needs someone to actually commit to fixing the i915 backlight code
[10:40] <zyga> mjg59: is there a bug on that open anywhere that you know of?
[10:41] <mjg59> Unsure off hand
[10:41] <mjg59> It was discussed on LKML
[10:43] <cking> that narrows it down, some discussion on LKML
[10:46] <cking> https://lkml.org/lkml/2013/6/9/161 perchance?
[10:51] <mjg59> Yeah, followed by the complaints that saw it reverted
[10:52] <cking> ok, I see intel needs to play catchup on this, sigh
[10:56] <brendand> mjg59, what range of hardware does this affect? haswell only?
[11:04] <mjg59> brendand: And some Ivy Bridge
[11:04] <mjg59> There's certainly an argument that it's a firmware bug, in that the firmware's exposing an interface that doesn't work
[11:05] <mjg59> But if Windows doesn't use a firmware interface then it's not going to be tested
[11:05] <mjg59> And there's no reasonable expectation that it'll work
[11:07] <mjg59> So the kernel really shouldn't attempt to use it
[11:14] <apw> amen to that
[11:14] <cking> so much borkage
[11:18] <apw> bios is junk, shocker
[11:18] <brendand> this is the bug we raised btw: https://launchpad.net/bugs/1250401
[11:18] <ubot2> Launchpad bug 1250401 in linux-lts-raring (Ubuntu) "[Dell Inspiron 5737] brightness could not be controlled by the indicator applet "System settings -> Brightness and Lock"" but sysfs works" [Undecided,New]
[11:26] <cking> apw, we need a way to test for that for sure
[11:46] <apw> good old dell firmware
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
=== fmasi is now known as fmasi_afk
[19:50]  * rtg -> lunch
[20:01] <cwillu_borken> Is there a debug package for the mainline repo kernels available anywhere?
[20:02] <cwillu_borken> the btrfs folks want me to run a systemtap script to troubleshoot an issue I'm having, but it complains about missing DWARF information
[20:03] <apw> cwillu_borken, nope we don't make those, though the source can be reconstruced and you could make them
[20:04] <cwillu_borken> that's too bad
[20:04]  * cwillu_borken starts compiling a kernel
[20:04] <apw> they are half a gig per build, they are just tooo big to have large numbers thereof
[20:06]  * cwillu_borken buys apw a 2tb drive to hold them, because that's obviously all that's needed to keep them around right? ;p
[20:08] <rtg> apw, I'm rebasing again after the vfs and net merge. I dropped all aufs patches because of the extensive vfs changes 
[20:09] <apw> rtg, thanks for the warnig
[20:09] <rtg> apw, build testing, then I'll push 
[20:14] <rtg> apw, looks like overlayfs is gonna have issues as well
[20:55] <apw> rtg, no supprises, something for me for the mornign
[20:55] <rtg> apw, yep
[21:57] <manjo> is there a kernel release milestones wiki for trusty?
[21:58] <bjf> manjo, was there one for saucy?
[21:58] <manjo> bjf, no I think the last one was raring 
[21:58] <bjf> manjo, you mean a release schedule?
[21:58] <manjo> right release schedule 
[21:59] <Sarvatt> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[21:59] <bjf> manjo, what Sarvatt said
[21:59] <manjo> cool thanks 
[22:00] <manjo> looks like the kernel wiki stop updating those links since raring :) 
[22:01] <bjf> manjo, there used to be an interlock schedule with had the sru cadence schedule on it
[22:01] <manjo> bjf, so drop dead date for patches would be March 27th ? 
[22:01] <manjo> ie sometime before final beta freeze
[22:01] <bjf> manjo, yes i think so
[22:01] <manjo> cool thanks 
[23:38] <xnox> bjf: the interlock schedule was mostly out of date, most of the time. As it was updated by hand, and was out-of-sync with every authoritative sources of information.
[23:39] <xnox>  https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule <- is the only authoratative for Trusty release. Same naming pattern goes for all other releases.