On Mon, Dec 16, 2019 at 06:34:22PM +0100, Stefan Roese wrote: > Hi Keith, > > On 16.12.19 16:50, Keith Busch wrote: > > On Mon, Dec 16, 2019 at 07:50:20AM +0100, Stefan Roese wrote: > > > On 16.12.19 01:46, Bjorn Helgaas wrote: > > > > > > The logs are also included. Please let me know, if I should do any other > > > > > > tests and provide the logs. > > > > > > > > Please include these logs in your mail to the list or post them > > > > someplace where everybody can see them. > > > > > > Gladly. Please find the archive here: > > > > > > https://filebin.ca/55U8waihXJVI/logs.tar.bz2 > > > > I can't access that. Could you paste directly into the email? I'm just > > looking for 'dmesg' and 'lspci -vvv' right now, so trim to that if your > > full capture is too long. > > Sure, here a try with inline logs (stripped down a bit). I didn't include > all test versions for now, since this inrease the mail size even more, Only > test a) ... d) are inlined here: I think your platform bios simply doesn't support it. It does not provision empty slots on its own, and it doesn't tolerate the OS reassigning resources to them from what appears to be unnassigned memory windows. The platform may be using those memory windows for something outside the kernel's visibility. What happens if you boot the system with all slots populated? Do all devices configure in that case, and if so, can you hot-swap them?
