| memguy | ok so i insmod every single oss .ko module i could http://pastebin.com/VsiPgkWJ then i created the dsp device file major 14 minor 3 character device then tried to uses it nothing said No such device or address | 04:36 |
|---|---|---|
| memguy | How does the /dev/dsp module get associated with the oss modules from the lsmod seems like everything depends on osscore but not sure on why the device file is not working would have thought one of the LKM would register /uses /dev/dsp i mean what creates this or links this to usable device file | 04:38 |
| mjg59 | memguy: Why are you trying to use the oss drivers? | 04:41 |
| memguy | I know i may have installed the modules in the incorrect order or didn't pass parameters so maybe thats the issue. in dmesg i do have a lot of | 04:41 |
| memguy | oss_ali5455: Unknown symbol ac97_spdifout_ctl (err 0) | 04:41 |
| mjg59 | If all you want is /dev/dsp, then use alsa and load the OSS compatibilty module | 04:42 |
| memguy | ...etc so maybe its those issue... though i am spining my head on what modules and what parameters to uses with this audio hardware 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) | 04:42 |
| memguy | I just want to uses the old oss as opposed to the alsa stuff for right now | 04:42 |
| mjg59 | If the alsa driver is loaded then OSS won't be able to bind | 04:43 |
| memguy | well this kind of sucks i am trying to remove the alsa module or all the snd.* LKM but i get Module snd is in uses | 04:47 |
| memguy | humm so first off how does one locate dependencies or process currently using an LKM so i can terminate these resources so i can modprobe -r snd.* all away | 04:48 |
| memguy | Thats my first issue my second issue is what .ko to load to get oss sound working mjg59 you mentioned using the alsa loading the oss compatiblity module what name would that be for the .ko what location | 04:50 |
| memguy | ya kind of sucks seems if i kill pulseaudio or hd-audio it just recreates the process something so those are not the root process | 04:53 |
| memguy | so i am kind of stuck not able to unload these lkm's and not able to kill the sound audio process that probably uses these LKM | 04:53 |
| mjg59 | memguy: load snd_pcm_oss | 04:58 |
| mjg59 | That'll give you /dev/dsp | 04:58 |
| memguy | where would that .ko file be located /lib/modules/??? | 04:59 |
| mjg59 | Why? | 05:00 |
| memguy | doing a find for it gave me nothing | 05:00 |
| mjg59 | Just do modprobe snd_pcm_oss | 05:00 |
| memguy | modprobe: FATAL: Module snd_pcm_oss not found. | 05:00 |
| mjg59 | Oh hm. I haven't actually checked whether that's still built. | 05:01 |
| memguy | either way my more general issue is how to uninstall all the snd LKM's rmmod with out getting dependency issues or module in uses | 05:02 |
| mjg59 | Try installing osspd instead? That uses CUSE to emulate /dev/dsp | 05:02 |
| memguy | ya i will give that a try some time but really rather then using some software character driver analogy to FUSE .. i want to understand how to load and unload the different sound modules properly from scratch | 05:03 |
| ohsix | why? | 05:04 |
| memguy | because to me understanding how to load and unload proper lkm's for devices you have more control in the end of troubleshooting and getting hardware to work | 05:05 |
| ohsix | that doesn't follow but OK | 05:05 |
| memguy | Plus to me this is the missing piece in understanding what creates the /dev/dsp what LKM's and how they are associated to an LKM the device files them selfs | 05:05 |
| memguy | Ideally i would have like to uninstall /rmmod/modprobe -r all the snd.* modules i had from lsmod ... then go to the oss .ko and insmod/ modprobe them to create the /dev/dsp ...etc devices | 05:07 |
| memguy | And the other important thing to understand would have been how to trace down what is holding some LKM from not unloading | 05:08 |
| memguy | any help would be great on the uninstalling in use modules how one can remedy this | 05:10 |
| memguy | so i guess if rmmod -f doesn't work because kernel wasn't compiled with the ability to force modules to unload then one would have to track down all dependencies by hand and kill those... and if there is circular dependencies then the only way i can see it is a reboot with blacklisting | 05:37 |
| memguy | 483 ? 00:00:00 pulseaudio | 05:46 |
| memguy | 1442 ? 00:00:00 hd-audio0 | 05:46 |
| memguy | 387 ? 00:00:00 indicator-sound | 05:46 |
| memguy | does anybody know how to kill these process because they get like recreated | 05:46 |
| memguy | and i am thinking that these are part of my problem of not being able to rmmod -f the snd.* LKM | 05:47 |
| memguy | ok well i got it down to 1442 ? 00:00:00 hd-audio0 | 06:15 |
| memguy | removing pulseaudio because it auto regenerates so trying to figure out this last one | 06:15 |
| memguy | never mind figured it out after i removed rmmod -f in the correct order from 0 dependencies onward i finally was able to remove all the snd.* based modules which when i looked took care of the ps 1442 process. Which this all was held up by pulseaudio being installed. I am curious of one thing when i relooked at /dev/snd all the devices pretty much disappeared but i am left with seq and timer so curious maybe there is still | 06:40 |
| memguy | an LKM that is for audio just not named snd.* that i am missing? | 06:40 |
| memguy | Or why are these 2 devices left behind | 06:40 |
| apw | memguy, or that is from something which is built in | 08:42 |
| ricotz | apw, hi, isnt that essential for the 4.7 mainline builds? https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/commit/?id=a3b42405327c946274fe8ee0e737a27b396ce7bf | 10:47 |
| apw | ricotz, i am not sure what you are asking | 10:48 |
| ricotz | apw, I have a "missing-symbols" problem of nvidia dkms module with the 4.7 mainline kernel | 10:49 |
| apw | ricotz, with which one | 10:49 |
| apw | ricotz, these are only debug builds, they not intended for long term use | 10:50 |
| ricotz | apw, sorry, currently can't say with exact symbol it was | 10:50 |
| apw | ricotz, no which version of the mainline build ... as they are built with whatever tim applies | 10:51 |
| apw | so any which are newer than when he applied that will have that | 10:51 |
| ricotz | 4.7rc4 worked, none after that | 10:51 |
| apw | ricotz, which is the latest you have tried | 10:51 |
| ricotz | rc6 | 10:51 |
| apw | -rc7 built at 5 UTC this morning which would have been after so it should be "fixed" if that is your issue | 10:52 |
| ricotz | the initrd size shrunk by over 1MB with it | 10:52 |
| apw | symbol tables are big | 10:52 |
| ricotz | -rw-r--r-- 1 root root 45060130 Jul 11 12:29 initrd.img-4.6.0-8-generic | 10:53 |
| ricotz | -rw-r--r-- 1 root root 43939988 Jul 11 12:28 initrd.img-4.7.0-040700rc6-generic | 10:53 |
| apw | so i guess test -rc7 if that resolves the issue, then it may be worth rebuilding 5 and 6 | 10:54 |
| ricotz | will reinstall rc4/rc5 in a bit | 10:56 |
| * apw is confused, but will let you report whatever you do | 10:58 | |
| ricotz | I just want to double check the old kernels and having the dkms module with the current toolchain | 10:59 |
| ricotz | apw, btw, the rc7 build doesnt include the mentioned commit | 11:04 |
| apw | ricotz, it wouldn't need to include a commit | 11:04 |
| apw | ricotz, the changelog is dropped in wholesale | 11:04 |
| ricotz | ok | 11:06 |
| ricotz | apw, https://paste.debian.net/plain/780375 | 11:21 |
| apw | ricotz, with which version | 11:21 |
| ricotz | seems rc7 is more complete compared to rc5/rc6 and grepping the Symbols.map listings matches the rc4 one | 11:22 |
| ricotz | 367.27 | 11:23 |
| ricotz | this was from a log of rc5 | 11:23 |
| ricotz | e.g. "grep -r _smp_call_function$ System.map-*" | 11:24 |
| ricotz | apw, looks like the rc7 build works again with nvidia here | 11:38 |
| apw | ricotz, ack | 11:38 |
| ricotz | apw, was this a known issue with those missing symbols like *_smp_call_function ? | 11:40 |
| apw | ricotz, upstream added an option to remove redundant exports from the symbol tables to save space, this broke out of tree modules using any of them | 11:41 |
| ricotz | ok | 11:47 |
| rtg | dannf, I think the only kernels we're accepting patches for are P,T,LTS-U,X, and Y. V and W are now EOL. kamal - correct me if I'm wrong. | 16:23 |
| dannf | rtg: yeah, already sync'd with kamal - W is EOL, but V isn't for some reason | 16:24 |
| rtg | dannf, ack | 16:24 |
| kamal | rtg, the ones that just went EOL are LTS-U and W (V is still alive) | 16:24 |
| rtg | kamal, ack | 16:24 |
| memguy | is /dev/pcm0,1,2 and /dev/pcmin0,1 the oss device files for speakers/lineout and mic/line in if so how do you know which device file is associated to which device without trial and error | 18:26 |
| memguy | O never mind ossinfo tells me everything i need to know except i still don't get what /dev/dsp_ac3 -> /dev/oss/oss_hdaudio0/spdout0 devices is for is this some kind of digital in/out port or something | 18:31 |
| memguy | i imagine | 18:34 |
| memguy | SPDIF seems as it for an output port also digital but never used it of all the other port i think this and midi are the ones i never used | 18:48 |
| === sakrecoer_ is now known as sakrecoer | ||
| === DzAirmaX_ is now known as DzAirmaX | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!