NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/53814: wm0 device timeout in netbsd 7.1
The following reply was made to PR kern/53814; it has been noted by GNATS.
From: Aravind M <aravind.ss1094%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: kern/53814: wm0 device timeout in netbsd 7.1
Date: Mon, 31 Dec 2018 14:35:05 +0530
--000000000000331cd7057e4db69c
Content-Type: text/plain; charset="UTF-8"
Thanks for your assistance.
I'll add those options suggested and will get back on this.
Regards,
Aravind Mani
On Thu 27 Dec, 2018, 9:10 AM Masanobu SAITOH <msaitoh%execsw.org@localhost wrote:
> The following reply was made to PR kern/53814; it has been noted by GNATS.
>
> From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
> To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
> gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
> Cc: msaitoh%execsw.org@localhost
> Subject: Re: kern/53814: wm0 device timeout in netbsd 7.1
> Date: Thu, 27 Dec 2018 12:38:45 +0900
>
> On 2018/12/26 15:50, aravind.ss1094%gmail.com@localhost wrote:
> >> Number: 53814
> >> Category: kern
> >> Synopsis: wm0 device timeout in netbsd 7.1
> >> Confidential: no
> >> Severity: serious
> >> Priority: medium
> >> Responsible: kern-bug-people
> >> State: open
> >> Class: sw-bug
> >> Submitter-Id: net
> >> Arrival-Date: Wed Dec 26 06:50:00 +0000 2018
> >> Originator: Aravind Mani
> >> Release: netbsd 7.1
> >> Organization:
> > private organization
> >> Environment:
> > chip type: I354
> >> Description:
> > We use WM_T_I354 chip type.When we reload continuously,we could able to
> observe device timeout issue. wm_init(),wm_reset() doesn't help to recover
> from problem state.The only way to recover is to reload the switch.There
> was no initialization error.
> >>From wm_print_stats() and wm_pkt_stats(),i don't see any value in the
> registers listed and the packets are not hitting the hardware.
> > wm_reset also didn't help to recover the issue.
> >
> > Do you need any other output to investigate further?
> > Is there any other way to recover from this issue?.
> > Is there any other fix has been done around this area?.
> >
> >
> >
> >> How-To-Repeat:
> > Reload the switch continuously that runs with NetBSD 7.1.
> >> Fix:
> >
>
> Are you using modified version of if_wm.c? It has neither
> wm_print_stats()
> nor wm_pkt_stats().
>
> > Do you need any other output to investigate further?
>
> wm(4) has WM_EVENT_COUNTERS option, so it would be good to
> add "options WM_EVENT_COUNTERS" into your kernel configuration
> file and see vmstat -e.
>
> > Reload the switch continuously that runs with NetBSD 7.1.
>
> It's little hard to know what triggers the problem because
> I don't know what your switch implementation do in the reload.
>
> I have SGMII based C2000 machines. I've not tested on others
> (e.g. KX, PCIe SERDES or GMII). It would be good to check your
> PHY configuration and/or status if your system is not SGMII based.
>
>
> --
> -----------------------------------------------
> SAITOH Masanobu (msaitoh%execsw.org@localhost
> msaitoh%netbsd.org@localhost)
>
>
--000000000000331cd7057e4db69c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Thanks for your assistance.<div dir=3D"auto">I'll add=
those options suggested and will get back on this.<br><br><div data-smartm=
ail=3D"gmail_signature" dir=3D"auto">Regards,<br>Aravind Mani</div></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu 27 Dec, 2018, 9:=
10 AM Masanobu SAITOH <<a href=3D"mailto:msaitoh%execsw.org@localhost";>msaitoh@exe=
csw.org</a> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The following re=
ply was made to PR kern/53814; it has been noted by GNATS.<br>
<br>
From: Masanobu SAITOH <<a href=3D"mailto:msaitoh%execsw.org@localhost"; target=3D"_=
blank" rel=3D"noreferrer">msaitoh%execsw.org@localhost</a>><br>
To: gnats-bugs%NetBSD.org@localhost, <a href=3D"mailto:kern-bug-people%netbsd.org@localhost"; ta=
rget=3D"_blank" rel=3D"noreferrer">kern-bug-people%netbsd.org@localhost</a>,<br>
=C2=A0<a href=3D"mailto:gnats-admin%netbsd.org@localhost"; target=3D"_blank" rel=3D"no=
referrer">gnats-admin%netbsd.org@localhost</a>, <a href=3D"mailto:netbsd-bugs@netbsd.=
org" target=3D"_blank" rel=3D"noreferrer">netbsd-bugs%netbsd.org@localhost</a><br>
Cc: <a href=3D"mailto:msaitoh%execsw.org@localhost"; target=3D"_blank" rel=3D"noreferr=
er">msaitoh%execsw.org@localhost</a><br>
Subject: Re: kern/53814: wm0 device timeout in netbsd 7.1<br>
Date: Thu, 27 Dec 2018 12:38:45 +0900<br>
<br>
=C2=A0On 2018/12/26 15:50, <a href=3D"mailto:aravind.ss1094%gmail.com@localhost"; targ=
et=3D"_blank" rel=3D"noreferrer">aravind.ss1094%gmail.com@localhost</a> wrote:<br>
=C2=A0>> Number:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A053814<br>
=C2=A0>> Category:=C2=A0 =C2=A0 =C2=A0 =C2=A0kern<br>
=C2=A0>> Synopsis:=C2=A0 =C2=A0 =C2=A0 =C2=A0wm0 device timeout in ne=
tbsd 7.1<br>
=C2=A0>> Confidential:=C2=A0 =C2=A0no<br>
=C2=A0>> Severity:=C2=A0 =C2=A0 =C2=A0 =C2=A0serious<br>
=C2=A0>> Priority:=C2=A0 =C2=A0 =C2=A0 =C2=A0medium<br>
=C2=A0>> Responsible:=C2=A0 =C2=A0 kern-bug-people<br>
=C2=A0>> State:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 open<br>
=C2=A0>> Class:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sw-bug<br>
=C2=A0>> Submitter-Id:=C2=A0 =C2=A0net<br>
=C2=A0>> Arrival-Date:=C2=A0 =C2=A0Wed Dec 26 06:50:00 +0000 2018<br>
=C2=A0>> Originator:=C2=A0 =C2=A0 =C2=A0Aravind Mani<br>
=C2=A0>> Release:=C2=A0 =C2=A0 =C2=A0 =C2=A0 netbsd 7.1<br>
=C2=A0>> Organization:<br>
=C2=A0> private organization<br>
=C2=A0>> Environment:<br>
=C2=A0> chip type: I354<br>
=C2=A0>> Description:<br>
=C2=A0> We use WM_T_I354 chip type.When we reload continuously,we could =
able to observe device timeout issue. wm_init(),wm_reset() doesn't help=
to recover from problem state.The only way to recover is to reload the swi=
tch.There was no initialization error.<br>
=C2=A0>>From wm_print_stats() and wm_pkt_stats(),i don't see any =
value in the registers listed and the packets are not hitting the hardware.=
<br>
=C2=A0> wm_reset also didn't help to recover the issue.<br>
=C2=A0> <br>
=C2=A0> Do you need any other output to investigate further?<br>
=C2=A0> Is there any other way to recover from this issue?.<br>
=C2=A0> Is there any other fix has been done around this area?.<br>
=C2=A0> <br>
=C2=A0> <br>
=C2=A0> <br>
=C2=A0>> How-To-Repeat:<br>
=C2=A0> Reload the switch continuously that runs with NetBSD 7.1.<br>
=C2=A0>> Fix:<br>
=C2=A0> <br>
<br>
=C2=A0 =C2=A0Are you using modified version of if_wm.c? It has neither wm_p=
rint_stats()<br>
=C2=A0nor wm_pkt_stats().<br>
<br>
=C2=A0> Do you need any other output to investigate further?<br>
<br>
=C2=A0wm(4) has WM_EVENT_COUNTERS option, so it would be good to<br>
=C2=A0add "options WM_EVENT_COUNTERS" into your kernel configurat=
ion<br>
=C2=A0file and see vmstat -e.<br>
<br>
=C2=A0> Reload the switch continuously that runs with NetBSD 7.1.<br>
<br>
=C2=A0It's little hard to know what triggers the problem because<br>
=C2=A0I don't know what your switch implementation do in the reload.<br=
>
<br>
=C2=A0I have SGMII based C2000 machines. I've not tested on others<br>
=C2=A0(e.g. KX, PCIe SERDES or GMII). It would be good to check your<br>
=C2=A0PHY configuration and/or status if your system is not SGMII based.<br=
>
<br>
<br>
=C2=A0-- <br>
=C2=A0-----------------------------------------------<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SAITOH Masan=
obu (<a href=3D"mailto:msaitoh%execsw.org@localhost"; target=3D"_blank" rel=3D"norefer=
rer">msaitoh%execsw.org@localhost</a><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:msait=
oh%netbsd.org@localhost" target=3D"_blank" rel=3D"noreferrer">msaitoh%netbsd.org@localhost</a>)=
<br>
<br>
</blockquote></div>
--000000000000331cd7057e4db69c--
Home |
Main Index |
Thread Index |
Old Index