Re: SD Host Controller 3.0 support

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

Re: acpithinkpad tablet dock/undock events

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

Re: [patch] kern/exec_script: return error when the shell name is not specified

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

Problem with svlan(4) and bge(4)

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

Problem with svlan(4) and bge(4)

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

sdmmc voltage bits

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

acpithinkpad tablet dock/undock events

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

Re: Problem with svlan(4) and bge(4)

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)

Re: Problem with svlan(4) and bge(4)

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 :

Re: acpithinkpad tablet dock/undock events

> 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 >

SD Host Controller 3.0 support

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

Re: UTF-8 support for colrm(1)

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)

Re: sdmmc voltage bits

> 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 >

Re: bug in fputwc(3) error reporting

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, >>>

Re: ksyms uiomove() conversion

> 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@ > >

Re: bug in fputwc(3) error reporting

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

Re: Patch to new PF FAQ entry

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

Re: Patch to new PF FAQ entry

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

Re: ksyms uiomove() conversion

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:

Re: Patch to new PF FAQ entry

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 >

Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)

> 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

Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)

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 >

Re: fusefs uiomove() conversion

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 >

Patch to new PF FAQ entry

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

Re: bug in fputwc(3) error reporting

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

Re: Problem with svlan(4) and bge(4)

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

Re: sdmmc CIS parsing fix

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