NetBSD Problem Report #17956
Received: (qmail 25933 invoked by uid 605); 16 Aug 2002 11:11:38 -0000
Message-Id: <200208161111.g7GBBY700867@karo.kortex.jyu.fi>
Date: Fri, 16 Aug 2002 14:11:34 +0300 (EEST)
From: kaeesalm@cc.jyu.fi
Sender: gnats-bugs-owner@netbsd.org
Reply-To: kaeesalm@cc.jyu.fi
To: gnats-bugs@gnats.netbsd.org
Subject: qe0<->qe1 transfer freezes the system
X-Send-Pr-Version: 3.95
>Number: 17956
>Category: port-sparc
>Synopsis: qe0<->qe1 transfer freezes the system
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: port-sparc-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Aug 16 11:12:00 +0000 2002
>Closed-Date:
>Last-Modified: Tue Aug 20 18:04:01 +0000 2002
>Originator:
>Release: NetBSD 1.6_BETA5
>Organization:
>Environment:
System: NetBSD karo.kortex.jyu.fi 1.6_BETA5 NetBSD 1.6_BETA5 (experiment) #0: Sat Aug 10 17:37:23 EEST 2002 karo@experiment.kortex.jyu.fi:/opt/sources/src/sys/arch/sparc/compile/experiment sparc
Architecture: sparc
Machine: sparc
>Description:
I use qec SBus card, which has 4 ethernet slots. If I transfer data
through le0 (integrated Lance) and qe0 everything works fine, but if I
transfer data through qe0 and qe1 the transfer speed will stay at
600kB/s instead of the 1M/s (10Mbit/s) and the system loads will go up
to 5 and higher and the system really freezes. I use this machine as a
router/switch/firewall, so qe0 and qe1 are in different subnets.
/var/run/dmesg.boot:
NetBSD 1.6_BETA5 (experiment) #0: Sat Aug 10 17:37:23 EEST 2002
karo@experiment.kortex.jyu.fi:/opt/sources/src/sys/arch/sparc/compile/experi
ment
total memory = 65116 KB
avail memory = 57568 KB
using 839 buffers containing 3356 KB of memory
bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@3,
0
mainbus0 (root): SUNW,SPARCstation-4
cpu0 at mainbus0: MB86904 @ 110 MHz, on-chip FPU
cpu0: 16K instruction (32 b/l), 8K data (16 b/l): cache enabled
obio0 at mainbus0
clock0 at obio0 slot 0 offset 0x200000: mk48t08: hostid 807d8621
timer0 at obio0 slot 0 offset 0xd00000: delay constant 52
zs0 at obio0 slot 0 offset 0x100000 level 12 softpri 6
zstty0 at zs0 channel 0 (console i/o)
zstty1 at zs0 channel 1
zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6
kbd0 at zs1 channel 0: baud rate 1200
ms0 at zs1 channel 1: baud rate 1200
slavioconfig at obio0 slot 0 offset 0x800000 not configured
auxreg0 at obio0 slot 0 offset 0x900000
power0 at obio0 slot 0 offset 0x910000 level 2
fdc0 at obio0 slot 0 offset 0x400000 level 11 softpri 4: chip 82077
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
iommu0 at mainbus0 addr 0x10000000: version 0x4/0x0, page-size 4096, range 64MB
sbus0 at iommu0: clock = 22 MHz
dma0 at sbus0 slot 4 offset 0x8400000: dma rev 2
esp0 at dma0 slot 4 offset 0x8800000 level 4: ESP200, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets, 8 luns per target
bpp0 at sbus0 slot 4 offset 0xc800000 level 2 (ipl 3): dma rev 2
ledma0 at sbus0 slot 4 offset 0x8400010: dma rev 2
le0 at ledma0 slot 4 offset 0x8c00000 level 6: address 08:00:20:7d:86:21
le0: 8 receive buffers, 2 transmit buffers
qec0 at sbus0 slot 0 offset 0x20000 level 4 (ipl 7): 128K memory
qe0 at qec0 slot 0 offset 0x0 rev 1 address 08:00:20:7d:86:21
qe1 at qec0 slot 1 offset 0x0 rev 1 address 08:00:20:7d:86:21
qe2 at qec0 slot 2 offset 0x0 rev 1 address 08:00:20:7d:86:21
qe3 at qec0 slot 3 offset 0x0 rev 1 address 08:00:20:7d:86:21
tcx0 at sbus0 slot 2 offset 0x800000 level 5 (ipl 9): SUNW,tcx, 1152 x 900, id 0
, rev 2, sense 0
tcx0: attached to /dev/fb
power-management at sbus0 slot 3 offset 0xa000000 not configured
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 3 lun 0: <FUJITSU, M2954ESP SUN4.2G, 2545> SCSI2 0/direct
fixed
sd0: 4094 MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sect x 8385121 sectors
sd0: sync (100.0ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 6 lun 0: <TOSHIBA, XM-4101TASUNSLCD, 1755> SCSI2 5/cdrom
removable
cd0: async, 8-bit transfers
Kernelized RAIDframe activated
root on sd0a dumps on sd0b
root file system type: ffs
IP Filter: v3.4.27 initialized. Default = pass all, Logging = enabled
cpu0: NMI: system interrupts: 40000000<VME=0,SBUS=0,ME>
Kernel configuration can be found at http://www.cc.jyu.fi/~kaeesalm/experiment
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Karo Salminen <kaeesalm@cc.jyu.fi>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/17956
Date: Fri, 16 Aug 2002 19:59:07 +0300
Actually, the symptom only appears when transferring through qe0.
When I send data with high speed from a machine that is connected to qe0, the
sparc freezes. However, if I download something, it will act as normal.
This symptom doesn't appear with qe1 and the machine that is attached to it.
Both NICs(/machines) have the very same NAT rules.
From: Karo Salminen <karo@karo.kaista.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/17956
Date: Tue, 20 Aug 2002 11:08:58 +0300
I noticed that using a hub in qe0 and connecting my LAN to it, didn't
help a thing. The very same problem appears. Plus that, I looked at
netstat -id:
Name Mtu Network Address Ipkts Ierrs Opkts
Oerrs Colls Drops
le0 1500 <Link> 08:00:20:7d:86:21 520745 0 175770 0
3039 0
le0 1500 130.234.180/2 karo 520745 0 175770
0 3039 0
le0 1500 fe80:: fe80::a00:20ff:fe 520745 0 175770
0 3039 0
qe0 1500 <Link> 08:00:20:7d:86:21 95875 0 86414 26127
26112 0
qe0 1500 192.168 192.168.0.1 95875 0 86414 26127
26112 0
qe0 1500 fe80:: fe80::a00:20ff:fe 95875 0 86414
26127 26112 0
qe1* 1500 <Link> 08:00:20:7d:86:21 91159 0 121027 4896
4864 0
qe1* 1500 fe80:: fe80::a00:20ff:fe 91159 0 121027
4896 4864 0
qe1* 1500 0 0.0.0.0 91159 0
121027 4896 4864 0
Is the qec broken or what?
From: Karo Salminen <karo@karo.kaista.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-sparc/17956
Date: Tue, 20 Aug 2002 21:04:01 +0300
The following is a part of the message J. Wright send to port-sparc
mailinglist:
On the other hand, the sbus glue logic is buggy and requires an sbus
tick
between successive accesses to the mac and dma chip or it generates a
bus
fault. See revision 1.13 of sys/arch/sparc/dev/qe.c in OpenBSD for more
(ugly) details. I suspect this is the problem (the NetBSD driver was
imported from OpenBSD before this fix).
A whole message can be found at
http://mail-index.netbsd.org/port-sparc/2002/08/15/0017.html
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.