> 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?
