Re: Request for Testing: TCP RACK

ccur in some dedicated context, like per-CPU thread, instead of userret. > > > R > > > > On 3/18/24 3:42 PM, Drew Gallatin wrote: > > No.  The goal is to run on every return to userspace for every thread. > > > > Drew > > > > On Mon, Mar 18

Re: Request for Testing: TCP RACK

it registers the ast to run on next return to userspace, for the current thread. Is it enough? > > Drew > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > > On 18 Mar 2024, at 7:04, tue...@freebs

Re: Request for Testing: TCP RACK

On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote: > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote: > >> > >> Hello all! > >> > >> It works just fine! > >> System performance is OK. > >> Using patch on

IPSEC inline offload

NVIDIA networking developed support for inline IPSEC offload on FreeBSD. It consists of the common infrastructure part, and changes for mlx5en(4) driver fitting the kernel counterpart. Inline offload moves (almost) all IPSEC processing of the packet from CPU and crypto accelerators, to the

Re: kernel crash: devctl set driver -f mlx5_core6 ppt

driver. > > > > > >Also of note, if multiple VFs are created and a single > > > VF is targeted for the detach operation, all VFs are operated > > > on. It seems the VFs are not seen as individual entities > > > but a group of children in detach_meth

Re: mlx5 fails to attach after STABLE-14 source upgrade

