Howto : ASUS M2NPV-VM mit Kanotix/easyVDR

BooStar · 21. Juni 2007

hi,
ich nochmal,
also mein adapter scheint zu die pins 1:1 durchzugeben...
masse liegt an pin 5...
also scheint das zu stimmen...
trotzdem funkt lirc noch nicht... ich werde mal weiter basteln..

__
boo

prahn · 22. Juni 2007

Also die Lösung der Lüftersteuerung hab ich jetzt:
Nur die Lüfter-Anschlüsse 'CHA_FAN1' und 'CPU_FAN' sind geregelt.
Die anderen beiden laufen konstant mit einer Geschwindigkeit!

Jetzt ist die Kiste leise!

Gruß,
prahn

Dr. Seltsam · 22. Juni 2007

findet man übrigens nur auf http://support.asus.com in den FAQs (nicht bei asus.de):

Zitat

Question
M2NVP-VM comes with four fan connectors onboard (CPU_Fan, Chassis_Fan1, Chassis_Fan2, and Power_Fan). Out of these, which fans connectors are capable of supporting Q'Fan functionality?

Answer
M2NVP-VM is capable of supporting Q'Fan through both CPU_Fan and Chassis_Fan1 connector on this motherboard.
Both Chassis_Fan2 and Power_Fan connector are not capable of supporting Q'Fan.

Das deutsche pdf-Handbuch nennt fälschlicherweise auch Chassis Fan2 als unterstützt.

sparkie · 23. Juni 2007

Zitat

findet man übrigens nur auf http://support.asus.com in den FAQs (nicht bei asus.de):

und hier

BooStar · 23. Juni 2007

aber ich hab den cpu-luefter an cpu_fan angeschlossen...

Dr. Seltsam · 23. Juni 2007

Zitat

Original von BooStar
der lüfter rennt konstant auf 2300upm

mit welcher Drehzahl läuft er denn, wenn Du ihn an Chassis_Fan2 anschließt?

Vielleicht ist 2300 ja schon gedrosselt, und Du brauchst einfach einen langsamer drehenden Lüfter. Merkst Du denn, wie beim Anschalten der Lüfter erst schneller läuft, und dann gedrosselt wird?

BooStar · 24. Juni 2007

hallo

Zitat

Merkst Du denn, wie beim Anschalten der Lüfter erst schneller läuft, und dann gedrosselt wird?

ja du hast recht.. das ist zu merken, ich dachte nur, da waer vllt noch mehr drin...

Zitat

mit welcher Drehzahl läuft er denn, wenn Du ihn an Chassis_Fan2 anschließt?

da kann ich den cpu-luefter leider nicht anschließen, da der luefter einen 4-pin anschluss hat, und alle anderen fan anschluesse einen 3-pin anschluss haben.

Zitat

Du brauchst einfach einen langsamer drehenden Lüfter

richtig.. sowohl fuer die cpu, als auch fuer mein netzteil, das problem daran ist, ich weiss weder wieviel luftstrom (m³ / h ) die cpu mindestens braucht, noch we0iss ich das vom netzteil.

kennt sich da vllt jemand aus und kann da was zu sagen?

__
boo

obelix · 2. Juli 2007

Hi,
ich bekomme wol nicht ans drehen. Die Netzwerkkarte lässt sich per /usr/sbin/ethtool -s eth1 wol g (eth0 ist Firewire) konfigurieren. Ich habe das wake_on_lan Script übernommen aber er wacht nicht auf. Auf diesem Rechner ist Debian 4.0 (Etch) installiert.

Ich habe etherwake und wakeonlan probiert. Beides ohne Erfolg.

Gruß

Obelix

Wicky · 2. Juli 2007

Hallo obelix,

dazu fallen mir folgende Dinge ein:

1. Du verwendest eine Bios Version, die kein WOL unterstützt (seeehr unwahrscheinlich)
-> Was gibt "ethtool eth1" aus?

2. Die von dir verwendete etherwake Syntax ist falsch (hier habe ich bei meinen WOL Versuchen viele Fehler gemacht, bis es endlich lief)

3. Der Befehl "/usr/sbin/ethtool -s eth1 wol g " ist nicht der lezte Befehl, der eth1 konfiguriert !!
-> Das wäre zumindest denkbar.
Was ist "wake_on_lan" für ein Skript?

