The AMD/ATI Bar & Grill

Vi0L0 · 2010-09-08 23:12:13

cyberpatrol wrote:

I don't like the idea about the daemon method, because a daemon needs to run always in the background and takes system resources while the fglrx modules only need to be rebuilt after a kernel upgrade. And I really don't want to have a daemon permanently run in the background just for one task which has to be accomplished only once every several weeks or months.
The daemon method would really be a waste of resources.
And it always takes time to starting the daemon at boot time, which means that booting the system takes unnecessarily longer every time.

Looks like you didn't test it . Daemon is taking time to build module but only if kernel was updated. If it wasn't it will just load previously built module - and it's taking less than 1 second. So it's not wasting resources, at least not as much as you thought.
This daemon is really good, i wouldn't even try to give you something crappy. It's better than hook in every way, also hook sometimes fails - ie. it wasn't working for my kernel26-zen, i dunno why, i checked everything.

Plus note that daemon fits to Arch Way far better than a hook.

Last edited by Vi0L0 (2010-09-08 23:30:58)

cyberpatrol · 2010-09-08 23:49:47

Vi0L0 wrote:

Looks like you didn't test it . Daemon is taking time to build module but only if kernel was updated. If it wasn't it will just load previously built module - and it's taking less than 1 second. So it's not wasting resources, at least not as much as you thought.

Even if it only takes a second or less, it takes a second and booting takes a second longer. Then there will be the next (unnecessary) daemon which takes only one second, too, then the third, etc. A daemon is for services which need to do something regularly during uptime or need to be accessible all the time like cups, an e-mail server, a proxy server, the cron daemon, etc., but not for tasks which need to be done once only every now and then.

And it is a waste of system resources, because it needs to permanently stay in memory even if it's not needed and just because it is needed only now and then. And a daemon which needs to permanently stay in memory permanently takes memory space even if it's not needed. And I need my memory for things I need to do.

With your logic you ought to build gcc or the complete hook system as daemons, because it could once be needed to run. So why not keep everything in memory? Why isn't gimp implemented as a daemon? It should be started at boot time, because it could happen that it is needed sometime.

Like I said, a daemon is only for services which need to be accessible all the time, but not for single tasks which are only be accomplished every now and then.

This is a waste of system resources.

Vi0L0 wrote:

This daemon is really good, i wouldn't even try to give you something crappy. It's better than hook in every way, also hook sometimes fails - ie. it wasn't working for my kernel26-zen, i dunno why, i checked everything.
Also note that daemon fits to Arch Way far better than a hook.

It doesn't matter how good the daemon works. It's a matter of system resources, time-saving, efficiency and a matter of the task of a software. And it's definitely not better than a hook, because it wastes system resources, needs unnecessarily time. And this really doesn't have anything to do with an Arch Way or the like. It has something to do with general policies, Linux standards, resource-efficiency, etc.

And, btw., booting my system already takes long enough, I really don't want to wait any longer to have my system up, not a second either, especially not for such an unnecessary daemon which I only need after a kernel upgrade.

Last edited by cyberpatrol (2010-09-08 23:52:35)

Vi0L0 · 2010-09-08 23:56:28

@cyberpatrol:
why do you think it's staying in memory? I don't understant why it should...

I also don't get the argument that booting time will be longer for less than 1 second. How many times you are booting the kernel per day?
Believe me i did many many boots to test this deamon, and it's not annoying at all.

subzero316 · 2010-09-09 00:09:46

Any one checked on Firefox H/W acceleration? http://hacks.mozilla.org/2010/09/hardware-acceleration/

Vi0L0 · 2010-09-09 00:18:36

subzero316 wrote:

Any one checked on Firefox H/W acceleration? http://hacks.mozilla.org/2010/09/hardware-acceleration/

Why do you think it would work? Afaik linux isn't supporting Direct2D.

Vi0L0 · 2010-09-09 00:20:04

Daemon vs Captain Hook
Actually i can provide both methods of automatic re-compilation, so users can decide which one they prefer

cyberpatrol · 2010-09-09 00:25:09

Vi0L0 wrote:

@cyberpatrol:
why do you think it's staying in memory? I don't understant why it should...

Because that's how a daemon is working. How shall a daemon do its task (automatically) if it's not running and staying in memory all the time? Otherwise you would need to start it only if it's really needed, but then you have the hook method and wouldn't need to start the daemon at boot time, and then you again wouldn't need a daemon.

One hint: Look at ps -elyF or htop with this daemon being started at boot time and without the daemon being started at boot time. Every process listed there is a piece of running software which is in memory. Software can't do anything if it's not in the memory. That's why every program needs to be read from harddisk and put into RAM before it can be executed by the CPU. There's no software which can be executed directly from harddisk without being copied into RAM.

