I'm in the process of developing a driver for the i8254 NIC (an Intel networking chipset). recently I added code to continue development only to find the software failed to operate as expected (the low level components are finished). in the process of testing my code I found that adding innocent code sequences were causing the problem.

after finding a version of the code that worked I started adding test code to see if I could trigger the problem. I first added tests that simply printed data to the screen. when doing so caused the problem I calculated the size of the code that was added and replaced it with a set of NOPs. the problem remained even with the NOPs. assuming the code works how could adding NOPs cause a problem?

before I get into code I need to say a few things about Emulators / VMs: QEMU has bugs so you won't be able to test on that emulator. VirtualBox also has issues with certain devices but it does implement this particular device with the correct choice of Chipset on the System Page (use PIX3). VMware is the preferred VM to test with however its' current version doesn't like MP handling so you might want to use a Single Processor (code that executes on the secondary processors take an abhorrent length of time). I don't have the hardware to verify whether the VMware/VirtualBox handle it correctly.

I'm using FASM v. 1.70.03 on Windows.

the following code is on line 750 of 'ORB.net.asm' in the Mathis Directory of the included file:

this code is of the version meant for VMware (the i8254 with a Device ID of 0x100F). VirtualBox uses a nearly identical code sequence that starts on line 1000 of the same file.

if you try the code you might think nothing is wrong (it's not apparent from the output). An interrupt is forced at the end of the Initialization sequence. if the code executes properly the interrupt happens (remove the NOPs to see it). if the code doesn't execute properly then the interrupt wont happen. there is a set of counters on the top right corner of the screen. the first should be something like 100. the second is the number of interrupts that have occurred since boot (this will change very quickly [roughly 100 per second]). the third is the number of seconds since boot. the 4th is the number of megabytes remaining to user code. the 5th is the Network Packet Counter. if the code works it'll be 1 shortly after boot. with VirtualBox it will likely be 2 after 5 seconds.

your screen will vary depending on what devices and the number of processors that are available.

-Stefan

The forum you posted in suggests you think there is a bug with fasm. But your explanation gives no insight about what you think is wrong.

Are you suggesting there is a bug with fasm or are you requesting help with your driver?

revolution: I'm not looking for help developing the driver. I have more than a 100 templates that use the same macros as the template I'm talking about. if something was wrong with my code I think it would have shown itself elsewhere.

If you think there is a bug with fasm's output binary then I think the way to find it would be to disassemble and compare the output to the source to find the discrepancy.

comparing the binaries is a nice idea but it looks like the issue is only triggered by adding a certain amount of data. it can be triggered elsewhere.

If you have a binary output that you know is not working then you should be able to identify the instruction(s) that is failing to assemble correctly by comparing the source lines in the .asm file to the disassembled binary file.

it's not just a matter of the instructions. I'm also using FASM to generate numeric values for the runtime system to process. disassembling it is meaningless if the data generated is bad.

the templates, by the way, are actually very difficult to disassemble since there are no jump/call instruction that lead to them directly. the runtime software performs "copy and paste" style operations using only the templates the PCI Enumerator tells it are needed then patches the code by using the constants FASM generated and attached to the template (in the header).

Templar is a 2 pass Template Engine. the first pass involves copying the templates to dynamically allocated memory and patching the first ".init" so that it'll record the differential to the last ".init" of the previously copied template. once the first pass is done it starts on the last ".init" of the last template and patches each instruction within the runtime copy of the code.

once the code is copied it prints the output information (such as the time it took, the number of bytes the code occupies and the name of the code) then calls (using a call reg) the Initialization code (which was one of the templates).

The process I've just described works for over 100 other templates in the rest of the Operating System. I honestly don't know what is actually wrong with the code I simply know that adding innocent NOPs (or other innocent code) triggers it.

Maybe using the PREPSRC.INC tool can help you identify the problem.

does that include need to be included in my source file?

I've read the README in the TOOLS directory and it says to execute "listing" but there are no executable files with that name.

IIRC you have to assemble to tool manually. I forget how now and I'm not currently at my dev machine so I can't say for sure. Perhaps another reader can post the details.

There are no details:

JohnFound: let me guess; you typed that up off hand.

edit: types->typed

If you can get an .exe ready for PREPSRC then feed it the .fas file.

yeah. I just did. it's interesting to look at the code expanded (atleast that is what it looks like) but it's incredibly difficult to read it with the formatting.

Maybe there is a problem in your macro.
Depending on data size, parameters or special characters/values ?

shutdownall: you really think I didn't consider that?

shutdownall: I first encountered this bug almost a week ago and only came here after enumerating all of the macros used repeatedly.