-1

we have rhel 7.5 machines , that perform unexpected reboot

before the reboot we can see the following lines from /var/log/messages file

any idea how this lines indicate about the machine reboot? 

May  8 21:46:01 server_mng kernel: system 00:00: [io  0x1000-0x103f] could not be reserved
May  8 21:46:01 server_mng kernel: system 00:00: [io  0x1040-0x104f] has been reserved
May  8 21:46:01 server_mng kernel: system 00:00: [io  0x0cf0-0x0cf1] has been reserved
May  8 21:46:01 server_mng kernel: system 00:04: [mem 0xfed00000-0xfed003ff] has been reserved
May  8 21:46:01 server_mng kernel: system 00:05: [io  0xfce0-0xfcff] has been reserved
May  8 21:46:01 server_mng kernel: system 00:05: [mem 0xf0000000-0xf7ffffff] has been reserved
May  8 21:46:01 server_mng kernel: system 00:05: [mem 0xfe800000-0xfe9fffff] has been reserved
May  8 21:46:01 server_mng kernel: pnp: PnP ACPI: found 6 devices
May  8 21:46:01 server_mng kernel: ACPI: bus type PNP unregistered
May  8 21:46:01 server_mng kernel: pci 0000:00:15.0: BAR 15: assigned [mem 0xc0000000-0xc01fffff 64bit pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:16.0: BAR 15: assigned [mem 0xc0200000-0xc03fffff 64bit pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:0f.0: BAR 6: assigned [mem 0xc0400000-0xc0407fff pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.3: BAR 13: no space for [io  size 0x1000]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.3: BAR 13: failed to assign [io  size 0x1000]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.4: BAR 13: no space for [io  size 0x1000]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.4: BAR 13: failed to assign [io  size 0x1000]
May  8 21:46:01 server_mng kernel: pci 0000:00:01.0: PCI bridge to [bus 01]
May  8 21:46:01 server_mng kernel: pci 0000:02:01.0: BAR 6: assigned [mem 0xfd500000-0xfd50ffff pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:11.0: PCI bridge to [bus 02]
May  8 21:46:01 server_mng kernel: pci 0000:00:11.0:   bridge window [io  0x2000-0x3fff]
May  8 21:46:01 server_mng kernel: pci 0000:00:11.0:   bridge window [mem 0xfd500000-0xfdffffff]
May  8 21:46:01 server_mng kernel: pci 0000:00:11.0:   bridge window [mem 0xe7b00000-0xe7ffffff 64bit pref]
May  8 21:46:01 server_mng kernel: pci 0000:03:00.0: BAR 6: assigned [mem 0xfd400000-0xfd40ffff pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.0: PCI bridge to [bus 03]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.0:   bridge window [io  0x4000-0x4fff]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.0:   bridge window [mem 0xfd400000-0xfd4fffff]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.0:   bridge window [mem 0xc0000000-0xc01fffff 64bit pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.1: PCI bridge to [bus 04]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.1:   bridge window [io  0x8000-0x8fff]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.1:   bridge window [mem 0xfd000000-0xfd0fffff]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.1:   bridge window [mem 0xe7800000-0xe78fffff 64bit pref]
May  8 21:46:01 server_mng kernel: pci 0000:00:15.2: PCI bridge to [bus 05]
Improve this question
5
  • If a VM, see the logs on vmware side too. – Rui F Ribeiro May 19 '20 at 9:33
  • yes its VM machines what I need to fix from the rhel side? – yael May 19 '20 at 9:56
  • It is not evident there is "something to fix". You have to talk with the hypervisor managers, and find out if there were hosts reboots, forced VM reboots or migrated VMs. – Rui F Ribeiro May 19 '20 at 10:18
  • from the logs messages that I post - how you know this is something that related to VM<ware? – yael May 19 '20 at 10:23
  • 1
    The logs that you post seem to be from a start and not a shutdown...call it an educated guess. – Rui F Ribeiro May 19 '20 at 10:27
1

Those messages are the result of the system scanning the hardware configuration and assigning system resources to various devices. Normally you'll see these messages logged in an early part of the boot-up sequence, basically just after the bootloader has loaded the kernel and started it.

If the system would assign the resources incorrectly, it might cause the system to crash immediately. In that case, the last messages logged/displayed before the crash might be helpful to kernel developers to identify which resource allocation was done incorrectly, and the nature of the incorrect allocation (Overlapping assignments? Trying to assign a configuration that makes no sense? Something else?). If you selected a more verbose boot process (in RHEL, typically removing the boot options rhgb and quiet), all these messages would appear as boot messages.

If the system has hot-pluggable PCI/PCI-X/PCIe/Thunderbolt devices, you might see a smaller group of similar messages at hot-plug time. But the facts that there are both PnP ACPI resource allocations and PCI ones, and that there are messages for so many different PCI devices, support the conclusion that these messages are probably from the boot process. A PCI hot-plug event would generally produce a group of messages with a more limited set of PCI device ID numbers.

This output looks like it's scanning for basically all the (virtual) devices the (virtual) machine has, and that usually only happens at boot time.

When troubleshooting an unexpected system crash, usually the messages logged just before the reboot, if any are available, are the most useful in finding out the cause of the crash.

If there aren't any abnormal messages logged from before the reboot, it might mean that the problem has been detected at the level of the virtualization host, and it has killed and restarted the VM - the VM-level equivalent of kill -9, of sorts. Or it might mean that the problem affected the storage driver, and so the kernel had no way to get the error message written into the logs.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.