Date: Fri, 25 Jan 2013 17:19:16 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Paul Keusemann <pkeusem@visi.com> Cc: freebsd-net@freebsd.org Subject: Re: Cas driver fails to load first time after boot. Message-ID: <20130125161916.GV85306@alchemy.franken.de> In-Reply-To: <5101F264.7030206@visi.com> References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> <5101F264.7030206@visi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--mJm6k4Vb/yFcL9ZU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote:
>
> On 01/24/13 15:50, Marius Strobl wrote:
> > On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote:
> >> On 01/24/13 09:09, Marius Strobl wrote:
> >>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote:
> >>>> Hi,
> >>>>
> >>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun
> >>>> QGE (501-6738-10). The cas driver fails to load the first time I try to
> >>>> load it but succeeds the second time. Is this a problem with the card,
> >>>> the driver, my karma?
> >>> Wrong phase of the moon, apparently :)
> >>> The MII setup of these chips is a bit tricky and I'm not sure whether
> >>> I've hit all code paths during development of the driver. I certainly
> >>> didn't test with a 501-6738, these have been reported as working before,
> >>> though. It also doesn't make much sense that attaching the devices
> >>> succeeds on the second attempt. Could you please use a if_cas.ko built
> >>> with the attached patch and report the debug output for one of the
> >>> interfaces in both the working and the non-working case?
> >> I would love to give you output from the working and non-working case
> >> but apparently the phase of the moon has changed, I can't get it to fail
> >> now. The messages output from the working case is attached.
> >>
> > Thanks but unfortunately this doesn't make any sense either. In general,
> > printf()s cause deays which can be relevant. In the locations I've put
> > them they hardly can make such a difference though.
> > If you haven't already done so, could you please power off the machine
> > before doing the test with the patched module? Is the problem still gone
> > if you revert to the original module?
>
> OK, power-cycling makes a difference. The driver fails to attach all of
> the devices after power-cycling most of the time if not all of the
> time. The number of devices attached varies, the attached message file
> fragment is from my last test. Three of the devices were attached on
> the first load attempt and all four of them on the second attempt.
Okay, so we now at least have a way to reproduce the problem.
Unfortunately, it's still unclear what's the exact cause of it. At
least the problem is not what I suspected and hoped it most likely is.
Could you please test how things behave after a power-cycle with the
attached patche (after reverting the previous one).
Marius
--mJm6k4Vb/yFcL9ZU
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="if_cas.c.diff"
Index: if_cas.c
===================================================================
--- if_cas.c (revision 245046)
+++ if_cas.c (working copy)
@@ -214,8 +214,12 @@ cas_attach(struct cas_softc *sc)
error = ENXIO;
goto fail_ifnet;
}
- taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq",
+ error = taskqueue_start_threads(&sc->sc_tq, 1, PI_NET, "%s taskq",
device_get_nameunit(sc->sc_dev));
+ if (error != 0) {
+ device_printf(sc->sc_dev, "could not start threads\n");
+ goto fail_taskq;
+ }
/* Make sure the chip is stopped. */
cas_reset(sc);
@@ -339,10 +343,13 @@ cas_attach(struct cas_softc *sc)
BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE);
/* Enable/unfreeze the GMII pins of Saturn. */
if (sc->sc_variant == CAS_SATURN) {
- CAS_WRITE_4(sc, CAS_SATURN_PCFG, 0);
+ CAS_WRITE_4(sc, CAS_SATURN_PCFG,
+ CAS_READ_4(sc, CAS_SATURN_PCFG) &
+ ~CAS_SATURN_PCFG_FSI);
CAS_BARRIER(sc, CAS_SATURN_PCFG, 4,
BUS_SPACE_BARRIER_READ |
BUS_SPACE_BARRIER_WRITE);
+ DELAY(10000);
}
error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp,
cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK,
@@ -359,10 +366,12 @@ cas_attach(struct cas_softc *sc)
/* Freeze the GMII pins of Saturn for saving power. */
if (sc->sc_variant == CAS_SATURN) {
CAS_WRITE_4(sc, CAS_SATURN_PCFG,
+ CAS_READ_4(sc, CAS_SATURN_PCFG) |
CAS_SATURN_PCFG_FSI);
CAS_BARRIER(sc, CAS_SATURN_PCFG, 4,
BUS_SPACE_BARRIER_READ |
BUS_SPACE_BARRIER_WRITE);
+ DELAY(10000);
}
error = mii_attach(sc->sc_dev, &sc->sc_miibus, ifp,
cas_mediachange, cas_mediastatus, BMSR_DEFCAPMASK,
@@ -2865,7 +2874,7 @@ cas_pci_attach(device_t dev)
goto fail;
}
i = 0;
- if (lma > 1 && pci_get_slot(dev) < sizeof(enaddr) / sizeof(*enaddr))
+ if (lma > 1 && pci_get_slot(dev) < nitems(enaddr))
i = pci_get_slot(dev);
memcpy(sc->sc_enaddr, enaddr[i], ETHER_ADDR_LEN);
@@ -2874,7 +2883,7 @@ cas_pci_attach(device_t dev)
goto fail;
}
i = 0;
- if (phy > 1 && pci_get_slot(dev) < sizeof(pcs) / sizeof(*pcs))
+ if (phy > 1 && pci_get_slot(dev) < nitems(pcs))
i = pci_get_slot(dev);
if (pcs[i] != 0)
sc->sc_flags |= CAS_SERDES;
--mJm6k4Vb/yFcL9ZU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130125161916.GV85306>