4. Debugging:
Was gibt denn "cat /proc/acpi/wakeup"
a) nach einem "/usr/sbin/ethtool -s eth1 wol g" und
b) nach einem reboot aus?

Gruß
Wicky

obelix · 3. Juli 2007

Hallo Wicky,

Zu 1: BIOS ist OK. ethtool eth1 nach Neustart:

Code

Settings for eth1:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Alles anzeigen

Nach absetzen von "/usr/sbin/ethtool -s eth1 wol g" sieht das ganze so aus:

Code

Settings for eth1:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Link detected: yes

Alles anzeigen

Zu 2: etherwake -i eth0 -b MAC-Adresse -D. Als Debug Ausgabe bekomme ich ein "
Sendto worked ! 116." zurück.

Zu 3: Ich habe in /etc/init.d/reboot die Option -i entfernt. In /etc/init.d/halt habe ich den Eintrag NETDOWN=no gesetzt (war auf yes). Das "wake_on_lan" Script wurde in diesem Thread gepostet um "/usr/sbin/ethtool -s eth1 wol g" beim Starten und / oder Beenden des Systems auszuführen.

Zitat

#! /bin/sh
#
# Ensures that the Wake On Lan works
#

#PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

set -e

case "$1" in
stop|start|restart|force-reload|reload)
echo -n "Turn on: Wake on Magic Packet"
/usr/sbin/ethtool -s eth1 wol g
echo
;;
*)
# N=/etc/init.d/hwtools
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac

exit 0

Alles anzeigen

Zu 4: Dort könnte durchaus der "Hund" begraben liegen

Ausgabe a und b:

Code

cat /proc/acpi/wakeup
Device  Sleep state     Status
HUB0       5            disabled
XVRA       5            disabled
XVRB       5            disabled
XVRC       5            disabled
USB0       4            disabled
USB2       4            disabled
AZAD       5            disabled
MMAC       5            disabled
MMCI       5            disabled
UAR1       5            disabled
UAR2       5            disabled
PS2K       4            disabled

Alles anzeigen

Ich habe gelesen, dass die Netzwerkkarte PCI0 sein soll aber diese gibt es, aus welchen Gründen auch immer, bei mir nicht.

Gruß
Obelix

obelix · 3. Juli 2007

Ergänzung: Die LEDs der Netzwerkkarte leuchten / blinken wenn der Rechner heruntergefahren ist.

Gruß

Obelix

obelix · 3. Juli 2007

hmm, seltsam. Wenn ich den Rechner mit /etc/init.d/halt stop herunterfahre, funktioniert wol.

berndl · 3. Juli 2007

Zitat

Original von obelix
hmm, seltsam. Wenn ich den Rechner mit /etc/init.d/halt stop herunterfahre, funktioniert wol.

N'abend,
war da nicht was mit irgendeinem parameter beim shutdown der Kiste? In irgendeinem shutdown skript? Irgendein parameter -i?
Such mal hier im Forum danach, mir faellt's gerade nicht ein wo ich das gelesen habe...

Gruss,
- berndl

Wicky · 3. Juli 2007

Hallo obelix,

Zitat

Original von obelix
hmm, seltsam. Wenn ich den Rechner mit /etc/init.d/halt stop herunterfahre, funktioniert wol.

Sehr schön. Damit ist die Sache doch schon etwas eingegrenzt.

D.h. das Problem liegt in der Menge der Unterschiede zwischen

"/etc/init.d/halt stop" und "/sbin/poweroff"

Hierbei könnte ein Studium des Skriptes "/etc/init.d/halt" aufschlussreich sein, da das Skript sehr wahrscheinlich das Binary "halt" aufruft. Da sich das Binary "halt" nur unwesentlich vom Binary "poweroff" unterscheiden dürfte, verrät das Skript eventuell schon die Unterschiede zwischen "/etc/init.d/halt stop" und "/sbin/poweroff"

Falls nicht, so müsste man sämtliche init Skripte durchgehen, die beim Shutdown ausgeführt werden... aber ich denke das dies nicht notwendig sein wird.

-> Poste doch einmal /etc/init.d/halt

Nochwas:
Du hast gesehen, dass WOL nach einem reboot deaktiviert war, gell? (-> Wake-on: d=disabled)
Manche Netzwerktreiber (z.B. 3com...) machen das so, ohne dass Skripte hierfür herumwerkeln müssten. Ich glaube jedoch nicht, dass es bei forcedeth so ist.

