[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mct
From: |
Jonathan Cameron |
Subject: |
Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mctp-1.0 |
Date: |
Fri, 17 Mar 2023 18:12:05 +0000 |
On Fri, 17 Mar 2023 16:37:20 +0000
Jonathan Cameron via <qemu-devel@nongnu.org> wrote:
> On Fri, 17 Mar 2023 00:11:10 +0530
> Maverickk 78 <maverickk1778@gmail.com> wrote:
>
> > Hi
> >
> > I am trying mctp & mctpd with aspeed +buildroot(master) + linux v6.2
> > with Qemu 7.2.
> >
> >
> > I have added necessary FMAPI related patches into QEMU to support CLX
> > switch emulation
> >
> > RFC-1-2-misc-i2c_mctp_cxl_fmapi-Initial-device-emulation.diff
> >
> > RFC-2-3-hw-i2c-add-mctp-core.diff
> >
> > RFC-4-4-hw-misc-add-a-toy-i2c-echo-device.diff
> >
> > RFC-2-2-arm-virt-Add-aspeed-i2c-controller-and-MCTP-EP-to-enable-MCTP-testing.diff
> >
> > RFC-3-3-hw-nvme-add-nvme-management-interface-model.diff
> >
> >
> > Executed following mctp commands to setup the binding,
> >
> > mctp link set mctpi2c15 up
> >
> > mctp addr add 50 dev mctpi2c15
> >
> > mctp link set mctpi2c15 net 11
> >
> > systemctl restart mctpd.service
> >
> > busctl call xyz.openbmc_project.MCTP /xyz/openbmc_project/mctp
> > au.com.CodeConstruct.MCTP AssignEndpoint say mctpi2c15 1 0x4d
> >
> >
> > The above busctl configuration is reaching fmapi patch and sets up
> > the endpoint id but then mctpd fails with log after timeout.
> >
> > Call failed: MCTP Endpoint did not respond
> >
> > Any clue what's going on?
>
> Hi Raghu,
>
> Yikes. Didn't think anyone would still use that series.
> Not even sure I still have a tree with it on.
>
> I'll try and bring up again and get back to you. Might be a little
> while though.
It is Friday and this was more interesting than what I was planning to do. :)
I think the breakage comes from the async send i2c series that was a month
or so after the PoC was posted. Issues was it was only entering the _bh once.
Following hack works for me on current mainline (+ CXL patches that shouldn't
affect this.)
From c8d819835faaec2b2a4755eb891284fe21c0747d Mon Sep 17 00:00:00 2001
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Fri, 17 Mar 2023 18:07:08 +0000
Subject: [PATCH] misc/i2c_mctp_fmapi: Hack
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
hw/misc/i2c_mctp_cxl_fmapi.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/misc/i2c_mctp_cxl_fmapi.c b/hw/misc/i2c_mctp_cxl_fmapi.c
index 219e30bfd5..2e2da80264 100644
--- a/hw/misc/i2c_mctp_cxl_fmapi.c
+++ b/hw/misc/i2c_mctp_cxl_fmapi.c
@@ -330,7 +330,7 @@ static int i2c_mctp_cxl_switch_event(I2CSlave *i2c, enum
i2c_event event)
case I2C_FINISH:
s->len = 0;
s->state = MCTP_I2C_PROCESS_REQUEST;
- qemu_bh_schedule(s->bh);
+ i2c_bus_master(s->bus, s->bh);
return 0;
case I2C_NACK:
default:
@@ -671,12 +671,11 @@ static void mctp_bh(void *opaque)
switch (s->state) {
case MCTP_I2C_PROCESS_REQUEST:
- i2c_bus_master(s->bus, s->bh);
s->state = MCTP_I2C_START_SEND;
- return;
-
+// return;
+ //fallthrough
case MCTP_I2C_START_SEND:
- i2c_start_send(s->bus, s->source_slave_addr);
+ i2c_start_send_async(s->bus, s->source_slave_addr);
s->send_buf[s->len] = s->source_slave_addr << 1;
s->len++;
s->state = MCTP_I2C_ACK;
--
2.37.2
>
> Jonathan
>
>
> >
> >
> > Regards
> > Raghu
>
>
>