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