On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton
<jlinton(a)redhat.com> wrote:
> On 05/12/2016 02:59 PM, Peter Robinson wrote:
>>>>>
>>>>> The ARM Juno development platform's PCIe is supported
>>>>> by the generic PCI host driver. Enable it so that PCIe
>>>>> attached peripherals work.
>>>>
>>>>
>>>>
>>>> Pushed as (F-24 and rawhide)
>>>>
>>>>
>>>>
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=d...
>>>>
>>>> Let me know if there's other branches you'd like it on, also let
me
>>>> know if there's other improvements that can be made for Juno,
we've
>>>> not had anyone to test so what we have is a bit of a guess so any
>>>> feedback for Juno support would be useful.
>>>
>>>
>>>
>>> Thanks those two branches should be sufficient. I have a few other tweaks
>>> to
>>> post now that I seem to have cleared some internal hurtles.
>>
>>
>> Excellent, really glad to get confirmation it's looking reasonable.
>>
>>> FYI: There is a dmi_match oops on boot, and the SMSC's phy state change
>>> isn't consistently detected, resulting in unreliable link detection.
>>> Plus,
>>> there is likely a grub EFI issue (there are a couple bugs floating around
>>> about that).
>>
>>
>> 1) dmi_match oops we've seen for a long time, it doesn't seem to cause
>> issues but I think it's because most devices don't actually have dmi
>> tables (or what ever they're called) so should likely be taught to
>> behave on absence
>
>
> This machine has DMI tables, the problem is that the fedora specific
> watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to
> dmi_check_system before the smbios initcall has set up the tables (AFAIK).
When is that initcall done on your platform? lockup_detector_init is
called in a kthread started by the rest_init function. All of that is
called after acpi_subsystem_init, sfi_init_late, efi_late_init, and
efi_free_boot_services.
Also, the dmi code protects itself behind the dmi_initialized
variable, so if dmi_check_system is called before dmi_scan_machine is
called then nothing bad should happen. On x86, dmi_scan_machine is
called from setup_arch, which is well before any of the above
functions are called.
Its the WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized
yet.\n"); in dmi_matches that is firing.
That is because, arm64_dmi_init is a core_initcall() and ends up being
called after the watchdog/SMP setup, same on IA64 the only other
platform with a dmi_scan_machine() call. A large part of this is because
it should run after arm_enable_runtime_services, which is an
early_initcall itself.
I moved the arm64_dmi_init() call into arm_enable_runtime_services() and
removed the core_initcall(arm64_dmi_init) and that solves the problem.
Of course that will likely cause a build failure on 32-bit ARM without
some kind of stubbed out call.