Re: dhcrelay: send_packet: No buffer space available

On 12/02/16 18:56, Stuart Henderson wrote: On 2016-02-12, Kapetanakis Giannis wrote: Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: What

Re: Daily digest, Issue 3715 (21 messages)

Re: dhcrelay: send_packet: No buffer space available If it's easy to do try a different network card. The only time I've ever seen that error came from a urtwn card under OpenBSD 5.7 and earlier. But Stuart knows a lot more about it than I do. On 2/13/16, owner-m...@openbsd.org

Will Softraid RAID1 read from the fastest mirror/-s / supports user-specified device read priority order, nowadays? Takes broken disk out of use?

Hi, 1) http://www.openbsd.org/papers/asiabsdcon2010_softraid/softraid.pdf page 3 "2.2 RAID 1" says that it reads "on a round-robin basis from all active chunks", i.e. read operations are spread evenly across disks. Since then did anyone implement selective reading based on experienced read

How extensive OpenBSD's write caching (for softdep or async-mounted UFS, as long as I never fsync() )?

Hi, How much of my file writing, and filesystem operations such as creating a new file/directory, will land in OpenBSD's disk/write cache without touching the disk before return of the respective operation to my program, for softdep or async UFS media and I never fsync() ? This is relevant

Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

Hi, Some quite deep reading [1] taught me that at least quite recently, there was a ~3GB cap on the buffer cache, independent of architecture and system RAM size. Reading the source history of vfs_bio.c [2] gives me a vague impression that this cap is there also today. Just wanted to

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

I think you would also like to investigate this one: http://www.undeadly.org/cgi?action=article=2006061416 > Some quite deep reading [1] taught me that at least quite recently, there > was a ~3GB cap on the buffer cache, independent of architecture and system > RAM size.

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

Dear Karel, Thanks - wait - this post from 2006 you mentioned now, is it saying that actually >32bit/>~3GB buffer cache IS SUPPORTED/WORKS on any AMD64 *with IOMMU* support in the CPU, and was working all the time?? (That would mean that I misunderstood those references I posted in the

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

I'm afraid you read too quickly and w/o attention to detail, please reread and pay special attention to the last paragraph. Especially to: "IOMMU is present in all "real" AMD64 machines, but not the Intel clones. Unfortunately, OpenBSD support for IOMMU on the AMD machines is not quite ready for

"Abort trap" when pledge()d and compiled with -pg

When compiling a program that calls pledge(2) with "-pg" the resulting binary will execute seemingly fine, but at the very end die with: Abort trap (core dumped) I think the problem lies in a call to profil(2). Is this a bug or a feature? -- Michal Mazurek

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

Aha. So the article is saying that full IOMMU support is waiting on all AMD64 machines (so that would mean any Intel and AMD-manufactured processor with VT-d etc.), and you're saying that this is what needs to be implemented for the buffer cache to finally get >32bit/>~3GB support? Are there

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

On 2016-02-13, Tinker wrote: > Hi, > > Some quite deep reading [1] taught me that at least quite recently, > there was a ~3GB cap on the buffer cache, independent of architecture > and system RAM size. > > Reading the source history of vfs_bio.c [2] gives me a vague

Re: Accessing USB with OpenBSD 5.7/amd64

Hi Richard Same issue for me. Did you get any answer? Regards Jean-Louis

Re: Kernel panic during installation

On 2016-02-12, Donald Allen wrote: > On Fri, Feb 12, 2016 at 3:42 PM, Stefan Sperling wrote: > >> On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote: >> > I just used this exchange as an example to a friend who buys everything >> > Apple and then

Re: Kernel panic during installation

Stuart Henderson wrote on Sat, Feb 13, 2016 at 08:45:35PM +: > On 2016-02-12, Donald Allen wrote: >> On Fri, Feb 12, 2016 at 3:42 PM, Stefan Sperling wrote: >>> On Fri, Feb 12, 2016 at 03:03:46PM -0500, Donald Allen wrote: I just used this

USB device descriptor access bug (?)

On an amd64 5.8-release system running under VMWare, with the virtual USB controller configured as USB 2.0, I'm seeing a problem getting device descriptor strings off of USB devices (or, at least, the one that I care about). With the virtual USB configured to support USB 3.0, the problem goes

Setting setenv=DISPLAY=:1 in login.conf problem

Setting DISPLAY=:1 as setenv in /etc/login.conf selenium:\ :setenv=DISPLAY=:1:\ :tc=daemon: is a problem as colon is a separator and thus value is lost. Escaping or quoting did not work too. I put in my selenium rc script `env' to get environment vars and DISPLAY is unset: ...

Re: Setting setenv=DISPLAY=:1 in login.conf problem

On Sat, Feb 13, 2016 at 3:54 PM, Jiri B wrote: > Setting DISPLAY=:1 as setenv in /etc/login.conf > > selenium:\ > :setenv=DISPLAY=:1:\ > :tc=daemon: > > is a problem as colon is a separator and thus value is lost. > Escaping or quoting did not work too. ... > Any

Re: Setting setenv=DISPLAY=:1 in login.conf problem

On Sat, Feb 13, 2016 at 04:28:48PM -0800, Philip Guenther wrote: > On Sat, Feb 13, 2016 at 3:54 PM, Jiri B wrote: > > Setting DISPLAY=:1 as setenv in /etc/login.conf > > > > selenium:\ > > :setenv=DISPLAY=:1:\ > > :tc=daemon: > > > > is a problem as colon is a

Re: How extensive OpenBSD's write caching (for softdep or async-mounted UFS, as long as I never fsync() )?

Did two tests, one with async and one with softdep, on amd64, 5.9-CURRENT, UFS. (Checked "dd"'s sources and there is no fsync() anywhere in there. The bufcache setting was 90, 3GB free RAM, pushed 2GB of data using "dd" to disk. It took 12 and 15 seconds respectively, which is the

Re: Buffer cache made to use >32bit mem addresses (i.e. >~3GB support for the buffer cache) nowadays or planned soon?

On 2016-02-14 03:39, Stuart Henderson wrote: On 2016-02-13, Tinker wrote: Hi, Some quite deep reading [1] taught me that at least quite recently, there was a ~3GB cap on the buffer cache, independent of architecture and system RAM size. Reading the source history of