From: "edmund.raile" <edmund.raile@proton.me>
To: helgaas@kernel.org, o-takashi@sakamocchi.jp,
alex.williamson@redhat.com,
linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI: Mark LSI FW643 to avoid bus reset
Date: Sat, 30 Mar 2024 10:14:06 +0000 [thread overview]
Message-ID: <nmmp42qhsajsxs2inzpmir7k7goeqlm36tfbjhvzuu4uevdcyu@zpatg2zmwd2b> (raw)
> 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?
next reply other threads:[~2024-03-30 10:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-30 10:14 edmund.raile [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-02-26 10:25 [PATCH] PCI: Mark LSI FW643 to avoid bus reset Edmund Raile
2024-02-27 13:14 ` [PATCH v2] " Edmund Raile
2024-02-29 23:00 ` Bjorn Helgaas
2024-03-25 1:21 ` Takashi Sakamoto
2024-03-25 14:41 ` Bjorn Helgaas
2024-03-26 13:18 ` Takashi Sakamoto
2024-03-27 15:01 ` Bjorn Helgaas
2024-03-28 20:42 ` Alex Williamson
2024-03-28 21:06 ` Bjorn Helgaas
2024-03-29 4:41 ` Lukas Wunner
2024-03-29 8:12 ` Takashi Sakamoto
2024-03-29 13:37 ` Lukas Wunner
2024-03-28 18:35 ` edmund.raile
2024-03-29 8:05 ` Takashi Sakamoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nmmp42qhsajsxs2inzpmir7k7goeqlm36tfbjhvzuu4uevdcyu@zpatg2zmwd2b \
--to=edmund.raile@proton.me \
--cc=alex.williamson@redhat.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=o-takashi@sakamocchi.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.