Re: [LinuxBIOS] i82801DB PCI Bridge locking up

Quoting Tom Sylla :
> 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, [e-mail]  wrote:
> > Quoting Peter Stuge :
> > > On Thu, Sep 13, 2007 at 02:40:16AM -0400,
> >
> > [e-mail] 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;
    ctrl |= (PCI_STATUS_SIG_SYSTEM_ERROR + PCI_STATUS_DETECTED_PARITY);
    pci_write_config16(dev, PCI_STATUS, ctrl);

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

pci_dev_enable_resources(dev);

enable_childrens_resources(dev);
}
-----------------------------------------------

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  
Bridges.

I will test it and get back.

Thanks - Joe