Ryota Ozaki writes:
> One possible fix has been committed.
>
> Can you update the source code and try a new kernel?
Will do.
Meanwhile, before I got around to building a kernel with debug options
enabled, I had another hang. Got it into DDB successfully, but then I
managed, while looking for a
On Tue, 26 Dec 2017, Ryota Ozaki wrote:
Well, since the lock _might_ be released (and subsequently reacquired)
by callout_halt(), it might be easiest to modify all the callers to
just unlock it before calling nd6_dad_stoptimer(), and reacquire the
mutex after it returns (as well as re-establishi
On Tue, Dec 26, 2017 at 12:37 PM, Paul Goyette wrote:
> On Tue, 26 Dec 2017, Ryota Ozaki wrote:
>
>> On Tue, Dec 26, 2017 at 11:35 AM, Paul Goyette wrote:
>>>
>>>
To generate a diff of this commit:
>>>
>>>
>>>
>>> # cvs rdiff -u -r1.139 -r1.140 src/sys/netinet6/nd6_nbr.c
>>> @@ -1097,7 +1097
On Tue, 26 Dec 2017, Ryota Ozaki wrote:
On Tue, Dec 26, 2017 at 11:35 AM, Paul Goyette wrote:
To generate a diff of this commit:
# cvs rdiff -u -r1.139 -r1.140 src/sys/netinet6/nd6_nbr.c
@@ -1097,7 +1097,11 @@ nd6_dad_stoptimer(struct dadq *dp)
#ifdef NET_MPSAFE
callout_halt(&dp-
One possible fix has been committed.
Can you update the source code and try a new kernel?
Thanks,
ozaki-r
On Tue, Dec 26, 2017 at 1:00 AM, Ryota Ozaki wrote:
> On Mon, Dec 25, 2017 at 8:31 PM, Tom Ivar Helbekkmo
> wrote:
>> Martin Husemann writes:
>>
>>> The sparc64 hang happened with:
>>>
On Tue, Dec 26, 2017 at 11:35 AM, Paul Goyette wrote:
>
>> To generate a diff of this commit:
>
>
> # cvs rdiff -u -r1.139 -r1.140 src/sys/netinet6/nd6_nbr.c
> @@ -1097,7 +1097,11 @@ nd6_dad_stoptimer(struct dadq *dp)
> #ifdef NET_MPSAFE
> callout_halt(&dp->dad_timer_ch, NULL);
> #else
>
To generate a diff of this commit:
# cvs rdiff -u -r1.139 -r1.140 src/sys/netinet6/nd6_nbr.c
@@ -1097,7 +1097,11 @@ nd6_dad_stoptimer(struct dadq *dp)
#ifdef NET_MPSAFE
callout_halt(&dp->dad_timer_ch, NULL);
#else
- callout_halt(&dp->dad_timer_ch, softnet_lock);
+ /* XXX
On Mon, Dec 25, 2017 at 8:31 PM, Tom Ivar Helbekkmo
wrote:
> Martin Husemann writes:
>
>> The sparc64 hang happened with:
>>
>> $NetBSD: ip_output.c,v 1.288 2017/12/22 11:22:37 ozaki-r Exp $
>
> My amd64 that experienced hangs has:
>
> $NetBSD: ip_output.c,v 1.287 2017/12/15 04:03:46
On Mon, Dec 25, 2017 at 8:16 PM, Martin Husemann wrote:
> On Mon, Dec 25, 2017 at 12:05:28PM +0900, Ryota Ozaki wrote:
>> Anyway I annoy that we often cannot have suspect commits because of cvs
>> (you know the kernel version doesn't work at all for the purpose). I wish
>> we had revision IDs of s
In article <20171225061550.e13a3f...@cvs.netbsd.org>,
Rin Okuyama wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rin
>Date: Mon Dec 25 06:15:50 UTC 2017
>
>Modified Files:
> src/distrib/ews4800mips/floppies/ramdisk: list
>
>Log Message:
>Drop the following features, which
Martin Husemann writes:
> The sparc64 hang happened with:
>
> $NetBSD: ip_output.c,v 1.288 2017/12/22 11:22:37 ozaki-r Exp $
My amd64 that experienced hangs has:
$NetBSD: ip_output.c,v 1.287 2017/12/15 04:03:46 ozaki-r Exp $
...and was last updated from CVS on December 19th, which
On Mon, Dec 25, 2017 at 12:05:28PM +0900, Ryota Ozaki wrote:
> Anyway I annoy that we often cannot have suspect commits because of cvs
> (you know the kernel version doesn't work at all for the purpose). I wish
> we had revision IDs of svn or commit IDs of git to know them.
The sparc64 hang happen
On 25.12.2017 02:21, m...@netbsd.org wrote:
> On Tue, Dec 19, 2017 at 07:40:04PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Dec 19 19:40:04 UTC 2017
>>
>> Modified Files:
>> src/sys/compat/netbsd32: netbsd32_netbsd.c netbsd32_sy
13 matches
Mail list logo
