Michael McConville wrote:
> Maxim Pugachev wrote:
> > In a case when the shell name is not specified (i.e. just "#!" without
> > a path), don't run the heavy logic that checks shell, simply return
> > ENOENT.
>
> I'm not sure whether this is a reasonable thing to do. Someone with more
> kernel API
On Sun, Jan 10, 2016 at 05:11:35PM +0100, Mark Kettenis wrote:
> > Date: Sun, 10 Jan 2016 16:47:05 +0100
> > From: Stefan Sperling
> >
> > Add events which occur when docking/undocking a tablet observed
> > on the Helix 2.
>
> You have a tabs vs. spaces inconsistency, but otherthan that, this is
On Sun, Jan 10, 2016 at 04:03:03PM +0100, Mark Kettenis wrote:
> The diff below adds (minimal) support for the 3.0 specification. The
> most important bit is support for the higher base clock and the larger
> divisors that this standard brings. It doesn't really add support for
> the new features
On Sun, Jan 10, 2016 at 07:21:37PM +0100, Mark Kettenis wrote:
> Apparently the CIS on the Broadcom BCM43341 in the ASUS X205TA has
> CISTPL_NULL codes, which causes somedmesg spam:
>
> sdmmc1: CIS parse error at 4286, tuple code 0, length 0
>
> Handling these is simple. They're just bytes that
On Thu, Jan 07, 2016 at 05:56:17PM +0100, Martin Pieuchot wrote:
> I spent some time trying to implement clustering writes for MSDOSFS
> before I could figure out that our cluster_write() functions is not
> doing anything but delaying the calls do bawrite(). Awesome!
>
> So I think it's time for
On Sun, Jan 10, 2016 at 05:58:13PM +0100, Denis Fondras wrote:
> On Sun, Jan 10, 2016 at 03:42:34PM +, Christian Weisgerber wrote:
> > You don't actually describe your interface configuration. I _guess_
> > you are trying to terminate IP traffic directly on an svlan(4)
> > interface. That sou
Hi Todd,
Todd C. Miller wrote on Sun, Jan 10, 2016 at 12:33:07PM -0700:
> On Sun, 10 Jan 2016 19:55:53 +0100, Ingo Schwarze wrote:
>> So, my conclusion is that it's the C standard that is carelessly
>> worded, not POSIX. I don't think the C standard intends to say
>> that fgetwc(3) and fputwc(3
> Date: Sun, 10 Jan 2016 21:28:31 +0100
> From: Joerg Jung
>
> On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote:
> > Hi,
> >
> > I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's
> > instructions [1], OpenBSD is the only OS and boots via EFI.
> >
> > I'
On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote:
> Hi,
>
> I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's
> instructions [1], OpenBSD is the only OS and boots via EFI.
>
> I'm experiencing a problem with LCD backlight: on wakeup from suspend, the
> ba
Makes sense.
Thanks!!
El 10/1/2016 20:59, "Peter Hessler" escribió:
> This is not a bug.
>
> As long as the router for the dhcp client has a route to the DNS server,
> then they can connect.
>
>
> On 2016 Jan 10 (Sun) at 20:53:23 +0100 (+0100), Pablo M??ndez Hern??ndez
> wrote:
> :Hi tech@,
> :
On 2016/01/10 20:53, Pablo Méndez Hernández wrote:
> Hi tech@,
>
> Below you can find what I think is a typo and an error. As far as I
> understand it the IP shown could only be reached if you match the
> subnet segment.
"option domain-name-servers" would often be the same for all subnets,
so out
This is not a bug.
As long as the router for the dhcp client has a route to the DNS server,
then they can connect.
On 2016 Jan 10 (Sun) at 20:53:23 +0100 (+0100), Pablo M??ndez Hern??ndez wrote:
:Hi tech@,
:
:Below you can find what I think is a typo and an error. As far as I
:understand it the
Hi tech@,
Below you can find what I think is a typo and an error. As far as I
understand it the IP shown could only be reached if you match the
subnet segment.
Kind regards.
--
Pablo Méndez Hernández
--- faq/pf/example1.html.orig 2016-01-10 20:44:21.926795536 +0100
+++ faq/pf/example1.html
> Date: Sun, 10 Jan 2016 19:44:27 +0100
> From: Stefan Kempf
>
> Martin Natano wrote:
> > Below the uiomove() conversion for dev/ksyms.c. 'len' is a size_t.
>
> And len is computed from values >= 0 and from expressions that do not
> wrap around.
>
> ok?
ok kettenis@
> > Index: dev/ksyms.c
> >
On Sun, 10 Jan 2016 19:55:53 +0100, Ingo Schwarze wrote:
> So, my conclusion is that it's the C standard that is carelessly
> worded, not POSIX. I don't think the C standard intends to say
> that fgetwc(3) and fputwc(3) are not allowed to set the error
> indicator on an encoding error, it just do
Hi,
Ted Unangst wrote on Wed, Dec 30, 2015 at 01:22:17AM -0500:
> Philip Guenther wrote:
>> On Tue, Dec 29, 2015 at 2:34 PM, Todd C. Miller wrote:
>>> Since POSIX defers to ISO C we should be following the ISO C standard
>>> with respect to behavior when an encoding error occurs. As such,
>>> I'
looks good to me.
ok?
Martin Natano wrote:
> Below the conversion from uiovmovei() to uiomove() for miscfs/fusefs/.
> All size parameters already are size_t, so the diff is straightforward.
>
> Index: miscfs/fuse/fuse_device.c
> ===
Martin Natano wrote:
> Below the uiomove() conversion for dev/ksyms.c. 'len' is a size_t.
And len is computed from values >= 0 and from expressions that do not
wrap around.
ok?
> Index: dev/ksyms.c
> ===
> RCS file: /cvs/src/sys/de
Apparently the CIS on the Broadcom BCM43341 in the ASUS X205TA has
CISTPL_NULL codes, which causes somedmesg spam:
sdmmc1: CIS parse error at 4286, tuple code 0, length 0
Handling these is simple. They're just bytes that have to be skipped.
Diff below rearranges the parsing loop a bit to accompl
On Sun, Jan 10, 2016 at 03:42:34PM +, Christian Weisgerber wrote:
> You don't actually describe your interface configuration. I _guess_
> you are trying to terminate IP traffic directly on an svlan(4)
> interface. That sounds very unusual.
>
Sorry, the configuration is actually :
/etc/hostn
Hi,
Ingo Schwarze wrote on Wed, Dec 23, 2015 at 07:44:05PM +0100:
> Steffen Nurpmeso wrote on Wed, Dec 23, 2015 at 11:45:36AM +0100:
>> Ingo Schwarze wrote:
>>> For example, colrm(1).
[Regarding one of the various bugs in FreeBSD:]
>>> 4. The backspace character (U+0008) backs up by one display
> Date: Sun, 10 Jan 2016 16:47:05 +0100
> From: Stefan Sperling
>
> Add events which occur when docking/undocking a tablet observed
> on the Helix 2.
You have a tabs vs. spaces inconsistency, but otherthan that, this is ok
> Index: acpithinkpad.c
> ==
Add events which occur when docking/undocking a tablet observed
on the Helix 2.
Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.50
diff -u -p -r1.50 acpithinkpad.c
--- acpithinkpad.c
On 2016-01-10, Denis Fondras wrote:
> Following http://article.gmane.org/gmane.os.openbsd.tech/47475, I have a
> similar
> problem with svlan(4) and em(4) (Intel 80003ES2). The main difference with
> bge(4) is that ping works with em(4) but not tcp/udp. (obviously my bge(4)
> supports IFCAP_CSUM
The diff below adds (minimal) support for the 3.0 specification. The
most important bit is support for the higher base clock and the larger
divisors that this standard brings. It doesn't really add support for
the new features that allow faster data transport.
ok?
Index: sdhc.c
===
> Date: Mon, 11 Jan 2016 00:50:23 +1100
> From: Jonathan Gray
>
> On Sun, Jan 10, 2016 at 12:34:56PM +0100, Mark Kettenis wrote:
> > Seems the voltage bit defenitions in sdmmcreg.h for voltages below 2V
> > are not quite right. At least I can't find them in any of the MMC and
> > SD card documen
Hi,
Following http://article.gmane.org/gmane.os.openbsd.tech/47475, I have a similar
problem with svlan(4) and em(4) (Intel 80003ES2). The main difference with
bge(4) is that ping works with em(4) but not tcp/udp. (obviously my bge(4)
supports IFCAP_CSUM_IPv4 and not my em(4)).
Everything works fi
On Sun, Jan 10, 2016 at 12:34:56PM +0100, Mark Kettenis wrote:
> Seems the voltage bit defenitions in sdmmcreg.h for voltages below 2V
> are not quite right. At least I can't find them in any of the MMC and
> SD card documentation I can find on the interwebs. Instead there is a
> single "low volt
Hi,
I have a problem with svlan(4) and bge(4) (Broadcom BCM5721).
With TCO :
denis@jigai:~$ ssh root@10.20.30.210
root@10.20.30.210's password:
Last login: Sun Jan 10 13:22:27 2016 from 192.168.10.10
OpenBSD 5.9-beta (GENERIC) #1: Sun Jan 10 13:25:07 CET 2016
Welcom
The uiomove() manual page states that "The lesser of n or uio->uio_resid
bytes are copied." However, this is only true, when uio_resid ends up on
an iovec boundary. Otherwise more bytes may be copied, even if they
exceed uio_resid. The patch below changes uiomove() to actually never
copy more than
Seems the voltage bit defenitions in sdmmcreg.h for voltages below 2V
are not quite right. At least I can't find them in any of the MMC and
SD card documentation I can find on the interwebs. Instead there is a
single "low voltage bit" that indicates support for the 1.65-1.95V or
1.70-1.95V range
31 matches
Mail list logo
