On 3 December 2013 22:45, David Laight wrote:
> On Tue, Nov 26, 2013 at 01:32:44PM -0500, Mouse wrote:
>>
>> When serving a request takes nontrivial time, and multiple requests can
>> usefully be in progress at once, it is useful - it typically improves
>> performance - to have multiple workers se
Hi
I am still trying to work aroud the spurious reboots I get on netbsd-6/i386
with PAE. It happens on different machines when the load rises, and
-current/i386 is not affected.
Unfortunately using a -current kernel is not an option just right now,
because of kernel bugs. For a reason I have no
Hi Emanuel,
sorry for not being helpful with the other problems, but
Unfortunately using a -current kernel is not an option just right now,
because of kernel bugs. For a reason I have not yet tracked down, dovecot
is broken (IPC between (pop|imap)-login and auth process is screwed), and
sshd r
On Thu, Dec 05, 2013 at 12:13:46PM +0100, Wolfgang Solfrank wrote:
> The problem is a change in the semantics of local domain
> socket addresses.
(...)
> Note that there are even programs within our own
> distribution which trigger core dumps due to this change
> (at least kdump does).
Oh, yes,
> > Run a single nfsd and it all works much better.
>
> On that basis should the NetBSD default be changed from -n 4?
i definitely would object to such a change.
i see slowness from multiple clients when i run nfsd with just
one thread. i've never seen the problem dsl has seen with a
netbsd nf
> The problem is a change in the semantics of local domain
> socket addresses. Previously, they had a fixed size, and the
> path name contained within the address was therefor normally
> '\0'-terminated. Now the address is the common socket address
> part plus the pathname, where the terminating
On Thu, Dec 05, 2013 at 11:20:16PM +1100, matthew green wrote:
> breaking binary compat like this is really unacceptable.
> can someone please file a PR about it. we should not have
> to patch and rebuild apps!
Attached is a patch that seems to solve the problem at mine. Dovecot
works again and k
Emmanuel Dreyfus wrote:
> Hi
>
> I am still trying to work aroud the spurious reboots I get on
> netbsd-6/i386 with PAE. It happens on different machines when the load
> rises, and -current/i386 is not affected.
>
Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is
pretty ex
On Thu, Dec 05, 2013 at 02:12:19PM +, Mindaugas Rasiukevicius wrote:
> Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is
> pretty expensive) options enabled?
It still reboots without a panic.
--
Emmanuel Dreyfus
m...@netbsd.org
Hi,
Attached is a patch that seems to solve the problem at mine. Dovecot
works again and kdump does not dumps core anymore.
Your patch doesn't look right, and is probably incomplete, too.
For one thing, you append the trailing '\0' one byte beyond the
end of the the now extended mbuf.
In add
On Thu, Dec 05, 2013 at 05:25:21PM +0100, Wolfgang Solfrank wrote:
> For one thing, you append the trailing '\0' one byte beyond the
> end of the the now extended mbuf.
Atatched is a second attempt;
>
> In addition, there are other places where the additional byte
> needs to be accounted for, e.g
On Thu, Dec 05, 2013 at 04:10:07PM +, Emmanuel Dreyfus wrote:
> On Thu, Dec 05, 2013 at 02:12:19PM +, Mindaugas Rasiukevicius wrote:
> > Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is
> > pretty expensive) options enabled?
>
> It still reboots without a panic.
But
Emmanuel Dreyfus wrote:
> On Thu, Dec 05, 2013 at 04:10:07PM +, Emmanuel Dreyfus wrote:
> > On Thu, Dec 05, 2013 at 02:12:19PM +, Mindaugas Rasiukevicius wrote:
> > > Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is
> > > pretty expensive) options enabled?
> >
> > It
Hi,
In addition, there are other places where the additional byte
needs to be accounted for, e.g. in makeun() within this file.
Not sure whether there are others.
There is already a +1 in makeun.
*addrlen = nam->m_len + 1;
Yes, that's what I was trying to hint at. Here the m_len
doe
>> The problem is a change in the semantics of local domain socket
>> addresses. Previously, they had a fixed size, and the path name
>> contained within the address was therefor normally '\0'-terminated.
>> Now the address is the common socket address part plus the pathname,
>> where the terminat
On Thu, Dec 05, 2013 at 12:13:26PM -0500, Mouse wrote:
> > we should not have to patch and rebuild apps!
>
> Only buggy apps, apps that already needed patching and rebuilding and
> NetBSD just formerly let get away with their incorrect assumptions.
IMO there is no point to break backward compatib
matthew green wrote:
> breaking binary compat like this is really unacceptable.
> can someone please file a PR about it. we should not have
> to patch and rebuild apps!
I will look at it and propose a patch to have the path nul-terminated.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@n
On Wed, Dec 04, 2013 at 02:09:49PM +0100, Christoph Badura wrote:
> > After updating my -current kernel from 6.99.24 to 6.99.27 so I could
> > commit my ubsec(4) changes I noticed that under 6.99.27 I get between
> > 3 and 8 percent less throughput on accelerated crypto ops.
>
> I was able to
>>> we should not have to patch and rebuild apps!
>> Only buggy apps, apps that already needed patching and rebuilding
>> and NetBSD just formerly let get away with their incorrect
>> assumptions.
> IMO there is no point to break backward compatibility just for the
> sake of correctness.
That's an
Hi,
That's an argument for doing this for COMPAT_* code. It's not an
argument for doing it for non-compat programs. Indeed, I think it's
actually better to break code depending on such incorrect assumptions,
beacuse it makes it easier to find (and then fix) them.
While in principle I agree w
> To the best of my knowledge, it was long unspecified whether the
> terminating '\0' was part of the address or not.
Even 1.4T's unix(4) says "the terminating NUL is not part of the
address". It (like the 4.0.1 manpage) even emphasizes the "not". I no
longer have anything older easily available
On Thu, Dec 05, 2013 at 05:57:06PM +0100, Wolfgang Solfrank wrote:
> Yes, that's what I was trying to hint at. Here the m_len
> does include the terminating '\0' byte, so it should be
> something like (untested):
Attached is third version, which seems to work fine at mine
--
Emmanuel Dreyfus
m..
Mindaugas Rasiukevicius wrote:
> Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is
> pretty expensive) options enabled?
After dozens of silent reboots, I had a panic, but I suspect it is
caused by filesystem corruption;
dev = 0x0, block = 1717456, fs = /
panic: blkfree: fre
Dear valued customer,
We regret to inform you that access to your accounts has been
temporarily susspended.
This has been done to avoid a potential threat on your account (©
Australia and New Zealand Banking Threat-sense ).
The access can be restored anytime by donwloading and completing
the
24 matches
Mail list logo
