systemofapwne
commented
2 years ago This sounds very interesting. TBH, I always hated the FPU in the kernel workarounds I had to figure out the hard way here (messing up my BTRFS volumes multiple times).
To elaborate a bit regarding the float traps:
- The code correctly uses a check to not use FPU when not usable https://github.com/systemofapwne/leetmouse/blob/306a26c6693b407236a6ea6eef1a52defcabfea2/driver/accel.c#L109
- However, for reasons unknown, FPU sometimes gets screwed up such that FP operations become messy. I check for this here https://github.com/systemofapwne/leetmouse/blob/306a26c6693b407236a6ea6eef1a52defcabfea2/driver/accel.c#L131 which is (so far I can tell over the year of usage) without any severe consequences of data corruptions or crashes. This is the first float trap, which can be triggered from time to time.
- At the end of the acceleration code, there is one more float trap, making sure, that FPU is still working as expected https://github.com/systemofapwne/leetmouse/blob/306a26c6693b407236a6ea6eef1a52defcabfea2/driver/accel.c#L219 I did not expect this ever to be triggered but it looks like, for you, it does.
So I really should consider migrating to fixed point arithmetic. Thank you for also providing a C library here. This really might speed up things. I will give it a look, if I find some time this weekend (I just recently moved and didn't check github).
Cloudperry
serossi
nullprop
I have been using this driver for a couple of days and it has worked great most of the time. However yesterday my ethernet connection went down and I saw these messages in dmesg:
After that I haven't seen these float traps getting triggered much, but I'm not fully confident in this driver not breaking shit randomly. It seems that there have been many attempts at fixing problems caused by using the FPU in a kernel module, but there are still some problems.
Maybe this driver could change the math operations to fixed-point arithmetic to get rid of all the problems that come with using the FPU in kernel code. An alternative driver that uses fixed-point would be fine too. Replacing floats with Q16.16 fixed point numbers (16-bits integer part inc. sign bit, 16-bits decimal part) would probably have enough precision for the purposes of this driver. There are good C libraries for this like libfixmath. That library should be suitable for kernel code as it is made for use on embedded systems. I might look into porting this driver to fixed-point math, when I have the time for it (my only C experience is customising a qmk keyboard).
If you are interested in the precision of fixed-point numbers I did play a bit with them and here are the results (using fpn):
Update: It seems that playing CS:GO triggers the float traps much more often than playing Overwatch. I haven't gotten any more ethernet disconnects for now.