And because a daemon is a program which runs permanently regardless of having anything to do or not, it needs to stay in memory. So it takes memory which I need for important things.

And, btw., the more software is staying in memory and eats memory space the more the computer is slowing down.

Vi0L0 wrote:

I also don't get the argument that booting time will be longer for less than 1 second. How many times you are booting the kernel per day?
Believe me i did many many boots to test this deamon, and it's not annoying at all.

I've got a desktop system and need it privately. And because a computer consumes power which costs money, I shut my computer down when I don't need it for a considerable time. So I boot my system several times a day. But even if I would boot my computer only once a day I didn't want to wait unnecessarily longer for such an unnecessary daemon. It's my memory and time which is wasted and I really don't want to start anything senseless at boot time or want it to stay in memory permanently.

Building a module is definitely not a task for a daemon. It is a one-time task which only needs to be done if it needs to be done.

Vi0L0 · 2010-09-09 00:33:29

cyberpatrol wrote:

Vi0L0 wrote:
@cyberpatrol:
why do you think it's staying in memory? I don't understant why it should...
Because that's how a daemon is working. How shall a daemon do its task (automatically) if it's not running and staying in memory all the time? Otherwise you would need to start it only if it's really needed, but then you have the hook method and wouldn't need to start the daemon at boot time, and then you again wouldn't need a daemon.
One hint: Look at ps -elyF or htop with this daemon being started at boot time and without the daemon being started at boot time. Every process listed there is a piece of running software which is in memory. Software can't do anything if it's not in the memory. That's why every program needs to be read from harddisk and put into RAM before it can be executed by the CPU. There's no software which can be executed directly from harddisk without being copied into RAM.
And because a daemon is a program which runs permanently regardless of having anything to do or not, it needs to stay in memory. So it takes memory which I need for important things.
And, btw., the more software is staying in memory and eats memory space the more the computer is slowing down.

Yeah, i checked it, there's nothing in memory related to this daemon, it's just killed after doing it's job.

cyberpatrol wrote:

Vi0L0 wrote:
I also don't get the argument that booting time will be longer for less than 1 second. How many times you are booting the kernel per day?
Believe me i did many many boots to test this deamon, and it's not annoying at all.
I've got a desktop system and need it privately. And because a computer consumes power which costs money, I shut my computer down when I don't need it for a considerable time. So I boot my system several times a day. But even if I would boot my computer only once a day I didn't want to wait unnecessarily longer for such an unnecessary daemon. It's my memory and time which is wasted and I really don't want to start anything senseless at boot time or want it to stay in memory permanently.
Building a module is definitely not a task for a daemon. It is a one-time task which only needs to be done if it needs to be done.

So i will provide both methods of auto re-compilation. I personally will pick up the daemon

cyberpatrol · 2010-09-09 00:34:33

Vi0L0 wrote:

Daemon vs Captain Hook
Actually i can provide both methods of automatic re-compilation, so users can decide which one they prefer

But then you have the problem, that it wastes disk space, because something unnecessary needs to be installed to harddisk regardless of wether someone wants the daemon method or the hook method.

And I really don't see a reason why someone would prefer a permanently running daemon for such a one-time task above the hook method which only rebuilds the module if it's needed. And the hooks are executed automatically after every kernel update anyway. So you can better wait once every now and then for rebuilding the module instead of additionally always waiting for starting a daemon at boot time. You have to wait for the module being built after a kernel update anyway regardless of whether you are using the hook or the daemon method anyway. And there's another problem with the daemon method. How do you know when the module is ready and when you can reboot the system or reload the module? With the hook method you get explicit infos on the screen and now when the modules is being built and when it is ready. And with the hook method you definitely have more control over your system and module than with with the daemon method.

Vi0L0 · 2010-09-09 00:52:40

cyberpatrol wrote:

Vi0L0 wrote:
Daemon vs Captain Hook
Actually i can provide both methods of automatic re-compilation, so users can decide which one they prefer
But then you have the problem, that it wastes disk space, because something unnecessary needs to be installed to harddisk regardless of wether someone wants the daemon method or the hook method.

Yeah, daemon is eating <2KB, thats a very very huge waste of disk space
Actually i can say that hook is also taking disk space, but that argument was never posted by people who didn't want it.

cyberpatrol wrote:

And I really don't see a reason why someone would prefer a permanently running daemon for such a one-time task above the hook method which only rebuilds the module if it's needed. And the hooks are executed automatically after every kernel update anyway.

I prefer daemon because it's working always
And that doesn't actually mean that hook is bad.

cyberpatrol wrote:

And there's another problem with the daemon method. How do you know when the module is ready and when you can reboot the system or reload the module?

You don't need to know, module will be built after kernel's update. Like i said i spent some time for testing it, and it's good . I asked for feedback to be sure.

cyberpatrol wrote:

