Recursive pci scan hanging on some PC's?

clementttttttttt · **Joined:** Tue Jul 14, 2020 4:01 am **Posts:** 60

So I made a recursive pci scanning function, and it's hanging on my computer, but not in qemu, bochs, etc. Additionally, is there anyway to debug pci hangs on real hardware?

Korona · **Joined:** Thu May 17, 2007 1:27 pm **Posts:** 881

Recursive PCI enumeration does not hang PCs.

Recursive PCI enumeration is the only correct strategy to enumerate busses. For configuration mechanisms such as ECAM, non-recursive enumeration does not even work.

clementttttttttt · **Joined:** Tue Jul 14, 2020 4:01 am **Posts:** 60

might have make some mistake in the code then. will look at it even more

Gigasoft · **Joined:** Sat Nov 21, 2009 5:11 pm **Posts:** 749

Do you have a way to output text on the screen?

Ethin · **Posted:** Mon Mar 29, 2021 3:02 pm

Korona wrote:

Recursive PCI enumeration does not hang PCs.

Recursive PCI enumeration is the only correct strategy to enumerate busses. For configuration mechanisms such as ECAM, non-recursive enumeration does not even work.

How so? Unless I'm missing something, this method, which is what I use, is not recursive and works just fine:

Code:

        let mut maxsg: u16 = 0;
        (0..MAX_SG).for_each(|i| {
            if regions.physical_address(i as u16, 0, 0, 0).is_some() {
                maxsg += 1;
            }
        });
        for sg in 0u16..maxsg {
            for bus in 0..MAX_BUS {
                for device in 0..MAX_DEVICE {
                    for function in 0..MAX_FUNCTION {
// Probe
                    }
                }
            }
        }

I use a method to check to see if the region I'm accessing in PCIe is actually a region in PCIe space but other than that, this is the code I'm using. Are you saying that this way isn't the right way?

AndrewAPrice · **Posted:** Mon Mar 29, 2021 4:18 pm

I can't see your code but feel free to compare against mine for any differences:

https://github.com/AndrewAPrice/Percept ... c#L56-L119

kzinti · **Joined:** Mon Feb 02, 2015 7:11 pm **Posts:** 664

Ethin wrote:

How so? Unless I'm missing something, this method, which is what I use, is not recursive and works just fine:

How do you handle/detect nested/secondary/subordinate buses? Recursion seems to be the natural way to go about it.

Ethin · **Posted:** Mon Mar 29, 2021 5:14 pm

kzinti wrote:

Ethin wrote:

How so? Unless I'm missing something, this method, which is what I use, is not recursive and works just fine:

How do you handle/detect nested/secondary/subordinate buses? Recursion seems to be the natural way to go about it.

I don't treat a bridge or bus any differently than any other device. If I can scan it (that is, if the vendor ID isn't 0xFFFF or 0x0000), I add it. For bridges and such, I have this extra bit of handlign code:

Code:

                                // Bridge or PCI card bus
                                secondary_bus: if (read_byte(addr as usize, HEADER_TYPE) & 0x7F)
                                    == 1
                                    || (read_byte(addr as usize, HEADER_TYPE) & 0x7F) == 2
                                {
                                    read_byte(addr as usize, SEC_BUS)
                                } else {
                                    0
                                },

And then, for any device, I set command bits 0, 1, 2, 6, 8, and 10 and clear bits 3, 4, 5, 7, 9, and 15:11.

clementttttttttt · **Joined:** Tue Jul 14, 2020 4:01 am **Posts:** 60

nevermind, it works now, might have mistyped something somewhere

Korona · **Joined:** Thu May 17, 2007 1:27 pm **Posts:** 881

Ethin wrote:

I use a method to check to see if the region I'm accessing in PCIe is actually a region in PCIe space but other than that, this is the code I'm using. Are you saying that this way isn't the right way?

Okay, that works but that's kind of a hack -- using recursive enumeration you know a priori whether a bus number is valid or not.

Aside from that, there are situations where non-recursive enumeration truly does not work: for example, on most (all?) ARM devices, the firmware does not allocate bus numbers for you and you have to do it yourself once you see a bridge. The same is true even for x86 if you have a bridge on an expansion card.

Ethin · **Posted:** Tue Mar 30, 2021 8:31 am

Korona wrote:

Ethin wrote:

I use a method to check to see if the region I'm accessing in PCIe is actually a region in PCIe space but other than that, this is the code I'm using. Are you saying that this way isn't the right way?

Okay, that works but that's kind of a hack -- using recursive enumeration you know a priori whether a bus number is valid or not.

Aside from that, there are situations where non-recursive enumeration truly does not work: for example, on most (all?) ARM devices, the firmware does not allocate bus numbers for you and you have to do it yourself once you see a bridge. The same is true even for x86 if you have a bridge on an expansion card.

Hmm... That definitely seems like a problem. I might switch my code to using the recursive initialization sequence then.

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 927

Ethin wrote:

How so? Unless I'm missing something, this method, which is what I use, is not recursive and works just fine:

That method is not recursive, but it will scan a lot of busses that are not actually present. And a lot of functions that are not present. I mean, the code will work, it's just doing a lot of useless nonsense.

Korona wrote:

Aside from that, there are situations where non-recursive enumeration truly does not work: for example, on most (all?) ARM devices, the firmware does not allocate bus numbers for you and you have to do it yourself once you see a bridge. The same is true even for x86 if you have a bridge on an expansion card.

I would handle that by putting a separate PCI bridge initialization step before the actual enumeration. Besides, if I have to initialize PCI bridges, I will likely also have to initialize PCI BARs, and that is where it gets complicated without knowledge of the system.

Korona · **Joined:** Thu May 17, 2007 1:27 pm **Posts:** 881

nullplan wrote:

I would handle that by putting a separate PCI bridge initialization step before the actual enumeration. Besides, if I have to initialize PCI bridges, I will likely also have to initialize PCI BARs, and that is where it gets complicated without knowledge of the system.

To see all bridges, you have to see all devices anyway, so you can integrate these two kinds of iterations into a single recursive scan.

You are correct about the BARs. It is a bit annoying but not too complicated: you get the memory range that the PCI root complex can address from the DTB, you recursively enumerate all BARs behind each bridge, and you allocate enough space for the devices behind each bridge, set up the bridge's MMIO range registers, and finally set up the BARs.

clementttttttttt · **Joined:** Tue Jul 14, 2020 4:01 am **Posts:** 60

Now it sometime hangs, but sometime works. This doesn't happen on emulators so debugging is very hard. Is there anything like a pci card or smth that shows the register states on real hardware?

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 927

Have you taken any steps to debug the issue? Even something as simple as "print EIP when I press a button"? You should be able to see what is going on that way.

OSDev.org

Recursive pci scan hanging on some PC's?

Who is online