diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1925496')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1925496 | 140 |
1 files changed, 140 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1925496 b/results/classifier/zero-shot/108/other/1925496 new file mode 100644 index 00000000..eb630483 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1925496 @@ -0,0 +1,140 @@ +other: 0.745 +semantic: 0.720 +debug: 0.705 +KVM: 0.680 +vnc: 0.668 +permissions: 0.667 +PID: 0.657 +device: 0.653 +graphic: 0.652 +socket: 0.630 +files: 0.619 +performance: 0.616 +network: 0.602 +boot: 0.588 + +nvme disk cannot be hotplugged after removal + +Hello, + +When I try to re-add an nvme disk shortly after removing it, I get an error about duplicate ID. + +See the following commands to reproduce. This happens consistently on all VMs that I tested: + + +attach +========== + +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; +$VAR1 = { + 'execute' => 'device_add', + 'arguments' => { + 'serial' => 'nvme1', + 'drive' => 'drive-nvme1', + 'driver' => 'nvme', + 'id' => 'nvme1' + } + }; + + +detach +=========== +$VAR1 = { + 'arguments' => { + 'id' => 'nvme1' + }, + 'execute' => 'device_del' + }; +$VAR1 = { + 'execute' => 'human-monitor-command', + 'arguments' => { + 'command-line' => 'drive_del drive-nvme1' + } + }; + +reattach +=========== +$VAR1 = { + 'arguments' => { + 'command-line' => 'drive_add auto "file=/dev/zvol/rpool/data/vm-20000-disk-1,if=none,id=drive-nvme1,format=raw,cache=none,aio=native,detect-zeroes=on"' + }, + 'execute' => 'human-monitor-command' + }; + + +and I get: +"Duplicate ID 'drive-nvme1' for drive" + +although it does not show up in query-block or query-pci anymore after the first detach. + + +Is this a bug or am I missing something? Please advise. + +Best regards, +Oguz + +Hi, + +What QEMU version is this happening on? Is this the -rc4, is it a regression? + +Hi, + +this is happening on qemu 5.2.0 + +BTW Re: Regression, I think it's not, because this didn't work a year ago either, but I wasn't sure if it's a bug. + +So, I had to investigate this a bit, since it is a part of QEMU that I'm not too familiar with. + +My understanding is that this is the expected behavior. The reason is that the drive cannot be deleted immediately when the device is hot-unplugged, since it might not be safe (other parts of QEMU could be using it, like background block jobs). + +What we *can* do, is make sure we mark the drive for auto deletion when it is safe to do so. I'll add a patch for that. + +On the other hand, the fact that if the drive is removed explicitly through QMP (or in the monitor with drive_del), the drive id is remains "in use". This might be a completely different bug that is unrelated to the nvme device. + +> My understanding is that this is the expected behavior. The reason is that the drive cannot be deleted immediately when the device is hot-unplugged, since it might not be safe (other parts of QEMU could be using it, like background block jobs). + +> On the other hand, the fact that if the drive is removed explicitly through QMP (or in the monitor with drive_del), the drive id is remains "in use". This might be a completely different bug that is unrelated to the nvme device. + +using the same commands I can hot-plug and hot-unplug a scsi disk like this without issue - this behavior only appeared on nvme devices. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know how to transfer the bug to the new system if +(if still necessary). Thus we're setting the status to "Incomplete" now. + +In the unlikely case that the bug has already been fixed in the latest +upstream version of QEMU, then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here should be +moved to the new system, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +This issue has been moved to the new bug tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues/423 + +Thus let's close this version in the Launchpad tracker now. + |