What's your biggest OSDev frustrating moment?

[Peterbjornx]

As MessiahAndrw suggested, here's a parody of "What's your OSDev AWWWW YEAH! moment?": post your most frustrating moments related to OS development!

Some of mine:
* Discovering a (still unfixed) bug that causes my OS to randomly pagefault about once in every 20 tests (still worrying about having to rewrite lots of my code to be more clean in order to fix this one)

* Realizing that a homebrew graphics library for my compositor was never going to be fast enough and deciding to drag in an external lib

[Rusky]

Saw this somewhere and chuckled:

[martinFTW]

Building GCC, binutils libstdc++, newlib and the other toolchain software is definitly the most frustrating thing by far. You wait it a decade to build and then you almost always have to start from the beginning again.

[Bender]

Saw this somewhere and chuckled:

<image/><phpnerd/>

And also,

[piranha]

A (seemingly random) kernel memory corruption whenever I started and exited nano. Turned out to only occur if I exited nano on a second virtual terminal while the first terminal was scrolling. Many many hours later, it turns out that an old hack I had put in to the tty escape sequences code came back to bite me after I refactored the general console code...It was such a bad hack, I can't believe that I even left it in there.

[Muazzam]

My total frustrating moments > My total ah yeah moments.
Few Frustrating moments are:
1. PS/2 mouse not working but don't know why.
2. Labels after entering protected mode not working but don't know why.
3. Building script not working but don't know why.
4. Bootloader not working but don't know why.
5. CPU triple faulting but don't know why.
and ..............

[SpyderTL]

Honestly?

Spending months trying to find the exact combination of Floppy Controller register flags to poll (when in DMA mode) that would work on VirtualBox, VMware, Bochs, VirtualPC, SimNOW(!), QEMU, M.E.S.S., Tornado64(!), and my HP desktop at work, which, yes, still has a 3 1/4" floppy drive...

(SimNOW was the worst, by far!!)

But I think I finally have a working 32-bit floppy read method that works across all of these. (At least until the next VM I test it on.)

[embryo]

Spending months trying to find the exact combination of Floppy Controller register flags to poll (when in DMA mode) that would work on VirtualBox, VMware, Bochs, VirtualPC, SimNOW(!), QEMU, M.E.S.S., Tornado64(!), and my HP desktop at work

It seems the only working solution is the Microsoft's way of doing things. Just because it is the main test for every emulator. The Microsoft really has power

[Combuster]

I'd guess the fact of polling is wrong when you should be waiting for an interrupt instead - which is either the FDC or the clock in case of timeouts.

[SpyderTL]

I knew someone would say something...

Even when using DMA and interrupts, you still have to check your FDC status registers before you can start reading the result status bytes to check for errors.

Note: if you try to read the result bytes without waiting for RQM to set, then you are likely to always get an incorrect result value of 0. This is also likely to get your driver out of sync with the FDC for input/output.

However, in my case, I don't have much choice, since this is the code that is responsible for loading my interrupt handlers. (I probably should be using PIO mode, though...)

[Owen]

Note: if you try to read the result bytes without waiting for RQM to set, then you are likely to always get an incorrect result value of 0. This is also likely to get your driver out of sync with the FDC for input/output.

However, in my case, I don't have much choice, since this is the code that is responsible for loading my interrupt handlers. (I probably should be using PIO mode, though...)

There are two cases:

• You're loading your kernel, in which case why are you messing with the hardware when you should be leaving this job to the BIOS (or UEFI), which presumably works on your hardware (because you've gotten this far)
• You're writing a driver for your kernel, in which case you should be going for interrupt-driven DMA mode

In other words, whatever you're doing, it's probably wrong.

Cheers,
Not Brendan

[SpyderTL]

I'm loading my Kernel, but I'm already in 32-bit protected mode... So that I can load stuff above 1 MB. And as I said earlier, I probably should be using PIO instead of DMA in the boot loader.

[Octocontrabass]

I'm loading my Kernel, but I'm already in 32-bit protected mode... So that I can load stuff above 1 MB.

This sounds like a perfect job for unreal mode. (I'm assuming you're doing it this way because your kernel is too big to load the whole thing in conventional memory before switching to protected mode and moving it above 1MB.)

[SpyderTL]

I could probably fit it all under 1MB. The whole .ISO is only 528K at the moment. But trying to find space under 1 MB to put the code, interrupt handlers, interrupt tables, descriptor tables, data buffers, memory maps, etc. while avoiding the reserved areas was becoming annoying. Switching to 32-bit before loading any data solved that problem, but it is a bit tricky to get everything in the right order and get it to work on most hardware. All of this will most likely be redesigned when I start redesigning my 64-bit version.

I fear we may have drifted off topic a bit...

[darkinsanity]

I recently worked on my threading-code and discovered that sometimes threads crashed when trying to access their stack. It turned out that I had a bug in my unmap-function which resulted in unmapping one page too much. So, when a thread exited, it's stack got unmapped, and if another stack was directly behind it, it got unmapped too which wasn't very fun for the belonging thread. This took me quite a while to find. Mainly because I didn't think that it would be something so simple and stupid.

Also, I once managed to put pagetables into the video memory.