| View previous topic :: View next topic |
| Author |
Message |
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
 Posted: Sun Nov 19, 2006 10:42 pm Post subject: ipw3945+nVidia+dpms=freeze [SOLVED] |
 |
|
Hi.
I have a Dell Inspiron 9400. I've been experiencing freezes with ipw3945 and nVidia drivers when I run vbetool dpms off under X. If I switch to a text console (tty1-tty6) before I run vbetool dpms off my laptop doesn't freeze. I have never been able to solve this issue. Till now I've been using vbetool to blank the screen when the lid closes. I had an Inspiron 6000 before and I created an acpi event to blank the screen with vbetool. Maybe there's a better way?
Since I've installed Beryl 0.1.2 and nvidia drivers 9742 (unmasked) the screen sometimes happens to be impossible to unlock. The screen blanks and the screen saver that was active seems to display its background but the unlock dialog doesn't appear. I have to SSH into my laptop and reboot it remotely.
I'm almost sure both issues are related. These are the most annoying ones but I never could solve them. Has anybody an idea how to fix it?
Many thanks in advance for any hint/suggestion.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Last edited by VinzC on Fri Jan 05, 2007 9:53 pm; edited 1 time in total |
|
| Back to top |
|
 |
beatryder
Veteran
Joined: 08 Apr 2005
Posts: 1138
|
| Posted: Mon Nov 20, 2006 6:31 am Post subject: Re: ipw3945+nVidia+dpms=freeze |
|
|
| VinzC wrote: | Hi.
I have a Dell Inspiron 9400. I've been experiencing freezes with ipw3945 and nVidia drivers when I run vbetool dpms off under X. If I switch to a text console (tty1-tty6) before I run vbetool dpms off my laptop doesn't freeze. I have never been able to solve this issue. Till now I've been using vbetool to blank the screen when the lid closes. I had an Inspiron 6000 before and I created an acpi event to blank the screen with vbetool. Maybe there's a better way?
Since I've installed Beryl 0.1.2 and nvidia drivers 9742 (unmasked) the screen sometimes happens to be impossible to unlock. The screen blanks and the screen saver that was active seems to display its background but the unlock dialog doesn't appear. I have to SSH into my laptop and reboot it remotely.
I'm almost sure both issues are related. These are the most annoying ones but I never could solve them. Has anybody an idea how to fix it?
Many thanks in advance for any hint/suggestion. |
I would start by using the latest non-beta drivers. I have a similar configuration to you, and I found the latest beta drivers to be very unstable.
This is the script i use for screen blanking:
| Code: |
#!/bin/bash
state=`cat /proc/acpi/button/lid/LID/state | gawk '{print $2}'`;
logger "lid is ${state}"
case "$state" in
closed)
if test -f /tmp/oldvt; then
/bin/true
else
fgconsole > /tmp/oldvt
fi
chvt 12
/usr/sbin/vbetool dpms off &
/etc/acpi/lockkde.sh
sleep 2
;;
*)
/usr/sbin/vbetool dpms on
chvt `cat /tmp/oldvt`
rm /tmp/oldvt
;;
esac |
I hope that helps
_________________
Dont make it idiot proof, make it work.
Neucode.org
<suppressed key> |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Nov 20, 2006 10:08 am Post subject: Re: ipw3945+nVidia+dpms=freeze |
|
|
| beatryder wrote: | | I would start by using the latest non-beta drivers. I have a similar configuration to you, and I found the latest beta drivers to be very unstable. |
Thanks. However I experienced these problems with stable and unstable versions of nvidia drivers. But I start to wonder if the issue couldn't be caused by the program itself, vbetool, since it uses VESA API to blank the screen. It works with consoles because they are framebuffer consoles, i.e. they use VESA graphics modes. X in turn doesn't use VESA but some native graphics modes. Hence I think mixing VESA calls are in fact messing up with the graphics chip, nvidia.
I've taken a look at Ubuntu acpi scripts and they handle ACPI events (especially the lid close event) in a completely different manner. Here's an example:
| /etc/acpi/events/lidbtn: | event=button[ /]lid
action=/etc/acpi/lid.sh |
| /etc/acpi/lid.sh: | #!/bin/bash
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/policy-funcs
. /etc/default/acpi-support
[ -x /etc/acpi/local/lid.sh.pre ] && /etc/acpi/local/lid.sh.pre
if [ `CheckPolicy` == 0 ]; then exit; fi
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
. /usr/share/acpi-support/screenblank
fi
done
else
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
grep -q off-line /proc/acpi/ac_adapter/*/state
if [ $? = 1 ]
then
if pidof xscreensaver > /dev/null; then
su $user -c "xscreensaver-command -unthrottle"
fi
fi
if [ x$RADEON_LIGHT = xtrue ]; then
[ -x /usr/sbin/radeontool ] && radeontool light on
fi
if [ `pidof xscreensaver` ]; then
su $user -c "xscreensaver-command -deactivate"
fi
su $user -c "xset dpms force on"
fi
done
fi
[ -x /etc/acpi/local/lid.sh.post ] && /etc/acpi/local/lid.sh.post |
| /usr/share/acpi-support/power-funcs: | # a micro library of helper functions for the power scripts
umask 022;
PATH="$PATH:/usr/bin/X11"
POWERSTATE="/var/lib/acpi-support/powerstate"
getXuser() {
user=`finger| grep -m1 ":$displaynum " | awk '{print $1}'`
if [ x"$user" = x"" ]; then
user=`finger| grep -m1 ":$displaynum" | awk '{print $1}'`
fi
if [ x"$user" != x"" ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=""
fi
}
getXconsole() {
console=`fgconsole`;
displaynum=`ps ax | grep -e 'X .* vt'$console | grep -v grep | sed -re 's!.*/X .*:([0-9]+).*!\1!'`
if [ x"$displaynum" != x"" ]; then
export DISPLAY=":$displaynum"
getXuser
fi
}
getState() {
/usr/bin/on_ac_power;
if [ "$?" -eq 0 ]; then
STATE="AC";
elif [ "$?" -eq 1 ]; then
STATE="BATTERY";
fi
}
#check our state has actually changed
checkStateChanged() {
# do we have our state stashed?
if [ -f "$POWERSTATE" ]; then
OLDSTATE=$(<$POWERSTATE)
if [ "$STATE" = "$OLDSTATE" ]; then
exit 0
else
#stash the new state
echo "$STATE" > $POWERSTATE
fi
else
#we need to stash the new state
echo "$STATE" > $POWERSTATE
fi
}
LAPTOP_MODE='/usr/sbin/laptop_mode'
HDPARM='/sbin/hdparm -q'
LIDSTATE='/var/lib/acpi-support/lidstate' |
| /usr/share/acpi-support/policy-funcs: | CheckPolicy() {
if pidof gnome-power-manager kpowersave > /dev/null ||
(pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop kded kded loadedModules | grep -q klaptopdaemon) ; then
echo 0;
else
echo 1;
fi
} |
That looks quite interesting though. Regardless the fact that it seems (very) complex, Gentoo, IMHO, needs some more functionality as far as ACPI is concerned for I think everything - until now - needs to be done by hand, am I right?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
beatryder
Veteran
Joined: 08 Apr 2005
Posts: 1138
|
| Posted: Mon Nov 20, 2006 8:09 pm Post subject: Re: ipw3945+nVidia+dpms=freeze |
|
|
| VinzC wrote: | | beatryder wrote: | | I would start by using the latest non-beta drivers. I have a similar configuration to you, and I found the latest beta drivers to be very unstable. |
Thanks. However I experienced these problems with stable and unstable versions of nvidia drivers. But I start to wonder if the issue couldn't be caused by the program itself, vbetool, since it uses VESA API to blank the screen. It works with consoles because they are framebuffer consoles, i.e. they use VESA graphics modes. X in turn doesn't use VESA but some native graphics modes. Hence I think mixing VESA calls are in fact messing up with the graphics chip, nvidia.
I've taken a look at Ubuntu acpi scripts and they handle ACPI events (especially the lid close event) in a completely different manner. Here's an example:
| /etc/acpi/events/lidbtn: | event=button[ /]lid
action=/etc/acpi/lid.sh |
| /etc/acpi/lid.sh: | #!/bin/bash
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/policy-funcs
. /etc/default/acpi-support
[ -x /etc/acpi/local/lid.sh.pre ] && /etc/acpi/local/lid.sh.pre
if [ `CheckPolicy` == 0 ]; then exit; fi
grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
. /usr/share/acpi-support/screenblank
fi
done
else
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
grep -q off-line /proc/acpi/ac_adapter/*/state
if [ $? = 1 ]
then
if pidof xscreensaver > /dev/null; then
su $user -c "xscreensaver-command -unthrottle"
fi
fi
if [ x$RADEON_LIGHT = xtrue ]; then
[ -x /usr/sbin/radeontool ] && radeontool light on
fi
if [ `pidof xscreensaver` ]; then
su $user -c "xscreensaver-command -deactivate"
fi
su $user -c "xset dpms force on"
fi
done
fi
[ -x /etc/acpi/local/lid.sh.post ] && /etc/acpi/local/lid.sh.post |
| /usr/share/acpi-support/power-funcs: | # a micro library of helper functions for the power scripts
umask 022;
PATH="$PATH:/usr/bin/X11"
POWERSTATE="/var/lib/acpi-support/powerstate"
getXuser() {
user=`finger| grep -m1 ":$displaynum " | awk '{print $1}'`
if [ x"$user" = x"" ]; then
user=`finger| grep -m1 ":$displaynum" | awk '{print $1}'`
fi
if [ x"$user" != x"" ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=""
fi
}
getXconsole() {
console=`fgconsole`;
displaynum=`ps ax | grep -e 'X .* vt'$console | grep -v grep | sed -re 's!.*/X .*:([0-9]+).*!\1!'`
if [ x"$displaynum" != x"" ]; then
export DISPLAY=":$displaynum"
getXuser
fi
}
getState() {
/usr/bin/on_ac_power;
if [ "$?" -eq 0 ]; then
STATE="AC";
elif [ "$?" -eq 1 ]; then
STATE="BATTERY";
fi
}
#check our state has actually changed
checkStateChanged() {
# do we have our state stashed?
if [ -f "$POWERSTATE" ]; then
OLDSTATE=$(<$POWERSTATE)
if [ "$STATE" = "$OLDSTATE" ]; then
exit 0
else
#stash the new state
echo "$STATE" > $POWERSTATE
fi
else
#we need to stash the new state
echo "$STATE" > $POWERSTATE
fi
}
LAPTOP_MODE='/usr/sbin/laptop_mode'
HDPARM='/sbin/hdparm -q'
LIDSTATE='/var/lib/acpi-support/lidstate' |
| /usr/share/acpi-support/policy-funcs: | CheckPolicy() {
if pidof gnome-power-manager kpowersave > /dev/null ||
(pidof dcopserver > /dev/null && test -x /usr/bin/dcop && /usr/bin/dcop kded kded loadedModules | grep -q klaptopdaemon) ; then
echo 0;
else
echo 1;
fi
} |
That looks quite interesting though. Regardless the fact that it seems (very) complex, Gentoo, IMHO, needs some more functionality as far as ACPI is concerned for I think everything - until now - needs to be done by hand, am I right? |
You might want to look at this https://bugs.gentoo.org/show_bug.cgi?id=99446
Looks as though someone has packaged the ubuntu ACPI scripts for gentoo.
_________________
Dont make it idiot proof, make it work.
Neucode.org
<suppressed key> |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Nov 20, 2006 8:50 pm Post subject: |
|
|
Thanks for the link. The last message dates June, 30th... No more news since then?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
beatryder
Veteran
Joined: 08 Apr 2005
Posts: 1138
|
| Posted: Tue Nov 21, 2006 7:06 am Post subject: |
|
|
| VinzC wrote: | | Thanks for the link. The last message dates June, 30th... No more news since then? |
Well, I am not exactly sure how well they work. I had installed them, but they did not seem to work, turns out I did not noticed that there was an init script :p
_________________
Dont make it idiot proof, make it work.
Neucode.org
<suppressed key> |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Tue Nov 21, 2006 10:12 am Post subject: |
|
|
I don't know if it matters much but the only one big difference between Gentoo and Ubuntu is that ACPI events are noted button[ /]lid in Ubuntu but button[ /]lid.* in Gentoo. And under Gentoo such a notation used to work on my current laptop but now it doesn't. Under Ubuntu it works. Unless it's the default event script that's no longer supported or no longer works. So I was wondering...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
beatryder
Veteran
Joined: 08 Apr 2005
Posts: 1138
|
| Posted: Tue Nov 21, 2006 5:12 pm Post subject: |
|
|
| VinzC wrote: | | I don't know if it matters much but the only one big difference between Gentoo and Ubuntu is that ACPI events are noted button[ /]lid in Ubuntu but button[ /]lid.* in Gentoo. And under Gentoo such a notation used to work on my current laptop but now it doesn't. Under Ubuntu it works. Unless it's the default event script that's no longer supported or no longer works. So I was wondering... |
Use what ever works my friend.
_________________
Dont make it idiot proof, make it work.
Neucode.org
<suppressed key> |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Fri Jan 05, 2007 9:57 pm Post subject: |
|
|
Marking thread SOLVED for having stopped using vbetool. Ubuntu init script works - at least till now. I've currently only implemented the power button script but I guess the lid close/open script will also work although it needs a little rewriting for Gentoo.
Basically Gentoo implementation doesn't work because of how events are trapped in acpi scripts. As I said above you should replace button[ /]lid.* with button[ /]lid, for example, and so it goes with the power button event script. I guess it's the same with other events. I'll post as soon as I get good results but for now I'm involved in something else, which requires all my attention.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
|
Kernel & Hardware
