Hallo, wer merkt (Maus-)Hakeln/Verzögerungen/Stocken/Verlangsamung etc., sobald von CDs/DVDs gelesen wird? Dabei sollen folgende Fehlerquellen ausgeschlossen sein: 1. (U)DMA einschalten hilft nichts 2. (U)DMA per hdparm -d0 ausschalten hilft nichts 3. Laufwerk als ide-scsi benutzen hilft nichts 4. Laufwerk als ide-cd benutzen hilft nichts 5. Genug Speicher soll da sein, Prozessor soll schnell genug sein 6. Das Problem tritt (auch) bei Anschluss des Laufwerks am Onboard (Secondary) Master auf, als einziges Gerät mit Master gejumpert. Kabel soll ok sein, egal jetzt ob UDMA66 Kabel oder nicht. Das Laufwerk kann das einzige neben einer Festplatte sein. 7. Mit Knoppix 3.2 tritt es auch auf 8. Es tritt mit cdrecord 2.0 (bei mir unter SuSe 8.2) auf; trat aber auch schon bei 8.0 und 8.1 auf, vielleicht sogar unter 7.3 (?) 9. Es tritt vielleicht auch mit Cdrdao version 1.1.7 (SuSE 8.2 oder früher) auf. 10. CDs BRENNEN geht problemlos 11. vanilla 2.4.20 benutzen hilft auch nichts 12. ? Bitte bitte sagt mal was dazu, dieses Problem hab ich jetzt schon seit Jahren und noch keine Lösung. Deshalb hab ich noch Windoof. Es tritt bei meinen beiden Mitbewohnern an ihren Rechnern auf. Ich habe wirklich schon viele Fehlerquellenkombinationen bedacht, aber ich komm nicht drauf. Wer im Netz sucht, wird sehen, dass ich das Problem schon lange habe. Es gibt auch andere, die das haben und - möglicherweise - sogar Patchs bzw. es ist bekannt. Aber mich interessiert, wen von Euch es trifft bzw. getroffen hat. Da fällt mir ein: Es kann doch nicht etwa daran liegen, dass ich mehrere Software-RAIDs verwende? Ich hab massig Speicher, VIA KT133A, Duron 950, schnelle 7200er Platten, schnelle CD/DVD Laufwerke, alles UDMA, sonst kaum Prozessorlast beim Laden/Speichern wegen RAID 0 und 1. Oder...? Bin echt fast verzweifelt. Naja, dafür ertrag ichs jetzt schon lange. Aber es nervt mich _unendlich_, nicht ordentlich CDs kopieren zu können, insbesondere Audio-CDs, bzw. darunter zu leiden, dass das System hakelt. Aber beim Kopieren von Daten-CDs mit DAO ist nach ein paar Sekunden alles zu spät,s elbst beim Lesen hakelts manchmal. Haben das denn nicht einige andere auch?! Ré
Hi, Florian Gross schrieb:
Findet sich da ein Fehler/Hinweis in der /var/log/messages?
In dem Fall, wo ich per cdrecord oder cdrdao CDs sozusagen "raw" kopieren möchte, taucht so was auf: Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00 Das bloße Lesen einer gemounteten CD ist kein Problem - allerdings hakelt selbst da manchmal das ganze System für kurze Augenblicke. Ré
Hallo, * René Matthäi textete am 08.05.03:
Florian Gross schrieb:
Findet sich da ein Fehler/Hinweis in der /var/log/messages?
In dem Fall, wo ich per cdrecord oder cdrdao CDs sozusagen "raw" kopieren möchte, taucht so was auf:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
OK, mit ide-scsi hab' ich nichts am Hut, aber die Meldung "unsupported command" ist doch recht vielsagend. Irgendwas geht hier daneben und durch diese Fehler wird dein ganzes System langsam.
Das bloße Lesen einer gemounteten CD ist kein Problem - allerdings hakelt selbst da manchmal das ganze System für kurze Augenblicke.
Tut sich da auch was in der messages? cu flo --
wenn Du auch unbedingt eines der größten Rätsel der Informatik benutzen mußt... > Ich weiß gar nicht, was du gegen den vi(m) hast, nichts wirksames, von :q! mal abgesehen... [Hajo Pflueger und Christopher Splinter in dag°]
* René Matthäi textete am 08.05.03:
Florian Gross schrieb:
* René Matthäi textete am 08.05.03:
Das bloße Lesen einer gemounteten CD ist kein Problem - allerdings hakelt selbst da manchmal das ganze System für kurze Augenblicke.
Tut sich da auch was in der messages?
Nein.
In diesem Fall weiß ich dann nicht, was da los ist. cu flo -- Science Fiction is des midde Raumschiff un de Wisseschaft. Fantasy is des midde besoffene Zwerch un de Einhönner. [Heiko Nock in drsm]
Hallo, On Thu, 08 May 2003, René Matthäi wrote:
Florian Gross schrieb:
Findet sich da ein Fehler/Hinweis in der /var/log/messages? [..] Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Das bloße Lesen einer gemounteten CD ist kein Problem - allerdings hakelt selbst da manchmal das ganze System für kurze Augenblicke.
Auch wenn das deine ersten Angaben auszuschliesen scheinen: das riecht fuer mich sehr nach einem Ressourcen-Konflikt. Ueberpruefe mal /proc/interrupts und /proc/ioports... -dnh -- Wenn ich fleissig waere, waere ich kein Admin. -- Klaus Muth
Hi, David Haller schrieb:
Auch wenn das deine ersten Angaben auszuschliesen scheinen: das riecht fuer mich sehr nach einem Ressourcen-Konflikt. Ueberpruefe mal /proc/interrupts und /proc/ioports...
# cat /proc/interrupts CPU0 0: 437225 XT-PIC timer 1: 6922 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 700724 XT-PIC eth0, Ensoniq AudioPCI 6: 109 XT-PIC floppy 8: 161 XT-PIC rtc 9: 426187 XT-PIC nvidia 10: 90276 XT-PIC ide2, ide3, usb-uhci, usb-uhci 11: 14 XT-PIC aic7xxx 12: 172153 XT-PIC PS/2 Mouse 14: 109934 XT-PIC ide0 15: 66495 XT-PIC ide1 NMI: 0 LOC: 437172 ERR: 256 MIS: 0 Keine Konflikte, außer vielleicht bei IRQ #10, USB mit IDE2 und 3. Man bedenke aber meine Tests mit KNOPPIX: Booten von /dev/hdc und keine Festplatten gemountet. Allerdings trotzdem den Promise im System, zugegebenermaßen (vielleicht hatte ich den aber sogar auch rausgezogen). Müsste ich unter KNOPPIX vielleicht auch nochmal schauen. # cat /proc/ioports 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 03c0-03df : vesafb 03f2-03f5 : floppy 03f6-03f6 : ide0 03f7-03f7 : floppy DIR 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 1c00-1cff : aic7xxx 2c00-2cff : aic7xxx 3c00-3cff : aic7xxx 4c00-4cff : aic7xxx 5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 5c00-5cff : aic7xxx 6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 6000-607f : via686a-sensors 6c00-6cff : aic7xxx 7c00-7cff : aic7xxx 8c00-8cff : aic7xxx 9000-900f : VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE 9000-9007 : ide0 9008-900f : ide1 9400-941f : VIA Technologies, Inc. USB 9400-941f : usb-uhci 9800-981f : VIA Technologies, Inc. USB (#2) 9800-981f : usb-uhci 9c00-9cff : VIA Technologies, Inc. VT82C686 AC97 Audio Controller 9c00-9cff : aic7xxx a000-a003 : VIA Technologies, Inc. VT82C686 AC97 Audio Controller a400-a403 : VIA Technologies, Inc. VT82C686 AC97 Audio Controller a800-a8ff : Adaptec AHA-2940/2940W / AIC-7871 a800-a8ff : aic7xxx ac00-ac3f : Ensoniq 5880 AudioPCI ac00-ac3f : Ensoniq AudioPCI b000-b007 : Promise Technology, Inc. 20268 b000-b007 : ide2 b400-b403 : Promise Technology, Inc. 20268 b402-b402 : ide2 b800-b807 : Promise Technology, Inc. 20268 b800-b807 : ide3 bc00-bc03 : Promise Technology, Inc. 20268 bc02-bc02 : ide3 c000-c00f : Promise Technology, Inc. 20268 c000-c007 : ide2 c008-c00f : ide3 c400-c4ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ c400-c4ff : 8139too cc00-ccff : aic7xxx dc00-dcff : aic7xxx ec00-ecff : aic7xxx fc00-fcff : aic7xxx Hier gibt es nur einen Konflikt an 9c00-9cff, wo sich VIA Onboard-Sound und aic7xxx ins Gehege kommen. Ich habe bereits mitbekommen, dass sich das hätte lösen lassen (man beachte den Konjunktiv der Vergangenheit), wenn man den aic7xxx aus der initrd nimmt und später nachladen lässt. (wenn man nur einen Scanner dranhängen hat, so wie ich). Sollte aber nicht wirklich stören, oder? Ré
Hallo, On Thu, 08 May 2003, René Matthäi wrote: [IRQ-Tabelle]
Keine Konflikte, außer vielleicht bei IRQ #10, USB mit IDE2 und 3. Man bedenke aber meine Tests mit KNOPPIX: Booten von /dev/hdc und keine Festplatten gemountet. Allerdings trotzdem den Promise im System, zugegebenermaßen (vielleicht hatte ich den aber sogar auch rausgezogen).
Haengt am Promise denn was dran?
# cat /proc/ioports [..] 9c00-9cff : VIA Technologies, Inc. VT82C686 AC97 Audio Controller 9c00-9cff : aic7xxx [..] Hier gibt es nur einen Konflikt an 9c00-9cff, wo sich VIA Onboard-Sound und aic7xxx ins Gehege kommen. Ich habe bereits mitbekommen, dass sich das hätte lösen lassen (man beachte den Konjunktiv der Vergangenheit), wenn man den aic7xxx aus der initrd nimmt und später nachladen lässt. (wenn man nur einen Scanner dranhängen hat, so wie ich). Sollte aber nicht wirklich stören, oder?
Doch. IO-Port Konflikte sind toedlich. Normal haengt sich die Kiste bei sowas direkt auf. Und wenn am aic7xxx eh nur ein Scanner haengt (der evtl. meist nicht mal eingeschaltet ist), dann gibt's keinen Grund, den aic7xxx in die initrd zu packen... -dnh --
...die cd's brennen indische kinder. Ach so. Ist das nicht gefährlich, so Kinder mit dem Lötkolben? Ach da sind genug da die sind austauschbar und es werden jeden tag neue produziert..... lötkolben meine ich jetzt ;) Henne und Bernd
Am Mittwoch, 7. Mai 2003 23:29 schrieb René Matthäi:
Da fällt mir ein: Es kann doch nicht etwa daran liegen, dass ich mehrere Software-RAIDs verwende? Ich hab massig Speicher, VIA KT133A, ^^^^^^^^^^ Sag mal, ist der KT133A nicht der Chipsatz mit dem Bug bei großer Busslast? Hast Du mal geschaut, ob da ein BIOS-Update für das Board zur Verfügung steht?
-- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hi, Manfred Tremmel schrieb:
^^^^^^^^^^ Sag mal, ist der KT133A nicht der Chipsatz mit dem Bug bei großer Busslast? Hast Du mal geschaut, ob da ein BIOS-Update für das Board zur Verfügung steht?
Ich schau grad mal, aber ich glaub 1., dass es für mein Epox 8kta3 kein neueres gibt und 2., dass mein Mitbewohner ein neueres BIOS hat. 3. taucht das Problem auch bei meinem Kumpel auf einem SiS-Chipsatz auf :-( Achso: 4. gehts unter Windows, aber das besteht ja angeblich hauptsächlich aus Blacklists... Ré
participants (4)
-
David Haller -
Florian Gross -
Manfred Tremmel -
René Matthäi