Notebook schaltet bei längerem Backup (ca 1..2 Minuten) ab :

[Ottmar Ohlemacher]

Hallo,

wollte vorhin mit meinem Notebook (300MHz AMD, Win98) einen Ordner
(300MB) auf der FP des Desktops über USB-Ethernetadapter sichern, als
das Notebook sich mehrmals während der Datenübertragung nach rund
1...2 Minute mittendrinne abschaltete. Notebook wurde mit Netzteil
betreiben.

Hat jemand ne Idee, wo der Fehler zu suchen sein könnte.

Danke für Info.

mfG Ottmar
--
*ACHTUNG* E-mails mit der Adresse im Header wandern ungelsen in den Muell
Wer mich per Mail erreichen will, der muss "yyyyyyy" gegen
"emacher" ersetzen. Die Spamflut machte diese Maßnahme notwendig.

 

[Andreas Weber]

Ottmar Ohlemacher schrieb:

wollte vorhin mit meinem Notebook (300MHz AMD, Win98) einen Ordner
(300MB) auf der FP des Desktops über USB-Ethernetadapter sichern, als
das Notebook sich mehrmals während der Datenübertragung nach rund
1...2 Minute mittendrinne abschaltete. Notebook wurde mit Netzteil
betreiben.
Hat jemand ne Idee, wo der Fehler zu suchen sein könnte.

Hi Ottmar, ich würde als erstens beim Betriebssystem (Win98 SE?) suchen.
Kannst du den Fehler reproduzieren? oder geht das Notebook generell
(unabhängig von der Windows-Benutzung) nach ein paar Minuten aus? Nach
nur einmaligem "Abschalten/Abstürzen" würde ich nicht gleich auf einen
Hardwaredefekt schließen. Gruß Andy

 

[Ottmar Ohlemacher]

Andreas Weber <spam@tech-chat.de> wrote:

Ottmar Ohlemacher schrieb:

wollte vorhin mit meinem Notebook (300MHz AMD, Win98) einen Ordner
(300MB) auf der FP des Desktops über USB-Ethernetadapter sichern, als
das Notebook sich mehrmals während der Datenübertragung nach rund
1...2 Minute mittendrinne abschaltete. Notebook wurde mit Netzteil
betreiben.
Hat jemand ne Idee, wo der Fehler zu suchen sein könnte.

Hi Ottmar, ich würde als erstens beim Betriebssystem (Win98 SE?) suchen.
Kannst du den Fehler reproduzieren? oder geht das Notebook generell
(unabhängig von der Windows-Benutzung) nach ein paar Minuten aus? Nach
nur einmaligem "Abschalten/Abstürzen" würde ich nicht gleich auf einen
Hardwaredefekt schließen. Gruß Andy

Ja - Fehler ist reproduzierbar, allerdings nicht auf den "Punkt".

Ich hatte (wollte) mit dem Program Filesync einen Ordner mit 300 MB
Daten vom Laptop auf den Desktop schaufeln.

