Date: Mon, 7 Dec 2009 12:17:37 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Chris Cowart <ccowart@timesinks.net> Cc: freebsd-net@freebsd.org Subject: Re: msk link problems on 8.0 Message-ID: <20091207201737.GF1366@michelle.cdnetworks.com> In-Reply-To: <20091207194350.GB88840@marvin.timesinks.net> References: <20091207021746.GA86085@marvin.timesinks.net> <20091207185606.GD1366@michelle.cdnetworks.com> <20091207194350.GB88840@marvin.timesinks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 07, 2009 at 11:43:50AM -0800, Chris Cowart wrote:
> Pyun YongHyeon wrote:
> > On Sun, Dec 06, 2009 at 06:17:46PM -0800, Chris Cowart wrote:
> >> Having read the PR, I copied sys/dev/{msk,e1000} from HEAD into the
> >
> > I think the PR has nothing to do with this issue.
>
> You're right. I found it when I was hunting for an explanation to the
> hanging that seemed to come hand-in-hand with "Rx FIFO overrun" logs.
>
> >> 8.0-p1 source tree and installed the resulting kernel. The behavior
> >> did not change. If anyone has any alternative patching I could do,
> >> either against 8.0 or HEAD for these drivers, I'd be more than
> >> willing to try them out.
> >
> > There was a similar report on missing link state change and I think I
> > committed fix. Are you sure you used latest if_msk.c(r199413) in HEAD?
> > See if you have the following patch.
> > http://svn.freebsd.org/viewvc/base/head/sys/dev/msk/if_msk.c?r1=199012&r2=199413&view=patch
>
> I did get the file from HEAD, and I have verified that:
>
> | if ((sc_if->msk_flags & MSK_FLAG_LINK) == 0) |
> msk_miibus_statchg(sc_if->msk_if_dev);
>
> is in the patched kernel I built.
>
Ok.
> > > On a related note, last night, when the system did boot, I would
> > > also run into a problem where the following message would be logged:
> > > "msk0: Rx FIFO overrun!". Once logged, the NIC seemed to be
> > > completely wedged
> >
> > At least this indicates you didn't use latest msk(4) in HEAD because
> > the message was removed there.
>
> Sorry I was unclear on the chronology; I was seeing this behavior before
> I honed in on the link-state problem and built the msk(4) from HEAD.
>
> > > and unusable. Doing ifconfig down/up did not help things. At the
> > > time, I hadn't discovered the physical down/up workaround, so I
> > > can't speak to whether that would have helped (and this error
> > > condition hasn't recurred (knock on wood)). I don't know if
> > > the issues are related or
> >
> > I think it would be different issue, let's fix link state issue first.
>
> I think you're right that there are two issues here; I think I may have
> confused matters a little by intertwining my observations from both of
> them. Given that I've tried that patch and experienced the same link
> state behavior, is there something else I can try?
>
Hmm, that's strange. Let me summarize your issue.
You see "Waiting 30s for the default route interface" and you have
to wait until you finally got default route interface? Or does it
always time out for the default route interface and you always have
to wait 30 seconds?
Can msk(4) get an IP address via DHCP?
> Thanks,
>
> --
> Chris Cowart
> http://www.timesinks.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091207201737.GF1366>