# ipw3945+nVidia+dpms=freeze [SOLVED]

## VinzC

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.

----------

## beatryder

 *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 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:

```

#!/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

----------

## VinzC

 *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:

```
event=button[ /]lid

action=/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
```

```
# 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'
```

```
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?

----------

## beatryder

 *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:
> ...

 

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.

----------

## VinzC

Thanks for the link. The last message dates June, 30th... No more news since then?

----------

## beatryder

 *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

----------

## VinzC

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...

----------

## beatryder

 *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.

----------

## VinzC

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.

----------