Die Datenübertragung startet zunächst ganz normal und man kann in
Filsync die Datenübertagung beobachten, wie die Files auf dem
Desktoprechner landen, bis urplötzlich dem Laptop nach ca 1...3
Minuten urplötzlich das Licht ausgeht (Bildschim schwarz, Lüfter
steht, im "Betriebs-LCD" wird aber weiterhin angezeigt, das
Netzspannung vorhanden ist und zumendest der Prozessor mit veringerter
Leistung läuft (Wasserhahn mit einem von drei Strahlen).

Dieser komische Absturz ereignet sich nur bei der Datenübertagung über
das Netzwerk (USB-Ethernetadapter) :'(

mfG Ottmar
--
*ACHTUNG* E-mails mit der Adresse im Header wandern ungelsen in den Muell
Wer mich per Mail erreichen will, der muss "yyyyyyy" gegen
"emacher" ersetzen. Die Spamflut machte diese Maßnahme notwendig.

 

[Gernot Fink]

In article <u0t2l0haqtjiloo38vni89as4jigemsdpu@4ax.com>,
Ottmar Ohlemacher <2ohlyyyyyyy@web.de> writes:

Hallo,

wollte vorhin mit meinem Notebook (300MHz AMD, Win98) einen Ordner
(300MB) auf der FP des Desktops über USB-Ethernetadapter sichern, als
das Notebook sich mehrmals während der Datenübertragung nach rund
1...2 Minute mittendrinne abschaltete. Notebook wurde mit Netzteil
betreiben.

Hat jemand ne Idee, wo der Fehler zu suchen sein könnte.

Erstmal beim CPU Lüfter.

--
MFG Gernot

 

[Andreas Weber]

Gernot Fink schrieb:

Hat jemand ne Idee, wo der Fehler zu suchen sein könnte.

Erstmal beim CPU Lüfter.

Da sich der "Absturz" nur beim Synchronisieren von Dateien über einen
USB-Ethernet-Adapter ereignet, denke ich nicht, daß der CPU-Lüfter
schuld ist Der Fehler ist IMHO nur beim BS Win98 zu suchen.
(falscher Treiber oder sonstwas) Und passt deshalb IMO nicht in diese NG.
de.comp.hardware.misc oder so ist sicher passender.

Trotzdem kleiner Tip: Es gibt AFAIK einen Win98 Update Patch,
nachschauen, wenn gefunden updaten. Dann für den Adapter neue Treiber
laden und probieren... Gruß Andy

 

[Martin Petrson]

Hallo Ottmar,

Ottmar Ohlemacher schrieb:

Hallo,

wollte vorhin mit meinem Notebook (300MHz AMD, Win98) einen Ordner
(300MB) auf der FP des Desktops über USB-Ethernetadapter sichern, als
das Notebook sich mehrmals während der Datenübertragung nach rund
1...2 Minute mittendrinne abschaltete. Notebook wurde mit Netzteil
betreiben.

hier gabs probleme mit der Spannungsversorgung im Laptop: beim Anstecken
von einer externen HDD ging er auch in den suspend und kam nicht wieder
:-/

Verwendete Hardware: ipc starnote98 allerdings von k6-300 auf K6-III
400MHz aufgerüstet. Nach dem Heruntertakten auf 333 klappte es wieder...

Meine Vermutung: durch die andauernde Übertragung wird die
5V-Spannungsversorgung des Laptops vom usb-eth-Adapter überlastet und
die Kiste schaltet ab.

Probier doch mal PCMCIA, inzw. gibt´s ja sogar Kingston 10/100 MBit für
nen Zehner ;-)


MfG Martin

 

[Nils Juergens]

Ottmar Ohlemacher wrote:

Dieser komische Absturz ereignet sich nur bei der Datenübertagung über
das Netzwerk (USB-Ethernetadapter) :'(

Ich würde auf ein Problem mit den Interrupts tippen. Zwei Geräte teilen
sich den gleichen Interrupt und einer (oder beide) der Treiber sind
nicht in der lage, damit umzugehen. Wenn Du jetzt grössere Datenmengen
überträgst erhöht sich die Wahrscheinlichkeit einer Kollistion und es
kommt zu einem Fehlerzustand. Wenn die Interruptroutine jetzt erst
weitere Interrupts gesperrt hat und dann in einen Deadlock läuft
schmiert das ganze System ab.

Du könntest also mal versuchen die Interrupt-Zuordnung im BIOS
anzuschauen und evtl. abzuändern. Vielleicht schaltest Du zum Entwirren
ein paar Geräte (z.B. ungenutzte serielle Ports) ab und nutzt die damit
frei werdenden IRQs 4 oder 3.

viel Glück,
Nils

 

[Martin Laabs]

Nils Juergens <ju@isf.rwth-aachen.de> writes:

nicht in der lage, damit umzugehen. Wenn Du jetzt grössere Datenmengen
überträgst erhöht sich die Wahrscheinlichkeit einer Kollistion und es
kommt zu einem Fehlerzustand. Wenn die Interruptroutine jetzt erst
weitere Interrupts gesperrt hat und dann in einen Deadlock läuft
schmiert das ganze System ab.

