[12:31] <tjaalton> I'm debugging a weird swap issue on my main desktop, where the swap is fully allocated not long after a fresh reboot though smem shows it's not the apps using it
[12:31] <tjaalton> so I wonder if btrfs is to blame, I have a four disk raid on it
[12:32] <tjaalton> swapoff takes an eternity, making shutdown really slow
[12:32] <tjaalton> running vivid
[12:32] <tjaalton> but it was the same on trusty too
[12:33] <tjaalton> the box has 16GB of ram, and usually ~10G is for cache
[12:33] <tjaalton> so there's plenty of ram to use
[12:34] <tjaalton> swap is only 4G, running swapoff now and it's halfway done and cache amount has not changed
[12:41] <tjaalton> um, actually it increased, free ram is constantly around ~160M
[12:41] <tjaalton> guess I'm better off without swap, disabled it for now..
[14:18] <nemo> So... Nexia, someone who plays the game I help dev (Hedgewars) has a card that is an rt5390
[14:18] <nemo> When he reluctantly reboots to ubuntu from Windows, he gets disconnected all the time
[14:18] <nemo> I found several bugs and forum threads from 2013 indicating a patch exists that fixes the 64 bit support in the driver...
[14:18] <nemo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173759/comments/14  for example
[14:18] <nemo> (that link is corrupted btw)
[14:19] <nemo> the patch link is good though, so I'm hoping it works on ubuntu's version of the driver
[14:19] <nemo> so... I was wondering. since he clearly has a semi-functional card now in 2013, did this patch never make it upstream?
[14:19] <nemo> or is it only an incomplete fix?
[14:20] <nemo> BTW, all the bugs I could find in launchpad were closed for various reasons like "inactivity" or "the laptop you happened to report this against was recalled (even though the card is common enough)"
[14:34] <nemo> er. s/now in 2013/now in 2015/
[15:06] <Aram> Hi: 
[15:06] <Aram> dpkg-deb: building package `linux-image-3.19.0-rc6-uprobes-dbg' in `../linux-image-3.19.0-rc6-uprobes-dbg_3.19.0-rc6-uprobes-1_arm64.deb'.
[15:06] <Aram> It's been 40 minutes now and it's not finished. There doesn't seem to be any file I/O on the generated file. Is it stuck? What to do?
[15:06] <Aram> Thanks.
[15:08] <Aram> dpkg-deb uses 100% CPU.
[15:09] <Aram> straceing it looks liek it's doing lots of 4k reads and writes
[15:09] <Aram> oh, it either finished or my attempts to debug it killed it
[15:10] <Aram> it generated a 330MB file
[15:11] <data> hi, did something in the build process change between 3.16.0-28 and -29? My servers do not boot with -29 due to not being able to mount the rootfs, and the busybox rescue does not have the necessary drivers to support iDRAC or a USB keyboard
[15:36] <Aram> ok, so my arm64 machine does not boto with this kernel
[15:36] <Aram> boot
[15:36] <Aram> http://sprunge.us/OfFV
[15:36] <Aram> I don't see any output from the kernel
[22:18] <apw> data, not knowingly
[22:19] <apw> nemo, if someone can test, then you should (sadly) file a new bug with "ubuntu-bug linux" and add the info on the patch to that, and we can get someone to build a test kernel for it.  do paste the new bug number here.
[22:19] <apw> Aram, no idea what that kernel source is, nor whether i would expect it to boot ubuntu
[22:21] <Aram> it's an experimental patch that implemented uprobes on arm64, but that is not very relevant as I tried with vanilla kernel too, and that doesn't boot either on this machine.
[22:22] <Aram> and that boot log is complete, there is no kernel output at all.
[22:22] <Aram> I also tried earlycon= options