From owner-freebsd-stable@FreeBSD.ORG Fri Jan 16 17:19:48 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E93416A4CE for ; Fri, 16 Jan 2004 17:19:48 -0800 (PST) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 237D243D48 for ; Fri, 16 Jan 2004 17:19:27 -0800 (PST) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smtp3.sentex.ca (8.12.10/8.12.10) with ESMTP id i0H1JKU7024739 for ; Fri, 16 Jan 2004 20:19:21 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.9p2/8.12.9) with ESMTP id i0H1JKXw029549 for ; Fri, 16 Jan 2004 20:19:20 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.0.1.1.0.20040116201535.08335f20@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Jan 2004 20:18:16 -0500 To: stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new Subject: strange VPN1401 HiFn issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 01:19:48 -0000 Not sure if this is a card, FreeBSD (RELENG_4), HiFn driver, or MB issue. Here is the setup. Using openssl on freebsd, I am doing something like /usr/bin/openssl enc -des3 -in sourcefile -k passphrase | ssh -c 3des user@offsite.sentex.ca "cat - > /backup/user/targetfile.enc" In the past, this worked great and I could blast the file across the network without too much CPU load using an older MB and the VPN1201 (HiFn 7951). We got some of the new VPN1401 cards this week based on the HiFN 7955 and we also upgraded the server to a faster CPU and more RAM. Now, if I start this process on the console, the process will block. If I then start an ssh session that uses a supported cipher (eg 3des) and then generate some traffic across that ssh session, the openssl session then continues. Or, if I run /usr/src/tools/tools/crypto/cryptotest, again, the openssl session blasts some data across, but then blocks once more. Or, if I stop generating traffic on the other ssh session, the openssl session blocks. Top reports the openssl process is in crydev. # ps -auxw -o flags -p 1249 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND F root 1249 0.0 0.1 2520 1452 p0 D+ 7:20PM 0:07.61 /usr/bin/openssl 4006 I dont see this behavior on ssh, as I can run scp between the two sites and the hifn card is for sure kicking in as hifnstats are incrementing and data flows at wirespeed. The hifn card does share an interrupt with the onboard video card. I dont think its a hardware issue as it would affect the scp sessions as well. Is there something in the way that openssl talks to the hifn card thats different than sshd that would cause it to block like this ? On Monday I can try the previous 7951 card to see if I can duplicate the behaviour. pci0: at 2.0 irq 5 hifn0 mem 0xe8510000-0xe8517fff,0xe8518000-0xe8519fff,0xe851a000-0xe851afff irq 5 at device 0.0 on pci1 twe0: <3ware Storage Controller> port 0xa000-0xa00f irq 15 at device 1.0 on pci1 dc0: port 0x9000-0x907f mem 0xe8440000-0xe84403ff irq 14 at device 4.0 on pci2 dc1: port 0x9400-0x947f mem 0xe8441000-0xe84413ff irq 12 at device 5.0 on pci2 dc2: port 0x9800-0x987f mem 0xe8442000-0xe84423ff irq 10 at device 6.0 on pci2 dc3: port 0x9c00-0x9c7f mem 0xe8443000-0xe84433ff irq 11 at device 7.0 on pci2 fwohci0: port 0xa400-0xa47f mem 0xe851b000-0xe851b7ff irq 11 at device 4.0 on pci1 pci0: (vendor=0x8086, dev=0x24c3) at 31.3 irq 15 atkbd0: irq 1 on atkbdc0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 Anyone else out there try these new cards yet ? # hifnstats input 2604791208 bytes 451359 packets output 2604787112 bytes 451358 packets invalid 0 nomem 0 abort 0 noirq 0 unaligned 0 totbatch 0 maxbatch 0 nomem: map 0 load 0 mbuf 0 mcl 0 cr 0 sd 0 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike