Date:   Sun, 10 Oct 2021 19:42:00 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Thomas Zimmermann <tzimmermann@...e.de>
CC:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ainux Wang <ainux.wang@...il.com>
Subject: Re: 572994bf18ff prevents system boot



> On Oct 8, 2021, at 4:49 AM, Thomas Zimmermann <tzimmermann@...e.de> wrote:
> 
> Hi
> 
> Am 04.10.21 um 16:11 schrieb Chuck Lever III:
>>> On Oct 4, 2021, at 10:07 AM, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>>> 
>>> Hi
>>> 
>>> Am 04.10.21 um 15:34 schrieb Chuck Lever III:
>>>>> On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>>>>> 
>>>>> (cc: ainux.wang@...il.com)
>>>>> 
>>>>> 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

Fwiw, here's a working system:

DMI: Supermicro X10SRA-F/X10SRA-F, BIOS 2.0b 06/12/2017

Handle 0x0054, DMI type 41, 11 bytes
Onboard Device
        Reference Designation:  Aspeed Video AST2400
        Type: Video
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:08:00.0

08: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 Device 0857


The system that hangs reports:

DMI: Supermicro Super Server/X10SRL-F, BIOS 3.3 10/28/2020

Handle 0x0027, DMI type 41, 11 bytes
Onboard Device
        Reference Designation:  ASPEED Video AST2400
        Type: Video
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:0b:00.0

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


> 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.

I will try to make time to give this a shot.


> 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

Powered by blists - more mailing lists