On Thu, May 19, 2016 at 01:15:57AM +0200, Jeremie Courreges-Anglas wrote:
>
> As noticed by djm it doesn't make much sense to expose this in sysctl(8)
> output.
>
> ok?
OK, especially since it makes the setsockopt code path actually
understandable.
> Index: sbin/sysctl/sysctl.8
> =
Hi,
All msg buf counters are long, so lmin(9) should be used here.
ok?
bluhm
Index: kern/subr_log.c
===
RCS file: /cvs/src/sys/kern/subr_log.c,v
retrieving revision 1.43
diff -u -p -r1.43 subr_log.c
--- kern/subr_log.c 18 May 2
As noticed by djm it doesn't make much sense to expose this in sysctl(8)
output.
ok?
Index: sbin/sysctl/sysctl.8
===
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.193
diff -u -p -r1.193 sysctl.8
--- sbin/sysctl/sys
Back in the old cool days you could simply call ether_output() with a
stuffed sockaddr and it will do the L2 resolution for you... Well as
long as you do not care about IPv6 it's true.
During the last years I tried to reduce the number of places where
ether_output() was called without passing it
Patrick Wildt wrote:
> The same issue can be reproduced by calling usbdevs(8) in a loop. It
> uses the same ioctl and "breaks" this usb mass storage.
As a rule, we should limit the contact users have with hardware. "Safe"
readonly operations are no exception.
On 18/05/16(Wed) 18:28, Patrick Wildt wrote:
> Hi,
>
> I had the pleasure of debugging a USB mass storage device that showed
> interesting behaviour when used with our stack and in combination with
> the blink(1) usb device.
>
> The blink(1)-tool depends on libusb. Libusb calls ioctl(USB_DEVICEI
Bryan C. Everly wrote:
> I just received my 12" Retina Macbook (the Macbook9,1) which is the
> latest Skylake version. I would really like to get OpenBSD running on
> this and am happy to trace any code, build patches, stand on my head,
> etc. if I could get someone interested in working with me t
Looks good to me
> On May 18, 2016, at 11:14 PM, Jason McIntyre wrote:
>
>> On Wed, May 18, 2016 at 12:13:14AM +0800, Ray Lai wrote:
>> Also separate out the specification (does that count as a "standard"?)
>> and the implementation.
>
> i've tweaked the diff a little to shorten it and keep the
On Wed, May 18, 2016 at 09:32:55AM -0500, joshua stein wrote:
> On Wed, 18 May 2016 at 09:33:36 -0400, Bryan C. Everly wrote:
> > 2. The keyboard works at the boot prompt, but does not work once the
> > install/upgrade/shell prompt comes up
>
> The keyboard and trackpad appear to be connected ove
Hi,
I had the pleasure of debugging a USB mass storage device that showed
interesting behaviour when used with our stack and in combination with
the blink(1) usb device.
The blink(1)-tool depends on libusb. Libusb calls ioctl(USB_DEVICEINFO)
plenty of times to get a map of the USB tree. Per ioc
On Wed, May 18, 2016 at 11:46:32AM +0200, Martin Pieuchot wrote:
> Please test and report back.
Works fine on my T430s. I have tried several suspend/resume cycles,
once the laptop did not come back but resumed immediately again.
But I cannot reproduce that single failure, now it works.
> @@ -137
On Wed, May 18, 2016 at 12:13:14AM +0800, Ray Lai wrote:
> Also separate out the specification (does that count as a "standard"?)
> and the implementation.
>
i've tweaked the diff a little to shorten it and keep the links in one
section. STANDARDS seems the better choice. i also don;t think the
On Wed, 18 May 2016 at 09:33:36 -0400, Bryan C. Everly wrote:
> 2. The keyboard works at the boot prompt, but does not work once the
> install/upgrade/shell prompt comes up
The keyboard and trackpad appear to be connected over SPI:
https://bugzilla.kernel.org/show_bug.cgi?id=99891
While there m
Stuart Henderson writes:
> On 2016/05/18 14:01, Jeremie Courreges-Anglas wrote:
>> Stuart Henderson writes:
>>
>> > Removing the sysctl should be very pretty safe as far as ports goes (I
>> > did wonder if thing s might read the sysctl and change behaviour but it
>> > seems that's not the case)
Hello tech@
I just received my 12" Retina Macbook (the Macbook9,1) which is the
latest Skylake version. I would really like to get OpenBSD running on
this and am happy to trace any code, build patches, stand on my head,
etc. if I could get someone interested in working with me to figure
this thin
Tue, 17 May 2016 08:27:42 -0500 Brent Cook
> This patch came by way of the openntpd github. Linux (and possibly others)
> will attempt to bind to 0.0.0.0 when binding to '::' and return an error if
> it can't, unless IPV6_V6ONLY is set. See
> https://github.com/openntpd-portable/openntpd-portable/
> Yes, the ioctl has to stay for exactly the reasons you give.
> These are all over the tree. It's not 1 ports, but pretty
> much *everything* that talks v6 and listens on dual sockets
> apart from maybe some niche BSD-centric things. These
> programs won't run on Linux without it. (They will r
On 2016/05/18 14:01, Jeremie Courreges-Anglas wrote:
> Stuart Henderson writes:
>
> > Removing the sysctl should be very pretty safe as far as ports goes (I
> > did wonder if thing s might read the sysctl and change behaviour but it
> > seems that's not the case). Looks like only nsh will break f
Stuart Henderson writes:
> Removing the sysctl should be very pretty safe as far as ports goes (I
> did wonder if thing s might read the sysctl and change behaviour but it
> seems that's not the case). Looks like only nsh will break from doing
> that and it's easily fixed.
I fear that this is on
Op 05/18/16 om 13:55 schreef Ingo Schwarze:
Hi,
Remco wrote on Wed, May 18, 2016 at 10:29:40AM +0200:
Op 05/18/16 om 01:49 schreef Edgar Pettijohn:
The wording made it hard for me to understand at first.
The "unless" "non-zero" seem like double negatives.
Actually, quadruple negation:
1
Hi,
Remco wrote on Wed, May 18, 2016 at 10:29:40AM +0200:
> Op 05/18/16 om 01:49 schreef Edgar Pettijohn:
>> The wording made it hard for me to understand at first.
>> The "unless" "non-zero" seem like double negatives.
Actually, quadruple negation:
1. Unless
2. nochdir is
3. non-
4. zero
My apologies for the noise; the previous one was the wrong revision (r1.126
instead of 1.127) because both patches look similar; here is the most recent
catch:
Index: sys/dev/softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid
Ted Unangst wrote:
> i removed these last two lines, since they were incorrect. thanks for spotting
> that. however the vop_close at the end still needs updating.
Thanks Ted,
Also I found another stray VOP_CLOSE() setup.
I have also put in the VOP_OPEN(vn, FREAD, ...) as I am not sure about 100%
Update iwm(4) to firmware version 16.242414.0 (API 16).
New firmware has been available in fw_update(1) for several weeks already.
Among many API changes this firmware version introduces a wide command header
for some commands because the old API format has run out command number space.
This firm
New version of my fix for the "ehci_device_clear_toggle: queue active"
panic. This diff gets bigger and bigger after the years but the logic
remains the same.
It changes when QH are added and removed to/from the async list. Instead
of keeping a QH on the list as long as a pipe is open we now add
Now what we are calling ARP input routines directly from ether_input()
there's no need to use another if_get()/if_put() dance.
ok?
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.235
di
Visa Hankala wrote:
> On Tue, May 17, 2016 at 02:02:37AM +0200, Kim Lidström wrote:
> > Is this patch better? I have tested it by trying both cnmac0, cnmac1 and
> > cnmac2 as rootdev and it seems to work properly.
> > I also removed the outdated comment, changed the pointless text (Maybe
> > it'd
Op 05/18/16 om 01:49 schreef Edgar Pettijohn:
The wording made it hard for me to understand at first. The "unless"
"non-zero" seem like double negatives.
Index: daemon.3
===
RCS file: /cvs/src/lib/libc/gen/daemon.3,v
retrieving re
On Wed, May 18, 2016 at 06:24:15AM +0800, Nathanael Rensen wrote:
> On 27 April 2016 at 17:33, Stefan Sperling wrote:
>
> > This version includes minor tweak: When the AP goes down, we don't
> > need to send disassoc frames to nodes in COLLECT state.
>
> While testing this diff I found some addi
Removing the sysctl should be very pretty safe as far as ports goes (I did
wonder if thing s might read the sysctl and change behaviour but it seems
that's not the case). Looks like only nsh will break from doing that and it's
easily fixed.
I did a search for things using the ioctl too. It look
30 matches
Mail list logo