pci=no_e820 report for vmware fusion

pci=no_e820 report for vmware fusion

[Benjamin Coddington]

My VMWare Fusion linux VM's display stopped working after an update, 
with:

[.558514] vmwgfx 0000:00:0f.0: vgaarb: deactivate vga console
[.559964] Console: switching to colour dummy device 80x25
[.583703] vmwgfx 0000:00:0f.0: [drm] FIFO at 0x00000000c0000000 size is 
8192 kiB
[.583783] vmwgfx 0000:00:0f.0: [drm] VRAM at 0x00000000e8000000 size is 
131072 kiB
[.583845] vmwgfx 0000:00:0f.0: [drm] Running on SVGA version 2.
[.583863] vmwgfx 0000:00:0f.0: [drm] Capabilities: rect copy, cursor, 
cursor bypass, cursor bypass 2, 8bit emulation, alpha cursor, extended 
fifo, multimon, pitchlock, irq mask, display topology, gmr, traces, 
gmr2, screen object 2, command buffers, command buffers 2, gbobject, dx,
[.583865] vmwgfx 0000:00:0f.0: [drm] DMA map mode: Caching DMA mappings.
[.584003] vmwgfx 0000:00:0f.0: [drm] Legacy memory limits: VRAM = 4096 
kB, FIFO = 256 kB, surface = 0 kB
[.584006] vmwgfx 0000:00:0f.0: [drm] MOB limits: max mob size = 131072 
kB, max mob pages = 98304
[.584008] vmwgfx 0000:00:0f.0: [drm] Max GMR ids is 64
[.584009] vmwgfx 0000:00:0f.0: [drm] Max number of GMR pages is 65536
[.584010] vmwgfx 0000:00:0f.0: [drm] Maximum display memory size is 
131072 kiB
[.619664] vmwgfx 0000:00:0f.0: [drm] Screen Target display unit 
initialized
[.638401] vmwgfx 0000:00:0f.0: [drm] Fifo max 0xffffffff min 0xffffffff 
cap 0xffffffff
[.638406] vmwgfx 0000:00:0f.0: [drm] FIFO memory is not usable. Driver 
failed to initialize.
[.638407] [drm:vmw_request_device [vmwgfx]] *ERROR* Unable to initialize 
the device.

(There's also quite a lot of pci badness entries before this, left out
for brevity).

I bisected the issue to:
4c5e242d3e93 x86/PCI: Clip only host bridge windows for E820 regions

and to confirm that was the problem I attempted a revert of that commit 
on
v5.19-rc1.  The revert had a conflict which pointed me to this commit:
fa6dae5d8208 x86/PCI: Add kernel cmdline options to use/ignore E820 
reserved regions

So - I've added "pci=no_e820" to my kernel parameters, which allows 
vmwgfx
to work properly again, and I'm reporting it here as requested in the 
commit
adding that parameter.

I'm happy to provide more information if needed, or test.

Ben

Re: pci=no_e820 report for vmware fusion

[Hans de Goede]

Hi,

On 6/16/22 14:12, Benjamin Coddington wrote:
> My VMWare Fusion linux VM's display stopped working after an update, with:
> 
> [.558514] vmwgfx 0000:00:0f.0: vgaarb: deactivate vga console
> [.559964] Console: switching to colour dummy device 80x25
> [.583703] vmwgfx 0000:00:0f.0: [drm] FIFO at 0x00000000c0000000 size is 8192 kiB
> [.583783] vmwgfx 0000:00:0f.0: [drm] VRAM at 0x00000000e8000000 size is 131072 kiB
> [.583845] vmwgfx 0000:00:0f.0: [drm] Running on SVGA version 2.
> [.583863] vmwgfx 0000:00:0f.0: [drm] Capabilities: rect copy, cursor, cursor bypass, cursor bypass 2, 8bit emulation, alpha cursor, extended fifo, multimon, pitchlock, irq mask, display topology, gmr, traces, gmr2, screen object 2, command buffers, command buffers 2, gbobject, dx,
> [.583865] vmwgfx 0000:00:0f.0: [drm] DMA map mode: Caching DMA mappings.
> [.584003] vmwgfx 0000:00:0f.0: [drm] Legacy memory limits: VRAM = 4096 kB, FIFO = 256 kB, surface = 0 kB
> [.584006] vmwgfx 0000:00:0f.0: [drm] MOB limits: max mob size = 131072 kB, max mob pages = 98304
> [.584008] vmwgfx 0000:00:0f.0: [drm] Max GMR ids is 64
> [.584009] vmwgfx 0000:00:0f.0: [drm] Max number of GMR pages is 65536
> [.584010] vmwgfx 0000:00:0f.0: [drm] Maximum display memory size is 131072 kiB
> [.619664] vmwgfx 0000:00:0f.0: [drm] Screen Target display unit initialized
> [.638401] vmwgfx 0000:00:0f.0: [drm] Fifo max 0xffffffff min 0xffffffff cap 0xffffffff
> [.638406] vmwgfx 0000:00:0f.0: [drm] FIFO memory is not usable. Driver failed to initialize.
> [.638407] [drm:vmw_request_device [vmwgfx]] *ERROR* Unable to initialize the device.
> 
> (There's also quite a lot of pci badness entries before this, left out
> for brevity).
> 
> I bisected the issue to:
> 4c5e242d3e93 x86/PCI: Clip only host bridge windows for E820 regions
> 
> and to confirm that was the problem I attempted a revert of that commit on
> v5.19-rc1.  The revert had a conflict which pointed me to this commit:
> fa6dae5d8208 x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regions
> 
> So - I've added "pci=no_e820" to my kernel parameters, which allows vmwgfx
> to work properly again, and I'm reporting it here as requested in the commit
> adding that parameter.
> 
> I'm happy to provide more information if needed, or test.

