PCnet / FAST III

General discussion about Visopsys.
User avatar
andymc
Posts: 589
Joined: Tue Nov 16, 2010 7:20 pm

Re: PCnet / FAST III

Post by andymc »

ronaldlees wrote:I don't know much about Visopsys, and have only taken a few looks at the code. Does the kernel call the loader back, like in RiscOS?
No, once the loader hands off parameters to the kernel via its stack, the loader becomes free memory. It sets up a flat-memory, protected mode environment for the kernel to run in, and then the kernel is on its own.
ronaldlees wrote:When the QEMU window appeared, it displayed the initial loading of Visopsys, and stopped with:

Code: Select all

Detecting hardware: real-time clock (RTC) Error::kernelRtcDriver.c:waitReady(58)
RTC not ready
Detecting hardware: real-time clock (RTC) Error::kernelRtcDriver.c:waitReady(58)
RTC not ready
etc, etc
It's probably something brain dead simple I'm not doing.
It's probably a problem with the RTC code, in fact. I've recently tweaked it a bit for the next release - I was seeing similar error messages in VirtualBox (never on real machines, but these emulators can introduce weird factors) and it's working now. Here's the patch, if you wouldn't mind giving it a try?

Code: Select all

Index: src/kernel/kernelRtcDriver.c
===================================================================
RCS file: /home/andymc/Prog/cvs/visopsys/src/kernel/kernelRtcDriver.c,v
retrieving revision 1.25
diff -u -r1.25 kernelRtcDriver.c
--- src/kernel/kernelRtcDriver.c	29 Jun 2014 15:35:08 -0000	1.25
+++ src/kernel/kernelRtcDriver.c	30 Oct 2014 23:56:43 -0000
@@ -49,10 +49,16 @@
 	unsigned char data = 0x80;
 	int count;
 
