Unloading a module set up with kernel parameters without rebooting

Y

Yesyesloud

Guest
Is there any way to do that? It would make a handy workaround for my situation.

Avoidable info (well, if someone secretly solved the root of the problem and didn't make the solution public up to this date, their help will be most welcome):
ATI FOSS drivers have been working okay-ish for video playback (I wish there were less screen tearing) and I haven't played many heavy 3D games on Linux lately, plus, despite being a battery hog (2 to 3x faster discharging), it has better HDMI multihead support than proprietary (no artifacts or hangs when the cable is disconnected, a biggie for me), thus I loaded open source drivers and manually enabled a FOSS module for Radeon HDMI audio (it wouldn't work otherwise) that is known to cause problems - in my case, when it is enabled, temperature goes sky-high during skype conferences and the computer shuts down on its own within a few minutes. High resolution videos will also make the APU very hot, but not as fast or usually as hot as Skype. Temperatures also keep higher than I'd like when the computer is idle, but decent multi-display support keeps me from going back to proprietary.

The thing:

The line on grub.cfg in which the module parameter was manually included:

linux /vmlinuz-linux root=UUID=4d265c22-7b6f-4ccd-8a7c-388f98fbacbf rw radeon.audio=1 quiet splash

Common sense says that the handiest way to disable that module is by rebooting to edit it out during boot, and I do it frequently, but I wish I could disable/enable that driver without restarting my laptop. Possible?
 
Last edited:


That HDMI audio module can be unloaded during a desktop session, but temperatures would only lower if it were never loaded on boot.

I decided to install the development proprietary video driver, it also comes with an HDMI audio module, let's see if it will handle multi-monitor set ups better than the latest stable version.
 
Last edited:
I saw the word "APU" and shuddered a little. :eek: A friend of mine has a laptop with an AMD E1-2500 APU and I could not get any system to function nicely on it. Neither the FOSS or Proprietary drivers seem to support it very well. He has since switched back to windows 8. :oops:

Anyway, yes it is possible. The trick is knowing which modules depend on the one you want to remove. Like package dependencies.
 
I saw the word "APU" and shuddered a little. :eek: A friend of mine has a laptop with an AMD E1-2500 APU and I could not get any system to function nicely on it. Neither the FOSS or Proprietary drivers seem to support it very well. He has since switched back to windows 8. :oops:

Anyway, yes it is possible. The trick is knowing which modules depend on the one you want to remove. Like package dependencies.
I managed to turn off that nasty but useful HDMI sound module during the x session, but I learnt temperatures would only lower if the module weren't even loaded during boot. Thus, I decided to quit FOSS video and hdmi audio drivers for catalyst-test.

AMD Catalyst 14.1 (development) is so much better than stable releases (which I used before FOSS). It works with xorg 1.15 and I have no more catalyst multihead issues. Peak temperatures are always ~20ºC (~68ºF) lower with proprietary video drivers on this laptop, and battery cycles last about thrice more.

The 2 APUs (A8-4500M and A10-5757M) I've had experience with seem to have good Linux support, but I can see why people give up on these tricky chips sometimes. Installing and configuring catalyst drivers on ARCH became a moderately difficult task, for instance.

From what you say, the E-series APUs may cause some of those Linux nightmares we eventually have... :O
 
Major update:

I've just upgraded ARCH. FOSS driver (xf86-video-ati) is running great on kernel 3.13.5-1-ARCH and xorg 1.15.0-5.

Most linux kernels from 3.13.x on may also do the job.

No need to load Radeon HDMI audio module with boot parameters anymore, it's loaded out of the box now.

No screen tearing in 3D gaming and 1080p videos. As well as 3D rendering, temperatures seem to be as good as proprietary driver's. Skyping is also smooth now.

This goes for both my A10-5757M and A8-4500M systems.
 
I managed to turn off that nasty but useful HDMI sound module during the x session, but I learnt temperatures would only lower if the module weren't even loaded during boot. Thus, I decided to quit FOSS video and hdmi audio drivers for catalyst-test.

