On Jun 23, 2015, at 12:17 PM, Reinoud Zandijk rein...@netbsd.org wrote:
Hi Matt,
On Sun, Jun 21, 2015 at 01:42:38PM -0700, Matt Thomas wrote:
On Jun 21, 2015, at 12:02 PM, Reinoud Zandijk rein...@netbsd.org wrote:
On Sun, Jun 21, 2015 at 08:01:47AM -0700, Matt Thomas wrote:
IMO,
(sorry, I'm not subbed to list; only saw your reply by looking up archives)
The only high priority events are socket out of band data.
EV_OOB is only used in 3 c files:
http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24i=EV_OOB
It is simple enough for us to do the same if that's useful.
Hello,
I have NetBSD 6.1.5 on a amd64 with USB 3.0 ports.
When writing files to an external USB (3.0) connected disk, using
ntfs-3g, the write performance is abyssal : it is only USB 1.0 (12
Mbps or 1.5MB/s).
From the manual pages (ehci(4)), NetBSD 6.x supports only USB 2.0 via
ehci(4). The
David Holland writes:
On Fri, May 01, 2015 at 07:48:37PM +0200, Joerg Sonnenberger wrote:
On Fri, May 01, 2015 at 01:58:34PM -0300, Leandro Santi wrote:
A quick look at build.sh shows that one of the first things that
needs to be done is to map the MACHINE name to the CPU architecture
On Jun 24, 2015, at 10:27 AM, Jeff Rizzo r...@tastylime.net wrote:
On 6/24/15 7:13 AM, matthew green wrote:
David Holland writes:
I think keeping evb* for boards makes sense, though.
i dunno.
i don't see what it adds. in particular, evb means evaluation
board, and there are heaps of
I agree that evb* is confusing and increasingly meaningless and would
like to see us transition away from it.
I contend that moving to sys/arch/cpu is incorrect which there are
multiple MACHINE values for that CPU. sys/tem/mips (haha!) or
sys/platform/mips (yuk) or sys/arch/cpusys or
In article caenby+cd28rgjiw69_0jxfffhqtlvwtvofmre-cc8ykbmsn...@mail.gmail.com,
Daurnimator q...@daurnimator.com wrote:
(sorry, I'm not subbed to list; only saw your reply by looking up archives)
The only high priority events are socket out of band data.
EV_OOB is only used in 3 c files:
The reason kgdb wasn't working all this time on amd64 is that GETC()
returns -1 immediately whether or not a character is available =
all of kgdb's checksums fail due to the extra -1 characters.
A quick revert of
RCS file: /cvsroot/src/sys/dev/ic/com.c,v
revision
On 2015/06/24 07:17, takahiro hayashi wrote:
On 2015/06/23 17:01, takahiro hayashi wrote:
Hi,
On 2015/06/23 16:12, Nick Hudson wrote:
On 06/23/15 07:43, takahiro hayashi wrote:
[snip]
+ USB keyboard interaction is laggy and annoying.
Any idea why keyboard is laggy?
Currently I'm not
On Wed, Jun 24, 2015 at 04:01:24PM -0700, Matt Thomas wrote:
I agree that evb* is confusing and increasingly meaningless and
would like to see us transition away from it.
I contend that moving to sys/arch/cpu is incorrect which there
are multiple MACHINE values for that CPU.
On Wed, Jun 24, 2015 at 04:42:12PM +0100, Patrick Welche wrote:
The reason kgdb wasn't working all this time on amd64 is that GETC()
returns -1 immediately whether or not a character is available =
all of kgdb's checksums fail due to the extra -1 characters.
The attached gets us that far.
In article 20150624163947.ga17...@quark.internal.precedence.co.uk,
Patrick Welche pr...@cam.ac.uk wrote:
-=-=-=-=-=-
On Wed, Jun 24, 2015 at 04:42:12PM +0100, Patrick Welche wrote:
The reason kgdb wasn't working all this time on amd64 is that GETC()
returns -1 immediately whether or not a
On 6/24/15 7:13 AM, matthew green wrote:
David Holland writes:
I think keeping evb* for boards makes sense, though.
i dunno.
i don't see what it adds. in particular, evb means evaluation
board, and there are heaps of things in evb* that are *not*
evaluation boards, but stuff that might have
13 matches
Mail list logo
