From owner-svn-src-head@freebsd.org Sat Aug 4 10:49:41 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 296A11065E82; Sat, 4 Aug 2018 10:49:41 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D36C68F357; Sat, 4 Aug 2018 10:49:40 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 6A260173B6; Sat, 4 Aug 2018 10:49:40 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8rgnodtw3ikd82geexy.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240b:b802:2085:aca2:f9e7:5b26]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D6CCF3F0B0; Sat, 4 Aug 2018 12:49:37 +0200 (CEST) From: "Kristof Provost" To: "Gleb Smirnoff" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336221 - head/sys/net Date: Sat, 04 Aug 2018 12:49:36 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org> In-Reply-To: <20180803230405.GI420@FreeBSD.org> References: <201807121635.w6CGZZAN046919@repo.freebsd.org> <20180803230405.GI420@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 10:49:41 -0000 On 4 Aug 2018, at 1:04, Gleb Smirnoff wrote: > On Thu, Jul 12, 2018 at 04:35:35PM +0000, Kristof Provost wrote: > K> Author: kp > K> Date: Thu Jul 12 16:35:35 2018 > K> New Revision: 336221 > K> URL: https://svnweb.freebsd.org/changeset/base/336221 > K> > K> Log: > K> pf: Increate default state table size > K> > K> The typical system now has a lot more memory than when pf was = > new, and is also > K> expected to handle more connections. Increase the default size of = > the state > K> table. > K> Note that users can overrule this using 'set limit states' in = > pf.conf. > K> > K> From OpenBSD: > K> The year is 2018. > K> Mercury, Bowie, Cash, Motorola and DEC all left us. > K> Just pf still has a default state table limit of 10000. > K> Had! Now it's a tiny little bit more, 100k. > K> lead guitar: me > K> ok chorus: phessler theo claudio benno > K> background school girl laughing: bob > > For FreeBSD it would also make sense to bump hash sizes along with = > this change. > Yeah, Olivier did some benchmarking work around this: https://github.com/ocochard/netbenches/blob/master/Atom_C2758_8Cores-Chel= sio_T540-CR/pf-states_hashsize/results/fbsd12-head.r332390/README.md He found a roughly 10% increase in throughput by increasing the hash = size to 256K. I=E2=80=99ve been thinking about making the hash size dynamically configu= rable = (so we could calculate it based in the state limit, rather than expect = users to tune this manually), but that=E2=80=99s probably not going to ge= t = done any time soon. I=E2=80=99ll see about increasing the default (although perhaps not to 25= 6K, = because if my math is right that=E2=80=99s cost us ~20MB of memory) soon,= = because that=E2=80=99s mostly a quick win. Regards, Kristof From owner-svn-src-head@freebsd.org Sat Aug 4 10:58:46 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 182581066279; Sat, 4 Aug 2018 10:58:46 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9E8C8F95F; Sat, 4 Aug 2018 10:58:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PCX00F00N46B100@mr11p00im-asmtp004.me.com>; Sat, 04 Aug 2018 10:58:38 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PCX003F1NTDXE30@mr11p00im-asmtp004.me.com>; Sat, 04 Aug 2018 10:58:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-04_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1808040123 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r337271 - head/stand/i386/libi386 From: Toomas Soome In-reply-to: <87cc3ae5-cbef-0d04-071e-cb7f7a410ce8@delphij.net> Date: Sat, 04 Aug 2018 13:58:24 +0300 Cc: Cy Schubert , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, tsoome@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <7212F80A-9BA8-4D64-AB66-B8FA9F08409F@me.com> References: <201808031911.w73JB0WK025164@repo.freebsd.org> <87cc3ae5-cbef-0d04-071e-cb7f7a410ce8@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 10:58:46 -0000 > On 4 Aug 2018, at 11:54, Xin Li wrote: >=20 > Hi, Cy, >=20 > On 8/3/18 12:11, Cy Schubert wrote: >> Author: cy >> Date: Fri Aug 3 19:11:00 2018 >> New Revision: 337271 >> URL: https://svnweb.freebsd.org/changeset/base/337271 >>=20 >> Log: >> Some drives report a geometry that is inconsisetent with the total >> number of sectors reported through the BIOS. Cylinders * heads * >> sectors may not necessarily be equal to the total number of sectors >> reported through int13h function 48h. >>=20 >> An example of this is when a Mediasonic HD3-U2B PATA to USB = enclosure >> with a 80 GB disk is attached. Loader hangs at line 506 of >> stand/i386/libi386/biosdisk.c while attempting to read sectors = beyond >> the end of the disk, sector 156906855. I discovered that the = Mediasonic >> enclosure was reporting the disk with 9767 cylinders, 255 heads, 63 >> sectors/track. That's 156906855 sectors. However camcontrol and >> Windows 10 both report report the disk having 156301488 sectors, not >> the calculated value. At line 280 biosdisk.c sets the sectors to the >> higher of either bd->bd_sectors or the total calculated at line 276 >> (156906855) instead of the lower and correct value of 156301488 = reported >> by int 13h 48h. >>=20 >> This was tested on all three of my Mediasonic HD3-U2B PATA to USB >> enclosures. >>=20 >> Instead of using the higher of bd_sectors (returned by int13h) or = the >> calculated value, this patch uses the lower and safer of the values. >>=20 >> Reviewed by: tsoome@ >> Differential Revision: https://reviews.freebsd.org/D16577 >>=20 >> Modified: >> head/stand/i386/libi386/biosdisk.c >>=20 >> Modified: head/stand/i386/libi386/biosdisk.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/stand/i386/libi386/biosdisk.c Fri Aug 3 18:52:51 2018 = (r337270) >> +++ head/stand/i386/libi386/biosdisk.c Fri Aug 3 19:11:00 2018 = (r337271) >> @@ -275,7 +275,7 @@ bd_int13probe(struct bdinfo *bd) >>=20 >> total =3D (uint64_t)params.cylinders * >> params.heads * params.sectors_per_track; >> - if (bd->bd_sectors < total) >> + if (bd->bd_sectors > total) >> bd->bd_sectors =3D total; >>=20 >> ret =3D 1; >>=20 >=20 > This broke loader on my system, but I think your reasoning was valid = so > I took a deeper look and discovered that on my system, INT 13h, = function > 48h would give zeros in EDD parameters' CHS fields. With that, the > calculated CHS based total would be 0, and your change would cause > bd_sectors be zeroed. >=20 > Could you please let me know if https://reviews.freebsd.org/D16588 = makes > sense to you? (I'm not 100% certain if I have followed the code). It > allowed my Asrock C2750D4I based board to boot from ZFS. >=20 I have in mind something a bit different for some time, but haven=E2=80=99= t had chance to complete it because I have no =E2=80=9Cweird=E2=80=9D = systems to validate the idea:D I=E2=80=99ll try to get a bit of time and = post an phabricator soon. rgds, toomas