On 15 Nov 2014, at 3:40 am, Stuart Henderson st...@openbsd.org wrote:
On 2014/11/14 15:24, Rafael Zalamena wrote:
On Fri, Nov 14, 2014 at 05:41:32PM +0100, Mike Belopuhov wrote:
is it possible to call it something other than just wire(4)?
vpls maybe?
pseudowire(4) then? (looks long to
On 4 Nov 2014, at 10:23 pm, Martin Pieuchot mpieuc...@nolizard.org wrote:
Remove pl suffix, ok?
ok
Index: net/pipex.c
===
RCS file: /home/ncvs/src/sys/net/pipex.c,v
retrieving revision 1.61
diff -u -p -r1.61 pipex.c
---
On 30 Oct 2014, at 07:52, Ted Unangst t...@tedunangst.com wrote:
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
i dunno. im fine with either removing colouring altogether or setting it
from something else completely. i just want a decision to be made cos
right now ph_color isnt set
On 5 Nov 2014, at 10:12, Mike Belopuhov m...@belopuhov.com wrote:
On 5 November 2014 00:38, David Gwynne da...@gwynne.id.au wrote:
On 30 Oct 2014, at 07:52, Ted Unangst t...@tedunangst.com wrote:
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
i dunno. im fine with either
On 5 Nov 2014, at 10:27, David Gwynne da...@gwynne.id.au wrote:
On 5 Nov 2014, at 10:12, Mike Belopuhov m...@belopuhov.com wrote:
On 5 November 2014 00:38, David Gwynne da...@gwynne.id.au wrote:
On 30 Oct 2014, at 07:52, Ted Unangst t...@tedunangst.com wrote:
On Wed, Oct 29, 2014
On 5 Nov 2014, at 10:58, Ted Unangst t...@tedunangst.com wrote:
On Wed, Nov 05, 2014 at 09:38, David Gwynne wrote:
On 30 Oct 2014, at 07:52, Ted Unangst t...@tedunangst.com wrote:
On Wed, Oct 29, 2014 at 07:25, David Gwynne wrote:
i dunno. im fine with either removing colouring
this uses siphash to protect the in_pcb hashes. this is pretty much
a textbook example of what siphash should be used for.
tests? ok?
Index: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.583
diff -u -p
On 4 Nov 2014, at 09:50, Alexander Bluhm alexander.bl...@gmx.net wrote:
On Thu, Oct 30, 2014 at 09:55:35PM -0400, Ted Unangst wrote:
On Thu, Oct 30, 2014 at 22:10, Alexander Bluhm wrote:
+
+ /* Avoid user land starvation. */
+ yield();
I think this is the responsibility of the
On 31 Oct 2014, at 22:37, Alexander Bluhm alexander.bl...@gmx.net wrote:
On Fri, Oct 31, 2014 at 02:50:00PM +1000, David Gwynne wrote:
so without splicing, the payloads from multiple tcp packets (at least all of
the ones in a single softnet run?) get bundled up into a buffer
On 31 Oct 2014, at 07:10, Alexander Bluhm alexander.bl...@gmx.net wrote:
Hi,
Some performance measurements showed that socket splicing for TCP
can be made faster. The main slowdown was that tcp_output() got
called for every incomming packet. When copying through user-land
this cannot
ola,
while your explanation is good it still makes my head hurt. i think it makes
sense, but i will throw it on a box here to try. we use both numbered and
unnumbered carpdevs.
dlg
On 28 Oct 2014, at 23:56, Henning Brauer hb-openbsdt...@ml.bsws.de wrote:
so, carp interface with
On 29 Oct 2014, at 2:44 am, Mike Belopuhov m...@belopuhov.com wrote:
On 28 October 2014 17:02, Ted Unangst t...@tedunangst.com wrote:
On Tue, Oct 28, 2014 at 16:49, David Gwynne wrote:
when i shuffled the locking in pools around, page colouring was
left behind.
page colouring is where
this replaces the use of select with libevent in inetd.
it has been reviewed by a few people, but tests would be appreciated.
if people are still using inetd, could they give this a go and let
us know if it behaves differently than expected?
Index: Makefile
i think arm is the last arch that lacks the full set of ops advertised
by the atomic_foo manpages.
this adds support for the lowest common denominator, which in our
tree is armv5. armv5 lacks the linked load and store conditional
opcodes that armv6 grew. it implements that atomic sequences by
, mounted the
test crypto partition, and sha1'd every hundredth file and compared against
originals, nothing seems amiss. is that a sufficient test?
yep, perfect.
thank you.
dlg
On Mon, 20 Oct 2014 11:28:34 +1000 David Gwynne da...@gwynne.id.au wrote:
the distinct impression i get
everything else in crypto is protected at IPL_VM (via splvm), i
cant see a reason for the taskq to be different. ive read all the
users of the crypto api and theyre all at or below IPL_VM.
can someone test this with ipsec or softraid crypto?
cheers,
dlg
Index: crypto.c
ok?
Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.67
diff -u -p -r1.67 crypto.c
--- crypto.c14 Sep 2014 14:17:23 - 1.67
+++ crypto.c20 Oct 2014 00:26:56 -
@@ -220,15 +220,12
pools lock themselves, we just gotta tell them how hard.
can someone test this with ipsec or softraid crypto? or ok it?
Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.68
diff -u -p -r1.68 crypto.c
the distinct impression i get is crypto_invoke is an internal
abstraction to src/sys/crypto/crypto.c. it isnt documented in
crypto(9), and is only used outside crypto by softraid. softraid
should be calling crypto_dispatch with CRYPTO_F_NOQUEUE set if it
wants/needs those semantics.
can a
On 13 Oct 2014, at 9:00 pm, Christian Weisgerber na...@mips.inka.de wrote:
David Gwynne:
dont you need endian.h to get bemtoh64 and htobem64?
I went by the man page, which says sys/types.h.
and cvs blame says that's my fault... fair enough.
ill talk to philip about whether that should
dont you need endian.h to get bemtoh64 and htobem64?
On 13 Oct 2014, at 7:57, Christian Weisgerber na...@mips.inka.de wrote:
Here's a cleaned-up diff. Briefly tested on amd64 sparc64. I'll
do some more testing tomorrow. This already has mikeb@'s blessing.
Index:
On Thu, Oct 09, 2014 at 05:36:07AM -0600, Todd C. Miller wrote:
Two comments inline, otherwise OK.
like this?
a couple of people also suggested changing select to poll in the
error messages.
Index: net/rcmd.c
===
RCS file:
On Fri, Oct 10, 2014 at 02:42:08PM +1000, David Gwynne wrote:
On Thu, Oct 09, 2014 at 05:36:07AM -0600, Todd C. Miller wrote:
Two comments inline, otherwise OK.
like this?
a couple of people also suggested changing select to poll in the
error messages.
theo made me look at where i
this is the only use of select inside libc i could find. it appears
pretty straightforward to replace with poll.
this compiles, but i have no idea how to test it.
any suggestions? or oks?
Index: net/rcmd.c
===
RCS file:
deraadt points out i suck at grep.
ok?
Index: termios/tcsendbreak.c
===
RCS file: /cvs/src/lib/libc/termios/tcsendbreak.c,v
retrieving revision 1.6
diff -u -p -r1.6 tcsendbreak.c
--- termios/tcsendbreak.c 5 Aug 2005 13:03:00
On 9 Oct 2014, at 15:11, Bryan Steele bry...@gmail.com wrote:
On Thu, Oct 09, 2014 at 02:52:50PM +1000, David Gwynne wrote:
this is the only use of select inside libc i could find. it appears
pretty straightforward to replace with poll.
this compiles, but i have no idea how to test
vi gets upset if i maximise my terminal window. it might need to
go even bigger for 4k displays.
ok?
Index: common/options_f.c
===
RCS file: /cvs/src/usr.bin/vi/common/options_f.c,v
retrieving revision 1.7
diff -u -p -r1.7
On 29 Sep 2014, at 19:58, Stuart Henderson st...@openbsd.org wrote:
On 2014/09/26 22:49, Reyk Floeter wrote:
Taking the interface down shouldn't change the link / media state on
Ethernet interfaces (at least with modern drivers).
Hmm - that is interesting and definitely not what I would
sm(4) doenst have to bpfdetach cos if_detach will do it for it.
also, useless comments are useless.
ok?
Index: dev/ic/smc91cxx.c
===
RCS file: /cvs/src/sys/dev/ic/smc91cxx.c,v
retrieving revision 1.35
diff -u -p -r1.35 smc91cxx.c
if you configure a read timeout, but then use kqs to wait for stuff
to happen, it doesnt happen. you end up waiting for the buffer to
fill, which might not be timely...
this fixes it by starting the read timer when the kq is set up.
works for me. i can provide some example code if anyone wants a
now that we have large clusters, we can easily support packets up to 64k in
length.
is there doco i have to update?
ok?
Index: bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.103
diff -u -p -r1.103 bpf.c
---
if you have more than 8 cpus, combine the cpu lines by default.
ok?
Index: machine.c
===
RCS file: /cvs/src/usr.bin/top/machine.c,v
retrieving revision 1.78
diff -u -p -r1.78 machine.c
--- machine.c 4 Jul 2014 05:58:31 -
2014 21:51:00 +1000
From: David Gwynne da...@gwynne.id.au
if you have more than 8 cpus, combine the cpu lines by default.
Just curious, is there a command line argument to expand the list?
/Alexander
ok?
8 seems a reasonable number
ok kettenis@
Index: machine.c
mpsafe mpi. eyes would be appreciated. tests well to me.
ok?
Index: ic/mpi.c
===
RCS file: /cvs/src/sys/dev/ic/mpi.c,v
retrieving revision 1.195
diff -u -p -r1.195 mpi.c
--- ic/mpi.c3 Sep 2014 00:46:04 - 1.195
+++
can someone test this?
cheers,
dlg
Index: arc.c
===
RCS file: /cvs/src/sys/dev/pci/arc.c,v
retrieving revision 1.103
diff -u -p -r1.103 arc.c
--- arc.c 13 Jul 2014 23:10:23 - 1.103
+++ arc.c 9 Sep 2014 05:52:14
...and some mpsafety in the scsi_cmd path.
this is working well for me, but considering how used it is i would
appreciate some extra tests.
ok?
Index: pci/mfi_pci.c
===
RCS file: /cvs/src/sys/dev/pci/mfi_pci.c,v
retrieving revision
On 1 Sep 2014, at 9:22 pm, Mike Belopuhov m...@belopuhov.com wrote:
On 1 September 2014 13:06, Stefan Fritsch s...@sfritsch.de wrote:
On Mon, 1 Sep 2014, Mike Belopuhov wrote:
On 29 August 2014 22:39, Stefan Fritsch s...@sfritsch.de wrote:
Yes, that seems to be what happens. But if every
if noone else is going to try this then i think it should go in.
On 28 Aug 2014, at 20:32, David Gwynne da...@gwynne.id.au wrote:
On 28 Aug 2014, at 3:02 am, Mike Belopuhov m...@belopuhov.com wrote:
On 27 August 2014 08:25, Brad Smith b...@comstyle.com wrote:
Looking for some testing
On 30 Aug 2014, at 6:39, Stefan Fritsch s...@sfritsch.de wrote:
On Fri, 29 Aug 2014, Mike Belopuhov wrote:
On 29 August 2014 11:26, Stefan Fritsch s...@sfritsch.de wrote:
On Fri, 29 Aug 2014, Miod Vallat wrote:
sc-sc_xfer_max is computed according to the host's capabilities. What I
want
is it something msdos isnt doing that ffs does?
On 29 Aug 2014, at 15:55, Stefan Fritsch s...@sfritsch.de wrote:
On Friday 29 August 2014 10:34:20, David Gwynne wrote:
are you expecting minphys to appear in that backtrace?
No. In that trace minphys should have limited the transfer size
On 28 Aug 2014, at 3:02 am, Mike Belopuhov m...@belopuhov.com wrote:
On 27 August 2014 08:25, Brad Smith b...@comstyle.com wrote:
Looking for some testing of the following diff to add Jumbo support for the
BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766
chipsets.
On 28 Aug 2014, at 11:05 pm, Mike Belopuhov m...@belopuhov.com wrote:
On 28 August 2014 12:32, David Gwynne da...@gwynne.id.au wrote:
On 28 Aug 2014, at 3:02 am, Mike Belopuhov m...@belopuhov.com wrote:
On 27 August 2014 08:25, Brad Smith b...@comstyle.com wrote:
Looking for some testing
are you expecting minphys to appear in that backtrace?
On 29 Aug 2014, at 5:07, Stefan Fritsch s...@sfritsch.de wrote:
Hi,
while debugging some problems on a virtio host that supports only few dma
segments per request, I noticed that the minphys function is not called in
all code paths.
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
On 20/08/14 8:03 PM, David Gwynne wrote:
sthen@ says this is likely a bit optimistic. while most of our drivers
unconditionally configure their max mru, there's some stupid ones that still
interpret the configured mtu as a what
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
On 20/08/14 8:03 PM, David Gwynne wrote:
sthen@ says this is likely a bit optimistic. while most of our drivers
unconditionally configure their max mru, there's some stupid ones that still
interpret the configured mtu as a what
@
David Gwynne [da...@gwynne.id.au] wrote:
this lets you have networks on the native vlan on an interface
at 1500, while setting a child vlan interfaces mtu to jumbos.
ok?
Index: if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
I think sthen is referring to the original diff Kettenis had in the tree a
few years ago.
On 20/08/2014 4:44 am, Brad Smith b...@comstyle.com wrote:
On 19/08/14 2:43 PM, Stuart Henderson wrote:
From what I remember from last attempt to convert sk(4) to MCLGETI,
there were problems which only
On 20 Aug 2014, at 7:12 am, Stuart Henderson st...@openbsd.org wrote:
On 2014/08/20 07:06, David Gwynne wrote:
I think sthen is referring to the original diff Kettenis had in the tree a
few years ago.
Yes - I just wanted to give ideas of things that might be worth testing
that have been
this lets you have networks on the native vlan on an interface
at 1500, while setting a child vlan interfaces mtu to jumbos.
ok?
Index: if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.108
diff -u -p
jumbos seem find. nfs seems fine.
im going to put this and the other jalloc driver changes in to see what happens.
dlg
On 20 Aug 2014, at 7:41, Brad Smith b...@comstyle.com wrote:
On 19/08/14 2:19 PM, Brad Smith wrote:
On 18/08/14 6:24 PM, David Gwynne wrote:
On Sun, Jul 13, 2014 at 02:01
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just annoying cos
im pretty sure its sr optics with sc connectors.
thanks for testing.
how's this one?
Index: if_sk.c
Cool, thanks.
On 19/08/2014 8:42 am, Brad Smith b...@comstyle.com wrote:
On 18/08/14 6:24 PM, David Gwynne wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just
annoying cos im pretty sure its sr optics with sc
this attempts to replace to custom jumbo allocator in ti(4) with
MCLGETI. it does not implement struct if_rxring, it just changes
where the memory comes from.
can someone test this for me?
Index: ti.c
===
RCS file:
the jumbo rx stuff wasnt run (look for notyet in the diff), so it's
all just dead code. i dont care enough to try and fix it without
access to or a use for the hardware, so id rather just remove it
and save the bytes in the kernel.
can anyone test to make sure i havent broken existing use?
dlg
i dont have the hardware, can anyone test?
Index: if_lge.c
===
RCS file: /cvs/src/sys/dev/pci/if_lge.c,v
retrieving revision 1.62
diff -u -p -r1.62 if_lge.c
--- if_lge.c22 Jul 2014 13:12:11 - 1.62
+++ if_lge.c19 Aug
i dont have the hardware, can anyone test?
dlg
Index: if_nge.c
===
RCS file: /cvs/src/sys/dev/pci/if_nge.c,v
retrieving revision 1.79
diff -u -p -r1.79 if_nge.c
--- if_nge.c22 Jul 2014 13:12:11 - 1.79
+++ if_nge.c19
:
On Mon, Aug 18, 2014 at 6:24 PM, David Gwynne da...@gwynne.id.au wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just annoying
cos im pretty sure its sr optics with sc connectors.
thanks for testing.
how's
ok
i have a 5709 somewhere i can work on.
dlg
On 15 Aug 2014, at 9:50 am, Brad Smith b...@comstyle.com wrote:
On 14/08/14 5:09 PM, Brad Smith wrote:
On 13/08/14 6:42 AM, David Gwynne wrote:
ive had this for 2 years or so. updated to current again.
its been tested on the following
the silence is deafening.
unless anyone objects im going to commit this tomorrow (~8pm GMT+10) to force
some testing.
dlg
On 13 Aug 2014, at 8:42 pm, David Gwynne da...@gwynne.id.au wrote:
ive had this for 2 years or so. updated to current again.
its been tested on the following:
bnx0
ive had this for 2 years or so. updated to current again.
its been tested on the following:
bnx0 at pci4 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16
bnx1 at pci13 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 16
bnx0: address 00:1e:4f:1b:26:53
brgphy0 at bnx0 phy 1:
why does it need queue.h?
the diffs ok by me.
On 11 Aug 2014, at 7:55 pm, Martin Pieuchot mpieuc...@nolizard.org wrote:
Some llinfo structures might be allocated in interrupt path when
ifa_rtrequest() is called, diff below convert such allocation to
pool(9), ok?
Index: netinet/if_ether.c
On Tue, Aug 05, 2014 at 08:15:59PM +, Miod Vallat wrote:
Hiding a lot of sys/pool.h from userland breaks the build of the
extent test in regress/sys/kern/extent on amd64. Additionally, tedu's
added size variable in free(9) breaks the userland macros in
sys/kern/subr_extent.c. The
how about this?
Index: if_sk.c
===
RCS file: /cvs/src/sys/dev/pci/if_sk.c,v
retrieving revision 1.168
diff -u -p -r1.168 if_sk.c
--- if_sk.c 19 Apr 2014 18:29:39 - 1.168
+++ if_sk.c 12 Jul 2014 08:29:20 -
@@
i think i'll try to find the sk at work and wire it up. its just annoying cos
im pretty sure its sr optics with sc connectors.
thanks for testing.
On 13 Jul 2014, at 4:45 am, Brad Smith b...@comstyle.com wrote:
On 12/07/14 4:32 AM, David Gwynne wrote:
how about this?
Now it attaches
On 11 Jul 2014, at 9:48, Brad Smith b...@comstyle.com wrote:
On 10/07/14 1:33 AM, David Gwynne wrote:
this is an update of if_sk.c r1.151, which tried to introduce
mclgeti. it updates it to use the if_rxring accounting.
does anyone have one they can test this on?
it also saves about 2k
this is an update of if_sk.c r1.151, which tried to introduce
mclgeti. it updates it to use the if_rxring accounting.
does anyone have one they can test this on?
it also saves about 2k on amd64.
Index: if_sk.c
===
RCS file:
em(4) appears to be susceptible to the same problem that if_bge.c
r1.355 addressed.
long mbuf chains can cause em_encap to fail, which will cause OACTIVE
to be set on the interface, and the problem packet to remain at the
start of the send queue. this will cause no packets to end up on
the tx
On 20 Jun 2014, at 7:35, Ted Unangst t...@tedunangst.com wrote:
Always explicitly compare memcmp with 0. I find this adds clarity.
i agree.
ok by me if that has any value in this part of the tree.
Index: s3_clnt.c
===
RCS
i fixed this in src/sys/dev/pci/mfii.c r1.14.
cheers,
dlg
On 28 Mar 2014, at 7:43 am, kspill...@acm.org wrote:
Is anyone else seeing this error building -current?
/usr/src/sys/dev/pci/mfii.c: In function 'mfii_initialise_firmware':
/usr/src/sys/dev/pci/mfii.c:1004: error: 'struct
is there anything in particular you're supposed to look for to see if it is or
isnt working?
either it locks up the machine (deadlock) or doesnt?
On 29 Jan 2014, at 8:06 pm, Mark Kettenis mark.kette...@xs4all.nl wrote:
Here is a diff that makes mutexes raise their ipl to the highest level
On 26 Jan 2014, at 11:31 am, Brad Smith b...@comstyle.com wrote:
On 31/12/13 5:50 AM, Mike Belopuhov wrote:
On 31 December 2013 09:46, Brad Smith b...@comstyle.com wrote:
On 31/12/13 3:14 AM, Mark Kettenis wrote:
Date: Tue, 31 Dec 2013 01:28:04 -0500
From: Brad Smith b...@comstyle.com
this gets rid of XS_NO_CCB in sbic(4) by moving to iopools. i dont
have an arch that uses this so i mostly want compile testers, but
if someone actually has the hardware that would be great.
this change is mildly interesting because it demonstrates the
flexibility of iopools at sharing resources
can anyone compile or even test this on a sparc or vax for me?
cheers,
dlg
Index: ncr5380sbc.c
===
RCS file: /cvs/src/sys/dev/ic/ncr5380sbc.c,v
retrieving revision 1.30
diff -u -p -r1.30 ncr5380sbc.c
--- ncr5380sbc.c17 Jul
Ok
On 27/12/2013 5:28 am, Mark Kettenis mark.kette...@xs4all.nl wrote:
Our bus_dmamap(9) man page says:
On platforms which implement reordered stores, bus_dmamap_sync()
will always cause the store buffer to be flushed.
In 2003 NetBSD actually changed that to:
On platforms which
wrote:
On Fri, Dec 20, 2013 at 01:17:08PM +1000, David Gwynne wrote:
im glad you wrote a diff rather than simply complain that nat and tftp
doesnt work. the moving parts generally look good to me apart from the
struct src_addr and getopt chunks.
please use sockaddr_storage instead
im glad you wrote a diff rather than simply complain that nat and tftp doesnt
work. the moving parts generally look good to me apart from the struct src_addr
and getopt chunks.
please use sockaddr_storage instead of sockaddr in the src_addr struct.
could you split the resolution of the
On 20 Dec 2013, at 2:56 am, Alexander Hall alexan...@beard.se wrote:
Henning Brauer lists-openbsdt...@bsws.de wrote:
* Craig R. Skinner skin...@britvault.co.uk [2013-12-19 10:18]:
On 2013-12-18 Wed 20:48 PM |, J??r??mie Courr??ges-Anglas wrote:
skin...@britvault.co.uk (Craig R. Skinner)
timeout_pending followed by timeot_del is pointless, as timeout_del
effectively does the pending check itself.
now that timeout_del returns whether the timeout was actually
removed, you can make decisions based on that rather than race with
timeout_pending
checking timeout_pending shortly after
On 9 Dec 2013, at 6:59 pm, Bret Lambert blamb...@openbsd.org wrote:
On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote:
this is a demonstration of using TIMEOUT_INITIALIZED().
because we know the timeout is always set up correctly, we dont
have to test for it all over the place
On 9 Dec 2013, at 10:01 pm, David Gwynne da...@gwynne.id.au wrote:
On 9 Dec 2013, at 6:59 pm, Bret Lambert blamb...@openbsd.org wrote:
On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote:
this is a demonstration of using TIMEOUT_INITIALIZED().
because we know the timeout
this lets you init a timeout when its declared, much like how things
like MUTEX_INITIALIZER or RWLOCK_INITIALIZER work.
ok?
Index: sys/sys/timeout.h
===
RCS file: /cvs/src/sys/sys/timeout.h,v
retrieving revision 1.24
diff -u -p
this is a demonstration of using TIMEOUT_INITIALIZED().
because we know the timeout is always set up correctly, we dont
have to test for it all over the place.
Index: rnd.c
===
RCS file: /cvs/src/sys/dev/rnd.c,v
retrieving revision
this removes the idea of multiple cfdata tables. code for it was
introduced for some reason for some hotplug stuff 17 years ago, if
0'd 14 years ago, and removed 11 years ago.
i dont think we need it.
ok?
Index: sys/device.h
===
the subject says it all really. this is sort of inspired by 5d2ecd5224
in bitrig except this brings all the architectures and device drivers
forward (i didnt get to delete any to prepare for this), and maintains
an algorithm for trying to order io on spinning rust (nscan).
ok?
Index:
most hardware and most of the kernel has given up on cylinders
meaning anything, we generally work in logical block addresses now.
now that disksort is (almost) gone it is no longer used for anything
meaningful except in floppy disk drivers.
the #define b_cylinder b_resid alias has always grated
this one is for hd(4) on hp300s. again, i cant compile and therefore cant test.
anyone able to compile this for me? does anyone have such hardware?
On Sun, Nov 03, 2013 at 09:30:56AM +1000, David Gwynne wrote:
once upon a time pretty much all block storage was on spinning disks, so all
this one is for xy(4) on sparc. again, i cant test, so if anyone
could do that for me it would be appreciated.
does anyone have one of these?
Index: xy.c
===
RCS file: /cvs/src/sys/arch/sparc/dev/xy.c,v
retrieving revision 1.57
diff
and here's the last one, the hdc stuff on vax.
can anyone compile this? test?
Index: hdc9224.c
===
RCS file: /cvs/src/sys/arch/vax/vsa/hdc9224.c,v
retrieving revision 1.41
diff -u -p -r1.41 hdc9224.c
--- hdc9224.c 14 Oct 2013
here's a diff to sys/arch/sparc/dev/fd.c. not compiled, and therefore
not tested.
anyone? ok?
On Sun, Nov 03, 2013 at 09:30:56AM +1000, David Gwynne wrote:
once upon a time pretty much all block storage was on spinning disks, so all
the drivers for disks tried to order queued io to better
On 5 Nov 2013, at 12:40 am, Kenneth R Westerback kwesterb...@rogers.com wrote:
On Sun, Nov 03, 2013 at 10:51:43PM -0500, Brad Smith wrote:
LLVM errors out on the i2o code with the following warning..
../../../../dev/i2o/iop.c:2399:42: error: comparison of unsigned expression
0 is always
once upon a time pretty much all block storage was on spinning disks, so all
the drivers for disks tried to order queued io to better suit moving a head
across a platter by calling disksort. between then and now a lot of the
assumptions that disksort relied on are no longer true (eg, SSDs are a
jmatthew@ tells me this compiles, but we dont have hardware to test
with.
tests? oks? go for its?
cheers,
dlg
Index: octcf.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/octcf.c,v
retrieving revision 1.12
diff -u -p -r1.12 octcf.c
can someone with an alpha test this diff for me?
if your computer still boots after you're running a kernel with it,
i will consider it tested.
Index: arch/alpha/alpha/pmap.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/pmap.c,v
this replaces the bare use of disksort with a bufq in fd. this means
it will use the new system default of the nscan sorting algorithm,
but that shouldnt be a noticable change.
it works for me, but i would love to hear from someone with a real
floppy drive still...
ok?
Index: fd.c
i dont have the hardware to test this on. could someone give it
a go and see if it still works?
cheers,
dlg
Index: viomb.c
===
RCS file: /cvs/src/sys/dev/pci/viomb.c,v
retrieving revision 1.6
diff -u -p -r1.6 viomb.c
--- viomb.c
makes a lot of sense to me, ok. you need oks from people other than me though.
dlg
On 14/09/2013, at 8:34 PM, Jonathan Matthew jmatt...@openbsd.org wrote:
The network interfaces on the ubiquiti edgerouter lite don't work yet.
Here's the first step towards fixing that:
Mapping port numbers
ok by me.
On 05/08/2013, at 7:04 PM, Christiano F. Haesbaert haesba...@openbsd.org
wrote:
On Thu, Jun 06, 2013 at 12:54:31PM +0200, Christiano F. Haesbaert wrote:
Hi,
We would like to switch mfii(4) to msi, there is a family of supermicro
X9 motherboards with incorrect ioapic routing, so
On 04/06/2013, at 11:22 AM, Claudio Jeker cje...@diehard.n-r-g.com wrote:
On Mon, Jun 03, 2013 at 11:49:58PM +0100, Stuart Henderson wrote:
On a router running PF and isakmpd, I have a rule like this:
match out on pppoe0 inet all received-on vlan5 nat-to $someip
I was surprised to find
ive tested this on:
bge0 at pci4 dev 0 function 0 Broadcom BCM5721 rev 0x21, BCM5750 C1 (0x4201):
apic 0 int 16, address 00:18:f3:d1:80:64
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
bge1 at pci5 dev 0 function 0 Broadcom BCM5720 rev 0x00, BCM5720 A0
(0x572), APE firmware
On 30/05/2013, at 2:56 AM, Mike Belopuhov m...@belopuhov.com wrote:
cool, thanks! does your 5719 work w/o other diffs?
yes, otherwise i would have fixed it :)
dlg
901 - 1000 of 1094 matches
Mail list logo
