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

On 9/17/18 11:32 AM, Michael Butler wrote:
> 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! :-)

Hmm, I'm not sure how that fixed this, but glad it is ok now.

-- 
John Baldwin