[LinuxBIOS] i82801DB PCI Bridge locking up

joe at smittys.pointclark.net joe at smittys.pointclark.net
Fri Sep 14 08:49:58 CEST 2007

Quoting Tom Sylla <tsylla at gmail.com>:

> Can you check the SERR and PERR status in the bridge before the
> enable? (they are in offset 1f of config space)  If you clear them
> first, does it help? We have a platform with a different southbridge
> where we find that to be the case (clearing the status bits first
> makes it not hang)
> On 9/13/07, joe at smittys.pointclark.net <joe at smittys.pointclark.net> wrote:
>> Quoting Peter Stuge <peter at stuge.se>:
>> > On Thu, Sep 13, 2007 at 02:40:16AM -0400,   
>> joe at smittys.pointclark.net wrote:
>> >> I wonder if my nic needs the pci rom to get it going, and this
>> >> would solve the problem?
>> >
>> > The ROM would be used much later in the init process, so no, it's not
>> > likely to help. :\
>> >
>> >
>> After a few tests I found the problem. It is locking up on this line:
>>         pci_write_config16(dev, PCI_COMMAND, command);
>> It is trying to write to the CMD(0x04) register of the PCI Bridge.
>> Looks like it is trying to write 0x0141. Setting the SERR# Enable
>> (SERR_EN), Parity Error Response (PER), and I/O Space Enable (IOSE).
>> I have no idea why this would cause a lock up??? I doesn't on any of
>> the other devices?? Could someone take a look at the i82801DB
>> datasheet and tell me if I am missing something?? Sometimes two (or
>> more) heads are better than one.
OK, I think I know what is going on here. When the  
pci_bus_enable_resources() function runs it sets the Parity Error  
Response Enable and SERR# Enable bits in the Bridge Control Register  
(0x3E). And then it goes to the pci_dev_enable_resources() function  
and Parity Error Response Enable and SERR# Enable bits in the Command  
Register (0x04). I found this in the datasheet:

BRIDGE_CNT?Bridge Control Register

SERR# Enable ? R/W.
0 = Disable
1 = If this bit is set AND bit 8 in CMD register (D30:F0 Offset 04h)  
is also set, the ICH4 will set the SSE bit in PD_STS register (D30:F0,  
offset 06h, bit 14) and also generate an NMI (or SMI# if NMI routed to  
SMI) when the SERR# signal is asserted.

So, I should just need to clear any parity and serr errors after  
pci_bus_enable_resources() function runs but before the  
pci_dev_enable_resources() function runs. Like this:

void pci_bus_enable_resources(struct device *dev)
	uint16_t ctrl;
	/* enable IO in command register if there is VGA card
	 * connected with (even it does not claim IO resource) */
	if (dev->link[0].bridge_ctrl & PCI_BRIDGE_CTL_VGA)
		dev->command |= PCI_COMMAND_IO;
	ctrl = pci_read_config16(dev, PCI_BRIDGE_CONTROL);
	ctrl |= dev->link[0].bridge_ctrl;
	ctrl |= (PCI_BRIDGE_CTL_PARITY + PCI_BRIDGE_CTL_SERR); /* error check */
	printk_debug("%s bridge ctrl <- %04x\n", dev_path(dev), ctrl);
	pci_write_config16(dev, PCI_BRIDGE_CONTROL, ctrl);

	/* Clear any signaled system and parity errors */
	ctrl = pci_read_config16(dev, PCI_STATUS);
	ctrl |= dev->ctrl;
	pci_write_config16(dev, PCI_STATUS, ctrl);

	ctrl = pci_read_config16(dev, PCI_SEC_STATUS);
	ctrl |= dev->ctrl;
	pci_write_config16(dev, PCI_SEC_STATUS, ctrl);



I think this should work?? If it does work, how does everyone feel  
about a patch for pci_device.c. This will effect alot of motherboards,  
I'm supprised it hasn't already been an issue with other Intel PCI  

I will test it and get back.

Thanks - Joe

More information about the coreboot mailing list