Debian reageert soms (helemaal) niet.

[banaan-X]

Ik heb net een unstable geinstalleerd op mijn Duron '950'. Maar hij heeft nogal de neiging om even niet te reageren. Als ik bijvoorbeeld een tekstbestand doorblader dan haakt ie soms een halve seconde, en gaat ie weer verder...
Ik heb m net de opdracht gegeven via dselect op KDE op te halen, en toen ik vervolgens man useradd deed, blokkeerde ie helemaal. Ik heb kernel-image-2.4.16-k7 en 17-k7 geprobeerd, maar het gebeurt bij beide.
Heeft iemand anders dit probleem toevallig ook? Of weet iemand waar het aan zou kunnen liggen?

[odysseus]

Vreemd...zou niet mogen gebeuren. Wat is je load? Staan er nog 'zware' dingen tussen ps aux? Je zou de low-latency patch voor de kernel eens kunnen proberen, maar die haal eigenlijk vooral spinlocks in de kernel weg en die duren toch normaal geen halve seconde...

[banaan-X]

Op donderdag 03 januari 2002 19:04 schreef odysseus het volgende:
Vreemd...zou niet mogen gebeuren. Wat is je load? Staan er nog 'zware' dingen tussen ps aux? Je zou de low-latency patch voor de kernel eens kunnen proberen, maar die haal eigenlijk vooral spinlocks in de kernel weg en die duren toch normaal geen halve seconde...

Load is normaal. 0.20 ongeveer tijdens KDE'en. Het gebeurt ook steeds minder. Verder geen rare dingen ofzo...

[deadinspace]

Probeer je CPU eens terug te clocken...

[Predator]

Op donderdag 03 januari 2002 18:17 schreef banaan-X het volgende:
Ik heb net een unstable geinstalleerd op mijn Duron '950'. ......

Heeft iemand anders dit probleem toevallig ook? Of weet iemand waar het aan zou kunnen liggen?

[Servowire]

Op donderdag 03 januari 2002 19:47 schreef Pr3d4t0r het volgende:

[..]

Woeiiii

[deadinspace]

pr3d4t0r: dat mag het probleem niet zijn hoor
Debian Unstable bevat bugs, maar als je compu telkens even stil hangt, lijkt me dit een hardware of een kernel issue.

Banaan-X: laat even weten of het toevallig vanzelf helemaal weggaat btw...

[Predator]

Op donderdag 03 januari 2002 20:27 schreef deadinspace het volgende:
pr3d4t0r: dat mag het probleem niet zijn hoor
Debian Unstable bevat bugs, maar als je compu telkens even stil hangt, lijkt me dit een hardware of een kernel issue.

Banaan-X: laat even weten of het toevallig vanzelf helemaal weggaat btw...

Ik know

Nu lijkt het mij ook wel kernel probleem maar ie heeft al 2 verschillende kernels getest en ie heeft het bij beide zegt ie.

[stiena]

Wel toevallig, dit probleem heb ik de laatste tijd ook. Weliswaar met debian potato stable. Met de standaard kernel werkt die goed, maar toen ik kernel 2.4.17 compileerd heb gebeurde hetzelfde bij mij ook wel eens als ik een paar mozila vensters open heb staan en xmms heb draaien, als ik dan iets in de terminal wil typen dan hangt heel ff, is irritant maar kheb er ook nog nix voor kunnen vinden dus heb er maar mee leren leven....


owjah ik heb ook een duron (1ghz OC, op standaard 700 doet het hetzelfde)

sorrie dak je niet kan helpen....

[banaan-X]

Op donderdag 03 januari 2002 21:37 schreef stiena het volgende:
Wel toevallig, dit probleem heb ik de laatste tijd ook. Weliswaar met debian potato stable. Met de standaard kernel werkt die goed, maar toen ik kernel 2.4.17 compileerd heb gebeurde hetzelfde bij mij ook wel eens als ik een paar mozila vensters open heb staan en xmms heb draaien, als ik dan iets in de terminal wil typen dan hangt heel ff, is irritant maar kheb er ook nog nix voor kunnen vinden dus heb er maar mee leren leven....


owjah ik heb ook een duron (1ghz OC, op standaard 700 doet het hetzelfde)

sorrie dak je niet kan helpen....

Hmm, ik geloof dat mijne idd met de 2.2.19 kernel het nog niet deed. Ik ga maar eens een k6 kernel proberen ofzo. Het lijkt immers toch een kernel-probleem te zijn lijkt me. Jij hebt ook k7-kernel genomen?

