[LinuxBIOS] [v2][PATCH] PCI PERR# and SERR#
marc.jones at amd.com
Wed Sep 26 02:21:36 CEST 2007
I found this problem on the AMD Geode db800 platform but it probably
affects other platforms and chipsets. LinuxBIOS sets every PCI device
PERR# enable and SERR# enable in the PCI Command Register. This is
probably not the right thing to do for a number of reasons.
The PCI spec is not clear on what should be done with a PERR# it is a
device, chipset and platform design desicsion and we don't know what the
platform or device will do. For example, PERR# can be connected to SERR#
which can be connected to reset. Instead of just getting a parity error
you have now reset the system, oops.
Also, PERR# is required to be reported to system software. This has to
be done through the driver via an interrupt (or through polling, ewwww).
As you can see, a lot of pieces need to be in place, the device has to
do the interrupt, the driver should do something with the PERR#, and
then? I don't know if the kernel does anything with the PERR# message.
LinuxBIOS is no longer in play so it can't do anything with the errors.
Because of the uncertainty of PERR# and SERR# I don't think that many
manufacturers use it, especially in the consumer space. They may still
detect and fix parity errors at the hardware level or in their driver,
just not use the PERR# and SERR signals. Note that is a device does have
a parity error it will still report it in
As I noted above, the SERR# can cause a system reset. I think that it
would be better to do nothing and maybe the device will stop/hang/etc
rather than to mysteriously reset. Again, let the system software decide
All this seems like a good reason to let the driver and/or system level
software enable PERR# and SERR# and for LinuxBIOS to leave them alone.
Dissenting opinions welcome.
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the coreboot