[OSS-worked-around] Kernel modules being unzipped after every reboot?

cshake · 2013-05-26 02:25:09

I've been having this issue for a while, but didn't bother to track it down until now...
Every time I log into my desktop environment (xfce4, xfwm, through slim) the process monitor widget shows one full core of CPU usage for almost a minute after the desktop loads. I open it up to look at what's going on, and immediately after I update oss it is gcc rebuilding those modeles, but every other time it appears to be running a whole bunch of "sh gunzip <path to various places in the kernel tree>". Now, I update fairly regularly and generally only reboot after an update, but I checked it and this happens after every boot even if I haven't recently updated anything.
Is there a reason for this? I would think that it should cache these unzipped modules so it doesn't take up a full core for a minute every boot, but I could be wrong, since I can't find any reference to this anywhere online...

Last edited by cshake (2013-05-27 01:02:19)

falconindy · 2013-05-26 15:09:36

Sounds like something you've done on your own -- there's isn't any such "feature" in Arch. If we wanted to ship unzipped modules, we'd ship unzipped modules.

cshake · 2013-05-26 20:58:29

I haven't done anything custom that I know of - installed fresh around 2 years ago and have kept it updated since, (through the migration from sysv to systemd, sysvinit is completely gone now and the -compat package has been removed) everything through pacman (yaourt) and a few through AUR (like dropbox and skype at one point, though skype is gone now). I have to use OSS for sound because of the chipset (alsa doesn't find the headphone jack), and that likes to compile itself after an update, but I expected that.

Where could I find what is making this happen? In the startup manager for xfce4 the only auto-started applications are network manager applet, power manager, xscreensaver daemon, and policykit. I don't save sessions between boots, so nothing extra starts from there. Nothing is started in the .xinitrc besides startxfce4. In /etc/systemd/system/multi-user.target.wants there's acpid.service, dcron.service, laptop-mode.service, ModemManager.service, NetworkManager.serice, ntpd.serivice, oss.service, remote-fs.target, sshdgenkeys.service, sshd.service.

I guess this gets moved to newbie corner, because I'm clearly missing something...

WonderWoofy · 2013-05-26 22:21:41

Th only thing I can think of that would recompile things on boot is dkms. Do you have this service activated? Is it in use for anything?

cshake · 2013-05-26 23:16:28

I don't have the dkms package installed, and `locate dkms` returns an empty set.

After some more digging, it appears to be triggered by the "soundon" command from oss. When my laptop sleeps and resumes it doesn't work, so I have to force soundoff && soundon, and the same series of processes happens. I assume figuring that out will fix this problem, so I'll have to go down that route. I didn't expect that it was from sound, because the modules don't appear to be related, but that's no longer a kernel issue.

Thanks for the ideas though.

cshake · 2013-05-27 01:00:45

And now I've finally traced it down to the oss utility `ossvermagic` which apparently calculates or looks at kernel module 'varmagic' identifiers, to check that the oss modules were built against the kernel that is currently booting. However, it returns an empty string after running for around 2 minutes (on my machine at least). Running the same program on the compiled modules for oss also returns an empty string.
It appears from a quick search that vermagic was for kernel versions 2.x and not used anymore for 3.x, and could be why this just churns cycles. I can stop this from happening by manually changing the soundon script to not run it and just say the test for string match is true, but if so it doesn't have any way of checking that the modules it is enabling were built for the correct kernel. I'd submit this as a bug upstream in oss, but since they haven't released a new version in 6 years, I'll just submit one on the arch bug tracker.

WorMzy · 2013-05-27 01:50:06

cshake wrote:

I'd submit this as a bug upstream in oss, but ... they haven't released a new version in 6 years

The last OSS release was on 2012-07-03: http://www.opensound.com/forum/viewtopi … =19&t=4754

Latest git commit was 2013-03-18: http://opensound.git.sourceforge.net/gi … mit;h=HEAD

Looks like bug reports go here or here.

cshake · 2013-05-28 11:59:58

WorMzy wrote:

The last OSS release was on 2012-07-03: http://www.opensound.com/forum/viewtopi … =19&t=4754

Ah, oops, thought the 2007 in the version string was a year, not a build. I'll check it out then.

Thaodan · 2013-05-28 15:10:24

WorMzy wrote:

cshake wrote:
I'd submit this as a bug upstream in oss, but ... they haven't released a new version in 6 years
The last OSS release was on 2012-07-03: http://www.opensound.com/forum/viewtopi … =19&t=4754
Latest git commit was 2013-03-18: http://opensound.git.sourceforge.net/gi … mit;h=HEAD
Looks like bug reports go here or here.

So better use oss-git when using oss?

Arch Linux

#1 2013-05-26 02:25:09

[OSS-worked-around] Kernel modules being unzipped after every reboot?

#2 2013-05-26 15:09:36

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#3 2013-05-26 20:58:29

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#4 2013-05-26 22:21:41

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#5 2013-05-26 23:16:28

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#6 2013-05-27 01:00:45

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#7 2013-05-27 01:50:06

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#8 2013-05-28 11:59:58

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

#9 2013-05-28 15:10:24

Re: [OSS-worked-around] Kernel modules being unzipped after every reboot?

Board footer