On Mon, 16 Dec 2013, Jukka Ruohonen wrote:
On Sun, Dec 15, 2013 at 11:00:43AM -0800, Paul Goyette wrote:
static void
sysctl_module_setup(void)
{
@@ -433,10 +456,16 @@ sysctl_module_setup(void)
CTL_CREATE, CTL_EOL);
sysctl_createv(&module_sysctllog, 0, &node, NULL,
On Sun, Dec 15, 2013 at 11:00:43AM -0800, Paul Goyette wrote:
> static void
> sysctl_module_setup(void)
> {
> @@ -433,10 +456,16 @@ sysctl_module_setup(void)
> CTL_CREATE, CTL_EOL);
> sysctl_createv(&module_sysctllog, 0, &node, NULL,
> CTLFLAG_PERMANENT | CTLFLA
Updating src tree:
P src/compat/arm/oabi/bsd.oabi.mk
P src/crypto/external/bsd/openssh/dist/servconf.c
P src/dist/smbfs/lib/smb/nb_name.c
P src/external/historical/nawk/dist/run.c
P src/share/man/man7/sysctl.7
P src/share/mk/bsd.own.mk
P src/sys/arch/acorn26/stand/Makefile.buildboot
P src/sys/arch
> I ported the changes in FreeBSD SVN r257305 that add support for
> RTL8168G. This works except for the RX path. When I netboot; an
> unpatched NetBSD re(4) works for TX and RX. Any ideas?
> Jonathan Kollasch
I have an on-motherboard (MSI Z77 MPOWER) Ethernet, Realtek 8111E or RTL8168
Matt Sporleder asks:
> What is your build.sh command?
> Did the build ever work?
Latest build.sh command was
===> build.sh command:./build.sh -m amd64 -M ../obj.amd64.llvm -B
nb20131214-llvm -T ../tooldir.amd64.llvm -V MKLLVM=yes -V HAVE_LLVM=yes -V
MKLIBCXX=yes -U -j 9 distribution kern
On Sun, Dec 15, 2013 at 11:17:00AM -0600, Jonathan A. Kollasch wrote:
> On Sun, Dec 15, 2013 at 09:57:59AM -0600, Jonathan A. Kollasch wrote:
> >
> > I ported the changes in FreeBSD SVN r257305 that add support for
> > RTL8168G. This works except for the RX path. When I netboot; an
> > unpatched
Now that evbmips64-el builds again for LOONGSON processors, I set about
doing just that.
The result is that all userland programs die with SIGSEGV, usually upon
exit (they otherwise seem to work OK).
Examining results with 'gdb' produces similar results in all examples
observed:
[...]
Core was
On Dec 15, 12:37pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: module auto-unload
| Yes, this check could be simply == instead of <=
Like it is just below
christos
On Sun, 15 Dec 2013, Christos Zoulas wrote:
+ if (t < 0)
+ return (EINVAL);
You are not allowing it to become negative.
* Automatically unload modules. We try once to unload autoloaded
* modules after module_autotime seconds. If the system is under
- * s
In article ,
Paul Goyette wrote:
>-=-=-=-=-=-
>
>On Sun, 15 Dec 2013, Paul Goyette wrote:
>
>> Given the recent discussion on the usefulness of auto-unload, would it
>> possibly make sense to enable/disable this via a new sysctl variable?
>>
>> We could make kern.module.unload_delay default to 1
On Sun, 15 Dec 2013, Paul Goyette wrote:
On Sun, 15 Dec 2013, Paul Goyette wrote:
Given the recent discussion on the usefulness of auto-unload, would it
possibly make sense to enable/disable this via a new sysctl variable?
We could make kern.module.unload_delay default to 10 seconds (the cur
On Sun, 15 Dec 2013, Paul Goyette wrote:
Given the recent discussion on the usefulness of auto-unload, would it
possibly make sense to enable/disable this via a new sysctl variable?
We could make kern.module.unload_delay default to 10 seconds (the current
default); if the delay is ever set t
On Sun, Dec 15, 2013 at 09:57:59AM -0600, Jonathan A. Kollasch wrote:
>
> I ported the changes in FreeBSD SVN r257305 that add support for
> RTL8168G. This works except for the RX path. When I netboot; an
> unpatched NetBSD re(4) works for TX and RX. Any ideas?
>
> Jonathan Kollasch
For
I ported the changes in FreeBSD SVN r257305 that add support for
RTL8168G. This works except for the RX path. When I netboot; an
unpatched NetBSD re(4) works for TX and RX. Any ideas?
Jonathan Kollasch
Given the recent discussion on the usefulness of auto-unload, would it
possibly make sense to enable/disable this via a new sysctl variable?
We could make kern.module.unload_delay default to 10 seconds (the
current default); if the delay is ever set to a non-positive value, it
would disable t
Recently, I've been noticing these messages during system startup (and
possibly during shutdown). They may have been around for a while, but
I've noticed them.
# dmesg | grep ahcisata1
ahcisata1 at jmide0
ahcisata1: AHCI revision 1.0, 2 ports, 32 slots, CAP
0xc7
On Dec 15, 2013, at 6:34 AM, "Thomas Mueller" wrote:
>>> This is in particular a sudden inability to build NetBSD-current from
>>> source.
>
>> Those happen, and are usually fixed by reading UPDATING and doing what it
>> recommends (or in the case of obvious breaks, waiting a day, updating
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 2013.12.15.11.06.57.
An extract from the build.sh output follows:
# compile XEN3PAE_DOMU/linux_ipc.o
/tmp/bra
> >This is in particular a sudden inability to build NetBSD-current from source.
> Those happen, and are usually fixed by reading UPDATING and doing what it
> recommends (or in the case of obvious breaks, waiting a day, updating and
> running the build again).
> -current is built by umpte
Hi,
mueller6...@bellsouth.net ("Thomas Mueller") writes:
>from Paul Goyette:
>> I've had intermittent similar problems with NetBSD for at least three
>> years now. I have no idea what the problem is, though. I've
>> suspected some sort of memory corruption, but was never able to make
>> any pr
On Sun, Dec 15, 2013 at 07:54:55AM +, Thomas Mueller wrote:
> I look at the build.sh command line in the build logs on
> http://releng.netbsd.org/cgi-bin/builds.cgi
>
> and at least for HEAD and netbsd-6, one parameter is
> USE_PIGZGZIP=yes
>
> What is this, and would it make a build
21 matches
Mail list logo
