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

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
 Click to see the full signature
Reply to
Ottmar Ohlemacher
Loading thread data ...

Ottmar Ohlemacher schrieb:

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

Reply to
Andreas Weber

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
 Click to see the full signature
Reply to
Ottmar Ohlemacher

Erstmal beim CPU Lüfter.

--
MFG Gernot
Reply to
Gernot Fink

Gernot Fink schrieb:

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

Reply to
Andreas Weber

Hallo Ottmar,

Ottmar Ohlemacher schrieb:

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

Reply to
Martin Petrson

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

Reply to
Nils Juergens

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.

Reply to
Martin Laabs

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
 Click to see the full signature
Reply to
Ottmar Ohlemacher

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

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.

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
formatting link
Reply to
Nils Juergens

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.