)]}'
{"doc/source/configuration/drivers.rst":[{"author":{"_account_id":39344,"name":"Gihong Lee","display_name":"gamio","email":"gh9231@gmail.com","username":"gamio"},"change_message_id":"84a0fd98dc1d3f8287d31195300b0386db7d0995","unresolved":true,"context_lines":[{"line_number":334,"context_line":"* One or more mdev-capable devices are installed and their host"},{"line_number":335,"context_line":"  drivers are loaded (e.g. the NVIDIA vGPU manager or the"},{"line_number":336,"context_line":"  ``i915`` driver with GVT-g support)."},{"line_number":337,"context_line":"* Each parent device exposes ``mdev_supported_types`` in sysfs."},{"line_number":338,"context_line":"  Verify by checking that the path"},{"line_number":339,"context_line":"  ``/sys/class/mdev_bus/\u003cPCI_ADDRESS\u003e/mdev_supported_types/``"},{"line_number":340,"context_line":"  exists and contains one or more type directories."}],"source_content_type":"text/x-rst","patch_set":8,"id":"7e5830a6_65d8b3ee","line":337,"range":{"start_line":337,"start_character":31,"end_line":337,"end_character":51},"updated":"2026-07-23 13:44:12.000000000","message":"For Ampere+ GPUs, mdev types live under SR-IOV VFs, not the PF. Worth noting the pre-Ampere vs Ampere+ distinction here.","commit_id":"632337755649168b0692a6a048aa5849977b1b31"},{"author":{"_account_id":39344,"name":"Gihong Lee","display_name":"gamio","email":"gh9231@gmail.com","username":"gamio"},"change_message_id":"66f690bf3717543d6874956550a579e866a716aa","unresolved":false,"context_lines":[{"line_number":334,"context_line":"* One or more mdev-capable devices are installed and their host"},{"line_number":335,"context_line":"  drivers are loaded (e.g. the NVIDIA vGPU manager or the"},{"line_number":336,"context_line":"  ``i915`` driver with GVT-g support)."},{"line_number":337,"context_line":"* Each parent device exposes ``mdev_supported_types`` in sysfs."},{"line_number":338,"context_line":"  Verify by checking that the path"},{"line_number":339,"context_line":"  ``/sys/class/mdev_bus/\u003cPCI_ADDRESS\u003e/mdev_supported_types/``"},{"line_number":340,"context_line":"  exists and contains one or more type directories."}],"source_content_type":"text/x-rst","patch_set":8,"id":"8569e531_7eebc3c5","line":337,"range":{"start_line":337,"start_character":31,"end_line":337,"end_character":51},"in_reply_to":"109053fa_c65bf665","updated":"2026-08-03 12:53:18.000000000","message":"Agreed. Since the mdev types are exposed under the device\u0027s PCI address in sysfs regardless of PF or VF, the generic procedure holds. Keeping it vendor neutral makes sense, thanks.","commit_id":"632337755649168b0692a6a048aa5849977b1b31"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"a490d1ab96254e49ac1250fe21a403f3dd66429d","unresolved":true,"context_lines":[{"line_number":334,"context_line":"* One or more mdev-capable devices are installed and their host"},{"line_number":335,"context_line":"  drivers are loaded (e.g. the NVIDIA vGPU manager or the"},{"line_number":336,"context_line":"  ``i915`` driver with GVT-g support)."},{"line_number":337,"context_line":"* Each parent device exposes ``mdev_supported_types`` in sysfs."},{"line_number":338,"context_line":"  Verify by checking that the path"},{"line_number":339,"context_line":"  ``/sys/class/mdev_bus/\u003cPCI_ADDRESS\u003e/mdev_supported_types/``"},{"line_number":340,"context_line":"  exists and contains one or more type directories."}],"source_content_type":"text/x-rst","patch_set":8,"id":"109053fa_c65bf665","line":337,"range":{"start_line":337,"start_character":31,"end_line":337,"end_character":51},"in_reply_to":"26abc1c8_614d1a5e","updated":"2026-08-03 07:17:19.000000000","message":"the ampere mdevs even if they live under the vfs will still be exposed in the sysfs mdev_bus behind a pci address so the documented procedure is still valid right? If so I would prefer avoid going into vendor details when possible and defer that to vendor drivers as Sean said","commit_id":"632337755649168b0692a6a048aa5849977b1b31"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"595ab21793c0d3fec5fe72ab11bef9e5b1ac9586","unresolved":true,"context_lines":[{"line_number":334,"context_line":"* One or more mdev-capable devices are installed and their host"},{"line_number":335,"context_line":"  drivers are loaded (e.g. the NVIDIA vGPU manager or the"},{"line_number":336,"context_line":"  ``i915`` driver with GVT-g support)."},{"line_number":337,"context_line":"* Each parent device exposes ``mdev_supported_types`` in sysfs."},{"line_number":338,"context_line":"  Verify by checking that the path"},{"line_number":339,"context_line":"  ``/sys/class/mdev_bus/\u003cPCI_ADDRESS\u003e/mdev_supported_types/``"},{"line_number":340,"context_line":"  exists and contains one or more type directories."}],"source_content_type":"text/x-rst","patch_set":8,"id":"26abc1c8_614d1a5e","line":337,"range":{"start_line":337,"start_character":31,"end_line":337,"end_character":51},"in_reply_to":"7e5830a6_65d8b3ee","updated":"2026-07-31 14:44:26.000000000","message":"i guess we coudl but that is more a vendor specfic implemaiton detail and i woudl prefer to aovid docuemthjign the specific of the nvida chocie in to much detail\n\n\nthe dirver will not asuume either toplogy and work with both.","commit_id":"632337755649168b0692a6a048aa5849977b1b31"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"595ab21793c0d3fec5fe72ab11bef9e5b1ac9586","unresolved":true,"context_lines":[{"line_number":315,"context_line":"    [agent]"},{"line_number":316,"context_line":"    enabled_drivers \u003d fake_driver"},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Generic Mdev Driver"},{"line_number":319,"context_line":"-------------------"},{"line_number":320,"context_line":""},{"line_number":321,"context_line":"The generic mdev (mediated device) driver (``mdev_driver``) allows"}],"source_content_type":"text/x-rst","patch_set":12,"id":"c9176a89_961d6daf","line":318,"updated":"2026-07-31 14:44:26.000000000","message":"please create a new top level document for the mdev driver and link to it form here\n\nit is my hope that by the end of the release or eearly next cycle we will have sepreated out each driver into there own document and this will just aggreate links to them","commit_id":"b8fc9d8cac4ad65076131511bdf97cc33269f64c"},{"author":{"_account_id":34452,"name":"Joan Gilabert","display_name":"jgilaber","email":"jgilaber@redhat.com","username":"jgilaber"},"change_message_id":"a490d1ab96254e49ac1250fe21a403f3dd66429d","unresolved":true,"context_lines":[{"line_number":315,"context_line":"    [agent]"},{"line_number":316,"context_line":"    enabled_drivers \u003d fake_driver"},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"Generic Mdev Driver"},{"line_number":319,"context_line":"-------------------"},{"line_number":320,"context_line":""},{"line_number":321,"context_line":"The generic mdev (mediated device) driver (``mdev_driver``) allows"}],"source_content_type":"text/x-rst","patch_set":12,"id":"975abb74_a8fc7662","line":318,"in_reply_to":"c9176a89_961d6daf","updated":"2026-08-03 07:17:19.000000000","message":"makes sense, done","commit_id":"b8fc9d8cac4ad65076131511bdf97cc33269f64c"}],"doc/source/configuration/mdev-driver.rst":[{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"394d58b441241aee76f51f162b7ef20d1d34ad77","unresolved":false,"context_lines":[{"line_number":58,"context_line":"    PCI address of the parent device, e.g. ``\"0000:06:00.0\"``."},{"line_number":59,"context_line":"    Use ``\"*\"`` to match all mdev-capable parent devices."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"``mdev_type`` (required)"},{"line_number":62,"context_line":"    The mdev type name as it appears in"},{"line_number":63,"context_line":"    ``mdev_supported_types/``, e.g. ``\"nvidia-319\"``."},{"line_number":64,"context_line":"    Use ``\"*\"`` to match all supported types on matched"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3a61629b_de53327e","line":61,"updated":"2026-08-31 13:27:15.000000000","message":"The document states that mdev_type can be \u0027*\u0027 to \u0027match all supported types on matched parent devices\u0027 and ships a dedicated Wildcard matching example plus a wildcard entry in the Multiple entries example. In the code only the address field is wildcard-aware: MdevDeviceSpec.match() computes addr_match with a WILDCARD check but then requires self.mdev_type \u003d\u003d type_name literally. Consequently a spec with mdev_type\u003d\u0027*\u0027 never matches a real sysfs type name, find_spec() returns None for every type, and discover() produces no deployables for that entry. The wildcard mdev_type behavior simply does not exist in the prepared tree, so the documented configuration discovers nothing.\n\n**Severity**: HIGH | **Confidence**: 0.9\n\n**Impact**: Operators following the Wildcard matching example (address\u003d\u0027*\u0027, mdev_type\u003d\u0027*\u0027, max_instances\u003d8) or the catch-all entry in the Multiple entries example get no mdev resources reported to Placement and no error pointing at the wildcard as the cause, leading to the exact \u0027No devices discovered\u0027 troubleshooting path the doc tries to prevent.\n\n**Priority**: Before merge\n**Recommendation**:\nCoordinate with the driver patches in this series: either add a WILDCARD check for mdev_type in MdevDeviceSpec.match() (and cover it in test_devspec.py), or remove wildcard mdev_type from the doc (keeping wildcard address) and note that mdev_type must be an exact type name. Do not merge documentation for behavior that does not exist.","commit_id":"485a938888ae6a75ca1f76488fba9443d76568f3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"394d58b441241aee76f51f162b7ef20d1d34ad77","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Multiple entries"},{"line_number":116,"context_line":"----------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Multiple ``device_spec`` lines can target different devices or"},{"line_number":119,"context_line":"types with independent settings.  When a device/type pair matches"},{"line_number":120,"context_line":"more than one entry, the most specific match wins: exact"},{"line_number":121,"context_line":"address and exact type first, then exact address with wildcard"}],"source_content_type":"text/x-rst","patch_set":15,"id":"d5737ba2_ed9a2819","line":118,"updated":"2026-08-31 13:27:15.000000000","message":"The Multiple entries section documents a specificity precedence (exact address + exact type \u003e exact address + wildcard type \u003e wildcard address + exact type \u003e both wildcards). MdevDeviceSpec.find_spec() iterates the spec list and returns the first match, and from_config_list() returns specs in config-file order (its \u0027sorted by specificity\u0027 docstring is not implemented; only exact (address, mdev_type) duplicates are dropped with a \u0027keeping first entry\u0027 warning). If the wildcard entry appears before the more specific entry in cyborg.conf, the wildcard entry\u0027s max_instances/resource_class/traits win, contradicting the documented rule. The undocumented duplicate-entry behavior (first entry kept, warning logged) is also missing from the docs.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: An operator who lists the catch-all entry first (a natural ordering) silently loses the per-device overrides documented to win, getting the wrong max_instances, resource_class, or traits reported to Placement without any error.\n\n**Suggestion**:\nEither implement specificity sorting in from_config_list() (and test it), or change the doc to state that the first matching entry in configuration order wins and that exact duplicate (address, mdev_type) entries are deduplicated with a warning keeping the first entry. Given CF-002, also align the precedence wording with whichever wildcard support actually ships.","commit_id":"485a938888ae6a75ca1f76488fba9443d76568f3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"394d58b441241aee76f51f162b7ef20d1d34ad77","unresolved":false,"context_lines":[{"line_number":141,"context_line":"    (``mdev_driver``) and a vendor-specific driver (e.g."},{"line_number":142,"context_line":"    ``nvidia_gpu_driver``) for the same parent device."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"If two drivers discover the same PCI device, the conductor"},{"line_number":145,"context_line":"will log a warning about duplicate devices.  The set-based diff"},{"line_number":146,"context_line":"silently collapses duplicates, but which driver\u0027s resource"},{"line_number":147,"context_line":"classes and traits are used is non-deterministic.  This can"}],"source_content_type":"text/x-rst","patch_set":15,"id":"702d3748_22f5ff93","line":144,"updated":"2026-08-31 13:27:15.000000000","message":"The new \u0027Coexistence with vendor-specific drivers\u0027 section states that if two drivers discover the same PCI device \u0027the conductor will log a warning about duplicate devices\u0027 and that \u0027the set-based diff silently collapses duplicates\u0027, making the chosen driver non-deterministic. That is the pre-check behavior. Commit 35caac8 in the same topic added _check_duplicate_devices(), called at the top of report_data(), which raises exception.DuplicateDeviceReported for any cpid_info reported by more than one driver. With the current code the agent\u0027s report_data RPC fails outright and no device data is written until the operator fixes enabled_drivers or device_spec.\n\n**Severity**: HIGH | **Confidence**: 0.95\n\n**Impact**: An operator who enables both mdev_driver and nvidia_gpu_driver for the same device will see report_data fail with DuplicateDeviceReported, not the documented warning-and-continue behavior, and may misdiagnose the error (e.g. as an agent bug) instead of fixing the config as the code intends.\n\n**Priority**: Before merge\n**Recommendation**:\nRewrite the paragraph to state that report_data() in the conductor detects duplicate controlpath_id.cpid_info entries and raises DuplicateDeviceReported, so the agent\u0027s device report fails until enabled_drivers or device_spec is corrected; keep the warning admonition and the address-restriction example, which remain good advice.","commit_id":"485a938888ae6a75ca1f76488fba9443d76568f3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"394d58b441241aee76f51f162b7ef20d1d34ad77","unresolved":false,"context_lines":[{"line_number":191,"context_line":"Invalid device_spec JSON"},{"line_number":192,"context_line":"-------------------------"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"If the agent fails to start with an error like::"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"    PciConfigInvalidWhitelist: Invalid mdev device_spec entry: ..."},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"74929221_a465e0ca","line":194,"updated":"2026-08-31 13:27:15.000000000","message":"The troubleshooting entry says \u0027If the agent fails to start with an error like:: PciConfigInvalidWhitelist: Invalid mdev device_spec entry: ...\u0027. The actual exception is exception.InvalidMdevDevSpecConfig (rendered as \u0027Invalid Mdev DevSpec config: Invalid mdev device_spec entry: ...\u0027); PciConfigInvalidWhitelist is the PCI passthrough_whitelist error and is never raised for [mdev] device_spec. Additionally the exception is raised from MdevDeviceSpec.from_config_list() inside GenericMdevDriver.discover() during the periodic discovery pass, so the agent starts fine and the error surfaces in the agent log at discovery time.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators diagnosing a malformed device_spec will search agent logs or startup output for \u0027PciConfigInvalidWhitelist\u0027 and find nothing; the real InvalidMdevDevSpecConfig error appears only in the discovery logs of a running agent.\n\n**Suggestion**:\nReplace the example error with \u0027InvalidMdevDevSpecConfig: Invalid Mdev DevSpec config: Invalid mdev device_spec entry: ...\u0027 and reword to \u0027if the agent log shows this error during device discovery\u0027 rather than \u0027if the agent fails to start\u0027.","commit_id":"485a938888ae6a75ca1f76488fba9443d76568f3"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"b8ec106940ee3d3cf66868411cd3a7e4004cb118","unresolved":false,"context_lines":[{"line_number":136,"context_line":"    (``mdev_driver``) and a vendor-specific driver (e.g."},{"line_number":137,"context_line":"    ``nvidia_gpu_driver``) for the same parent device."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"If two drivers discover the same PCI device, the conductor"},{"line_number":140,"context_line":"will raise an error about duplicate devices.  The set-based diff"},{"line_number":141,"context_line":"silently collapses duplicates, but which driver\u0027s resource"},{"line_number":142,"context_line":"classes and traits are used is non-deterministic.  This can"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a8d75aa_5d0cc53e","line":139,"updated":"2026-09-01 10:36:51.000000000","message":"The new \u0027Coexistence with vendor-specific drivers\u0027 section states: \u0027If two drivers discover the same PCI device, the conductor will raise an error about duplicate devices. The set-based diff silently collapses duplicates, but which driver\u0027s resource classes and traits are used is non-deterministic.\u0027 The second and third sentences describe behavior that no longer exists: since commit 1876295 (\u0027Detect duplicate device discovery in conductor\u0027), ConductorManager.report_data calls _check_duplicate_devices() before drv_device_make_diff(), and it raises DuplicateDeviceReported for any cpid_info reported by more than one device. Duplicates therefore never reach the set-based diff, nothing is collapsed, and no non-deterministic resource classes/traits can be used; the entire report is rejected.\n\n**Severity**: WARNING | **Confidence**: 0.9\n\n**Impact**: Operators reading the troubleshooting/coexistence guidance are told the symptom of a driver overlap is silently collapsed duplicates and unpredictable Placement resources, when the actual symptom since 1876295 is a failing agent report_data call with no device data stored for the host. This misdirects diagnosis and contradicts the release note shipped in the same change.\n\n**Suggestion**:\nDelete the \u0027The set-based diff silently collapses duplicates ... scheduling failures.\u0027 sentences and instead state the actual current behavior: the conductor rejects the whole device report by raising DuplicateDeviceReported, the agent\u0027s report_data fails, and no devices for that host are stored until enabled_drivers/device_spec are corrected (matching the release note wording).","commit_id":"6ea921c2b0bc9c69f5bcc0efbf1a5cdea4d4b61d"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2c585702f9ef5c0ccd22bc125ea19ffa7be2eb78","unresolved":false,"context_lines":[{"line_number":136,"context_line":"    (``mdev_driver``) and a vendor-specific driver (e.g."},{"line_number":137,"context_line":"    ``nvidia_gpu_driver``) for the same parent device."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"If two drivers discover the same PCI device, the conductor"},{"line_number":140,"context_line":"will raise an error about duplicate devices.  The set-based diff"},{"line_number":141,"context_line":"silently collapses duplicates, but which driver\u0027s resource"},{"line_number":142,"context_line":"classes and traits are used is non-deterministic.  This can"}],"source_content_type":"text/x-rst","patch_set":18,"id":"388d99fb_9fe45351","line":139,"updated":"2026-09-18 14:59:47.000000000","message":"Right after correctly stating that the conductor raises an error about duplicate devices, the new paragraph says: \u0027The set-based diff silently collapses duplicates, but which driver\u0027s resource classes and traits are used is non-deterministic. This can lead to unexpected Placement resources and scheduling failures.\u0027 This describes the behavior before the duplicate-detection check was added and contradicts the implemented code: _check_duplicate_devices runs first in report_data and raises DuplicateDeviceReported, so drv_device_make_diff never sees a duplicate list and nothing is silently collapsed. It also contradicts the release note edited in this same commit, which says the report is rejected and no device data is stored for the host.\n\n**Severity**: WARNING | **Confidence**: 0.92\n\n**Impact**: Operators debugging a DuplicateDeviceReported error are told that resource classes and traits may still have been non-deterministically reported to Placement, sending them to hunt phantom scheduling inconsistencies instead of recognizing that the entire report is rejected and the host reports nothing until the overlap is fixed.\n\n**Suggestion**:\nDelete the stale sentences and describe the actual outcome: on duplicate discovery the conductor rejects the whole report with DuplicateDeviceReported before diffing or storing anything, so no device data (from either driver) is stored for the host until enabled_drivers/device_spec no longer overlap.","commit_id":"724c07d296c8c07dd0623f70fec807fc78dbc294"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2c585702f9ef5c0ccd22bc125ea19ffa7be2eb78","unresolved":false,"context_lines":[{"line_number":142,"context_line":"classes and traits are used is non-deterministic.  This can"},{"line_number":143,"context_line":"lead to unexpected Placement resources and scheduling failures."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"To avoid overlap when both drivers are enabled on the same host,"},{"line_number":146,"context_line":"use the ``address`` field in ``device_spec`` to restrict the mdev"},{"line_number":147,"context_line":"driver to specific PCI addresses that are not managed by the"},{"line_number":148,"context_line":"vendor driver:"}],"source_content_type":"text/x-rst","patch_set":18,"id":"46f1f6d4_a04bd2f2","line":145,"updated":"2026-09-18 14:59:47.000000000","message":"The new coexistence section tells operators they can enable nvidia_gpu_driver and mdev_driver on the same host and \u0027use the address field in device_spec to restrict the mdev driver to specific PCI addresses that are not managed by the vendor driver\u0027, with an example where mdev_driver manages only \u00270000:07:00.0\u0027. This remedy cannot work: the NVIDIA driver has no address scoping and discovers every NVIDIA GPU on the host (sysinfo._discover_gpus filters lspci output by vendor id and GPU class only), so it also reports 0000:07:00.0. Both drivers build controlpath ids with utils.pci_str_to_json(\u0027\u003caddress\u003e\u0027), producing identical cpid_info, so the conductor\u0027s _check_duplicate_devices raises DuplicateDeviceReported and rejects the whole report every cycle.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: An operator who follows the documented example gets a host where report_data fails permanently: the conductor rejects the combined report, so per the release note \u0027no device data is stored for that host until the conflict is resolved\u0027 - losing reporting for all drivers on the host, including the vendor driver\u0027s GPUs, and starving Placement of accelerator resources. The documentation thus instructs operators into exactly the failure the warning box describes, which is hard to diagnose.\n\n**Suggestion**:\nCorrect the section: state that nvidia_gpu_driver discovers all NVIDIA GPUs on the host and cannot be restricted to a subset, so the two drivers must not be co-enabled for NVIDIA mdev parents; coexistence with a vendor driver is only valid when the mdev driver\u0027s device_spec addresses devices the vendor driver does not claim (e.g. Intel GVT-g parents). Remove or rewrite the \u0027second GPU\u0027 example accordingly.","commit_id":"724c07d296c8c07dd0623f70fec807fc78dbc294"},{"author":{"_account_id":28006,"name":"teim-ci","display_name":"teim-ci","email":"ci@seanmooney.info","username":"ci-sean-mooney","status":"this is a third-party ci account run by sean-k-mooney on irc\nhosted at zuul.teim.app"},"tag":"autogenerated:zuul:automatic-ci","change_message_id":"2c585702f9ef5c0ccd22bc125ea19ffa7be2eb78","unresolved":false,"context_lines":[{"line_number":186,"context_line":"Invalid device_spec JSON"},{"line_number":187,"context_line":"-------------------------"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"If the agent fails to start with an error like::"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"    InvalidMdevDevSpecConfig: Invalid mdev device_spec entry: ..."},{"line_number":192,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"2fa84295_35dbb54b","line":189,"updated":"2026-09-18 14:59:47.000000000","message":"The \u0027Invalid device_spec JSON\u0027 troubleshooting entry says \u0027If the agent fails to start with an error like: InvalidMdevDevSpecConfig: Invalid mdev device_spec entry: ...\u0027. The agent does not fail to start in this case: GenericMdevDriver parses CONF.mdev.device_spec inside discover() (not at driver load, and _initialize_drivers instantiates drivers without parsing config), and discover() is only invoked from the periodic update_usage path. AgentManager.periodic_tasks runs with raise_on_error\u003dFalse, so oslo_service logs the exception and the service keeps running while every discovery/report cycle fails.\n\n**Severity**: WARNING | **Confidence**: 0.85\n\n**Impact**: An operator diagnosing a bad device_spec checks service status, restarts cyborg-agent, or inspects boot/unit logs looking for a failed start, while the actual symptom is a healthy agent whose periodic discovery error repeats in the logs and reports no mdev (or other) resources. The wrong failure mode sends diagnosis down an unproductive path.\n\n**Suggestion**:\nReword to: \u0027If the cyborg-agent log repeatedly shows an error like InvalidMdevDevSpecConfig: Invalid mdev device_spec entry: ... during periodic discovery, the device_spec value is not valid JSON.\u0027 Keep the existing advice about single-line JSON objects and required keys, which is accurate.","commit_id":"724c07d296c8c07dd0623f70fec807fc78dbc294"}]}