On 09.04.20 02:04, Peter Stuge wrote:
I found something that might be relevant in https://del.dog/raw/cbmemlog however, search it for Remap:
--8<-- https://del.dog/raw/cbmemlog#149 PCI: 00:1c.0: Disabling device PCI: 00:1c.0: check set enabled PCH: Remap PCIe function 1 to 0
That's a weird puzzle. I've looked into the code, it's not mapping _to_ a specific number but swapping _with_ what was there last. So if the mapping was:
idx 0 1 2 3 4 5 6 7 fn 0 1 2 3 4 5 6 7
this swaps what is at 0 with what is at 1:
idx 0 1 2 3 4 5 6 7 fn 1 0 2 3 4 5 6 7
PCI: 00:1c.1 [8086/1c12] enabled PCI: 00:1c.2: Disabling device PCH: Remap PCIe function 3 to 0
Swaps what is at 3 with what is at 0:
idx 0 1 2 3 4 5 6 7 fn 3 0 2 1 4 5 6 7
PCI: 00:1c.3 [8086/1c16] enabled PCH: Remap PCIe function 4 to 0
Swaps what is at 4 with what is at 0:
idx 0 1 2 3 4 5 6 7 fn 4 0 2 1 3 5 6 7
idx 1, 3 and 4 are on in the devicetree. So final relevant state:
idx 0 1 2 3 4 5 6 7 fn 0 1 3
This is not wrong. But the algorithm is that complex because it's supposed to leave no gaps. And it fails at that in this case :-/
--8<-- https://del.dog/raw/cbmemlog#175 PCI: Leftover static devices: PCI: 00:01.0 PCI: 00:16.1 PCI: 00:16.2 PCI: 00:16.3 PCI: 00:1c.4 PCI: 00:1c.2 PCI: 00:1c.5 PCI: 00:1c.7 PCI: Check your devicetree.cb. -->8--
Partially my fault, when we added these messages, we didn't consider devices that were hidden on purpose. I guess we should not complain about devices on bus 0 with !dev->enabled (i.e. `off` in the device- tree).
But here seems also something fishy wrt. the remapping: What about 1c.6?
Nico