Confirmation of Bug diagnosis sought: Solved
Posted: Sun May 06, 2018 9:41 am
I have been plugging away at my OS in the background and had it installed on its own partition on a hard disk that also contained a Windows and two Linux installations with booting controlled by Grub2. My OS was simply chain loaded by Grub. I recently copied the system to the first (and only) partition of a USB drive and after some tweaking got my machine to boot up from the USB. The OS was booted fine but there was strange behaviour by the volume boot record whose first job was to clear the screen, which it did only partially and not with the requested background colour. Inspection of the vbr code showed a mistakenly loaded byte at 0x7c24 which should have been 0xcd, the start of a bios call to hide the video cursor. Instead, 0x80 was present which was causing an unwanted register load that was clearly preventing the interrupt and which was also spilling over to the following instructions that were setting up the screen clear.
Problem apparently solved - disk corruption. However, inspecting the disk content itself, both in my own OS and using a utility in Windows, consistently showed the relevant byte to be correctly recorded as 0xcd. So the next step was to see if early code in the vbr was corrupting memory - hardly anything was done earlier on: the segment registers and stack were set up, a far jump was done to ensure cs was correctly zero, dl was saved to a memory location and the screen mode was set. Code was the same as for the well-established hard disk version but nevertheless I removed elements individually but without solving the problem.
At this point, inspecting the disk again in a utility Disk Editor on Windows, I noticed that that 0x7c24 corresponded to a location reserved by FAT boot records for a physical disk number - and that my corruption of 0x80 in place of 0xcd fitted well with some machine boot code "helpfully" correcting my vbr to a "valid" value.
This made further sense as on the hard disk this probaby would not occur because by the time my vbr had loaded grub had previously taken control of the boot process whereas on my usb I was depending on the native boot sequence. Anyway, I buried the offending byte location in a pointless register load instruction and sacrificed the cursor hiding interrupt: all problems disappeared.
However, I am conscious that there's quite a bit of supposition in this solution. The machine involved is a Toshiba Satellite Pro and I wondered if anyone had come across anything similar to this, or, indeed, has knowledge that this sort of thing does happen?
Problem apparently solved - disk corruption. However, inspecting the disk content itself, both in my own OS and using a utility in Windows, consistently showed the relevant byte to be correctly recorded as 0xcd. So the next step was to see if early code in the vbr was corrupting memory - hardly anything was done earlier on: the segment registers and stack were set up, a far jump was done to ensure cs was correctly zero, dl was saved to a memory location and the screen mode was set. Code was the same as for the well-established hard disk version but nevertheless I removed elements individually but without solving the problem.
At this point, inspecting the disk again in a utility Disk Editor on Windows, I noticed that that 0x7c24 corresponded to a location reserved by FAT boot records for a physical disk number - and that my corruption of 0x80 in place of 0xcd fitted well with some machine boot code "helpfully" correcting my vbr to a "valid" value.
This made further sense as on the hard disk this probaby would not occur because by the time my vbr had loaded grub had previously taken control of the boot process whereas on my usb I was depending on the native boot sequence. Anyway, I buried the offending byte location in a pointless register load instruction and sacrificed the cursor hiding interrupt: all problems disappeared.
However, I am conscious that there's quite a bit of supposition in this solution. The machine involved is a Toshiba Satellite Pro and I wondered if anyone had come across anything similar to this, or, indeed, has knowledge that this sort of thing does happen?