Hi,
As it became evident, ix is driven by Low Latency Interrupts
on 82599 to do all sorts of processing instead of the regular
Rx/Tx queue interrupts. LLI is an additional facility that
is aimed to do out of band signalling for certain conditions.
Therefore it has it's own interrupt moderation se
On Wed, Feb 01, 2012 at 17:12 +, Miod Vallat wrote:
> > Machine needs an update anyway, but does anyone know offhand what
> > this might be?
>
> Dereference of a NULL (or invalid) function pointer, coupled with the
> lack of smarts of the ddb code. (part of my ddb todolist somewhere)
>
> Miod
On Sat, Jan 28, 2012 at 3:54 AM, Brynet wrote:
> Remove redundant call to vr_reset, it gets called in vr_init.
>
> -Bryan.
>
I agree that this is pointless. OK mikeb
On Sat, Jan 28, 2012 at 12:06 PM, Stuart Henderson
wrote:
> Any comments? ("bleurgh" is implicitly assumed).
> OK? This mail was sent through a router running it.
>
hi,
if you remove pp_fastq, why don't i see it being removed from the header
file?
On Fri, Jan 20, 2012 at 3:08 PM, Christian Ehrhardt
wrote:
> Hi!
>
> the ix(4)-Driver stores a pointer to the pci_attach_args structure (as
> passed to ixgbe_attach) in its softc. However, the pci_attach_args
> structure lives on the stack somewhere in autoconf, i.e. its contents are
> undefined a
Hi,
If there's no objections, I'm going to commit it soon.
Thanks
On Tue, Dec 20, 2011 at 15:30 +0100, Mike Belopuhov wrote:
> hi,
>
> hardware vlan tagging/stripping got broken with the driver update.
> freebsd people have changed the code to handle events from the v
hi,
hardware vlan tagging/stripping got broken with the driver update.
freebsd people have changed the code to handle events from the vlan(4)
pseudo-device into the hardware driver. so when you configure new
vlan a special function is called and driver can setup a vlan filtering
table. because o
this is an improved diff that addresses the problem with forced
unmount of the ntfs filesystem in situations like the one described
here: http://marc.info/?l=openbsd-bugs&m=132257956328474&w=2
ntfs keeps a bunch of vnodes opened and marked as VSYSTEM including
the mount point: it's usecount is 1
On Mon, Dec 19, 2011 at 21:46 +0100, Mike Belopuhov wrote:
> On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> > - Original Message -
> > | Hi All,
> > |
> > | Today is our semester maintenance day and we've upgraded our backup
> >
i've decided to rewrite the description to faciliate the review
process.
currently icmp6->icmp translation fails because of the incorrect
"icmp direction" check in pf_icmp_state_lookup. first of all it
checks all icmp packets except for the "echo reply". the reasons
for this are unknown. it wor
On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> - Original Message -
> | Hi All,
> |
> | Today is our semester maintenance day and we've upgraded our backup
> | bridge firewall to the Dec. 15, 2011 snapshot available from
> | ftp.openbsd.org and I'm getting this odd error wh
got an ok from henning, anyone else cares to comment?
On Tue, Dec 13, 2011 at 00:40 +0100, Mike Belopuhov wrote:
> updating regress tests, i've noticed that some of the optimizer
> tests are failing with additional (unoptimized) rules popping out.
> digging deeper has shown that i
On Sat, Dec 17, 2011 at 8:48 AM, Loganaden Velvindron
wrote:
> command is initialised in main but not freed
> before exit.
>
because there's no reason to do it. when program terminates
all resources are returned to the operating system.
updating regress tests, i've noticed that some of the optimizer
tests are failing with additional (unoptimized) rules popping out.
digging deeper has shown that is indeed a bug introduced by af-to
(sorry!). the fix is simple though.
ok?
Index: parse.y
still looking for ok's for this version of the diff.
although i've got mcbride's and claudio's oks for the
older version, this is the one i consider correct.
On Fri, Oct 28, 2011 at 3:59 PM, Mike Belopuhov wrote:
> hi,
>
> icmp6->icmp translation does
pfctl should not infer the af-to behavior from the af/naf
difference. instead, we should be clear that this is an
af-to rule. essentially this diff converts FOM_AFTO marker
into a rule flag PFRULE_AFTO so that we don't rely on
ambiguous checks (like r->af != r->naf) when setting things up.
also,
On Thu, Dec 8, 2011 at 7:25 PM, Aaron Stellman wrote:
> Hello there,
>
> Is there any good reason why most of .c files need to have externs for
> ServerOptions/Options? Any reason not to have them in appropriate header
> files?
>
hi,
patches for portable openssh should go to the portable openssh
On Thu, Dec 08, 2011 at 17:46 +0100, Mike Belopuhov wrote:
> there are some m_freem's missing in the error code paths.
> i guess that's because freebsd code is a bit different
> and we didn't look closely at it.
>
> ok?
>
> @@ -2601,6 +2604,8 @@ no_split:
>
On Fri, Nov 25, 2011 at 15:02 +0100, Mike Belopuhov wrote:
> hi,
>
> i've spent a week trying to fix performance regression in ix(4)
> since the introduction of the new driver and this is where i'm
> right now. with the following change machine is able to sustain
>
On Sun, Nov 27, 2011 at 11:26 +0100, Mike Belopuhov wrote:
> On Sun, Nov 27, 2011 at 8:58 AM, Claudio Jeker wrote:
> > On Fri, Nov 25, 2011 at 02:43:38PM +0100, Mike Belopuhov wrote:
> >> shaves off some bus read/write operations.
> >> tested on 82598 and 82599. ok?
>
we don't do intel i/oat and don't set up parameters for the
tcp timer interrupts, therefore there's no reason we should
enable the interrupt itself.
ok?
diff --git dev/pci/ixgbe_type.h dev/pci/ixgbe_type.h
index 601c6d5..b59 100644
--- dev/pci/ixgbe_type.h
+++ dev/pci/ixgbe_type.h
@@ -1318,7
we need to always schedule another rx ring refill callout
in case we fail to do it at the spot. previously what would
happen is that say we have 2 clusters on the rx ring and we
schedule an rxrefill callout that fails to update the ring.
then we still have those 2 clusters around. under heavy
loa
there are some m_freem's missing in the error code paths.
i guess that's because freebsd code is a bit different
and we didn't look closely at it.
ok?
diff --git dev/pci/if_ix.c dev/pci/if_ix.c
index 4468401..8ab83f8 100644
--- dev/pci/if_ix.c
+++ dev/pci/if_ix.c
@@ -2547,7 +2547,7 @@ ixgbe_get_b
On Sun, Nov 27, 2011 at 8:58 AM, Claudio Jeker wrote:
> On Fri, Nov 25, 2011 at 02:43:38PM +0100, Mike Belopuhov wrote:
>> shaves off some bus read/write operations.
>> tested on 82598 and 82599. ok?
>
> On what information is this based? The intel driver in .Fx does not do
&
On Fri, Nov 25, 2011 at 3:02 PM, Mike Belopuhov wrote:
> hi,
>
> i've spent a week trying to fix performance regression in ix(4)
> since the introduction of the new driver and this is where i'm
> right now. with the following change machine is able to sustain
>
On Fri, Nov 25, 2011 at 2:48 PM, Mike Belopuhov wrote:
> checksum fix from reyk (rev1.31) was lost during update:
>
> Fix the IP ckecksum offloading logic that disables and breakes offloading
> if the packet is neither TCP nor UDP because of an erroneous "default" case.
>
On Fri, Nov 25, 2011 at 2:45 PM, Mike Belopuhov wrote:
> lost while upgrading the driver. originally from claudio in rev1.46.
> tested on 82599 w/ sfp+. ok?
>
regenerated w/o git prefixes:
diff --git dev/pci/if_ix.c dev/pci/if_ix.c
index e3b575f..cec0c99 100644
--- dev/pci/if_ix.c
++
On Fri, Nov 25, 2011 at 2:43 PM, Mike Belopuhov wrote:
> shaves off some bus read/write operations.
> tested on 82598 and 82599. ok?
>
regenerated without git prefixes. should apply cleanly now.
diff --git dev/pci/if_ix.c dev/pci/if_ix.c
index 2c0d8e0..e3b575f 100644
--- dev/pci/if_ix.
hi,
i've spent a week trying to fix performance regression in ix(4)
since the introduction of the new driver and this is where i'm
right now. with the following change machine is able to sustain
760kpps and reach 9Gbit/s of forwarding performance.
(the other change that is very likely affecting t
checksum fix from reyk (rev1.31) was lost during update:
Fix the IP ckecksum offloading logic that disables and breakes offloading
if the packet is neither TCP nor UDP because of an erroneous "default" case.
No functional change in the default build because IP checksum offloading
is currently disa
lost while upgrading the driver. originally from claudio in rev1.46.
tested on 82599 w/ sfp+. ok?
diff --git a/dev/pci/if_ix.c b/dev/pci/if_ix.c
index e3b575f..cec0c99 100644
--- a/dev/pci/if_ix.c
+++ b/dev/pci/if_ix.c
@@ -635,8 +635,7 @@ ixgbe_init(void *arg)
struct ifnet*ifp = &sc-
shaves off some bus read/write operations.
tested on 82598 and 82599. ok?
diff --git a/dev/pci/if_ix.c b/dev/pci/if_ix.c
index 2c0d8e0..e3b575f 100644
--- a/dev/pci/if_ix.c
+++ b/dev/pci/if_ix.c
@@ -917,7 +917,7 @@ ixgbe_legacy_irq(void *arg)
struct tx_ring *txr = sc->tx_rings;
st
On Fri, Oct 28, 2011 at 12:09 PM, Tom Murphy wrote:
> You guys might want to add a note to current.html that from October
> 13 2011, the NAT updates have made it impossible to not use an address
> family in a nat-to statement.
>
> The following statement fails now:
>
> match out on egress from ($i
On Mon, Oct 10, 2011 at 7:37 AM, patrick keshishian wrote:
> I know nothing of IPv6 stuff, but is this line removal
> a typo or an intended change?
>
there's a bzero call above.
you didn't remove an ip address from ral0 after bringing it down.
On Sun, Oct 2, 2011 at 5:13 PM, David Coppa wrote:
> Am I stupid or there's a bug with routing?
>
> This is what I've found when I was trying to switch from the internal
> wireless card in my laptop to an external usb wireless adap
it doesn't.
On Fri, Aug 19, 2011 at 6:44 PM, Gaurav Kansal wrote:
> Any idea if it supports transport mode? That seems to be missing.
>
> Regards,
> Gaurav Kansal
> +91 98454 22400
> http://gkansal.blogspot.com
>
>
>
>
> On Wed, Jul 13, 2011 at 7:14 AM, Mike
On Wed, Aug 10, 2011 at 17:39 +0200, Peter J. Philipp wrote:
> Hi,
>
> I'm reading through lib/libc/gen/getpwent.c and I found this right at the
> end of the file:
>
> ---
> /* See if there's any data left. If so, read in flags. */
> if (data.size > (p - (char *)data.data)) {
>
On Wed, Aug 10, 2011 at 21:49 +0900, Ryan McBride wrote:
> On Wed, Aug 10, 2011 at 01:07:28PM +0200, Henning Brauer wrote:
> > this is indeed the way it was supposed to work.
>
> I dissagree. This is not at all what my understanding was of how it was
> supposed to work. You'd have to talk to dhart
On Tue, Aug 09, 2011 at 22:24 +0200, Alexander Bluhm wrote:
> Consider these two rules:
>
> pass quick 'special match condition' 'do something' keep state
> pass quick 'more general match condition' 'do something else'
>
> With your change, the special packets, matching both rules, would
> match
Hi,
I'd like to propose the following change in the pf ruleset evaluation:
Index: pf.c
===
RCS file: /home/cvs/src/sys/net/pf.c,v
retrieving revision 1.770
diff -u -p -r1.770 pf.c
--- pf.c3 Aug 2011 12:28:40 - 1.770
On Sat, Aug 06, 2011 at 20:05 +0200, Alexander Bluhm wrote:
> On Fri, Aug 05, 2011 at 08:19:21PM +0200, Mike Belopuhov wrote:
> > opinions?
>
> Although there are other opinions, I think we should not reinvent
> the wheel and use KAME where apropiate. So we
nd solves a bunch of problems
with assigning addresses that don't belong us.
opinions?
On Thu, Aug 04, 2011 at 23:29 +0200, Mike Belopuhov wrote:
> i saw what kame did. be my guest and try to port that.
>
> On Thu, Aug 4, 2011 at 11:23 PM, Alexander Bluhm
> wrote:
> > On
On Thu, Aug 4, 2011 at 11:23 PM, Alexander Bluhm
wrote:
> On Thu, Aug 04, 2011 at 05:06:24PM +0200, Mike Belopuhov wrote:
>> I'm not sure it's a desired behavior and afaik it's not possible
>> to achieve this with IPv4 sockets without the need to be a root.
>>
i saw what kame did. be my guest and try to port that.
On Thu, Aug 4, 2011 at 11:23 PM, Alexander Bluhm
wrote:
> On Thu, Aug 04, 2011 at 05:06:24PM +0200, Mike Belopuhov wrote:
>> I'm not sure it's a desired behavior and afaik it's not possible
>> to achieve this
On Thu, Aug 04, 2011 at 17:06 +0200, Mike Belopuhov wrote:
> Hi,
>
> Currently it's possible to assign *any* IPv6 source address to
> the datagram sent out by the unprivileged process by supplying
> a IPV6_PKTINFO control message to the sendmsg(2).
>
> I'm not s
Hi,
Currently it's possible to assign *any* IPv6 source address to
the datagram sent out by the unprivileged process by supplying
a IPV6_PKTINFO control message to the sendmsg(2).
I'm not sure it's a desired behavior and afaik it's not possible
to achieve this with IPv4 sockets without the need t
On Mon, Aug 1, 2011 at 11:59 PM, Alexander Bluhm
wrote:
> On Wed, Jul 27, 2011 at 12:44:21AM +0200, Alexander Bluhm wrote:
>> On Fri, May 20, 2011 at 11:54:09AM +0200, Camiel Dobbelaar wrote:
>> > I'll spend some more time on this, but maybe there's an IPv6 guru that
>> > can lend a hand? :-)
>>
no.
On Tue, Jul 12, 2011 at 1:47 PM, Gaurav Kansal wrote:
> Hi
>
> Is there a list available of supported/missing features in iked?
>
> Regards,
> Gaurav Kansal
On Sat, Jul 02, 2011 at 11:04 -0400, Ted Unangst wrote:
> On Mon, Jun 27, 2011, Henry Precheur wrote:
> > According to pthread_key_create(3): Upon key creation, the value NULL is
> > associated with the new key in all active threads.
> >
> >
> > When pthread_key_create reuse an existing key, the
On Mon, Jun 20, 2011 at 20:22 +0200, Claudio Jeker wrote:
> On Mon, Jun 20, 2011 at 06:30:11PM +0200, Mike Belopuhov wrote:
> > Now that we support SO_RTABLE on the socket level, it makes
> > sense to cleanup the tree. OK?
> >
>
> The if (getsockopt() && errn
On Mon, Jun 20, 2011 at 13:22 +0200, Mark Kettenis wrote:
> > Date: Mon, 20 Jun 2011 11:04:24 +0200
> > From: Mike Belopuhov
> >
> > hi,
> >
> > the hibernate_machdep.c file depends on the acpi so it would be
> > nice if we excluded this file if k
Now that we support SO_RTABLE on the socket level, it makes
sense to cleanup the tree. OK?
Index: sbin/ping/ping.c
===
RCS file: /home/cvs/src/sbin/ping/ping.c,v
retrieving revision 1.88
diff -u -p -r1.88 ping.c
--- sbin/ping/ping.c
hi,
the hibernate_machdep.c file depends on the acpi so it would be
nice if we excluded this file if kernel config doesn't reference
acpi. a simple fix that establishes the dependency is below. ok?
Index: arch/i386/conf/files.i386
==
On Fri, May 20, 2011 at 06:24 -0600, David Coppa wrote:
> Hi all,
>
> OpenBSD-current snapshot dated 16-May-2011:
> I get an always-reproducible panic with softraid crypto and
> kern.bufcachepercent >= 75, when untarring a tarball of the
> complete source tree.
>
> The disk layout is the followin
On Fri, May 20, 2011 at 4:04 AM, Ariane van der Steldt
wrote:
>
> AVL trees have a difference of max 1 between the longest and shortest
> path to a leaf, whereas RB-trees have at max the longest path be double
> the length of the shortest path.
> I.e. work case lookups require traversal of
>ln
On Thu, May 19, 2011 at 7:25 PM, Michael Pounov wrote:
> Not see differences in results with performance from RB tree vs AVL,
> but right solution for problems when we have choice between algorithms.
>
if you don't see any difference then what's the point in having them
both available? how are
On Thu, May 19, 2011 at 7:12 PM, Thordur Bjornsson wrote:
> On Thu, May 19, 2011 at 07:52:44PM +0300, Michael Pounov wrote:
>> Add AVL tree implementation and merge few RB tree related macros.
>>
>> If you have comments or any claims, please send me feedback
>> and I will fix them.
> cool. but tec
On Mon, May 16, 2011 at 8:20 PM, Jason McIntyre wrote:
>
> what pf keyword addition?
>
Andreas asked this question in the last sentence of his email:
> Is there a key word planned for this icmp6 code which could be used in PF?
On Mon, May 16, 2011 at 6:45 PM, Jason McIntyre wrote:
> On Sun, May 08, 2011 at 08:27:31AM +0100, Jason McIntyre wrote:
>> On Sat, May 07, 2011 at 09:29:21PM +0200, Andreas Bartelt wrote:
>> > Hello,
>> >
>> > I've noticed a typo in the icmp6(4) man page regarding icmp6 type 4 code
>> > 2. Diff i
On Fri, Apr 08, 2011 at 18:27 -0400, Brad wrote:
> On Thu, Apr 07, 2011 at 09:00:45PM -0400, Brad wrote:
> > Some _LP64 ifdef's leftover from rev 1.1. They appear to be unnecessary
> > since this code is only for amd64 anyway and thus a 64-bit arch.
> >
> >
>
> Actually using the same if defined
On Fri, May 13, 2011 at 11:50 AM, Otto Moerbeek wrote:
> On Fri, May 13, 2011 at 11:39:01AM +0200, Mike Belopuhov wrote:
>
>> On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis
wrote:
>> >> From: Vadim Zhukov
>> >> Date: Fri, 13 May 2011 13:10:10 +0400
>>
On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis wrote:
>> From: Vadim Zhukov
>> Date: Fri, 13 May 2011 13:10:10 +0400
>>
>> Hello all.
>>
>> Looks like there is a typo in ioctl number...
>
> What makes you think this is a typo?
>
there are two ioctls with the same command number:
#define BIOCDI
On Tue, May 3, 2011 at 9:24 PM, Claudio Jeker
wrote:
> On Tue, May 03, 2011 at 07:53:56PM +0200, Mike Belopuhov wrote:
>> hi,
>>
>> recently me and jsg have figured out that a traffic burst can kill
>> your interface (deplete the rx ring) if you're using ipsec. t
On Tue, May 3, 2011 at 9:56 AM, Stuart Henderson wrote:
> On 2011/05/02 22:28, Lawrence Teo wrote:
>> The DIOCNATLOOK example program at the end of the pf(4) man page
>> uses memset(3), but string.h is not included. The following diff
>> fixes this. Any thoughts?
>
> That change is correct but I'm
hi,
recently me and jsg have figured out that a traffic burst can kill
your interface (deplete the rx ring) if you're using ipsec. the
problem is that there's no limit on number of outstanding crypto
operations. every job contains a pointer to a cluster that comes
from the nic driver.
under hig
On Mon, Apr 11, 2011 at 16:59 +0200, Mike Belopuhov wrote:
> On Thu, Apr 07, 2011 at 18:58 +0200, Mike Belopuhov wrote:
> > this allows us to get rid of the nasty NATLOOKUP ioctl and get
> > the original server address right from the socket. also this
> > paves the way t
On Mon, Apr 11, 2011 at 19:52 +0200, Claudio Jeker wrote:
> On Mon, Apr 11, 2011 at 07:18:13PM +0200, Mike Belopuhov wrote:
> > On Mon, Apr 11, 2011 at 18:51 +0200, Claudio Jeker wrote:
> > > On Mon, Apr 11, 2011 at 04:52:23PM +0200, Mike Belopuhov wrote:
> > > >
On Mon, Apr 11, 2011 at 18:51 +0200, Claudio Jeker wrote:
> On Mon, Apr 11, 2011 at 04:52:23PM +0200, Mike Belopuhov wrote:
> > hi,
> >
> > currently there's no way to figure out what rdomain the diverted
> > connection came from. this diff introduces a ne
On Mon, Apr 11, 2011 at 7:08 PM, Alexander Bluhm
wrote:
> On Mon, Apr 11, 2011 at 04:52:23PM +0200, Mike Belopuhov wrote:
>> currently there's no way to figure out what rdomain the diverted
>> connection came from. this diff introduces a neat hack that reyk
>> and
On Thu, Apr 07, 2011 at 18:58 +0200, Mike Belopuhov wrote:
> this allows us to get rid of the nasty NATLOOKUP ioctl and get
> the original server address right from the socket. also this
> paves the way to the transparent ftp-proxy mode.
>
> if you will like this diff and nobod
hi,
currently there's no way to figure out what rdomain the diverted
connection came from. this diff introduces a neat hack that reyk
and i have invented. from the programmer's perspective this is
as simple as calling getsockopt(SO_RTABLE) on the "accepted" socket.
from the kernel perspective ea
please disregard this diff. it's wrong.
On Thu, Apr 7, 2011 at 6:58 PM, Mike Belopuhov wrote:
> this allows us to get rid of the nasty NATLOOKUP ioctl and get
> the original server address right from the socket. also this
> paves the way to the transparent ftp-proxy mode.
>
&
this allows us to get rid of the nasty NATLOOKUP ioctl and get
the original server address right from the socket. also this
paves the way to the transparent ftp-proxy mode.
if you will like this diff and nobody objects, i'll try to rip
NATLOOKUP out from the other places too.
note, that it requi
bpf is not called on multicast/broadcast packets arriving to the carp
interface. this allows us to setup drop filters and allows tcpdump to
show all the packets.
OK/not-OK?
Index: ip_carp.c
===
RCS file: /home/cvs/src/sys/netinet/ip
On Fri, Mar 11, 2011 at 14:45 -0800, Philip Guenther wrote:
> On Fri, 11 Mar 2011, Mike Belopuhov wrote:
> > recent commit to pirofti made me wonder why don't we take an advantage
> > of the 64 bit bswap instruction on amd64?
>
> Here's a revised diff with two ch
recent commit to pirofti made me wonder why don't we take an advantage
of the 64 bit bswap instruction on amd64?
Index: arch/amd64/include/endian.h
===
RCS file: /home/cvs/src/sys/arch/amd64/include/endian.h,v
retrieving revision 1.3
On Fri, Feb 04, 2011 at 14:53 +, emeric boit wrote:
> Hello,
>
> After doing a clean install of OpenBSD 4.8 (AMD64) on an IBM x3550 M3,
> I find
> the
> system randomly panics after a period of use.
> uvm_fault(0x80cc8360, 0x8000149b7000, 0, 1) -> e
> kernel: page
> fault trap, co
On Wed, Mar 2, 2011 at 11:54 AM, Okan Demirmen wrote:
> I'm not certain this is wanted, but I said I would forward along this
> very simplisitc patch, so here it is. If something like this is wanted,
> it can be re-worked to take multiple args to -e and such, but again,
> only if this is deemed n
Currenlty socket man page mentions long dead netns stack (PF_NS)
when talks about SOCK_SEQPACKET which is only valid for AF_BLUETOOTH
these days. Also it mentions SOCK_RDM that is an unused SysV compat
goo.
I think it make sense to update a reference for SOCK_SEQPACKET and
don't mention SOCK_RDM
On Thu, Feb 24, 2011 at 11:42 +1000, David Gwynne wrote:
> you want to look up disks attached to an mpi by bus addressing, not
> which raid volume you happen to be up to.
>
> before this diff i got:
>
> dlg@hotspare dlg$ sudo bioctl mpii0
> Volume Status Size Device
> mpii0 0 Onl
On Thu, Feb 17, 2011 at 14:00 +0100, Mike Belopuhov wrote:
> in the simple setup, like the one described in the pr 6564,
> pf won't rewrite source address for the icmp errors (like
> destination unreachable) when doing rdr-to.
>
> this diff fixes issue for me and a pr origina
some sites enforce a minimum reply length, so when you send them
8 bytes of user data, they reply with your 8 bytes and zero padding
to the minumum reply length. our ping6 code then fails to compare
data against its internal buffer because it doesn't expe
On Sun, Feb 20, 2011 at 10:08 PM, Mark Kettenis
wrote:
> And it turns out the xf86-video-ati driver has a bug very similar to
> the one in xf86-video-r128. This makes my XVR-100 restore the video
> mode a blade2k.
>
this fixes the named problem for me on mac mini g4 with radeon 9200.
thanks!
On Fri, Feb 18, 2011 at 03:44 +, Jacob Meuser wrote:
> at line 190, if nports == 0, 'hub' will be NULL at line 334, and
> 'if (hub->ports)' will be a NULL dereference.
>
> found by Amit Kulkarni using clang.
>
makes perfect sense. ok mikeb
> --
> jake...@sdf.lonestar.org
> SDF Public Acce
On Thu, Feb 10, 2011 at 14:25 +0100, Lukasz Czarniecki wrote:
> Hi
>
> I've bought a Dell R310 with H200 raid controller reported in dmesg as:
> Symbios Logic SAS2008. It uses mpii driver and has two hard drives
> configured in RAID 1.
>
> Now it seems to work fine but i still have a problem with
in the simple setup, like the one described in the pr 6564,
pf won't rewrite source address for the icmp errors (like
destination unreachable) when doing rdr-to.
this diff fixes issue for me and a pr originator. comments?
do we want to put it into 4.9?
Index: pf.c
===
On Sat, Feb 5, 2011 at 2:54 PM, Alexander Bluhm
wrote:
> On Sat, Feb 05, 2011 at 02:03:25PM +0100, Mike Belopuhov wrote:
>> we can check if "af == inet" in icmp case obviously, but how and why
>> can we end up with af == inet6 and an icmp payload (or af == inet
>
On Sat, Feb 5, 2011 at 1:50 PM, Alexander Bluhm
wrote:
> I think there is a missing check and fallthrough in the icmp case.
>
> The logic should be
>
> if (proto == tcp) {
> } else if (proto == udp) {
> } else if (proto == icmp && af == inet) {
> } else if (proto == icmp6 && af == inet6) {
> } els
hi, in pf_translate, when we're changing addresses for the icmp messages
there's an unjustified fallthrough in the IPPROTO_ICMPV6 case. in fact
this doesn't seem to harm anything because default case performs the
same operation. note that pd->ip_sum is null in ipv6 case so pf_change_a6
just punch
On Mon, Jan 31, 2011 at 1:35 PM, Brad wrote:
> Also that second chunk of alc_newbuf from mikeb@ doesn't look right.
> There is a logic error with the way its written but it looks like it should
> be moved further down within the function.
>
there's a call to the bus_dmamap_unload further down tha
ork does not come back when plugging a network cable
> >- watchdog timeouts
>
> Mike Belopuhov found another logic bug, updated diff follows.
>
> cf http://marc.info/?l=openbsd-tech&m=129639859909043&w=2
>
> -int alc_match(struct device *, void *, void *);
> +
On Fri, Jan 28, 2011 at 09:03 +0100, Gabriel Linder wrote:
> On 01/27/11 09:13, Gabriel Linder wrote:
> >When booting 4.9-beta/amd64 without a network cable plugged, I get
> >a lot of splassert failures.
> >
> >After changing kern.splassert to 3 I was able to get the following
> >trace (get with dm
On Thu, Jan 27, 2011 at 1:14 AM, Christiano F. Haesbaert
wrote:
>
> The sender/client is pretty stupid, it sends as much as possible until a
> ENOBUFS
> is reached, then it sleeps for 50ms, I'm not sure this is acceptable, we don't
> have sched_yield(2) which would do the work so I chose this ran
On Thu, Jan 20, 2011 at 1:57 PM, Joel Sing wrote:
> pool_get() with PR_NOWAIT... and then not checking the return value? That's
> got null pointer dereference written all over it... :)
>
> However, the bigger problem is what can you then do if the pool_get() fails?
> This then results in the inter
On Thu, Jan 20, 2011 at 10:31 +0200, Gregory Edigarov wrote:
> --- interrupt ---
> end trace frame: 0x0, count: 245
> 0x8:
> End of stack trace.
> pppoe0: received unexpected PADO
> pppoe0: chap failure
> pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated
> pppoe0: received unexpected PA
On Thu, Dec 30, 2010 at 10:48 PM, David Gwynne wrote:
> i'll wire up an IR volume and muck around then. does this mean that the
> physical and logical disks have colliding or overlapping entries in the
> sc_devs array?
>
> dlg
no, the border value is controlled by sc_pd_id_start and sc_vd_id_lo
On Wed, Dec 29, 2010 at 11:01 +1000, David Gwynne wrote:
> ive had no takers on testing.
>
> i cant see how raid and sas events will race in the current code,
> so i think the 1second sleep to avoid confusion is unecessary. i
> will put it in and deal with fallout if it comes up.
>
i didn't look
On Fri, Dec 24, 2010 at 16:09 +1000, David Gwynne wrote:
> i can reliably produce a situation where an io on a disk attached
> to mpii(4) never completes. this implements timeouts on scsi io so
> we can recover from this situation.
>
> ok?
>
although, you've already committed the change, i have
On Mon, Dec 20, 2010 at 5:46 PM, Mark Kettenis
wrote:
>> Date: Mon, 20 Dec 2010 17:29:36 +0100
>> From: Mike Belopuhov
>>
>> On Mon, Dec 20, 2010 at 5:11 PM, Mark Kettenis
wrote:
>> >> Date: Mon, 20 Dec 2010 16:12:24 +0100
>> >> From: Claudio Je
On Mon, Dec 20, 2010 at 5:11 PM, Mark Kettenis
wrote:
>> Date: Mon, 20 Dec 2010 16:12:24 +0100
>> From: Claudio Jeker
>>
>> With the change in rev. 1.99 of subr_pool() changing the limit
>> will no longer set the high watermark as well.
>> This causes i386 to stop forwading packets on very busy s
901 - 1000 of 1074 matches
Mail list logo