AMD Catalyst 14.1 (development) is so much better than stable releases (which I used before FOSS). It works with xorg 1.15 and I have no more catalyst multihead issues. Peak temperatures are always ~20ºC (~68ºF) lower with proprietary video drivers on this laptop, and battery cycles last about thrice more.

The 2 APUs (A8-4500M and A10-5757M) I've had experience with seem to have good Linux support, but I can see why people give up on these tricky chips sometimes. Installing and configuring catalyst drivers on ARCH became a moderately difficult task, for instance.

From what you say, the E-series APUs may cause some of those Linux nightmares we eventually have... :O

What is the manufacture of this laptop? Does your laptop display wake from suspend after lid closing?
I'm running the same Arch kernel version but have not iinstalled catalyst 14.1 yet I just loaded straight ATI drivers so far. I did read the 3.13.3 change log and thought I'd wait for Arch to update from 3.12.
 
What is the manufacture of this laptop? Does your laptop display wake from suspend after lid closing?
I'm running the same Arch kernel version but have not iinstalled catalyst 14.1 yet I just loaded straight ATI drivers so far. I did read the 3.13.3 change log and thought I'd wait for Arch to update from 3.12.
Acer. Also, mobo revisions have been changing a lot, but I had the models of mine noted down somewhere, after I opened my computers out of curiosity. This info is trickier to get from most laptops nowadays, I guess the "manufacturers" don't want people to know how rebranded their hardware is.

Anyway, I always keep my system up-to-date, there have been 2 kernel updates for ARCH from its official repositories lately (in less than a week, I guess). 3.13.5-1-ARCH, currently. Big improvements took place. Take a look at my previous post.

I'm using FOSS drivers for now. My display wakes from suspend when lid is re-opened, although it used to behave in the same manner with Catalyst 14.1.

This is the first serious ride I'll give FOSS drivers, since they've never worked for me before.
 
Last edited:
Acer. Also, mobo revisions have been changing a lot, but I had the models of mine noted down somewhere, after first I opened my computers out of curiosity. This info is trickier to get from most laptops nowadays, I guess the "manufacturers" don't want people to know how rebranded their hardware is.

Anyway, I always keep my system up-to-date, there have been 2 kernel updates for ARCH from its official repositories lately (in less than a week, I guess). 3.13.5-1-ARCH, currently. Big improvements took place. Take a look at my previous post.

I'm using FOSS drivers for now. My display wakes from suspend when lid is re-opened, although it used to behave in the same manner with Catalyst 14.1.

This is the first serious ride I'll give FOSS drivers, since they've never worked for me before.

My systems are up to date as well, but the first of the two recent updates sacked my wireless on two of the three Arch systems. It was an easy fix, thankfully, common issue with Broadcom adapters after a kernel update.
My problem with my HP is well noted in Arch support but I assumed it was resolved, because I saw a lot of resolved issues with the similar model. My fault for not doing the proper research.
Thanks for posting this thread I'm going to re read through it to see what I might benefit from. I've been bed ridden in illness for a week so I have'nt messed with this newer laptop build.
 
My systems are up to date as well, but the first of the two recent updates sacked my wireless on two of the three Arch systems. It was an easy fix, thankfully, common issue with Broadcom adapters after a kernel update.
My problem with my HP is well noted in Arch support but I assumed it was resolved, because I saw a lot of resolved issues with the similar model. My fault for not doing the proper research.
Thanks for posting this thread I'm going to re read through it to see what I might benefit from. I've been bed ridden in illness for a week so I have'nt messed with this newer laptop build.
No problems :)

Broadcom is a mess on Linux, maybe there will be some hook service to automatize its driver fixes after kernel upgrades on ARCH.

I've had an HP DV9000 for years. It caused me serious headaches, as well as to almost everybody who owned one - I had to have its nvidia bga gpu reballed. I hope HP enhanced their builds. Still, I loved that pretty big thing :D

Best of luck with your new laptop. If it's recent, those kernel upgrades may likely enhance hardware support.
 
Last edited:


Top