=== tmpRAOF is now known as RAOF
=== tmpRAOF is now known as RAOF
[00:39] <RAOF> Days since btrfs has eaten any of my data: 0.
=== gerald is now known as Guest19747
[07:42] <smb> tseliot, just as a bit of feedback the nvidia-340-updates variant of the binary driver for vivid at least seems to have only one dkms module producing both kernel modules in vivid. The uvm one is not loaded on that particular system but that might be related to the gpu variant. I am not sure when it should be loaded
[07:45] <tseliot> smb: does dmesg say anything interesting about uvm? Also, you shouldn't notice any problems unless you decided to use CUDA
[07:48] <smb> tseliot, nothing about uvm... and since cuda does not ring a bell immediately I suppose I have not decided to use that
[07:48] <smb> :)
[07:50] <tseliot> smb: yep, most users don't use the GPU that way ;)
[07:53] <smb> tseliot, so meh. :) I guess then it looks good to be backported into the Trusty version of the updates driver as you surely also noticed people start complaining about that. 
[07:54] <tseliot> smb: yes, I want to backport all the new drivers too. This will take a little longer but it will be worth the effort
[08:00] <smb> tseliot, Yeah, since long-term this will let things cope better with hwe kernels. Hopefully power users have some amount of patience. Hm... maybe it is worth documenting how to manually resolve things until it gets fixed. I would not want to overestimate the patience of gamers. :-P 
[08:02] <tseliot> smb: right now it's a bit of a random failure. At times it's even a false positive, meaning that, at times, dkms will complain even when the module is built
[08:04] <smb> tseliot, exactly. Even if one of the modules permanently failed it might be the uvm and if that is rarely used anyway most people won't care.
[08:04] <tseliot> smb: right
[08:42] <smb> apw, Hm, not sure I just did not see those before but udev rules seem to produce "error: /dev/sd*: No medium found" style message on usb card reader devices (without card) though this should be obvious by capacity 0 ... (vivid that is)
[09:05] <apw> smb, not sure i have either now
[09:05] <apw> no
[09:07] <smb> apw, yeah, likely only observable with hw that creates disk devices that has ejectable media
[09:28] <smb> apw, Oh,,, hm... so 60-persitent-storage.rules does have some checking on ATTR{removable}=="1" ... guess I have to run with debug to get any idea what part really does the access
[13:52] <mssbrg> Hi, I'm trying to build an in-tree driver via `make modules SUBDIRS=drivers/thunderbolt` but I get a "disagrees about version of symbol module_layout" in dmesg upon insmod. What build files should I check to make sure I'm building for the right kernel? .config? Module.symvers?
[13:57] <apw> mssbrg, you need to make sure it is the exact version that was built, and the compiler matches iirc
[13:59] <mssbrg> apw: the compiler should be the same. as for version, I'm currently running this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/, and I've checked out to tag v3.19 in the tree
[14:00] <mssbrg> so it seems like those should match. I noticed that there were no *patch files for reconstructing the source tree though
[14:05] <apw> mssbrg, there really ought to be ... hmmm
[14:37] <mssbrg> apw: if you happen to investigate/have any more info, please let me know :)
[17:16] <apw> mssbrg, oddly the patches are there for .2 and .3
[17:35] <apw> mssbrg, oh ... well thats strange, it seems the kernel user on one of our builders doesn't have an "real name", and that has hosed the patches for those builds ... so i am rebuilding the two i noticed which are affected, though i am sure there are others
[20:08] <hanfm> Hello, i have a problem in ubuntu 10.04, /var/log/messages is full of entries like this:
[20:08] <hanfm> Apr  9 21:55:01 <myserver> kernel: [1708785.301163] cron[17345] general protection ip:7f9b28621786 sp:7fff2d524b20 error:0 in libpthread-2.11.1.so[7f9b2861c000+18000]
[20:08] <hanfm> does anyone know, how to solve this  issue?
=== spideyman is now known as Guest99096