OSDev.org

linuxyne wrote:Assuming that 'instance' is stored at a linear address 0xa7000, you seem to be confirming (with evidence) that, after irq() wrote 1 to 0xa7010, wait() continued to read 0 from 0xa7010.

linuxyne wrote:* Are there more than one cpus?
* Do wait() and irq() operate within the same virtual address space?

linuxyne wrote:* Any unexpected memory overwrites?

onlyonemac wrote: There is one CPU and both functions have the same address space, yes.

onlyonemac wrote:

linuxyne wrote: * Any unexpected memory overwrites?

No (although I may have missed something). I'm pretty sure that everything I think is allocated somewhere really is allocated, and my stack is not overflowing. I know as a fact that the structure to which "instance" points is allocated, and that nothing else is allocated there.

linuxyne wrote:* Dumping the entire 'instance', inside both irq() and wait(), should show if the discrepancy between their views of it is wider than just a single field.

onlyonemac wrote:

linuxyne wrote:* Dumping the entire 'instance', inside both irq() and wait(), should show if the discrepancy between their views of it is wider than just a single field.

OK so I tried dumping instance->path (and "((instance_data*) data)->path" inside irq6_handler()), which is a pointer to a string and the field directly before instance->irq, and it had the same correct non-zero value in both places. I should try adding a field after instance->irq (currently irq is the last field in struct instance_data) and see what happens with its value... EDIT: Done and it works correctly.

linuxyne wrote:Did you mean to say that the fields surrounding irq are not affected (but irq is, as we already know)?
Or, that after adding an extra field after irq, the rw to the irq field started working as expected?

<somewhere in initialisation routine>

instance->test = 0x01234567;

static void fdc_wait_for_irq()
{
	while (instance->irq == FALSE)
	{
		if (instance->test == 0x89ABCDEF)
		{
			sys_log("FDC: true");
		}

		// wait
	}
}

void irq6_handler(uint8_t interrupt, uint32_t data)
{
	// don't let anyone else attach us as their interrupt handler
	if (interrupt != 0x26)
	{
		return;
	}

	((instance_data*) data)->irq = TRUE;
	((instance_data*) data)->test = 0x89ABCDEF;
}

onlyonemac wrote: Get this: I added a new field, "test", at the end of the structure, and tried writing to it from the irq handler and it worked.

Code: Select all

...

The system log gets flooded with "FDC: true". In other words, the value of instance->test has clearly changed but not instance->irq.

linuxyne wrote:Edit0: Are we sure that the wait() did not actually return (where irq got set to 0 again) and get invoked again, very quickly?
I think not, but the question arose since the activities of wait() and its caller are not visible here.

onlyonemac wrote: . . . the issue is that the second interrupt is not arriving. Whether that's because I'm expecting the FDC to send an interrupt at the wrong time or I haven't acknowledged the previous interrupt correctly I don't know.

onlyonemac wrote:Here's my interrupt dispatcher. It gets called from an assembly wrapper for each interrupt, where the assembly wrapper is the routine pointed to by the IDT.

Code: Select all

void irq_handler(uint32_t irq)
{
	if (interrupt_handler_table[irq] != NULL)
	{
		interrupt_handler_table[irq](irq, interrupt_handler_data_table[irq]);
	}

	if (irq >= 0x20 && irq < 0x30)
	{
		if (irq >= 0x28)
		{
			hardware_outb(0x00A0, 0x20);
		}

		hardware_outb(0x0020, 0x20);
	}
}

interrupt_handler_table and interrupt_handler_data_table store the function pointer and custom data parameter, respectively, for whatever code wants to respond to the interrupt (in this case, the aforementioned irq6_handler() function). irq is passed from the assembly wrapper and is known to be correct.

Does this look OK?

linuxyne wrote:* It may also be a synchronization problem.

linuxyne wrote:* Are interrupts from other devices, such as timer and keyboard, being serviced properly?

linuxyne wrote:* Is wait() being called inside a loop which processes IO? If so, what is the request, for which the driver configured the controller before calling into wait()?

linuxyne wrote:The prevention or channelling of nested interrupts might be in the asm wrapper, I think.

Currently I'm not doing anything to avoid receiving nested interrupts. I can receive a second interrupt while the first one is still being processed. Should I try to avoid this (e.g. cli on entry to the asm wrapper and sti before iret)?