PCnet / FAST III

[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

[ronaldlees]

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

[andymc]

Cheers Ron,

I posted a link to a pre-release ISO image in that other thread http://visopsys.org/forums/viewtopic.ph ... 1116#p1116

I haven't tried your debugging technique yet. I'm not against interactive debuggers at all, but the "printing stuff out" method works well for me in most cases - at least when I know the code well enough, and know roughly where to look. When it's unfamiliar code, or it's some tricky multi-threading scenario, then stepping is often the right way to identify problem areas.

[ronaldlees]

Hello again Andy:

Well, I downloaded the ISO image from the link in your message (above), and it works fine with my QEMU version 1.1.2, running on Debian Wheezy (7.5).

Edit:
It looks like there are some intermittent issues, found on a second run. The system sometimes hangs as it did before.

[ronaldlees]

This post was redundant with a following one. (should be deleted)

[ronaldlees]

Andy:

IMO Visopsys runs pretty well without the APIC enabled. With APIC enabled, I don't get the same result every time. It seems to be a little varied as to what will happen. I'm not familiar enough with visopsys at this time to make any intelligent guesses as to cause. Working on it though!

BTW: I looked at the kernel in the 2014-12-13-debug ISO, and it doesn't have debug info. Well - at least gdb doesn't think so. . I think your debug target may not be inserting the "-g". Anyway, I've been loading debug info from an older kernel that I compiled, which may explain some of the misalignments seen in the debugging sessions.

I wonder if you've ever considered a Trac bug page? It might be a better place to put overly long diagnostic text runs.

[ronaldlees]

I've observed that single stepping the kernel, you'll often invoke an artificial timeout. During one run, the visopsys screen had:

Code: Select all

Visopsys 0.75
Copyright (C) 1998-2014 J. Andrew McLaughlin
Starting, one moment please ...
Detecting hardware: real time clock Error::kernelRtcDriver.c:waitOperationComplete(395):
Disk 01 no interrupt received - timeout

I had set a breakpoint, and caused the time-out. Then, when I resumed, I observed the following call graph as I continued:

Code: Select all

0xc0024f0e in kernelMultitaskerGetProcesses (buffer=0xc002084e, buffSize=2014)
    at kernelMultitasker.c:2398
2398	}
(gdb) n
kernelMultitaskerGetCurrentProcessId () at kernelMultitasker.c:2402
2402	{
(gdb) n
flushLogStream () at kernelLog.c:57
57		status = kernelLockGet(&logLock);
(gdb) n
58		if (status < 0)
(gdb) n
pushBytes (theStream=0xc009017c, number=61, 
    buffer=0xc00d6d28 "Dec 16 20:12:17 2014 Disk 03 no interrupt received - timeout\n") at kernelStream.c:282
282		if ((theStream == NULL) || (buffer == NULL))
(gdb) n
kernelLockGet (getLock=0xc009017c) at kernelLock.c:126
126				return (status = ERR_BUSY);
(gdb) n

[ronaldlees]

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

Andy: The "prioritizing multiple interrupt..." and very related topics are covered in pretty decent detail in this link:

http://developer.novell.com/devres/lang ... mpmemo.htm

The authors indicate that often times interrupt service and driver routines for devices must be modified to switch from PIC to APIC (excuse my lack of experience with this). Did you find it necessary to change much? The document is a little old, so maybe some of the described issues have been resolved in hardware by now.

[andymc]

Thanks Ron. It's pretty hard to make sense of this, I think maybe because your sources won't match up with the binary download I gave you (usually, I'm not keen on releasing sources before things are stable and ready for release).

Can you tell me what command line you've been using with Qemu to reproduce these hangs?

The Visopsys kernel doesn't switch between PIC and APIC. That's called mixed mode, and it's generally considered to be a bad idea (or at least, a pain in the backside).

http://developer.novell.com/devres/lang ... mpmemo.htm

This seems like a good overview of things. I'll read through it to make sure I haven't missed anything obvious, but at this stage I think I understand the APIC pretty well

[ronaldlees]

Andy:

On FreeBSD10 with qemu, Visopsys is working pretty well. In fact, I'm having trouble making it break.

Here's the qemu line:

Code: Select all

qemu -hda ./visopsys1.img -cdrom ./visopsys-2014-12-13.iso -boot d -s -serial stdio -S