[12:42] <phillw> hi kernel team. I know that me and others will complain so fast about things. However, I'd like to give kudos where it is due. 4.8 kernel has behaved perfectly on my 'production' machine, even though you guys and gals are pushing new releases out as fast as possible to hit 16.10. You can quote me on this, I'd like to put on record that I am deeply impressed with the team getting 4.8 into 16.10 as it is an important hardware update for new kit arr
[12:43] <apw> phillw, hey thanks, it has been a rockey-road the last couple of weeks, but the current state is looking pretty good.  It will only improve as we get stables coming in.
[12:43] <LocutusOfBorg> torvalds has a different opinion, but I'm happy to see 4.8 landing
[12:44] <LocutusOfBorg> https://linux.slashdot.org/story/16/10/05/210227/linus-torvalds-says-buggy-crap-made-it-into-linux-48
[12:44] <apw> heh that is somewaht over blown, a new bugon blew his box.  that happens a lot :)
[13:25] <jtaylor> I'd like to try 4.8 but it still wont boot my lvm raid1 :(
[13:36] <smb> jtaylor, is that pure lvm raid or fakeraid via dmraid?
[13:37] <apw> (and is there a bug with the details yet?)
[13:38] <smb> apw, I know of one bug related to the kernel now presenting more disks as removable (if the controller claims to support hot-plug) but dmraid currently ignoring those
[13:38] <apw> smb, ugg i feel ill
[13:44] <smb> A bug report about that would be most helpful since there are many ways things could be arranged. dmraid, lvm raided lv, mdraid... /boot on the raid or not...
[13:50] <jtaylor> I can create one later today
[13:52] <jtaylor> let me know what I should put in, its a lvm raid1 array, not just mirror
[13:53] <jtaylor> boot is in a normal linear lv
[13:56] <apw> all background and symptoms you have
[14:31] <om26er> jsalisbury, the latest kernel is bad.
[14:31]  * om26er thinks we are closing in on the regression.
[14:32] <thierryp> hey there; I'd need to run kernel 4.7 on top of ubuntu-14.04
[14:33] <thierryp> the naive method of installing .deb packages from e.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7/ won't work
[14:33] <jsalisbury> om26er, ack, thanks
[14:33] <thierryp> after some googling it appears that it only misses one configuration option about CONFIG_UEVENT_HELPER
[14:34] <om26er> jsalisbury, curious how big is the number of commits between the two kernels
[14:34] <thierryp> is there any plan to provide binary debs that have that setting ?
[14:35] <thierryp> otherwise, what is the simplest angle that I should pursue to go about building this correction ?
[14:35] <jsalisbury> om26er, 12423
[14:35] <jsalisbury> om26er, but we are narrowing it down 
[14:35] <om26er> jsalisbury, hmm, ok. btw pitti is also affected by that bug and I assume lots others too
[14:35] <thierryp> or where should I asj if here is not the place ?
[14:35] <thierryp> s,asj,ask
[14:35] <apw> thierryp, no specific plans no -- that is however set in the yakkety 4.8 kernels so i would expect mainline builds later than 4.7 to have it set
[14:36] <jsalisbury> om26er, yes, I saw his comment.  We have only 226 commits left to bisect through, so maybe 7 or 8 more test kernels.
[14:36] <thierryp> jsalisbury: where can i find this yakkety thing ? is this avail. as a binary deb as well ?
[14:36] <thierryp> I can probably go what that as well
[14:36] <thierryp> s,what,with
[14:37] <om26er> apw, hello. re: bug 1622655 I couldn't get a reply from you yesterday, you probably signed off. Any chance we can get that enabled ?
[14:37] <ubot5> bug 1622655 in linux-raspi2 (Ubuntu) "Enable CPUset and pids CGroup controllers for RPi kernel" [Undecided,New] https://launchpad.net/bugs/1622655
[14:37] <thierryp> oh I get it
[14:37] <apw> ppisati, ^
[14:37] <thierryp> didn't know the codename for 16.10 
[14:38] <jsalisbury> thierryp, do you need a link to the 16.10(Yakkety) kernel?
[14:42] <thierryp> jsalisbury: thanks I will manage
[14:48] <ppisati> om26er: xenial? yakkety?
[14:48] <om26er> ppisati, xenial, would be good to have on yakkety but I haven't found a yakkety based RPi image anywhere.
[14:49] <ppisati> om26er: which image are you using now? kernel version?
[14:50] <om26er> ppisati, its linux 4.4, downloaded from http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/
[14:50] <om26er> ppisati, but ofcourse it will be usable on all-snap as well when we finally have lxd running on it.
[14:52] <ppisati> om26er: hold on
[14:55] <ppisati> om26er: http://pastebin.ubuntu.com/23284837/
[14:55] <ppisati> om26er: whart's the missing option?
[14:58] <om26er> ppisati, not sure about that, I came from https://github.com/lxc/lxd/issues/2361 where stgraber suggested to have CPUSet and PIDs controllers enabled. Maybe he can answer better
[14:59] <ppisati> om26er: add the exact option that you want to the LP bug and we'll make it happen
[14:59] <thierryp> jsalisbury: thanks a lot - that was really helpful :)
[15:00] <om26er> stgraber, Can you tell here or comment on bug 1622655 on what kernel options need to be enabled in linux-raspi2 for lxd limits to work
[15:00] <ubot5> bug 1622655 in linux-raspi2 (Ubuntu) "Enable CPUset and pids CGroup controllers for RPi kernel" [Undecided,New] https://launchpad.net/bugs/1622655
[15:01] <om26er> stgraber, ref: https://github.com/lxc/lxd/issues/2361
[15:03] <om26er> ppisati, I presume its CONFIG_CPUSETS and CONFIG_CGROUP_PIDS but stgraber may confirm.
[15:04] <ppisati> om26er: just add all the options that you want to the lp bug and we'll modify the config
[15:06] <om26er> ppisati, ok thanks. Curious can you trigger a build with those two configs enabled, so I can test. Its totally fine if you cant :) 
[15:06] <ppisati> om26er: sorry, i'm  really busy ATM
[15:06] <om26er> I will update the bug report once I hear from Stephane.
[15:07] <ppisati> om26er: but you can download the xenial git tree and do it by yourself
[15:07] <om26er> ppisati, no problem at all. Building for arm is a challenge for me.
[15:07] <om26er> ...and slow
[15:09] <ppisati> om26er: can't you cross compile locally?
[15:10] <om26er> ppisati, I can try, seems a found a somewhat old guide from you https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
[15:11] <ppisati> om26er: download the xenial git tree
[15:11] <ppisati> om26er: export ARCH=arm; export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linu
[15:11] <ppisati> x-gnueabihf-
[15:11] <ppisati> om26er: fdr clean && debian/rules build && fdr binary-raspi2
[15:11] <ppisati> done
[15:12] <ppisati> fdr=fakeroot debian/rules
[15:12] <ppisati> and once you have downloaded the xenial tree, you need to switch to the raspi2 branch
[15:12] <ppisati> git clone $XENIAL-TREE
[15:12] <ppisati> git checkout linux-raspi2
[15:13] <ppisati> export ARCH=arm; export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
[15:13] <om26er> ppisati, where is the xenial tree hosted ?
[15:13] <ppisati> fdr clean && debian/rules build && fdr binary-raspi2
[15:13] <ppisati> done
[15:13] <ppisati> om26er: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/
[15:19] <om26er> Thanks, will follow that, first need to reboot to test a kernel bisect.
[15:24] <om26er> jsalisbury, that's a good build.
[15:24] <KidCharlemagne> Hello Ubuntu Kernel team, on Ubuntu Xenial i installed kernel 4.8 from PPA and now proprietary broadcom WLAN driver is not working. How do i fix it?
[15:27] <apw> KidCharlemagne, which driver is failing?  is that in the ubuntu archive?
[15:27] <jsalisbury> om26er, ack
[15:28] <KidCharlemagne> apw: yes, broadcom-sta-common & broadcom-sta-dkms. It seems Linux 4.8 & 4.7 have this problem but not default Xenial kernel and 4.6.7
[15:31] <apw> KidCharlemagne, you may find the version from yakkety works, it claims to support 4.7 at least
[15:33] <KidCharlemagne> apw: this one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc6-yakkety/
[15:40] <stgraber> om26er, ppisati: you should just make sure that it matches the cgroup configuration of all the other Ubuntu kernels. lxc-checkconfig from the lxc1 package may be useful to test some of this, but I'd really just grep for the cgroup keys in both kernel configs and compare.
[15:56] <hallyn> sforshee: (not sure you're the right person, but) do you know why on 4.4.0-38-generic #57-Ubuntu all the blkio.* files under /sys/fs/cgroup/blkio would be empty?
[15:57] <hallyn> (i haven't tested any other kernels, but have to assume they were non-empty at some point in the past :)
[16:12] <elmo> apw, rtg: honestly not nagging, but what's the timeline for hwe-y?
[16:13] <apw> elmo, it is mostly there, there are some naming issues the air, but i'd expect there to be early access versions "soon"
[16:13] <elmo> apw: super, thanks
[16:14] <rtg> elmo, there is an lts-yakkety in ppa:canonical-kernel-team/ppa. We release it usually soon after final (Oct 13 in this case)
[16:14] <elmo> rtg: yep, testing that now - thanks for the info
[16:15] <rtg> elmo, I just noticed that the one we'll most likely release with is in ppa:canonical-kernel-team/unstable
[16:15] <rtg> but there is little difference between -20 and -21
[16:19] <elmo> rtg: OK
[16:31] <om26er> jsalisbury: that kernel does not boot. does not go past loading ramdisk message after grub.
[16:48] <sforshee> hallyn: no not sure, let me look
[16:54] <jsalisbury> om26er, ok, I'll skip that one in the bisect and build the next
[16:57] <sforshee> hallyn: for me the files aren't empty
[17:05] <hallyn> sforshee: what do you see?  not just "Total: 0" ?
[17:20] <sforshee> hallyn: http://paste.ubuntu.com/23285454/
[17:21] <sforshee> that's cat /sys/.../blkio.*
[17:40] <hallyn> sforshee: hm.  in 4.4?
[17:46] <sforshee> hallyn: 4.4.0-38-generic #57-Ubuntu
[17:49] <hallyn> ok thx.  i'll just have to find time to look int oit
[17:50] <jtaylor> where should bugs for the lts-yakkety from the ppa br filed?
[17:55] <om26er> jsalisbury: that's a bad kernel.
[17:55] <jsalisbury> om26er, ack, next one coming
[19:14] <svilic> Hi everyone, 
[19:14] <svilic> I have very strange deadlock situation, that I don't understand quite well, because it goes into libc and possible a kernel. Here is a backtrace
[19:14] <svilic> #0  0x00007ffff3629e03 in futex_wait (private=0, expected=15, futex_word=0x7fffffffda00) at ../sysdeps/unix/sysv/linux/futex-internal.h:61 
[19:14] <svilic> #1  futex_wait_simple (private=0, expected=15, futex_word=0x7fffffffda00) at ../sysdeps/nptl/futex-internal.h:135 
[19:14] <svilic> #2  __nptl_setxid (cmdp=0x7fffffffd9e0) at allocatestack.c:1163 
[19:14] <svilic> #3  0x00007ffff112ca35 in __GI_seteuid (uid=uid@entry=0) at ../sysdeps/unix/sysv/linux/seteuid.c:37 
[19:14] <svilic> #4  0x00007ffff2a4a382 in pion::PionAdminRights::PionAdminRights (this=0x7fffffffdc00, use_log=<optimized out>) at PionAdminRights.cpp:35 
[19:14] <svilic> #5  0x00007ffff2c9dfe3 in pion::net::TCPServer::start (this=0x3417180) at TCPServer.cpp:86
[19:14] <svilic> My question is, could this be introduced by application bug, by overwriting some part of memory or this is a kernel/libc bug?
[19:16] <jtaylor> very likely an application bug, all locks end up in the kernel at some point
[19:18] <svilic> that is what I assume. If I understand correctly, all this from #0 to #3 is still user space,right?
[19:19] <svilic> isn't #2 or #3 actually a SYSCALL
[19:24] <apw> futex_wait() is a library call calling futex() the system call
[19:26] <svilic> ok. last question: are futex structues stored in kernel or in user space? is it possible for application to corrupt futex? I assume yes, but I am not sure ...
[19:28] <om26er> jsalisbury: that's a bad kernel.
[19:29] <jsalisbury> om26er, thanks, I'll spin the next one.  Only 3 more to go
[19:30] <om26er> seems we are close now :)
[19:34] <jtaylor> svilic: you shouldn't be able to screw up a futex, but you for sure can mess up the userspace part of a lock
[19:35] <jtaylor> though its more likely its just a regular deadlock, does valgrind show any corruption?
[19:40] <svilic> jtaylor: This is a project being ported from precise to xenial. It used to work and what you see in backtrace are very first steps doing start of server. But since we had to change a few things during porting, I guess there has be an application bug. Now, this shouldn't be a deadlock, because it happens when libpion tries to changes effective user id, which leaves me to conclusion, that this has to be corruption. I was just confuse
[19:40] <svilic> jtaylor: but you guys helped me a lot. Knowing that is not a kernel bug, I know where to look for it :)
[19:40] <svilic> thank you very much
[20:03] <jsalisbury> om26er, I think I pointed you at the wrong directory in the bug report for the last kernel. I should have asked you to test: http://kernel.ubuntu.com/~jsalisbury/lp1627108/55e16d30bd99510900caec913c90f53bc2b35cba/
[20:04] <jsalisbury> om26er, if you see comment #26, the SHA1 I mention does not match up with the URL I gave you.
=== rcj` is now known as rcj
=== rcj is now known as Guest46240
=== Guest46240 is now known as rcj
=== mamarley is now known as Guest70811
=== mamarley_ is now known as mamarley