On 24/02/2011, at 5:33 PM, Mark Kettenis wrote:
Hmm, this looks like a fix for PR 6269, although that report is for
mpi(4). Any chance a similar fix works for mpi(4)?
thats a fairly old PR. is anyone able to reproduce it on mpi(4) with a modern
kernel?
dlg
On 24/02/2011, at 6:51 PM, David Gwynne wrote:
On 24/02/2011, at 5:33 PM, Mark Kettenis wrote:
Hmm, this looks like a fix for PR 6269, although that report is for
mpi(4). Any chance a similar fix works for mpi(4)?
thats a fairly old PR. is anyone able to reproduce it on mpi(4
there have been reports of panics with pfsync defer combined with
ipv6 traffic. ive been over the pfsync code repeatedly trying to
find out where it treats ipv4 and ipv6 differently without any luck.
i just had a lightbulb moment literally minutes ago and came up
with the code below. turns out
i agree that mikebs change should go in.
On 05/03/2011, at 12:10 AM, Mark Kettenis wrote:
Date: Fri, 4 Mar 2011 07:30:24 -0600
From: Marco Peereboom sl...@peereboom.us
That is a huge penalty because it is read over the pci bus. The trick
with 0x should work just fine per the doco
makes sense to me.
On 23/03/2011, at 10:28 AM, Alexander Bluhm wrote:
Hi,
When the kernel runs out of mbuf clusters, the hme receive ring may
become empty. In that case, the hme driver cannot recover as the
ring is only filled after receiving data. My fix is to fill an
empty receive
all the things i can imagine using this for, i can do with pf features.
ok.
On 02/04/2011, at 10:49 PM, Henning Brauer wrote:
lo has that link1 wankery where it kind of replies to all addresses in
the subnet, except that it doesn't really - it is very halfbaked and
gets in the way. unless
ok.
On 02/04/2011, at 11:15 PM, Kenneth R Westerback wrote:
Another driver malloc'ing and passing potentially dma unsafe memory
to do i/o into.
ok?
Ken
Index: atascsi.c
===
RCS file:
ok
On 02/04/2011, at 11:58 PM, Thordur Bjornsson wrote:
Hi,
So, it doesn't make sense to have a bufq for vnds.
The disk that stores the image backing the vnd has it's own bufq
ofcourse and what happens is that vnd puts a buf on it's bufq,
which is promptly removed when we call vndstart,
this cuts ips over to using iopools. it gets the usual benefits of
more reliable ioctl paths, better io scheduling between volumes and
the pt busses, and a removal of NO_CCB.
i dont have an ips, so i cant test this. id like more than an ok
from gcc before committing this.
Index: ips.c
if you have a twe, let me first say how sorry i am for you.
this cuts twe over to using iopools. it gets the usual benefits of
more reliable ioctl paths, better io scheduling between volumes and
the pt busses, and a removal of NO_CCB.
it is a bit more than a straight conversion, it also moves
ahci_port_read_ncq_error is used from interrupt context, so you either have to
preallocate it during port attach (hi kettenis!) or fix your flags.
dlg
On 03/04/2011, at 11:38 PM, Kenneth R Westerback wrote:
Another allocation/memory use made big mem friendly.
Ken
Index: ahci.c
ok
On 04/04/2011, at 1:41 AM, Kenneth R Westerback wrote:
On Sun, Apr 03, 2011 at 09:38:44AM -0400, Kenneth R Westerback wrote:
Another allocation/memory use made big mem friendly.
Ken
Try to avoid allocating memory in interrupt context, as pointed out
by dlg@.
Ken
there is an expectation that if you timeout_del the timeout will
not run. however, it doesnt prevent it from being about to run, or
from running on another cpu at the same time as you're doing the
timeout_del. you can check if the timeout ran with timeout_triggered,
but that can race unless you
On 04/04/2011, at 5:31 AM, Mark Kettenis wrote:
Date: Sun, 3 Apr 2011 13:46:40 +0200
From: Claudio Jeker cje...@diehard.n-r-g.com
bce(4) was turned off because of limitations in the DMA engine that allows
the chip to access only 1G of memory. On systems with more then 1G of
memory hilarity
comments inline...
On 04/04/2011, at 9:01 AM, Kenneth R Westerback wrote:
Works on my crypto volume. People with other volume types would be nice
to hear from.
Ken
Index: softraid.c
===
RCS file:
On 04/04/2011, at 8:43 PM, Thordur Bjornsson wrote:
On Mon, Apr 04, 2011 at 12:34:17PM +0200, Otto Moerbeek wrote:
On Mon, Apr 04, 2011 at 09:22:41AM +, Thordur Bjornsson wrote:
Hi,
1) Swapping to svnds has issues (pagedaemon deadlocks) and has been
broken since forever.
2) Swapping
this reads fine by me, except for one thing. i worry that it looks like wu's
get lists of ccbs attached to them that are released when the wu is released.
before iopools there was a wu per call to softraids scsi_cmd handler, but now
the same wu can be given to scsi_cmd multiple times. sr_scsi_done
...so the io path doesnt have to do it EVERY TIME FOR EVERY IO.
Index: isp_openbsd.c
===
RCS file: /cvs/src/sys/dev/ic/isp_openbsd.c,v
retrieving revision 1.45
diff -u -p -r1.45 isp_openbsd.c
--- isp_openbsd.c 31 Dec 2010
so use the appropriate define to report that.
Index: isp_openbsd.c
===
RCS file: /cvs/src/sys/dev/ic/isp_openbsd.c,v
retrieving revision 1.46
diff -u -p -r1.46 isp_openbsd.c
--- isp_openbsd.c 5 Apr 2011 12:09:20 -
since atascsi screws it up...
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.174
diff -u -p -r1.174 ahci.c
--- ahci.c 7 Apr 2011 15:30:16 - 1.174
+++ ahci.c 18 Apr 2011 01:39:19
ok
On 20/04/2011, at 12:54 AM, Kenneth R Westerback wrote:
gdt(4) man page says 'transparent raw SCSI mode' is unsupported.
The code just returns errors to any attempts to submit i/o. I'm
pretty sure nobody is going to add support so eliminate the framework
for it.
Shrinks the iopool
On 14/05/2011, at 6:43 PM, Abel Abraham Camarillo Ojeda wrote:
I'm starting to get angry about the _horrible_ performance on this drive
(WD10EARS-00Y), some developer ever got a chance to see something about
this?
don't get angry, it's just a disk.
we changed the default alignment of
this is based on the solaris code. its a lot less arbitrary than
the stupid linux code.
if this works i'll add back the printing of the physical path, it can be useful
when debugging wiring issues.
cheers,
dlg
Index: mpath_hds.c
ie, check if the VPD bit is set when an inquiry is issued and stop
if it is. adds a free check for the cdblen there too.
i cant even ping my x60 atm, so i cant test. anyone else want to
give it a spin?
Index: sdmmc_scsi.c
===
RCS
this is like the change i did for ix(4)...
Index: if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.94
diff -u -p -r1.94 if_bnx.c
--- if_bnx.c18 Apr 2011 04:27:31 - 1.94
+++ if_bnx.c15 Jun
the subject line says it all, but happy to explain further if
required.
Index: mpath.c
===
RCS file: /cvs/src/sys/scsi/mpath.c,v
retrieving revision 1.21
diff -u -p -r1.21 mpath.c
--- mpath.c 27 Apr 2011 05:22:24 - 1.21
On 15/06/2011, at 8:16 PM, Mark Kettenis wrote:
Date: Wed, 15 Jun 2011 18:04:24 +1000
From: David Gwynne l...@animata.net
the subject line says it all, but happy to explain further if
required.
Hmm, I'm somewhat confused:
+#define MPATH_ROUNDROBIN0
+#define MPATH_NEXT
On 15/06/2011, at 9:52 PM, Kenneth R Westerback wrote:
On Wed, Jun 15, 2011 at 01:27:03PM +1000, David Gwynne wrote:
ie, check if the VPD bit is set when an inquiry is issued and stop
if it is. adds a free check for the cdblen there too.
i cant even ping my x60 atm, so i cant test. anyone
On Wed, Jun 15, 2011 at 07:39:12PM +0100, Stuart Henderson wrote:
On 2011/06/15 14:06, David Gwynne wrote:
this is like the change i did for ix(4)...
Index: if_bnx.c
can i have the if_bnxreg.h part too, please? :)
yes...
Index: if_bnx.c
On 22/06/2011, at 3:52 AM, Stefan Rinkes wrote:
Hi,
while playing around with carp and pfsync I spotted
two minor bugs.
1. Not all pfstate flags are synced, cause pfsync uses
u_int8_t, while pf uses u_int16_t for state_flags.
Currently that means PFSTATE_SCRUB_TCP flags don't
ok
On 23/06/2011, at 3:06 AM, Ted Unangst wrote:
checked with md5, before line folding caused differences.
Index: cninit.c
===
RCS file: /home/tedu/cvs/src/sys/dev/cninit.c,v
retrieving revision 1.10
diff -u -r1.10 cninit.c
you dawe,
you could point both chips at the same function...
dlg
On 23/06/2011, at 10:50 PM, Dawe wrote:
Hi,
the intel_3400_4 has the same issue as the intel_3400_1, ahci(4)
hangs for 30 seconds on boot and resume. See also PR6630.
Index: ahci.c
this was surprisingly straightforward, i just copied it from ospfd.
ok?
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ospf6d/parse.y,v
retrieving revision 1.20
diff -u -p -r1.20 parse.y
--- parse.y 13 Dec 2010 13:43:37 -
this works great for me. i'll pressure claudio@ to have a look at it over the
next week or two.
cheers,
dlg
On 25/04/2011, at 8:44 PM, Patrick Coleman wrote:
On Wed, Jan 5, 2011 at 8:32 PM, Jan Johansson janj+open...@wenf.org
wrote:
So I found a bug here.
Your mk2 patch (didn't try the
i like this.
On 12/07/2011, at 9:23 PM, Otto Moerbeek wrote:
Hi,
at the cost of some speed, reduce the malloc cache size to 0 with
flag 'S'. This means that pages that become free will be unmapped asap.
This detects more use-after-free bugs. The slowdown is because of more
unmap/mmap
in my environment i have nginx in front of apache to offload ssl
and to let me easily point different parts of the uri namespace at
all crazy backends we have. this works fine except if the apache
wants to canonicalise something on the ssl backends. because the
ssl is done in nginx, apache doesnt
noone has an opinion?
would anyone get upset if i committed this?
dlg
On 14/07/2011, at 1:40 PM, David Gwynne wrote:
in my environment i have nginx in front of apache to offload ssl
and to let me easily point different parts of the uri namespace at
all crazy backends we have. this works
On Thu, Jul 21, 2011 at 02:21:19PM +0100, Federico Schwindt wrote:
On Thu, Jul 14, 2011 at 4:40 AM, David Gwynne l...@animata.net wrote:
in my environment i have nginx in front of apache to offload ssl
and to let me easily point different parts of the uri namespace at
all crazy backends we
vmwares pxe rom in guests uses the giaddr (the address of the dhcp
relay) as the default ip gateway.
this is a problem if you're running carped firewalls, because you'll
be running a dhcrelay on each of them attached to the hardware
interface, not the carped interface. if the vmware client
i want to push my set scheme in http diff again, but it makes
sense to reuse server_port as part of that.
this makes server_port more palatable to me.
ok?
Index: src/main/http_core.c
===
RCS file:
its generally hard for the cpu to slow a disk down...
On 12/11/2011, at 8:36 AM, Geoff Steckel wrote:
Increasing MAXPHYS to 256K shows a few places where it's assumed that
there are 16 pages in MAXPHYS.
In dev/ic/ahci.c I had to make this change @307 to make the
scatter-gather table large
this diff enables large ethernet frames on bnx(4) chips.
initial tests are good, im going to put it on the firewalls now.
Index: mii/brgphy.c
===
RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.93
diff -u -p -r1.93
you forgot https_proxy and no_proxy...
however, im against this change since it allows a user to redirect a program
they need privileges to use to an arbitrary proxy they specify, something
there is no good mitigation against.
dlg
On 16/01/2012, at 12:15 AM, Peter Hessler wrote:
When you are
pretty confident a regex wont fly :)
On 04/04/2012, at 11:34 PM, Bjvrn Ketelaars wrote:
2012/4/3 Theo de Raadt dera...@cvs.openbsd.org:
Hmm, I'd like to see that refactored somehow.
Also, '-' should not be legal at the start of a login name. There
are things that care. I think at the end
that tftpd has been unlinked from the tree, and therefore unlikely to get
patches against it.
have you tried the new one to see if you get annoying errors out of it?
dlg
On 29/06/2012, at 4:11 AM, Peter J. Philipp wrote:
Hi,
I have the weird scenario when I try to tftp a file from a remote
i believe as an ssl client you can add intermediate certs to /etc/ssl/cert.pem
and they'll be used to validate the endpoint.
if you're an ssl server and your program doesnt let you specify a chain, you
can just cat them on the end of the crt. eg, i do something like the following
when configuring
this moves knowledge of where the inbound doorbell on chips is out
of code and into the structure that stores the chip differences.
ive tested this on a perc5 (which is the xscale gen). id like a
skinny user to give it a spin too.
Index: mfi.c
ive been beating my head against why mpi is slow on some machines
and not others, and i think this may be why.
issuing a command to the chip is done by posting its address to a
register. in my code this was done by doing a write to the register
and then using a barrier immediately after. i think
this makes mfi(4) print details about itself like mfii(4) does.
instead of:
instead of this:
mfi0 at pci10 dev 14 function 0 Dell PERC 5 rev 0x00: apic 10 int 14,
0x1f031028
mfi0: logical drives 2, version 5.2.2-0072, 256MB RAM
scsibus0 at mfi0: 2 targets
sd0 at scsibus0 targ 0 lun 0: DELL,
yes.
On 02/09/2012, at 8:20 PM, Stefan Sperling s...@openbsd.org wrote:
prelist_update() runs at IPL_SOFTNET. Code moved out of it into a
workq task for adding new addresses from process context should
run at IPL_SOFTNET, too, shouldn't it?
Index: netinet6/nd6_rtr.c
i dont have this hardware, so i can only test that it hasnt broken
this chip:
bge0 at pci3 dev 4 function 0 Broadcom BCM5714 rev 0xa3, BCM5715 A3 (0x9003):
ivec 0x795, address 00:14:4f:a9:34:90
brgphy0 at bge0 phy 1: BCM5714 10/100/1000baseT/SX PHY, rev. 0
i need tests from any bge users
bge(4)s traditionally only have a phy at address 1, which is enforced
by the mii_read backend by failing reads at any other address.
why not just tell mii up front that the phy is at address 1?
why not avoid a conditional in an io path?
also, this is necessary to support recent chips which have
i cant see anything except some stupid debug code touching that memory. it is
reading it though. shouldnt we sync it for READs at the bottom of rx_intr too?
dlg
On 22/01/2013, at 9:49 AM, David Hill dh...@mindcry.org wrote:
I think this should be POSTREAD in bnx_rx_intr. This matches
scsi_xfers have a thing in them for letting adapters store them on
lists via a LIST_ENTRY. turns out most adapters want SIMPLEQ type
operations, so they end up doing things by hand. LIST_ENTRYs and
SIMPLEQ_ENTRYs are the same size, so this is effectively just a
code simplification.
id appreciate
On 15/03/2013, at 9:02 AM, Maxime Villard rusty...@gmx.fr wrote:
Hi,
there is a huge bug in the tftp daemon.
sure, but then there's also a huge bug in your fix by your own definition of
huge.
when oack fails it frees the client struct and everything hanging off it. now
you avoid the
good point.
On 16/03/2013, at 10:17 PM, Maxime Villard rusty...@gmx.fr wrote:
Le 15/03/2013 12:17, David Gwynne a écrit :
On 15/03/2013, at 9:02 AM, Maxime Villard rusty...@gmx.fr wrote:
Hi,
there is a huge bug in the tftp daemon.
sure, but then there's also a huge bug in your fix
this lets the code that picks the filenames to use for certificates
fall through to using the services name, instead of just the ip
addresses of the service.
eg, if i have this in relayd.conf:
relay sslnews.eait.uq.edu.au {
listen on 0.0.0.0 port 563 ssl
On 19/03/2013, at 7:56 PM, Reyk Floeter r...@openbsd.org wrote:
On Tue, Mar 19, 2013 at 05:57:16PM +1000, David Gwynne wrote:
this lets the code that picks the filenames to use for certificates
fall through to using the services name, instead of just the ip
addresses of the service.
eg
sad but ok dlg@
On 22/05/2013, at 2:06 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
From: Theo de Raadt dera...@cvs.openbsd.org
Date: Tue, 21 May 2013 09:23:04 -0600
I'd say no. Why is the driver tearing down and reinitializing the dma
maps when a watchdog timeout happens? That's
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
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
if ciss(4) has multiple disks on it, this should let any one of
those disks to use all the commands. with the iopools stuff thats
now in the tree, io on another disk should then be able to start
up and get a fair share.
i want a test from someone who has multiple LDs on a single ciss(4).
if you
On 29/06/2010, at 12:20 PM, J.C. Roberts wrote:
dlg,
It took me weeks and a few failed attempts with various disk
manufacturers, but it's done, and we have victory!
The value from the modified atactl output for reg 106: 4000
Finally it seems we have a disk that is properly showing us 4k
this diff is largely a mechanical change.
firstly, it makes struct bufq a member of the softc for devices
that use it, rather than it being a pointer to something that needs
to be allocated at attach. since all these devices need a bufq to
operate, it makes sense to have it allocated as part of
unless someone fixes mclgeti in this driver in the next 24 hours, this should
go in.
this has my ok on august 31.
On 28/08/2010, at 4:07 AM, Thordur I Bjornsson wrote:
As seen on misc@, and also by myself sometime ago, but I forgot about
it as work got hectic and I was moving.
Anyways,
last time i tried this i caused weird issues on people using the
SPI variants of mpi(4).
this restricts the large number of openings to the SAS or FC mpi(4)
variants, both of which i have succesffully tested myself.
ok?
Index: mpi.c
On 19/10/2010, at 4:17 AM, Driton Husnovic wrote:
Hi @Tech,
I want to configure dhcpd with WPAD option. I see that option-252 is
renamed/moved as autoproxy.
But there is no manual or reference about autoproxy.
Can anyone add any syntax or mini example to the list please?
option
thanks to work by jonathan matthew, vmt is now actually useful for
more than helping your clocks keep in sync.
is there a reason we shouldnt enable it?
cheers,
dlg
Index: amd64/conf/GENERIC
===
RCS file:
if you have two carped routers and you also want to redistribute
routes that relayd inserts into the kernel via ospf or bgp, but
only on the router that has the master carp interface, then this
diff should allow you to do so.
in relayd you can have a config like:
table routers { $gw1 ip
without this diff this box panics on boot while attaching the 36th
cpu. its a buffer overrun...
analysis done by kettenis.
ok?
Index: cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.38
diff -u -p
On Thu, Nov 25, 2010 at 06:04:23PM -0500, Kenneth R Westerback wrote:
Index: amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.38
diff -u -p -r1.38 cpu.c
--- amd64/cpu.c 13 Nov 2010
i agree with mark.
On 28/11/2010, at 11:12 PM, Mark Kettenis wrote:
Date: Sun, 28 Nov 2010 17:02:43 +1100 (EST)
From: Damien Miller d...@mindrot.org
On Sat, 27 Nov 2010, Ted Unangst wrote:
if you really really need to know that your cpu cache has 48 fully
associative entries, go
seems to work fine on my big box.
On 29/11/2010, at 5:43 PM, Philip Guenther wrote:
On Sun, 28 Nov 2010, Philip Guenther wrote:
On Sun, 28 Nov 2010, Philip Guenther wrote:
On Sunday, November 28, 2010, David Gwynne d...@cvs.openbsd.org wrote:
...
Log message:
bump the number of supported
it's the same code, so yes, it does.
i'll fix it and commit it if/when this diff gets oked.
dlg
On 02/12/2010, at 3:21 PM, Theo de Raadt wrote:
i386 doesn't have this bug?
the boot loader passes a variable that identifies the disk its
booting off made up of a bunch of fields like adapter,
On 02/12/2010, at 10:35 PM, Kenneth R Westerback wrote:
If this works then ok k...@. Certainly comparing all the fields is
better as far as I am concerned.
My only twinge is relying on the overflow of the unit field. Some
clever dick (intern?) may look at MAKEBOOTDEV() some day and apply
hi guys,
this makes mpii properly detach devices, which helps a lot if they
have commands in flight. to relevant changes are:
- call the activate(DVACT_DEACTIVATE) function against all the luns
on the target that is going away.
- issue the target reset BEFORE detaching the children devices.
this
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?
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
24, 2010 at 04:01:19PM +1000, David Gwynne wrote:
hi guys,
this makes mpii properly detach devices, which helps a lot if they
have commands in flight. to relevant changes are:
- call the activate(DVACT_DEACTIVATE) function against all the luns
on the target that is going away
the subject pretty much says it all. this is the least intrusive
version of the change i could come up with.
io on multiple volumes is scheduled better, and the ioctl paths
become more reliable with this change.
tests? ok?
Index: mfi.c
explanation makes perfect sense to me and the diff is good.
ok dlg@
On 29/12/2010, at 11:03 PM, Thordur Bjornsson wrote:
hi,
so cut vnds over to bufqs. this diff is similar to a diff
that was commited, but got backed out after one of the
hackathon fiasco's, with a small
On 31/12/2010, at 3:51 AM, Mike Belopuhov wrote:
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
On 31/12/2010, at 4:03 AM, Mike Belopuhov wrote:
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
ok
On 12/01/2011, at 8:44 AM, Mark Kettenis wrote:
Capability 0x12 is called SATA. I have a diff to add PCI_CAP_SATA
to pcireg.h, but given the fact that we're in ABI lock, that'll have
to wait. But it is anyhow better to use the number of elements in the
array to decide whether we know
On 15/06/2009, at 1:39 AM, Christian Weisgerber wrote:
Theo de Raadt dera...@cvs.openbsd.org wrote:
ahci0: error 35 loading dmamap
de0: unable to load tx map, error = 35
bigmem is unworkable.
Your DMA descriptor rings are in high memory.
They should be in low memory.
I thought iommu takes
, and umass
(usb). i have read through mfi, arc, and sili. if you want to avoid
this diff breaking any other controllers, please try the diff out
and report results.
On Thu, Aug 13, 2009 at 02:50:00AM +1000, David Gwynne wrote:
this diff starts to address several problems i have with the scsi
midlayer
This second patch applies cleanly, and no errors were generated in
dmesg. Subsequent usage of growisofs fails to burn a dvd, and hangs the
computer. The following error message was displayed on the console:
cd0(atapiscsi0:0:0):User Command with no buffer
ah, good catch. this is another
do the sb900 chipsets suffer the same bugs as the sb600 ones?
dlg
On 13/10/2009, at 11:00 AM, Brad wrote:
On Sun, Sep 20, 2009 at 02:31:27PM -0400, Brad wrote:
The following diffs add support for IDE and SATA with the AMD SB900
chipset.
Here is an updated diff after the last commit to
On Fri, Oct 30, 2009 at 09:50:34PM +0200, Atte Peltom?ki wrote:
Hi,
Link state change interrupt was not generated due to a missing bit in
the MAC event register. This fixes at least carp and ifstated for 5709
chip (eg. in Dell R610).
i have verified this on the 5709. i dont have a box
On Sun, Jan 31, 2010 at 09:41:14AM +1000, David Gwynne wrote:
pmap_enter in this situation should fail, not panic. the error would be
handled properly as the stack unwinds up to ami_allocmem.
i can change ami_allocmem to take a NOWAIT etc as an argument rather than
just assume it, so
i'll give a cookie* to anyone who can fix the bug described at
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=6329.
ive stared at the pfsync code for hours trying to find it and cannot. fresh
eyes might have better luck though.
dlg
* may not include real cookie.
this code lets userland check and change the caches on disks using
the new ioctl i just put into the tree.
id be extremely happy if someone would take the functionality here
and fit it into bioctl.
/*
* Copyright (c) 2010 David Gwynne d...@openbsd.org
*
* Permission to use, copy, modify
you cant test a variable and then sleep on it without blocking
interrupts, cos a completion could change the variables state between
those two actions.
could anyone test setting a hotspare on ami(4) while doing io?
dlg
Index: ami.c
i have no idea how to test this.
tests? oks?
Index: ip_mroute.c
===
RCS file: /cvs/src/sys/netinet/ip_mroute.c,v
retrieving revision 1.71
diff -u -p -r1.71 ip_mroute.c
--- ip_mroute.c 30 Sep 2014 12:54:22 - 1.71
+++
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
im in two minds about this.
on the one hand, its not like this can be attacked remotely. on the
other hand, maybe someone would create a metric buttload of files
and open all the ones with inodes whose values are 4096 apart.
discussion? tests? ok?
part of me thinks we shoudl apply siphash to
can someone test this? and eyeball the use of a pointer as data to
get mixed into the hash?
Index: ufs_quota.c
===
RCS file: /cvs/src/sys/ufs/ufs/ufs_quota.c,v
retrieving revision 1.35
diff -u -p -r1.35 ufs_quota.c
--- ufs_quota.c 13
src/sys/queue.h invalidates pointers in lists if DIAGNOSTIC is
enabled, so ufs_ihash.c doesnt have to.
ok?
Index: ufs_ihash.c
===
RCS file: /cvs/src/sys/ufs/ufs/ufs_ihash.c,v
retrieving revision 1.20
diff -u -p -r1.20 ufs_ihash.c
this cuts all the hashes in the filesystems over to using siphash
to get keys into their hashes.
i have compiled all of them, and will start on testing them as much
as i can. so far i have done softdep and started on the nfs srv
cache. id like help and review though.
Index:
On 18 Nov 2014, at 11:39, Ted Unangst t...@tedunangst.com wrote:
On Tue, Nov 18, 2014 at 11:06, David Gwynne wrote:
+#include dev/rndvar.h
Sorry to interrupt :), but I think it's become clear that rndvar.h is
the wrong header for arc4random() to live in.
agreed.
The diff below moves
101 - 200 of 1094 matches
Mail list logo
