| apw | moin | 08:54 |
|---|---|---|
| smb | mornings | 08:56 |
| cking | morning | 08:56 |
| smb | (kernel devs crawling out from under their rocks) | 08:57 |
| 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:58 |
| apw | there is ice on my grass | 08:59 |
| cking | 'tis cold ere too | 08:59 |
| * cking has a audio issues today, I was faffing around with a new MIDI USB dongle and managed to kill audio | 09:01 | |
| smb | sound waves are frozen? | 09:02 |
| 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:03 |
| 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:04 |
| tseliot | apw: right, and we're talking about the broadcom driver here... | 09:05 |
| 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:06 |
| tseliot | :D | 09:07 |
| * smb also wonders what exactly fails to bind means (where, what call, return code?) | 09:09 | |
| tseliot | smb: https://launchpadlibrarian.net/155781369/for-comment-21-lp-bug-1247712.log | 09:13 |
| * 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:15 |
| tseliot | smb: basically jockey writes to the sysfs tree to unbind and then rebind the driver after the driver installation | 09:16 |
| smb | tseliot, Supposedly that is "simpler" than unloading the other broadcom modules after blacklisting them? | 09:19 |
| 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:20 |
| tseliot | apw: I'm not sure as I have no device with that driver here but the log reports "[last unloaded: bcma]" | 09:21 |
| smb | Yeah, the lspci also shows those two as possible alternatives (wl and bcma) | 09:22 |
| 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:23 |
| smb | apw, Yeah, I don't know like that other thing you get with b43 | 09:24 |
| smb | ... ssb I think | 09:25 |
| 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:26 |
| 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:29 |
| 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:31 |
| 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:32 |
| smb | Ok, it says 4312, too | 09:34 |
| tseliot | I'm still looking for a device for local testing | 09:38 |
| tseliot | I wish it were easier to find one | 09:39 |
| === fmasi_afk is now known as fmasi | ||
| 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:10 |
| brendand | cking, that's all i've got right now | 10:11 |
| 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:12 |
| 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:27 |
| brendand | mjg59, but the kernel docs say that the firmware interface should be used when available? | 10:29 |
| brendand | mjg59, which happens to be acpi_video0 | 10:30 |
| 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:31 |
| 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:33 |
| mjg59 | brendand: Correct | 10:35 |
| mjg59 | zyga: No, the bug should just be fixed | 10:35 |
| 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:40 |
| mjg59 | Unsure off hand | 10:41 |
| mjg59 | It was discussed on LKML | 10:41 |
| cking | that narrows it down, some discussion on LKML | 10:43 |
| cking | https://lkml.org/lkml/2013/6/9/161 perchance? | 10:46 |
| mjg59 | Yeah, followed by the complaints that saw it reverted | 10:51 |
| cking | ok, I see intel needs to play catchup on this, sigh | 10:52 |
| brendand | mjg59, what range of hardware does this affect? haswell only? | 10:56 |
| 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:04 |
| 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:05 |
| mjg59 | So the kernel really shouldn't attempt to use it | 11:07 |
| apw | amen to that | 11:14 |
| cking | so much borkage | 11:14 |
| 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:18 |
| cking | apw, we need a way to test for that for sure | 11:26 |
| apw | good old dell firmware | 11:46 |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| * rtg -> lunch | 19:50 | |
| cwillu_borken | Is there a debug package for the mainline repo kernels available anywhere? | 20:01 |
| 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:02 |
| apw | cwillu_borken, nope we don't make those, though the source can be reconstruced and you could make them | 20:03 |
| 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:04 |
| * 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:06 | |
| rtg | apw, I'm rebasing again after the vfs and net merge. I dropped all aufs patches because of the extensive vfs changes | 20:08 |
| apw | rtg, thanks for the warnig | 20:09 |
| rtg | apw, build testing, then I'll push | 20:09 |
| rtg | apw, looks like overlayfs is gonna have issues as well | 20:14 |
| apw | rtg, no supprises, something for me for the mornign | 20:55 |
| rtg | apw, yep | 20:55 |
| manjo | is there a kernel release milestones wiki for trusty? | 21:57 |
| 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:58 |
| Sarvatt | https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule | 21:59 |
| bjf | manjo, what Sarvatt said | 21:59 |
| manjo | cool thanks | 21:59 |
| manjo | looks like the kernel wiki stop updating those links since raring :) | 22:00 |
| 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 | 22:01 |
| 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:38 |
| xnox | https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule <- is the only authoratative for Trusty release. Same naming pattern goes for all other releases. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!