[01:34] <bhuey> Is there a wiki on making a new flavour correctly ? I just copied the .generic file over and renamed it
[01:35] <bhuey> Enabling a kernel option creates the problem with the module failing to load
[01:35] <bhuey> I'm obviously missing something here but I don't know what it is
[13:37] <mterry> Hello!  Who is involved with the Touch kernels?  I *think* it's missing ACL support and wanted to check in with someone about the config we use there
[13:40] <apw> mterry, which kernels specificially ?
[13:41] <mterry> apw, I guess I happen to be testing on the arale device.  So whatever kernel we ship there.  But I haven't done a survey of all our supported devices to test kernel configs.  Are the configs we use so device-specific?
[13:43] <apw> mterry, yes, the kernels are mostly very different, and so there is a lot of manual work in that
[13:43] <mterry> apw, OK.  Where could I go and look at the config we use to build one of these kernels with?
[13:44] <apw> mterry, i'll find out and let you know
[15:41] <xnox> why doesn't 9pnet_virtio module autoload upon trying to mount 9p virtio filesystem....?
[15:41] <apw> xnox, dunno maete
[15:42] <apw> maybe it cannot be detected
[15:46] <xnox> it can be....
[15:48] <apw> that combination of things is a bit wierd to put it mildly, a virtio filesystem
[15:50]  * apw goes for supplies
[15:53] <xnox> apw, oh, it's racy on boot
[15:54] <xnox> somehow systemd tries to mount it before it's ready.... as post-boot i can restart .mount unit and it just works.
[17:40] <Gnar> https://youtu.be/0yJn-5hpU94
[18:18] <gQuigs> shouldn't regressions have a higher importance? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719
[19:31] <bhuey> hi
[19:33] <apw> gQuigs, regressions are indeed of importance to us
[19:34] <apw> gQuigs, that wasn't marked (correctly) as a regression, i've marked it up
[19:34] <apw> jsalisbury, ^ that one needs to be on our list
[19:34] <gQuigs> apw: thanks
[19:35]  * bhuey reasks question
[19:35] <bhuey> I created a flavor and I'm ahving problems loading the nvidia propreitary driver
[19:35]  * gQuigs is bisecting now, but still on first kernel build (slow machine, via VPN)
[19:36] <bhuey> Builds and installs ok but I don't know what how to get the module to load without complaining
[19:36] <bhuey> Do I needd to do something in addition to just creating a new flavor file ?
[19:36] <bhuey> and configuring the .config of those kernels ?
[19:37] <bhuey> I did this to enable a kernel parameter for testing that isn't on in a normal Ubuntu kernel
[19:37] <bhuey> but it seems to be causing ABI issues
[19:44] <apw> bhuey, that sounds like a description of a debian kernel flavour
[19:45] <apw> bhuey, but if it is building you are not throwing abi issues, that would prevent the build
[19:45] <apw> bhuey, you would be better telling us what error you see when you try and insert the module
[19:46] <bhuey> apw: yeah this is kind of baffling as I odn't much about kernel packaging
[19:46] <bhuey> We're building it locally here and need the Nvidia drivers for CUDA development
[19:47] <bhuey> Basically, we compile 4.4.8 for trusty
[19:47] <bhuey> lowlatency kernel as well
[19:47] <bhuey> the generic one works fine, same for lowlatency but I added a kernel option to enable lock stat and the nvidia module fails to load at runtime
[19:48] <bhuey> compiles and installs with no complains
[19:48] <bhuey> Have zero idea what's going on to push this forward
[19:48] <bhuey> apw: thanks for any help btw
[19:49]  * bhuey waits
[19:51] <apw> bhuey, is there anything in dmesg at the point where you probe it in?
[19:54] <jsalisbury> apw ack
[19:57] <jsalisbury> gQuigs, are you going to be doing a bisect?  
[19:58] <gQuigs> jsalisbury: in progress, but if anyone has a faster machine with this issue they might finish first
[19:58] <gQuigs> still on the first kernel build
[19:59] <jsalisbury> gQuigs, I have build servers that can build a kernel in 20 minutes or so.  If you send me the current bisect log, I can build the kernels for you and post a link to them in the bug?
[20:01] <gQuigs> jsalisbury: sure thing - http://pastebin.ubuntu.com/20352223/
[20:02] <gQuigs> it's just the first build so I assumed that rebuilding 4.4.0-28 and 4.4.0-31 wasn't needed
[20:02] <jsalisbury> gQuigs, I'll build that kernel and post it in the bug. If you test it and post the results, I can then update the bisect and build the next one.
[20:03] <gQuigs> jsalisbury: feel free to just ping me here, I'll be around
[20:03] <gQuigs> thanks!
[20:03] <jsalisbury> gQuigs, 
[20:03] <jsalisbury> gQuigs, ack
[20:09] <jsalisbury> gQuigs, Is the issue fixed in the upstream 4.4.15 kernel?  
[20:10] <jsalisbury> gQuigs, if it is, it might be better for us to reverse bisect to find the commit that fixes things
[20:10] <gQuigs> jsalisbury: yea  4.4.15 works fine, but keep in mind I haven't found an upstream kernel to have the issue to begin with
[20:10] <gQuigs> err
[20:11] <jsalisbury> gQuigs, ahh, ok.  Then it is probably due to a SAUCE commit.
[20:12] <apw> gQuigs, have you tested the -proposed kernel, i _thought_ that had 4.4.15 applied
[20:12] <jsalisbury> gQuigs, The xenail -proposed kernel alread has the 4.4.15 updates.  It might be worth a shot testing it while the bisect kernel builts.
[20:12] <jsalisbury> heh, collision.
[20:12] <gQuigs> will cancel my build and try that
[20:12] <jsalisbury> gQuigs, great.  and my build is going
[20:21] <gQuigs> 4.4.0-32-generic #51 in proposed has the issue as well
[20:22] <jsalisbury> gQuigs, Ok, a bisect is the best route then.
[20:23] <gQuigs> I'm guessing it's related to the series under - cgroupfs mounts can hang
[20:23] <gQuigs> as the NFS failure says - [80914.821533] <-- nfs_xdev_mount() = -1 
[20:23] <gQuigs> [80914.821535] nfs_do_submount: done 
[20:23] <gQuigs> [80914.821536] <-- nfs_do_submount() = ffffffffffffffff 
[20:23] <gQuigs> [80914.821577] <-- nfs_d_automount(): error -1
[20:24] <jsalisbury> gQuigs, First kernel is done building.  You can get it here:
[20:24] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1603719/
[20:27] <jsalisbury> gQuigs, apw There are only 6 SAUCE patches between 28.47 and 31.50: 
[20:28] <jsalisbury> 9ef55b6 UBUNTU: SAUCE: drm: check for supported chipset before booting fbdev off the hw
[20:28] <jsalisbury> 7b97729 UBUNTU: SAUCE: (noup) Update zfs to 0.6.5.6-0ubuntu10
[20:28] <jsalisbury> 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches
[20:28] <jsalisbury> 765ab2f Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a cgroup namespace"
[20:28] <jsalisbury> 3988fb7 Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user namespace when mounting"
[20:28] <jsalisbury> f256722 Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the user ns which owns the ipc ns"y
[20:28] <jsalisbury> guess I should have pastbin'd that
[20:29] <jsalisbury> http://paste.ubuntu.com/20356124/
[20:32] <jsalisbury> gQuigs, apw three are reverts, so I'm going to assume they probably didn't cause the bug.  Could be: 
[20:32] <jsalisbury> 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches
[20:32] <gQuigs> jsalisbury: that kernel has the issue; git bisect bad
[20:32] <apw> jsalisbury, that is paired with the three reverts
[20:32] <jsalisbury> apw, hmm
[20:33] <apw> sforshee, ^
[20:33] <jsalisbury> apw, maybe I should revert 302cabb and build a test kernel with those other three reverts reverted
[20:35] <apw> jsalisbury, i'd say so
[20:36] <jsalisbury> apw, sforshee crap, f256722 doesn't revert cleanly.
[20:38] <apw> jsalisbury, which order are you reverting them, that the last one i assume
[20:39] <jsalisbury> apw, yeah.  The last one reverted first.
[20:40] <apw> jsalisbury, must be something on top needing revert first
[20:40] <jsalisbury> apw, I'll see what other commits happened around it
[20:40] <apw> prolly the other two namespace ones
[20:40] <jsalisbury> apw, yeah, trying to find it now
[20:41] <jsalisbury> apw, trying those two namespace ones
[20:42] <jsalisbury> apw, there are 5 other namespace ones
[20:43] <jsalisbury> apw: http://paste.ubuntu.com/20358102/
[20:43] <jsalisbury> actually 6
[20:44] <jsalisbury> apw, maybe I'll just revert the whole lot
[20:44] <sforshee> jsalisbury, apw: "(namespace) vfs: Pass data, ns, and ns->userns to mount_ns" touches nfs, but I'm not seeing how it would cause that problem
[20:44] <sforshee> I'd think if there was a problem it would happen at mount time
[20:45] <gQuigs> sforshee: it is "mount" time, just submount time
[20:45] <gQuigs> for example I can access /cfs/home,  but not not /cfs/share
[20:46] <sforshee> gQuigs: but does that actually trigger a separate filesystem mount operation?
[20:46] <gQuigs> see the NFS error I posted above (nfs_xdev_mount),  not sure what that translates to elsewhere
[20:47] <gQuigs> but according to NFS, yes...
[20:51] <jsalisbury> sforshee, gQuigs I'll build a quick test kernel with a5abdcb for a test
[20:53] <jsalisbury> with a5abdcb reverted
[20:53] <gQuigs> ah, that makes more sense :)
[20:53] <jsalisbury> gQuigs, heh, I typed it then looked at another monitor :-)
[20:54] <jsalisbury> gQuigs, should be ready in about 10 minutes
[20:54] <gQuigs> awesome, thanks!
[21:00] <sforshee> it does do some mount stuff, but I'm still not seeing how that's going to end up through the call path which now has a capability check on the net ns
[21:02] <sforshee> I wonder if it has more to do with moving where sb->s_fs_info gets set
[21:09] <bhuey> apw: not that I can tell. The Xorg logs shows that it's unable to load the device. I'll have to reboot back into that kernel if I want to find it in the logs
[21:09] <bhuey> apw: should I do that ?
[21:14] <jsalisbury> gQuigs, test kernel is ready.  Same location:
[21:14] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1603719/
[21:14] <sforshee> oh, I think it's sget
[21:17] <sforshee> yeah, it almost certainly is. The internal mount doesn't use MS_KERNMOUNT, and now sget has a capability check if that isn't used
[21:20] <gQuigs> sforshee: jsalisbury the reverted kernel still fails
[21:21] <sforshee> gQuigs: that's what I'd expect if my suspicions are correct
[21:21] <sforshee> I'm going to try to reproduce locally, shouldn't be difficult, then I can test my theory
[21:22] <jsalisbury> gQuigs, sforshee ack
[21:46] <gQuigs> going away for a bit, will test anything else when I get back later tonight
[21:46] <gQuigs> thanks!