-	kernelProcessorOutPort8(0x70, 0x0A);
-	for (count = 0; ((count < 10000) && (data & 0x80)); count ++)
+	for (count = 0; count < 10000; count ++)
+	{
+		kernelProcessorOutPort8(0x70, 0x0A);
+		kernelProcessorDelay();
 		kernelProcessorInPort8(0x71, data);
 
+		if (!(data & 0x80))
+			break;
+	}
+
 	if (data & 0x80)
 	{
 		kernelError(kernel_error, "RTC not ready");
User avatar
ronaldlees
Posts: 120
Joined: Tue May 20, 2014 5:19 pm

Re: PCnet / FAST III

Post by ronaldlees »

Here's the patch, if you wouldn't mind giving it a try?

Code: Select all

Index: src/kernel/kernelRtcDriver.c
===================================================================
RCS file: /home/andymc/Prog/cvs/visopsys/src/kernel/kernelRtcDriver.c,v
retrieving revision 1.25
diff -u -r1.25 kernelRtcDriver.c
--- src/kernel/kernelRtcDriver.c	29 Jun 2014 15:35:08 -0000	1.25
+++ src/kernel/kernelRtcDriver.c	30 Oct 2014 23:56:43 -0000
@@ -49,10 +49,16 @@
 	unsigned char data = 0x80;
 	int count;
 
-	kernelProcessorOutPort8(0x70, 0x0A);
-	for (count = 0; ((count < 10000) && (data & 0x80)); count ++)
+	for (count = 0; count < 10000; count ++)
+	{
+		kernelProcessorOutPort8(0x70, 0x0A);
+		kernelProcessorDelay();
 		kernelProcessorInPort8(0x71, data);
 
+		if (!(data & 0x80))
+			break;
+	}
+
 	if (data & 0x80)
 	{
 		kernelError(kernel_error, "RTC not ready");
Sure. I'll slap it on right after I get back from my (daily) five mile run (gotta keep MY old hardware running :-) )

- Ron
User avatar
ronaldlees
Posts: 120
Joined: Tue May 20, 2014 5:19 pm

Re: PCnet / FAST III

Post by ronaldlees »

Andy:

I got back, walked the dogs, and did the patch.

Good news - the patch allows the installation onto the QEMU virtual drive to continue further. The less good news, is that as the installation continues, it shows messages about having problems detecting the virtual drive.

Maybe I'm not on the same page with the other QEMU users of Visopsys. Just to be certain, I'll check the Qemu version. I'm using:

Code: Select all

qemu -version

QEMU emulator version 1.1.2 (Debian 1.1.2+dfsg-6a+deb7u5), Copyright (c) 2003-2008 Fabrice Bellard
Is that the same version that works for everybody else?
User avatar
ronaldlees
Posts: 120
Joined: Tue May 20, 2014 5:19 pm

Re: PCnet / FAST III

Post by ronaldlees »

Well, I did get what I wanted, and was able to single step the visopsys kernel with QEMU and gdb.

First, I set QEMU to start with "stopped" option:

Code: Select all

qemu-system-i386 -hda ./visopsys1.img -cdrom ./visopsys-2014-12-02.iso -boot d -s -serial stdio -S
Then, in separate terminal, I started gdb:

Code: Select all

gdb ./visopsys
          (loading debug symbols)

(gdb) target remote localhost:1234
(gdb) b identify
   (Breakpoint 1 at 0xc0047a45: file kernelIdeDriver.c, line 1081.)
(gdb) cont
      (Continuing.)

Breakpoint 1, identify (diskNum=diskNum@entry=0, 
    buffer=buffer@entry=0xc00d841c) at kernelIdeDriver.c:1081
1081	{
(gdb) si
I tried to pick a series of good breakpoints, so that I might isolate the issue quicker, which is that the device was not identified. The following is a small snippet of the debugging session. I guess I should study the code to select some good breakpoints for this issue...

Code: Select all

0xc004631b	367							kernelProcessorInPort8(DISK_CHAN(diskNum).ports.altComStat,
369				if (statReg & ATA_STAT_ERR)
0xc0046321	369				if (statReg & ATA_STAT_ERR)
376				if (kernelSysTimerRead() > (startTime + timeout))
kernelSysTimerRead () at kernelSysTimer.c:136
136		if (systemTimer == NULL)
0xc002cf3d	136		if (systemTimer == NULL)
141		if (ops->driverRead == NULL)
0xc002cf49	141		if (ops->driverRead == NULL)
148		timer = ops->driverRead();
0xc0053cc5 in driverRead () at kernelSysTimerDriver.c:71
71	}
driverSetupTimer (counter=-1073454261, mode=-1073257218, count=0)
    at kernelSysTimerDriver.c:115
115	{
0xc0053ccc in driverSetupTimer (counter=-1073257218, mode=0, count=37)
    at kernelSysTimerDriver.c:115
115	{
0xc0053ccd in driverSetupTimer (counter=0, mode=20, count=-1072856236)
    at kernelSysTimerDriver.c:115
115	{
0xc004634b in waitOperationComplete (diskNum=diskNum@entry=0, 
    yield=yield@entry=0, dataWait=dataWait@entry=1, ack=0, timeout=20)
    at kernelIdeDriver.c:376
376				if (kernelSysTimerRead() > (startTime + timeout))
0xc004634e	376				if (kernelSysTimerRead() > (startTime + timeout))
346			if (yield && !DISK_CHAN(diskNum).gotInterrupt)
0xc0046296	346			if (yield && !DISK_CHAN(diskNum).gotInterrupt)
355			if (DISK_CHAN(diskNum).gotInterrupt)
0xc00462bf	355			if (DISK_CHAN(diskNum).gotInterrupt)
367				kernelProcessorInPort8(DISK_CHAN(diskNum).ports.altComStat,
0xc004631c	367				kernelProcessorInPort8(DISK_CHAN(diskNum).ports.altComStat,
369				if (statReg & ATA_STAT_ERR)
0xc0046321	369				if (statReg & ATA_STAT_ERR)
376				if (kernelSysTimerRead() > (startTime + timeout))
kernelSysTimerRead () at kernelSysTimer.c:136
136		if (systemTimer == NULL)
0xc002cf3d	136		if (systemTimer == NULL)
141		if (ops->driverRead == NULL)
0xc002cf44	141		if (ops->driverRead == NULL)
148		timer = ops->driverRead();
0xc0053cc5 in driverRead () at kernelSysTimerDriver.c:71
71	}
driverSetupTimer (counter=-1073454261, mode=-1073257218, count=0)
    at kernelSysTimerDriver.c:115
115	{
0xc0053ccc in driverSetupTimer (counter=-1073257218, mode=0, count=37)
    at kernelSysTimerDriver.c:115
115	{
0xc0053ccd in driverSetupTimer (counter=0, mode=20, count=-1072856236)
    at kernelSysTimerDriver.c:115
115	{
0xc004634b in waitOperationComplete (diskNum=diskNum@entry=0, 
    yield=yield@entry=0, dataWait=dataWait@entry=1, ack=0, timeout=20)
    at kernelIdeDriver.c:376
376				if (kernelSysTimerRead() > (startTime + timeout))
0xc004634e	376				if (kernelSysTimerRead() > (startTime + timeout))
346			if (yield && !DISK_CHAN(diskNum).gotInterrupt)
0xc0046296	346			if (yield && !DISK_CHAN(diskNum).gotInterrupt)
355			if (DISK_CHAN(diskNum).gotInterrupt)
0xc00462bf	355			if (DISK_CHAN(diskNum).gotInterrupt)
367				kernelProcessorInPort8(DISK_CHAN(diskNum).ports.altComStat,
0xc004631c	367				kernelProcessorInPort8(DISK_CHAN(diskNum).ports.altComStat,
369				if (statReg & ATA_STAT_ERR)
0xc0046321	369				if (statReg & ATA_STAT_ERR)
376				if (kernelSysTimerRead() > (startTime + timeout))
kernelSysTimerRead () at kernelSysTimer.c:136
136		if (systemTimer == NULL)
(gdb) quit
A debugging session is active.

Obviously I really need to find some decent breakpoints. Stepping with "n" commands directly in GDB results in ugly output. I'd do better with an IDE here (emacs). But, I'm feeling like I might learn something about your kernel!
Last edited by ronaldlees on Fri Dec 19, 2014 2:00 pm, edited 3 times in total.
User avatar
andymc
Posts: 589
Joined: Tue Nov 16, 2010 7:20 pm

Re: PCnet / FAST III

Post by andymc »

Man, that's so cool. I've never considered doing this stuff. I'm not much of a debugger-user anyway, but sometimes they're the right tool for a tricky problem. I need to try this.

These lines

Code: Select all

driverSetupTimer (counter=-1073454261, mode=-1073257218, count=0)
    at kernelSysTimerDriver.c:115
look screwy, but I think it's just a debugger hiccup. That function is not called when reading the timer. Basically, the code is looping, waiting for an IDE interrupt.

Is this a debug build? (make debug) Do you see any messages like

Code: Select all

		// Just a timeout
		kernelDebugError("Disk %02x no interrupt received - timeout",
			 diskNum);
? You'd only see those in a debug build.

I suspect that the real problem here is the new APIC interrupt controller code, introduced in the most recent release (0.75). Nextvolume posted about problems with the APIC in Qemu http://visopsys.org/forums/viewtopic.php?f=3&t=250. I'm currently trying to debug it in VirtualBox (gah!) and when I get that sorted, I was planning to test in Qemu...

If you want to disable the APIC code and test that, just stick a "return 0;" at the top of the driverDetect() function in kernelApicDriver.c. Then it will fall back to using the old PIC code.
User avatar
ronaldlees
Posts: 120
Joined: Tue May 20, 2014 5:19 pm

Re: PCnet / FAST III

Post by ronaldlees »

andymc wrote: Is this a debug build? (make debug) Do you see any messages like

Code: Select all

		// Just a timeout
		kernelDebugError("Disk %02x no interrupt received - timeout",
			 diskNum);
? You'd only see those in a debug build.
Yes, kernelDebugError() lines were scrolling by all the time. The snippet I selected was pretty random.
andymc wrote: I suspect that the real problem here is the new APIC interrupt controller code, introduced in the most recent release (0.75). Nextvolume posted about problems with the APIC in Qemu http://visopsys.org/forums/viewtopic.php?f=3&t=250. I'm currently trying to debug it in VirtualBox (gah!) and when I get that sorted, I was planning to test in Qemu...

If you want to disable the APIC code and test that, just stick a "return 0;" at the top of the driverDetect() function in kernelApicDriver.c. Then it will fall back to using the old PIC code.
Yes, I'll give your suggestion to drop back to old PIC a go. Probably in the morning tho ...

I just spent about an hour trying to get all of this to run with Eclipse, but so far there seems to be some muckup in the remote debug configuration.

Edit: (twenty minutes later)

- I couldn't stand the suspense, so I made the change you suggested to drop back to "old PIC" mode and recompiled, and now it works. So we can end the day on a high note (other than for the APIC needing something)
User avatar
andymc
Posts: 589
Joined: Tue Nov 16, 2010 7:20 pm

Re: PCnet / FAST III

Post by andymc »

That's good news - thanks for the update. My task is clearly marked out for me in that case.

With the APIC, on VirtualBox, it's a tricky one. I've spent 2 evenings trying to debug it. Identified some tweaks, but no answer yet. Hopefully, whatever the issue is, it'll be the same for Qemu. Ideally I'd be trying Qemu in parallel to compare results, but I had some difficulty getting it installed in my Ubuntu. Perhaps I should try again.
User avatar
andymc
Posts: 589
Joined: Tue Nov 16, 2010 7:20 pm

Re: PCnet / FAST III

Post by andymc »

Hi Ron,

Could you possibly try dropping this version of the APIC driver into your source tree, and see whether it solves the problems you've been seeing with missing interrupts, etc., in Qemu?

I seem to have solved it in VirtualBox, and the error messages were so similar to Qemu, but I've had trouble setting up Qemu on my dev machine. If you and nextvolume think the APIC code is working in Qemu, then I'll feel more confident that I've fixed it.
Attachments
kernelApicDriver.c
(26.76 KiB) Downloaded 894 times
User avatar
andymc
Posts: 589
Joined: Tue Nov 16, 2010 7:20 pm

Re: PCnet / FAST III

Post by andymc »

Alright, I did get Qemu up and running. There are some seemingly-harmless error messages from the RTC driver, but the APIC code seems alright now.

The problem was related to prioritizing multiple interrupts-in-service, for anyone who's interested in that level of detail ;-)
User avatar
ronaldlees
Posts: 120
Joined: Tue May 20, 2014 5:19 pm

Re: PCnet / FAST III

Post by ronaldlees »

andymc wrote:Alright, I did get Qemu up and running. There are some seemingly-harmless error messages from the RTC driver, but the APIC code seems alright now.

The problem was related to prioritizing multiple interrupts-in-service, for anyone who's interested in that level of detail ;-)
Hi Andy:

I've had to do some traveling, and don't currently have access to my dev machine. But, I'll try the new APIC code as soon as I can. I concur with NextVolume that it would be great to have a .76 release with some of the most recent improvements.

Glad you got your QEMU running. I wonder if you've been using GDB on your QEMU instance? I guess you're not that much in favor of interactive debugging, so you likely follow Linus's admonition that interactive debuggers make for sloppier code. I don't think I have that much patience - LOL - so I'd probably decide to go fishing before I'd write an entire application without one!

- Ron
Post Reply