Page 2 of 2

Re: Testing request

Posted: Tue Oct 14, 2014 12:07 pm
by andymc
Cheers Ron,

There's something there that caught my eye. Do you know whether there's a slave drive on the primary channel?

Right after the line

Code: Select all

DEBUG IDE try to detect disk 0:1
there's a line

Code: Select all

DEBUG IDE disk 01 driverDetect:2899 expect interrupt
In the code comments I noted that some controllers fire an interrupt if you try to 'select' a nonexistent slave, but I'm not doing any acknowledgement of the interrupt if it comes (in this case, it does come). Then, when I send the 'identify' command, that unacknowledged previous interrupt fools the

Code: Select all

DEBUG IDE disk 01 wait (poll) for interrupt 14 ack=0
code into thinking the command completed, but the 'real' interrupt hasn't arrived. Note how the sequence is slightly different, interrupt-wise, for the master and the slave. If there's no drive there, it should time out instead (or I should skip it altogether, if the controller's trying to tell me it's not there, with that interrupt).

I'll need to check the code that issues the 'identify' command for robustness, so that it doesn't crash if there's no/bogus data in the buffer (bug #1 - the actual crash), and hopefully adding an interrupt acknowledgement will stop the polling code from being fooled (bug #2) by that extra interrupt.

Re: Testing request

Posted: Tue Oct 14, 2014 4:13 pm
by ronaldlees
Exactly what caught my eye!

My setup is:

Code: Select all

Primary master:       Seagate hard drive
Primary slave:          None
Secondary master:      LiteOn CD drive
Secondary slave:      None
Maybe we're making some progress!

Re: Testing request

Posted: Tue Oct 14, 2014 4:17 pm
by ronaldlees
Here is the NOAPIC run:

Code: Select all

Detecting hardware: IDE disk controller
warning::kernelIdeDriver.c:waitOperationComplete(395):
Disk 02 no interrupt received - timeout
warning::kernelIdeDriver.c:identify(1201): unknown error
Detecting hardware: PS/2 mouse warning::kernelPS2MouseDriver.c:command(352):
Not resending reset (no PS2 mouse?)
Error: kernelprocess::kernelDisk.c:identifyBootCd(1994):
The boot CD could not be identified
Error: kernelprocess::kernelInitialize.c:kernelInitialize(363):
Disk functions initialization failed
Error: kernelprocess::kernelMain.c:kernelMain(77):
Initialization failed
Press any key to reboot ...

Re: Testing request

Posted: Tue Oct 14, 2014 4:22 pm
by ronaldlees
Andy:

By the way - I have both USB (Microsoft) and PS/2 mouse plugged in.

Edit: But - now looking at the FreeBSD dmesg, I see it doesn't see the PS/2 mouse either. So, maybe a bad mouse. I usually use the MS USB mouse.

- Ron

Re: Testing request

Posted: Tue Oct 14, 2014 5:31 pm
by andymc
Yes, I think we're gonna fix this one. Judging from that code comment I mentioned, it's likely that I have a test system at home that fires these same 'no slave' interrupts. I'd like to see if I can find it and try out my changes before I upload a new version for you, probably in a few hours - is that OK?

The 'no APIC' version I gave you doesn't have IDE debugging turned on :doh:. It does seem likely that the same unacknowledged interrupt is preventing your CD-ROM on the second channel from being identified.

The APIC being enabled/disabled makes some difference to the timing. Seems like APICs are faster than the old PICs, and they showed up a handful of race conditions in my drivers. That's probably why the APIC version crashes, even though both versions really suffer from the same bug.

Re: Testing request

Posted: Tue Oct 14, 2014 8:47 pm
by ronaldlees
andymc wrote:Yes, I think we're gonna fix this one. Judging from that code comment I mentioned, it's likely that I have a test system at home that fires these same 'no slave' interrupts. I'd like to see if I can find it and try out my changes before I upload a new version for you, probably in a few hours - is that OK?

The 'no APIC' version I gave you doesn't have IDE debugging turned on :doh:. It does seem likely that the same unacknowledged interrupt is preventing your CD-ROM on the second channel from being identified.

The APIC being enabled/disabled makes some difference to the timing. Seems like APICs are faster than the old PICs, and they showed up a handful of race conditions in my drivers. That's probably why the APIC version crashes, even though both versions really suffer from the same bug.
Andy: the 'noapic' version basically seems to confirm the suspicion induced by the 'idedebug' run. Sure - if you have time to create another ISO - I'll test it.

Re: Testing request

Posted: Wed Oct 15, 2014 2:12 am
by andymc
I've tried out all my workstations, and my test laptops here, and couldn't find one that does that interrupt (although I discovered that a couple of the latter batch have gone to the great 'lap' in the sky since the last time I started them).

I've tried to fix things up for your system, and tuned a couple of other bits as well, so hopefully this will work better now:
http://visopsys.org/files/visopsys/viso ... ix-iso.zip
http://visopsys.org/files/visopsys/viso ... sb-img.zip

Thanks Ron,
Andy

Re: Testing request

Posted: Wed Oct 15, 2014 2:35 am
by ronaldlees
Hmmm. In terms of interrupt handling I might have the exceptional system. Anyway, in the morning I'll give the new ISO a go. I have a feeling it'll work. Thanks Andy!

BTW: I'm really impressed by this OS project. Out of hundreds of projects that have been started to build the "next big OS" - only a handful have reached the maturity level of this one (not including the Linux/Unix knockoff type of system). And - of the handful that are on the level of this one, I can think of only two that are primarily the efforts of a single person. So - hat's off to ya!


- Ron