2
0
mirror of https://git.missingno.dev/kolibrios-nvme-driver/ synced 2024-09-19 01:51:03 +02:00

Running Loaddrv Manually Doesn't Work On VMWare #2

Closed
opened 2024-08-03 19:03:30 +02:00 by ramenu · 13 comments
Member

Crashes on VMWare according to @Burer and garbage values are being read on QEMU

Crashes on VMWare according to @Burer and garbage values are being read on QEMU
ramenu self-assigned this 2024-08-03 19:03:30 +02:00
Author
Member

NVM, so the QEMU issue was just related to me not having the NVMe device attached to QEMU (I'm an idiot...)

Regardless I've added a new patch to prevent the driver from loading if it fails to find any NVMe devices.

NVM, so the QEMU issue was just related to me not having the NVMe device attached to QEMU (I'm an idiot...) Regardless I've added a new patch to prevent the driver from loading if it fails to find any NVMe devices.

Yes, just to be clear. I added NVMe driver (version for 02.04.2024 from forum, I believe) loading to the AUTORUN.DAT, and got just the same results - system froze after a 1–2 seconds after loading a desktop, just when loading a NVMe driver itself, I suppose.

Yes, just to be clear. I added NVMe driver (version for 02.04.2024 from forum, I believe) loading to the AUTORUN.DAT, and got just the same results - system froze after a 1–2 seconds after loading a desktop, just when loading a NVMe driver itself, I suppose.
Author
Member

Yes, just to be clear. I added NVMe driver (version for 02.04.2024 from forum, I believe) loading to the AUTORUN.DAT, and got just the same results - system froze after a 1–2 seconds after loading a desktop, just when loading a NVMe driver itself, I suppose.

Thank you. Honestly at this point I'm thinking of including the image directly into the Git repository, just to make life easier for testers. Is that a good idea?

EDIT: I've added it in, at least for now. Please try using the latest image. It takes a little while for Gitea to sync the repos so you can pull the changes from here: https://codeberg.org/ramenu/kolibrios-nvme-driver

Also, the old image is not good for testing since it does all sorts of crazy dumb stuff.

> Yes, just to be clear. I added NVMe driver (version for 02.04.2024 from forum, I believe) loading to the AUTORUN.DAT, and got just the same results - system froze after a 1–2 seconds after loading a desktop, just when loading a NVMe driver itself, I suppose. Thank you. Honestly at this point I'm thinking of including the image directly into the Git repository, just to make life easier for testers. Is that a good idea? EDIT: I've added it in, at least for now. Please try using the latest image. It takes a little while for Gitea to sync the repos so you can pull the changes from here: https://codeberg.org/ramenu/kolibrios-nvme-driver Also, the old image is not good for testing since it does all sorts of crazy dumb stuff.

EDIT: I've added it in, at least for now. Please try using the latest image. It takes a little while for Gitea to sync the repos so you can pull the changes from here: https://codeberg.org/ramenu/kolibrios-nvme-driver

Yep, this is just a great idea, and thank you very much for adding it. Will make testing process much easier, at least for me.
I tested latest image both in VirtualBox and VMWare, will write results into #1 discussion now.

> EDIT: I've added it in, at least for now. Please try using the latest image. It takes a little while for Gitea to sync the repos so you can pull the changes from here: https://codeberg.org/ramenu/kolibrios-nvme-driver Yep, this is just a great idea, and thank you very much for adding it. Will make testing process much easier, at least for me. I tested latest image both in VirtualBox and VMWare, will write results into #1 discussion now.

UPD. Loading driver manually works fine now, at least for me in VirtualBox.
But if loading driver multiple times, it loads connected devices multiple times, duplicating them and messing up all drive content.

UPD. Loading driver manually works fine now, at least for me in VirtualBox. But if loading driver multiple times, it loads connected devices multiple times, duplicating them and messing up all drive content.
ramenu changed title from Running Loaddrv Manually Doesn't Work to Running Loaddrv Manually Doesn't Work On VMWare 2024-08-09 16:11:35 +02:00
Author
Member

UPD. Loading driver manually works fine now, at least for me in VirtualBox.
But if loading driver multiple times, it loads connected devices multiple times, duplicating them and messing up all drive content.

Ah! I didn't think of this when writing the driver. Indeed, there's no check to see if the device has already been initialized. Will add a fix for this today. Thanks as always @Burer :)

> UPD. Loading driver manually works fine now, at least for me in VirtualBox. > But if loading driver multiple times, it loads connected devices multiple times, duplicating them and messing up all drive content. Ah! I didn't think of this when writing the driver. Indeed, there's no check to see if the device has already been initialized. Will add a fix for this today. Thanks as always @Burer :)

@ramenu, you are always welcome, and of course, will be waiting for that! :)

UPD. Sometimes NVMe drive doesn't appear in Eolite after driver was successfully loaded, but appear normally after Eolite restart.
It is pretty random, and I suppose, that it is Eolite problem, but decided to write about it here just in case.

UPD. I also tried to load NVMe driver manually in VMWare, as this issue title states, and it failed to load for some reason, so this issue is still actual.

@ramenu, you are always welcome, and of course, will be waiting for that! :) UPD. Sometimes NVMe drive doesn't appear in Eolite after driver was successfully loaded, but appear normally after Eolite restart. It is pretty random, and I suppose, that it is Eolite problem, but decided to write about it here just in case. UPD. I also tried to load NVMe driver manually in VMWare, as this issue title states, and it failed to load for some reason, so this issue is still actual.
Author
Member

Fixed in daa8ad4a62 :)

EDIT: Running LOADDRV more than once is fixed, working on the other problems.

Fixed in https://git.kolibrios.org/GSoC/kolibrios-nvme-driver/commit/daa8ad4a627baff150afbab0740102bfb3838317 :) EDIT: Running LOADDRV more than once is fixed, working on the other problems.

Update with commit 0f24000b9a, now both automatic and manual load of driver in NVMe seems to be broken.
Good news - now it doesn't hang up the whole system, just doesn't load driver.

Update with commit 0f24000b9a, now both automatic and manual load of driver in NVMe seems to be broken. Good news - now it doesn't hang up the whole system, just doesn't load driver.
Author
Member

@Burer, Oh.. well so the problem is the driver uses 256 queue entries. But VMWare only has 255. I'll add in a fix for lowering the queue requirement later.

This is not a bug in the driver, just one of the checks didn't pass the requirements in initialization.

@Burer, Oh.. well so the problem is the driver uses 256 queue entries. But VMWare only has 255. I'll add in a fix for lowering the queue requirement later. This is not a bug in the driver, just one of the checks didn't pass the requirements in initialization.
Author
Member

@Burer, I've lowered this number to 64 in the newer commits, please test now. Thank you.

@Burer, I've lowered this number to 64 in the newer commits, please test now. Thank you.

@ramenu, in current commit, a734080cf8, kolibri.img seems to be last updated two days ago. Do I need to test it, or some other image?

@ramenu, in current commit, a734080cf8, **kolibri.img** seems to be last updated two days ago. Do I need to test it, or some other image?
Author
Member

@Burer Oops, my bad. Updated the image. Try now.

@Burer Oops, my bad. Updated the image. Try now.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: GSoC/kolibrios-nvme-driver#2
No description provided.