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