With the hook method you get explicit infos on the screen and now when the modules is being built and when it is ready.

Daemon will also tell you about the error, and if module won't be built you will see black screen of tty .
But during tests i haven't seen this error.

cyberpatrol wrote:

And with the hook method you definitely have more control over your system and module than with with the daemon method.

Yes, hook is probably more user-friendly. But i don't care since daemon is just doing it's job. I'm also not afraid of tty, so still - i prefer daemon.

Last edited by Vi0L0 (2010-09-09 00:53:54)

cyberpatrol · 2010-09-09 00:54:46

Vi0L0 wrote:

Yeah, i checked it, there's nothing in memory related to this daemon, it's just killed after doing it's job.

But it is only killed after the module is built. If the kernel is not updated and no module has to be built it stays in memory. Or how does it know if and when the module has to be rebuilt?

Or does this daemon only check if the kernel is updated and the module needs to be rebuilt and rebuilds the module at boot time and stops itself after that? But then you have several other issues. If fglrx is in the MODULES array in /etc/rc.conf, what is most likely the case for the most users, the old module for the old kernel gets loaded before the module is rebuilt, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is started by init after /etc/rc.sysinit. So loading the module will fail and/or the module which is loaded at boot time won't work (correctly). So you definitely need to build the module before you reboot your system.

And even if this would work, booting the system would take endless if the module needs to be rebuilt. And if I don't have much time but quickly need to look something up in the web I need to wait for the module being built, while I only reinstall a kernel when I have time enough for waiting for the hooks being executed. Or I'm forced to reboot my system even if I don't have time for waiting for a reboot after a kernel update.

And think of cases in which someone needs to include the fglrx module into the initrd. In these cases you must rebuild the module with the hook method. Well, in these cases it could be necessary to run mkinitcpio twice. But that's a different issue.

cyberpatrol · 2010-09-09 01:10:25

Vi0L0 wrote:

Yeah, daemon is eating <2KB, thats a very very huge waste of disk space

And what? This daemon is eating <2KB, the next daemon will eat <2KB, the next will only eat <10KB, etc. Not everybody has 4GB RAM.

Vi0L0 wrote:

Actually i can say that hook is also taking disk space, but that argument was never posted by people who didn't want it.

Of course it takes disk space. But if you provide only one method it takes less disk space.

Vi0L0 wrote:

I prefer daemon because it's working always

I doubt that. See my previous reply.

Vi0L0 wrote:

You don't need to know, module will be built after kernel's update.

Wrong, I need to know that because I need to know if and when I can reboot or shut down my computer after a kernel update. And I can only reboot or shut down it after the module is rebuilt. But I don't know when the daemon is rebuilding the module and I don't know when the daemon has finished.

Vi0L0 wrote:

Daemon will also tell you about the error, and if module won't be built you will see black screen of tty .

Well, nice. I update the kernel, reboot my machine and get only a black screen? You don't want to know what I then will do with you.

Vi0L0 wrote:

Yes, hook is probably more user-friendly. But i don't care since daemon is just doing it's job. I'm also not afraid of tty, so still - i prefer daemon.

It's not only more user-friendly, it's more efficient, more secure, more resource-efficient and just works. But good luck with your daemon method as long as you don't take the hook away.

Last edited by cyberpatrol (2010-09-09 01:11:30)

Vi0L0 · 2010-09-09 01:30:35

cyberpatrol wrote:

Vi0L0 wrote:
Yeah, i checked it, there's nothing in memory related to this daemon, it's just killed after doing it's job.
But it is only killed after the module is built. If the kernel is not updated and no module has to be built it stays in memory. Or how does it know if and when the module has to be rebuilt?
Or does this daemon only check if the kernel is updated and the module needs to be rebuilt and rebuilds the module at boot time and stops itself after that? But then you have several other issues. If fglrx is in the MODULES array in /etc/rc.conf, what is most likely the case for the most users, the old module for the old kernel gets loaded before the module is rebuilt, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is started by init after /etc/rc.sysinit. So loading the module will fail and/or the module which is loaded at boot time won't work (correctly). So you definitely need to build the module before you reboot your system.

Please, please... just look at the daemon's source
While "Checking fglrx"...

xmL wrote:

it compares the modification date of the module with the installation date of the kernel package (XOR the modification date of the .config file of the kernel), and chooses whether to rebuild or to load the module.

This functionality works very very nice. First version of daemon was just checking 'modprobe fglrx' but it had to be added because: let me quote my correspondence:

me wrote:

