Cas driver fails to load first time after boot.

[Marius Strobl]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_cas.c.diff
Type: text/x-diff
Size: 2247 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20130125/508d5bea/attachment.diff>