Poet129

No, you mod the K40C bios to identify as the K40T to allow flashing.

@lkamill Glad to hear that it works... I believe this is the third card to work, those being K40M, M40 and now the K40T. The mod itself is quite simple. The K40C V-BIOS works in a 32bit bar motherboard. So just flash that V-BIOS to use instead. However because we are forced to use a NVIDIA tool, we have to bypass / fulfill any checks that it has before flashing. In this case nvflash checks the device id and pci id of the V-BIOS, among other things. So changing these values to the ones from the V-BIOS you gave me allowed it to be flashed. HxD actually has a really useful compare tool. The first two bytes that are different between the K40C V-BIOS and the K40TC V-BIOS mod I gave you resembles those changes. Then signing with Kepler Bios Tweaker changes another two bytes, for a total of four changed bytes. If you don't resign, the NVIDIA driver will error, I've found most commonly code 10, could be different though.

@lkamill Good to see that people are finding use for this little project of mine... As per usual I'll remind you that I can NOT be held liable for any damage, but I'll help as I can. This should work in theory, it is just a modded form of the K40C bios to allow it to be flashed on the K40T in this case instead of the K40M. Then signed with Kepler Bios Tweaker. Would like to know results if at all possible. Thanks. Tesla K40tc Signed.rom

Being dell I wouldn't be surprised if that made a difference... did you save the original v-bios? Was there a power failure? There is no "backup" switch. Maybe try installing the GPU in that older system, it is possible that the K40c v-bios doesn't play nice with 64 bit bar.

I personally don't recommend messing with the H61 Bios (or any motherboard bios)... In terms of the K20m, you have come to the right place. The only thing needed to get the K20m running a K20c vbios is nvflash along with a proper vbios. The only edit you need to make is to change the K20c vbios device id to think it is for the K20m so that nvflash will allow it to be written. Along with resigning with Kepler Bios Tweaker (Not Hard, just resave). I'll load up a K20c vbios when I get the chance and make the necessary changes and I'll post back here with it. Note: I'm not responsible for any bricked hardware but I will help in any way that I can. @ABIT-Wolf Sorry I haven't posted in a while. I have had a lot going on with school recently... I believe your analysis is correct though the two gpus seem to be fighting for the same resources. I do not have my original vbios file I didn't count on it getting messed up on the LTT website, so hopefully it can be restored soon. Is it possible that your motherboard is using a plx chip rather than having the raw pcie lanes... I feel like that could be causing an issue. Have you tried without the display out card and using a remote desktop tool like parsec? This could free up unnecessarily used pcie lanes that could be causing your issue. Note: You will probably have to enable a setting like "Headless mode" in the motherboard bios to get a post without a display card. Good Luck.

AIDA64 is one of the only ones I'm aware of. Perhaps some video games, like Minecraft, but I'm unsure of how much they would benefit from increased BAR space. AIDA64 has a free trial and a portable .zip if you don't feel like installing... the tests are fast enough that cooling shouldn't be a huge issue, but it is best practice to have the same cooling between both cards.

Would be interesting to see a performance comparison between 32 and 64 bit BAR.

You should be able to pull it from the working card.

UEFI should not be required with 32 Bit BAR, the Tesla K40M works without it.

@ABIT-WolfYes, because I didn't change anything else from the Titan-X V-Bios it has all the same clocks and voltages. Should be fine anyway since the Tesla M40 has better cooling. If it becomes unstable though you may want to turn the clocks down with the maxwell II v-bios editor. It is normal for it to still show up as a Tesla M40 and not as a Titan-X, The same happened with the Tesla K40M. Is it working in a non-64bit BAR motherboard now?

Okay, didn't windows have a little better support for different versions though?

Is that the special version of nvflash from that forum?