But then i reminded something odd about stock kernel - some release of kernel
stable serie may be changed so much that previously builded module won't fit to
it.
Ie. fglrx module builded on 2.6.35.3 won't work with 2.6.35.4.
I was pretty sure this will be a problem for autofglrx. Although i decided to
test it, so i've downgraded packages kernel26 and kernel26-headers to
2.6.35.3, rebooted - X started, everything was ok, then updated mentioned
packages to 2.6.35.4, rebooted - i was welcomed by TTY's black screen.
So i logged in as root, and typed:
# modprobe fglrx
Refuse nothing, means no error, module was inserted correctly.
But it's impossible to start X.

If it needs to be rebuild - it will remove (with rmmod) older fglrx module before building, and after build it will push new one.

cyberpatrol wrote:

And even if this would work, booting the system would take endless if the module needs to be rebuilt.

Yes, building module is taking like <5 seconds for me. Is it endless time? Maybe, but not for me.

Vi0L0 · 2010-09-09 01:41:21

cyberpatrol wrote:

Vi0L0 wrote:
Yeah, daemon is eating <2KB, thats a very very huge waste of disk space
And what? This daemon is eating <2KB, the next daemon will eat <2KB, the next will only eat <10KB, etc. Not everybody has 4GB RAM.

It's not eating RAM! How many times i gotta tell you that? It is always killed!

cyberpatrol wrote:

Vi0L0 wrote:
Actually i can say that hook is also taking disk space, but that argument was never posted by people who didn't want it.
Of course it takes disk space. But if you provide only one method it takes less disk space.

<sigh>

cyberpatrol wrote:

Vi0L0 wrote:
I prefer daemon because it's working always
I doubt that.

You shouldn't

cyberpatrol wrote:

Vi0L0 wrote:
You don't need to know, module will be built after kernel's update.
Wrong, I need to know that because I need to know if and when I can reboot or shut down my computer after a kernel update. And I can only reboot or shut down it after the module is rebuilt. But I don't know when the daemon is rebuilding the module and I don't know when the daemon has finished.

You really should to test this daemon before writing false words... Daemon is telling you when he is building or when it's just loading module.

cyberpatrol wrote:

Vi0L0 wrote:
Daemon will also tell you about the error, and if module won't be built you will see black screen of tty .
Well, nice. I update the kernel, reboot my machine and get only a black screen? You don't want to know what I then will do with you.

C'mon - it's bleeding edge distribution! Things not working here all the time
Edit: Besides - it's very easy to fix it - after black screen of tty you just have to login as root, type 'catalyst_build_module' and reboot (or after loging type as root: rmmod fglrx, catalyst_build_module, modprobe fglrx and then restart your X/DM)

cyberpatrol wrote:

But good luck with your daemon method as long as you don't take the hook away.

Now you are talking!

Last edited by Vi0L0 (2010-09-09 01:50:45)

cyberpatrol · 2010-09-09 01:58:26

Vi0L0 wrote:

Yes, building module is taking like <5 seconds for me. Is it endless time? Maybe, but not for me.

For me and for computers this is endless especially if I have to wait such a long time at boot time. If I update the kernel and the module is rebuilt by the hooks then I know that updating the kernel and executing the hooks takes a while. But I only update the kernel if and when I have time enough for this.

Like I said, if I don't have much time because I need to take a train or the like and quickly have to look something up in the web before I go, I can't and don't want to wait for a module being rebuilt. And, btw., compiling is not a task that should be done at boot time. The init process is to get the system and the necessary daemons up.

And the daemon still wastes system resources if the kernel is not updated and the module doesn't need to be rebuilt, because it's only killed after the module rebuilding. And then, what if the system is not rebooted and the kernel is updated a second time? Then the daemon can't rebuild the module again, because it's not running, because it was killed after the first kernel update.

And there's another issue. There are several environment variables which set build options. They aren't set at boot time but only after logging into the system. So you most likely build the module with wrong build options at boot time. And people who change various build options on their system will definitely get the module built with wrong options. See e.g. CARCH, CHOST, CFLAG, MAKEFLAGS etc.

Vi0L0 · 2010-09-09 02:19:17

cyberpatrol wrote:

Vi0L0 wrote:
Yes, building module is taking like <5 seconds for me. Is it endless time? Maybe, but not for me.
For me and for computers this is endless especially if I have to wait such a long time at boot time. If I update the kernel and the module is rebuilt by the hooks then I know that updating the kernel and executing the hooks takes a while. But I only update the kernel if and when I have time enough for this.
Like I said, if I don't have much time because I need to take a train or the like and quickly have to look something up in the web before I go, I can't and don't want to wait for a module being rebuilt. And, btw., compiling is not a task that should be done at boot time. The init process is to get the system and the necessary daemons up.

Just a few posts ago you said that building module:

cyberpatrol wrote:

has to be accomplished only once every several weeks or months

cyberpatrol wrote:

And the daemon still wastes system resources if the kernel is not updated and the module doesn't need to be rebuilt, because it's only killed after the module rebuilding. And then, what if the system is not rebooted and the kernel is updated a second time? Then the daemon can't rebuild the module again, because it's not running, because it was killed after the first kernel update.

