[BUG] Kernel memory overwrite attempt detected to SLUB object 'fusion_user_ll_request' #115
Comments
|
This is due to the userspace tools from Fusion-io (fio-sure-erase, fio-format, etc.) which don't know about modern kernels. Since the userspace tools are not open/visible source, we have no way of updating them. The workaround (and I admit it's a pain) is to boot to a lower kernel, run the tools, then boot back into your OS. This is where the whole concept of keeping these cards alive is going to hit a brick wall. My suggestion for folks who are just trying to run some sort of rig to do X, is go back to an older kernel. Unless you need the latest kernel for your project, why go to it? 5.15 is actually EOL before 5.10 as 5.10 is considered more of a long term release. |
|
Ah, good to know. This is kind of a silly project, so I'll just switch to Debian 10 for the OS.
Apparently the Proxmox people are shipping 5.15 on top of Debian 11, which caught me out a bit. I believe Debian 11 is supposed to be based off 5.10, but I didn't really consider the platform as much as I probably should have. |
and Here I am on PVE kernel 6.1 due to my hardware being EPYC and the performance is there for EPYC, I dont have my fio drive in it however, just adding my 2 cents, its an opt-in kernel, might wanna poke the bear if you really wanted to see if your mem issue goes away |
|
The userspace tools are doing things the newer kernels don't like. I doubt that the kernel devs are going to go backwards in security. The expectation is that apps get rewritten. But the userspace tools are not ours to rewrite. |
|
FYI, I got |
|
@bdurrow if you want the "safest" option use CentOS 7 combined with the more or less vanilla driver source branch. For vsl that would be It's not just kernel version dependent, but depends on if the |
|
@snuf , Thank you. You probably just saved me another day of frustration, maybe two. My goal is to roll a bootable iso so that I can use the tools. Do you know of one that already exists? If not I'll see about hosting my work so others can use it in the future. Would you like to link to it if I do that? |
|
@bdurrow we were kicking around the idea of creating one for a while, but it's not manifested itself yet. Probably due to life, the universe and everything. I have most of the bits and pieces to go into it I guess, but keep overthinking it probably. If you have something, and a link I think that would help some folks :) |
Bug description
From the title. I'm trying to recover a ioDrive2 with a missing LEB map:
How to reproduce
Built from the current HEAD: f3a056d using DKMS
The erase then seems to either take a LONG time, or not make any progress (it's still at 0% after about an hour).
Possible solution
No idea
Environment information
Please excuse the host name, I'm trying to redneck a flash-SAN out of (mostly) used bitcoin miner parts (it's cheap!). The name amuses me. FWIW, it's a cheap way to get 5 PCIe 8x slots, particularly when it's $43 with the CPU on ebay.
Yes, there are 2 ioDrives in this system. I'm dealing with
/dev/fct1here.The host OS is actually Proxmox 7.3.
The text was updated successfully, but these errors were encountered: