From owner-freebsd-hackers@freebsd.org Mon May 9 18:49:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5106FB34268 for ; Mon, 9 May 2016 18:49:55 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8001198 for ; Mon, 9 May 2016 18:49:55 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id s8so99576324ign.0 for ; Mon, 09 May 2016 11:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=UkbWWBwAtJm+CxB/yVuWqV1GCSh4g3gZFexEKZLhbuk=; b=che5ajCi1+UZvN/UJfQIFO1LyjKjsO3L5eJoHqCu6cdZlwdIaq2InNSZQYi9VYb68y T0TMIUZL6boBuIY3Qa0H/VdPtXg4sYKABYMGjM23doC2tJ7UUFE9Fo7qo6LhQSLSFSXb NsY7anPGzGis9JaY2HSX70IaCqfg6meR+F69OXlTxIhkvFrc5InPtBWa51kvmA3eh0jx A26AkLWWvdyUXiuHmb14WekNY8chkR2v1GUx5lcIL1t6SFpmX5Tkum9lT4mp0vYOOiDu EJMRUbIBBotgfceBrkm34l/jWsuZLdOpsbW1twVmggLGpX5ECVgPuq9OD9oUikcDn5wg z5yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=UkbWWBwAtJm+CxB/yVuWqV1GCSh4g3gZFexEKZLhbuk=; b=a36k1AtAWnvZqG3kEnMl32TzcRqKM7V75DJPY33gB0fNIPEKtIOGi+vMM2oLhkIwV9 t5TZ1Ftbf3E99TTeZsarRBk1K52vayJKqCsx/e2T2zKnBmKWf7KYJxz+CVgjfzAwCFCj X+OjSCDqglf8oqXUx03wJXClw+A/udJ6MxN4dEQ26eolikmjoNX7nkXlC8HUiXS5tO36 gaD6U/rfJJVSZ40REE1HopXHoCoRxa1UCH1697hoggCULbpw5a9zQclRSNlbgNyvTtgY evryuIAkAGBUUxHk4lFXO2cmsJRT7SckgljWpERKePeFr0obTnFw2pB1FuD2iOaknaPj IwbQ== X-Gm-Message-State: AOPr4FUWawz6sTizVJnENF9dJS1HaASmi1tWaJuHYhraNZHpBwcPb2aw4KDgdvJu7sFlAwFkwCIPiE2ddscLUQ== MIME-Version: 1.0 X-Received: by 10.50.112.42 with SMTP id in10mr12322665igb.67.1462819794318; Mon, 09 May 2016 11:49:54 -0700 (PDT) Received: by 10.64.89.101 with HTTP; Mon, 9 May 2016 11:49:54 -0700 (PDT) Date: Mon, 9 May 2016 11:49:54 -0700 Message-ID: Subject: Re: TCP problems From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 18:49:55 -0000 Larry suggests: > Have you tried bumping the MTU on the interfaces to JUMBO frames? > 9000 or whatever max is? Easy enough to try, but 2 of the 4 max out at 1500. I suppose I could rewire the networks to get the 2 that allow 9000 on the same wire. But packet size seems unlikely to have anything to do with bind failing. And MTU=1500 is really supposed to work. I set ue0 to *smaller* mtu (500, 250, 100) and still got data corruption, along with rcp: lost connection Data connection: Operation timed out. (ftp) More on ue0's MTU below. Mark suggests: > Sounds like you may have fired the nic on the G box Which is why I tried both networks. Seems unlikely that both re0 *and* ue0 would fail with the same symptoms. Seems unlikely that bad nics would have anything to do with bind failing? Thank you both for your suggestions. ------------------- re0: New problem. One network got some strange ping times for awhile: 64 bytes from machine_G_re0: icmp_seq=2 ttl=64 time=0.355 ms 64 bytes from machine_G_re0: icmp_seq=3 ttl=64 time=2001.209 ms 64 bytes from machine_G_re0: icmp_seq=4 ttl=64 time=2001.219 ms 64 bytes from machine_G_re0: icmp_seq=5 ttl=64 time=1000.728 ms 64 bytes from machine_G_re0: icmp_seq=6 ttl=64 time=0.229 ms 64 bytes from machine_G_re0: icmp_seq=7 ttl=64 time=2001.091 ms 64 bytes from machine_G_re0: icmp_seq=8 ttl=64 time=2001.129 ms 64 bytes from machine_G_re0: icmp_seq=9 ttl=64 time=1000.643 ms 64 bytes from machine_G_re0: icmp_seq=10 ttl=64 time=0.149 ms 64 bytes from machine_G_re0: icmp_seq=11 ttl=64 time=2001.207 ms 64 bytes from machine_G_re0: icmp_seq=12 ttl=64 time=2001.211 ms 64 bytes from machine_G_re0: icmp_seq=13 ttl=64 time=1000.726 ms 64 bytes from machine_T_bge0: icmp_seq=0 ttl=64 time=423.415 ms 64 bytes from machine_T_bge0: icmp_seq=1 ttl=64 time=14491.793 ms 64 bytes from machine_T_bge0: icmp_seq=2 ttl=64 time=13490.387 ms 64 bytes from machine_T_bge0: icmp_seq=3 ttl=64 time=12489.373 ms 64 bytes from machine_T_bge0: icmp_seq=4 ttl=64 time=11488.635 ms 64 bytes from machine_T_bge0: icmp_seq=5 ttl=64 time=10487.481 ms 64 bytes from machine_T_bge0: icmp_seq=6 ttl=64 time=9486.493 ms 64 bytes from machine_T_bge0: icmp_seq=7 ttl=64 time=8485.567 ms Powered machine G down overnight and re0 mostly recovered. Still have the bind problem. Does bind have anything to do with the Ethernet hardware or device drivers? I'm guessing no. No clue as to why re0 was causing data corruption, or why the data corruption went away (that problem went away before the power down so it isn't that). Also no clue about what caused the long ping times, which went away after the power down. ------------------- ue0: Noticed that netstat was reporting input errors for ue0. And ue0 input was where the data corruption was happening. Sent data from machine A with 10Mbps Ethernet. Netstat did not report any input errors on ue0 and there was no data corruption. So ue0 can handle gigabit data rate, but gets input errors if packets arrive too frequently. # ifconfig ue0 media 100baseTX-FDX fixed the input error problem and the data corruption problem, at the expense of making it even slower. Max data rate seen (before lowering to 100Mbps) was about 35 MB/s which is said to be the effective rate of USB2. usbconfig says: ugen0.3: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) so I guess it really is running at USB3 speed. The chip performs a lot better for tweaktown: http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html (Vantec CB-U300GNA with the same Asix AX88179 chip) "full duplex gigabit with 952 Mbps consistently across the chart" Asix AX88179 chip: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 "Supports Jumbo frame up to 4KB" But ifconfig rejects any value > 1500: # ifconfig ue0 mtu 4000 ifconfig: ioctl (set mtu): Invalid argument # ifconfig ue0 mtu 1501 ifconfig: ioctl (set mtu): Invalid argument A quick look at the driver code didn't find a MTU limit. (But did in other Ethernet drivers.) Looks to me like axge(4) doesn't support a large MTU. IIRC, one should set ifconfig -rxcsum -txcsum to get maximum data integrity (at the expense of using more cpu). If the cpu were doing the checksums it should catch and correct the data corruption I'm getting since the corruption appears to be happening inside the Asix AX88179 chip. But: # ifconfig ue0 -rxcsum results in no Ethernet traffic # ifconfig ue0 -txcsum seems to work ok. (including no data corruption) Why am I not getting any Ethernet traffic with -rxcsum? I can see that some controllers might not have the hardware to support rxcsum, but it seems to me that -rxcsum and -txcsum should always work? # ifconfig re0 -rxcsum -txcsum seems to work ok. (including no data corruption) Is Asix AX88179 still the only USB to gigabit Ethernet chip? From owner-freebsd-hackers@freebsd.org Mon May 9 19:33:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 299AEB34712 for ; Mon, 9 May 2016 19:33:43 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C6B1E1C for ; Mon, 9 May 2016 19:33:42 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by mail-pf0-x22a.google.com with SMTP id 206so79811337pfu.0 for ; Mon, 09 May 2016 12:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackerdojo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RxZDc2Pt4l/NfqKLZLdGR00odZrakmHBhKr00007Wp0=; b=lMXGoTTBBF/Wije2XR+tY++lrhnYZZGWAAVRtBwzRH3DelOY3ym7VS2hf+b/xgdGsl b1oX9QK1DlzOySbWQm1bcPALXzk8XOZNT4P/1d21C2bcpKZhN6ymCpT8DmQoSJS+1vKl dJB29heJTWVli3JOx1CyLo8q3rbQCjrydwtZ9o9+2vod38N7/Yz4IPF8AjaC4GgH16ID WVVOzMVpwMgd2PjaGG5d7u83D/YWBn9iYIFfDt3M6v3JKVgLYWvXXaRoscM2FLt1vEBT ZvGAdbBhrv9AOdNsF04/q/lK2sb6xwv7m/s8B1kjbW8/dZCB/LyQE8plsxBbpJvBAN57 mQ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RxZDc2Pt4l/NfqKLZLdGR00odZrakmHBhKr00007Wp0=; b=Pl6UJJgGHu6ewwFLc3xasO5QaegatLREphinefcaH2GT3z9mnZkUy0qExNH7zwTCjD NJ3zsJyHgQfKunCLrLCM6oTwBV6IzL47fIQzGqt/7TGt0k9rPipikMEAgTJIYRBLsQU0 dGAjgeZ7MdY7wkzyqsCOMFiZrhoV+KLvrqcN+lljDIC4ThTX5K7VXgeTCJy3z3Xi289Z 4pJNTbPTyiU+kttZeUn4VQjaw7hv/dB4HALr09KskG71dCGSIVjzLBzywsIFVB1Hq7KB vp36QBDEdasdLubTbU6CZAbRvld3cRcELsRNvnp3uVzr5ahvfnTfc+r6EfiIu5fHbzKb M2qQ== X-Gm-Message-State: AOPr4FWNh8m75M07HTyzVWADqTaQcVPddaxmM9E6c+TUJKWQrRKsvH5GYX+q8O9IXeh7cKSy X-Received: by 10.98.95.71 with SMTP id t68mr48763220pfb.158.1462822421873; Mon, 09 May 2016 12:33:41 -0700 (PDT) Received: from ?IPv6:2601:647:4204:2b00:528:4042:cb2a:9e77? ([2601:647:4204:2b00:528:4042:cb2a:9e77]) by smtp.gmail.com with ESMTPSA id h16sm40766351pfj.0.2016.05.09.12.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 12:33:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TCP problems From: Larry Maloney X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Mon, 9 May 2016 12:33:38 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3754545C-B66D-4D40-BC92-FF1BA3D8B25D@hackerdojo.com> References: To: Dieter BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:33:43 -0000 Can you do a sysctl dump for each NIC to see their settings? /Larry Sent from my iPhone > On May 9, 2016, at 11:49 AM, Dieter BSD wrote: >=20 > Larry suggests: >> Have you tried bumping the MTU on the interfaces to JUMBO frames? >> 9000 or whatever max is? >=20 > Easy enough to try, but 2 of the 4 max out at 1500. I suppose I > could rewire the networks to get the 2 that allow 9000 on the > same wire. But packet size seems unlikely to have anything to do > with bind failing. And MTU=3D1500 is really supposed to work. >=20 > I set ue0 to *smaller* mtu (500, 250, 100) and still got data corruption, > along with > rcp: lost connection > Data connection: Operation timed out. (ftp) >=20 > More on ue0's MTU below. >=20 > Mark suggests: >> Sounds like you may have fired the nic on the G box >=20 > Which is why I tried both networks. Seems unlikely that both > re0 *and* ue0 would fail with the same symptoms. Seems unlikely > that bad nics would have anything to do with bind failing? >=20 > Thank you both for your suggestions. > ------------------- > re0: >=20 > New problem. One network got some strange ping times for awhile: >=20 > 64 bytes from machine_G_re0: icmp_seq=3D2 ttl=3D64 time=3D0.355 ms > 64 bytes from machine_G_re0: icmp_seq=3D3 ttl=3D64 time=3D2001.209 ms > 64 bytes from machine_G_re0: icmp_seq=3D4 ttl=3D64 time=3D2001.219 ms > 64 bytes from machine_G_re0: icmp_seq=3D5 ttl=3D64 time=3D1000.728 ms > 64 bytes from machine_G_re0: icmp_seq=3D6 ttl=3D64 time=3D0.229 ms > 64 bytes from machine_G_re0: icmp_seq=3D7 ttl=3D64 time=3D2001.091 ms > 64 bytes from machine_G_re0: icmp_seq=3D8 ttl=3D64 time=3D2001.129 ms > 64 bytes from machine_G_re0: icmp_seq=3D9 ttl=3D64 time=3D1000.643 ms > 64 bytes from machine_G_re0: icmp_seq=3D10 ttl=3D64 time=3D0.149 ms > 64 bytes from machine_G_re0: icmp_seq=3D11 ttl=3D64 time=3D2001.207 ms > 64 bytes from machine_G_re0: icmp_seq=3D12 ttl=3D64 time=3D2001.211 ms > 64 bytes from machine_G_re0: icmp_seq=3D13 ttl=3D64 time=3D1000.726 ms >=20 > 64 bytes from machine_T_bge0: icmp_seq=3D0 ttl=3D64 time=3D423.415 ms > 64 bytes from machine_T_bge0: icmp_seq=3D1 ttl=3D64 time=3D14491.793 ms > 64 bytes from machine_T_bge0: icmp_seq=3D2 ttl=3D64 time=3D13490.387 ms > 64 bytes from machine_T_bge0: icmp_seq=3D3 ttl=3D64 time=3D12489.373 ms > 64 bytes from machine_T_bge0: icmp_seq=3D4 ttl=3D64 time=3D11488.635 ms > 64 bytes from machine_T_bge0: icmp_seq=3D5 ttl=3D64 time=3D10487.481 ms > 64 bytes from machine_T_bge0: icmp_seq=3D6 ttl=3D64 time=3D9486.493 ms > 64 bytes from machine_T_bge0: icmp_seq=3D7 ttl=3D64 time=3D8485.567 ms >=20 > Powered machine G down overnight and re0 mostly recovered. > Still have the bind problem. Does bind have anything to do > with the Ethernet hardware or device drivers? I'm guessing no. >=20 > No clue as to why re0 was causing data corruption, or why the > data corruption went away (that problem went away before the power down > so it isn't that). Also no clue about what caused the long ping times, > which went away after the power down. >=20 > ------------------- > ue0: >=20 > Noticed that netstat was reporting input errors for ue0. > And ue0 input was where the data corruption was happening. > Sent data from machine A with 10Mbps Ethernet. Netstat > did not report any input errors on ue0 and there was no data > corruption. >=20 > So ue0 can handle gigabit data rate, but gets input errors if > packets arrive too frequently. >=20 > # ifconfig ue0 media 100baseTX-FDX > fixed the input error problem and the data corruption problem, > at the expense of making it even slower. >=20 > Max data rate seen (before lowering to 100Mbps) was about 35 MB/s > which is said to be the effective rate of USB2. >=20 > usbconfig says: > ugen0.3: at usbus0, cfg=3D0 md=3DHOST spd=3DSUP= ER > (5.0Gbps) pwr=3DON (124mA) >=20 > so I guess it really is running at USB3 speed. >=20 > The chip performs a lot better for tweaktown: > http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-netw= ork-adapter-review/index.html > (Vantec CB-U300GNA with the same Asix AX88179 chip) > "full duplex gigabit with 952 Mbps consistently across the chart" >=20 > Asix AX88179 chip: > http://www.asix.com.tw/products.php?op=3DpItemdetail&PItemID=3D131;71;112 > "Supports Jumbo frame up to 4KB" >=20 > But ifconfig rejects any value > 1500: >=20 > # ifconfig ue0 mtu 4000 > ifconfig: ioctl (set mtu): Invalid argument > # ifconfig ue0 mtu 1501 > ifconfig: ioctl (set mtu): Invalid argument >=20 > A quick look at the driver code didn't find a MTU limit. (But did in othe= r > Ethernet drivers.) Looks to me like axge(4) doesn't support a large MTU. >=20 > IIRC, one should set ifconfig -rxcsum -txcsum to get maximum data > integrity (at the expense of using more cpu). If the cpu were doing > the checksums it should catch and correct the data corruption I'm > getting since the corruption appears to be happening inside the > Asix AX88179 chip. But: >=20 > # ifconfig ue0 -rxcsum > results in no Ethernet traffic > # ifconfig ue0 -txcsum > seems to work ok. (including no data corruption) >=20 > Why am I not getting any Ethernet traffic with -rxcsum? I can see that > some controllers might not have the hardware to support rxcsum, but it > seems to me that -rxcsum and -txcsum should always work? >=20 > # ifconfig re0 -rxcsum -txcsum > seems to work ok. (including no data corruption) >=20 > Is Asix AX88179 still the only USB to gigabit Ethernet chip? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon May 9 19:35:19 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8528B34839 for ; Mon, 9 May 2016 19:35:19 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99F5D1F73 for ; Mon, 9 May 2016 19:35:19 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by mail-pa0-x22c.google.com with SMTP id bt5so75254493pac.3 for ; Mon, 09 May 2016 12:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackerdojo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wK/D/qa+M4HHRlZuWDbg9XbmIHNRbqZs5jd/IWFqy2g=; b=wIFEW2E37RwKQGoVyLHsj1PalBOaJT+jrePS9/S1GPHTBIwY5tzM9xAIw+xjkMwQnA sZrTYF6GbQZ7G6YleT/SsA7CeQpaHykNYgi8eXcSiZ0KSNH95viJ7r36rGeL2329LiOJ iFkFPV2GpKp3po/5SMuU+55h2kaBItJe2kVnfKIPxDXT1ABJV4r8BP+FNLcc450Tmk7T x5LMlC7ipHma6jJu2spMaxsC2yhWhR43RiHuFpMvgzFS4hDRvo+upqXueehGJNpilKB6 PB9esQWTDY+QGU9JEJ019sQzRHqD5WMCTECiYrJO1BCn/Ee4Awl1gmLJLNCT2esB0eQe sN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wK/D/qa+M4HHRlZuWDbg9XbmIHNRbqZs5jd/IWFqy2g=; b=jh8Jn6ItAKI3UiqRB6znSvNxaqMOUwvRmCeDVwAA5FwN55L9G60jCBi6sSZn0sN6Gm jp8cSkhLBver4wo2TiTiplvStsmnKu+UHO54GWqrB7ezVxFtJpeG4NjlFpRlQSic2E2x 6hu/IlzEjQjd6PryDvKnA3RK7B85X2e9Mdhx4We0GJRZpeo9fg8siaaXADHo/eyQ64P2 2F9w9O6tFt+8PYnOCZJOCcxiO4qs2hMtyTWDDSwn3v+qKw1OPP8UJP3CWfe+EuT/8Lxw h6NyKzAhjDJC3oFJ7PFBKmKaRE7zTyxFeCZQ9htaiowNM45AtZnj0JmMn0GT/zzB3EL4 iXAA== X-Gm-Message-State: AOPr4FWO69wqcJZtkSx93fGaCtHD1+5znMRlmJPimlA4WAEUejnWtaMQlFXn/ZnOp41ZDgRy X-Received: by 10.66.65.133 with SMTP id x5mr53120425pas.108.1462822519244; Mon, 09 May 2016 12:35:19 -0700 (PDT) Received: from ?IPv6:2601:647:4204:2b00:528:4042:cb2a:9e77? ([2601:647:4204:2b00:528:4042:cb2a:9e77]) by smtp.gmail.com with ESMTPSA id h16sm40770948pfj.0.2016.05.09.12.35.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2016 12:35:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TCP problems From: Larry Maloney X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Mon, 9 May 2016 12:35:16 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dieter BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:35:19 -0000 Keep in mind, if you are going through a switch, you may need to bump the sw= itch's MTU too if you want to try jumbo frames. Are these machines direct connected? /Larry Sent from my iPhone > On May 9, 2016, at 11:49 AM, Dieter BSD wrote: >=20 > Larry suggests: >> Have you tried bumping the MTU on the interfaces to JUMBO frames? >> 9000 or whatever max is? >=20 > Easy enough to try, but 2 of the 4 max out at 1500. I suppose I > could rewire the networks to get the 2 that allow 9000 on the > same wire. But packet size seems unlikely to have anything to do > with bind failing. And MTU=3D1500 is really supposed to work. >=20 > I set ue0 to *smaller* mtu (500, 250, 100) and still got data corruption, > along with > rcp: lost connection > Data connection: Operation timed out. (ftp) >=20 > More on ue0's MTU below. >=20 > Mark suggests: >> Sounds like you may have fired the nic on the G box >=20 > Which is why I tried both networks. Seems unlikely that both > re0 *and* ue0 would fail with the same symptoms. Seems unlikely > that bad nics would have anything to do with bind failing? >=20 > Thank you both for your suggestions. > ------------------- > re0: >=20 > New problem. One network got some strange ping times for awhile: >=20 > 64 bytes from machine_G_re0: icmp_seq=3D2 ttl=3D64 time=3D0.355 ms > 64 bytes from machine_G_re0: icmp_seq=3D3 ttl=3D64 time=3D2001.209 ms > 64 bytes from machine_G_re0: icmp_seq=3D4 ttl=3D64 time=3D2001.219 ms > 64 bytes from machine_G_re0: icmp_seq=3D5 ttl=3D64 time=3D1000.728 ms > 64 bytes from machine_G_re0: icmp_seq=3D6 ttl=3D64 time=3D0.229 ms > 64 bytes from machine_G_re0: icmp_seq=3D7 ttl=3D64 time=3D2001.091 ms > 64 bytes from machine_G_re0: icmp_seq=3D8 ttl=3D64 time=3D2001.129 ms > 64 bytes from machine_G_re0: icmp_seq=3D9 ttl=3D64 time=3D1000.643 ms > 64 bytes from machine_G_re0: icmp_seq=3D10 ttl=3D64 time=3D0.149 ms > 64 bytes from machine_G_re0: icmp_seq=3D11 ttl=3D64 time=3D2001.207 ms > 64 bytes from machine_G_re0: icmp_seq=3D12 ttl=3D64 time=3D2001.211 ms > 64 bytes from machine_G_re0: icmp_seq=3D13 ttl=3D64 time=3D1000.726 ms >=20 > 64 bytes from machine_T_bge0: icmp_seq=3D0 ttl=3D64 time=3D423.415 ms > 64 bytes from machine_T_bge0: icmp_seq=3D1 ttl=3D64 time=3D14491.793 ms > 64 bytes from machine_T_bge0: icmp_seq=3D2 ttl=3D64 time=3D13490.387 ms > 64 bytes from machine_T_bge0: icmp_seq=3D3 ttl=3D64 time=3D12489.373 ms > 64 bytes from machine_T_bge0: icmp_seq=3D4 ttl=3D64 time=3D11488.635 ms > 64 bytes from machine_T_bge0: icmp_seq=3D5 ttl=3D64 time=3D10487.481 ms > 64 bytes from machine_T_bge0: icmp_seq=3D6 ttl=3D64 time=3D9486.493 ms > 64 bytes from machine_T_bge0: icmp_seq=3D7 ttl=3D64 time=3D8485.567 ms >=20 > Powered machine G down overnight and re0 mostly recovered. > Still have the bind problem. Does bind have anything to do > with the Ethernet hardware or device drivers? I'm guessing no. >=20 > No clue as to why re0 was causing data corruption, or why the > data corruption went away (that problem went away before the power down > so it isn't that). Also no clue about what caused the long ping times, > which went away after the power down. >=20 > ------------------- > ue0: >=20 > Noticed that netstat was reporting input errors for ue0. > And ue0 input was where the data corruption was happening. > Sent data from machine A with 10Mbps Ethernet. Netstat > did not report any input errors on ue0 and there was no data > corruption. >=20 > So ue0 can handle gigabit data rate, but gets input errors if > packets arrive too frequently. >=20 > # ifconfig ue0 media 100baseTX-FDX > fixed the input error problem and the data corruption problem, > at the expense of making it even slower. >=20 > Max data rate seen (before lowering to 100Mbps) was about 35 MB/s > which is said to be the effective rate of USB2. >=20 > usbconfig says: > ugen0.3: at usbus0, cfg=3D0 md=3DHOST spd=3DSUP= ER > (5.0Gbps) pwr=3DON (124mA) >=20 > so I guess it really is running at USB3 speed. >=20 > The chip performs a lot better for tweaktown: > http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-netw= ork-adapter-review/index.html > (Vantec CB-U300GNA with the same Asix AX88179 chip) > "full duplex gigabit with 952 Mbps consistently across the chart" >=20 > Asix AX88179 chip: > http://www.asix.com.tw/products.php?op=3DpItemdetail&PItemID=3D131;71;112 > "Supports Jumbo frame up to 4KB" >=20 > But ifconfig rejects any value > 1500: >=20 > # ifconfig ue0 mtu 4000 > ifconfig: ioctl (set mtu): Invalid argument > # ifconfig ue0 mtu 1501 > ifconfig: ioctl (set mtu): Invalid argument >=20 > A quick look at the driver code didn't find a MTU limit. (But did in othe= r > Ethernet drivers.) Looks to me like axge(4) doesn't support a large MTU. >=20 > IIRC, one should set ifconfig -rxcsum -txcsum to get maximum data > integrity (at the expense of using more cpu). If the cpu were doing > the checksums it should catch and correct the data corruption I'm > getting since the corruption appears to be happening inside the > Asix AX88179 chip. But: >=20 > # ifconfig ue0 -rxcsum > results in no Ethernet traffic > # ifconfig ue0 -txcsum > seems to work ok. (including no data corruption) >=20 > Why am I not getting any Ethernet traffic with -rxcsum? I can see that > some controllers might not have the hardware to support rxcsum, but it > seems to me that -rxcsum and -txcsum should always work? >=20 > # ifconfig re0 -rxcsum -txcsum > seems to work ok. (including no data corruption) >=20 > Is Asix AX88179 still the only USB to gigabit Ethernet chip? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Mon May 9 21:57:08 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93A4BB358D8 for ; Mon, 9 May 2016 21:57:08 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C9901EE2 for ; Mon, 9 May 2016 21:57:08 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-ig0-x235.google.com with SMTP id s8so103561178ign.0 for ; Mon, 09 May 2016 14:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=5L3bXoH+xF7QZb2CKSzm1V4TFN+K88UHeDtsvzc5jq4=; b=0eJjIoN3BEcy77yYiSKqcpnAjXK1mc4eH7MUHB5s1WSAYN0hb4/R4Shk1M3/6tl82S v1p+Of+k1lCLBn8Wyfzov2zmQI256TYEGdSKfUjGm3jhvPf9SbcjdCcFLPI3MWQmrgn+ g4bm+iDpSEuU6YzLRve+F3wFVMTXchLhuDIx0YiVVA7oO9KEL8M3tDPtAvH6Luo45veN 0ROF+H9ZoRBVneSAUCpLlNyJUmtEDaDQtuBqNCQB4hYjH3jTnThU8qb+I+wRZRvPuQSO xz3Hy93wMeQk3ARA/07kO6bksnLNu/9yvxJu1vIFy/lmMpSPvoRv7VK+i3sebcTt5lRm GXOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=5L3bXoH+xF7QZb2CKSzm1V4TFN+K88UHeDtsvzc5jq4=; b=a0MgBp+lhsYAL7FMY5/G6A48j2tJ/XoFVnj+TY5WTkuumhm2tf77i4GdyFVGdU8aCX gPfPY/Le+eveQKh37c8/5pL3KTFjwIa4La98uC55ScCRqJIZnGhwx5rVutOdWOgSyzGk WNCL0E7RriRr37/A8nyRNRKF3dtELLOJ8E0YXrj59oP8QdzZlOdTEBzHeJeHnF+4uKuS zMx7dHdmUhSPW6rAg2EcSYvjerRx4eDpk+dkyrAXc7AAe0n53gZW3WzyBvZsVaRZQgAy qgMbf+YTcK1fWFCffels6s+WbkZiYdWiyu7B5937u1IFKaei5DUi+okIE9zoHP73snCv ib1A== X-Gm-Message-State: AOPr4FVG6BKOwhKe1ev0Wnb+ztSmCqVYPCXuPizvEhMRdflRnhwNpWPLBzjhE8OuzypUVATqk7mCWnn8Str7Og== MIME-Version: 1.0 X-Received: by 10.50.34.130 with SMTP id z2mr12861504igi.82.1462831027745; Mon, 09 May 2016 14:57:07 -0700 (PDT) Received: by 10.64.89.101 with HTTP; Mon, 9 May 2016 14:57:07 -0700 (PDT) Date: Mon, 9 May 2016 14:57:07 -0700 Message-ID: Subject: Re: TCP problems From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 21:57:08 -0000 Larry: > Can you do a sysctl dump for each NIC to see their settings? # sysctl -a | grep re0 dev.miibus.0.%parent: re0 dev.amdtemp.0.core0.sensor0: 16.2C # sysctl -a | grep ue0 # Hmmmm, 16.2 degrees C = 61.16 degrees F Seems very unlikely. Somehow I don't think this is what you had in mind? ifconfig says: re0: flags=8843 metric 0 mtu 1500 options=82098 media: Ethernet autoselect (1000baseT ) ue0: flags=8843 metric 0 mtu 1500 options=80009 media: Ethernet 100baseTX > Keep in mind, if you are going through a switch, you may need to bump > the switch's MTU too if you want to try jumbo frames. Are these machines > direct connected? G_re0 ----- Netgear GS116 --- Netgear GS108 --- T_bge0 --- A_tlp0 NetBSD/alpha tulip 10 Mbps G_ue0 ----- Netgear GS108 --- T_nfe0 http://www.downloads.netgear.com/files/GDC/datasheet/en/GS116v2.pdf doesn't seem to be sure about the MTU: page 1 says 9 KB page 2 says 16 KB But ifconfig refuses to increase MTU for ue0, so... From owner-freebsd-hackers@freebsd.org Wed May 11 03:12:09 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7507B368F4 for ; Wed, 11 May 2016 03:12:09 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD3A11A6; Wed, 11 May 2016 03:12:09 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9] (unknown [IPv6:2001:470:1f11:617:8fe:6a13:797b:e9c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id B09711FA4; Wed, 11 May 2016 03:12:08 +0000 (UTC) References: <65BAB92F-271C-489F-A804-6496B4953599@metricspace.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4F645FB4-BA35-4F0F-9EE0-C1167696E135@metricspace.net> Cc: "freebsd-hackers@freebsd.org" X-Mailer: iPad Mail (13D15) From: Eric McCorkle Subject: Re: Problem with objcopy corrupting section names Date: Tue, 10 May 2016 23:12:07 -0400 To: Ed Maste X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 03:12:09 -0000 I've been head-down in my boot/loader project (as well as at work), but I've= basically confirmed that this is an issue with the tool chain. I can repro= duce it reliably, and I have a workaround. It seems to manifest when the -j= option is used and some sections are omitted. My changes are pulling the filesystem backend code over from loader into boo= t, which seemed to add some new sections. There's a simple enough workaround though (don't omit sections), and I want t= o keep up my current momentum on this stuff. I'll circle back around once I= 've got this project ready for testing. > On May 4, 2016, at 09:23, Ed Maste wrote: >=20 >> On 2 May 2016 at 18:25, Eric McCorkle wrote: >>=20 >> I've run into a weird problem where the section names are seemingly being= corrupted for boot1. The process to reproduce this should be simple: just b= uild boot1 and then do objdump -x boot1.efi and you should see that the sect= ion names are corrupted. >=20 > This could well be a bug in elfcopy's libpe - it's a new addition to > the ELF Tool Chain project, and I have not tested it extensively > outside of the plain boot1.efi and loader.efi. To confirm my > understanding, this happens with your patched tree, but not stock > FreeBSD? Also, in what way are they corrupted? It's expected that > section will be truncated, as the COFF format only supports char[8] > for the name. >=20 > If you mail me (off-list) a copy of boot1.sym I'll take a look. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Wed May 11 20:09:16 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7716AB37BE2 for ; Wed, 11 May 2016 20:09:16 +0000 (UTC) (envelope-from dsiluanius@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13E8510F3 for ; Wed, 11 May 2016 20:09:16 +0000 (UTC) (envelope-from dsiluanius@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id g17so101431712wme.1 for ; Wed, 11 May 2016 13:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GYmSrk0DfwbwpqRdMp+hOzJiqdfcUy7wododfB6Qjk0=; b=EYx1qf3OGJ4DWThwWUz0qs/3cquMu/caeoipccUzBT02bJl0/lZ5kbR7aQxf3GAi1C /tKqFyoWaaIagJqyj/dUt8cQe1Xid7hx2O0IlZQnT9DH9H/Ycgi3s7iW7YmdIvsDpDj5 Acjf0XnqfQAwPXU2XQvzEC5IFV02Dm6s4V/yKz1Rq6nNdXIJAG7AF4tNoYRxqurXxmEO 5KeVxeKoBSzWbQLATgiBMhv3f282geIP2JRWYf6ZZ8+CWhFCYxDKJdQ2HuMueDjUHdMd HNnZUsSnjiTG52+6TKNx0tXLrZpT5tqK0Mh89KVbwPGY3BJXyKJZxMNXBTm3zfXWMKvd u1DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GYmSrk0DfwbwpqRdMp+hOzJiqdfcUy7wododfB6Qjk0=; b=dvXH7x1cE4bnupULVsGoR57OLx3UWM3R3drT9Dg+5mDuhLfzLw5nNoOJiEGT9kZQSw zElgKja6N9dEWBhwD/904/ON+uN2W5jkZcHK1d6uJ2gXQApOAWK+L74n+fqjVuevPnGC twD9bMQkJhJe40/qHowjFANuK0Oz7UsjyAO7CsXO7y9aYqG/M/6az3mxKRb0dTmAblnP /M6d9CRx1sd4y9hBue/jcGdYxiuyDN0Z5IbSc8tEsby/1j9vm0pyg+QFGs2YQn9/d+T6 SyuUbuGTFd0M32ppmxmi82BqJJ8BiNc/NxQeh+XMbkdhdkm0+lL0eBuwaaq6P4eWvoGL TrAQ== X-Gm-Message-State: AOPr4FWmY/MsWcRu+Lzg0sn4Ny/qq9QOsNKJToG1TGxcglmnoUEnzT0urf/4vPW6/pDdHQ/Crcl3IkjgRRQzbA== X-Received: by 10.28.94.193 with SMTP id s184mr6113822wmb.57.1462997354600; Wed, 11 May 2016 13:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.63.178 with HTTP; Wed, 11 May 2016 13:08:55 -0700 (PDT) From: Demetrius Siluanius Date: Wed, 11 May 2016 23:08:55 +0300 Message-ID: Subject: bsd.incs.mk: include subdirectories To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 20:09:16 -0000 Hello everyone! Recently I started porting a number of my projects to BSD world. I realized it would be great if I could use a native make(1) tool instead of GNU make. I'm really impressed how easy it is to create a makefile for a library with almost a single '.include bsd.lib.mk' statement. Thank you guys for such an amazing build system! The only thing I couldn't deal with is when headers must be placed into subdirectories. For simplicity let's assume that project's headers hierarchy is the following one: include/ mylib/ A/ A0.h A1.h B/ B0.h B1.h base.h The only header that will be used is "mylib/base.h", but it includes other headers using statements '#include "A/A0.h". What should I do to install files like this? I can't really understand what's happening inside of bsd.incs.mk file, but I guess there should be something simpler than overriding the default 'installincludes' target. I could't find any relevant information; I tried to find an example Makefile which could have a similar headers hierarchy, but didn't succeed. Could you help me, please? Thank you! From owner-freebsd-hackers@freebsd.org Fri May 13 23:27:09 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 568FAB3ABC8 for ; Fri, 13 May 2016 23:27:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12BF0171E for ; Fri, 13 May 2016 23:27:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4DNR1HQ061893 for ; Fri, 13 May 2016 16:27:05 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605132327.u4DNR1HQ061893@gw.catspoiler.org> Date: Fri, 13 May 2016 16:27:01 -0700 (PDT) From: Don Lewis Subject: patch for acpidump CID 1011278 (Buffer not null terminated) and other issues To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 23:27:09 -0000 I posted a patch to fix some problems in acpidump here: https://reviews.freebsd.org/D6360 The changes are extensive enough that I thought that they deserved some review. The modified code seems to work for me.