Le 10/07/2018 à 11:01, Martin Husemann a écrit :
On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote:
I have no scientific data yet, but just noticed that build times on the
auto build cluster did rise very dramatically since it has been updated
to run NetBSD 8.0 RC2.
Since builds
On 10.07.2018 11:01, Martin Husemann wrote:
> On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote:
>> I have no scientific data yet, but just noticed that build times on the
>> auto build cluster did rise very dramatically since it has been updated
>> to run NetBSD 8.0 RC2.
>>
>> Since
On Tue, Jul 10, 2018 at 12:11:41PM +0200, Kamil Rytarowski wrote:
> After the switch from NetBSD-HEAD (version from 1 year ago) to 8.0RC2,
> the ld(1) linker has serious issues with linking Clang/LLVM single
> libraries within 20 minutes. This causes frequent timeouts on the NetBSD
> buildbot in
On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote:
> I have no scientific data yet, but just noticed that build times on the
> auto build cluster did rise very dramatically since it has been updated
> to run NetBSD 8.0 RC2.
>
> Since builds move around build slaves sometimes (not
On 08.07.2018 17:44, Kamil Rytarowski wrote:
> I will try to scratch a new header unaligned.h with the set of macros
> and submit it to evaluation.
I've prepared a scratch of unaligned.h with get_unaligned():
http://netbsd.org/~kamil/kubsan/unaligned.h
There are at least two problems to
So the machine where ipnat's ftp proxy misbehaved just paniced:
uvm_fault(0x8076d460, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip 8045102e cs 8 rflags 10212 cr2 8 cpl 0 rsp
fe812a095a90
kernel: page fault trap, code=0
Stopped in pid 27044.1 (perl)
> So the machine [...] just paniced:
It's running 6.1/amd64.
> Since it's a development server, I let it sit in DDB in case someone wants me
> to examine something.
I tried to dump (reboot 104), but that froze, so I had to press The Button,
so above no longer holds, sorry.
Hi,
The code in sys/dev/pci/n8 has bitrotted - it still makes references to
LKM_ system things, so it is unlikely it builds.
This has been the case since netbsd-6.
I am interested in removing this because while playing with a
text-processing tool to look for bugs, I came across this and spent
I asked
> Is there any way to have the console (more precisely: the thing where panic
> messages go and where DDB operates on) both on VGA/Physical Keyboard (for
> on-site access) and something like IPMI SOL (for off-site access)?
How does DDB select the device it communicates on?
On Mon, Jul 02, 2018 at 12:18:51PM +, co...@sdf.org wrote:
> Hi folks,
>
> we have two ports of linux drm code. old drm, which exists because not
> all devices/drivers work with the newer, also non-x86 architectures use
> this.
>
> new drm ("drm2") which hopefully we'll transition to.
>
>
On Tue, Jul 10, 2018 at 06:56:53PM +, co...@sdf.org wrote:
> Hi,
>
> The code in sys/dev/pci/n8 has bitrotted - it still makes references to
> LKM_ system things, so it is unlikely it builds.
> This has been the case since netbsd-6.
I still have the hardware, but I seriously doubt anyone's
Thanks for confirming! :-)
I'll still hold my original promise of waiting a month to do so.
Le 10/07/2018 à 16:44, Edgar Fuß a écrit :
So the machine [...] just paniced:
It's running 6.1/amd64.
You are using NetBSD 6 and IPF; that's about the least bug-free configuration
I can think of. Really, you should switch to NetBSD 8 - even if IPF is not
maintained at least the rest of the
14 matches
Mail list logo