Now read your words again...
It doesn't need to build module for kernel that's not in use. You really need this module? What for? Or maybe you know some magic way of booting kernel without reboot?
Module for new kernel will be built after booting new kernel.

cyberpatrol wrote:

And there's another issue. There are several environment variables which set build options. They aren't set at boot time but only after logging into the system. So you most likely build the module with wrong build options at boot time. And people who change various build options on their system will definitely get the module built with wrong options. See e.g. CARCH, CHOST, CFLAG, MAKEFLAGS etc.

I dont get this... fglrx module is builded with simple:

make -C /lib/modules/${kernver}/build SUBDIRS="`pwd`" ARCH=${arch} modules

Last edited by Vi0L0 (2010-09-09 02:21:13)

cyberpatrol · 2010-09-09 02:20:13

Vi0L0 wrote:

It's not eating RAM! How many times i gotta tell you that? It is always killed!

It is! If it's killed after the module is rebuilt then it can't rebuild it a second time. If it is just started at boot time to check if the kernel is updated and the module is rebuilt, and to rebuild the module at boot time if it's necessary, and then get's killed, then you get several other issues I explained before (e.g. loading the old, not working module, not correctly set compiler options, etc.)

Vi0L0 wrote:

You shouldn't

I do! For good reasons.

Vi0L0 wrote:

You really should to test this daemon before writing false words... Daemon is telling you when he is building or when it's just loading module.

I definitely won't test this daemon due to the many reasons I told you before. How does the daemon tell me this? Will it write between the screen output of other software I've running after the kernel update? Or will it open a window in X? Or is it doing the whole stuff at boot time and writes the output between the bootlog? The latter would be the only acceptable way, but then you have all the other issues.

And, btw., if the daemon doesn't do all the stuff at boot time but runs indeed as a daemon it always has to check which software is currently running on my system and if the kernel is currently updated to know when to rebuilding the module. And this not only eats RAM but also a lot of CPU time.

Vi0L0 wrote:

C'mon - it's bleeding edge distribution! Things not working here all the time

I hadn't had any issues, yet, especially not such serious ones except when I once tried using [testing], but never with the stable repos. And bleeding edge doesn't mean instable, it means it provides the latest stable upstream versions. So Arch is bleeding edge but stable.

Vi0L0 wrote:

Edit: Besides - it's very easy to fix it - after black screen of tty you just have to login as root, type 'catalyst_build_module' and reboot (or after loging type as root: rmmod fglrx, catalyst_build_module, modprobe fglrx and then restart your X/DM)

I really don't want to first fix X and module related issues after I booted the system. The module simply has to be rebuilt directly after the kernel update and before the system is rebooted. Then you won't get such a serious issue. Again, the hook method is extremely time-saving in many respects.

Vi0L0 wrote:

Now you are talking!

I'm talking all the time.

cyberpatrol · 2010-09-09 02:44:42

Vi0L0 wrote:

Now read your words again...
It doesn't need to build module for kernel that's not in use. You really need this module? What for?

I really need this module. I need it to have fglrx working after the next reboot, to ensure a clean system start and a working system. You don't need the module for the running kernel on the hard disk, because this is already loaded into RAM. So on your hard disk you need the module for the kernel which is loaded at the next reboot.

Vi0L0 wrote:

Or maybe you know some magic way of booting kernel without reboot?

No, but when you boot the new kernel, you need the new, rebuilt module.

Vi0L0 wrote:

Module for new kernel will be built after booting new kernel.

And that's too late. And see again the several issues, above all that the old module for the old kernel is loaded before the daemon can rebuild the new module.
So if you update from kernel26 2.6.34 to kernel26 2.6.35 and use your daemon method, then during the next reboot the system first tries to load fglrx.ko and after that starts the daemon that rebuilds the module, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is executed after /etc/rc.systinit. So the modules are loaded before any daemon is started. So when the modules are loaded the system either only finds the old modules for the kernel26 2.6.34 and tries to load this, which most likely fails or doesn't work correctly later when X is started, or doesn't find the module, because the module for the new kernel26 2.6.35 doesn't, yet, exist and therefore can't load the module.

So to get the correct working module with your daemon method you must reboot the system twice. Look at the initscripts.

Vi0L0 wrote:

I dont get this... fglrx module is builded with simple:
make -C /lib/modules/${kernver}/build SUBDIRS="`pwd`" ARCH=${arch} modules

And where is ${arch} and ${kernver} set at boot time? If it's set then you are lucky. Usually these are only set after the login (/etc/profile /etc/profile.d/*, etc.). And what is `pwd` at boot time? You most likely write to /, which is not recommended.

Like I said, compiling is not a task which should be done at boot time by a daemon.

