Re: 32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

Started by Andreas Schwab on Aug 22, 2017 · 3 messages from 2 authors · Last reply Aug 22, 2017

open the first message on its own page

Message details and related content
On Aug 18 2017, Meelis Roos [off-list ref] wrote:
Aug 17 23:53:57 pohl kernel: [ 2940.146546] aty128fb 0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x1111
Aug 17 23:54:02 pohl kernel: [ 2944.804838] aty128fb 0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x1110
I think these messages are harmless and expected.  This device has no
x86 option ROM but a OpenFirmware one.  This is likely unrelated to the
sddm crash.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Message details and related content
quoted
Aug 17 23:53:57 pohl kernel: [ 2940.146546] aty128fb 0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x1111
Aug 17 23:54:02 pohl kernel: [ 2944.804838] aty128fb 0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x1110
I think these messages are harmless and expected.  This device has no
x86 option ROM but a OpenFirmware one.  This is likely unrelated to the
sddm crash.
Yes, but after these crashes have happened for a while, vmalloc 
problems appear.

sddm crash might be related to X server dying under it, or it crashes 
for it own problems (varying signals and addresses beacuse of some 
ASLR?) and causes X server restart that triggers another ROM allocation 
round.

I did read the kernel code and I do not see how the dmesg lines are 
possible without corresponding aty128fb lines about the same ROM 
signature, or why the ROM signature is sometimes 0x1111 and sometimes 
0x1110 instead of x86 ROM signature (that clearly is not there, 
but this is expected).

-- 
Meelis Roos (mroos@linux.ee)
Message details and related content
quoted
I think these messages are harmless and expected.  This device has no
x86 option ROM but a OpenFirmware one.  This is likely unrelated to the
sddm crash.
Yes, but after these crashes have happened for a while, vmalloc 
problems appear.

sddm crash might be related to X server dying under it, or it crashes 
for it own problems (varying signals and addresses beacuse of some 
ASLR?) and causes X server restart that triggers another ROM allocation 
round.
I fount hat there is /proc/vmallocinfo, with contents like this. SO it 
really is lots of pci_map_rom's.

0xf1000000-0xf1002000    8192 _mpic_map_mmio.isra.5+0x20/0x44 phys=0x80041000 ioremap
0xf1002000-0xf1005000   12288 _mpic_map_mmio.isra.5+0x20/0x44 phys=0x80041000 ioremap
0xf1005000-0xf1007000    8192 _mpic_map_mmio.isra.5+0x20/0x44 phys=0x80060000 ioremap
0xf1007000-0xf1009000    8192 _mpic_map_mmio.isra.5+0x20/0x44 phys=0x80050000 ioremap
0xf1009000-0xf100c000   12288 drm_addmap_core+0x584/0x664 [drm] pages=2 vmalloc user
0xf100c000-0xf100e000    8192 bpf_prog_alloc+0x4c/0xd8 pages=1 vmalloc
0xf100e000-0xf1010000    8192 bpf_prog_alloc+0x4c/0xd8 pages=1 vmalloc
0xf1010000-0xf1013000   12288 pmac_i2c_init+0x204/0x4f4 phys=0xf8001000 ioremap
0xf1013000-0xf1015000    8192 pmac_i2c_init+0x204/0x4f4 phys=0x80018000 ioremap
0xf1019000-0xf101b000    8192 devm_ioremap+0x58/0xc8 phys=0x8001f000 ioremap
0xf101c000-0xf1021000   20480 aty128_probe+0xe8/0xac8 phys=0x90000000 ioremap
0xf1021000-0xf1023000    8192 devm_ioremap+0x58/0xc8 phys=0x80008000 ioremap
0xf1023000-0xf1025000    8192 devm_ioremap+0x58/0xc8 phys=0x80020000 ioremap
0xf1025000-0xf1027000    8192 devm_ioremap+0x58/0xc8 phys=0x80008000 ioremap
0xf1027000-0xf102b000   16384 n_tty_open+0x20/0xec pages=3 vmalloc
0xf1030000-0xf1032000    8192 devm_ioremap+0x58/0xc8 phys=0x80021000 ioremap
0xf1032000-0xf1034000    8192 devm_ioremap+0x58/0xc8 phys=0x80008000 ioremap
0xf1034000-0xf1036000    8192 usb_hcd_pci_probe+0x27c/0x45c phys=0x80081000 ioremap
0xf1036000-0xf1038000    8192 usb_hcd_pci_probe+0x27c/0x45c phys=0x80080000 ioremap
0xf1038000-0xf103c000   16384 n_tty_open+0x20/0xec pages=3 vmalloc
0xf103c000-0xf1040000   16384 unpurged vm_area
0xf1040000-0xf1061000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf106b000-0xf1072000   28672 load_module+0x10e8/0x22b0 pages=6 vmalloc
0xf107e000-0xf1080000    8192 bpf_prog_alloc+0x4c/0xd8 pages=1 vmalloc
0xf1080000-0xf2081000 16781312 aty128_probe+0x118/0xac8 phys=0x94000000 ioremap
0xf20a0000-0xf20c1000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf20e0000-0xf2101000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf2120000-0xf2141000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf2160000-0xf2181000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf21a0000-0xf21c1000  135168 pci_map_rom+0x6c/0x138 phys=0x90020000 ioremap
0xf21c9000-0xf21cb000    8192 load_module+0x10e8/0x22b0 pages=1 vmalloc
0xf21e8000-0xf21f7000   61440 load_module+0x10e8/0x22b0 pages vmalloc
0xf2202000-0xf2206000   16384 load_module+0x10e8/0x22b0 pages=3 vmalloc
0xf220d000-0xf2210000   12288 load_module+0x10e8/0x22b0 pages=2 vmalloc
0xf2228000-0xf2237000   61440 load_module+0x10e8/0x22b0 pages vmalloc
0xf2246000-0xf224c000   24576 load_module+0x10e8/0x22b0 pages=5 vmalloc

774 more lines

Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help