freebsd stable - Nov 2007 - re(4) lockups on a MSI K9AG Neo2-Digital (7.0-BETA3 amd64)

Hi,

I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in
amd64 mode at a german dedicated server provider.
The mainboard has a onboard re(4) ethernet controller. I experience a
very strange behaiviour:

When there are large transfers on the onboard SATA controller the re(4)
controller starts to have packet loss.

This packet loss does not stop when there is no more load on ata(4).
With another high load (like doing a full-system backup) the packet loss
keeps increasing up to 90% and more - the system is not accesible over
the internet anymore, packets get lost, SSH sessions or http requests
get stale, I have to restart the system.

I experience no kernel panics. Another (maybe related) problem that
occurs (but does not effect system responsiveness) is described in:
http://lists.freebsd.org/pipermail/freebsd-current/2007-November/080525.html

Here is some information about the system:

dmesg (boot -v):
http://test.vx.sk/MS-7368/dmesg.txt

pciconf -lcv:
http://test.vx.sk/MS-7368/pciconf.txt

dmidecode:
http://test.vx.sk/MS-7368/dmidecode.txt

I don't understand why this happens and would like to help debugging
this issue.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Matuska wrote:
> Hi,
>
> I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in
> amd64 mode at a german dedicated server provider.
> The mainboard has a onboard re(4) ethernet controller. I experience a
> very strange behaiviour:
I have a Neo-F and it does the same thing.... for a quick ref see
http://readlist.com/lists/freebsd.org/freebsd-current/9/47364.html....
it seems to have improved steadly as 8-current has been developed but
it is by no way fixed yet (even though I suggest switching to
8-current if you can afford the occasional down time from stuff not
working for short periods of time)
>
> When there are large transfers on the onboard SATA controller the re(4)
> controller starts to have packet loss.
Hum.... I see this when doing long heavy multi downloads.... but since
it is torrent it could be disk but I don't see a lot of disk
activity
>
> This packet loss does not stop when there is no more load on ata(4).
> With another high load (like doing a full-system backup) the packet loss
> keeps increasing up to 90% and more - the system is not accesible over
> the internet anymore, packets get lost, SSH sessions or http requests
> get stale, I have to restart the system.
I think this has been well confirmed for TCP but I wonder if there is
a good UDP test to see if UDP is effected also.
>
> I experience no kernel panics. Another (maybe related) problem that
> occurs (but does not effect system responsiveness) is described in:
*SOMETIMES* just rerunning ifconfig on re(4) will do it (question to
Pyun why does the routing table loose the default route when I do this
even if re0 keep the same ip?)


- --
Aryeh M. Friedman
Developer, not business, friendly
http://www.flosoft-systems.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHSoZeJ9+1V27SttsRArmkAJwIVuyC1by+iUvsRwulKgjVTBNFHgCfa9sP
FcpoMQvwCEOHXfQBuTpIFWU=kMm2
-----END PGP SIGNATURE-----

On Mon, Nov 26, 2007 at 09:10:43AM +0100, Martin Matuska wrote:
 > Hi,
 > 
 > I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in
 > amd64 mode at a german dedicated server provider.
 > The mainboard has a onboard re(4) ethernet controller. I experience a
 > very strange behaiviour:
 > 
 > When there are large transfers on the onboard SATA controller the re(4)
 > controller starts to have packet loss.
 > 
 > This packet loss does not stop when there is no more load on ata(4).
 > With another high load (like doing a full-system backup) the packet loss
 > keeps increasing up to 90% and more - the system is not accesible over
 > the internet anymore, packets get lost, SSH sessions or http requests
 > get stale, I have to restart the system.
 > 
 > I experience no kernel panics. Another (maybe related) problem that
 > occurs (but does not effect system responsiveness) is described in:
 >
http://lists.freebsd.org/pipermail/freebsd-current/2007-November/080525.html
 > 
 > Here is some information about the system:
 > 
 > dmesg (boot -v):
 > http://test.vx.sk/MS-7368/dmesg.txt
 > 
 > pciconf -lcv:
 > http://test.vx.sk/MS-7368/pciconf.txt
 > 
 > dmidecode:
 > http://test.vx.sk/MS-7368/dmidecode.txt
 > 
 > I don't understand why this happens and would like to help debugging

Me either. I have a WIP version that fixes other issues on re(4) but
I'm not sure whether it mitigates your issue. The overhauled re(4)
supports larger descriptors(256 instead of 64) and TSO.
http://people.freebsd.org/~yongari/re/if_re.c
http://people.freebsd.org/~yongari/re/if_rlreg.h

 > this issue.
 > 

-- 
Regards,
Pyun YongHyeon

On Mon, Nov 26, 2007 at 09:10:43AM +0100, Martin Matuska
wrote:
> Hi,
> 
> I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in
> amd64 mode at a german dedicated server provider.
> The mainboard has a onboard re(4) ethernet controller. I experience a
> very strange behaiviour:
Just for the record - I have almost the same hardware as Martin has, and
I had alike problems as described here.

You will be able to access my original problem report at:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-11/msg00675.html

Since that time, I have moved to the Intel NICs, as I haven't had time
to debug this issue. There are no more network problems that I am aware
of, although I am having issues with interrupt storms described in the
other email from Martin.

I am open to any debugging suggestions, I might be also able to arrange
a remote ssh access to the machine, just let me know.

-- 
S pozdravom / Best Regards,
  Daniel Gerzo

On Mon, Nov 26, 2007 at 09:10:43AM +0100, Martin Matuska
wrote:
> Hi,
> 
> I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in
> amd64 mode at a german dedicated server provider.
> The mainboard has a onboard re(4) ethernet controller. I experience a
> very strange behaiviour:
> 
> When there are large transfers on the onboard SATA controller the re(4)
> controller starts to have packet loss.
> 
> This packet loss does not stop when there is no more load on ata(4).
> With another high load (like doing a full-system backup) the packet loss
> keeps increasing up to 90% and more - the system is not accesible over
> the internet anymore, packets get lost, SSH sessions or http requests
> get stale, I have to restart the system.
One thing you could check is if the network cards are sharing an irq
with other hardware; "ps -xa | grep '\[irq'"

If so, you could try to enable device polling(4) with ifconfig. The
sysctl kern.polling.enable must be set to 1, and the kernel must be
compiled with 'options DEVICE_POLLING'.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20071126/efccacbb/attachment.pgp