Nein, so kann es nicht funktionieren. Das System ist ja:

-Interrupt ausgelöst (bei PCI pegelgesteuert)
-1. Interruptroutine aufgerufen
-Interrupthandler testet ob sein Gerät gemeint ist. Wenn ja Int. löschen
-wenn nicht, weiter
-2. Interruptroutine
-testen, wenn diesmal getroffen löschen
usw

Vom Interrupt her kann es also keine Kollisionen geben. Es kann aber sehr
wohl sein das ein Interrupthandler nicht erkennt das es sich um
sein Gerät handelt und den Interrupt nicht löscht. Dann probiert es
das System immer weiter und wenn es beim letzen Handler angekommen ist
fängt es beim 1. wieder an => Endlosschleife.

Aber auch das halte ich für unwarscheinlich weil es nicht schwer ist
zu testen ob "sein" Gerät den Interrupt generiert hat und daher dort
wenig Fehler zu erwarten sind. Es wird warscheinlich einen anderen
Grund haben ... (zumal mehrere Minuten viele zehntausend Interrupts
bedeuten).

Ich mir eher vorstellen das der Programmierer irgendeinen Puffer
(z.B. für DMA Transfer) nicht wieder frei gibt und es dann nach
x Übertragungen keinen freien Speicher zum alloziieren gibt.

Tschüss
Martin L.

Du könntest also mal versuchen die Interrupt-Zuordnung im BIOS
anzuschauen und evtl. abzuändern. Vielleicht schaltest Du zum Entwirren
ein paar Geräte (z.B. ungenutzte serielle Ports) ab und nutzt die damit
frei werdenden IRQs 4 oder 3.

viel Glück,
Nils

 

[Ottmar Ohlemacher]

Ottmar Ohlemacher <2ohlyyyyyyy@web.de> wrote:

Hi Ottmar, ich würde als erstens beim Betriebssystem (Win98 SE?) suchen.
Kannst du den Fehler reproduzieren? oder geht das Notebook generell
(unabhängig von der Windows-Benutzung) nach ein paar Minuten aus? Nach
nur einmaligem "Abschalten/Abstürzen" würde ich nicht gleich auf einen
Hardwaredefekt schließen. Gruß Andy


Ja - Fehler ist reproduzierbar, allerdings nicht auf den "Punkt".

Ich hatte (wollte) mit dem Program Filesync einen Ordner mit 300 MB
Daten vom Laptop auf den Desktop schaufeln.