Commit 4c5e242d3e93 breaking things is a known issue and a rever for this is pending:

https://lore.kernel.org/linux-pci/20220612144325.85366-1-hdegoede@redhat.com/

Regards,

Hans

Re: pci=no_e820 report for vmware fusion

[Bjorn Helgaas]

On Thu, Jun 16, 2022 at 08:12:28AM -0400, Benjamin Coddington wrote:
> My VMWare Fusion linux VM's display stopped working after an update, with:
> 
> [.558514] vmwgfx 0000:00:0f.0: vgaarb: deactivate vga console
> [.559964] Console: switching to colour dummy device 80x25
> [.583703] vmwgfx 0000:00:0f.0: [drm] FIFO at 0x00000000c0000000 size is 8192
> kiB
> [.583783] vmwgfx 0000:00:0f.0: [drm] VRAM at 0x00000000e8000000 size is
> 131072 kiB
> [.583845] vmwgfx 0000:00:0f.0: [drm] Running on SVGA version 2.
> [.583863] vmwgfx 0000:00:0f.0: [drm] Capabilities: rect copy, cursor, cursor
> bypass, cursor bypass 2, 8bit emulation, alpha cursor, extended fifo,
> multimon, pitchlock, irq mask, display topology, gmr, traces, gmr2, screen
> object 2, command buffers, command buffers 2, gbobject, dx,
> [.583865] vmwgfx 0000:00:0f.0: [drm] DMA map mode: Caching DMA mappings.
> [.584003] vmwgfx 0000:00:0f.0: [drm] Legacy memory limits: VRAM = 4096 kB,
> FIFO = 256 kB, surface = 0 kB
> [.584006] vmwgfx 0000:00:0f.0: [drm] MOB limits: max mob size = 131072 kB,
> max mob pages = 98304
> [.584008] vmwgfx 0000:00:0f.0: [drm] Max GMR ids is 64
> [.584009] vmwgfx 0000:00:0f.0: [drm] Max number of GMR pages is 65536
> [.584010] vmwgfx 0000:00:0f.0: [drm] Maximum display memory size is 131072
> kiB
> [.619664] vmwgfx 0000:00:0f.0: [drm] Screen Target display unit initialized
> [.638401] vmwgfx 0000:00:0f.0: [drm] Fifo max 0xffffffff min 0xffffffff cap
> 0xffffffff
> [.638406] vmwgfx 0000:00:0f.0: [drm] FIFO memory is not usable. Driver
> failed to initialize.
> [.638407] [drm:vmw_request_device [vmwgfx]] *ERROR* Unable to initialize the
> device.
> 
> (There's also quite a lot of pci badness entries before this, left out
> for brevity).

The badness would definitely be interesting (the entire dmesg log), as
well as a dmesg log collected with "pci=no_e820".  I'll attach them to
this bugzilla [1].

Generally I expect PCI devices to work even if we reassign their BARs
before a driver claims them.  But apparently some do not, and I'm
always curious about which ones they are.

If you could confirm that Hans' revert [2] avoids the problem without
needing "pci=no_e820", that would be awesome, too.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=216109
[2] https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=dd104bcc2cf233234f82bfc4bd5b8ab32cdbf117

> I bisected the issue to:
> 4c5e242d3e93 x86/PCI: Clip only host bridge windows for E820 regions
> 
> and to confirm that was the problem I attempted a revert of that commit on
> v5.19-rc1.  The revert had a conflict which pointed me to this commit:
> fa6dae5d8208 x86/PCI: Add kernel cmdline options to use/ignore E820 reserved
> regions
> 
> So - I've added "pci=no_e820" to my kernel parameters, which allows vmwgfx
> to work properly again, and I'm reporting it here as requested in the commit
> adding that parameter.
> 
> I'm happy to provide more information if needed, or test.
> 
> Ben
> 

Re: pci=no_e820 report for vmware fusion

[Benjamin Coddington]

On 16 Jun 2022, at 16:40, Bjorn Helgaas wrote:

> The badness would definitely be interesting (the entire dmesg log), as

Here it is:
https://bcodding.com/d/dmesg_pci_badness.txt

> well as a dmesg log collected with "pci=no_e820".  I'll attach them to
> this bugzilla [1].

https://bcodding.com/d/dmesg_pci_no_e820_param.txt

> Generally I expect PCI devices to work even if we reassign their BARs
> before a driver claims them.  But apparently some do not, and I'm
> always curious about which ones they are.
>
> If you could confirm that Hans' revert [2] avoids the problem without
> needing "pci=no_e820", that would be awesome, too.

I can confirm that the Hans' revert avoids the problem without having the
kernel param set.  I've only booted it, not done any other PCI testing.

Ben