On Linux it can format any storage device. That being /dev/sdx devices. Python on Windows seems to have trouble working with the \\.\PhsicalDriveX devices. So no raw formats on Windows as of now. As per usual, with better testing, you are correct... Interestingly the writes are still doing better along with the one 16K Read. I'm assuming, even though the cache is now full because of the file size increase, having this user space cache still seems to make a difference. After further testing on my main pc that has much more RAM the results stayed the same as the 64MB results clear upto a 16GB test. Thus it isn't due to gradual slowing of the programming just the cache becoming full. As expected by @Sauron. I didn't mean to claim that SpaceFS was inherently better than NTFS or others as it is not. It just came out that way. Is there a better way I can present my ideas and work without becoming a toss out case of "this isn't going anywhere"? Perhaps better testing methodology is in order. Is there a publically available testing suite for this kind of thing? Google didn't turn much else up, for me anyway. Perhaps I'm not looking in the right places. In this specific case it may have been better to focus on the main point more. This is due to the completely absurd 2MB sector size. Forcing NTFS to fill 2MB per file, while SpaceFS will use only the file size... plus a little overhead for the table this has already been included in the used space. These files are made from the os.urandom function each the size of 1024 Bytes. Other sizes can be used without issue, that was just the number I used. Still not to say that SpaceFS is better than NTFS, The time SpaceFS took to make the files was a quite bit longer than NTFS. And not just because of having more files but also the create file function is slower and seems to get slightly slower as more files exist.

At the moment the only thing I was able to find which was not supported is symlinks as I have not made an implementation for it yet. The file system is still very much a work in progress. Other drives/filesystems can symlink to the filesystem just native symlinks on the drive are not supported yet. Whatever edits made to the files are saved as soon as they are written to the drive. My custom table is only flushed every 60 seconds. So if a file's size changes and the system loses power the data will remain written but the file size will remain unchanged as of the last update to the table. If only one file was being written simply truncating the file to the new size will recover all written data. As for multiple files it would only be possible to know which blocks are going to which file if the files were sequentially truncated in a known order. Which should happen automatically unless multiple trucations of the same file occur within 60 seconds. That 60 MB also includes python, fusepy, etc. Not to nullify any of your points they are excellent questions. I look forward to working on making this more memory efficient and less prone to potential data loss. I will include multiple file count points as to get a better idea the next time I run one of those tests.

I wrote my own filesystem built on the fusepy translation layer. The source code is publically available on GitHub. I've posted speed comparisons as of version 1.3.1. On the left NTFS and on the right my own SpaceFS. Both are formatted with a 2MB Block Size. SpaceFS does support higher block sizes however NTFS does not. It can be run natively on Windows and Linux, I do not have a Mac to test on but it may work there too. Looking at the speed differences might make one wonder about what kind of caching is going on the answer is none. Both tests are performed on virtual drives of the same size on the same drive that being a SATA III SSD. The only external requirement needed is for Windows that being WinFSP. But the speed difference is not the only benefit to using SpaceFS over NTFS. SpaceFS is much more space efficient as well. Using a custom made table to store which bytes are used and not used in sector groups. This means that files are not rounded to the nearest sector like they are on most modern filesystems. RAM usage was roughly 60 MB with 100,000 files stored. I will gladly answer any questions. Feel free to leave your comments and experiences here as well.

@ABIT-WolfOkay flash the original V-Bios and wait for your new board to try with. Perhaps the Titan X has the same requirement...

The device will continue to identify as a Tesla M40, I don't think the versions were the same, most likely not any way.

Has it always been that way?

No the --protectoff does not help any. To fix the edit issue try reflashing the original V-Bios.

The card definitely is not bricked if it still shows up. I think it would work given the proper motherboard. Which could possibly be used to make it work in other not officially supported boards as well with the V-Bios I Modded paired with the Windows version of the Cert Bypass version of nvflash.

That was a different error that we have fixed. With my version neither show and we get a separate cert error instead. Which I'm not sure that we can fix.

Looks good, or rather bad just to verify the M40 shows the error code 12 in device manager?

At the bottom where it has the partitions separated out to each is where you need to right click Disk 1.

Send pic?