Trouwens als ik xmms aanheb, toen ging het geluid eerst overslaan, en vervolgens steeds kortere stukjes spelen, totdat het op een gegeven moment alleen nog maar ruis was. Of ie toen ook vastliep weet ik eigenlijk niet meer (was een beetje laat ).
Maar jij hoort je muziek dus nog wel goed?

Op donderdag 03 januari 2002 20:27 schreef deadinspace het volgende:
pr3d4t0r: dat mag het probleem niet zijn hoor
Debian Unstable bevat bugs, maar als je compu telkens even stil hangt, lijkt me dit een hardware of een kernel issue.

Banaan-X: laat even weten of het toevallig vanzelf helemaal weggaat btw...

Het was vanochtend nog steeds zo, ik zit nu op een andere pc. Ik ga zo weer ff proberen, en dan draai ik constant top, misschien dat ik dan ontdek wat het is.

Op donderdag 03 januari 2002 20:16 schreef Servowire het volgende:

[..]

Woeiiii

Unstable mag dan wel unstable zijn, maar vastlopen is ook weer niet de bedoeling Maar ik ga wel ff 'apt-get upgrad'-en zo.

Op donderdag 03 januari 2002 19:04 schreef odysseus het volgende:
Vreemd...zou niet mogen gebeuren. Wat is je load? Staan er nog 'zware' dingen tussen ps aux? Je zou de low-latency patch voor de kernel eens kunnen proberen, maar die haal eigenlijk vooral spinlocks in de kernel weg en die duren toch normaal geen halve seconde...

Ik had gisteren ook een erg lange 'pauze', daarna gaf uptime een load van 5.11

edit:
ff wat dingen bijgezet

[deadinspace]

Mja, ik heb dit probleem ook gehad op een AMD Duron (Op een MSI K7T Turbo).
Het probleem is nu weg (al een hele tijd trouwens), maar ergens in die periode zat er ook brak ram in, dus ik kan mij niet meer goed herinneren of dat dat 'stilhangen' nu over is gegaan doordat het brakke ram eruit is gehaald, of dat het 'vanzelf' over is gegaan.

Die bak draait Debian Potato met kernel 2.2.19 (laatst geupdate naar 2.2.20, maar daarvoor draaide hij al goed).

[banaan-X]

Op vrijdag 04 januari 2002 22:37 schreef deadinspace het volgende:
Mja, ik heb dit probleem ook gehad op een AMD Duron (Op een MSI K7T Turbo).
Het probleem is nu weg (al een hele tijd trouwens), maar ergens in die periode zat er ook brak ram in, dus ik kan mij niet meer goed herinneren of dat dat 'stilhangen' nu over is gegaan doordat het brakke ram eruit is gehaald, of dat het 'vanzelf' over is gegaan.

Die bak draait Debian Potato met kernel 2.2.19 (laatst geupdate naar 2.2.20, maar daarvoor draaide hij al goed).

