Updating src tree:
U src/common/lib/libc/string/strcspn.c
U src/common/lib/libc/string/strpbrk.c
U src/common/lib/libc/string/strspn.c
P src/distrib/sets/lists/base/ad.arm
P src/distrib/sets/lists/base/ad.mips
P src/distrib/sets/lists/base/ad.powerpc
P src/distrib/sets/lists/base/md.amd64
P src/di
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host,
using sources from CVS date 2014.07.19.20.21.52.
An extract from the build.sh output follows:
^
/tmp/bracket/build/2014.07.19.20.21
Hello all (are we getting tired of me posting yet?),
This is a long post, but it requires some background:
Although I'm only capable of testing this on the Raspberry Pi for now, I can't
duplicate this problem on Linux on the Pi. Therefore, I'll write to the mailing
list for now to get some ad
-Original Message-
From: Iain Hibbert
Sent: Saturday, July 19, 2014 1:33 PM
To: William D. Jones
Cc: current-users@netbsd.org
Subject: Re: Building PCC for "tools" is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
it certainly is. I think I remember that __USE(
christos@ wrote:
> In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
> Izumi Tsutsui wrote:
> >> On behalf of the release engineering team, I am happy to announce that
> >> the release process for NetBSD 7.0 is now underway.
> >
> >Does anyone (core? releng?) has a particular plan abou
On Saturday, July 19, 2014 at 7:11 PM, "Iain Hibbert" wrote:
> Is this with LOCKDEBUG and no other changes, or with LOCKDEBUG and
> the addition of the MPSAFE flag?
Both, D_MPSAFE was an attempt to walk-around the first mentioned
panic, but we ran into another (mentioned) issue with spin lock he
On Wed, 16 Jul 2014, William D. Jones wrote:
> I'm afraid that I am cross-compiling from a Linux system, and as to not
> contaminate my source tree, I wanted to create a "tools" version of PCC that
> can be used to compile the rest of the tree. However, if your source tree does
> not have __USE (
On Sat, 19 Jul 2014, Kamil Rytarowski wrote:
> plunky @ NetBSD the original commiter (and author?)
yes I wrote this originally
> Unfortunatelly, I've got issues with the driver with LOCKDEBUG turned on
> (expensive locking checks/support), and these issues result in kernel
> panics.
Is this wit
In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>> On behalf of the release engineering team, I am happy to announce that
>> the release process for NetBSD 7.0 is now underway.
>
>Does anyone (core? releng?) has a particular plan about
>the default MACHINE_ARCH fo
> On behalf of the release engineering team, I am happy to announce that
> the release process for NetBSD 7.0 is now underway.
Does anyone (core? releng?) has a particular plan about
the default MACHINE_ARCH for each arm ports?
---
Izumi Tsutsui
My Ivy Bridge integrated GPU, sources from today, but still no banana. :(
1. X got resolution 1024x768 on 1280x1024 screen
2. glxgears causes crash:
Jul 19 12:54:07 dodo aniou: glxgears start
Jul 19 12:55:08 dodo syslogd[147]: restart
Jul 19 12:55:08 dodo /netbsd: drm: stuck on render ring
Jul 19
Hello,
plunky @ NetBSD the original commiter (and author?)
skrll @ NetBSD a developer who took a bug related to the same driver uhso(4) [1]
Grzegorz Bernacki gber @ FreeBSD who had a look at kernel panics
current-users @ NetBSD
uhso(4) is a kernel driver for Option modems. It utilizes inter ali
12 matches
Mail list logo
