Date: Wed, 22 Aug 2001 07:41:46 +0200 From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de> To: Warner Losh <imp@harmony.village.org> Cc: David Malone <dwmalone@maths.tcd.ie>, walter@pelissero.org, John Baldwin <jhb@FreeBSD.ORG>, net@FreeBSD.ORG, hackers@FreeBSD.ORG, Andre Albsmeier <andre.albsmeier@mchp.siemens.de> Subject: Re: 4.4-RC NFS panic Message-ID: <20010822074146.A34016@curry.mchp.siemens.de> In-Reply-To: <200108211745.f7LHjCW66969@harmony.village.org>; from imp@harmony.village.org on Tue, Aug 21, 2001 at 11:45:12AM -0600 References: <200108210935.aa87782@salmon.maths.tcd.ie> <200108211745.f7LHjCW66969@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21-Aug-2001 at 11:45:12 -0600, Warner Losh wrote:
> In message <200108210935.aa87782@salmon.maths.tcd.ie> David Malone writes:
> : Andre Albsmeier, who's seeing various network problems, is using
> : the xe driver (also PCMCIA I think), but the problems go away if
> : he uses an Etherexpress card on the PCI bus of the same machine.
> :
> : It seems unlikely to be PCMCIA related ('cos it has nothing to do
> : with the networking itself) it may just be triggered in machines
> : with slower networking.
>
> After talking with Ian Dowse, I think that we've hammered out what may
> cause this. Basically, the problem is
>
> code in net doing splnet()
>
> <interrupt here> -> pcic_pci_intr -> netcard_intr -> network code.
>
> And we've interrupted the critical section, broken all kinds of
> invariants.
>
> Warner
>
> P.S. I think that with Ian's other interrupt changes, we can do the
> following w/o problems. This should fix the network problems, I
> think.
Runs perfectly for about 10 minutes now under full load. It didn't
survive 10 seconds before :-)
I still have the hangs on a warm reboot but this is a different
story...
Thanks a lot for the quick help!
-Andre
>
> Index: pcic_pci.c
> ===================================================================
> RCS file: /cache/ncvs/src/sys/pccard/pcic_pci.c,v
> retrieving revision 1.54.2.7
> diff -u -r1.54.2.7 pcic_pci.c
> --- pcic_pci.c 2001/08/21 09:06:25 1.54.2.7
> +++ pcic_pci.c 2001/08/21 17:18:06
> @@ -515,15 +515,6 @@
> * in the CD change.
> */
> sp->getb(sp, PCIC_STAT_CHG);
> -
> - /*
> - * If we have a card in the slot with an interrupt handler, then
> - * call it. Note: This means that each card can have at most one
> - * interrupt handler for it. Since multifunction cards aren't
> - * supported, this shouldn't cause a problem in practice.
> - */
> - if (sc->cd_present && sp->intr != NULL)
> - sp->intr(sp->argp);
> }
>
> /*
> @@ -784,36 +775,6 @@
> return (0);
> }
>
> -static int
> -pcic_pci_setup_intr(device_t dev, device_t child, struct resource *irq,
> - int flags, driver_intr_t *intr, void *arg, void **cookiep)
> -{
> - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev);
> - struct pcic_slot *sp = &sc->slots[0];
> -
> - if (sp->intr) {
> - device_printf(dev,
> -"Interrupt already established, possible multiple attach bug.\n");
> - return (EINVAL);
> - }
> - sp->intr = intr;
> - sp->argp = arg;
> - *cookiep = sc;
> - return (0);
> -}
> -
> -static int
> -pcic_pci_teardown_intr(device_t dev, device_t child, struct resource *irq,
> - void *cookie)
> -{
> - struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev);
> - struct pcic_slot *sp = &sc->slots[0];
> -
> - sp->intr = NULL;
> - sp->argp = NULL;
> - return (0);
> -}
> -
> static device_method_t pcic_pci_methods[] = {
> /* Device interface */
> DEVMETHOD(device_probe, pcic_pci_probe),
> @@ -829,8 +790,8 @@
> DEVMETHOD(bus_release_resource, bus_generic_release_resource),
> DEVMETHOD(bus_activate_resource, pcic_activate_resource),
> DEVMETHOD(bus_deactivate_resource, pcic_deactivate_resource),
> - DEVMETHOD(bus_setup_intr, pcic_pci_setup_intr),
> - DEVMETHOD(bus_teardown_intr, pcic_pci_teardown_intr),
> + DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
> + DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
>
> /* Card interface */
> DEVMETHOD(card_set_res_flags, pcic_set_res_flags),
--
BSD, from the people who brought you TCP/IP.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822074146.A34016>