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.
IRQ Konflikte beseitigen
- MacGyver031
- Beiträge: 628
- Registriert: 18.08.2003 11:24:49
- Wohnort: Wiedlisbach, Schweiz
-
Kontaktdaten:
IRQ Konflikte beseitigen
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.
MacGyver
SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.
Re: IRQ Konflikte beseitigen
Das Zeugs im BIOS ist Wurstzipfel...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?
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 ?
- MacGyver031
- Beiträge: 628
- Registriert: 18.08.2003 11:24:49
- Wohnort: Wiedlisbach, Schweiz
-
Kontaktdaten:
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?
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.
MacGyver
SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.
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*
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*
- MacGyver031
- Beiträge: 628
- Registriert: 18.08.2003 11:24:49
- Wohnort: Wiedlisbach, Schweiz
-
Kontaktdaten:
Hallo,
So sieht er heute aus nach dem ich PNP OS =NO gestellt habe
Aber der ursprungliche problem
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.
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
bestand weiter hin.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
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.
MacGyver
SysInfo:
Intel Centrino 1.3GHz, 1GB, ATI M9, 1400x1050.
2.6.23, xorg-x11 7.2 Fluxbox 1.0.0 and many more.