Last edited by cyberpatrol (2010-09-09 02:46:02)

Vi0L0 · 2010-09-09 02:50:56

cyberpatrol wrote:

Vi0L0 wrote:
It's not eating RAM! How many times i gotta tell you that? It is always killed!
It is! If it's killed after the module is rebuilt then it can't rebuild it a second time. If it is just started at boot time to check if the kernel is updated and the module is rebuilt, and to rebuild the module at boot time if it's necessary, and then get's killed, then you get several other issues I explained before (e.g. loading the old, not working module, not correctly set compiler options, etc.)

That's why i'm asking for feedback.

cyberpatrol wrote:

Vi0L0 wrote:
You really should to test this daemon before writing false words...
I definitely won't test this daemon due to the many reasons I told you before.

If you won't test this daemon and you didn't even looked at the source then why you are wasting my time since i wrote that i will provide both methods of auto re-compiling?

cyberpatrol wrote:

And, btw., if the daemon doesn't do all the stuff at boot time but runs indeed as a daemon it always has to check which software is currently running on my system and if the kernel is currently updated to know when to rebuilding the module. And this not only eats RAM but also a lot of CPU time.

Yes, it's eating whole <1 second of CPU time.

cyberpatrol wrote:

Vi0L0 wrote:
C'mon - it's bleeding edge distribution! Things not working here all the time
I hadn't had any issues, yet, especially not such serious ones except when I once tried using [testing], but never with the stable repos. And bleeding edge doesn't mean instable, it means it provides the latest stable upstream versions. So Arch is bleeding edge but stable.

What? Stable? xD Buuahahahaaaa, ok now tell it on the IRC, tell it to people from bugs.archlinux.org
You are seriously a lucker.
And no - this issue is not serious issue. It's easy as piece of cake.

cyberpatrol wrote:

The module simply has to be rebuilt directly after the kernel update and before the system is rebooted. Then you won't get such a serious issue. Again, the hook method is extremely time-saving in many respects.

But why you should get any issue with daemon? You really know almost nothing about this daemon.

Plus i'm sure that hook won't work when you will downgrade 2.6.35.4 -> 2.6.35.3 if kernel26-headers will be installed before kernel26 (it is happening when you are downgrading ie. from [testing] repo to [stable] repos, forcing kernel26-headers in pacman.conf is working only when you are updating) - the module will be built without errors, but after reboot you will see black screen of tty.
Daemon will work. Hook isn't really as good as you think.

Vi0L0 · 2010-09-09 02:58:56

cyberpatrol wrote:

Vi0L0 wrote:
Now read your words again...
It doesn't need to build module for kernel that's not in use. You really need this module? What for?
I really need this module. I need it to have fglrx working after the next reboot, to ensure a clean system start and a working system. You don't need the module for the running kernel on the hard disk, because this is already loaded into RAM. So on your hard disk you need the module for the kernel which is loaded at the next reboot.
Vi0L0 wrote:
Or maybe you know some magic way of booting kernel without reboot?
No, but when you boot the new kernel, you need the new, rebuilt module.
Vi0L0 wrote:
Module for new kernel will be built after booting new kernel.
And that's too late. And see again the several issues, above all that the old module for the old kernel is loaded before the daemon can rebuild the new module.
So if you update from kernel26 2.6.34 to kernel26 2.6.35 and use your daemon method, then during the next reboot the system first tries to load fglrx.ko and after that starts the daemon that rebuilds the module, because the modules are loaded by /etc/rc.sysinit and the daemons are started by /etc/rc.multi which is executed after /etc/rc.systinit. So the modules are loaded before any daemon is started. So when the modules are loaded the system either only finds the old modules for the kernel26 2.6.34 and tries to load this, which most likely fails or doesn't work correctly later when X is started, or doesn't find the module, because the module for the new kernel26 2.6.35 doesn't, yet, exist and therefore can't load the module.
So to get the correct working module with your daemon method you must reboot the system twice. Look at the initscripts.
Vi0L0 wrote:
I dont get this... fglrx module is builded with simple:
make -C /lib/modules/${kernver}/build SUBDIRS="`pwd`" ARCH=${arch} modules
And where is ${arch} and ${kernver} set at boot time? If it's set then you are lucky. Usually these are only set after the login (/etc/profile /etc/profile.d/*, etc.). And what is `pwd` at boot time? You most likely write to /, which is not recommended.
Like I said, compiling is not a task which should be done at boot time by a daemon.

That's just enough for me. I won't speak with you about daemon until you test it.

Last edited by Vi0L0 (2010-09-09 03:00:18)

msx · 2010-09-09 03:19:00

Vi0L0 wrote:

cyberpatrol wrote:
And, btw., if the daemon doesn't do all the stuff at boot time but runs indeed as a daemon it always has to check which software is currently running on my system and if the kernel is currently updated to know when to rebuilding the module. And this not only eats RAM but also a lot of CPU time.
Yes, it's eating whole <1 second of CPU time.

