Code: Select all
math_abort: MSDOS compatibility FPU exception
Once upon a time (80386 and older CPUs) the FPU was a seperate chip, which generated IRQ 13 via. the PIC when it got an error. When Intel put the FPU on the same chip as the CPU this became rather dumb - it's much faster and easier to generate an exception instead, and IRQ 13 doesn't work when you've got multiple CPUs.durand wrote:I grep'ed the bochs source code for the log entry and found it in fpu/fpu.cc.
Basically, it looks like the FPU specific flags in your CR0 are set up in a way that bochs doesn't support. In particular, your CR0 NE flag is set to 0. Bochs freaks out when it's set to 0.
Just investigate what bits you're setting and see if it's what you want, etc..
I wasn't doing anything with th FPU before... so I guess both those are the problem.- your OS doesn't initialize the FPU correctly, or the code you're running expects that certain FPU exceptions are disabled in the FPU control register when they aren't.
- your task switch code doesn't save and restore the FPU state correctly
"Sharing" ?? you mean, like running bochs and QEMU at the same time on the same HDD.img file so that you could format/populate it with linux and read it with YourOS?spix wrote: I think I have worked out the problem, you cant share hard drive images between bochs and qemu.
Does that actually fix it?spix wrote: I've fixed the FPU exception, each time an IRQ fires my irq fault handler checks if the FPU has been used and if it has, saves the state. Then it resets the task switch flag in cr0 and so next time it restores via the int 7 device missing fault.
Bochs' handler isn't on steroids, it's set to 18.2 hertz in the given IPS. If your actual IPS is much higher, it'll fire too often. If your handler takes longer than the IPS / clocktime you'll get a stack overflow (oops on that).in qemu this seems to work, adding some printf to the int 7 handler i can see it is getting called when it should. In bochs, it does a similar thing, but bochs' timer seems to be on steroids, so it does the int 7 handler routine a lot more.
What would e2fsck do with floating point? As far as I'm concerned, that's too unreliable in rounding, especially for a bit-level correct thing as a file system.At first I thought, what if e2fsck (the offending program) was in the middle of a floating point operation when the kernel interrupted, and the kernel wanted to do a floating point operation in that interrupt. So I have done some tests, and no that doesn't appear to be the case.
Might it be an exception mapped to the IRQ there? Did you remap IRQs? Could it be that you're receiving exception 13 instead?So, I am no longer getting FPU exceptions, e2fsck thinks it finished with a job well done and marks the filesystem clean. After that the filesystem is almost completely messed up.
Would it be reasonable to assume that the FPU isn't the cause of this problem?
Yes, I started out not doing anything with the FPU and I was getting irq 0x13 causing the message in the topic with bochs. I modified cr0 to give a floating point exception instead of an external IRQ, I also have set the TS bit so that when a floating point operation happens it generates a device not found exception which is where I clear the TS bit and restore the FPU state. Next context change the FPU state is saved and the TS bit is set again. I no longer recieve the IRQs and I have set the FPU exception handler to generate a SIGFPE for the task involved, that should exit the program (or if it has a handler, do that) So yeah, it *seems* to be fixed.Does that actually fix it?
Well it seems to run a lot faster than it should. I recalibrate the timer phase to 100Hz and use the CPU timer to count the time. It's always gains too much time in bochs.Bochs' handler isn't on steroids, it's set to 18.2 hertz in the given IPS. If your actual IPS is much higher, it'll fire too often. If your handler takes longer than the IPS / clocktime you'll get a stack overflow (oops on that).
I have no idea why it wants to use the FPU. My ls command I made uses the FPU to calculate human readable sizes.What would e2fsck do with floating point? As far as I'm concerned, that's too unreliable in rounding, especially for a bit-level correct thing as a file system.
No, I am pretty sure it's not generating IRQ 13, it was doing that at the beginning, as I had the NE bit cleared. Yeah IRQs are remapped.Might it be an exception mapped to the IRQ there? Did you remap IRQs? Could it be that you're receiving exception 13 instead?
Human-readable sizes without FPU:spix wrote:I have no idea why it wants to use the FPU. My ls command I made uses the FPU to calculate human readable sizes.What would e2fsck do with floating point? As far as I'm concerned, that's too unreliable in rounding, especially for a bit-level correct thing as a file system.
Code: Select all
#include <stdio.h>
typedef unsigned long long uint64_t;
// change to 1000 for SI-compatible numbers
#define KILOBYTE 1024
char *human_readable(char *buffer, int n, uint64_t size) {
static char indexes[] = " kMGTPE";
// clean up the interface if you're using this
// assert(n == 10);
int idx = 0;
int cidx = n-1;
while (size > 10*KILOBYTE) { size /= KILOBYTE; idx++; }
buffer[cidx--] = '\0';
buffer[cidx--] = 'B';
if (idx) buffer[cidx--] = indexes[idx];
buffer[cidx--] = ' ';
if (size == 0) {
buffer[cidx--] = '0';
} else {
while (size > 0) {
buffer[cidx--] = '0' + size % 10;
size /= 10;
}
}
return buffer + cidx + 1;
}
void try(uint64_t long_num) {
char buffer[20];
buffer[10] = 0;
printf("%s = %08x %08x\n", human_readable(buffer, 10, long_num), long_num);
}
int main() {
try(239587);
try(4294967296ULL);
try(23507012394780145ULL);
try(1677721600000000000ULL);
try(0);
try(42);
}
Just ffs, assume it does use the FPU. Does e2fsck init its own fpu or does it assume it's inited when it starts up?I'm really not sure what the problem is, I'm just trying to work out what the problem isn't. I don't think it is the FPU as it's no longer generating exceptions, and like you said, what does e2fsck need that for anyway.
Thanks.. the part that uses the FPU is when the human readable size is only 1 digit, then it uses a float, for example 1k would appear 1.0k (or 1.3k or whatever.)Human-readable sizes without FPU:
I don't understand what you mean by this. My understanding is, when you use code that requires floating point arithmetic, gcc compiles in the necessary FPU op-codes, e2fsck is written in C. I understand it is the job of the OS to init the FPU.Just ffs, assume it does use the FPU. Does e2fsck init its own fpu or does it assume it's inited when it starts up?
Yeah my OS does initialize the FPU.Does your OS initialize (FINIT) the FPU before use? I would say it either does or your ls would also have failed. It could be that the default settings for the FPU that GCC assumes is different from your setup.