IRQ Konflikte beseitigen

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
Benutzeravatar
MacGyver031
Beiträge: 628
Registriert: 18.08.2003 11:24:49
Wohnort: Wiedlisbach, Schweiz
Kontaktdaten:

IRQ Konflikte beseitigen

Beitrag von MacGyver031 » 11.09.2003 14:58:40

Hallo,
Manchmal kommen komische SCSI-Fehlermeldungen folgender art:
scsi : aborting command due to timeout : pid 86641, scsi0, id 0, lun 0 Write (10) 00 00 06 59 a1 00 00 10 00
sym53c8xx_abort:pid=86641 serial_mumber=86642 serial_number_at_timeout=86642
SCSI host 0 abort (pid 86641) timed out -resetting
SCSI bus is being reset for host 0 channel 0
sym53c8xx_reset: pid=86641 reset_flags=2 serial_number=86642 serial_number_at_timeout=86642


Nun das ist nach meiner Meinung wegen der Geänderten Hardware nach der Installation von Linux.

wenn ich in /proc/interrupts aufrufe sehe ich eine interrupt sharing bei 5 (ide2, ide3, sym53c8xx) und 10 (usb-uchi, eth0)
die interrupts 9, 11,12 werden nicht belegt.

Ich habe im BIOS auf PNP OS = YES gestellt.

Meine Frage: Ist Linux PNP oder nPNP? Wie kann ich Manuell die IRQs einstellen?

Vielen dank.
Sincerely your
MacGyver

SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.

Benutzeravatar
zyta2k
Beiträge: 2446
Registriert: 14.03.2003 09:18:00
Kontaktdaten:

Re: IRQ Konflikte beseitigen

Beitrag von zyta2k » 11.09.2003 17:25:54

MacGyver031 hat geschrieben: Ich habe im BIOS auf PNP OS = YES gestellt.
Meine Frage:Ist Linux PNP oder nPNP? Wie kann ich Manuell die IRQs einstellen?
Das Zeugs im BIOS ist Wurstzipfel...
wenn man PNP=YES setzt wurstelt das BIOS dem Linux drein... drum PNP=NO (hat aber nix damit zu tun, dass Linux != PNP).

IRQ's werden vom Kernel automatisch (und in 99% der Fälle Korrekt zugeordnet - ganz im Gegensatz zu Windows *looool*)

Was hast du denn eingebaut / geändert ?

Benutzeravatar
MacGyver031
Beiträge: 628
Registriert: 18.08.2003 11:24:49
Wohnort: Wiedlisbach, Schweiz
Kontaktdaten:

Beitrag von MacGyver031 » 11.09.2003 17:43:12

Danke.

Ich habe zuerst nur SCSI-LWs gehabt und später kam die IDE0, IDE2 und IDE3 die nun im /proc/interrupts mit den SCSI-LWs konflikt verursachen. Zu dem hab ich die ganze Mainboard in ein grösseres Tower eingebaut, und dabei die Karten vermischt.

Ich habe bevor ich hier um hilfe bat, gesucht und keine Lösungsansatz gefunde, ABER es gab einen hinweis dass einige IRQs von mainboard reserviert werden. Toll finde ich dass trotz Konfliktes das System nicht abstützt!

Wenn ich PNP OS = NO setze, dann sollte die IRQ belegung automatisch korrekt sein?
Sincerely your
MacGyver

SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.

Benutzeravatar
zyta2k
Beiträge: 2446
Registriert: 14.03.2003 09:18:00
Kontaktdaten:

Beitrag von zyta2k » 11.09.2003 18:31:20

Yep...

Linux MUSS imho PnP=No gesetzt haben...

zu den Interrupts:
Eigentlich sollte es keine Probleme darstellen.
http://www.xml.com/ldd/chapter/book/ch09.html#t6


The notion of an IRQ conflict is almost synonymous with the PC architecture. In general, IRQ lines on the PC have not been able to serve more than one device, and there have never been enough of them. As a result, frustrated users have often spent much time with their computer case open, trying to find a way to make all of their hardware play well together.

But, in fact, there is nothing in the design of the hardware itself that says that interrupt lines cannot be shared.
The problems are on the software side. With the arrival of the PCI bus, the writers of system software have had to work a little harder, since all PCI interrupts can explicitly be shared. So Linux supports shared interrupts -- and on all buses where it makes any sense, not just the PCI. Thus, suitably aware drivers for ISA devices can also share an IRQ line.


*looool* drum gibts bei Win auch stetig Probs mit Interrupts
The problems are on the software side *huuuh* *hoooooh* :D

Benutzeravatar
MacGyver031
Beiträge: 628
Registriert: 18.08.2003 11:24:49
Wohnort: Wiedlisbach, Schweiz
Kontaktdaten:

Beitrag von MacGyver031 » 12.09.2003 20:42:55

Hallo,

So sieht er heute aus nach dem ich PNP OS =NO gestellt habe

Code: Alles auswählen

           CPU0
  0:    6609788          XT-PIC  timer
  1:      47227          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:    2387515          XT-PIC  usb-uhci, eth0
 10:    1237165          XT-PIC  ide2, ide3, sym53c8xx
 14:      87757          XT-PIC  ide0
NMI:          0
ERR:          0
Aber der ursprungliche problem
Manchmal kommen komische SCSI-Fehlermeldungen folgender art:
scsi : aborting command due to timeout : pid 86641, scsi0, id 0, lun 0 Write (10) 00 00 06 59 a1 00 00 10 00
sym53c8xx_abort:pid=86641 serial_mumber=86642 serial_number_at_timeout=86642
SCSI host 0 abort (pid 86641) timed out -resetting
SCSI bus is being reset for host 0 channel 0
sym53c8xx_reset: pid=86641 reset_flags=2 serial_number=86642 serial_number_at_timeout=86642
bestand weiter hin.

Da dank deiner "Entdeckung" denke ich weiss ich wer der Uebeltäter ist: CDROM 0

Seit dem ich diesen CDROM ausgesteckt habe, hab ich bis heute keine o.e. Fehlermeldung erhalten.

Ich danke dir sehr und wünsche dir einen schönen Sonntag.
Sincerely your
MacGyver

SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.

Antworten