/srv/irclogs.ubuntu.com/2016/07/21/#ubuntu-kernel.txt

bhueyIs there a wiki on making a new flavour correctly ? I just copied the .generic file over and renamed it01:34
bhueyEnabling a kernel option creates the problem with the module failing to load01:35
bhueyI'm obviously missing something here but I don't know what it is01:35
mterryHello!  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 there13:37
apwmterry, which kernels specificially ?13:40
mterryapw, 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
apwmterry, yes, the kernels are mostly very different, and so there is a lot of manual work in that13:43
mterryapw, OK.  Where could I go and look at the config we use to build one of these kernels with?13:43
apwmterry, i'll find out and let you know13:44
xnoxwhy doesn't 9pnet_virtio module autoload upon trying to mount 9p virtio filesystem....?15:41
apwxnox, dunno maete15:41
apwmaybe it cannot be detected15:42
xnoxit can be....15:46
apwthat combination of things is a bit wierd to put it mildly, a virtio filesystem15:48
* apw goes for supplies15:50
xnoxapw, oh, it's racy on boot15:53
xnoxsomehow systemd tries to mount it before it's ready.... as post-boot i can restart .mount unit and it just works.15:54
Gnarhttps://youtu.be/0yJn-5hpU9417:40
gQuigsshouldn't regressions have a higher importance? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/160371918:18
ubot5Launchpad bug 1603719 in linux (Ubuntu) "[regression] NFS client: access problems after updating to kernel 4.4.0-31-generic" [Low,Confirmed]18:18
bhueyhi19:31
apwgQuigs, regressions are indeed of importance to us19:33
apwgQuigs, that wasn't marked (correctly) as a regression, i've marked it up19:34
apwjsalisbury, ^ that one needs to be on our list19:34
gQuigsapw: thanks19:34
* bhuey reasks question19:35
bhueyI created a flavor and I'm ahving problems loading the nvidia propreitary driver19:35
* gQuigs is bisecting now, but still on first kernel build (slow machine, via VPN)19:35
bhueyBuilds and installs ok but I don't know what how to get the module to load without complaining19:36
bhueyDo I needd to do something in addition to just creating a new flavor file ?19:36
bhueyand configuring the .config of those kernels ?19:36
bhueyI did this to enable a kernel parameter for testing that isn't on in a normal Ubuntu kernel19:37
bhueybut it seems to be causing ABI issues19:37
apwbhuey, that sounds like a description of a debian kernel flavour19:44
apwbhuey, but if it is building you are not throwing abi issues, that would prevent the build19:45
apwbhuey, you would be better telling us what error you see when you try and insert the module19:45
bhueyapw: yeah this is kind of baffling as I odn't much about kernel packaging19:46
bhueyWe're building it locally here and need the Nvidia drivers for CUDA development19:46
bhueyBasically, we compile 4.4.8 for trusty19:47
bhueylowlatency kernel as well19:47
bhueythe 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 runtime19:47
bhueycompiles and installs with no complains19:48
bhueyHave zero idea what's going on to push this forward19:48
bhueyapw: thanks for any help btw19:48
* bhuey waits19:49
apwbhuey, is there anything in dmesg at the point where you probe it in?19:51
jsalisburyapw ack19:54
jsalisburygQuigs, are you going to be doing a bisect?  19:57
gQuigsjsalisbury: in progress, but if anyone has a faster machine with this issue they might finish first19:58
gQuigsstill on the first kernel build19:58
jsalisburygQuigs, 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
gQuigsjsalisbury: sure thing - http://pastebin.ubuntu.com/20352223/20:01
gQuigsit's just the first build so I assumed that rebuilding 4.4.0-28 and 4.4.0-31 wasn't needed20:02
jsalisburygQuigs, 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
gQuigsjsalisbury: feel free to just ping me here, I'll be around20:03
gQuigsthanks!20:03
jsalisburygQuigs, 20:03
jsalisburygQuigs, ack20:03
jsalisburygQuigs, Is the issue fixed in the upstream 4.4.15 kernel?  20:09
jsalisburygQuigs, if it is, it might be better for us to reverse bisect to find the commit that fixes things20:10
gQuigsjsalisbury: yea  4.4.15 works fine, but keep in mind I haven't found an upstream kernel to have the issue to begin with20:10
gQuigserr20:10
jsalisburygQuigs, ahh, ok.  Then it is probably due to a SAUCE commit.20:11
apwgQuigs, have you tested the -proposed kernel, i _thought_ that had 4.4.15 applied20:12
jsalisburygQuigs, 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
jsalisburyheh, collision.20:12
gQuigswill cancel my build and try that20:12
jsalisburygQuigs, great.  and my build is going20:12
gQuigs4.4.0-32-generic #51 in proposed has the issue as well20:21
jsalisburygQuigs, Ok, a bisect is the best route then.20:22
gQuigsI'm guessing it's related to the series under - cgroupfs mounts can hang20:23
gQuigsas 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 -120:23
jsalisburygQuigs, First kernel is done building.  You can get it here:20:24
jsalisburyhttp://kernel.ubuntu.com/~jsalisbury/lp1603719/20:24
jsalisburygQuigs, apw There are only 6 SAUCE patches between 28.47 and 31.50: 20:27
jsalisbury9ef55b6 UBUNTU: SAUCE: drm: check for supported chipset before booting fbdev off the hw20:28
jsalisbury7b97729 UBUNTU: SAUCE: (noup) Update zfs to 0.6.5.6-0ubuntu1020:28
jsalisbury302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches20:28
jsalisbury765ab2f Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a cgroup namespace"20:28
jsalisbury3988fb7 Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user namespace when mounting"20:28
jsalisburyf256722 Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the user ns which owns the ipc ns"y20:28
jsalisburyguess I should have pastbin'd that20:28
jsalisburyhttp://paste.ubuntu.com/20356124/20:29
jsalisburygQuigs, apw three are reverts, so I'm going to assume they probably didn't cause the bug.  Could be: 20:32
jsalisbury302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches20:32
gQuigsjsalisbury: that kernel has the issue; git bisect bad20:32
apwjsalisbury, that is paired with the three reverts20:32
jsalisburyapw, hmm20:32
apwsforshee, ^20:33
jsalisburyapw, maybe I should revert 302cabb and build a test kernel with those other three reverts reverted20:33
apwjsalisbury, i'd say so20:35
jsalisburyapw, sforshee crap, f256722 doesn't revert cleanly.20:36
apwjsalisbury, which order are you reverting them, that the last one i assume20:38
jsalisburyapw, yeah.  The last one reverted first.20:39
apwjsalisbury, must be something on top needing revert first20:40
jsalisburyapw, I'll see what other commits happened around it20:40
apwprolly the other two namespace ones20:40
jsalisburyapw, yeah, trying to find it now20:40
jsalisburyapw, trying those two namespace ones20:41
jsalisburyapw, there are 5 other namespace ones20:42
jsalisburyapw: http://paste.ubuntu.com/20358102/20:43
jsalisburyactually 620:43
jsalisburyapw, maybe I'll just revert the whole lot20:44
sforsheejsalisbury, apw: "(namespace) vfs: Pass data, ns, and ns->userns to mount_ns" touches nfs, but I'm not seeing how it would cause that problem20:44
sforsheeI'd think if there was a problem it would happen at mount time20:44
gQuigssforshee: it is "mount" time, just submount time20:45
gQuigsfor example I can access /cfs/home,  but not not /cfs/share20:45
sforsheegQuigs: but does that actually trigger a separate filesystem mount operation?20:46
gQuigssee the NFS error I posted above (nfs_xdev_mount),  not sure what that translates to elsewhere20:46
gQuigsbut according to NFS, yes...20:47
jsalisburysforshee, gQuigs I'll build a quick test kernel with a5abdcb for a test20:51
jsalisburywith a5abdcb reverted20:53
gQuigsah, that makes more sense :)20:53
jsalisburygQuigs, heh, I typed it then looked at another monitor :-)20:53
jsalisburygQuigs, should be ready in about 10 minutes20:54
gQuigsawesome, thanks!20:54
sforsheeit 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 ns21:00
sforsheeI wonder if it has more to do with moving where sb->s_fs_info gets set21:02
bhueyapw: 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 logs21:09
bhueyapw: should I do that ?21:09
jsalisburygQuigs, test kernel is ready.  Same location:21:14
jsalisburyhttp://kernel.ubuntu.com/~jsalisbury/lp1603719/21:14
sforsheeoh, I think it's sget21:14
sforsheeyeah, it almost certainly is. The internal mount doesn't use MS_KERNMOUNT, and now sget has a capability check if that isn't used21:17
gQuigssforshee: jsalisbury the reverted kernel still fails21:20
sforsheegQuigs: that's what I'd expect if my suspicions are correct21:21
sforsheeI'm going to try to reproduce locally, shouldn't be difficult, then I can test my theory21:21
jsalisburygQuigs, sforshee ack21:22
gQuigsgoing away for a bit, will test anything else when I get back later tonight21:46
gQuigsthanks!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!