From owner-freebsd-drivers@freebsd.org Mon Aug 31 21:33:37 2015 Return-Path: Delivered-To: freebsd-drivers@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 45E709C6F1A for ; Mon, 31 Aug 2015 21:33:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2366417E0 for ; Mon, 31 Aug 2015 21:33:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FE92B95D; Mon, 31 Aug 2015 17:33:36 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Date: Sun, 30 Aug 2015 17:04:31 -0700 Message-ID: <17365161.8JflB5H0LB@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150829103049.GA2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <2785418.Nryjt2Jbzi@ralph.baldwin.cx> <20150829103049.GA2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 31 Aug 2015 17:33:36 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:33:37 -0000 On Saturday, August 29, 2015 01:30:49 PM Konstantin Belousov wrote: > On Fri, Aug 28, 2015 at 01:34:58PM -0700, John Baldwin wrote: > > Perhaps we could force cloning to serialize with opens? That is, use > > some sort of global lock in devfs such that any non-cloning opens use > > a shared lock but an exclusive lock is taken before running clone > > event handlers (and held until after d_open returns)? To really > > close this sort of race, the exclusive lock acquired when a clone > > is created in lookup() would have to be held until devfs_open() is > > called. That's rather gross. I suppose you could always aquire the > > lock in devfs_lookup() when ISOPEN is set (exclusive if you have to > > clone, otherwise shared) and then drop it in devfs_open() after d_open > > returns. > Hm, I do not think taking a lock in lookup(ISOPEN) is feasible. VFS migh > not call VOP_OPEN() after the lookup, for misc. reasons (e.g. due to the > permissions, or forced umount reclaiming vnode as two obvious cases). > > Also, I am not sure about the definition about non-cloning open. Other > thread might race with the cloner and open the newly cloned node > before the cloner has a chance to proceed. Do you want to prevent this > situation ? If yes, then why ? si_drv1 issue should be handled by other > means. This isn't about si_drv1, this is about my other change of trying to let an open of /dev/tap reliably open a "free" tap device. The race my current change there doesn't handle is that if an open of /dev/tap that returns a "free" tap device from the clone handler might race with another process that opens a tap device by name (e.g. /dev/tap0). An entirely different possibility is to change /dev/tap to not use cloning at all and instead use cdevpriv. It could then safely choose a "free" tap device during its open routine. This might be a bit of an API change though as devname/fdevname could no longer be used to determine the name of the interface opened by an open of /dev/tap. > > Well, we've had this race in most cdev drivers in the tree for a long > > time. It's a narrow one that doesn't get hit often (if at all) in > > practice, but if I were to do a sweep to patch all the open routines > > to handle it, I'd rather we do it this way instead. OTOH, I don't have > > a burning desire to patch all the open routines. > > For the race to be real, the device must be created after the userspace > is running. I think that the main case there are pty. Or kldload of a device driver. > I do not see a possibility of removing existing make_dev*() after the > make_dev_uber() is introduced, so there is no need for the whole tree > sweep. I mean more that if one wanted to fix the si_drv1 race one would have to do some sort of sweep of affected drivers. -- John Baldwin From owner-freebsd-drivers@freebsd.org Wed Sep 2 13:59:28 2015 Return-Path: Delivered-To: freebsd-drivers@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 59F189C893E for ; Wed, 2 Sep 2015 13:59:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBBC66D0; Wed, 2 Sep 2015 13:59:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t82DxMjt020795 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Sep 2015 16:59:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t82DxMjt020795 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t82DxMXt020794; Wed, 2 Sep 2015 16:59:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Sep 2015 16:59:22 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Message-ID: <20150902135922.GZ2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <2785418.Nryjt2Jbzi@ralph.baldwin.cx> <20150829103049.GA2072@kib.kiev.ua> <17365161.8JflB5H0LB@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17365161.8JflB5H0LB@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 13:59:28 -0000 On Sun, Aug 30, 2015 at 05:04:31PM -0700, John Baldwin wrote: > On Saturday, August 29, 2015 01:30:49 PM Konstantin Belousov wrote: > > On Fri, Aug 28, 2015 at 01:34:58PM -0700, John Baldwin wrote: > > > Perhaps we could force cloning to serialize with opens? That is, use > > > some sort of global lock in devfs such that any non-cloning opens use > > > a shared lock but an exclusive lock is taken before running clone > > > event handlers (and held until after d_open returns)? To really > > > close this sort of race, the exclusive lock acquired when a clone > > > is created in lookup() would have to be held until devfs_open() is > > > called. That's rather gross. I suppose you could always aquire the > > > lock in devfs_lookup() when ISOPEN is set (exclusive if you have to > > > clone, otherwise shared) and then drop it in devfs_open() after d_open > > > returns. > > Hm, I do not think taking a lock in lookup(ISOPEN) is feasible. VFS migh > > not call VOP_OPEN() after the lookup, for misc. reasons (e.g. due to the > > permissions, or forced umount reclaiming vnode as two obvious cases). > > > > Also, I am not sure about the definition about non-cloning open. Other > > thread might race with the cloner and open the newly cloned node > > before the cloner has a chance to proceed. Do you want to prevent this > > situation ? If yes, then why ? si_drv1 issue should be handled by other > > means. > > This isn't about si_drv1, this is about my other change of trying to let > an open of /dev/tap reliably open a "free" tap device. The race my current > change there doesn't handle is that if an open of /dev/tap that returns > a "free" tap device from the clone handler might race with another process > that opens a tap device by name (e.g. /dev/tap0). This is a race which must be handled by userspace, I am afraid. > > An entirely different possibility is to change /dev/tap to not use cloning > at all and instead use cdevpriv. It could then safely choose a "free" > tap device during its open routine. This might be a bit of an API change > though as devname/fdevname could no longer be used to determine the name > of the interface opened by an open of /dev/tap. What if we change tap to use cdevpriv, and have some unit number sequencer for the cdevprivs (as I understand, this would correspond to the unit of the cloned tap interface ?). Also, we add a cdevsw method to get the devname. By default, the method will provide dev->si_name. For tap, the method would create the the /dev/tapX, where X is the tap interface number, and returns corresponding name. The /dev/tapX opens would need to find cdevprivs from the /dev/tap. This would cause KBI change for the cdevs, but no API change for tap consumers and no KPI changes for cdevs. > > > > Well, we've had this race in most cdev drivers in the tree for a long > > > time. It's a narrow one that doesn't get hit often (if at all) in > > > practice, but if I were to do a sweep to patch all the open routines > > > to handle it, I'd rather we do it this way instead. OTOH, I don't have > > > a burning desire to patch all the open routines. > > > > For the race to be real, the device must be created after the userspace > > is running. I think that the main case there are pty. > > Or kldload of a device driver. But this is much more rare, this is what I mean. > > > I do not see a possibility of removing existing make_dev*() after the > > make_dev_uber() is introduced, so there is no need for the whole tree > > sweep. > > I mean more that if one wanted to fix the si_drv1 race one would have to > do some sort of sweep of affected drivers. Yes. From owner-freebsd-drivers@freebsd.org Wed Sep 2 18:35:33 2015 Return-Path: Delivered-To: freebsd-drivers@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 50E739C89B1 for ; Wed, 2 Sep 2015 18:35:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C0B3671 for ; Wed, 2 Sep 2015 18:35:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8F834B98E; Wed, 2 Sep 2015 14:35:31 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Date: Wed, 02 Sep 2015 10:59:12 -0700 Message-ID: <1619676.EuPFulsFRT@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150902135922.GZ2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <17365161.8JflB5H0LB@ralph.baldwin.cx> <20150902135922.GZ2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 02 Sep 2015 14:35:31 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 18:35:33 -0000 On Wednesday, September 02, 2015 04:59:22 PM Konstantin Belousov wrote: > On Sun, Aug 30, 2015 at 05:04:31PM -0700, John Baldwin wrote: > > On Saturday, August 29, 2015 01:30:49 PM Konstantin Belousov wrote: > > > On Fri, Aug 28, 2015 at 01:34:58PM -0700, John Baldwin wrote: > > > > Perhaps we could force cloning to serialize with opens? That is, use > > > > some sort of global lock in devfs such that any non-cloning opens use > > > > a shared lock but an exclusive lock is taken before running clone > > > > event handlers (and held until after d_open returns)? To really > > > > close this sort of race, the exclusive lock acquired when a clone > > > > is created in lookup() would have to be held until devfs_open() is > > > > called. That's rather gross. I suppose you could always aquire the > > > > lock in devfs_lookup() when ISOPEN is set (exclusive if you have to > > > > clone, otherwise shared) and then drop it in devfs_open() after d_open > > > > returns. > > > Hm, I do not think taking a lock in lookup(ISOPEN) is feasible. VFS migh > > > not call VOP_OPEN() after the lookup, for misc. reasons (e.g. due to the > > > permissions, or forced umount reclaiming vnode as two obvious cases). > > > > > > Also, I am not sure about the definition about non-cloning open. Other > > > thread might race with the cloner and open the newly cloned node > > > before the cloner has a chance to proceed. Do you want to prevent this > > > situation ? If yes, then why ? si_drv1 issue should be handled by other > > > means. > > > > This isn't about si_drv1, this is about my other change of trying to let > > an open of /dev/tap reliably open a "free" tap device. The race my current > > change there doesn't handle is that if an open of /dev/tap that returns > > a "free" tap device from the clone handler might race with another process > > that opens a tap device by name (e.g. /dev/tap0). > This is a race which must be handled by userspace, I am afraid. It can't really be handled well though. It would mean that any user of /dev/tap basically has to do opens of /dev/tap in a loop in case the open fails with EBUSY. This makes it useless for existing applications (e.g. the use case I care about personally is when I run multiple bhyve VMs. Currently I have to statically allocate tap0 to vm0, tap1 to vm1, etc. What I would really like to do is just tell my various VMs to open /dev/tap and get a "free" tap device to use for the lifetime of the VM. > > An entirely different possibility is to change /dev/tap to not use cloning > > at all and instead use cdevpriv. It could then safely choose a "free" > > tap device during its open routine. This might be a bit of an API change > > though as devname/fdevname could no longer be used to determine the name > > of the interface opened by an open of /dev/tap. > What if we change tap to use cdevpriv, and have some unit number > sequencer for the cdevprivs (as I understand, this would correspond to > the unit of the cloned tap interface ?). Also, we add a cdevsw method to > get the devname. By default, the method will provide dev->si_name. > > For tap, the method would create the the /dev/tapX, where X is the tap > interface number, and returns corresponding name. The /dev/tapX opens > would need to find cdevprivs from the /dev/tap. > > This would cause KBI change for the cdevs, but no API change for tap > consumers and no KPI changes for cdevs. If we allow a cdevsw to override how devname works, then that would probably be sufficient on its own. I don't think you would need to change the /dev/tapX devices at all. The cdevpriv for /dev/tap desciptors would have a reference to the /dev/tapX device it is using and return that device's name in the devname override. Another option that I had started to play with previously is to let devices auto-created by /dev/tap set an internal 'destroy-on-close' flag. That seems a bit more heavyweight, but it might also be simpler to implement? -- John Baldwin From owner-freebsd-drivers@freebsd.org Thu Sep 3 09:47:33 2015 Return-Path: Delivered-To: freebsd-drivers@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 7F8459C9EB1 for ; Thu, 3 Sep 2015 09:47:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1306F1E94; Thu, 3 Sep 2015 09:47:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t839lSFR052969 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Sep 2015 12:47:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t839lSFR052969 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t839lRpA052968; Thu, 3 Sep 2015 12:47:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Sep 2015 12:47:27 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Message-ID: <20150903094727.GD2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <17365161.8JflB5H0LB@ralph.baldwin.cx> <20150902135922.GZ2072@kib.kiev.ua> <1619676.EuPFulsFRT@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1619676.EuPFulsFRT@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 09:47:33 -0000 On Wed, Sep 02, 2015 at 10:59:12AM -0700, John Baldwin wrote: > If we allow a cdevsw to override how devname works, then that would probably > be sufficient on its own. I don't think you would need to change the > /dev/tapX devices at all. The cdevpriv for /dev/tap desciptors would have a > reference to the /dev/tapX device it is using and return that device's name > in the devname override. You mean, the consumers of tap use fdevname(3), not devname(3) ? Since for devname(), there is no access to cdevpriv. > > Another option that I had started to play with previously is to let devices > auto-created by /dev/tap set an internal 'destroy-on-close' flag. That > seems a bit more heavyweight, but it might also be simpler to implement? Could you, please, clarify, how this would help to handle the race at open ? From owner-freebsd-drivers@freebsd.org Thu Sep 3 23:07:12 2015 Return-Path: Delivered-To: freebsd-drivers@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 CB4D79CA456; Thu, 3 Sep 2015 23:07:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A97421029; Thu, 3 Sep 2015 23:07:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C01C0B941; Thu, 3 Sep 2015 19:07:11 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org, Nomad Esst Cc: "freebsd-drivers@freebsd.org" Subject: Re: Get pci slot number in driver Date: Thu, 03 Sep 2015 15:57:15 -0700 Message-ID: <8357967.OxrZP5NxFz@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <1473579278.716147.1440404222458.JavaMail.yahoo@mail.yahoo.com> References: <1473579278.716147.1440404222458.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Sep 2015 19:07:11 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 23:07:12 -0000 On Monday, August 24, 2015 08:17:02 AM Nomad Esst via freebsd-hackers wrote: > Is it possible to find out the pci slot number on which the card is mounted in driver? I tried pci_get_slot but it's always 0.Any ideas about doing this? > regards It depends on what you mean by slot. If you mean the label of the physical slot in a chassis / motherboard, then there is no reliable way to determine this. (There are some PCI extended capabilities that I've never seen in the wild that can communicate this. There are various firmware tables ($PIR and SMBIOS) on x86 that can in theory tell you this, but it's a crap shoot whether the tables are correct or a pack of lies. If you want to determine the "device" field of a PCI device's (bus, device, function) config space access, you can use pci_get_slot() (FreeBSD calls it a slot even though the standard name in the PCI spec is "device" for legacy reasons as in original PCI a physical slot did have a unique "device" address on a given bus). -- John Baldwin From owner-freebsd-drivers@freebsd.org Fri Sep 4 10:43:41 2015 Return-Path: Delivered-To: freebsd-drivers@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 C6EFA9CA2B5 for ; Fri, 4 Sep 2015 10:43:41 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 970758AC for ; Fri, 4 Sep 2015 10:43:41 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441363052; bh=3YXjyDVxosqhgiKrw6+4y5eHt9KyXAmAlUfvAcYn3Cs=; h=Date:From:Reply-To:To:Subject:From:Subject; b=QGxbJtmXPih7VwMd/5YqigktekAjDp3zSbQXQUddZfV5XIIbqGKpJ3CDLke9dDCK7gTfHOs6s5kNHDIsmS7yxwrAdTZ33JXSs+A78To1xqCjhIjH9LKAo91+xYoQVkAVo1ZtSzCKRT8ZU/Z0YGkBt3eeZFQqH2stIhp4i9kzXIcrOvAh3uL+X7qpDQpdlL2eSu2NNr5ZQFnfHGsHCVmGbHFGACIZD9nAz+ekp9R1FZ21MlPnWnMeSdmpZE0nany9JqbrvY3HemOavRLWPf2KLcuxJeF8NLrx39TlDqYo63CQ0nnur08NrQspTO/VZyqwUmhsGhqqaoFxRUOZXYnU5g== Received: from [98.138.101.132] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 Received: from [98.138.87.5] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 04 Sep 2015 10:37:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 176579.64844.bm@omp1005.mail.ne1.yahoo.com X-YMail-OSG: ymxtVEQVM1np.37CbZ1Ys8NXXC.st3CmV2qBc76lqrg9.U2higFhK2ljyok.1D0 b8wcF__acyeVBBlSe_ENxkMVXbz481jQ2esW48lCnCmL2DbjVXlj9vP2rZNWs6u8Sb9AXoOD5GiM phPuGTKwUqwhpSjQrvkSlef8MUzBhl_tSTpq_j5rr7_WApXRpLgKyAvjRv1nGr4tY.OscrreIdXz ViprMdG9cqiwU7CR9exkmBrGzHVr6lrln3Pml87EdiTrh2FqkOAtuqDx_cNz72pJyEd3rHt.bS4F QwyEwO.LnaEW69SA.pmgZIVqm7H2n0LKr1PQ5k6NA_CYkO5gd3GpHNh8bQF1O7suOkYOq7ubgOW1 XKHDLLBTFkXQ5QEKfrWLc_tUt4ZKA3pRd.oLhV_fsLoRNPTFDAUaziztDofahY11WErSx8X8E.rL Wj9b9mSnzcQyWtef7pjox3aE16RhWmckoGR0Ugx51nWi6qsSHMi6kA34- Received: by 98.138.105.193; Fri, 04 Sep 2015 10:37:31 +0000 Date: Fri, 4 Sep 2015 10:37:31 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "freebsd-drivers@freebsd.org" , FreeBSD Net , Freebsd Hackers List Message-ID: <740628555.1564144.1441363051289.JavaMail.yahoo@mail.yahoo.com> Subject: FreeBSD em, igb driver question MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 10:43:41 -0000 Hi allDuring some performance tests, we found out some weird problems. We u= se a shell script that do the following : do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface uptcp= replay -i em0 -l ospf_hello.pcap=C2=A0sleep3end By running this shell on one side we expect 10 ospf hello packets to get ar= rived at the other side, but tcpdump (on the other side) shows 4, sometimes= 8 and etc ... (not all 10 packets are arrived at the other side).We test t= his scenario with a Cisco router, and all packets are received at the Cisco= side. What causes this packet loss in FreeBSD (maybe in em or igb drivers)= ?I know that this scenario may not have any use in the real world, but I'm = curious, why Cisco don't have such behavior.Thanks in advance. Regards. From owner-freebsd-drivers@freebsd.org Fri Sep 4 19:22:36 2015 Return-Path: Delivered-To: freebsd-drivers@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 426CF9CA2E4 for ; Fri, 4 Sep 2015 19:22:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C53A14AB for ; Fri, 4 Sep 2015 19:22:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E57B2B945; Fri, 4 Sep 2015 15:22:33 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Date: Fri, 04 Sep 2015 11:42:38 -0700 Message-ID: <1595067.LHJIsK18l7@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150903094727.GD2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <1619676.EuPFulsFRT@ralph.baldwin.cx> <20150903094727.GD2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Sep 2015 15:22:34 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 19:22:36 -0000 On Thursday, September 03, 2015 12:47:27 PM Konstantin Belousov wrote: > On Wed, Sep 02, 2015 at 10:59:12AM -0700, John Baldwin wrote: > > If we allow a cdevsw to override how devname works, then that would probably > > be sufficient on its own. I don't think you would need to change the > > /dev/tapX devices at all. The cdevpriv for /dev/tap desciptors would have a > > reference to the /dev/tapX device it is using and return that device's name > > in the devname override. > You mean, the consumers of tap use fdevname(3), not devname(3) ? Since > for devname(), there is no access to cdevpriv. Correct, if you open /dev/tap to get a free tap device, you want to find out which interface you actually opened, so fdevname() on the descriptor would work. If you used fstat() to extract a dev_t to pass to devname() I guess that would still just return '/dev/tap'. > > Another option that I had started to play with previously is to let devices > > auto-created by /dev/tap set an internal 'destroy-on-close' flag. That > > seems a bit more heavyweight, but it might also be simpler to implement? > > Could you, please, clarify, how this would help to handle the race at > open ? Hmm, I guess it wouldn't really help. There's just no way to reliably interlock between the clone handler and the open routine. Even with "simple" cloning I think you will always have a race in that the clone handler might create a new device to use but then fail the open. I think that from an API perspective, opening a "clone" device should never fail. Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open, but instead using a d_fdopen routine and explicitly setting up the new file descriptor as if it had opened the equivalent named device. Perhaps that is what I should do instead in my tap change. If I go that route, then I think that fdevname/devname would already DTRT without needing a new cdevsw method. -- John Baldwin From owner-freebsd-drivers@freebsd.org Fri Sep 4 19:32:13 2015 Return-Path: Delivered-To: freebsd-drivers@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 ADD759CA7CC for ; Fri, 4 Sep 2015 19:32:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40C3C1AB0; Fri, 4 Sep 2015 19:32:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t84JW71P063902 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 Sep 2015 22:32:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t84JW71P063902 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t84JW7ru063901; Fri, 4 Sep 2015 22:32:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Sep 2015 22:32:07 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Message-ID: <20150904193207.GK2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <1619676.EuPFulsFRT@ralph.baldwin.cx> <20150903094727.GD2072@kib.kiev.ua> <1595067.LHJIsK18l7@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1595067.LHJIsK18l7@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 19:32:13 -0000 On Fri, Sep 04, 2015 at 11:42:38AM -0700, John Baldwin wrote: > Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open, > but instead using a d_fdopen routine and explicitly setting up the new > file descriptor as if it had opened the equivalent named device. Perhaps > that is what I should do instead in my tap change. If I go that route, > then I think that fdevname/devname would already DTRT without needing a > new cdevsw method. There is probably some fine difference between pts, which are typically fully managed and configured by master using the file descriptor, and cloned network interfaces, where you usually allow external processes to do the work. But if it works for tap, great. Also, you should have noted D3557 (csw d_devname), just in case ? From owner-freebsd-drivers@freebsd.org Fri Sep 4 20:38:03 2015 Return-Path: Delivered-To: freebsd-drivers@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 A02049CBF7E for ; Fri, 4 Sep 2015 20:38:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6A41628 for ; Fri, 4 Sep 2015 20:38:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B8E0DB945; Fri, 4 Sep 2015 16:38:01 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: freebsd-drivers@freebsd.org, Leonardo Fogel Subject: Re: Race conditions Date: Fri, 04 Sep 2015 13:37:59 -0700 Message-ID: <2149458.2Hg3JbBXY3@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150904193207.GK2072@kib.kiev.ua> References: <1439923294.98963.YahooMailBasic@web120801.mail.ne1.yahoo.com> <1595067.LHJIsK18l7@ralph.baldwin.cx> <20150904193207.GK2072@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 Sep 2015 16:38:01 -0400 (EDT) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 20:38:03 -0000 On Friday, September 04, 2015 10:32:07 PM Konstantin Belousov wrote: > On Fri, Sep 04, 2015 at 11:42:38AM -0700, John Baldwin wrote: > > Hmm, looking at /dev/ptmx, it handles this by not doing a clone on open, > > but instead using a d_fdopen routine and explicitly setting up the new > > file descriptor as if it had opened the equivalent named device. Perhaps > > that is what I should do instead in my tap change. If I go that route, > > then I think that fdevname/devname would already DTRT without needing a > > new cdevsw method. > > There is probably some fine difference between pts, which are typically > fully managed and configured by master using the file descriptor, and > cloned network interfaces, where you usually allow external processes to > do the work. But if it works for tap, great. In some cases though the external management is not that much to arrange. For my particular use case (multiple VMs) devd can autoconfigure new tap devices as they are created (add them to a global bridge interface) and bhyve just does operations on the fd it has opened. > Also, you should have noted D3557 (csw d_devname), just in case ? I did see the e-mail but have not (yet) looked in detail. -- John Baldwin From owner-freebsd-drivers@freebsd.org Sat Sep 5 06:09:36 2015 Return-Path: Delivered-To: freebsd-drivers@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 D302E9C921D for ; Sat, 5 Sep 2015 06:09:36 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 68525B05 for ; Sat, 5 Sep 2015 06:09:36 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: by wicge5 with SMTP id ge5so35268442wic.0 for ; Fri, 04 Sep 2015 23:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=FliRE4DUfMvhwh5Shz5Dei8yEt6Cujm/1Z0nZbWs9RU=; b=Ip1j+h+fHVAPl57PPmEOANdgPJT4hlqBBeUFePmhU6h5pQO4BxoI1QanM7u4fsGcxb j8MHuXcGAvCBxcWuIrA5/r6ZAj1O6FjquxJcyPiyrn1rjdiFpUqsR7gyXqtedCGcsYwL y9v0j2Z16FkB7GdFtvIpuivShlD+oSXQEv4pO46is+DLjgf26Dze3tv328HEWgirYzvn Ihnj7vcS+sqxIGlN1xkbT39db3ef/GNZ+RVaL9dMKFvDB85xUBTxni3g7ks4PXrbIPO0 TPYV4PKElI3hvDI0MSO+r2kMOJQ4hwZO7nvQQwUum05r9n/0arbB/tuYeWKyXie6FL8t lnPg== X-Received: by 10.194.179.137 with SMTP id dg9mr14530164wjc.55.1441433374870; Fri, 04 Sep 2015 23:09:34 -0700 (PDT) Received: from [192.168.0.4] (cpc70503-cmbg14-2-0-cust92.5-4.cable.virginm.net. [86.26.152.93]) by smtp.googlemail.com with ESMTPSA id p3sm8165226wib.16.2015.09.04.23.09.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 23:09:34 -0700 (PDT) Message-ID: <55EA871D.9000209@gmail.com> Date: Sat, 05 Sep 2015 07:09:33 +0100 From: Rohit Grover User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: freebsd-drivers@freebsd.org Subject: Fwd: patch for atp driver References: <55CA26E8.6070201@gmail.com> In-Reply-To: <55CA26E8.6070201@gmail.com> X-Forwarded-Message-Id: <55CA26E8.6070201@gmail.com> Content-Type: multipart/mixed; boundary="------------070104090007010904040707" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 06:09:37 -0000 This is a multi-part message in MIME format. --------------070104090007010904040707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Can someone help process a patch to the atp driver? See below. thanks, -------- Forwarded Message -------- Subject: patch for atp driver Date: Tue, 11 Aug 2015 17:46:32 +0100 From: Rohit Grover To: Hans Petter Selasky Hello Hans, I'd like to submit a patch to fix an issue reported against the atp driver. Refer to https://github.com/rgrover/freebsd-atp/issues/1. This bug was introduced with revision *262417* . The original code can be seen at https://svnweb.freebsd.org/base/head/sys/dev/usb/input/atp.c?revision=233774&view=markup#l1788. Kevin, the person who reported the issue, has been driving the testing and validation effort. He confirms that the attached patch fixes the problem. Could you please review and merge this change? thanks, Rohit. --------------070104090007010904040707 Content-Type: text/plain; charset=UTF-8; name="diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="diff" ZGlmZiAtLWdpdCBhL2F0cC5jIGIvYXRwLmMKaW5kZXggODMyYzFlNi4uZjk3ZDY1OCAxMDA2 NDQKLS0tIGEvYXRwLmMKKysrIGIvYXRwLmMKQEAgLTk5NiwxNyArOTk2LDE2IEBAIGZnX2lu dGVycHJldF9zZW5zb3JfZGF0YShzdHJ1Y3QgYXRwX3NvZnRjICpzYywgdV9pbnQgZGF0YV9s ZW4pCiAJICogYmUgdXNlZCBhcyBwcmVzc3VyZSByZWFkaW5ncyBzdWJzZXF1ZW50bHkuCiAJ ICovCiAJc3RhdHVzX2JpdHMgPSBzYy0+c2Nfc2Vuc29yX2RhdGFbcGFyYW1zLT5kYXRhX2xl biAtIDFdOwotCWlmICgoKHBhcmFtcy0+cHJvdCA9PSBGR19UUkFDS1BBRF9UWVBFX0dFWVNF UjMpIHx8Ci0JICAgICAocGFyYW1zLT5wcm90ID09IEZHX1RSQUNLUEFEX1RZUEVfR0VZU0VS NCkpICAmJgorCWlmICgoKChwYXJhbXMtPnByb3QgPT0gRkdfVFJBQ0tQQURfVFlQRV9HRVlT RVIzKSB8fAorCSAgICAgIChwYXJhbXMtPnByb3QgPT0gRkdfVFJBQ0tQQURfVFlQRV9HRVlT RVI0KSkgJiYKKwkgICAgIChzdGF0dXNfYml0cyAmIEZHX1NUQVRVU19CQVNFX1VQREFURSkp IHx8CiAJICAgICgoc2MtPnNjX3N0YXRlICYgQVRQX1ZBTElEKSA9PSAwKSkgewotCQlpZiAo c3RhdHVzX2JpdHMgJiBGR19TVEFUVVNfQkFTRV9VUERBVEUpIHsKLQkJCW1lbWNweShzYy0+ c2NfYmFzZV94LCBzYy0+c2NfY3VyX3gsCi0JCQkgICAgcGFyYW1zLT5uX3hzZW5zb3JzICog c2l6ZW9mKCpzYy0+c2NfYmFzZV94KSk7Ci0JCQltZW1jcHkoc2MtPnNjX2Jhc2VfeSwgc2Mt PnNjX2N1cl95LAotCQkJICAgIHBhcmFtcy0+bl95c2Vuc29ycyAqIHNpemVvZigqc2MtPnNj X2Jhc2VfeSkpOwotCQkJc2MtPnNjX3N0YXRlIHw9IEFUUF9WQUxJRDsKLQkJCXJldHVybjsK LQkJfQorCSAgICBtZW1jcHkoc2MtPnNjX2Jhc2VfeCwgc2MtPnNjX2N1cl94LAorCSAgICAg ICAgICAgcGFyYW1zLT5uX3hzZW5zb3JzICogc2l6ZW9mKCpzYy0+c2NfYmFzZV94KSk7CisJ ICAgIG1lbWNweShzYy0+c2NfYmFzZV95LCBzYy0+c2NfY3VyX3ksCisJICAgICAgICAgICBw YXJhbXMtPm5feXNlbnNvcnMgKiBzaXplb2YoKnNjLT5zY19iYXNlX3kpKTsKKwkgICAgc2Mt PnNjX3N0YXRlIHw9IEFUUF9WQUxJRDsKKwkgICAgcmV0dXJuOwogCX0KIAogCS8qIEdldCBw cmVzc3VyZSByZWFkaW5ncyBhbmQgZGV0ZWN0IHAtc3BhbnMgZm9yIGJvdGggYXhlcy4gKi8K --------------070104090007010904040707-- From owner-freebsd-drivers@freebsd.org Sat Sep 5 14:45:44 2015 Return-Path: Delivered-To: freebsd-drivers@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 2EA599CA043 for ; Sat, 5 Sep 2015 14:45:44 +0000 (UTC) (envelope-from noname.esst@yahoo.com) Received: from nm13-vm5.bullet.mail.ne1.yahoo.com (nm13-vm5.bullet.mail.ne1.yahoo.com [98.138.91.235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F31971BCA for ; Sat, 5 Sep 2015 14:45:43 +0000 (UTC) (envelope-from noname.esst@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441464235; bh=AomhwY6Bl6BPwWS3hr97Zo3dOJrjtzMT5b9AybxnxCE=; h=Date:From:Reply-To:To:Subject:From:Subject; b=BelRgYnwMa+WyvENtyGHyfjJOqdK3EC8gc3RjNCiEnIU/i7Pww9yTa9xPPQpcUuYDnX5Ct9TuavQQcxMVK1Xk4ny36KVr8S/hNErpEbX2uL/JGzA9WFLkv/G//+L9AOmp/Xr8VPA/wK+amdZBElW6lkuhDxlNq567sysIKF9vUj93SJL09FHiL641kNTSLG+oVvseJ93v8z1OQbb6aa4nYj7mD75Bq6D+kU8h6kPiMwUc7t4ALBNImHc9KmNUY7AaQcBog7UZ55y6ZVbgJ5bhvOTlm4G6XucvfKNwc2WrSBzt+feo+SRXCzrq6JkViSaGd8ryXN0JU5AR/gKwg1aMw== Received: from [98.138.226.179] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2015 14:43:55 -0000 Received: from [98.138.87.3] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2015 14:43:54 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 05 Sep 2015 14:43:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880880.74107.bm@omp1003.mail.ne1.yahoo.com X-YMail-OSG: 6X2TLusVM1k6S5EW7_v9RWYv9aYO.liX4h_0Hm4MVe.6tTUUXv4u.sTSVNarse8 dPvoi2SMWRTTYcs.AnKdzLzdHMjVtH7RehAI9NZg4A4kj8ChGHH7wlZE_wpEi2d7JbBmQtl_yeuv 2Aknm.wBIgTmy77m2n0262JinbLqVeyD1U3_yAOCXzISSN5eOoS_XCnJtSDj9oleQxZmbIAOhetX Ephb0omUehy146Y8Vw9FXDEo8jBrxSgk2z2oF1LzLlLi9_kTRxCqPkAR7jdGsmpE9eoEYk79STiq 36lBijdTAFZX4FAT4LSUcV7jcmTzfQUmpsF.hgw0aO21o9kjaERLsz1Xtkd1Phf56eDzFRFgiBVY KY_28ogwLUzawN2RaR8F3KOg5okdWoLl9Wx7dH.yatOul2fuRbiISPN0qUFsy5DlCkINbMIQS1ge UcFmr61_30.SZ3kuZyiqaCZVJbeaChBtEq_OFEPnAfauSzL9lz2F1YqI- Received: by 98.138.105.202; Sat, 05 Sep 2015 14:43:54 +0000 Date: Sat, 5 Sep 2015 14:43:54 +0000 (UTC) From: Nomad Esst Reply-To: Nomad Esst To: "freebsd-drivers@freebsd.org" Message-ID: <1725304810.2091726.1441464234074.JavaMail.yahoo@mail.yahoo.com> Subject: em, igb performance test MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 14:45:44 -0000 Hi allDuring some performance tests, we found out some weird problems. We u= se a shell script that do the following : do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface uptcp= replay -i em0 -l ospf_hello.pcap=C2=A0sleep3end By running this shell on one side we expect 10 ospf hello packets to get ar= rived at the other side, but tcpdump (on the other side) shows 4, sometimes= 8 and etc ... (not all 10 packets are arrived at the other side).We test t= his scenario with a Cisco router, and all packets are received at the Cisco= side. What causes this packet loss in FreeBSD (maybe in em or igb drivers)= ?I know that this scenario may not have any use in the real world, but I'm = curious, why Cisco don't have such behavior.Thanks in advance. Regards.