Package Base Details: oss

Git Clone URL: (read-only, click to copy)
Keywords: oss
Submitter: keenerd
Maintainer: alexdw
Last Packager: alexdw
Votes: 48
Popularity: 0.005456
First Submitted: 2013-09-25 11:25
Last Updated: 2021-01-15 00:09

Packages (2)

Latest Comments

« First ‹ Previous ... 3 4 5 6 7 8 9 10 Next › Last »

freestyler7 commented on 2013-12-05 19:15

Thanks for the package. Worked perfectly.

nuc commented on 2013-11-16 19:39

oss 4.2_2008-3 is fully working, thanks!

Nowaker commented on 2013-11-16 18:00

I performed the same change to oss-git package. I couldn't verify if it's working though, so if anyone could have a look, I would be grateful.

Nowaker commented on 2013-11-16 17:37

Updates done. Thank you toksik!

toksik commented on 2013-11-14 18:53

I didn't expect that comments are stripped off of leading white space and tabs so the posted patch is a bit mangled. Here it is again:

@keenerd Great to hear you're interested in bringing OSS back into the repo.
The soundon issue seems to be easy to fix:

I could not reproduce the uninstall problem and might need some more details on it. However the deletion of the alsa modules could as well be replaced by some file in /etc/modprobe.d/ that blacklists these modules.

@Nowaker I've also uploaded an updated PKGBUILD:

nuc commented on 2013-11-11 22:21

Oh great.. so Hannu Savolainen's statement was quite right
> OSS doesn't use memmove at all so this problem must be caused by some
> new version of gcc that geterates calls to memmove. I have never heard
> about this kind of problem.

keenerd commented on 2013-11-11 20:51

> This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo.

toksik, awesome!

Not to be a BOFH, but if I brought it back into the repos I'd want the nastiest remaining bugs fixed first. The two major issues were 'soundon' and the uninstall script. 'soundon' would sometimes take several minutes to finish. (That was isolated to a single line in the soundon script, didn't look deeper.) The uninstall script had become a complete mess - it was supposed to put the alsa drivers back into place as if nothing happened. Instead you'd have to reinstall the kernel and reboot.

toksik commented on 2013-11-11 18:43

@Nowaker It is soley the OSS developers fault.

Either they relied on something that cannot be relied on, especially not when they turn compiler optimizations on by default. It was pure luck that this did not affect OSS in the past.

Or they are just doing the wrong thing to build the kernel module. My patch fixes the latter.

Nowaker commented on 2013-11-11 18:18

@toksik, Thank you very much for your input. I will update all the PKGBUILDs very soon.

Is it something worth reporting to GCC issue tracker as a bug? Or it's just oss's fault?

toksik commented on 2013-11-11 18:14

I seem to have finally discovered the actual bug in OSS and was able to fix it properly. This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo.

The patch below requires setup/Linux/oss/build/osscore.c to be renamed to osscore_wrapper.c (in prepare) and should be applied after all other patches.

When osscore.ko is loaded by running soundon dmesg shows

osscore: no symbol version for memmove
osscore: Unknown symbol memmove (err -22)

saying two things:

1. The function memmove is called somewhere in the kernel module.
Generally this is fine as the linux kernel provides the function.

What is interesting is that it is never directly called in the OSS codebase. Instead it is GCC that, in newer versions, sometimes generates calls to memmove as part of its code optimization at optimization level "-O3". To be precise it is an assingment in the function setfragment_error in kernel/framework/audio/oss_audio_core.c that gets optimized in this way. GCC's behaviour is correct and even documented in it's man page.

2. Symbol version information for memmove is missing.
The usual way to build a kernel module externally is to use the Makefile provided in /lib/modules/VERSION/build: It takes care of generating symbol version information and linking everything to a .ko kernel module.

This is also what OSS does with it's linux kernel wrapper to generate /lib/oss/build/osscore.ko. What it does then is what causes the problem: The main part of OSS /lib/oss/objects/osscore.o, which unfortunately contains the call to memmove, is linked together with this osscore.ko to /lib/modules/extramodules-VERSION/oss/osscore.ko with a conventional "ld". This of course does not take care of symbol versioning so that it is missing for symbols only used in this main part of OSS.

The fix is to hand both /lib/oss/build/osscore.c (renamed to osscore_wrapper.c to avoid name conflicts) and /lib/oss/objects/osscore.o (copied by to osscore_mainline.o) over to the provided Makefile that then generates symbol version information for the whole osscore.ko module.

I've successfully tested the patch on x86_64 and i686 with gcc-4.8.2.

--- setup/Linux/oss/build/ 2013-11-10 20:56:26.182816531 +0100
+++ setup/Linux/oss/build/ 2013-11-10 21:00:08.858276861 +0100
@@ -203,11 +203,8 @@
exit 3

-if ! $LD -r osscore.ko osscore_mainline.o -o /lib/modules/$UNAME/kernel/oss/osscore.ko
- echo Linking the osscore module failed
- exit 5
+cp -f osscore.ko /lib/modules/$UNAME/kernel/oss/osscore.ko

if test -f Module.symvers
--- setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:57:25.732493923 +0100
+++ setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:59:46.185066359 +0100
@@ -5,6 +5,7 @@

obj-m := osscore.o
+ osscore-y := osscore_wrapper.o osscore_mainline.o