| bhuey | Is there a wiki on making a new flavour correctly ? I just copied the .generic file over and renamed it | 01:34 |
|---|---|---|
| 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 | 01:35 |
| 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:37 |
| apw | mterry, which kernels specificially ? | 13:40 |
| 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:41 |
| 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:43 |
| apw | mterry, i'll find out and let you know | 13:44 |
| xnox | why doesn't 9pnet_virtio module autoload upon trying to mount 9p virtio filesystem....? | 15:41 |
| apw | xnox, dunno maete | 15:41 |
| apw | maybe it cannot be detected | 15:42 |
| xnox | it can be.... | 15:46 |
| apw | that combination of things is a bit wierd to put it mildly, a virtio filesystem | 15:48 |
| * apw goes for supplies | 15:50 | |
| xnox | apw, oh, it's racy on boot | 15:53 |
| xnox | somehow systemd tries to mount it before it's ready.... as post-boot i can restart .mount unit and it just works. | 15:54 |
| Gnar | https://youtu.be/0yJn-5hpU94 | 17:40 |
| gQuigs | shouldn't regressions have a higher importance? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719 | 18:18 |
| ubot5 | Launchpad bug 1603719 in linux (Ubuntu) "[regression] NFS client: access problems after updating to kernel 4.4.0-31-generic" [Low,Confirmed] | 18:18 |
| bhuey | hi | 19:31 |
| apw | gQuigs, regressions are indeed of importance to us | 19:33 |
| 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:34 |
| * 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:35 | |
| 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:36 |
| 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:37 |
| apw | bhuey, that sounds like a description of a debian kernel flavour | 19:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| * bhuey waits | 19:49 | |
| apw | bhuey, is there anything in dmesg at the point where you probe it in? | 19:51 |
| jsalisbury | apw ack | 19:54 |
| jsalisbury | gQuigs, are you going to be doing a bisect? | 19:57 |
| 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:58 |
| 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? | 19:59 |
| gQuigs | jsalisbury: sure thing - http://pastebin.ubuntu.com/20352223/ | 20:01 |
| 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:02 |
| 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:03 |
| jsalisbury | gQuigs, Is the issue fixed in the upstream 4.4.15 kernel? | 20:09 |
| 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:10 |
| jsalisbury | gQuigs, ahh, ok. Then it is probably due to a SAUCE commit. | 20:11 |
| 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:12 |
| gQuigs | 4.4.0-32-generic #51 in proposed has the issue as well | 20:21 |
| jsalisbury | gQuigs, Ok, a bisect is the best route then. | 20:22 |
| 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:23 |
| jsalisbury | gQuigs, First kernel is done building. You can get it here: | 20:24 |
| jsalisbury | http://kernel.ubuntu.com/~jsalisbury/lp1603719/ | 20:24 |
| jsalisbury | gQuigs, apw There are only 6 SAUCE patches between 28.47 and 31.50: | 20:27 |
| 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:28 |
| jsalisbury | http://paste.ubuntu.com/20356124/ | 20:29 |
| 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:32 |
| apw | sforshee, ^ | 20:33 |
| jsalisbury | apw, maybe I should revert 302cabb and build a test kernel with those other three reverts reverted | 20:33 |
| apw | jsalisbury, i'd say so | 20:35 |
| jsalisbury | apw, sforshee crap, f256722 doesn't revert cleanly. | 20:36 |
| apw | jsalisbury, which order are you reverting them, that the last one i assume | 20:38 |
| jsalisbury | apw, yeah. The last one reverted first. | 20:39 |
| 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:40 |
| jsalisbury | apw, trying those two namespace ones | 20:41 |
| jsalisbury | apw, there are 5 other namespace ones | 20:42 |
| jsalisbury | apw: http://paste.ubuntu.com/20358102/ | 20:43 |
| jsalisbury | actually 6 | 20:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| gQuigs | but according to NFS, yes... | 20:47 |
| jsalisbury | sforshee, gQuigs I'll build a quick test kernel with a5abdcb for a test | 20:51 |
| 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:53 |
| jsalisbury | gQuigs, should be ready in about 10 minutes | 20:54 |
| gQuigs | awesome, thanks! | 20:54 |
| 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:00 |
| sforshee | I wonder if it has more to do with moving where sb->s_fs_info gets set | 21:02 |
| 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:09 |
| 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:14 |
| 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:17 |
| gQuigs | sforshee: jsalisbury the reverted kernel still fails | 21:20 |
| 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:21 |
| jsalisbury | gQuigs, sforshee ack | 21:22 |
| gQuigs | going away for a bit, will test anything else when I get back later tonight | 21:46 |
| gQuigs | thanks! | 21:46 |
| === JanC is now known as Guest9881 | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!