XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. achim71
    3. Best
    A
    Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 0
    • Posts 7
    • Groups 0

    Posts

    Recent Best Controversial
    • RE: XCP-ng 8.0.0 Release Candidate

      Tracked down the necessary patch to make ipmi work again.

      https://lkml.org/lkml/2019/2/21/926

      *When excuting a command like:
      modprobe ipmi_si ports=0xffc0e3 type=bt
      The system would get an oops.

      The trouble here is that ipmi_si_hardcode_find_bmc() is called before ipmi_si_platform_init(), but initialization of the hard-coded device creates an IPMI platform device, which won't be initialized yet.

      The real trouble is that hard-coded devices aren't created with any device, and the fixup is done later. So do it right, create the hard-coded devices as normal platform devices.

      This required adding some new resource types to the IPMI platform code for passing information required by the hard-coded device
      and adding some code to remove the hard-coded platform devices on module removal.

      To enforce the "hard-coded devices passed by the user take priority over firmware devices" rule, some special code was added to check and see if a hard-coded device already exists.*

      The patch was backported to 4.19.37. Used the backported version from here. https://github.com/raspberrypi/linux/commit/6bba17f6bce39e46fdf8c0fe190bdc3f57ef8f8f

      Once applied to the 4.19.19 sources

      modprobe type=kcs ports=0xca2
      ipmitool sensor
      

      works. I tried it with an debian usb system with pristen 4.19.19 sources.
      Is it woth the effort to prepare the patch for the xcp-ng kernel "kernel-4.19.19-5.0.8.1.xcpng8.0.x86_64.rpm"?
      I assume it has to be signed by microsoft to make it work with secure uefi.

      0 cminyard committed to raspberrypi/linux
      ipmi_si: Fix crash when using hard-coded device
      
      Backport from 41b766d661bf94a364960862cfc248a78313dbd3
      
      When excuting a command like:
        modprobe ipmi_si ports=0xffc0e3 type=bt
      The system would get an oops.
      
      The trouble here is that ipmi_si_hardcode_find_bmc() is called before
      ipmi_si_platform_init(), but initialization of the hard-coded device
      creates an IPMI platform device, which won't be initialized yet.
      
      The real trouble is that hard-coded devices aren't created with
      any device, and the fixup is done later.  So do it right, create the
      hard-coded devices as normal platform devices.
      
      This required adding some new resource types to the IPMI platform
      code for passing information required by the hard-coded device
      and adding some code to remove the hard-coded platform devices
      on module removal.
      
      To enforce the "hard-coded devices passed by the user take priority
      over firmware devices" rule, some special code was added to check
      and see if a hard-coded device already exists.
      
      The backport required some minor fixups and adding the device
      id table that had been added in another change and was used
      in this one.
      
      Reported-by: Yang Yingliang <yangyingliang@huawei.com>
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: Corey Minyard <cminyard@mvista.com>
      Tested-by: Yang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: Sasha Levin <sashal@kernel.org>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      posted in News
      A
      achim71