fxp0: device timeout and sk0: watchdog timeout problems
Ganbold
ganbold at micom.mng.net
Wed Jan 18 22:14:22 PST 2006
I have same problem even after updating the sk code to the latest:
Jan 19 12:58:53 gw kernel: fxp0: device timeout
Jan 19 12:59:10 gw kernel: sk0: watchdog timeout
Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN
Jan 19 12:59:20 gw kernel: fxp0: device timeout
Jan 19 12:59:52 gw kernel: fxp0: device timeout
Jan 19 13:00:23 gw kernel: fxp0: device timeout
Jan 19 13:00:29 gw kernel: sk0: watchdog timeout
Jan 19 13:00:52 gw kernel: fxp0: device timeout
Jan 19 13:01:05 gw kernel: sk0: watchdog timeout
Ganbold
At 10:36 AM 1/18/2006, you wrote:
>On Wed, Jan 18, 2006 at 10:28:43AM +0800, Ganbold wrote:
> > At 09:55 AM 1/18/2006, you wrote:
> > > > inet 127.0.0.1 netmask 0xff000000
> > > >
> > > > I used new if_sk codes from Pyun YongHyeon but after 2 days I got
> > > > same problem device timeout.
> > > > fxp is also timing out and I don't know why.
> > > > Any idea?
> > > >
> > >
> > >If sk(4) is the cause of problem fxp wouldn't be affected.
> >
> > I guess so. But fxp also times out almost at same time as sk does.
> >
> > >Of course it's possible for sk(4) to corrupt kernel memory structure
> > >but the possibility is low. While fixing sk(4) I pushed sk(4) to the
> > >limit on sparc64. I never met such timeouts.
> > >
> > >atm I have no clue. How about updated sk(4)?
> > >http://people.freebsd.org/~yongari/sk/if_sk.c
> > >http://people.freebsd.org/~yongari/sk/if_skreg.h
> >
> > Is it new update? Because I used your update dated on Jan 12 2006. Is
> > it newer than that?
> >
>
>Yes.
>
> > >Disabling sk(4) remedy your issue?
> >
> > There is another on-board pcn NIC, I will try if problem exists with sk
> > driver.
> >
>Ok. Thank you.
>--
>Regards,
>Pyun YongHyeon
More information about the freebsd-stable
mailing list