Das kann man aber leicht herausbekommen:

1. /usr/sbin/ethtool -s eth1 wol g --->>> WOL aktivieren
2. /etc/init.d/halt stop ---->>> Rechner ausschalten
3. WOL ---->>>> Rechner per WOL aufwecken
4. ethtool eth1 ----->>> Nachschauen, ob WOL immernoch aktiviert ist

Und noch noch was:
Änderungen im reboot Skript helfen dir bei der Problematik nicht weiter ;)... du willst die Kiste doch ausschalten...

Gruß
Wicky

obelix · 3. Juli 2007

Hallo Wicky,

hier der Inhalt der /etc/init.d/halt:

Code

#! /bin/sh
### BEGIN INIT INFO
# Provides:          halt
# Required-Start:
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start:
# Default-Stop:      0
# Short-Description: Execute the halt command.
# Description:
### END INIT INFO


NETDOWN=no


PATH=/sbin:/usr/sbin:/bin:/usr/bin
[ -f /etc/default/halt ] && . /etc/default/halt


. /lib/lsb/init-functions


do_stop () {
        if [ "$INIT_HALT" = "" ]
        then
                case "$HALT" in
                  [Pp]*)
                        INIT_HALT=POWEROFF
                        ;;
                  [Hh]*)
                        INIT_HALT=HALT
                        ;;
                  *)
                        INIT_HALT=POWEROFF
                        ;;
                esac
        fi


        # See if we need to cut the power.
        if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
        then
                /etc/init.d/ups-monitor poweroff
        fi


        # Don't shut down drives if we're using RAID.
        hddown="-h"
        if grep -qs '^md.*active' /proc/mdstat
        then
                hddown=""        fi


        # If INIT_HALT=HALT don't poweroff.
        poweroff="-p"
        if [ "$INIT_HALT" = "HALT" ]
        then
                poweroff=""
        fi


        # Make it possible to not shut down network interfaces,
        # needed to use wake-on-lan
        netdown="-i"
        if [ "$NETDOWN" = "no" ]; then
                netdown=""
        fi


        log_action_msg "Will now halt"
        halt -d -f $netdown $poweroff $hddown
}


case "$1" in
  start)
        # No-op
        ;;
  restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
  stop)
        do_stop
        ;;
  *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac


:

Alles anzeigen

Zitat

Das kann man aber leicht herausbekommen:

1. /usr/sbin/ethtool -s eth1 wol g --->>> WOL aktivieren
2. /etc/init.d/halt stop ---->>> Rechner ausschalten
3. WOL ---->>>> Rechner per WOL aufwecken
4. ethtool eth1 ----->>> Nachschauen, ob WOL immernoch aktiviert ist

Das funktioniert. "/usr/sbin/ethtool -s eth1 wol g" wird auch bei jedem Start ausgeführt. Habe des so per update-rc.d hinzugefügt.

berndl: Das wird mittlerweile im halt Script (s.o.) per NETDOWN=no deaktiviert. Ich hatte sicherheitshalber mal das -i entfernt, hatte aber nichts gebracht.

Gruß

Obelix

Wicky · 3. Juli 2007

Hallo obelix,

ein Schuss ins Blaue (geht schnell...):

Versuch einmal:

1. ifconfig eth1 down
2. poweroff

So hat es bei jemandem hier geklappt:
http://board.gulli.com/thread/327243-poweroff---wake-on-lan/