On Mon, Dec 04, 2023 at 09:37:24AM +0800, Zhenlei Huang wrote: > > > > On Dec 2, 2023, at 3:29 AM, Dries Michiels wrote: > > > > > > > > After updating my STABLE-14 machine from somewhere quite recently (my old > > kernel that boots without error is from 14-n265716-bd7dceb27c08 somewhere >

Re: kernel crash: devctl set driver -f mlx5_core6 ppt

On Fri, Sep 29, 2023 at 04:32:30AM +, John wrote: > Hi Folks, > >Working against 13.2-STABLE. > >I have a chance to get some bhyve VMs running on new hardware > with Mellanox 100Gb/s cards. After creating VF entries with iovctl > at boottime, a devctl command to detach the mlx5

Re: About IFNET_PCP_NONE

On Mon, Aug 28, 2023 at 10:25:01PM +0800, Zhenlei Huang wrote: > > > > On Aug 28, 2023, at 3:54 PM, Konstantin Belousov > > wrote: > > > > On Mon, Aug 28, 2023 at 09:51:38AM +0800, Zhenlei Huang wrote: > >> Hi Konstantin, > >> > >

Re: About IFNET_PCP_NONE

On Mon, Aug 28, 2023 at 09:51:38AM +0800, Zhenlei Huang wrote: > Hi Konstantin, > > > I was just about going to open a PR for https://reviews.freebsd.org/D39536 and > realized I might made wrong assumption. > > I thought IFNET_PCP_NONE is something like IEEE8021Q_PCP_BE but I second why > not

Re: getaddrinfo error for existing host without requested address family

On Tue, Sep 27, 2022 at 03:53:12PM -0500, Mike Karels wrote: > I recently noticed the following behavior: > > % ping6 redrock > ping6: Name does not resolve > % host redrock > redrock.karels.net has address 10.0.2.2 > redrock.karels.net mail is handled by 10 mail.karels.net. > % ping6

Re: make NFSv3 default now on diskless

On Thu, Jun 02, 2022 at 08:03:05PM +, Rick Macklem wrote: > John-Mark Gurney wrote: > > Rick Macklem wrote this message on Thu, Jun 02, 2022 at 14:44 +: > > > John-Mark Gurney wrote: > > > > I just booted FreeBSD-current diskless, using NFS root, and I ended > > > > up having issues

Re: bind() to ::1 fails with EADDRNOTAVAIL / clang vs gcc

On Tue, Nov 23, 2021 at 09:08:39PM -0500, Jan Schaumann via freebsd-net wrote: > Hello, > > I'm observing the following strange behavior, where > trying to bind(2) a socket on "::1" fails with > EADDRNOTAVAIL, but binding in6addr_any will succeed > (and then yield a bound ::1). What's more, the

Re: Vector Packet Processing (VPP) portability on FreeBSD

On Mon, May 10, 2021 at 11:08:18AM +, Francois ten Krooden wrote: > Greetings > > We have a vested interest in high-speed IPsec VPN on FreeBSD. We have started > with the porting of VPP (https://fd.io/) to FreeBSD. > > Currently we have VPP compiled and running with netmap. The speeds we

Re: DNS using Name Service Switch module and Casper

On Sat, Jan 09, 2021 at 08:25:46PM +0300, Vasily Postnicov wrote: > Brilliant! It took me almost a day to dive into ZeroMQ to reassure > myself that there is nothing wrong with it. When I tried to write > minimal test programs which call fork after pthread_create() in all > combinations. When I

Re: DNS using Name Service Switch module and Casper

On Fri, Jan 08, 2021 at 08:17:25PM +0300, Vasily Postnicov wrote: > I have noticed that after I kill stuck ping, the process spawned with > cap_init() remains. I cannot even kill it with SIGKILL. This is the > output of procstat on such a process. > > > vasily 969 0.0 0.1 26428 6532 v0

Re: mlx5 interrupts

On Mon, Jul 20, 2020 at 04:25:27PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jul 20, 2020 at 03:38:48PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Jul 20, 2020 at 03:05:50PM +0300, Slawa Olhovchenkov wrote: > > > > > > > Currently this is idle server and totaly interrupts count for firmware

Re: mlx5 interrupts

On Mon, Jul 20, 2020 at 02:04:26PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jul 20, 2020 at 01:43:39PM +0300, Konstantin Belousov wrote: > > > On Sun, Jul 19, 2020 at 07:12:07PM +0300, Slawa Olhovchenkov wrote: > > > Can anybody explain what purpose of unnamed i

Re: mlx5 interrupts

On Sun, Jul 19, 2020 at 07:12:07PM +0300, Slawa Olhovchenkov wrote: > Can anybody explain what purpose of unnamed interrupts of Mellanox > ConnectX-5 cards? > > I am see 19 interrupts per card. I am mean last 16 is RX queue. It is more correct to describe them as completion queue interrupts, they

Re: HW timestamping e1000

On Tue, Jun 02, 2020 at 10:46:00AM +, gabriel.moy...@dlr.de wrote: > Hi everybody, > > Currently I am writing a piece of code to test HW timestamping on e1000 > during reception, which runs on FreeBSD 12, but unfortunately it seems that > it isn't working. > > The socket is created and

Re: mlx5en - PTYS reg - eth_proto_oper bit 19 not defined

On Mon, Feb 10, 2020 at 03:56:29PM -0500, Adam Peace wrote: > Thank you for the information. After searching, I found the 50GBase-KR4 > link mode is described in this patent: > https://patents.google.com/patent/US8891561. I have applied the below patch > to my local kernel and the driver appears

Re: mlx5en - PTYS reg - eth_proto_oper bit 19 not defined

On Fri, Feb 07, 2020 at 02:15:53PM -0500, Adam Peace wrote: > Hello, > > I'm using the mlx5en driver that's in the FreeBSD 11.3 tree for a Mellanox > ConnectX-4 ethernet card on an Azure VM. > > The problem that I'm seeing is that the value being retrieved from the PTYS > register for

Re: Still em(4) broken with epoch changes

On Wed, Oct 23, 2019 at 09:39:36AM +0200, Hans Petter Selasky wrote: > On 2019-10-23 09:33, Konstantin Belousov wrote: > > I tried to netboot my test box today with r353914 kernel, and still I get > > the following panic on machine attempt to start multiuser: > > > >

Still em(4) broken with epoch changes

I tried to netboot my test box today with r353914 kernel, and still I get the following panic on machine attempt to start multiuser: Feeding entropy: . lo0: link state changed to UP uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered panic: sleeping in an

Re: 11.3 tcpdump amd64 linked libs

On Fri, Aug 23, 2019 at 03:01:51PM +0100, Andrew White wrote: > Hi > > I noticed that tcpdump (amd64) for 11.3-release is linked against > additional libs than in 11.2, and also than i386 11.3 . I noticed after > upgrading from 11.2 > > Ldd shows these additional libs for amd64 11.3 , anyone

Re: Disabling 9k jumbo clusters on mce(4)

On Fri, May 03, 2019 at 03:37:11PM -0400, Garrett Wollman wrote: > < said: > > > On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote: > >> Does anyone have an easy patch to keep mce(4) from trying to use 9k > >> jumbo mbuf clusters? I think I went down this road once before but > >>

Re: Disabling 9k jumbo clusters on mce(4)

On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote: > Does anyone have an easy patch to keep mce(4) from trying to use 9k > jumbo mbuf clusters? I think I went down this road once before but > the fix wasn't as obvious as it is for the Intel drivers. (I assume > the hardware is not

Re: dhclient appears to misinterpret the exit status of dhclient-script

On Thu, Feb 07, 2019 at 08:45:32PM -0600, Nash Kaminski wrote: > Hello, > > I have been attempting to debug a peculiar issue with dhclient on a > vanilla FreeBSD 11.2 system where it appears that even if > dhclient-script returns nonzero when invoked in response to a protocol > timeout, dhclient

Re: mlx5(4) jumbo receive

On Wed, Apr 25, 2018 at 04:04:13PM -0400, Ryan Stone wrote: > On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov > <kostik...@gmail.com> wrote: > > +#ifndef MLX5E_MAX_RX_BYTES > > +#defineMLX5E_MAX_RX_BYTES MCLBYTES > > +#endif > > Why do you use a

Re: mlx5(4) jumbo receive

capitalize start of comments, > it seems that this may be the style of this code > > > commit f25c0c624177a1ca06ca051b0adb842acb66ec11 > > Author: Konstantin Belousov <konstant...@mellanox.com> > > Date: Wed Nov 22 20:14:53 2017 +0200 > > > > mlx5en: Han

Re: mlx5(4) jumbo receive

On Tue, Apr 24, 2018 at 11:55:38AM +0200, Ben RUBSON wrote: > On 24 Apr, Konstantin Belousov wrote: > > > Hello, > > the patch below is of interest for people who use Mellanox Connect-X/4 > > and 5 ethernet adapters and configure it for jumbo frames. > > Hi Konstan

mlx5(4) jumbo receive

not cause performance degradation for the normal 1500 MTU by keeping the same configuration as currently unpatched driver. I am interested in hearing about regressions (or not) caused by the change. commit f25c0c624177a1ca06ca051b0adb842acb66ec11 Author: Konstantin Belousov <konstant...@mellanox.

Re: tcpmux port opened for dual-stack results

On Sun, Feb 25, 2018 at 03:33:06PM -0500, Jan Schaumann wrote: > Hi, > > I just encountered something that befuddles me: > > On an AWS EC2 instance (ami-d0b520b8, FreeBSD 10.1-RELEASE), I noticed > that 'telnet www.google.com 80' first opens a UDP socket to google's > addresses on port 1, then

Re: memory leaks in 11.0?

On Wed, Jul 12, 2017 at 10:16:25AM +0200, Kajetan Staszkiewicz wrote: > Dnia wtorek, 11 lipca 2017 17:12:05 CEST Konstantin Belousov pisze: > > On Tue, Jul 11, 2017 at 03:56:04PM +0200, Kajetan Staszkiewicz wrote: > > > `vmstat -z` shows constantly increasing allocation

Re: memory leaks in 11.0?

On Tue, Jul 11, 2017 at 03:56:04PM +0200, Kajetan Staszkiewicz wrote: > `vmstat -z` shows constantly increasing allocation of "512" and "UMA > Slabs". Memory allocated for all pf-related things seems fine. I have > graphite graps for every `vmstat -z` and the icrease on "512" grows > in similar

Re: NFSROOT and lagg(4)

On Sat, Feb 04, 2017 at 01:44:21PM -0700, Sean Bruno wrote: > "what I want" is to pxe/netboot and then switch over to using a lagg(4) > interface that includes the interface used in the pxe/netboot boot up. > I suspect, I have to switch to MDROOT to do this, but I thought I'd ask > if anyone is

Re: sosend returning ERESTART

On Wed, Jan 18, 2017 at 10:52:02PM +, Rick Macklem wrote: > Colin Percival wrote: > >On 01/18/17 02:36, Konstantin Belousov wrote: > >> On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: > >>> Thanks, looks like that was exactly it -- if the TCP send

Re: sosend returning ERESTART

On Wed, Jan 18, 2017 at 04:37:40AM +, Colin Percival wrote: > On 01/17/17 02:06, Konstantin Belousov wrote: > > On Tue, Jan 17, 2017 at 04:57:23AM +, Colin Percival wrote: > >> I think I've tracked an NFS problem down to sosend returning ERESTART; it > >> l

Re: sosend returning ERESTART

On Tue, Jan 17, 2017 at 04:57:23AM +, Colin Percival wrote: > I think I've tracked an NFS problem down to sosend returning ERESTART; it > looks like it's easy to work around this, but I'm not sure *why* sosend is > returning ERESTART... or for that matter *how* since I can't find anywhere > in

Re: mutex usage in if_bridge vs other drivers

On Wed, Dec 07, 2016 at 05:41:51PM +0800, Sepherosa Ziehau wrote: > On Sat, Dec 3, 2016 at 3:36 PM, Chris Torek wrote: > >>... Dropping the lock is entirely the wrong thing to do -- as > >>you note, if we do, then the bridge members can change out from > >>under us. The only

Re: panic with tcp timers

On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote: > > Hi, > > On 6/20/16 9:39 AM, Gleb Smirnoff wrote: > > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote: > > J> > Comparing stable/10 and head, I see two changes that could > > J> > affect that: > > J> > > > J> > -

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Wed, Jan 27, 2016 at 12:14:02PM +0200, Boris Astardzhiev wrote: > Hello, > > I've made a few changes in the patch as recommended here starting with > the switch to ppoll(). I have a question since it's not quite clear to me > as written > in the manpage. Is it possible that ppoll() doesn't

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: > +ssize_t > +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, > +const struct timespec *__restrict timeout) > +{ > + size_t i, rcvd; > + ssize_t ret; > + > + if (timeout != NULL) { > +

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

Overall, the patch starts taking the committable shape, I only have small notes about it. On Fri, Jan 22, 2016 at 11:15:18AM +0200, Boris Astardzhiev wrote: > be>None of the above. Plain recvmsg() returns ssize_t and its len arg has > be>type size_t. That is excessively typedefed and

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Wed, Jan 20, 2016 at 10:29:47AM +0200, Boris Astardzhiev wrote: > Let me know the final decision then - whether in the existing manpages or > in new files. Decide it yourself, it is your patch. If you are fine with writing new man page, I do not object. > > jt>The Linux version has an

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: > +int > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > +{ > + int i, ret, rcvd; Shouldn't i and rcvd be unsigned as well ? Shouldn't return value also be unsigned ? > + > + if (vlen > VLEN_MAX) >

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Mon, Jan 18, 2016 at 12:37:01PM +0200, Boris Astardzhiev wrote: > Hello, > > Sorry for the delay of my reply. As far as I understand pthread_testcancel() > is not necessary in the recvmmsg syscall since cancellation is not quite > common > among apps. But if there is cancellation attempts as

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

Added threads@ where this discussion is more appropriate. On Sun, Jan 17, 2016 at 10:18:53PM +0100, Jilles Tjoelker wrote: > This will typically work (if the cancellation occurs while blocked > inside __sys_recvmsg()) but has the usual problem of relying on [EINTR]: > lost wakeups. This is

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

I am sorry for delay in answering, you will see the reason for it below. On Fri, Jan 15, 2016 at 01:53:14PM +0200, Boris Astardzhiev wrote: > kb>Big issue with the implementation is the interposing stuff, why do you > kb> need it at all ? Is it to correctly handle cancellation, to not fall > kb>

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Sat, Jan 16, 2016 at 09:56:57PM +0200, Konstantin Belousov wrote: > I am sorry for delay in answering, you will see the reason for it below. > > On Fri, Jan 15, 2016 at 01:53:14PM +0200, Boris Astardzhiev wrote: > > kb>Big issue with the implementation is the interposing

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Tue, Jan 12, 2016 at 04:53:25PM +0200, Boris Astardzhiev wrote: > Hello again, > > In my spare time I did the following simple libc-only implementation of the > syscalls. > I did some tests in a VM adapting these experiments: > https://blog.cloudflare.com/how-to-receive-a-million-packets/ > >

Re: generated files (Re: Does FreeBSD have sendmmsg or recvmmsg system calls?)

On Thu, Jan 07, 2016 at 03:07:55AM -0800, Luigi Rizzo wrote: > I wonder how complex it would be to autogenerate > at least part of the various components required > when adding a syscall like this. There are two places in libc that need updating when adding a new syscall. One is the

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Thu, Jan 07, 2016 at 03:29:23PM +0200, Boris Astardzhiev wrote: > First of all thanks for the insightful code review. > > >> + struct file *fp; > >> + cap_rights_t rights; > >> + > >> + if (fget(td, uap->s, cap_rights_init(, CAP_RECV), ) != 0) > >> + return (EBADF); >

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote: > While it was good to have the first patch as a reminder of what needs to be > done > (noticeably, discuss the various pieces to be modified and how to deal > with errors and the comments about DoS and malloc), I think that at > the

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Mon, Jan 04, 2016 at 10:17:47AM +, Mark Delany wrote: > > Why is a signal lost in the scenario you described ? > > Because the return can only indicate a signal/error *or* a batch of > messages but not both and the semantics of recvmsg() means that both > could occur. > > Don't just

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Sun, Jan 03, 2016 at 09:47:20PM +, Mark Delany wrote: > Eg, if a signal arrives after > more than zero packets have been processed by recvmmsg() what is the > correct return value? -1 or the count of messages returned? This is really not a question to consider different answers. Unix

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

On Mon, Jan 04, 2016 at 09:11:08AM +, Mark Delany wrote: > On 04Jan16, Konstantin Belousov allegedly wrote: > > On Sun, Jan 03, 2016 at 09:47:20PM +, Mark Delany wrote: > > > Eg, if a signal arrives after > > > more than zero packets have been p

Re: Kernel panics in tcp_twclose

On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote: > Hi Palle, > > On 18/09/15 11:12, Palle Girgensohn wrote: > > We see daily panics on our production systems (web server, apache > > running MPM event, openjdk8. Kernel with VIMAGE. Jails using netgraph > > interfaces [not epair]).

Re: netisr process eats 100% cpu

On Sat, Sep 12, 2015 at 11:47:45AM +0300, Dmitry Sivachenko wrote: > > > On 11 сент. 2015 г., at 20:19, hiren panchasara > > wrote: > > > > On 09/11/15 at 12:46P, Dmitry Sivachenko wrote: > >> > >>> hiren panchasara wrote: > >>> > >>> Unsure at the moment if

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

On Tue, Jul 21, 2015 at 07:17:43PM +, Mark Johnston wrote: On Tue, Jul 21, 2015 at 09:19:27AM -0700, David Wolfskill wrote: On Tue, Jul 21, 2015 at 04:39:07PM +0300, Konstantin Belousov wrote: On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote: My laptop had no problems

Re: FreeBSD sometimes uses the router for packets on the local network

On Tue, Apr 07, 2015 at 07:04:40AM +, Anton Farber wrote: On Mon, Apr 6, 2015 at 12:15 PM, Anton Farber dr_sweety_1...@hotmail.com wrote: I've opened a thread on the FreeBSD networking forum (https://forums.freebsd.org/threads/jail-fails-to-connect-to-main-host.50833/) as

Re: NFS: kernel modules (loading/unloading) and scheduling

On Wed, Feb 25, 2015 at 10:55:35PM -0500, Rick Macklem wrote: Garrett Wollman wrote: In article 388835013.10159778.1424820357923.javamail.r...@uoguelph.ca, rmack...@uoguelph.ca writes: I tend to think that a bias towards doing Getattr/Lookup over Read/Write may help performance

[Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).

kostikbel accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ freebsd-net@freebsd.org

[Differential] [Changed Subscribers] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other

kostikbel added a subscriber: kostikbel. kostikbel added a comment. Also would be nice to further split the patch into the mechanical change of the cc_exec/cc_migration macros, and the real fix(es). From what I read, the patch is correct, but it is currently noisy, which makes reading harder

Re: igb(4) panic: already enqueue

On Wed, Oct 09, 2013 at 10:56:25AM -0700, Jack Vogel wrote: Give the new driver I just committed to HEAD a try to verify/falsify a fix please. Updated driver seemingly fixed my issue with the drdb panic, thank you. The tx busdma map leakage is still there. Regards, Jack On Wed, Oct

igb(4) panic: already enqueue

On a relatively old test machine, dual-socket X7DWU supermicro, Xeon X5272, with on-board 82575EB igb controllers, running the stress2 udp blast test immediately causes the following panic: buf=0xf8001aa5c800 already enqueue at 1445 prod=1315 cons=1445 cpuid = 3 KDB: stack backtrace:

Re: igb(4) panic: already enqueue

On Sun, Sep 29, 2013 at 12:30:38AM +0300, Konstantin Belousov wrote: On a relatively old test machine, dual-socket X7DWU supermicro, Xeon X5272, with on-board 82575EB igb controllers, running the stress2 udp blast test immediately causes the following panic: buf=0xf8001aa5c800 already

Re: failed to use getifaddrs on geli code

On Sun, Feb 17, 2013 at 11:49:10AM +0330, h bagade wrote: On Sat, Feb 16, 2013 at 10:23 PM, Kevin Oberman kob6...@gmail.com wrote: On Sat, Feb 16, 2013 at 5:40 AM, h bagade baga...@gmail.com wrote: Hi all, I need to change the geli code and I want to use getifaddrs function inside

Re: 9.1-stable crashes while copying data from a NFS mounted directory

On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer wrote: On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: On Thu, Jan 24, 2013

Re: Processes' FIBs

On Tue, Jan 17, 2012 at 01:21:27PM +0100, Oliver Fromme wrote: Kostik Belousov kostik...@gmail.com wrote: The patch misses compat32 bits and breaks compat32 ps/top. Right, thank you for pointing it out! I missed it because I only have i386 for testing. I've created new patch sets for

Re: To SMP or not to SMP

On Mon, Jan 14, 2013 at 04:12:09PM -0600, Bryan Venteicher wrote: - Original Message - From: John Baldwin j...@freebsd.org To: freebsd-net@freebsd.org Cc: Konstantin Belousov kostik...@gmail.com, Bryan Venteicher bry...@daemoninthecloset.org, Peter Jeremy pe...@rulingia.com

Re: To SMP or not to SMP

On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote: On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote: - Original Message - From: John Baldwin j...@freebsd.org To: freebsd-net@freebsd.org Cc: Barney Cordoba barney_cord...@yahoo.com, Peter Jeremy

Re: To SMP or not to SMP

On Wed, Jan 09, 2013 at 03:54:43PM -0500, John Baldwin wrote: On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: --- On Wed, 1/9/13, sth...@nethelp.no sth...@nethelp.no wrote: From: sth...@nethelp.no sth...@nethelp.no Subject: Re: To SMP or not to SMP To:

Re: Fatal trap 1 [Was: Memory modified after free - by whom?]

On Sat, Dec 22, 2012 at 01:08:10PM +0200, Andriy Gapon wrote: on 22/12/2012 02:21 Garrett Cooper said the following: Fatal trap 1: privileged instruction fault while in kernel mode Fatal trap 1: privileged instruction fault while in kernel mode Unrelated to the original topic - this looks

Re: Fatal trap 1

On Sat, Dec 22, 2012 at 01:44:49PM +0200, Andriy Gapon wrote: on 22/12/2012 13:21 Konstantin Belousov said the following: This is due to the vtoslab() returning NULL. Since slabref is dereferenced later, clang tries to be helpful as usual and converts the !(p-flags PG_SLAB) case from

Re: A small cleanup patch

On Thu, Oct 18, 2012 at 04:09:33PM +0200, Andre Oppermann wrote: On 05.10.2012 01:21, Vijay Singh wrote: Folks, I came up with this while going through the lltable code. Thank you. I just purged a larger number of stray spl* from the net*/* directories. This stuff won't be backported to

Re: 82574L hangs (with r233708 e1000 driver).

Belousov kostik...@gmail.com Cc: j...@freebsd.org, Jack Vogel jfvo...@gmail.com, n...@freebsd.org Date: Friday, May 11, 2012, 6:24 PM --- On Tue, 5/8/12, Konstantin Belousov kostik...@gmail.com wrote: From: Konstantin Belousov kostik...@gmail.com Subject: Re: 82574L hangs

Re: PCI BAR mmap

On Tue, Jul 31, 2012 at 10:15:22AM -0700, Artem Belevich wrote: On Tue, Jul 31, 2012 at 5:48 AM, Venkat Duvvuru venkatduvvuru...@gmail.com wrote: Hi, How to mmap PCI BARs from userland in freebsd? In Linux the PCI BAR appears as a file in the sysfs file system. How can I access PCI BAR

Re: FreeBSD 10G forwarding performance @Intel

On Tue, Jul 17, 2012 at 02:33:24PM +0400, Alexander V. Chernikov wrote: On 17.07.2012 03:23, Konstantin Belousov wrote: On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: On 06.07.2012 10:11, Luigi Rizzo wrote: On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V

Re: FreeBSD 10G forwarding performance @Intel

On Mon, Jul 16, 2012 at 09:43:01PM +0400, Alexander V. Chernikov wrote: On 06.07.2012 10:11, Luigi Rizzo wrote: On Thu, Jul 05, 2012 at 05:40:37PM +0400, Alexander V. Chernikov wrote: On 04.07.2012 19:48, Luigi Rizzo wrote: the thing discussed a few years ago (at least the one i took out of

Re: 82574L hangs (with r233708 e1000 driver).

On Mon, May 07, 2012 at 01:44:57PM -0400, John Baldwin wrote: On Friday, May 04, 2012 6:18:19 pm Konstantin Belousov wrote: On Fri, May 04, 2012 at 11:30:22AM -0400, John Baldwin wrote: On Tuesday, May 01, 2012 12:21:21 pm Konstantin Belousov wrote: On Thu, Apr 12, 2012 at 09:38:49PM

Re: 82574L hangs (with r233708 e1000 driver).

On Fri, May 04, 2012 at 11:30:22AM -0400, John Baldwin wrote: On Tuesday, May 01, 2012 12:21:21 pm Konstantin Belousov wrote: On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote: On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: On Sunday, April 08, 2012 1:11

Re: 82574L hangs (with r233708 e1000 driver).

On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote: On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: Make sure you have any firmware

Re: Alloc Error Handling in lib/libc/rpc/svc.c

On Fri, Apr 27, 2012 at 05:48:06PM -0400, Matt Miller wrote: In an OOM condition, we noticed a couple of mem_alloc handling bugs in this file. Please let me know if a PR should be opened for these. - No NULL checks after mem_alloc()'s: SVCXPRT * svc_xprt_alloc() { SVCXPRT *xprt;

Re: 82574L hangs (with r233708 e1000 driver).

On Thu, Apr 12, 2012 at 03:40:27PM -0400, Ryan Stone wrote: On Thu, Apr 12, 2012 at 2:38 PM, Konstantin Belousov kostik...@gmail.com wrote: And, on receive, the atom board does receive interrupts, em0:rx 0 counter in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug shows

Re: 82574L hangs (with r233708 e1000 driver).

On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: Make sure you have any firmware up to the latest available, if that doesn't help let me know

82574L hangs (with r233708 e1000 driver).

I bought Intel Atom motherboard DN2800MT, which has integrated if_em LOM, reported by pciconf as em0@pci0:1:0:0: class=0x02 card=0x20128086 chip=0x10d38086 rev=0x00 hdr=0x00 82574L Gigabit Network Connection It seems that any non-trivial network activity on the interface causes reliable

Re: 82574L hangs (with r233708 e1000 driver).

On Sat, Apr 07, 2012 at 03:06:38PM -0700, Jason Wolfe wrote: On Sat, Apr 7, 2012 at 6:37 AM, Konstantin Belousov kostik...@gmail.com wrote: I bought Intel Atom motherboard DN2800MT, which has integrated if_em LOM, reported by pciconf as em0@pci0:1:0:0: class=0x02 card=0x20128086 chip

Re: 82574L hangs (with r233708 e1000 driver).

On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: Make sure you have any firmware up to the latest available, if that doesn't help let me know and I'll check internally to see if there are any outstanding issues in shared code, that will be after the weekend. I had BIOS rev. 151,

Re: Abstracting struct ifnet

On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: On Mon, Feb 20, 2012 at 18:34, Adrian Chadd adr...@freebsd.org wrote: Is the target though _binary_ compatibility? Just having a blessed method of doing accessor method things will buy more source flexibility. The KBI can stay