Re: Yet another panic

Doug Ledford (dledford@dialnet.net)
Tue, 16 Jun 1998 16:53:11 -0500


Alan Cox wrote:

> > page fault from irq handler
> > CPU: 1
> > EIP: 0010:[<c01d8ad7>]
> > eax: 00000006 ebx: c0004874 ecx: c8800000 edx: 00000000
> > esi: c0004874 edi: 00000011 ebp: 00000246 esp: c0107ee0
> > ds == es == ss == 0018
> >
> > >>EIP: c01d8ad7 <pci_read_config_byte+f/24>
>
> This is called from aic_7xxx_pci_intr(p->pdev, PCI_STATUS, &status1)
>
> now &status1 is a stack address of a local value, p is presumably at
> least sensibly valid because p->pdev dereferences. What p->pdev points to
> I dont know but its probably still valid.

p->pdev points to the struct pci_device that we got back from
pci_find_device during the detect routine. It should never go away.

> You should worry at this point by the way. That function is called
> when the 2940 encounters a PCI error condition - such as a parity error.
> It could be something innocent like a PCI target abort when no PCI bus
> time is free.

It shouldn't be calling the BIOS according to my understanding of the pci
function changes. Specifically, pcibios_read_config_byte would call the
BIOS, but I was under the impression that the pci_read_config_byte didn't
call into the BIOS. Am I wrong on this one?

>
> What worries me about this one is pci_read_config_byte calls the PCI bios
> routines via a bios32 interrupt, from an IRQ handler for BIOS access.

> Yes, try the other PCI way of working and see if it behaves differently.

The other way should explicitly do what you are saying not to do. So, the
question now is, which one of us has things backwards in regards to what the
pci_* functions and pcibios_* functions do?

> BTW if folks are going to call pci functions from inside interrupt handlers
> someone really ought to make the arch/i386/kernel/bios32.c code for
> PCI direct and PCI bios access use spinlock_and_cli() and have a PCI config
> spinlock.
>
> Martin ?

-- 

Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu