;if_flags & IFF_RUNNING == 0) {
>
> That's probably ((ifp->if_flags & IFF_RUNNING) == 0). Also, I'm not on
> freebsd-net or cc'ed on the PR afaik, so please cc me explicitly on
> followups if more information is
usec) macro, is there a maximum amount of time that the
driver is allowed to complete this function? I am concerned that if it takes
to too long I might run into a soft_lockup() situation.
>
> 2. Is it o.k to defer the processing in a separate in a separate
thre
my only personal experience has been with some
Mellanox 40G Ethernet parts. However, I will try to catch up on my
backlog of pending MFC's in the next week or so.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
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 +0300, Konstantin Belousov 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:25 am Konstantin Belousov wrote:
>
On Wednesday, April 25, 2012 3:30:25 pm Sean Bruno wrote:
> On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote:
> > CPU IDs are not guaranteed to be dense. However, you can use
> > CPU_FIRST() and
> > CPU_NEXT() with your static global instead.
> >
> Ah, does
he best approach might be to add a tunable to disable
igb's manual binding and instead let the default system round-robin be
preserved.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
uffers could be attached
> there.
Keep in mind that in the common case critical_enter() and critical_exit()
should be very cheap as they should just do td->td_critnest++ and
td->td_critnest--. critical_enter() should probably be inlined if KTR
is not en
duction for a couple of hours so the
> "smoke test" for this setting seems to be happy.
>
> We'll continue to adjust and test tomorrow during higher load
> conditions.
FWIW, at my current employer we run with both rxd and txd cranked up to 32k
(we had to patch the driver a
not changed anything in regard of hanging
> interface.
Does reverting 233708 make any difference? Have you tried futzing around with
kgdb when it is hung to see what state the device is in (software state at
least)?
--
John Baldwin
___
freebsd-net@fr
On Thursday, April 05, 2012 5:47:11 pm Bjoern A. Zeeb wrote:
> On 5. Apr 2012, at 18:47 , John Baldwin wrote:
>
> Hi,
>
> > The patch below adds 40G media types for what I think are the "common"
> > media
> > types we would see on FreeBSD (coul
\
{ IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) }, \
{ IFM_TOKEN | IFM_TOK_STP16,IF_Mbps(16) }, \
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
ster' if you are coming to
> the devsummit).
Actually, please don't use that page as it has moved. Instead, go to the main
wiki page for the devsummit and use the link to the page. I think it is
"Network" instead of "Networking".
--
John Baldwin
stems.com
>
>
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
--
John Baldwin
__
0 0 0 0
>
> It looks like packet count is correct (13955+48921=62876, two packets
> missed somewhere), while byte count is exact 2x more.
Yes, this is a bug. if_obytes already gets incremented in IFQ_HANDOFF(), so
the IB code doesn
On Friday, March 23, 2012 2:09:29 pm Mike Tancsa wrote:
> On 3/20/2012 2:57 PM, John Baldwin wrote:
> >>> TX when link becomes active. I've also updated it to fix resume for em
> >>> and igb to DTRT when buf_ring is used, and to not include old-style
start
> &g
On Thursday, March 22, 2012 11:00:35 am Traiano Welcome wrote:
> Hi John
>
>
>
> On 22/03/2012 14:16, "John Baldwin" wrote:
>
> >On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote:
> >> Hi List
> >>
> >> I've
has "filled" up with packets. Are you using
igb(4)? We have to crank the number of descriptors assigned to igb to the max
to workaround this at work (we get DNS timeouts during a simple boot
otherwise). hw.igb.maxtxd is the tunable you would set. The max value you
can set it to is 409
On Tuesday, March 20, 2012 1:45:32 pm Jason Wolfe wrote:
> On Thu, Mar 15, 2012 at 11:17 AM, John Baldwin wrote:
> > On Sunday, March 11, 2012 3:47:07 am Hooman Fazaeli wrote:
> >> On 3/11/2012 5:31 AM, Adrian Chadd wrote:
> >> > Are you able to post the patch here?
if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) {
> + if (more) {
> taskqueue_enqueue(adapter->tq, &adapter->que_task);
> return;
>
>
>
>
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
x27;ve also updated it to fix resume for em
and igb to DTRT when buf_ring is used, and to not include old-style start
routines at all when using multiq. It is at
http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch
--
John Baldwin
___
free
Err, normally things are merged to newer branches first (e.g. 9 before 8,
HEAD before stable, etc.).
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail
when card is not working (but after some up/down
> events) is attached.
Can you grab two snapshots after sending some traffic to it? You have several
non-zero error counters, but it would be good to see which ones are changing
while you are in this state.
--
John Baldwin
__
queue, it will drain it until empty unless it hits an
"error" condition (link went down, transmit ring full, etc.). If it
hits an "error" condition, the driver is responsible for restarting
transmit when the condition clears. I believe our drivers already
work this way now.
The
but it seems it is not.
> John, would you take a look?(NVIDIA HT MSI issue)?
It is not fully resolved. 9 has some different changes, but those changes
broke other systems. It seems MSI on NVIDIA HT systems requires a lot of
extra quirks to actually work.
--
John Baldwin
_
DR_ANY. It might be useful to break reception
> out using a separate hash/tree, rather than walking all sockets as is
> currently done, but legacy usage needs to be supported.
>
> Interestingly enough, Microsoft has probably done something similar,
> judging from things which appe
On Thursday, December 29, 2011 3:27:26 pm John Baldwin wrote:
> On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote:
> > Another bit of lock contention I ran into between a device driver doing
> > slow
> > MAC filter updates and the receive path is IF_ADD
t; shouldn't need to be true (I think).
If you really think it shouldn't occur, then commit the patch below and MFC it
to stable branches, but change the code in HEAD afterwards to add the assertion.
Then you will eventually find out if it's wrong (hopefull
On Wednesday, January 04, 2012 7:45:26 am Bjoern A. Zeeb wrote:
>
> On 3. Jan 2012, at 22:19 , Bjoern A. Zeeb wrote:
>
> > On 29. Dec 2011, at 20:27 , John Baldwin wrote:
> >> I've gone ahead with this approach. I have three separate patches that
> >>
d Intel, I'd go with Intel
> for this very reason.
OTOH, Broadcom also has a commiter on staff who helps to maintain FreeBSD
drivers (David Christensen - davidch@). There is a bxe(4) driver in 9.0
and later (albeit missing a manpage) which supports some Broadco
On Tuesday, January 03, 2012 5:14:22 pm Hiroki Sato wrote:
> John Baldwin wrote
> in <201201031608.59688@freebsd.org>:
>
> jh> > With this patch in_lifaddr_ioctl() now looks more syntactically similar
> jh> > to in6_lifaddr_ioctl(). They could look even
inm->in6m_state = MLD_IDLE_MEMBER;
- (void)mld_v1_transmit_report(inm,
-MLD_LISTENER_REPORT);
+ SLIST_INSERT_HEAD(&mli->mli_relinmhead, inm,
+ in6m_nrele);
}
break;
On Tuesday, January 03, 2012 3:44:50 pm Sergey Kandaurov wrote:
> On 4 January 2012 00:17, John Baldwin wrote:
> > On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote:
> >> On 24 December 2011 00:08, John Baldwin wrote:
> >> > The code to handle the
On Tuesday, January 03, 2012 2:36:25 pm Sergey Kandaurov wrote:
> On 24 December 2011 00:08, John Baldwin wrote:
> > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in
> > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure
> > that it us
On Tuesday, January 03, 2012 12:35:30 pm Bjoern A. Zeeb wrote:
>
> On 23. Dec 2011, at 20:08 , John Baldwin wrote:
>
> > The code to handle the SIOCGLIFADDR and SIOCDLIFADDR ioctls in
> > in6_lifaddr_ioctl() does not grab a reference to an ifnet address structure
&
On Thursday, December 29, 2011 5:55:39 pm Gleb Smirnoff wrote:
> On Thu, Dec 29, 2011 at 03:27:26PM -0500, John Baldwin wrote:
> J> - if_addr_uses.patch This changes callers of the existing macros to use
> J> either read or write locks. This is the pa
ut wanted to check if people know of an existing facility
> that might be used here?
The spinlock in question is probably the callout_mtx itself. The problem
is that you have to be able to acquire some sort of lock in the timer
interrupt to check the timer state to see if a timer thread should b
On Thursday, December 29, 2011 3:25:02 pm Pawel Jakub Dawidek wrote:
> On Thu, Dec 29, 2011 at 11:12:59AM -0500, John Baldwin wrote:
> > On Sunday, December 25, 2011 11:01:33 am Коньков Евгений wrote:
> > > Здравствуйте, John.
> > >
> > > Вы писали 20 декабр
On Thursday, December 22, 2011 11:30:01 am John Baldwin wrote:
> Another bit of lock contention I ran into between a device driver doing slow
> MAC filter updates and the receive path is IF_ADDR_LOCK(). NIC device
> drivers
> typically hold this lock while iterating the list
On Sunday, December 25, 2011 4:45:55 am Sergey Kandaurov wrote:
> On 25 December 2011 04:58, John Baldwin wrote:
> > On 12/23/11 6:38 PM, Sergey Kandaurov wrote:
> >>
> >> On 23 December 2011 23:46, John Baldwin wrote:
> >>>
> >>> I found
On Monday, December 26, 2011 11:17:28 pm Gleb Smirnoff wrote:
> On Thu, Dec 22, 2011 at 11:30:01AM -0500, John Baldwin wrote:
> J> You can find the patch for 8.x at
> J> http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
>
> Just my two pennies: for head/ patching if
p->if_oerrors++;
> Y>return (error);
> Y> }
>
> Thanks, Pyun! You can count me in as reviewer.
>
> I have also added jhb@ to Cc, the author of changed code, so that he
> can review, too.
I didn't really change it, I just unindented it when the loop
On Sunday, December 25, 2011 11:01:33 am Коньков Евгений wrote:
> Здравствуйте, John.
>
> Вы писали 20 декабря 2011 г., 16:52:44:
>
> JB> On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote:
> >> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Bald
On 12/23/11 6:38 PM, Sergey Kandaurov wrote:
On 23 December 2011 23:46, John Baldwin wrote:
I found these nits while working on the patches to convert if_addr_mtx to an
rwlock. The first change is cosmetic, it just un-inlines a TAILQ_FOREACH().
The second change is an actual bug. The code is
ia->ia_prefixmask.sin6_len);
ifra.ifra_flags = ia->ia6_flags;
+ ifa_free(ifa);
return in6_control(so, SIOCDIFADDR_IN6, (caddr_t)&ifra,
ifp, td);
}
--
John Baldwin
_
ni6_store_addrs(struct icmp6_nodeinfo *ni6, struct
return (0); /* needless to copy */
IFNET_RLOCK_NOSLEEP();
+ ifp = ifp0 ? ifp0 : TAILQ_FIRST(&V_ifnet);
again:
for (; ifp; ifp = TAILQ_NEXT(ifp, if_list)) {
--
John Baldwin
On Friday, December 23, 2011 12:13:44 pm Arnaud Lacombe wrote:
> Hi,
>
> On Thu, Dec 22, 2011 at 11:30 AM, John Baldwin wrote:
> > Another bit of lock contention I ran into between a device driver doing slow
> > MAC filter updates and the receive path is IF_ADDR_LOCK(). NI
Phase
2 locally if they need it.
You can find the patch for 8.x at
http://www.freebsd.org/~jhb/patches/if_addr_rwlock.patch
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscri
memberships;/* max memberships this socket */
struct in_multi **imo_membership; /* group memberships */
struct in_mfilter *imo_mfilters; /* source filters */
+ STAILQ_ENTRY(ip_moptions) imo_link;
};
struct ipstat {
--
John Baldwin
___
On Saturday, December 17, 2011 6:21:27 pm Pawel Jakub Dawidek wrote:
> On Mon, Dec 12, 2011 at 11:00:23AM -0500, John Baldwin wrote:
> > An update. I've sent Pawel a testing patch to see if my hypothesis is
> > correct
> > (www.freebsd.org/~jhb/patches/tcp_negwin_tes
e set to
1, 2, 4, or 8. It defaults to 2. In the 7 driver it looks like this
is a #define in sys/dev/bce/if_bcereg.h (RX_PAGES on line 6710). Try
changing RX_PAGES from 2 to 4 (or 8) and recompiling your kernel (or
bce driver) and see if that help
On Monday, October 24, 2011 8:14:22 am John Baldwin wrote:
> On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote:
> > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote:
> > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote:
>
On Friday, October 28, 2011 1:46:07 am Pawel Jakub Dawidek wrote:
> On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote:
> > On 10/26/11 22:53, John Baldwin wrote:
> > > The assertion would be triggered when the next packet arrives (as I said
> > >
On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote:
> On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote:
> > On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote:
> > > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote:
>
t code? If so, we
will need to fix this case:
/*
* Recover last window size sent.
*/
KASSERT(SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt),
("tcp_twstart negative window: tp %p rcv_nxt %u rcv_adv %u", tp,
tp->rcv_nxt, tp->r
s "on".
The ipmi driver attaching to the BMC is independent. You can have the BMC
active even though it's network channel is unavailable, so I wouldn't count
on that datapoint being meaningful.
--
John Baldwin
___
freebsd-net@freeb
On Wednesday, September 14, 2011 9:15:38 am Adrian Chadd wrote:
> On 14 September 2011 19:40, John Baldwin wrote:
>
> > You should probably commit that. I wonder if it should be a KASSERT() also
> > so
> > that it outright panics on a kernel with INVARIANTS enabled
t;ta_pending < UINT16_MAX)
> + task->ta_pending++;
> return (0);
> }
You should probably commit that. I wonder if it should be a KASSERT() also so
that it outright panics on a kernel with INVARIANTS enabled so developers
t; Particularly I'm trying to figure out how can I use all this variety of
> filters to get MPLS traffic split to different RX queues.
>
> Maybe someone can point me to the right direction?
There is another thread on net@ currently talking a good bit about this. It
started with
On Thursday, September 08, 2011 10:48:25 am K. Macy wrote:
> On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote:
> > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote:
> >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote:
> >> > Hi,
> >&g
ipulate filters, though they do not
provide explicit steering IIRC.
We would need to come up with some sort of standard interface (ioctls?) for
adding filters however.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/m
the
ones on the currently running system.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Friday, July 22, 2011 9:11:59 am Kostik Belousov wrote:
> On Fri, Jul 22, 2011 at 08:55:10AM -0400, John Baldwin wrote:
> > On Thursday, July 21, 2011 4:19:59 pm Jeremiah Lott wrote:
> > > We're seeing nfsclient deadlocks with what looks like lock order reversal
> &
s_vinvalbuf(ap->a_vp, 0, td, 1);
- /*
-* Remove the silly file that was rename'd earlier
-*/
- (sp->s_removeit)(sp);
- crfree(sp->s_cred);
- vrele(sp->s_dvp);
-
, 5155,
> 142849,0
> tcpcb: 728,25600,6, 454,
> 142849,0
> <...>
> Those ones looks ok?
Hmm, perhaps compare the 'kern.ipc.numopensockets' and 'kern.ipc.maxsockets'
tunables under load on the server?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
If
the RST arrives before you finish calling write() and close() then you will
get ECONNRESET errors from write() and close().
You can try turning off the syncache and syncookies as a test. This will
probably trigger more ECONNRESET errors in connect() (which your app will need
to retry on). However, the better fix is to track down what is causing your
connections to be dropped in the first place, e.g. if you are hitting the
limit on inpcbs (look for failures in vmstat -z output) and fix that.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
entence: usleep(30), the error disapears. But I want
> to send packets in high speed, what should I do?
>
> Btw, the packets are raw packets. So I thought maybe the kernel send some
> packets to the net interface card alc0 which doesn't work.
No, it is sending them all to
On 5/14/11 8:53 AM, Jason Hellenthal wrote:
Ivan,
I was also going to mention these threads in the previous message to
this list.
This is the thread that ended up getting committed and MFC'd from the
previous mesage.
Feb 08 John Baldwin( 73) TCP can advertise a really huge w
ump. I think if adv is negative, it's a
consequence of some other bug that we'd rather fix instead. Having a core
dump where one can examine all the TCP pcb state when rcv_adv is too big is
probably the best way to track that down.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Thursday, March 31, 2011 7:40:17 pm Stefan `Sec` Zehl wrote:
> On Wed, Mar 30, 2011 at 08:38 -0400, John Baldwin wrote:
> > There is at least one case I know of related to a bug I reported earlier
> > where a window probe from a remote connection can cause rcv_nxt to advance
>
On Monday, March 28, 2011 2:38:10 pm Stefan `Sec` Zehl wrote:
> Hi,
>
> On Mon, Mar 28, 2011 at 14:23 -0400, John Baldwin wrote:
> >
> > No, this is not really right. Your patch from your blog is the best
> > fix actually. The reason we want to let 'win'
On Monday, March 28, 2011 10:21:00 am John Baldwin wrote:
> On Saturday, March 26, 2011 10:02:12 am Stefan `Sec` Zehl wrote:
> > Hi again,
> >
> > On Fri, Mar 25, 2011 at 16:40 -0400, John Baldwin wrote:
> > > Reading some more. I'm trying to u
On Saturday, March 26, 2011 10:02:12 am Stefan `Sec` Zehl wrote:
> Hi again,
>
> On Fri, Mar 25, 2011 at 16:40 -0400, John Baldwin wrote:
> > Reading some more. I'm trying to understand the breakage in your case.
> >
> > You are saying that FreeBSD is the send
use no one has bothered to change it.
Realistically it probably won't make any noticable difference unless your
workload consists of doing lots of calls to getsockopt() but not sending any
actual traffic on the associated sockets. :) (Almost all of the other
operations on a TCP connection re
On Friday, March 25, 2011 3:41:09 pm Stefan `Sec` Zehl wrote:
> Hi,
>
> On Fri, Mar 25, 2011 at 08:25 -0400, John Baldwin wrote:
> > Ah, ok. Can you try this patch first (without the other)? If it doesn't
> > work then we can refine the patch above further.
>
>
On Thursday, March 24, 2011 7:02:35 pm Stefan `Sec` Zehl wrote:
> Hi,
>
> I just subscribed to this list, so sorry if I missed some previous
> discussion on this.
>
> On Thu, Mar 24, 2011 at 16:15 -0400, John Baldwin wrote:
> [...]
> > Otherwi
On Thursday, March 24, 2011 3:51:14 pm John Baldwin wrote:
> On Thursday, March 24, 2011 3:21:24 pm Doug Barton wrote:
> > http://blogmal.42.org/tidbits/tcp-bug.story
> >
> > $someone really needs to take a look at this. :)
>
> This is the same bug I reported back
7892.html
His patch may be the more correct fix though. I have two other TCP bugs also
awaiting review that I posted on the same day.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To un
you leave the nfs_reserved_port_only option and have it toggle the -n
option to mountd? Whatever the outcome, I think we need to collapse the
multiple rc.conf variables (mountd_weak_authentication and
nfs_reserved_port_only) down to 1 variable and have the kernel default to
requiring a privileged
gt;
> > ___
> > freebsd-sta...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
>
>
low */
#defineTF_LASTIDLE 0x04/* connection was previously
idle */
Index: netinet/tcp_output.c
=======
--- netinet/tcp_output.c(.../mirror/FreeBSD/stable/7/sys)
(revision 219412)
+++ netinet/tcp_output.c
indow, etc.). This
happens each time the receiver wakes up and drains a full socket buffer. The
tcp_good.out dump shows the stream with the patch applied. A similar event of
the receiver draining a full buffer starts at packet 83 and it sends a single
ACK for each "real" window update
p->rcv_adv - tp->rcv_nxt))
+ if (SEQ_GT(tp->rcv_adv, tp->rcv_nxt) &&
+ recwin < (long)(tp->rcv_adv - tp->rcv_nxt))
recwin = (long)(tp->rcv_adv - tp->rcv_nxt);
if (recwin > (long)TCP_MAXWIN << tp->rcv
> 190 {
> 191 if (hook->hk_magic != HK_MAGIC) {
> 192 printf("Accessing freed hook ");
> 193 dumphook(hook, file, line);
> 194 }
> 195 hook->lastline = line;
> (gdb) x/i 0x
gt; get a panic:
Did you compile your module with VIMAGE enabled?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Monday, January 31, 2011 9:40:09 pm Lawrence Stewart wrote:
> On 02/01/11 04:17, John Baldwin wrote:
> > Somewhat related fallout to the bug reported on security@ recently, I think
> > this KASSERT() in tcp_output() is bogus:
> >
> >
> > KASSERT(len
On Tuesday, February 01, 2011 12:53:36 am Eugene Grosbein wrote:
> On 31.01.2011 22:46, John Baldwin wrote:
>
> >># gdb kernel
> >> GNU gdb 6.1.1 [FreeBSD]
> >> Copyright 2004 Free Software Foundation, Inc.
> >> GDB is free software, covered by the GNU
re stored in a separate mbuf chain in the in pcb
(inp_options) that is passed as a separate argument to ip_output(). Given
that, I would think that m_length() should not reflect ipoptlen since it
should not include IP options in that chain?
--
John Baldwin
On Monday, January 31, 2011 1:31:54 am Eugene Grosbein wrote:
> On 15.01.2011 01:37, John Baldwin wrote:
> > On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
> >> On 14.01.2011 18:46, Mike Tancsa wrote:
> >>
> >>>> I'm using mpd 5.5 o
sysctl
> input in order to accept only a specific values? In my case only '1',
> '2' and '5'.
Use a SYSCTL_PROC and write your own handler that does a sanity check on the
value set by userland and returns EINVAL if the value is not correct.
--
Joh
The following reply was made to PR kern/154214; it has been noted by GNATS.
From: John Baldwin
To: freebsd-am...@freebsd.org
Cc: "Vladislav V. Prodan" ,
freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/154214: Panic when creating stf interface
Date: Mon, 24 Jan 2011 08:11:31
of the 'instruction pointer' value
above after the colon (:) and then send the output of that in your e-mail to
the list. This allows us to the source line at which the fault occurred.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
The devat hook I'm glad to see. I already have a local change that is very
similar so that a parent ifnet can find child interfaces via vlan tag ID.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
u need to wait for a
connection and dequeue the socket that connected and then call soaccept() on
that new socket. Look at kern_accept() in sys/kern/uipc_syscalls.c.
I wonder though if you wouldn't rather be calling soconnect instead? Do you
really need to list
et as I was worried about applications
such as this needing to be updated (such as dhcpd for example). I had thought
that I had not merged the kernel change to 8 though, that it was just in 9?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
again Intel or Broadcom). How was the value 32 picked? Anybody knows the
> reasoning behind them?
It may very well be a chip-dependent limitation due to something in the
hardware or
firmware of the nfe(4) devices.
--
John Baldwin
___
freebsd-ne
On Wednesday, December 08, 2010 11:29:49 am Kim Culhan wrote:
> On Wed, Dec 8, 2010 at 9:23 AM, John Baldwin wrote:
>
> > On Tuesday, December 07, 2010 5:17:30 pm Kim Culhan wrote:
> > > Had been running a wireless bridge for some months in rc.conf:
> > >
> >
> ifconfig_bridge0="addm wlan0 addm re1 up"
>
> Tried replacing the re device with em, no change.
>
> Any help is very greatly appreciated.
Most likely the bridge0 device is created by /etc/rc.d/netif before the wlan0
device is created, so when the sys
instantly work.
> I've had no problems with iSCSI over the same setup, and dhcp packets are
> getting trough properly.
> I've moved those last two vlans to bce0 and they work ok, but I'm a bit
> locked on why this is happening.
> Are t
On Tuesday, August 03, 2010 10:29:11 am John Baldwin wrote:
> Currently vlan(4) interfaces have an interface type of IFT_ETHER instead of
> IFT_L2VLAN in the sockaddr_dl that is returned by getifaddrs(3). If you do a
> route lookup for a route that goes across a vlan then the so
201 - 300 of 382 matches
Mail list logo
