| memguy | ok i have installed oss where alsa has been but i have noticed the only problem i have with it is when i turn the ossxmix up all the way i don't get the loudness range i did with ALSA. Maybe i am missing some mixer amplifier thing but i don't think so. Anybody know if this is fixable? | 04:07 |
|---|---|---|
| RAOF | There's presumably some reason you're using the deprecated-for-nearly-a-decade OSS rather than ALSA? | 04:17 |
| memguy | I just wanted to try it . Main reason was understanding of LKM loading the correct ones and getting device files working with the drivers... Thats the more general and important question i had figured out. But as a result of figure this all out i now notice only one setting is really noticeable it is the loudness level just curious what is causing this? | 04:20 |
| RAOF | I'm honestly surprised you could get it to work at all, and that we're still building it. | 04:23 |
| memguy | I do have an additional unrelated question. It is .. is there any program ,command , or file to look up which device files are associated to which module if any. I know each LKM doesn't necessarily have a /dev device file as well as each dev file doesn't have to be linked to a driver (could be just user created). But it sure would be nice of a way to list what device files are associated with what LKM | 05:25 |
| memguy | to know which ones are created by which lkm's. I have a few ways of going about this none of which i like yet | 05:27 |
| memguy | lsmod simple just opens /proc/modules so nothing revealing that i can uses to leverage how to get the associated device files | 05:44 |
| memguy | yet | 05:44 |
| memguy | /proc/devices seem to give mostly all device files names to some extent but there is no good way i can figure out yet on how to linking I am wondering if anybody knows of an ioctl or function one can pass the name of the device file that would tell it what LKM .ko it is registered with | 05:47 |
| === JanC_ is now known as JanC | ||
| memguy | There are ways like grepping the source for open(/dev/ occurrences in the LKM source code one by one but this isn't really nice or fast way just to find out about an LKM. I purpose that LKM writters embed in the modinfo strings the device files it creates if any . They all have Author , parameters ,...etc why not include the device files it uses in general | 06:30 |
| mjg59 | The name of the device file is determined by udev, not the driver | 06:34 |
| mjg59 | So the kernel has no idea what htey're called | 06:34 |
| memguy | wait LKM can create device files | 06:34 |
| mjg59 | They can, but they shouldn't | 06:34 |
| memguy | why not | 06:35 |
| mjg59 | Because that's up to udev | 06:35 |
| mjg59 | Anyway | 06:35 |
| mjg59 | You can figure it out by looking at the major and minor numbers on the device node | 06:35 |
| memguy | why do the want to uses udev i mean i get udev is for plug in play kind of detection which loads the LKM needed | 06:35 |
| mjg59 | And then look for the dev file under /sys which has those major and minor numbers in it | 06:36 |
| memguy | So its like udev creates the device file then loads the LKM for it | 06:36 |
| mjg59 | Then walk from there to the driver | 06:36 |
| memguy | mjg59 not sure what you mean. I know how to find the device files major and minor number | 06:39 |
| memguy | but how do you know which device file is associated to which LKM | 06:40 |
| memguy | are you saying that the sysfs has a way to associate the LKM with a device file because i have a number of way to figure out a device files major and minor numbers... but no way to know what device files are associated to which LKM if any. There could be one associated to an LKM or several or none. I just don't understand by major and minor number how one can determine what LKM its on | 06:44 |
| memguy | seems looking up a list of hardware to major and minor numbers is not a good way to do this as ever evolving LKM and device files one would have to have a list for his version he is on | 06:46 |
| mjg59 | There are files in /sys called "dev" which conain a major and minor number pair | 06:49 |
| mjg59 | That will allow you to associate the device node with a sysfs device | 06:49 |
| mjg59 | Then just follow the driver symlink | 06:49 |
| === ben_r_ is now known as ben_r | ||
| kamal | dmj_s76, hi -- we've just deployed Xenial 4.4.0-31.50 including the nouveau patch in the -proposed archive -- can we get you to do one more quick smoke test of it for verification? | 14:37 |
| kamal | dmj_s76, hi -- we've just deployed Xenial 4.4.0-31.50 including the nouveau patch in the -proposed archive -- can we get you to do one more quick smoke test of it for verification? | 15:53 |
| dmj_s76 | kamal: sure...I'll work on that this morning | 15:54 |
| kamal | dmj_s76, thanks a bunch -- just a sanity check on any one of the GPU's should be sufficient | 15:55 |
| === JanC is now known as Guest81961 | ||
| === JanC_ is now known as JanC | ||
| dmj_s76 | kamal: Just tested it...everything works right once the installer pulls in the proposed kernel. (Still have to do some nasty workarounds to get to the installer, but that should be fixed once the kernel hits the daily iso) | 17:03 |
| kamal | dmj_s76, excellent, thanks again for all this | 17:03 |
| dmj_s76 | My pleasure, makes the Ubuntu experience better and removes a huge support burden from us. | 17:04 |
| === PaulW2U_ is now known as PaulW2U | ||
| lamont | does ipv6 autoconf truly not work through a (xenial, 4.4.0-28-generic) bridge? | 17:34 |
| apw | lamont, are you saying the work around you had no longer works ? | 17:42 |
| lamont | there wasn't a bridge involved in that... | 17:44 |
| apw | lamont, there wasn't? i remember it as bridge related | 17:46 |
| lamont | this issue is that I boot a vm on a subnet that only has ipv6 (libvirt qemu-kvm), and I see the router solicitation go from the vm to ff02::2 on vnet0, but not on eth0.3 (the other interface in the bridge) | 17:46 |
| lamont | oh. | 17:46 |
| lamont | two different problems: | 17:47 |
| lamont | 1) br0 (eth0.2 and actually nothing else atm), didn't get an ipv6 autoconf on the host, because of multicast_snooping being enabled. | 17:47 |
| lamont | turns out that (I think), just enabling mutlicast_querier on that bridge is sufficient to get things happier, as a less invasive workaround | 17:47 |
| lamont | the new issue is on br1 (which I've been poking at for way too long now...) | 17:48 |
| lamont | current config is identical to br1, only with eth0.3 instead of eth0.2 | 17:48 |
| lamont | and the issue is that the VM doesn't get ipv6 autoconf | 17:48 |
| lamont | at one point, I had radvd installed on the host, advertising to eth0.3, and it seemed that broke autoconf for br0... but I didn't fully dive down that rathole. | 17:49 |
| lamont | so I brought up eth0.3 on the host that has radvd for eth0.2, and... | 17:49 |
| lamont | the host for the vms now autoconfs on both br0 and br1, and none of the vms do. | 17:50 |
| lamont | having said that, /proc/sys/net/ipv6/conf/$IFACE/mc_forwarding would seem to be HIGHLY relevant to my needs, but utterly lacking in documenation as to how to configure it to forward all traffic bound for ff02::/64 | 17:51 |
| lamont | end rant | 17:51 |
| lamont | http://paste.ubuntu.com/19288160/ <-- tcpdump -ni br1 icmp6 | 17:52 |
| lamont | ...:89:57 is hte vm | 17:52 |
| lamont | and yes, when I actually get this mess working, there's a blog post in it. | 17:53 |
| lamont | grep -ve ^# -e ^$ /etc/smcroute/startup.sh | 18:06 |
| lamont | mgroup from eth0.3 source fe80::1 group ff02::1 | 18:06 |
| lamont | mroute from eth0.3 source fe80::1 group ff02::1 br1 | 18:06 |
| lamont | it hurts, but it configures ipv6 on the guests | 18:06 |
| memguy | does any body know what the equivalent of configfs is in new linux is this info found somewhere in /sys sysfs? | 18:11 |
| apw | lamont, hrm | 18:12 |
| lamont | apw: which gets me to the next issue, where I see ipxe on the vm poke ff02::16 a couple times, and then fail over to ipv4 boot | 18:14 |
| lamont | hitting ctl-b for the ipxe command line doesn't help either | 18:16 |
| lamont | something tells me it may be time to bring in another box and see how it does booting with something like a real firmware interface | 18:17 |
| lamont | apw: mind you, that's still totally ignoring the router solicitations | 18:20 |
| lamont | ultimately, I suspect that I need dhcp6 queries from ipxe | 18:21 |
| bbuccianti | Hi! | 20:56 |
| bbuccianti | i don't want to interrupt anything | 20:56 |
| bbuccianti | but i have a problem and i can't resolve alone | 20:56 |
| bbuccianti | my kernel is booting to slow, or i think so | 20:57 |
| bbuccianti | look at my systemd-analyze | 20:57 |
| bbuccianti | systemd-analyze | 20:57 |
| bbuccianti | Startup finished in 16.145s (kernel) + 7.476s (userspace) = 23.622s | 20:57 |
| apw | bbuccianti, that does seem quite high, though not world ending | 21:07 |
| bbuccianti | i agree with you | 21:09 |
| bbuccianti | but i want to learn | 21:09 |
| bbuccianti | and reduce boot time | 21:09 |
| bbuccianti | can you give me some resources? | 21:09 |
| memguy | i got a question on vdso how does this actually speed up syscalls . I know it maps a page for each program with the vdso.so lib but doesn't each still at the lowest level have to call sysenter/exit or int instructions? Or is it speeding it up by remapping a complete syscall handler function into vdso.so userspace page? | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!