Zo, na een avondje top te hebben gedraaid ben ik er achter dat inderdaad de kernel de boosdoener is.
Als ik dpkg (apt) ga gebruiken treedt het trouwens pas op (misschien toeval).
[update] Waarschijnlijk gebeurt het als een ander proces veel cpu vraagt, want bij bunzip2 gebeurt het ook [/update]
Als het systeem dus even niet regeageerd is vooral kupdated erg druk bezig... soms wel 80% meestal ongeveer 40%. Ook kswapd weet er wat van, deze haalt soms ook 40% (tijdens zo'n 'schok').

Ligt dit nu idd aan de kernel? Want dan ga ik die van bunk maar eens proberen, helaas is die pas bij 2.4.14, maar die draait op mijn k6-2 in ieder geval wel erg goed (de -k6 dan )

[banaan-X]

Hoe kan ik nu dit probleem oplossen? kupdated en kswapd zijn echt veel te druk bezig... Inderdaad andere kernel? Of minder / geen swap?

[banaan-X]

Ik heb nu kernel-2.4.14-k7 van people.debian.org/~bunk/ geinstalleerd, en daar gebeurt het ook mee Ik wordt er een beetje ziek van eigenlijk... Iemand nog een idee?

(het probleem is dus dat kupdated en kswapd nogal druk bezig zijn als programma's veel cpu vragen...)

[Valium]

Zet er eens een gewone pentium-kernel in. Verschil merk je toch niet (nauwelijks), en misschien helpt het. Die K7-optimalisatie willen wel eens voor problemen zorgen met sommige harde waren.

edit:

een seconde pauze en kswapd bezig. Dat zou ook een IDE-probleem KUNNEN zijn (als je een IDE-swapdrive hebt). Misschien dat je daar eens naar moet kijken. Of het is een IDE-harddrive temeratuurcalibratie, maar dat gebeurt alleen bij VEEL activiteit, dus als je grote bestanden kopieert.

Ow ja, en de low-latency-patch moet je natuurlijk wel meteen combineren met de lock-break-patch. Die breekt de spinlocks die er nog zijn ook nog eens doormidden waar het kan.

[banaan-X]

Op zaterdag 05 januari 2002 13:47 schreef Valium het volgende:
Zet er eens een gewone pentium-kernel in. Verschil merk je toch niet (nauwelijks), en misschien helpt het. Die K7-optimalisatie willen wel eens voor problemen zorgen met sommige harde waren.

Welke dan? i586 of i386? Ik heb trouwens nog een pc met een k6-2 en daar draait de 2.4.14-k6 kernel erg goed op.

[edit]
een seconde pauze en kswapd bezig. Dat zou ook een IDE-probleem KUNNEN zijn (als je een IDE-swapdrive hebt). Misschien dat je daar eens naar moet kijken. Of het is een IDE-harddrive temeratuurcalibratie, maar dat gebeurt alleen bij VEEL activiteit, dus als je grote bestanden kopieert.

In Windows is er niets aan de hand, kan dat dan wel? Hoe zet ik trouwens swap uit?

Ow ja, en de low-latency-patch moet je natuurlijk wel meteen combineren met de lock-break-patch. Die breekt de spinlocks die er nog zijn ook nog eens doormidden waar het kan.
[/edit]

Dit snap ik niet helemaal...

[Valium]

Op zaterdag 05 januari 2002 14:13 schreef banaan-X het volgende:
Welke dan? i586 of i386? Ik heb trouwens nog een pc met een k6-2 en daar draait de 2.4.14-k6 kernel erg goed op.

Die is dus blijkbaar wel goed, of de harde waren die daarin zitten zijn minder "apart".
Probeer ze beide eens. Gewoon i586 moet perfect werken.

In Windows is er niets aan de hand, kan dat dan wel? Hoe zet ik trouwens swap uit?

Dan is het onwaarschijnlijk. Swap zet je uit met :swapoff. Permanent wil je dit niet, maar om ffies te testen kan 't wel. Let er wel op dat je je geheugen niet 100% vol laat lopen. Dan is het namelijk ook ECHT vol.

Dit snap ik niet helemaal...

Wat hierboven wordt geopperd (low-latency-patch), is een manier om de multitasking van de linux-kernel te verbeteren. Daarvoor moet je wel je eigen kerneltje gaan compileren.

Die patch die ik dan weer noem, is een verbetering op de algemene multiprocessor locking. Dit is ook een "goede patch (tm)" om audioverwerking te verbeteren.

[banaan-X]

Op zaterdag 05 januari 2002 15:31 schreef Valium het volgende:

[..]

Die is dus blijkbaar wel goed, of de harde waren die daarin zitten zijn minder "apart".
Probeer ze beide eens. Gewoon i586 moet perfect werken.
[..]

Dan is het onwaarschijnlijk. Swap zet je uit met :swapoff. Permanent wil je dit niet, maar om ffies te testen kan 't wel. Let er wel op dat je je geheugen niet 100% vol laat lopen. Dan is het namelijk ook ECHT vol.
[..]

Wat hierboven wordt geopperd (low-latency-patch), is een manier om de multitasking van de linux-kernel te verbeteren. Daarvoor moet je wel je eigen kerneltje gaan compileren.

Die patch die ik dan weer noem, is een verbetering op de algemene multiprocessor locking. Dit is ook een "goede patch (tm)" om audioverwerking te verbeteren.

Ik heb nu de k6 kernel 2.4.14 erop gezet, zelfde probleem Waar is die kupdated eigenlijk goed voor?? Iets met een HD toch? Ik heb een D740X, vrij nieuw, maar is dat een probleem dan?
En maakt het iets uit of hoe ik de udma enz heb staan? wat is udma5 trouwens?

hdparm:

code:

comp2:/home/peter# hdparm -I /dev/hda

/dev/hda:

non-removable ATA device, with non-removable media
      Model Number:      MAXTOR 6L060J3
      Serial Number:        663128915229
      Firmware Revision:    A93.0500
Standards:
      Used: ATA/ATAPI-5 T13 1321D revision 1
      Supported: 1 2 3 4 5
Configuration:
      Logical      max     current
      cylinders  16383   16383
      heads      16 16
      sectors/track   63    63
      bytes/track:    32256      (obsolete)
      bytes/sector:   21298      (obsolete)
      current sector capacity: 16514064
      LBA user addressable sectors = 117266688
Capabilities:
      LBA, IORDY(can be disabled)
      Buffer size: 1819.5kB   ECC bytes: 4    Queue depth: 1
      Standby timer values: spec'd by Vendor, no device specific minimum
      r/w multiple sector transfer: Max = 16  Current = 0
      DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6
         Cycle time: min=120ns recommended=120ns
      PIO: pio0 pio1 pio2 pio3 pio4
         Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
      Enabled Supported:
         *    READ BUFFER cmd
         *    WRITE BUFFER cmd
         *    Host Protected Area feature set
         *    look-ahead
         *    write cache
         *    Power Management feature set
            Security Mode feature set
         *    SMART feature set
            SET MAX security extension
         *    DOWNLOAD MICROCODE cmd
Security:
      Master password revision code = 65534
            supported
      not     enabled
      not     locked
      not     frozen
      not     expired: security count
      not     supported: enhanced erase
      30min for SECURITY ERASE UNIT.
HW reset results:
      CBLID- above Vih
      Device num = 0 determined by the jumper
Checksum: correct

[update]
swapoff hielp ook niet, kupdated blijft dan nog steeds vervelend doen
[/update]

[banaan-X]

Yes!! Ik ben eruit!

Ik had DMA van mijn schijf niet aan staan... Terwijl als je dus met hdparm info opvroeg hij udma5 aangaf. ECHTER: -d gaf dat ie uit stond...
Nou ja, rest van het verhaal snappen jullie wel he

P.S. Als ik nu reboot, blijft de dma dan aanstaan, of moet dit ergens ingesteld worden dat bij elke reboot dma aan wordt gezet?

[deadinspace]

Op zondag 06 januari 2002 17:51 schreef banaan-X het volgende:
P.S. Als ik nu reboot, blijft de dma dan aanstaan, of moet dit ergens ingesteld worden dat bij elke reboot dma aan wordt gezet?

Als je reboot is hij weer uit.
'hdparm -blaat /dev/blaat' ergens onderaan in /etc/init.d/bootmisc.sh (voor SYSV style initscripts) erbij zetten, en het wordt elke boot goedgezet.

Weet je zeker dat het hierdoor komt? Vind ik een beetje vreemd eigenlijk...
Kun je het reproduceren (dma uit -> schok, dma aan -> geen schok)?

[banaan-X]

Op zondag 06 januari 2002 19:15 schreef deadinspace het volgende:

[..]

Als je reboot is hij weer uit.
'hdparm -blaat /dev/blaat' ergens onderaan in /etc/init.d/bootmisc.sh (voor SYSV style initscripts) erbij zetten, en het wordt elke boot goedgezet.

Weet je zeker dat het hierdoor komt? Vind ik een beetje vreemd eigenlijk...
Kun je het reproduceren (dma uit -> schok, dma aan -> geen schok)?

Ik zal het erin blaten

Tja, wat is zeker he, maar ik zal het voor je proberen. Kun je trouwens gewoon dma aan/uit zetten in X (init 2)? Ik heb het veiligheidshalve in init1 gedaan.

[banaan-X]

Op zondag 06 januari 2002 19:15 schreef deadinspace het volgende:

Weet je zeker dat het hierdoor komt? Vind ik een beetje vreemd eigenlijk...
Kun je het reproduceren (dma uit -> schok, dma aan -> geen schok)?

Ik kan het reproduceren. En het is inderdaad zo...

[deadinspace]

Op zondag 06 januari 2002 19:39 schreef banaan-X het volgende:
Kun je trouwens gewoon dma aan/uit zetten in X (init 2)? Ik heb het veiligheidshalve in init1 gedaan.

Kun je gewoon in elk runlevel doen.

En vreemd dat het daaraan lag... geen DMA hebben zorgt voor schokkerigheid ja, maar toch niet zulke lange schokken? Naja... tzalwel.

[Verwijderd]

Thnx allen!
Ik had dit probleem ook (ook met debian )
het was een maxtor schijfje dat dezelfde problemen vertoonde
met udma aan doet ie het weer zoals het hoort

ikku blij