[00:05] https://cxsecurity.com/issue/WLB-2016050014 === JanC is now known as Guest22660 === JanC_ is now known as JanC [08:02] ejat, that one is known indeed, and the fix ought to be out in -security already [08:03] apw: ok thanks === adrianalves is now known as adrian [13:02] Who is the resident expert on wireless kernel modules ? [13:03] caribou, sforshee [13:03] rtg: thanks [13:04] I've been hunting a nasty wifi bug on my desktop @home (Trusty & Xenial) and the only fix I found is to get some module source on github & install it with dkms [13:04] same problem on realtek & ralink chips [13:05] so I'm curious to understand why such fix is not in the distro [13:05] sforshee: ^^ [13:06] did you report a bug? [13:09] JanC: I've seen a few while investigating the issue [13:10] JanC: none actually brought a solution; I thought that upgrading to Xenial would help but it didn't [13:11] JanC: installing https://github.com/pvaret/rtl8192cu-fixes does nail it down, now I'm about to look at what has changed [13:16] caribou: what's in the distro kernel is generally just what's in upstream linux. I can't say why any fixes there aren't making their way upstream. [13:17] sforshee: looking at the git repo, it looks like work that has never been submitted upstream [13:17] sometimes "fixes" for some hardware break other hardware though, and that's generally not considered acceptible [13:18] sforshee: true, that would explain why it is kept outside [13:18] it's a driver from Realtek that according to README only works on one specific chip and wasn't ported to recent kernels [13:20] I don't really recommend people use realtek or ralink because neither does a great job of making things work well upstream [13:20] looks like driver that was written for a specific device really [13:21] JanC: then it explains why it's kept there [13:21] as e.g. it doesn't support multiple antennas properly & such? [13:22] it might still be useful for somebody wanting to improve the drivers in upstream linux, dunno [13:22] sforshee: well, it's the builtin chip so not much choice [13:22] one thing though, it used to work fine for a long time (even during Trusty's early days) [13:22] caribou: it's not on PCIE? [13:23] JanC: ralink is a wifi dongle that I used to diagnose further; realtek is native on the desktop [13:25] or the other way around, I'd have to check [13:26] well, your clarifications pretty much explains why I had to chase it down [13:27] my only solution to identify the problem would be to identify a working kernel then bisect [13:28] JanC: sforshee: thanks for the clarifications btw [13:29] there seem to be several more drivers like that on github :-/ [13:29] for other Realtek chips etc. [17:55] jsalisbury: fyi, the upstream kernel still had the bug :\ [17:56] jsalisbury: in trying it I noticed that I couldn't use sbuild since overlayfs wasn't in the kernel. I thought the upstream kernels had overlayfs available. would it be possible to adjust the kernel config for the upstream kernels to include overlayfs? [18:51] jdstrand, I can look into it. I'm not sure off hand though. Maybe apw has an idea? [18:52] jdstrand, thanks for testing the latest mainline. I'll build the next kernel for the bisect. [18:53] jdstrand, i'd expect overlayfs to be included, _but_ you might find you are using old format overlayfs which only ubuntu lkernles support [18:53] as in using overlayfs not overlay [18:53] * jdstrand is just using sbuild [18:54] I don't recall changing anything, but its been a while [18:54] yeah sbuild i thnk support both, and it would remember which you first used [18:54] union-type=overlayfs [18:54] now how did you tell, erm, in the overlay directory it stores a flag [18:54] so thats V1 support with the old whiteouts, so a mainline kernel cannot mount it [18:55] you can make that overlay and it ought to work with both [18:55] obviously persistant ones get broken, but ephemerals for sbuild should just be ok [18:59] interesting [19:00] apw: ok, thanks!