Message-ID: <nmmp42qhsajsxs2inzpmir7k7goeqlm36tfbjhvzuu4uevdcyu@zpatg2zmwd2b>
Date: Sat, 30 Mar 2024 10:14:06 +0000
From: "edmund.raile" <edmund.raile@...ton.me>
To: helgaas@...nel.org, o-takashi@...amocchi.jp, alex.williamson@...hat.com, linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v2] PCI: Mark LSI FW643 to avoid bus reset

> Please mind that current software stack to operate your device does not
> support this kind of operation, as I've already sent to you several times.
> Users should cancel any type of communication on IEEE 1394 bus, then
> unplug devices from the bus (or power them off), finally operate
> suspending.

Yes I know, that's what I meant by it having "good cause to produce a trace".
I only meant ot demonstrate that sudo for tee is not potent enough here, which might also
be a reason why you get no kernel message.
I'm assuming the unbind indeed produces no kernel trace for you.
su -c 'echo -n "0000:03:00.0" > /sys/bus/pci/drivers/firewire_ohci/unbind'

> The power management method Apple uses to cut power to the FireWire
> controller, Thunderbolt controller and discrete GPU is nonstandard.
I sincerely hope any implementation for Apple PCs wouldn't hinder normal
operation of FW643 add-in-cards.

> In the meantime, or maybe as a permanent solution, Edmund can make use
> of the reset_method interface in pci-syfs to restrict the available
> reset methods for the device rather than risk removing a reset
> mechanism identified as working by other users. 

> Revert 29a43dc130ce until we figure out a better solution.  In the
> meantime, we can use the sysfs "reset_method" interface to restrict the
> available reset methods.

I tried your suggestion:
Instead of the patch:
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATT, 0x5901, quirk_no_bus_reset);
To avoid bus reset, as root, I ran:
echo -n "pm"> /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/reset_method
Which reduced reset_methods from 'pm bus' to just 'pm', according to
cat /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/reset_method

Then to bind the FW643 to vfio-pci:
echo -n "fw1.0" > /sys/bus/firewire/drivers/snd_fireface/unbind
echo -n "0000:03:00.0" > /sys/bus/pci/drivers/firewire_ohci/unbind
At this point, no kernel message, so I assume unbind worked fine!

modprobe vfio_pci
modprobe vfio_iommu_type1
modprobe vfio_pci
then strangely binding to vfio-pci returned an error
echo -n "0000:03:00.0" > /sys/bus/pci/drivers/firewire_ohci/bind
echo: write error: no matching device found.
so I used
echo 11c1 5901 > /sys/bus/pci/drivers/vfio-pci/new_id

Finally running qemu with '-device vfio-pci,host=03:00.0' produces these kernel messages:
pcieport 0000:00:1c.1: broken device, retraining non-functional downstream link at 2.5GT/s
pcieport 0000:00:1c.1: retraining failed
pcieport 0000:00:1c.1: broken device, retraining non-functional downstream link at 2.5GT/s
pcieport 0000:00:1c.1: retraining failed
vfio-pci 0000:03:00.0: not ready 1023ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 2047ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 4095ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 8191ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 16383ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 32767ms after bus reset; waiting
vfio-pci 0000:03:00.0: not ready 65535ms after bus reset; giving up
twice, then:
vfio-pci 0000:03:00.0: Unable to change power state from D0 to D3hot, device inaccessible
vfio-pci 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible

So the quirk_no_bus_reset does more than just setting reset_method manually.

So how can I use it then?

Zooming out, might this not be a general issue with bus reset not working on Z690?
Who do I turn to?

Powered by blists - more mailing lists