Re: Yet another panic
Vadim E. Kogan (vadim@vadim.gem.net)
Sat, 13 Jun 1998 10:27:46 -0700
Alan Cox wrote:
>
> > BTW, I wonder if these 2 lines are good:
> > Jun 12 22:52:08 vadim kernel: PCI->APIC IRQ transform: (B1,I5,P0) -> 18
> > Jun 12 22:52:08 vadim kernel: PCI->APIC IRQ transform: (B0,I19,P0) -> 18
>
> Fine (irq sharing is valid in PCI)
just checking :)
>
> > 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.
>
> 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.
>
> 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.
>
Yeah, that's what I figured out. So I disabled PCI bridging :) And it
worked (and I posted message).
> > Main question: should I try using by BIOS now & report, or no need for
> > that info?
>
> Yes, try the other PCI way of working and see if it behaves differently.
>
> 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.
Hmm.. I'll look @ the code & try putting some spinlocks around.
>
> Martin ?
>
> Alan
Vadim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu