lkml.org 
[lkml]   [1998]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Yet another panic
Date
> 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)

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

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

Martin ?

Alan


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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.041 / U:3.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site