I'm having a strange problem with timer and IRQ6.

[aladdin]

when i use this code to call timer handler, my fdc driver can't fire irq6 after doing a seek or recalibrate command.
but IRQ6 is fired after sending a reset command.

k_int0:
pushad
push ds
push es
mov ax, DATA_SELECTOR
mov ds, ax
mov es,ax
call timer_handler
mov al,0x20
out 0x20,al
pop es
pop ds
popad
iret

but when i use this code

k_int0:
pushad
push ds
push es
mov ax,DATA_SELECTOR
mov ds, ax
mov es,ax
call timer_handler
mov al,0x20
out 0x20,al
pop es
pop ds
popad
or eax, 0x0800 ; I added only this line to the code
iret

the fdc driver works well, but console output is buggy.
????
i'l become crazy >:(

[Schol-R-LEA]

Just a few things come to my head:

• What led you to try that particular instruction and operands?
• Try to determine just what is really doing it; try using [tt]or ax, 0x800[/tt] (which should have the same effect, since the only bit being set is bit 11), [tt]mov eax, 0x0800[/tt] (which will determine of having the other bits cleared makes a difference) and [tt]mov eax, 0xffffffff[/tt] (which will determine if having them all set makes a difference) and see if they also work, and if they cause any changes.
• Just what is being affected when you set bit 11 in EAX at the end of the interrupt routine? Or is the effect in the program where it returns to, and if so, how is it always interrupting the same point in the program each time?

No real answers, just a bit of thrashing, but I hope that it might help.

[distantvoices]

First, I don't get this relation between irq0 and irq6. Neither of the two should get into the others way.

Second: Never change registers in the isr stubs. They are only supposed to store - restore task states. You see what happens if you alter the contents of eax: as this register contains the return value - according to the c call convention (there may be other conventions which use other registers) - you are very likely to trash your console output and many other things (crucial mallocs f. ex.). So, I suppose you refrain from doing this and search for an other way.

Trace the course of your code with printf's. I'm doing it this way to find logical errors.

Best you show the crucial source code which is causing headache.

[aladdin]

Try to determine just what is really doing it; try using or ax, 0x800 (which should have the same effect, since the only bit being set is bit 11), mov eax, 0x0800 (which will determine of having the other bits cleared makes a difference) and mov eax, 0xffffffff (which will determine if having them all set makes a difference) and see if they also work, and if they cause any changes.

this is what make my problem "strange", when I push/pop eax, i have the problem, when eax change value after irq0 call, everithing works well ???

Trace the course of your code with printf's. I'm doing it this way to find logical errors.

Best you show the crucial source code which is causing headache.

i already did it, the problem hapens just after sending seek command to the fdc (IRQ6 never respond) ???

[BIlazy]

do you activate the fdc-motor prior to issueing "seek"?

[Pype.Clicker]

hah! everything does *not* work well with the "or eax" stuff, since display output is buggy. You're randomly turning bits to 1 in your program, so things *cannot* go correctly. Maybe it just let your driver work correctly because it makes a 0 status be modified into a '1' at some point ...

If i were you, i'd check that you let *both* interrupt enabled at 8259 mask ... But remove that *ugly* eax-mod-in-timer as soon as you can ...

[BI lazy]

And what, if the driver is spinning around some crucial return value you are querying? Say, a time out? Function retrieves the time_out value and suddenly, a value != 0 is returned and it finds that it can continue?

I'd check for polling-some-register-functions.

[aladdin]

after some tests, it seems that everythings works well with a real PC, the problem occures only with bochs.
I think the problem comes from the timer, because i wrote a function that counts from 0 to 10 seconds, and the delay is incorrect :
here is my timer handler

/*initialising timer*/
void set_timer(float freq)
{
unsigned int rate=0;
rate=1193182L/freq;
outb(Timer_cr, 0x36);
outb(Timer_port, LOW_BYTE(((unsigned short)rate)&0xFFFF));
outb(Timer_port, HIGH_BYTE(((unsigned short)rate)&0xFFFF));
}

/*delay function*/
void delay(unsigned int ms)
{
unsigned long int n=ms*FREQ_SYS/4000;
unsigned long int target=tick_count+n;
while(tick_count < target);
}

and in the kernel I do a call to set_timer(100) before interrupts activation.

[Pype.Clicker]

bochs timer is known not to be realtime, except if you explicitly compile it to behave realtime ... But the timer and floppy of bochs should still operate in the same "relative time" ...

[aladdin]

here is my reset function (where the problem occure), seek function and recalibrate function, I added comments on lines where the problem occure.

int fd_recalib()
{
#ifdef FDCDEBUG
printk("FD recalib\n");
#endif

called=0;

fd_cmd(FD_RECALIBRATE);
fd_cmd(0);

while(!called); /* the IRQ6 is never fired here under bochs*/


return 0;
}



int fd_seek(unsigned char trk)
{

#ifdef FDCDEBUG
printk("FD seek...\n");
#endif

called=0;

fd_cmd(FD_SEEK);
fd_cmd(0);
fd_cmd(trk);


while(!called); /*also here the IRQ6 never respond with bochs*/

delay(16);

return 0;
}

void fd_reset()
{
#ifdef FDCDEBUG
printk("FD reset\n");
#endif

called=0;

outb(FD_DOR, 0);
outb(FD_DCR, 0);
outb(FD_DOR, 0x0C);

while(!called); /*waiting for IRQ6 to be fired */
/*this works well*/
outb(FD_DCR, 0);

fd_cmd(FD_SPECIFY);
fd_cmd(0xdf);
fd_cmd(0x02);


fd_seek(1);
fd_recalib();

dchange = 0;
}

can you tell me if there is something wrong in this code :-\

[Pype.Clicker]

without the handler and the declaration of "called", i virtually can't help. Just make sure you declared "called" as "volatile" so that GCC knows that it should expect the value to change even if the code it generated cannot change it.

[aladdin]

here is my declaration of called

static volatile unsigned int called=0;

the interrupt hadler just do called=1;

[Dreamsmith]

I don't see any SENSE_INT_STATUS commands (floppy controller command 0x08) being issued, or any other attempts to read back results from commands sent to the floppy controller. The controller will (under Bochs and on some hardware) stubbornly refuse to generate any more interrupts if you never read back the results from the last one.

[aladdin]

ok i'll try this and inform you if there is any changes
thank you

[aladdin]

thank very much, now it seems that reset works well, new i have a problem with read_sector function but i think it is the same thing