Nachtrag:
Zum obigen Skript:
Das macht so ziemlich garnix :(. Außerdem habe ich gerade gelesen (man halt), dass das Binary "halt" eh das Binary "shutdown" ausführt, wenn sich der Rechner in einem Arbeits-Runlevel befindet.
Das binary "shutown" stößt dann zunächst das Runterfahren über die Init-Skripte an. D.h. die Init-Skripte dürften doch wieder als Ursache in Frage kommen..........:( ...da kann die Ursachenforschung langwierig werden, da beim Herunterfahren doch so einige Skripte durchlaufen werden...

Gruß
Wicky

obelix · 3. Juli 2007

Ich habe mal die Konsolenausgabe nach init 0 / shutdown -h now verfolgt. Ich sehe wie "/usr/sbin/ethtool -s eth1 wol g" erfolgreich ausgeführt wird. Danach passiert aber noch was. Irgendein Script macht danach noch was mit der Netzwerkkarte. Dies geht aber so schnell, dass ich nicht sehen kann was da genau passiert.

1. ifconfig eth1 down
2. poweroff

funktioniert nicht.

Gruß

Obelix

Wicky · 3. Juli 2007

Hallo obelix

Zitat

Original von obelix
Ich habe mal die Konsolenausgabe nach init 0 / shutdown -h now verfolgt. Ich sehe wie "/usr/sbin/ethtool -s eth1 wol g" erfolgreich ausgeführt wird. Danach passiert aber noch was. Irgendein Script macht danach noch was mit der Netzwerkkarte. Dies geht aber so schnell, dass ich nicht sehen kann was da genau passiert.

Das sieht so aus, als wenn dir die Analyse der init Skripte nicht erspart bleibt.

Der "gute Hoffnung" Ansatz:
Schau mal im Verzeichnis /etc/init.d/rc6 und /etc/init.d/ ob dir potentielle Skripte ins Auge Springen. Falls ja, dann bau logging Ausgaben an den betreffenden Stellen ein.

Eine gute debugging Hilfe ist dieser Block:

Code

echo "Variable1: $Variable1"  
read

->> So kann man auch noch lesen, welchen Wert eine interessante Variable hat.

Vergiss nicht die von dir veränderten Skripte zu sichern, oder die Stellen im Skript zu kommentieren, so dass du die Änderungen wieder rückgängig machen kannst.

Ach noch etwas:
Die Init-Skripte, die beim Shutdown ausgeführt werden, sind im entsprechenden Runlevel Verzeichnis (rc6, rc3...) mit einem "K" will kill gekennzeichnet. "S" seht für start.... und nicht für shutdown...

Die Datei /etc/inittab verät dir, welcher Runlevel für welchen Zweck verwendet wird.
Dies ist bei jeder Distribution ein wenig anders...

Gruß
Wicky

obelix · 3. Juli 2007

Hi Wicky,
die Start (S) und Stop(K) Scripte im SysV init runlevel hatte ich anfangs auch im Verdacht und hatte sie untersucht. Gefunden hatte ich nichts, werde dort aber nochmal schauen.

Das mit dem "Eine gute debugging Hilfe ist dieser Block:" habe ich nicht verstanden. Gibt es da nähere Infos zu oder kannst du das näher erklären?

Danke.

Gruß

Obelix

Wicky · 4. Juli 2007

Hallo ebelix,

Zitat

Original von obelix
Hi Wicky,
die Start (S) und Stop(K) Scripte im SysV init runlevel hatte ich anfangs auch im Verdacht und hatte sie untersucht. Gefunden hatte ich nichts, werde dort aber nochmal schauen.

...irgendwo muss der Hund begraben sein...insbesondere wenn du beim runterfahren schon etwas verdächtiges gelesen hast.

Zitat

Das mit dem "Eine gute debugging Hilfe ist dieser Block:" habe ich nicht verstanden. Gibt es da nähere Infos zu oder kannst du das näher erklären?

Wenn du "read" in ein Skript einfügst, dann bleibt es stehen und wartet auf eine Tastatureingabe. -> So kannst du bei einer verdächtigen Stelle lesen, was das Skript so von sich gibt -> Bei dir war ja die Ausgabe zu schnell weg....

Mit "echo $Variable" kannst du den Inhalt einer Variablen ausgeben lassen.
Das ist nützlich, wenn man sich fragt, welchen Wert wohl eine Variable angenommen hat... Wann man das benötigt, hängt von der Situation ab... in der Regel immer dann, wenn ein Skript in if-then, case-esac Konstrukt läuft...

Bei dem halt Skript könnte man so abfragen, welchen Wert z.B. die Variable INIT_HALT annimmt. Das ist zwar relativ sinnlos, da man sich das denken kann...

Konkreter:

Code

do_stop () {
echo "Init_halt hat den Wert: $INIT_HALT"   # <<<---- Den Wert ausgeben
read # <<<<-------- und dann das Skript anhalten bis zur Tastatureingabe.
        if [ "$INIT_HALT" = "" ]
        then
....

So habe ich schon manches "Rätsel" entschlüsseln können.

Gruß
Wicky

Howto : ASUS M2NPV-VM mit Kanotix/easyVDR

Jetzt mitmachen!

Teilen