Pyun YongHyeon wrote: > 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: >>>> 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?
I am seeing the "Waiting 30s for the default route interface" consistently on boot. If I take no action, the NIC will not work. The 30s will timeout, and the boot will continue without a default route interface. Once I get a shell, I run `ifconfig msk0` and see: | media: Ethernet autoselect (1000baseT <full-duplex,flag0,flag1>) | status: active $ sudo tcpdump -nei msk0 not ether src host 00:16:cb:ae:5b:1f No packets will be captured though the broadcast domain is quite active (I'm excluding the ones that I'm attempting to send; I do see those). At this point, I physically disconnect and reconnect the cable. Immediately, the tcpdump begins showing output. Instead of allowing the "Waiting 30s" timer to expire, I can disconnect/reconnect the cable during the boot process. If I do that, the interface begins working, dhclient does its business, and the system boots fine. A day later, it's still working. -- Chris Cowart http://www.timesinks.net/
pgp5zyrQYe9zo.pgp
Description: PGP signature
