On 12/06/2015 08:56 AM, Andrei Borzenkov wrote:
04.12.2015 12:40, Panu Matilainen пишет:
Hi all,
To follow-up on this thread from September-October:
http://lists.freedesktop.org/archives/systemd-devel/2015-September/034427.html
http://lists.freedesktop.org/archives/systemd-devel/2015-October/034551.html
The driverctl utility has matured a bit from the earliest tyre-kicking
version seen there and now lives at laiskiainen.org/git/?p=driverctl.git
Since it has everything to do with udev this seems like a reasonable
forum to advertise it a bit. Quoting from the README a bit:
driverctl is a tool for manipulating and inspecting the system
device driver choices.
Devices are normally assigned to their sole designated kernel driver
by default. However in some situations it may be desireable to
override that default, for example to try an older driver to
work around a regression in a driver or to try an experimental
alternative
driver. Another common use-case is pass-through drivers and driver
stubs to allow userspace to drive the device, such as in case of
virtualization.
driverctl integrates with udev to support overriding
driver selection for both cold- and hotplugged devices from the
moment of discovery, but can also change already assigned drivers,
assuming they are not in use by the system. The driver overrides
created by driverctl are persistent across system reboots
by default.
Usage
-----
Find devices currently driven by ixgbe driver:
# driverctl -v list-devices | grep ixgbe
0000:01:00.0 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
0000:01:00.1 ixgbe (Ethernet 10G 4P X520/I350 rNDC)
Change them to use the vfio-pci driver:
# driverctl set-override 0000:01:00.0 vfio-pci
# driverctl set-override 0000:01:00.1 vfio-pci
Find devices with driver overrides:
# driverctl -v list-devices|grep \\*
0000:01:00.0 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
0000:01:00.1 vfio-pci [*] (Ethernet 10G 4P X520/I350 rNDC)
Remove the override from slot 0000:01:00.1:
# driverctl unset-override 0000:01:00.1
As was mentioned recently PCI bus numbers may change between reboots, so
Hmm, got a pointer? I dont think PCI slots change between reboots
without physically swapping hardware, the "ethX-problem" comes from the
order of device discovery being unstable across boots, which is a
different issue and not relevant for this case.
you may want to start with something more stable from the very beginning.
Such as? I dont see any other data that is there for all PCI (and USB)
devices that allows differentiating between two otherwise identical devices.
- Panu -
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
