svn commit: r368523 - head/sys/vm

[Bryan Drewery]

On 12/15/2020 7:04 AM, Mark Johnston wrote:
> On Tue, Dec 15, 2020 at 03:33:09PM +0100, Hans Petter Selasky wrote:
>> On 12/15/20 3:27 PM, Mark Johnston wrote:
>>>> I'm seeing the following panic:
>>>>
>>>> panic("vm_wait in early boot")
>>>> vm_wait_domain()
>>>> kmem_alloc_contig_pages()
>>>> kmem_alloc_contig_domainset()
>>>> kmem_alloc_contig()
>>>> contigmalloc()
>>>> x86bios_alloc()
>>>> vesa_configure()
>>>> vesa_mod_event()
>>>> vesa_module_register_init()
>>>> mi_startup()
>>> Is it on a NUMA system?  I see that the new logic won't work properly if
>>> there are empty domains, so this suggests that we really do need a
>>> special contig iterator as discussed in the review.
>>
>> Yes, this is a numa system.
>>
>> I just noticed, that before r368523 "flags" was updated by 
>> _vm_domainset_iter_policy_init() to always contain M_NOWAIT and that 
>> avoids the wait logic, but I think x86bios_alloc() doesn't get its 
>> memory then.
> 
> Yes, but note that vm_domainset_iter_policy() will also call
> vm_wait_doms() if a M_NOWAIT allocation from each domain fails.
> x86bios_alloc() requests memory from the first 1MB of physical memory,
> but because contigmalloc() uses a round-robin iterator initialized from
> per-thread state it may try from the "wrong" domain first.  So really a
> different solution to the original problem is needed.
> 
>> I'm not sure if x86bios_alloc() needs to be attached a bit later anyway?
>>
>> --HPS

I have reverted the change in r368673 until we come up with a more
comprehensive fix.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201215/41401991/attachment.sig>