=== thomi_ is now known as thomi
[00:38] <Dandel> I am needing to find out who to talk to about some more trivial hardware enablement and procedures to get input devices updated where all that is really required is adding a few device id's to the appropriate drivers.
[01:03] <xnox> Dandel: simple things like config changes / extra device id's are usually handled very efficiently via bug reports against "linux-meta" package.
[01:08] <Dandel> xnox, thanks for the tip, but what would it take to bug report to without relying on linux-meta? ( if i have a specific kernel line )
[01:08] <Dandel> i use the 3.5.x kernel.
[01:11] <Dandel> after all I know that some of these devices do not have support added in the latest mainline kernel for 3.12
[01:16] <Dandel> good evenin RAOF 
[01:16] <RAOF> Ello.
[01:17] <Dandel> actually, I believe it should be possible to fix some devices permanently ( like xbox 360 gamepads ) to where the xpad driver will auto identify them all.
[01:21] <Dandel> I believe that all 360 gamepads have a similar layout that with some comparisons be used to identify the gamepad without having to add device id's.
[01:26] <RAOF> That sounds like a recipe for false-positives :)
[01:27] <Dandel> RAOF, not entirely
[01:27] <Dandel> there is a very specific signature
[01:28] <ohsix> one of them being the device id
[01:28] <Dandel> ohsix, yes, but there is a specific interface on all xbox 360 gamepads that you can look for
[01:28] <ohsix> is there a vendor descriptor that robustly identifies them? they have extensions windows and i think those gamepads use
[01:28] <Dandel> yea.
[01:28] <Dandel> interface descriptor
[01:28] <ohsix> it's used to store things like images and maps and stuff
[01:29] <Dandel> for xbox 360 gamepads, if you use an lsusb, you always find somethin like this on it... ** UNRECOGNIZED:  06 41 00 01 01 03
[01:29] <ohsix> that's documented in the wdk / on msdn too
[01:30] <Dandel> ya, and this is what microsoft uses to make their dumb driver auto-configure gamepads for xinput
[01:30] <Dandel> I have one wired 360 controller that works great on windows and has a psectacular blinking ring of death on linux.
[01:32] <Dandel> I believe it should be possible to identify the byte sequence that identifies things to make xinput capable devices work.
[01:34] <Dandel> from a few years back ( 2008  ) - http://ubuntuforums.org/showthread.php?t=993870 
[01:35] <Dandel> the unrecognized bits on all of those items have a strong match to my gamepad that is currently not supported.
[01:37] <ohsix> we can speak generally about it here, but it's probably prudent just to ask the person who wrote the code that has a whitelist in it
[02:04] <Dandel> ohsix, yes, if you are only talking about my device... However it does not fix end user usability... it forces end users to haft to figure out how to file a bug report ( this is not exactly a good solution)
[02:04] <ohsix> not really, the implied discussion would be finding out why he's not using the vendor extensions to find devices
[02:06] <Dandel> I do agree that talking to the author would help, however in the mean time it would probably be worth while to figure out what the appropriate byte code sequence and location is to permanently fix the detection.
[02:07] <ohsix> yes, and i think it's a foregone conclusion to use what documentation MS has for identifying those devices, i don't think that is true for the person that wrote it
[02:08] <ohsix> eg. i'm assuming there is a reason it was done one way or the other, and i don't have the information that person had
[02:09] <ohsix> it's probably related to the kernel not also supporting the gamepad even if it could identify ones it doesn't know about yet
[02:09] <ohsix> a device that is detected but doesn't work is just as useful as one that's not detected
[02:10] <Dandel> yes, however there is specific entries that give a lot of key data too.
[02:10] <ohsix> i don't doubt it,  but i also don'tk now if they're sufficient
[02:12] <Dandel> ohsix, the information is most likely static since the driver used by windows is about 6 years old ><; so i believe it should be possible to identify the devices without much work.
[02:13] <ohsix> the device for windows is also written with information othe rpeople don't have, and no explicit guarantees about any of it
[02:13] <ohsix> these are all reasons it may not have been done the 'correct' way, it is no substitute for asking the person
=== shuduo_afk is now known as shuduo
=== marrusl is now known as marrusl_afk
=== marrusl_afk is now known as marrusl
=== gfrog_afk is now known as gfrog
[03:31] <ripthejacker> Hi all, I have set CONFIG_IP_VS_WRR in /boot/config , but I cannot see it in lsmod.
[03:31] <ripthejacker> How do I check if a kernel module is loaded, or kernel has that capability?
=== shuduo is now known as shuduo_afk
=== shuduo_afk is now known as shuduo
=== shuduo is now known as shuduo_afk
=== shuduo_afk is now known as shuduo
=== shuduo is now known as shuduo_afk
=== shuduo_afk is now known as shuduo
[09:28]  * apw yawns
[09:29]  * RAOF pours the bees.
[09:35]  * smb sees a tradition
[09:39] <apw> gotta have some bees in the morning
=== gfrog is now known as gfrog_meeting
=== shuduo is now known as shuduo_afk
=== shuduo_afk is now known as shuduo
=== shuduo is now known as shuduo_afk
[17:13] <lamont> saucy kernel upgrade hung in os-prober doing a modprobe btrfs (on an openstack instance)... is that a known thing?
[17:13] <lamont> 3.11.0-3-generic
[17:13] <lamont> is the running kernel
[17:15] <rtg> jsalisbury, ^^ have you come across a bug like this ?
[17:16] <lamont> strace showed it sitting in init_module()
[17:17] <lamont> awesome.  update-grub is consistent in this manner!
[17:19] <jsalisbury> rtg, not that I can recall off the top of my head.  I'll do a search
[17:24] <lamont> http://paste.ubuntu.com/6562423/ <-- jsalisbury that's what I see 
[17:24]  * lamont spins up a fresh instance to see if it's current-ish
[17:26] <jsalisbury> lamont, I haven't seen any similar issues.  Does the entire system hang, or just the update-grup and kernel upgrade process?
[17:26] <lamont> update-grub hangs after: Found memtest86+ image: /boot/memtest86+.bin
[17:26] <lamont> and ps/strace are as per the pastebin
[17:28] <rtg> lamont, I assume this is a regression ?
[17:28] <lamont> nfc
[17:28] <jsalisbury> lamont, Are you upgrading via apt-get or did you download a .deb?  
[17:28] <lamont> update-grub runs fine on 3.11.0-14-generic
[17:29] <lamont> jsalisbury: this is a dist-upgrade of the box, I'll paste the history, but originally it was saucy-server-amd64-20130822 for the image
=== yofel_ is now known as yofel
[17:30] <lamont> that was last previously upgraded on 2013-08-29...
[17:30] <lamont> hence the ancient kernel that is currently running
[17:30] <jsalisbury> lamont, Do you have some earlier kernels on the system?  If so, you might be able to boot into the old image and just upgrade right to -14 by downloading the .deb
[17:31] <lamont> killing the modprobe seems to let everything finish ok
[17:31] <lamont> it was more "have we seen this"
[17:31] <lamont> fwiw, chinstrap:~lamont/update-grub/history* are the /var/log/apt/history* files
[17:31] <rtg> lamont, cool, you should have some dmesg output, right ?
[17:32] <lamont> dmesg shows bootup, after that it's boredome
[17:33] <rtg> hrmph
[17:33] <lamont> I suspect it's a bug from saucy-devel time, and fixed.
[17:33] <lamont> which I think I can confirm by rebooting the instance, but want to get what I can from it first
[17:34] <lamont> I even still have the image that was used to boot it.
[17:35] <lamont> which tells me I can reproduce this at will.  let me reboot the upgraded image
[17:35] <jsalisbury> lamont, it might be good to open a bug, so we have all the data capture in one spot.  apport will grab all the logs
[17:36] <lamont> it would seem that I'm missing either a package or my brain...  how shall I open this bug?
[17:37]  * lamont had thought reportbug, but that's not installed
[17:38] <lamont> ubuntu-bug seems to be the winner
[17:38] <jsalisbury> lamont, right.  ubuntu-bug linux
[17:39] <lamont> *** Problem in linux-image-3.11.0-3-generic
[17:39] <lamont> The problem cannot be reported:
[17:39] <lamont> This is not an official Ubuntu package. Please remove any third party package and try again.
[17:40] <lamont> I suppose I could reboot so that the running kernel is the current package, and then report the bug
[17:51] <lamont> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1260431 <-- such as it is.
[17:51] <ubot2> Launchpad bug 1260431 in linux (Ubuntu) "update-grub hangs under 3.11.0-3-generic" [Undecided,New]
[18:05] <jsalisbury> lamont, thanks
[18:31]  * rtg -> lunch
[19:14] <anon12> I installed linux kernel 3.10.0-rc3test+ from git after compiling it and have removed it but dkms keeps compiling modules for the 3.10.0-rc3test+ version. How do I find the right files to remove so that dkms starts working again?
[19:37] <hallyn_> stgraber: good news, new canonical-kernel-team/ppa trusty kernel lets me start unpriv containers with /proc/.../binfmt mounted
[19:42] <stgraber> hallyn_: yay!
[19:43] <stgraber> I'll have to update to that one
[20:21] <rtg> apw, Trusty server daily fails to finish booting after install. It gets as far as 'Add 2095100K swap on dev/vda5'. Didn't we have a frame buffer issue with KVM once upon a time ?
[20:21] <rtg> this is using virt-manager
[20:23] <rtg> boots OK is I use recovery mode
[20:23] <rtg> s/is/if/
[20:38] <apw> rtg, that sounds familiar, i wonder if that is which 'display driver' you are using in kvm.  i am using virt-mngr too but i have had to change the display h/w in the past 'cause of unity imploding with it
[20:38] <rtg> apw, I'm just booting server
[20:39] <apw> you know how you can change which h/w the VM has attached for graphics etc
[20:39] <rtg> apw, from virt-manager you mean ?
[20:40] <apw> yeah in there, where you define the macine there are various physicla devices, one you can change is the graphics
[20:40] <apw> though if desktop works ok, that seems less likley
[20:40] <apw> it oculd be a race of course, we had those in older kernels
[21:16]  * rtg -> EOD
[21:29] <phillw> Hi, good people, is there a any chance what so ever of http://packages.debian.org/wheezy/kernel-image-3.2.0-4-486-di being included in mulitverse (or where ever) to make it available to create a lubuntu community respin?
[21:31] <phillw> please do not laugh at my poor knowledge of kernels, but I believe it needs to be there to be used.
[21:58] <Dandel> phillw, the kernel you mentioned is over an year old. It would be better to use 3.10 or 3.4.x
[22:00] <phillw> Dandel: as it is for 13.10 lubuntu, I looked at 3.2 kernel, I'm not sure what the kernel team have chosen for the 14.04 LTS.
[22:01] <phillw> ahh.... sorry, 13.10 is on 3.11 :P
[22:01] <phillw> I was pulling a bug from the 3.2 kernel for zram.... my apologies. I'll go back and do some more reasearch :)
[22:02] <phillw> Dandel: it would be http://packages.debian.org/sid/linux-image-3.11-2-486
[22:05] <phillw> It does two things... 1) available for non-pae 2) allows those who were left behind after 10.04 (no cmov) to have an up to date kernel. I know it is limited in numbers of computers needing it; but being able to offer it would be nice :)
[22:08] <Dandel> phillw, look at the ubuntu mainline kernels
[22:09] <phillw> Dandel: as I have said, I'm not really a kernel person, is there a ubuntu mainline 486 kernel?
[22:09] <JanC> phillw: nope
[22:10] <Dandel> phillw, sorry, but that's not possible... support for 486 was removed with the 3.8 kernel
[22:11] <phillw> JanC: which was my understanding. Is it possible to build *buntu with the debian kernel?
[22:12] <JanC> you could build the Ubuntu kernel with support for 486 if you want...
[22:14] <JanC> (maybe an older Ubuntu kernel)
[22:15] <phillw> JanC: Yeah, I saw that on http://forums.debian.net/viewtopic.php?f=17&t=105200 if only I knew where to start! What I was, foolishly, assuming is that as debian have a 486 kernel, it could be used by *buntu. I'm realising that my simplistic understanding of how debian kernels are adopted by *buntu is woefully lacking.
[22:17] <JanC> phillw: I guess that you could use a Debian kernel too...
[22:18] <JanC> and AFAIK Ubuntu kernel isn't really based on Debian's kernels
[22:18] <phillw> hence my asking if the -486 one could be made available. It sorts out both the non-pae issue and the non-cmov issue,
[22:19] <phillw> I had a sneaky feeling it would be not be that easy, else it would have been done :)
[22:19] <JanC> IIRC Ubuntu requires PAE for security reasons
[22:20] <phillw> non-pae is still supported on 12.04
[22:21] <JanC> I know, I had to install that on a Pentium M system last week  :-/
[22:22] <phillw> IIRC, it was to keep the upkeep of the kernel down to manageable levels that it was dropped. JanC lubuntu have a fake-pae install for the pentium M's, we cannot held those who do not have pae (hidden).
[22:23] <JanC> fake-pae?
[22:23] <phillw> JanC: https://help.ubuntu.com/community/Lubuntu-fake-PA
[22:25] <JanC> interesting, maybe will look into re-installing those Thinkpads  :)
[22:25] <phillw> JanC: it gives you an idea as to asking about getting the -486 kernel made available :)
[22:30] <JanC> phillw: so, basically Intel deliberately crippled their CPUs by not setting that flag?   :-(
[22:32] <phillw> JanC: I prefer to think that they were in that much of a rush to get the chips out (it was a race of who got the newest one out 1st) that they simply dropped a rather large clanger! I'm sure they'd have preferred to launch it with full capabilities. Some one messed up :P
[22:33] <JanC> phillw: or they wanted to charge extra for other CPUs...
[22:33] <phillw> AMD took it by storm, I guess someone at Intel did not get their bonus that year :)
[22:34] <JanC> or maybe there are bugs in some early CPUs
[22:35] <phillw> there were, Intel did do crippling, but this is not a topic for this channel. there is #phillw which you are welcome to join. 
[22:36] <phillw> I'm awaiting the kernel team to give me more advice & this channel has a pretty specific topic :)