Lorenzo Milesi posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Jun 2005 09:36:36 +0200:
>> You don't mention what kernel you are running, nor anything else of >> that nature that might be relevant (mobo brand and model number, etc). If > > Yes, sorry. I'm running 2.6.12, but it has always happened (since I > turned to gentoo), also with 2.6.10 and 2.6.11. > My pc is an Asus A2K, with nvidia board. > >> Alternatively, try adjusting the verbosity of your ACPI log, and/or >> telling the ACPI event notification chain to ignore those events and not >> trigger the script call for them. > > err... how do I do the last thing? :) I was hoping to avoid having to look that up, as I'd seen it when browsing my system, but had forgotten the specifics. =8^) However, since you asked, and in the spirit of "teach a man to fish and he eats for a lifetime..." <g> here's how I go about finding such information, here. Note that I'm writing the below with the wider audience in mind, not assuming that much knowledge of acpi or init. However, the modifications mentioned will of course require some knowledge of shell scripting, tho folks can look around without modifying to no harm, without knowing much shell scripting, if they just want to learn a bit more about their system. 1) I know that I start an acpi service of some sort at boot, which means there's a symlink to the script in one of the /etc/runlevels/ subdirs. I'm not particularly concerned with that at this point, tho, only with the fact that all those symlinks point to the actual scripts in /etc/init.d/, and many of those scripts have a configuration file in /etc/conf.d/. 2) Therefore, I take a quick look in /etc/conf.d/ for a config file that has something to do with acpi, to see if there's anything it might be helpful to configure there. No such file, which means the init.d script doesn't anticipate any system level configuration being necessary. 3) On to /etc/init.d/ to take a look at the init script there. PAYDIRT! (Of course, since I already know such a script exist as it's started at each boot, and I remember adding it to some runlevel at some time in the dim past.) acpid. (A side note here. I do much of my sysconfig work using midnight commander, aka mc, the two-pane file manager, with included file viewer and file editor. Some reading will nodoubt find it very helpful, if they've not discovered it already. emerge mc, then invoke it with the mc command. I have my system EDITOR var set to mcedit as well, use it for my etc-update editor, and have aliases e and v set to mcedit and mcview, respectively. It works equally well in a virtual console outside X, and in xterm/gterm/konsole/etc.) 4) Opening the acpid initscript in my favorite editor (mcedit, naturally <g>), I can see it's a fairly simple thing. The start command starts /usr/sbin/acpid, with what appears to be a config file, /etc/acpi/events. (At this point, in many cases, I'd do a quick man <command> to see what other commandline switches were available, and what the ones that were used actually did. However, things look pretty straightforward at this point, so I'll skip that for now. You are of course welcome to take the detour and learn more about how your system works if desired, as I likely would if I were actually doing this instead of just explaining it.) That parameter tells us where we go next, /etc/acpi/. 5) Switching to /etc/acpi/ to take a look at what else is there, I see that events/ is actually a subdir, and there's a default.sh shellscript in the main dir as well. Now, knowing a bit about daemon and initscript implementation, the fact that /etc/acpi/events is a subdir not a file immediately tells me that anything executable, probably scripts, located there, will be executed for each acpi event. Normally, they'd be executed in sorted order (ASCII sorted here in the US, don't know how i18n/l10n might affect that), so you can call your script 001name or something similar if you want it executed first, zzzname if you want it executed last, or just name if you just want it executed and it doesn't matter where in the sequence it gets called. There'll normally be at least one "system" script in such a dir, but it's a dir and not a single file precisely so it's easy for you (or any package that needs to) to create another script to be called for each event. Note that there could be many events, only a few that might interest the creator of any specific script, so most scripts will probably implement some sort of filtering and simply exit if the event isn't one they are interested in. If it is, they'll do whatever they do that makes sense for that event. 6) So, into the events subdir we go. Perhaps your system has something else there, but here, sure enough, there's only the single "default" file. Opening it reveals a pretty simple commented config file. There are several commented example actions, but only two uncommented lines, an event filter as mentioned above, and an action, something to run if the filter matches. In this case, it matches all events, with the action calling the ../devault.sh script I mentioned earlier, feeding it the kernel event message, %e, as explained in the comments. So, the next place to look is now obvious. 7) Backing out of the events subdir to /etc/acpi/, we now load default.sh to see what it's doing. It's pretty simple as well. There's a bit of filtering to separate the group and action portions of the event as passed into separate vars, then a case statement branching on event group, with group button getting its own case statement, and all other groups simply logging an "undefined" message. The button group case statement branches on action, with the power action doing what might be expected, and all other button/* events again getting an "undefined" log action. That's it. It's a bit obvious that you have something else defined, causing additional log entries, as the ones you posted don't match the above. However, tracing them from /etc/acpi/events should be fairly trivial. You should be able to make mods as necessary after that. 8) Completing our little tour, lets take a look at the man pages we skipped earlier. man acpi<tab> lists two manpages, acpid, as expected, and an acpi_listen. 9) man acpid lists the expected, confirming most of the above suppositions, but there's something else of interest as well, the log file option. If nothing else, you can set this to /dev/null or the like, and not worry about logging. 10) acpi_listen appears to be what's causing the acpi_listen output you mentioned. It's not clear to me whether you were running that, or whether something else did automatically. However, if it's run automatically, using the above general techniques to trace things down, it should be fairly easy to find what's calling it and why, and modify things accordingly, if desired. That pretty much covers things. Using the above, you should be able to trace further as necessary. Note that some laptops in particular are likely to use ACPI for various powersaving functions. They should have hook scripts placed in /etc/acpi/events/ that can be modified as well. Just be aware as you are doing so that going wild here could seriously screw up that power saving, so as usual when messing with system configs, a bit of reasonable caution is warranted. Was that of any help? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