The only problem with this is you start adding just one second today, but tomorrow it may be just 2 more seconds (with a total of 3 extra seconds)... well, you got the point, and that's without taking in mind all the other thousand software pieces you can run at boot depending your needs. I think this should be totally inverse, trying to make system boot as swift as it can and doing all it's magic without interfering with user's work.

cyberpatrol wrote:
I hadn't had any issues, yet, especially not such serious ones except when I once tried using [testing], but never with the stable repos. And bleeding edge doesn't mean instable, it means it provides the latest stable upstream versions. So Arch is bleeding edge but stable.
What? Stable? xD Buuahahahaaaa, ok now tell it on the IRC, tell it to people from bugs.archlinux.org
You are seriously a lucker.

I'm another lucky one then
I'm using Arch since February and despite my little knowledge of GNU/Linux Arch Linux is the most stable while at the same time up-to-date but better than that easy to learn, easy to understand distro I've ever used. In all this time I've had some minor drawbacks -didn't affect system's uptime- related with updates with real problems the only time I tried to use [Testing] on my production machine (yeah, I know...)
To me, and I'm just one more -n00b- guy using Arch, this distro is rock-solid, more than stable and yet up-to-date, easy to learn and easy to understand beating everything else out there but many, many bodies.

Last edited by msx (2010-09-09 03:19:51)

cyberpatrol · 2010-09-09 03:44:52

Vi0L0 wrote:

That's why i'm asking for feedback.

And you asked me in a private e-mail what I think about it and asked me to comment.
So I did what you asked for.

Vi0L0 wrote:

If you won't test this daemon and you didn't even looked at the source then why you are wasting my time since i wrote that i will provide both methods of auto re-compiling?

Why should I test it and look at the source code? I told you about two possible methods how the daemon can work. Both have enough disadvantages, and I explained you both. If I'm wrong with both and the daemon is working in a different way, why don't you explain how it's working? That's usually called documentation.

But there are several fundamental issues - let's call them policy issues - which speak against the daemon method regardless of how the daemon is working, because it goes against several Linux standards. So there's no need to test the daemon and to look at the source code.

Btw., if you answer me, I answer you. So I don't waste your time, you do it yourself.

Vi0L0 wrote:

Yes, it's eating whole <1 second of CPU time.

And it's doing it all the time it is running. CPU time which is wasted and can't be used by other software, so computer slowdown.
If it's only started once at boot time and does it's job at boot time and is then killed, then the CPU time doesn't matter, but the time it needs to rebuild the module.

Vi0L0 wrote:

What? Stable? xD Buuahahahaaaa, ok now tell it on the IRC, tell it to people from bugs.archlinux.org
You are seriously a lucker.

No, I'm not a lucker. And I know Flyspray. And you won't find a software which doesn't have any bugs. But that hasn't anything to do with stable or unstable. Most of the people who have probably unstable systems are the [testing] users or users with esoteric hardware.

Vi0L0 wrote:

And no - this issue is not serious issue. It's easy as piece of cake.

If I get only a black screen instead of a login screen after a system start, this is a serious issue.

Vi0L0 wrote:

But why you should get any issue with daemon? You really know almost nothing about this daemon.

I know general principles of a daemon, I know Arch's initsystem - and not only Arch's -, I know when modules are loaded and daemons are started, and I know when environment variables are set. And all that together tells me, that the daemon method can't work. And if it works then you are lucky.

If I was wrong with my explanations and assumptions you could have explained it and corrected me instead of just telling me to look at the source code.

Like I said, the source code is uninteresting in this case. Look at the initsystem and you'll see that it can't work. You won't, of course, see these issues if you are just updating from kernel26 2.6.34.3 to kernel26 2.6.34.4, because the module usually doesn't need to be rebuilt after such a minor kernel upade and works with the old and the new kernel. But you will see it after major updates from kernel26 2.6.34.4 to kernel26 2.6.35.1.

And if the daemon doesn't do all it's jobs at boot time and needs to run all the time in the background you have again the waste of system resources (RAM and CPU), the problem that you don't know when the module is rebuilt etc.

Vi0L0 wrote:

Plus i'm sure that hook won't work when you will downgrade 2.6.35.4 -> 2.6.35.3 if kernel26-headers will be installed before kernel26 (it is happening when you are downgrading ie. from [testing] repo to [stable] repos, forcing kernel26-headers in pacman.conf is working only when you are updating)

I haven't tried downgrading the kernel from [testing] to [core], yet. But I'm pretty sure, that the hook will work in this case, too, because kernel26-headers are downgraded, too, in this case, and I'm pretty sure that kernel26-headers are downgraded first if it's in SyncFirst in /etc/pacman.conf. Otherwise it's time to either fixing the hook or to filing a bug report about pacman and SyncFirst.
I'll test it some day.

