Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'

From: Michael Butler <imb_at_protected-networks.net>
Date: Mon, 17 Sep 2018 14:32:09 -0400
On 9/10/18 1:20 PM, John Baldwin wrote:
> On 9/8/18 1:44 PM, Michael Butler wrote:
>> On 9/8/18 3:43 PM, Konstantin Belousov wrote:
>>> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote:
>>>> On 8/31/18 1:28 AM, Konstantin Belousov wrote:
>>>>> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote:
>>>>
>>>>  [ .. snip .. ]
>>>>
>>>>>> I see another problem after using Ian's workaround of moving the #ifdef
>>>>>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III)
>>>>>> machine with only 512MB of RAM:
>>>>>>
>>>>>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed
>>>>>
>>>>> What is the kernel revision for "now".  What was the previous revision
>>>>> where the kstack allocation failures did not happen.
>>>>>
>>>>> Also, what is the workload ?
>>>>
>>>> Sorry for the delay. Any version at or after SVN r338360 would either a)
>>>> not boot at all or b) crash shortly after boot with a swarm of messages
>>>> as above. It was stable before that.
>>>>
>>>> Unfortunately, this machine is remote and, being as old as it is, has no
>>>> remote console facility. 'nextboot' has been my savior ;-)
>>>>
>>>> It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces,
>>>> local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an
>>>> OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a
>>>> router/firewall with few actual applications running.
>>>>
>>>> As another data point, I manually reversed both SVN r338360 and r338415
>>>> (a related change) and it is now stable running at SVN r338520,
>>>
>>> It is very unprobable.  I do not see how could r338360 affect KVA allocation.
>>> Double-check that you booted right kernels.
>>>
>>
>> FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14
>> r338520M: Thu Sep  6 21:35:31 EDT 2018
>>
>> 'svn diff' reports the only changes being the two reversals I noted above,
> 
> Can you get the output of 'x num_io_irqs' at the DDB prompt after the
> panic?
> 

SVN r338725 fixed this - thanks! :-)

	imb
Received on Mon Sep 17 2018 - 16:32:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC