Hey all,
Here's a diff for adding the product ID for the Intel 82567V-4 NIC to
pcidevs and adding the card to em(4) (along with a corresponding man
update). The product ID came from the FreeBSD em. The information about
jumbo frames came from Intel's jumbo frame notes. This is my first
contributio
I noticed that httpd will exit if it attempts to serve a file from
a cd9660 filesystem. This is due to libevent's use of kqueue by
default and kqueue's lack of support for cd9660 filesystems. I'm
not sure if this is the most appropriate fix but the patch below
restricts the server processes from us
I took a shot at fixing this the correct way by adding kqueue support
to cd9660. Hopefully I'm on the right track here with this diff based on
what I saw for ufs.
Index: cd9660_vnops.c
===
RCS file: /cvs/src/sys/isofs/cd9660/cd9660_v
While studying bsd.port.mk I ran across a reference to
PACKAGES_REPOSITORY that seems like a typo. My assumption is that it
is supposed to be PACKAGE_REPOSITORY as in the rest of the document
(and in the FAQ, etc.).
Index: bsd.port.mk.5
=
lps some folks! I apologize that I am using 7.2-stable
and not -current.
Thanks,
John Browning
Hey,
It's: hw.vendor=LENOVO
hw.product=20Y4S1QE00
hw.version=ThinkPad P1 Gen 4i
That patch seems to be a better method.
Thanks!
On Fri, Nov 4, 2022 at 10:06 AM Jonathan Gray wrote:
>
> On Fri, Nov 04, 2022 at 09:10:52AM -0500, John Browning wrote:
> > Hi,
> > I noticed
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
> On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
> > Hi tech --
> >
> > Reminded by the recent email to tech@ about calendar.christian, I
> > took a look at syncing calendar.judaic.
> >
> > This diff does the following:
> >
On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote:
>
> On 11/12/18 11:20 AM, John Long wrote:
> > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
> > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
> > > > Hi tech --
> > &g
On Mon, 2018-11-12 at 15:01 -0500, Brian Callahan wrote:
>
> On 11/12/18 1:13 PM, John Long wrote:
> > On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote:
> > > On 11/12/18 11:20 AM, John Long wrote:
> > > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyr
I've just been trying to update a socks server to support IPv6 and found
that nc wasn't consuming all of the socks connect reply. I think that this
patch fixes this.
Index: socks.c
===
RCS file: /cvs/src/usr.bin/nc/socks.c,v
retrievi
oubleshoot this, but the dmesg after the commands
above and an attempted shutdown is below. I'm running the 4/28 snapshot
and applied the diff to kernel source synced a few hours ago. Let me
know what else I can provide.
Thanks,
John
OpenBSD 5.9-current (GENERIC.MP) #2: Fri Apr 29
On 5/1/16 3:09 PM, Mark Kettenis wrote:
Date: Sat, 30 Apr 2016 13:31:21 +0200 (CEST)
From: Mark Kettenis
From: John Troy
Date: Fri, 29 Apr 2016 11:56:24 -0400
On 4/28/16 2:30 PM, Mark Kettenis wrote:
So here are just the bits that add DMA support. Since Theo likes this
so much, I'd
I'm not an OpenBSD user, I'm not asking for help. I'm posting here
because OpenBSD was the only mention of this device I found when
searching the net. My device also identifies as 0x4651 0x3273, though
marked as PCI 60806 instead of TX382B. I never found a data sheet for
it, but after some trial an
makes it clearer for
someone like myself
2. The second suggestion handles the edge case where the argument to rcctl
matches the name of a subdirectory of rc.d. Note that ls_rcscripts()
earlier in the script has the same test
John
Index: etc/rc.d/rc
Not sure if folks are interested in this or not, but it sure caused me some
angst this morning. OSX has the same behaviour and also doesn't document
it. I assume it has been that way for a long, long time.
My first patch. Thanks for all the cool stuff :-)
Index: bin/test/test.1
==
So it does. Not sure how I missed that, but I did. Oh well. Thanks :-/
John
On 1 October 2016 at 14:31, Theo Buehler wrote:
> On Sat, Oct 01, 2016 at 01:38:49PM +1000, john slee wrote:
> > Not sure if folks are interested in this or not, but it sure caused me
> some
> > angst
sing all simplify
management, thus minimize the chance of error and enhance security.
This is true whether management is local or through a remote tool
like ansible. Or?
John
On Tue, Nov 22, 2016 at 10:46 AM, John Boeske wrote
> On Mon, Nov 21, 2016 at 3:48 PM, Antoine Jacoutet wrote
> > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> > > Ansible is already managing pkg and service of openBSD , cool
> > >
> > > I
Fantastic! Will be great for quick jobs without banshee fan wail and roasted
office space in the long summers.
Thank you.
/jl
On Fri, Dec 19, 2014 at 06:22:47PM -0700, Theo de Raadt wrote:
> The ntp daemon included in OpenBSD is our own openntpd, written
> from scratch.
>
> openntpd is not vulnerable.
Thank you OpenBSD people and project.
I just shitcanned ntp on my Linux box and replaced it with openntpd.
I plan to do
r: [drm:pid0:rs400_startup] *ERROR* failed initializing CP (-22).
error: [drm:pid0:rs400_init] *ERROR* Disabling GPU acceleration
error: [drm:pid0:r100_cp_fini] *ERROR* Wait for CP idle timeout,
shutting down CP.
error: [drm:pid0:r100_cp_disable] *ERROR* Failed to wait GUI idle while
programming pipes. Bad things might happen.
drm: radeon: cp finalized
radeondrm0: 1280x1024
wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
--
John Merriam
c or non-standard feature of a particular flavor
of a particular family of shells is not a good idea when writing a shell
script. If you can't do what you want without relying on that
particular feature then maybe what you're writing shouldn't be a shell
script. If it's a bug in a particular flavor of a shell, then instead
of checking for and working around it, report the bug to the
author/maintainer.
--
John Merriam
On Tue, 17 Feb 2015, Adam Thompson wrote:
> On 2015-02-17 08:06 PM, John Merriam wrote:
> > I definitely agree that the silliness of checking a version string to
> > possibly use some exotic or non-standard feature of a particular flavor of a
> > particular family of shells is
anted to pass along a BIG THANK YOU to all the OpenBSD developers
for all the great work you do!
--
John Merriam
r/xenocara/lib/libXont
+cd /usr/xenocara/lib/libXfont
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper build
Looks like the 5.5 patch has the same typo.
Also wanted to pass along a BIG THANK YOU to all the OpenBSD developers
for all the great work you do!
--
John Merriam
if I can find it but is there a different process to
build all of libssl to be sure it's all patched?
--
John Merriam
On Thu, 19 Mar 2015, John Merriam wrote:
> On Thu, 19 Mar 2015, Ted Unangst wrote:
>
> > Ted Unangst wrote:
> > > Patches are now available to fix a variety of issues in libcrypto and
> > > libssl.
> > > 5.5 patch:
> > > http://ftp.openbsd.org/pub/
fe9vYVqjf1a:5000:5000:: \
0:0:Some User:/home/some.user:/bin/ksh
...
As you can see the password entry gets corrupted with a 'b/bin/ksh...'
This behavior does not occur with -unencrypted.
Behavior *is* present when hash is wrapped in "
Take care,
John
libressl-2.5.1-medusade.tar.gz
Description: GNU Zip compressed data
On Wed, Sep 11, 2013 at 08:42:46PM +0300, Valentin Zagura wrote:
> The idea was to display a checksum of the files on such a https page.
> Like for example https://www.freebsd.org/releases/9.1R/announce.html at the
> bottom of the page.
>
>
> On Wed, Sep 11, 2013 at 7:18 PM, Stuart Henderson wro
Problem in a nutshell: pthread_getspecific serializes execution of
threads using it. Without a better implementation my program doesn't
work on OpenBSD.
I am trying to port Cilk+ to OpenBSD (5.3).
Cilk+ is a multithreaded extension to C/C++. It adds some bookkeeping
operations in the prologue
I attached a program showing the slowdown. It spawns threads that call
pthread_getspecific in a tight loop. On Linux the wall clock time is
essentially constant for number of threads up to number of processors.
On OpenBSD 5.3 wall clock time increases approximately linearly with
number of process
I think _spinlock is suboptimal, although that's not the real problem
as far as my code is concerned. Spinlock is a loop:
while (_atomic_lock(&lock->ticket)) _sched_yield();
This causes a system call every time the lock is held by another thread.
In many cases the spinlock protects a simple o
Here is a diff relative of OpenBSD 5.3 to avoid taking a lock in
pthread_getspecific in the common case where storage for the key is
already allocated.
I have only tested this patch for my use case where a single key is
created once and used many times. In that case, the bottleneck I
observed is
I got an email saying unified diff is preferred, so here's a resend
in that format.
Index: rthread_tls.c
===
RCS file: /cvs/src/lib/librthread/rthread_tls.c,v
retrieving revision 1.13
diff -u -r1.13 rthread_tls.c
--- rthread_tls.c 6 N
On 30 November 2013 21:59, Lars Nooden wrote:
> perlre(1) seems to be missing information about substitution evaluations
> with the /e option. The functionality is present in perl:
>
It is, however, already documented in perlop(1)
John
Why does a rarely called function need to be inline?
> Testing whether a process is (currently) done by checking whether the
> process's thread list has a single item. This is currently done in just
> two places, but I expect to need this in more places, so let's abstract
> that into an inlin
"gdb" (gdb 6.3) knows about threads but core dumps half the time
and is 10 years old.
"egdb" (gdb 7.6) does not work right with multithreaded programs. It
sees only one thread.
Neither supports "set scheduler-locking".
Is there any good option for debugging a multithreaded program?
I'm runnin
> > Is there any good option for debugging a multithreaded program?
>
> By defenition there isn't. Anything you do will affect the timing of
> your program. If you want debugability, avoid threads.
Race-free parallel programming is an active area of research. I can't
accept your definition be
well. The other greps didn't.
SunOS fakename 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-250
AIX fakename 1 6 005D981A4C00
OSF1 fakename V4.0 1229 alpha
SCO_SV fakename 3.2 2 i386
Though GNU grep does support this behaviour also. I like and use it.
John
ommercial UNIX I'm seeing in job listings these days, for what
that's worth. Solaris seems to be a corpse, and the flies are
swarming. I guess
people really don't need "DTrace and ZFS" after all ;-)
John
rving this history.
--
John Baldwin
On Sun, Mar 03, 2013 at 04:16:30PM +, Stuart Henderson wrote:
> Summary of off-list mail exchange: anoncvs.usa consistently has a
> realloc failure in xenocara/font/misc-misc/18x18ja.bdf, some other
> servers have a failure the first time checking this file out when
> it's part of the whole dir
Hello,
What have you been up to ?
Tell you a good news. At last few days,My friend Jack told me where
was called the factory of world.All the things is very cheap.
Register to be their members as soon as possible, during this time,
they have discount sales, many surprises are waiting for you.
w
rom my understanding is more complicated due to
display routing and other related features and FreeBSD does NOT
yet have support for it.
> It was implemented 2015 by John-Mark Gurney .
John Baldwin, j...@freebsd.org ended up implementing it differently
and not using the code I had written, so he
round would
be greatly appreciated.
Toshiba L505D-S5965
AMD Athlon Dual Core QL-65
3GB SDRAM, 250GB HDD
15.6" TruBrite Wide screen
DVD drive.
ATI Radeon graphics
thanks
John
John J. Rushford wrote:
Greetings,
I'm trying to install OpenBSD 4.6 onto a Toshiba L505D-S5965 Laptop and
am running into a problem. Just after booting from the kernel from the
install CD, the screen turns white and I am unable to proceed with the
install. Any ideas as to what is ca
This changes the dmesg on one acpi enabled machine:
acpiprt3 at acpi0: bus -1 (MPCI)
-acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals last
-acpicpu0: struck PSS entry, core frequency equals last
+acpicpu0 at acpi0
+acpicpu0: struck PSS entry, core frequency equals last
+acpic
- just use a buffer and make onewire_crc16() operate like onewire_crc()
- some style cleanups
- build for i386 GENERIC (only arch tested)
Index: onewire_subr.c
===
RCS file: /cvs/src/sys/dev/onewire/onewire_subr.c,v
retrieving revisi
fixes panic on attach/detach due to free list corruption, also use
after usbd_free_xfer(), tested on i386
~~~
Index: uow.c
===
RCS file: /cvs/src/sys/dev/usb/uow.c,v
retrieving revision 1.33
diff -u -p -s -r1.33 uow.c
--- uow.c
On Sun, Aug 30, 2015 at 12:32:24PM +0200, Martin Pieuchot stated:
> That's good but the original design of allocating an xfer for every
> usbd_transfer(9) call does not make much sense.
>
> You could allocate two xfers (one for read and one for write) at the
> same time the pipes are opened and
There was some discussion of this on misc@ recently. Some Baytrail
boards are setting local APIC flags to 0b11, which is a reserved value.
The acpidump and other info related to the problem is capture over
there, as well. Ref:
http://marc.info/?l=openbsd-misc&m=140043989412703&w=2
Instead of pan
On Thu, May 22, 2014 at 08:27:40PM -0400, John D. Verne wrote:
> There was some discussion of this on misc@ recently. Some Baytrail
> boards are setting local APIC flags to 0b11, which is a reserved value.
>
> The acpidump and other info related to the problem is capture over
>
r import into FreeBSD.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
keep these changes to a minimum between the two.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
of
> boundary access, depending on actual pmp->pm_maxcluster value.
FreeBSD fixed this by increasing the malloc size:
https://svnweb.freebsd.org/changeset/base/r126086
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
n =
> write(nfd, buf, available);
> + if (n !=
> available) {
> +
> return;
> + }
> + }
> + write_space_network
> -= available;
> + /* Break to ignore
> EVFILT_WRITE that could
> +* be in current
> keventlist, after this event
> +* and which is now
> invalid, because we just
> +* write in the fd.
> +*/
> + break;
> + }
> + }
> + }
As this second half of the path is the same as the first, my previous
comments also apply...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
a version with does 4 blocks at a time getting a
further speed up...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Christian Weisgerber wrote this message on Tue, Oct 07, 2014 at 23:08 +0200:
> John-Mark Gurney:
>
> > So, as I was working on FreeBSD's implementation of gmac.c, I noticed
> > that I was able to get a significant speed up by using a mask instead
> > of an if branch
Mike Belopuhov wrote this message on Wed, Oct 08, 2014 at 14:32 +0200:
> On 8 October 2014 00:48, John-Mark Gurney wrote:
> > Christian Weisgerber wrote this message on Tue, Oct 07, 2014 at 23:08 +0200:
> >> John-Mark Gurney:
> >>
> >> > So, as I was workin
ssize_t (*f) (int, void *, size_t)
to ssize_t (*f) (int, const void *, size_t)... There isn't any reason
why atomicio needs to have a non-const pointer to the buffer...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Mike Belopuhov wrote this message on Wed, Nov 12, 2014 at 19:05 +0100:
> On 10 October 2014 02:39, Damien Miller wrote:
> > On Thu, 9 Oct 2014, Christian Weisgerber wrote:
> >
> >> John-Mark Gurney:
> >>
> >> > I also have an implementation of ghash
62 matches
Mail list logo