[arch-dev-public] [signoff] udev 118-4
Crap, I missed the start_udev install. I guess I didn't fully test support for half-upgraded systems (why are we supporting this again? not sure, but people complained loudly enough). Thanks Thomas for pointing out that I was trying to install start_dev 8) ** Could someone build an i686 package for me, I have no remote access to my i686 box ** Reverting back to the older way of doing things, with minor improvements where they can be made Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule. Potential bug closings: http://bugs.archlinux.org/task/9648 http://bugs.archlinux.org/task/9193
Aaron Griffin schrieb:
Thanks Thomas for pointing out that I was trying to install start_dev 8)
** Could someone build an i686 package for me, I have no remote access to my i686 box **
Done.
Reverting back to the older way of doing things, with minor improvements where they can be made
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
Works for me. Signoff i686. -Dan
Am Samstag, 8. März 2008 schrieb Dan McGee:
On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
Works for me. Signoff i686.
-Dan
no signoff please add the framebuffer blacklist again to load-modules.sh, it's not possible to block framebuffer loading by udev rules. framebuffer modules can cause weird issues for amd/ati and nvidia binary drivers. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sat, Mar 8, 2008 at 10:34 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Dan McGee:
On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
Works for me. Signoff i686.
-Dan
no signoff please add the framebuffer blacklist again to load-modules.sh
This is a terrible place for it, as I tried to explain on IRC. We should not explicitly block a set of modules here. If we don't want them, then why the hell do we even put them in our kernel? If we do want them, then blacklist them correctly, which means people can have the option of *not* blacklisting them.
, it's not possible to block framebuffer loading by udev rules.
Can you please explain why? Thanks.
framebuffer modules can cause weird issues for amd/ati and nvidia binary drivers.
Sure, but not everyone uses a binary driver, and/or even xorg for that matter. I feel like I'm just being a naysayer here without actually providing a way to fix it, but this just seems like such a backwards way to fix a problem to me. -Dan
no signoff please add the framebuffer blacklist again to load-modules.sh
This is a terrible place for it, as I tried to explain on IRC. We should not explicitly block a set of modules here. If we don't want them, then why the hell do we even put them in our kernel? There was a request from people who wants to use it. You need user interaction to get them working.
If we do want them, then blacklist them correctly, which means people can have the option of *not* blacklisting them. You need parameters to enable the funtionality, disable the built in vesa framebuffer on kernel boot prompt and load the correct framebuffer module by rc.conf.
, it's not possible to block framebuffer loading by udev rules.
Can you please explain why? Thanks. Show me the rule which would do it? It is triggered by the pci subsystem so there is no chance in blocking it from loading.
framebuffer modules can cause weird issues for amd/ati and nvidia binary drivers.
Sure, but not everyone uses a binary driver, and/or even xorg for that matter. Why to cause trouble for people, where it is not needed?
I feel like I'm just being a naysayer here without actually providing a way to fix it, but this just seems like such a backwards way to fix a problem to me. Well going backwards at least fixes issues here, sure it could be probably done also by a generated blacklist which is only generated once, but we need to do something here.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Dan McGee schrieb:
, it's not possible to block framebuffer loading by udev rules.
Can you please explain why? Thanks.
The current package has the rule KERNEL=="fb[0-9]*", GOTO="hotplug_driver_loaded" However, this rule cannot work: At the point where the driver is not loaded, all you get is a uevent with a MODALIAS property, and without resolving that modalias, you cannot know what module will be loaded. Udev cannot set the KERNEL variable before the driver is loaded. If we don't want to put those modules in load-modules.sh, we can only put them in our normal blacklist, or blacklist them using a modprobe.d file.
On Sat, Mar 8, 2008 at 10:34 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Dan McGee:
On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
Works for me. Signoff i686.
-Dan
no signoff please add the framebuffer blacklist again to load-modules.sh, it's not possible to block framebuffer loading by udev rules.
framebuffer modules can cause weird issues for amd/ati and nvidia binary drivers.
a) Removing it was a mistake but I absolutely _will not_ go back to the old way. Do you know that my machine boots 17 seconds faster by removing those two loops? 17 seconds, for one module which actually works completely fine when loaded on my machine. b) I have radeonfb and nvidiafb loaded on two different machines and they work fine. c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On Sat, Mar 8, 2008 at 10:34 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Dan McGee:
On Fri, Mar 7, 2008 at 4:58 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Mar 7, 2008 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Somehow, module loading is considerably faster here than before (even fast than with 118-2)
Yeah, there were 2 filesystem globbing based loops in there that were the major killers... for every module load it was doing a "ls /foo/bar/*/*/blah" which is ridiculously slow.
Module loading and all that should be back to sanity, with slightly improved performance due to moving the framebuffer modules out to a udev rule.
Doesn't work: intelfb is loaded here (but doesn't do anything, as intelfb never worked).
Weird. Same thing here. I assumed it was working because it was balking before when it tried to load nvidiafb, and then stopped freaking out. Apparently, though, nvidiafb is loaded here... and doing nothing. So this udev rule to skip the modalias load fails... hrm
Works for me. Signoff i686.
-Dan
no signoff please add the framebuffer blacklist again to load-modules.sh, it's not possible to block framebuffer loading by udev rules.
framebuffer modules can cause weird issues for amd/ati and nvidia binary drivers.
a) Removing it was a mistake but I absolutely _will not_ go back to the old way. Do you know that my machine boots 17 seconds faster by removing those two loops? 17 seconds, for one module which actually works completely fine when loaded on my machine.
Amazing speedup.
b) I have radeonfb and nvidiafb loaded on two different machines and they work fine.
For me, it doesn't work. nvidiafb is loaded on startup (because no blacklisting works) and that causes to fail loading the nvidia module, which ends in a non-starting xorg. And I'm not the only one, who has this problem.
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
On Sat, Mar 8, 2008 at 4:24 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
Right, the reason I bring this up is that apparently some people are against using a modprobe.d file for this. Funny question though, if we make a /etc/modprobe.d/framebuffer_blacklist file, or something, what package does it belong to? I almost think it should be part of the kernel, but that seems weird.
Am Samstag, 8. März 2008 schrieb Aaron Griffin:
On Sat, Mar 8, 2008 at 4:24 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
Right, the reason I bring this up is that apparently some people are against using a modprobe.d file for this.
Funny question though, if we make a /etc/modprobe.d/framebuffer_blacklist file, or something, what package does it belong to? I almost think it should be part of the kernel, but that seems weird.
It should belong to udev because udev loads it, kernel doesn't make sense. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Mar 9, 2008 at 1:33 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Aaron Griffin:
On Sat, Mar 8, 2008 at 4:24 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
Right, the reason I bring this up is that apparently some people are against using a modprobe.d file for this.
Funny question though, if we make a /etc/modprobe.d/framebuffer_blacklist file, or something, what package does it belong to? I almost think it should be part of the kernel, but that seems weird.
It should belong to udev because udev loads it, kernel doesn't make sense.
Er? No. Modprobe loads it. udev calls a script that calls modprobe. We are not talking about where the CURRENT frambuffer blacklist exists, because I'm sure we all agree it is inefficient and broken. I'm talking about where it SHOULD be.
Am Sonntag, 9. März 2008 schrieb Aaron Griffin:
On Sun, Mar 9, 2008 at 1:33 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Aaron Griffin:
On Sat, Mar 8, 2008 at 4:24 PM, Daniel Isenmann <daniel.isenmann@gmx.de>
wrote:
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin"
<aaronmgriffin@gmail.com> wrote:
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
Right, the reason I bring this up is that apparently some people are against using a modprobe.d file for this.
Funny question though, if we make a /etc/modprobe.d/framebuffer_blacklist file, or something, what package does it belong to? I almost think it should be part of the kernel, but that seems weird.
It should belong to udev because udev loads it, kernel doesn't make sense.
Er? No. Modprobe loads it. udev calls a script that calls modprobe. We are not talking about where the CURRENT frambuffer blacklist exists, because I'm sure we all agree it is inefficient and broken. I'm talking about where it SHOULD be.
A file which belongs to a package that will affect also an other is bad. Placing it in kernel package is bad because it might interfere with an other kernel package. Placing the file in udev affects all kernels the same and udev is our primary module loader for now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Sonntag, 9. März 2008 schrieb Tobias Powalowski:
Am Sonntag, 9. März 2008 schrieb Aaron Griffin:
On Sun, Mar 9, 2008 at 1:33 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Samstag, 8. März 2008 schrieb Aaron Griffin:
On Sat, Mar 8, 2008 at 4:24 PM, Daniel Isenmann <daniel.isenmann@gmx.de>
wrote:
On Sat, 8 Mar 2008 15:37:24 -0600 "Aaron Griffin"
<aaronmgriffin@gmail.com> wrote:
c) The *only* thing that is appropriate is to autoblacklist them via modprobe rules.. Doing it the previous way is absolute crap.
I have done this and it works. I manually add the nvidiafb to modprobe.conf, but that's not a solution, just a workaround for me. It should be placed in a modprobe.d/ file instead, if we will do it.
Right, the reason I bring this up is that apparently some people are against using a modprobe.d file for this.
Funny question though, if we make a /etc/modprobe.d/framebuffer_blacklist file, or something, what package does it belong to? I almost think it should be part of the kernel, but that seems weird.
It should belong to udev because udev loads it, kernel doesn't make sense.
Er? No. Modprobe loads it. udev calls a script that calls modprobe. We are not talking about where the CURRENT frambuffer blacklist exists, because I'm sure we all agree it is inefficient and broken. I'm talking about where it SHOULD be.
A file which belongs to a package that will affect also an other is bad. Placing it in kernel package is bad because it might interfere with an other kernel package. Placing the file in udev affects all kernels the same and udev is our primary module loader for now.
greetings tpowa
Just for your information, i have a full splitup rule udev here now. about blacklisting, problem with modprobe.d/frambuffer would be if a modprobe.conf is present it ignores the modprobe.d/ directory completly :( greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Mar 9, 2008 at 8:48 AM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Sonntag, 9. März 2008 schrieb Aaron Griffin:
Er? No. Modprobe loads it. udev calls a script that calls modprobe. We are not talking about where the CURRENT frambuffer blacklist exists, because I'm sure we all agree it is inefficient and broken. I'm talking about where it SHOULD be.
A file which belongs to a package that will affect also an other is bad. Placing it in kernel package is bad because it might interfere with an other kernel package. Placing the file in udev affects all kernels the same and udev is our primary module loader for now.
But, that's exactly my point. This is only an issue with OUR kernel. If some custom kernel builds in different framebuffer modules, or even only includes the one that is needed, then the blacklisting is moot. The need to blacklist this modules is ONLY an artifact of the way we build the kernel.
Just for your information, i have a full splitup rule udev here now.
I'm not sure what this means? The udev.rules? Shouldn't we just be using (mostly) default rules from the udev source? I notice our PKGBUILD deletes a lot of rules. Why don't we just... not delete these, and then add our own like all the other distros do (i.e. 50-archlinux.rules)
about blacklisting, problem with modprobe.d/frambuffer would be if a modprobe.conf is present it ignores the modprobe.d/ directory completly :(
Ew, I just noticed that. That's a little annoying that it only loads one or the other. There are two solutions to that though: 1) Add "include /etc/modprobe.d" to the default modprobe.conf 2) Patch modprobe to not stop after the first thing found
participants (5)
-
Aaron Griffin
-
Dan McGee
-
Daniel Isenmann
-
Thomas Bächler
-
Tobias Powalowski