Vi0L0 wrote:

- the module will be built without errors, but after reboot you will see black screen of tty.

I guess that the module will either be built correctly or not at all. But I'll test it.

Btw., people who are using [testing] should know what they are doing. And people who are downgrading from [testing] to [core] should also know what they are doing. So such people should be able to rebuild the module manually by running catalyst_build_module.

Vi0L0 wrote:

Daemon will work. Hook isn't really as good as you think.

Like I said, I doubt that daemon will work. And hook is really as good as I think.

cyberpatrol · 2010-09-09 03:48:47

Vi0L0 wrote:

That's just enough for me. I won't speak with you about daemon until you test it.

You could either explain how the daemon is working exactly or read my explanations and come to the decision, that I'm most likely right.
I repeat myself, but there are only two ways, I can think of, how the daemon is working. I explained them both. You could correct me if I was wrong.

Vi0L0 · 2010-09-09 04:22:03

@cyberpatrol:
ok, so i'm sorry
I actually don't have time right now to write a documentation, nor to write long posts.
So i tried to convice you to test it or at least look at the source - its all there . Sorry again.

yes, the env vars are seted after starting daemons, but to build fglrx module you actually need just a few of them, they are seted by catalyst_build_module (like CARCH provided by `uname -m`) which is used by daemon.

Also:
make -C /lib/modules/${kernver}/build SUBDIRS="`pwd`" ARCH=${arch} modules
is just a scratch from catalyst_build_module.

There's no magic in daemon, it works as it should, i have tested it on many many kernels, and with many updates/downgrades of kernels. I'm not just the lucky one - it will work for anybody.

I will answer to you later, now please forgive me - i need to sleep, goodnight

Btw: by 'black screen of tty' i mean login screen

subzero316 · 2010-09-09 05:02:00

Vi0L0 wrote:

subzero316 wrote:
Any one checked on Firefox H/W acceleration? http://hacks.mozilla.org/2010/09/hardware-acceleration/
Why do you think it would work? Afaik linux isn't supporting Direct2D.

Because I actually read the Blog.
They claim composting is done by OpenGL which uses GPU.

Also Try this,
http://demos.hacks.mozilla.org/openweb/HWACCEL/

EDIT: http://demos.hacks.mozilla.org/openweb/CSSMAKESUSICK/

Last edited by subzero316 (2010-09-09 05:49:26)

Arch Linux

#2326 2010-09-08 23:12:13

Re: The AMD/ATI Bar & Grill

#2327 2010-09-08 23:49:47

Re: The AMD/ATI Bar & Grill

#2328 2010-09-08 23:56:28

Re: The AMD/ATI Bar & Grill

#2329 2010-09-09 00:09:46

Re: The AMD/ATI Bar & Grill

#2330 2010-09-09 00:18:36

Re: The AMD/ATI Bar & Grill

#2331 2010-09-09 00:20:04

Re: The AMD/ATI Bar & Grill

#2332 2010-09-09 00:25:09

Re: The AMD/ATI Bar & Grill

#2333 2010-09-09 00:33:29

Re: The AMD/ATI Bar & Grill

#2334 2010-09-09 00:34:33

Re: The AMD/ATI Bar & Grill

#2335 2010-09-09 00:52:40

Re: The AMD/ATI Bar & Grill

#2336 2010-09-09 00:54:46

Re: The AMD/ATI Bar & Grill

#2337 2010-09-09 01:10:25

Re: The AMD/ATI Bar & Grill

#2338 2010-09-09 01:30:35

Re: The AMD/ATI Bar & Grill

#2339 2010-09-09 01:41:21

Re: The AMD/ATI Bar & Grill

#2340 2010-09-09 01:58:26

Re: The AMD/ATI Bar & Grill

#2341 2010-09-09 02:19:17

Re: The AMD/ATI Bar & Grill

#2342 2010-09-09 02:20:13

Re: The AMD/ATI Bar & Grill

#2343 2010-09-09 02:44:42

Re: The AMD/ATI Bar & Grill

#2344 2010-09-09 02:50:56

Re: The AMD/ATI Bar & Grill

#2345 2010-09-09 02:58:56

Re: The AMD/ATI Bar & Grill

#2346 2010-09-09 03:19:00

Re: The AMD/ATI Bar & Grill

#2347 2010-09-09 03:44:52

Re: The AMD/ATI Bar & Grill

#2348 2010-09-09 03:48:47

Re: The AMD/ATI Bar & Grill

#2349 2010-09-09 04:22:03

Re: The AMD/ATI Bar & Grill

#2350 2010-09-09 05:02:00

Re: The AMD/ATI Bar & Grill

Board footer