Die Datenübertragung startet zunächst ganz normal und man kann in
Filsync die Datenübertagung beobachten, wie die Files auf dem
Desktoprechner landen, bis urplötzlich dem Laptop nach ca 1...3
Minuten urplötzlich das Licht ausgeht (Bildschim schwarz, Lüfter
steht, im "Betriebs-LCD" wird aber weiterhin angezeigt, das
Netzspannung vorhanden ist und zumendest der Prozessor mit veringerter
Leistung läuft (Wasserhahn mit einem von drei Strahlen).

Dieser komische Absturz ereignet sich nur bei der Datenübertagung über
das Netzwerk (USB-Ethernetadapter) :'(

NACHTRAG:

Bei oben beschriebenen Fall ist dieser komische Absturz immer noch
nach 1...3 Minuten reproduzierbar. Jetzt habe ich allerdings
herausgefunden, das der komische Absturz (Bild dunkel, Lüfter steht)
des Laptops nur erfolgt, wenn die Datenübertagung vom Desktoprechner
aus initiert und gesteuert wird.

Wenn ich allerdings die Datenübertagung vom Laptop aus initiere (egal,
ob ich einfach einen großen Ordner (300MB Daten) per Copy und Paste
oder das Program Filesynce dazu verwende), dann ereignet sich dieser
komische Absturz nicht .... also scheinbar doch ein Software- oder
Interupt(?)problem. (Die Datenflußrichtung wurde nicht geändert - es
ging weiterhin um eine Datenübertragung vom Laptop auf den Deskop, nur
eben diesmal vom Laptop aus eingeleitet).

Bemerkenswert hier bei die "Asymetrie", das die Datenanforderung des
Deskops den Laptop zum Absturz bringt, hingegen wenn die
Datenübertragung vom Laptop selbst aus initiert wurde, dann
funktionierts.

Vielleicht hat ja noch jemand ne Idee....

.....auf jeden Fall werde ich versuchen, mir deswegen jetzt keine
grauen Haare wachsen zu lassen und es einfach um das Problem
heraumzuarbeiten.

mfG Ottmar
--
*ACHTUNG* E-mails mit der Adresse im Header wandern ungelsen in den Muell
Wer mich per Mail erreichen will, der muss "yyyyyyy" gegen
"emacher" ersetzen. Die Spamflut machte diese Maßnahme notwendig.

 

[Nils Juergens]

Martin Laabs wrote:

Nein, so kann es nicht funktionieren. Das System ist ja:

-Interrupt ausgelöst (bei PCI pegelgesteuert)

Wäre es nicht denkbar, dass weitere Interrupts von
nicht-PCI-angebundenen Geräten ausgelöst werden (je nachdem, wie der
PCI-Bus an den PIC angebunden ist)?

-1. Interruptroutine aufgerufen
-Interrupthandler testet ob sein Gerät gemeint ist. Wenn ja Int. löschen

Nachdem Gerät A seinen Int. gelöscht hat kann es doch passieren, dass
wenige Takte später Gerät B einen Int. auf der gleichen Leitung auslöst
und innerhalb der Interrupt-Routine nochmals ein Interrupt und die
gleiche Routine ausgelöst wird.

Ich habe jedenfalls im Kopf, dass man bei Interruptroutinen immer davon
ausgehen muss, das weitere Interrupts ausgelöst werden können, es sei
denn der INT wird maskiert oder man sperrt alle Interrupts (CLI).

Wenn ein Treiber dies Versäumt kann es schnell dazu kommen, das ein
Treiber einen spinlock hält und dann der andere Treiber, aus dem zweiten
Interrupt heraus aufgerufen, verzweifelt versucht, eben diesen spinlock
zu bekommen. Wenn jetzt der _zweite_ (besser programmierte) Treiber alle
Interrupts gesperrt hat kommt es zum Stillstand des Systems, der Rechner
wartet permanent auf den spinlock.

Aber auch das halte ich für unwarscheinlich weil es nicht schwer ist
zu testen ob "sein" Gerät den Interrupt generiert hat und daher dort
wenig Fehler zu erwarten sind. Es wird warscheinlich einen anderen
Grund haben ... (zumal mehrere Minuten viele zehntausend Interrupts
bedeuten).

Bedauernswert schlechte Treiber hat es schon _soooo_ oft gegeben.

Aus [0]:
"Letzlich ist es eine Sache der PCI-Gerätetreiber, ob das Teilen der
IRQs funktioniert oder nicht. Hersteller, die es immer noch nicht
geschafft haben, dieses beinahe uralte Feature in ihre Karten zu
implementieren, gehören eigentlich vom Markt verbannt. Besonders Karten
der Marke "Creative" sind in der Vergangenheit häufig negativ
aufgefallen, ebenso wie TV- oder Videocapture-Karten. Wer also viele
PCI-Geräte (AGP-Karte, PCI-Karten, USB, evtl. Onboard-RAID etc.)
einbauen und verwenden will, sollte sich vor dem Kauf von der Fähigkeit
des IRQ-sharing der PCI-Kartentreiber überzeugen."

Und da es hier auch um nicht gerade aktuelle Hardware geht kann der
Absatz durchaus noch angewendet werden.

Gruss,
Nils

[0] de.comp.hardware.cpu+mainboard FAQ
(http://www.dch-faq.de/kap06.html)