Kernel hangs on PCI config register access ???

Kernel hangs on PCI config register access ???

[Matthias Urlichs]

Hi,

we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang
when a PCMCIA card is removed from its PCI->PCMCIA interface via "cardctl
eject". Right *here*, in fact:

static int pci_conf1_read (int seg, int bus, int devfn, int reg, int
len, + u32 *value) {
    [...]
    case 2:
        debug("you see me \n");
        *value = inw(0xCFC + (reg & 2));
        debug("but you don't get here \n");
        break;
    [...]

Does anybody have *any* idea what could possibly be the cause of this?
Using pci=bios still hangs; pci=conf2 doesn't work.

FWIW, the call sequence is:

shutdown_socket
yenta_sock_init
yenta_clear_maps
yenta_set_socket
pci_bus_read_config_word
pci_conf1_read

The systems in question are wildly different (VIA vs. Intel CPUs, standard
mainboard vs. PCI backplane, Ricoh vs. ENE cardbus bridges), so I'm
inclined to rule out hardware problems. The NMI monitor doesn't trigger
(yes I tested it), kgdb is unresponsive -- the system hangs hard at that
point, as far as I can determine.

Kernel: tested with various 2.6.1? plus -rc* and/or -mm*, no change.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Re: Kernel hangs on PCI config register access ???

[Adam Belay]

On Fri, Feb 18, 2005 at 08:49:58AM +0100, Matthias Urlichs wrote:
> Hi,
> 
> we have a bunch of systems which semi-reproducibly (chance of 1:1000) hang
> when a PCMCIA card is removed from its PCI->PCMCIA interface via "cardctl
> eject". Right *here*, in fact:
> 
> static int pci_conf1_read (int seg, int bus, int devfn, int reg, int
> len, + u32 *value) {
>     [...]
>     case 2:
>         debug("you see me \n");
>         *value = inw(0xCFC + (reg & 2));
>         debug("but you don't get here \n");
>         break;
>     [...]
> 
> Does anybody have *any* idea what could possibly be the cause of this?
> Using pci=bios still hangs; pci=conf2 doesn't work.
> 
> FWIW, the call sequence is:
> 
> shutdown_socket
> yenta_sock_init
> yenta_clear_maps
> yenta_set_socket
> pci_bus_read_config_word
> pci_conf1_read
> 
> The systems in question are wildly different (VIA vs. Intel CPUs, standard
> mainboard vs. PCI backplane, Ricoh vs. ENE cardbus bridges), so I'm
> inclined to rule out hardware problems. The NMI monitor doesn't trigger
> (yes I tested it), kgdb is unresponsive -- the system hangs hard at that
> point, as far as I can determine.
> 
> Kernel: tested with various 2.6.1? plus -rc* and/or -mm*, no change.

Is this still an issue with recent kernels?

Where in the PCI configuration space is it reading?  In other words, could you
show me the line that calls pci_bus_read_config_word.

Thanks,
Adam