If you did that it would change the KPI a bit meaning lots
of thrashing in the code.
And on top of that you now would no longer return 0..
You would get 1 it was restarted or -1 it was not running but is now started.
Makes no sense to me sorry..
R
On Dec 10, 2015, at 7:35 AM, Hans Petter Selask
For callout_stop/drain you get
-1 == Callout as already gone off or is not running (usually the latter) else
the caller iks
not using locking properly or did not lock and check the active()
value (which would have returned not active so no stop
would have been needed);
0 == w
Hans:
Though it would not hurt to add your patch, its not possible
for callout_reset() to return anything but 1 or 0.
Only callout_stop(), callout_drain(), callout_async_drain() can return -1.
So I don’t think that this will fix it.
R
On Dec 4, 2015, at 11:34 AM, Hans Petter Selasky wrote:
>>
On 12/10/15 16:35, Randall Stewart wrote:
If you did that it would change the KPI a bit meaning lots
of thrashing in the code.
Hi,
There are only 5 consumers of the callout_reset() return code in the
FreeBSD 11-current kernel from what I can see:
grep -r "= callout_reset" sys/ | wc -l
On 12/10/15 16:25, Randall Stewart wrote:
For callout_stop/drain you get
-1 == Callout as already gone off or is not running (usually the latter) else
the caller iks
not using locking properly or did not lock and check the active()
value (which would have returned not active so no s
Hi,
Here is the backtrace for a reproducable panic seen with arptimer():
#0 doadump (textdump=0) at pcpu.h:221
#1 0x80385afb in db_dump (dummy=, dummy2=false,
dummy3=0, dummy4=0x0) at /usr/img/freebsd/sys/ddb/db_command.c:533
#2 0x803858ee in db_command (cmd_table=0x0) at
/
On 12/04/15 20:34, Hans Petter Selasky wrote:
Hi Adrian,
On 10/31/15 16:01, Alexander V. Chernikov wrote:
31.10.2015, 16:46, "Adrian Chadd" :
On 31 October 2015 at 09:34, Alexander V. Chernikov
wrote:
31.10.2015, 05:32, "Adrian Chadd" :
Hiya,
Here's a panic from arptimer:
Hi Adr
Hi Adrian,
On 10/31/15 16:01, Alexander V. Chernikov wrote:
31.10.2015, 16:46, "Adrian Chadd" :
On 31 October 2015 at 09:34, Alexander V. Chernikov
wrote:
31.10.2015, 05:32, "Adrian Chadd" :
Hiya,
Here's a panic from arptimer:
Hi Adrian,
As far as I see, line 205 in if_ether.c
31.10.2015, 16:46, "Adrian Chadd" :
> On 31 October 2015 at 09:34, Alexander V. Chernikov
> wrote:
>> 31.10.2015, 05:32, "Adrian Chadd" :
>>> Hiya,
>>>
>>> Here's a panic from arptimer:
>> Hi Adrian,
>>
>> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which
>> happens afte
On 31 October 2015 at 09:34, Alexander V. Chernikov
wrote:
>
>
> 31.10.2015, 05:32, "Adrian Chadd" :
>> Hiya,
>>
>> Here's a panic from arptimer:
> Hi Adrian,
>
> As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens
> after LLE_WUNLOCK().
> So, it looks like (pre-cached) i
31.10.2015, 05:32, "Adrian Chadd" :
> Hiya,
>
> Here's a panic from arptimer:
Hi Adrian,
As far as I see, line 205 in if_ether.c is IF_AFDATA_LOCK(ifp) which happens
after LLE_WUNLOCK().
So, it looks like (pre-cached) ifp had been freed before locking ifdata.
Do you have any more details on tha
Hiya,
Here's a panic from arptimer:
(kgdb) bt
#0 doadump (textdump=0) at pcpu.h:221
#1 0x803666b6 in db_fncall (dummy1=,
dummy2=, dummy3=,
dummy4=) at
/usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568
#2 0x8036614e in db_command (cmd_table=0x0) at
/usr/home/adrian
12 matches
Mail list logo
