> On Oct 8, 2021, at 4:49 AM, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>
> Hi
>
> Am 04.10.21 um 16:11 schrieb Chuck Lever III:
>>> On Oct 4, 2021, at 10:07 AM, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>>>
>>> Hi
>>>
>>> Am 04.10.21 um 15:34 schrieb Chuck Lever III:
>>>>> On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>>>>>
>>>>> (cc: ainux.wang@xxxxxxxxx)
>>>>>
>>>>> Hi
>>>>>
>>>>> Am 03.10.21 um 20:09 schrieb Chuck Lever III:
>>>>>> Hi-
>>>>>> After updating one of my test systems to v5.15-rc, I found that it
>>>>>> becomes unresponsive during the later part of the boot process. A
>>>>>> power-on reset is necessary to recover.
>>>>>> I bisected to this commit:
>>>>>> 572994bf18ff ("drm/ast: Zero is missing in detect function")
>>>>>
>>>>> You don't have a monitor connected, I guess?
>>>> Correct, my lab systems use IPMI and a browser-attached console.
>>>>> In that case, we now trigger the helpers that poll for connected monitors. However, the overhead seems rather extreme.
>>>>>
>>>>> I'll have to try to reproduce this, or otherwise we can revert the commit.
>>>> It's strange, only that system in my lab seems to have a problem.
>>>> The others work fine.
>>>> Thanks for having a look!
>>>
>>> Is it a HW or FW problem? Maybe a different revision?
>> It's possible. I don't know how to further diagnose the issue,
>> though. Any guidance appreciated!
>
> v5.15-rc3 works well on my test machine.
>
> For getting the firmware revisions, run
>
> sudo dmidecode
>
> on the machine. It will print a long list of devices with related information. Running
>
> sudo lspci -v
>
> will give information about the PCI devices. There's an entry for the VGA device somewhere. Maybe you can find some difference between the different systems
>
> If you think the machine got stuck, try to plug-in the VGA cable during the boot and see if it makes the machine come up.
Yes, plugging in a physical monitor unsticks the machine and booting
continues normally.
However, after that, having a monitor present does not seem to be
necessary. The machine has been rebooted several times with
v5.15-rc5 and no monitor attached, without any delays.
I'll note this is Fedora 32, in case you suspect there is a user
space interaction involved. The system is going to be updated very
soon to a more recent release of Fedora.
> Best regards
> Thomas
>
>>> I'm asking because the problematic commit does the correct thing. If there is no VGA cable connected, the driver should poll until it detects one. The overhead should be minimal.
>>>
>>> But I'll try to reproduce anyway.
>>>
>>> Best regards
>>> Thomas
>>>
>>>>> Best regards
>>>>> Thomas
>>>>>
>>>>>> Checking out v5.15-rc3 and reverting this commit enables the system
>>>>>> to boot again.
>>>>>> 0b:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 30) (prog-if 00 [VGA controller])
>>>>>> DeviceName: ASPEED Video AST2400
>>>>>> Subsystem: Super Micro Computer Inc X10SRL-F
>>>>>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>> Interrupt: pin A routed to IRQ 18
>>>>>> Region 0: Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
>>>>>> Region 1: Memory at fb000000 (32-bit, non-prefetchable) [size=128K]
>>>>>> Region 2: I/O ports at c000 [size=128]
>>>>>> Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
>>>>>> Capabilities: [40] Power Management version 3
>>>>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
>>>>>> Address: 0000000000000000 Data: 0000
>>>>>> Kernel driver in use: ast
>>>>>> Kernel modules: ast
>>>>>> --
>>>>>> Chuck Lever
>>>>>
>>>>> --
>>>>> Thomas Zimmermann
>>>>> Graphics Driver Developer
>>>>> SUSE Software Solutions Germany GmbH
>>>>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>>>>> (HRB 36809, AG Nürnberg)
>>>>> Geschäftsführer: Felix Imendörffer
>>>> --
>>>> Chuck Lever
>>>
>>> --
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> (HRB 36809, AG Nürnberg)
>>> Geschäftsführer: Felix Imendörffer
>> --
>> Chuck Lever
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Chuck Lever
