| On Mon, 10 Dec 2001, Keith Warno wrote:
| > Any ideas? I really don't like the SCSI controller sharing an interrupt
| > with anyone but I can't seem to force it to be in its own land.
|
| If the controller is a separate board, not built onto the motherboard,
| move it to a different slot! There is only one interrupt line going
| to each PCI slot. This should move the IRQ to something else.
Yes in both cases it's a separate board. Been here, done this, and no
joy. This is what I meant by "I can't seem to force it to be in its own
land".
| In the same manner, if a board-mounted device is sharing an IRQ with
| some slot device, move the slot device to another slot or swap it with
| something that isn't using an interrupt.
Of course. Although not applicable in this case.
| Also, if your BIOS has an Y/N entry for (PnP OS), say "N". This
| will force the BIOS to more-properly allocate resources. This gives
| Linux at least a "correct" set-up to start with when it configures
| the PCI interface.
Yep. It's always set to No. I have little faith in this Plug 'n' Pray
OS jazz.
In both boxes the SCSI controller is sharing an interrupt with an AGP
NVidia board. Obviously I can't move the NVidia board. Shuffling the
SCSI controller around doesn't convince it not to share an IRQ with the
NVidia board. (I also have a PCI Linksys NIC and an SB Live on the same
interrupt. Go figure.)
The point here is I have not seen syslog messages like
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
in 2.4 kernels prior to 2.4.16. Perhaps an error was occuring with
those kernels and just wasn't being logged. Who knows. I'd just like
to know what specifically is causing this message to be emitted by the
kernel.
Regards,
kw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/