> While digging through some of the /proc files, I stumbled across some
> interesting behavior in /proc/bus/pci. This doesn't seem to be very
> serious, as things recover just fine after a few seconds, and it only
> works as root, but reading a file in /proc/bus/pci/00 on my system (09.0
> in this case) causes my SCSI controller to flip. Here's the console
> messages from 2 succesive reads:
It is a known problem that has recently been discussed on the list.
I have explained the reason of the breakage and indicated my opinion
about this reading being dangerous even from root account.
Martin Mares stated that chips that get problems when reading their entire
config space are not PCI compliants and promised to tell us where the PCI
specifications state so. I am not surprised not to have received any
further explanation from him.
> ncr53c875J-0: SCSI parity error detected: SCR1=65 DBC=50000000 SSTAT1=f
> scsi : aborting command due to timeout : pid 75486, scsi0, channel 0, id 0, lun 0 Write (6) 04 14 e8 02 00
> ncr53c8xx_abort: pid=75486 serial_number=75544 serial_number_at_timeout=75544
[ ... ]
> I assume that the files correspond to irqs (I have a Diamond Fireport 40
> as the card that's complaining, plus a Compaq Symbios 53c875 card of some
> sort, and a Diamond G460 sharing irq 9). Motherboard is a Gigabyte
> 5AX (with an award bios that seems to like nothing more than
> throwing lots of devices on a single IRQ). Kernel is 2.1.125 with the ac1
> patch installed.
Your hardware is probably quite fine. Just never try to read more than the
first 64 bytes of PCI configuration space from any device, since the
remaining bytes are device specific and the PCI specifications does
explicitely required this space to be readable without side effects.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/