Jump to content

endymion

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About endymion

  • Rank
    Newbie

Converted

  • Gender
    Undisclosed
  1. Thanks! I've added your results and johnnie.black's results to the initial report, here, as a comparison of all of the boards. As you can see there, there is not one suspect difference found, so I have failed to find a significant clue, so far. There are still possible differences in how the UEFI is configured in the systems, and perhaps the non-working systems should report anything in their UEFI setup that is not default. I didn't know that existed! And it actually works (even on the phone)! Awesome, thank you! This is interesting, and I'd like to know if IPMIView (or any other tool) has a screen buffer for the console, preserved even after the reboot. The problem here is that what we really needed to see was the console messages (or dmesg) up until just before the reboot, on the rebooting systems, but that hasn't been possible. If the second machine can capture the screen and still have it after the reboot, then we can know either the last error, or at least how far it got, and can narrow the suspects down. I am downloading an eval copy of SuperMicro's SUM now, which should allow me to dump the current BIOS config once I figure it out. Unfortunately I'm now one state over from my server, so getting a direct screen capture isn't possible. If I have a chance and IPMIView seems to work stable, I'll see if I can figure out a way to capture it. Attached are the current BIOS config, and for completion, the DMI config. SuperMicro was super helpful in giving me an eval key for SUM! dmi.txt bios.txt
  2. Thanks! I've added your results and johnnie.black's results to the initial report, here, as a comparison of all of the boards. As you can see there, there is not one suspect difference found, so I have failed to find a significant clue, so far. There are still possible differences in how the UEFI is configured in the systems, and perhaps the non-working systems should report anything in their UEFI setup that is not default. I didn't know that existed! And it actually works (even on the phone)! Awesome, thank you! This is interesting, and I'd like to know if IPMIView (or any other tool) has a screen buffer for the console, preserved even after the reboot. The problem here is that what we really needed to see was the console messages (or dmesg) up until just before the reboot, on the rebooting systems, but that hasn't been possible. If the second machine can capture the screen and still have it after the reboot, then we can know either the last error, or at least how far it got, and can narrow the suspects down. I am downloading an eval copy of SuperMicro's SUM now, which should allow me to dump the current BIOS config once I figure it out. Unfortunately I'm now one state over from my server, so getting a direct screen capture isn't possible. If I have a chance and IPMIView seems to work stable, I'll see if I can figure out a way to capture it.
  3. I didn't know that existed! And it actually works (even on the phone)! Awesome, thank you!
  4. No keyboard or mouse connected, access server by IPMI A bit off-topic, but how the heck did you get console-redirection working? Every time I try to use it, the Java thing comes up and looks like it's going to connect, and then it gets an error. Scouring the internet didn't seem to net anything terribly useful as far as a fix.
  5. My X11SSM-F is working fine, diags and dmesg attached, maybe it can help. johnnie.black and Herdo are using the same motherboard, with the same BIOS. That should eliminate the motherboard, the Skylake, the Sunrise Point-H, and the BIOS from consideration. Quick diff of the dmesg: * Same spurious IRQ7, so that's not an issue. Same ipmi_si and BMC fix needed, same messages entirely, so that's not it either. * One probably minor difference, Johnnie has one keyboard and mouse, the rebooting systems have 2 keyboards and one mouse. It still seems completely a coincidence. * Johnnie is booting with "pci-stub.ids=8086:10d3 pcie_acs_override=downstream", Intel gigabit card stubbed and ACS_override=downstream. The nonworking systems don't have that. Perhaps the override could help? There's nothing else in the dmesg of significance. And I don't *think* the override should affect booting. * Of unknown significance, the Host bridge PCI ID is slightly different: (mentioned for completeness) --- 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:1918] (rev 07) (Herdo & endymion) --- 00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM Registers [8086:190f] (rev 07) (johnnie.black) I found nothing else of significance between the systems. Only other thing I can think of that could be significant is how the UEFI/BIOS is set up. Just FYI, while my system was boot looping, I didn't have any keyboard or mouse hooked up. I normally only have power cable and 2 ethernet (one GigE port, one IPMI port) hooked up. I had to drag a monitor and keyboard/mouse downstairs to find out why it wasn't coming up after the upgrade SuperMicro console redirection via IPMI doesn't work, which is super frustrating.
  6. Have looked at it but can't reproduce just yet. Still a little perplexed on that one but definitely seems like hardware may be a little buggy there. I had the *exact* same problem when I upgraded last night. Tried different USB ports, stick, fresh install, etc, etc. Only having it boot in GUI mode works. Memory test came up with no issues, and a parity check completed with no errors. Can't find anything useful logged anywhere apparently. It's just bizarre. I have a SuperMicro X11SSH-F with a Xeon BX80662E31230V5, 32GB ECC RAM, 7 4TB drives, and 2 850EVO SSDs. Can you attach your diagnostics here? I'd like to compare with the other user with this issue, see what is common. I notice they too have a recent SuperMicro. Can you also attach a copy of your dmesg file? The following will copy it to your flash drive: cp /var/log/dmesg /boot/dmesg.txt Here you go. Thanks! It'd be nice not to have to default to GUI mode, considering I don't even have a monitor on the machine.... pvr-diagnostics-20160928-0111.zip dmesg.txt
  7. Thanks to YOU guys at Limetech for a really nice upgrade with 6.2 By the way, have you had a chance to take a look at this issue? https://lime-technology.com/forum/index.php?topic=51878.0 REALLY strange that it boots in GUI mode, but simply goes in a reboot loop otherwise. Have looked at it but can't reproduce just yet. Still a little perplexed on that one but definitely seems like hardware may be a little buggy there. I had the *exact* same problem when I upgraded last night. Tried different USB ports, stick, fresh install, etc, etc. Only having it boot in GUI mode works. Memory test came up with no issues, and a parity check completed with no errors. Can't find anything useful logged anywhere apparently. It's just bizarre. I have a SuperMicro X11SSH-F with a Xeon BX80662E31230V5, 32GB ECC RAM, 7 4TB drives, and 2 850EVO SSDs.