OSDev.org

Hi,

After many moons, I've released a new version of BCOS .

The new version of BCOS can be downloaded from http://bcos.hopto.org/dl.html as a floppy boot image or CD-ROM boot image, or as a utility to boot from DOS.

This version has a lot of new things - too many to mention here (see my project log at http://bcos.hopto.org/log.html if you're interested).

Minimum requirements are still an 80486 with 2 Mb of memory, a VGA video card, and something to boot from (floppy, CD or DOS). It shouldn't be possible for this release to effect anything, unless you choose to set the RTC time within the boot menu.

Even though it's doing PCI and ISA Plug & Play device detection there are still no device drivers. If it works correctly you should be presented with a list of all detected hardware (after this it waits for forever - just reboot).

For Bochs and QEMU it will be very slow. The reason for this is that both of these emulators don't allow the time stamp counter MSR to be set.

Full explanation: During boot I set the TSC to zero, and then measure how fast the CPU/s are with RDTSC (if present) and a fixed time delay. On Bochs/QEMU this measures how many cycles since the emulator was started, instead of how many cycles since the TSC was set to zero. This makes the OS think you've got an incredibly fast CPU. Later on this "cycles per second" measurement is used for time delays during device detection, resulting in very long time delays on Bochs and QEMU. The result is that it may get to "Starting ISA Plug & Play device scan" and take several minutes before continuing.

I'd recommend getting through the boot menu as quickly as possible (ie. press enter before you even get to the boot menu) to minimize this problem. I've hacked my version of Bochs so that the time stamp counter MSR does work correctly and will release a patch for Bochs 2.2 soon.

Anyway, it should work on all real computers - I've tried it on all of mine without problems. All comments, suggestions and bug reports appreciated !


Thanks,

Brendan

Hi,

I tested your OS on my p2 and my 486 laptop.

Dell (workstation@room) (P2):

- intel p2 333 mhz
- 2 HD's: Maxtor 4 gb and an 850 mb quantum hd.
- 64 mb (may change) PC66
- VESA 2.0 compatible video card with 4 MB of memory (it's an ATI 3D Rage Pro AGP 1x)
- a 28x speed cdrom player
- a 1,44" fd
- a 3c90x NIC

Laptop:
- 486 cpu dx2
- 8 mb
- a non working HD, have to figure out one day to get that working...
- normal VGA card

On my P2 it immediatly crashes when it gets to the PCI & ISA scanning mechanism. (it does detect some devices, but then it crashes)

Error:
[tt]Kernel re-entrancy lock
Process: Kernel
Thread: Idle thread #000

CS:EIP: 0x0008:C0007D10
SS:ESP: 0x0010:C9601F88

mark found on line 9 in file:
sched/wake.asm[/tt]

on my 486 it gets thru the PCI & ISA scanner. But IMO it takes very long (it looked like it crashed, but it didn't)
It stops after when it reports that I have a PS/2 mouse (which is correct )

HTH,

DennisCGc.

PS. Nice boot menu

Hi,

Thanks for testing - these are the types of bugs I'm looking for . First, the easy one (the 486 cpu dx2 laptop) then the hard one...


NANOSLEEP

The "ISA Plug & Play" detection code uses a lot of little time delays, which add up to a total of 2408 mS (plus a little overhead) on any computer. These time delays use my "nanosleep" function, which (for short delays on computers without a local APIC or RDTSC) uses PIT channel 2 for timing.

I was configuring this PIT channel to generate a 596.59 KHz square wave (PIT mode 3) and then monitoring the output of the timer using IO port 0x61 bit 5. When I wrote the code I made sure the time delays were accurate on a Pentium IV, and checked that it worked on an 80486DX2-66, but never actually checked that it was accurate on the 486 . On this 486 the ISA Plug & Play detection was taking 4 seconds and I had assumed it was just a slower CPU - I was wrong!

The 596.59 KHz square wave made the timer output change state every 838 nS, which was too fast for the CPU/chipset to keep up with. This resulted in my code skipping timer output state changes, causing longer than intended delays. Depending on the exact timing of the delay code (and how long your chipset makes the CPU wait for an "in al,0x61" instruction) each time delay could have been anything on older computers.

I rewrote/optimized the delay code so that it takes a little less time between sampling the timer output state. Then I tested various timer frequencies with my 80486DX2-66 to find that frequencies higher than 298.295 KHz are unreliable. Based on this I've estimated that a 16 MHz 80486 (the slowest 80486) should handle frequencies lower than 149.1477 KHz and then halved it just to make sure, resulting in a final frequency of 74.573 KHz. IMHO this should be a very conservative setting, as the majority of time is spent within the "in al,0x61" instructions, which would depend on the speed of the chipset rather than the speed of the CPU (and all 80486 chipsets should be relatively similar).


KERNEL RE-ENTRANCY DEADLOCK

This is a strange one. The error itself is generated when the kernel detects that a re-entrancy lock is already locked when a thread is trying to acquire it. For a multi-CPU kernel this is normal and the CPU will wait for another CPU to release the lock before acquiring it. On a single-CPU kernel it's impossible for another CPU to release the lock, so the kernel generates this error (as the lock can't be freed when the CPU is waiting for it).

The re-entrancy lock in question is used to protect the "sleep queue", which is a list of threads that are sleeping. When a thread calls the "sleep" function, interrupts are disabled, the lock is acquired, the thread is inserted into the queue, then the lock is freed and interrupts are restored.

The handler for IRQ 8 (which is started by an interrupt gate - interrupts disabled) calls a routine that checks the sleep queue for threads that should be woken. The routine that wakes threads starts with interrupts disabled, acquires the re-entrancy lock, enables interrupts, removes any threads from the sleep queue, then frees the lock. The lock allows other IRQ handlers to interrupt but prevents thread switches. None of the other IRQ handlers (and none of the routines called by other IRQ handlers) uses the sleep queue lock.

Based on all of that, I can't find any way for the sleep queue lock to be locked twice (either through some quirk of timing, or something failing to release it). It's also (supposed to be) impossible for the scheduler to do a thread switch while the lock is acquired, so the kernel's idle thread shouldn't have been able to run (and even if thread switches were possible, the idle thread is a much lower priority than any thread that could've called the sleep function).

Therefore, the only explanation I can think of at the moment is that some code somewhere is overwriting the memory that contains the re-entrancy lock, and that's why the kernel thinks the re-entrancy lock is locked. Considering that I haven't been able to reproduce this problem, the "overwritten memory" idea doesn't sound too likely to me either (it's more likely I've overlooked some timing/synchronization related bug).

In an attempt to shed more light, I've improved the re-entrancy locking so that it will return an error code (containing the lock state and thread ID for who-ever locked it last), and added code to detect lock corruption. I've also tightened things up within the code that wakes sleeping threads and the code that stops running threads (used when they go to sleep, etc). If it is lock corruption it'll say so, if it's timing/synchronization I might have (hopefully) fixed it or I might have changed the exact timing so that the bug doesn't surface (hopefully not).

[EDIT: I've updated the web site's download page so the old link goes to the new version - http://bcos.hopt.org/dl.html ]


Thanks again,

Brendan

Hi,

I did a retest on my p2 machine. Is it just me or... it works now.. guess it was just being a bad floppy ? Anyway, it's pretty weird. It detected the things well

HTH,

DennisCGc.

Hi,



Thanks! Not sure if I fixed it or not, but I'm glad it's not a memory corruption thing ;D.

I guess hardware detection is one of the main additions for this release - now I can start working on device drivers (I've wanted to throw a keyboard driver into this thing for a long time now ).


Thanks,

Brendan

Hi,

I did a few retests after my second post. It works okay, but I'm getting to see that screen again, but immediatly it goes further (it "flashes" )

Anyway, If you're confused, I'm as well

DennisCGc.

Hi,



Hmmm, are you sure?

Before the lock code jumps to the critical error handler it disables interrupts, and the first thing the critical error handler does is disable interrupts again. It only displays the error after interrupts are disabled, and it always ends with a ".die: hlt; jmp .die".

The only way the CPU could do anything else (after entering the critical error handler) is if the critical error handler causes an exception and the exception handler enables interrupts. All exception handlers will either generate another critical error (which would lead to a triple fault as the kernel stack grows too much) or they fix the cause of the exception and return to the interrupted code. In no case are interrupts enabled by any of them.

There is an alternative though - does the screen flash black without the red "Critical Error" title, etc?

During boot, code accesses the video display memory directly as there's no alternative. Near the end of the kernel setup driver (the last boot stage) the boot log is transferred to the "kernel log" (which runs as a kernel thread), and then "kernel modules" are loaded and started.

These kernel modules are the User Interface, Virtual File System and Device Manager (the device manager would've triggered the earlier re-entrancy problems).

Once the kernel setup driver knows that the User Interface module has been started it tells the kernel log thread to open a connection to the User Interface. From that point on any text data is sent via. messaging to the kernel log thread - the kernel log thread sends a copy of the text data to the User Interface, and the User Interface displays it on the screen.

Now, when the kernel log thread first creates it's connection to the User Interface, the User interface makes the connection "active" and displays it immediately. At this point the kernel log thread hasn't sent any data to the User Interface, so this results in the User Interface displaying a black screen with a grey title (and the words "Kernel Log" in the title).

Just after this the kernel log thread sends a pile of data, which the User Interface will also display immediately. This data looks almost exactly the same as it did during boot, with the only difference being the title. Eventually the user will be able to close the boot log or scroll through it (back to text from the earliest boot code).

Anyway, you should see the message "Initializing kernel log", then the screen will flash black with a grey title, then the text will re-appear (with a few extra lines saying "Initialization complete" and telling you the kernel modules were started).

To make this slower (or easier to determine what's in the flash), use the boot menu to select the the video mode that uses the most video display memory - something using 24 bpp colour would be ideal (it's slower due to alignment problems). The longer it takes the OS to update the screen the better .

It's also possible to remove the "Device Manager" completely - from the boot menu select "List Boot Image Items" and then scroll down until "/sys/bin/devman.bin" is highlighted. Then press 'D' to delete the device manager from the boot image. After this it should still flash black, but it'll be impossible for the device manager to cause any problems .

You can also delete the User Interface module in the same way, so that you don't get that black flash. In this case you shouldn't see anything after the "Initializing kernel log" message because after this point nothing should modify video display memory. The red & blue critical errors will still be displayed though (the kernel does pump these directly into video display memory).


Cheers,

Brendan

Yep, it was the alternative. I was getting to see a black screen and then it immediatly returned to the "normal" screen.

Hi,



That's a relief - I don't mind admitting my kernel has reached the point where I can't be 100% sure of anything!


Thanks,

Brendan

Tested your OS on both my laptop ( pentium) and my primary computer, AMD 2200 something.
Worked fine.

In BOCHS it seems to hang at the device listing.. SmiddyOS ( downloadable via BOS forum as attachment ) on the other hand lists BOCHS devices as Compaq hardware..
Maybe he could give you some hints?

/ Christoffer

Hi,

Thanks for testing!



Does it hang at (or during) the device listing, or during device detection?

On Bochs or QEMU it's likely that it'll get to "Starting ISA Plug & Play device scan" and take a very long time due to incomplete time stamp counter MSR support in Bochs (see my first message for details)...

I downloaded and tried SmiddyOS - scanning through VENDORS.TXT to convert the PCI vendor ID & device ID's into text strings is a nice touch...

Notes for others:
See http://www.pcidatabase.com/ for VENDORS.TXT
See http://bos.asmhackers.net/forum/viewtopic.php?id=52 for SmiddyOS (you have to register before it'll show attachments)


Thanks,

Brendan

@Brendan,

Thanks for the complement...on my rudementary attempt.

I will give your code a go through this evening if I get the opportunity. I may not get to it until this weekend though.

So you are aware, I haven't finalized my approach to PCI yet either and I'm using PCI32 through BIOS32, which may well be the issue, may be not. SolarOS does use ports and it is able to enumerate without error though...

Also, Bochs has a switch in the setup file for either Intel chipset, or not. The not is the Compaq devices, in the Intel chipset you'll get a total of three devices, all Intel.

Hi,



Thanks!



My PCI device detection is reasonably finalized for now. Keeping track of hardware resources and doing resource conflict resolution is something I still need to do (after I've got a keyboard driver and temporary command prompt, so I can interactively view and change settings). I don't trust all BIOS's to do the resource conflict resolution correctly before boot - for e.g. multiple video cards where only the first is enabled/configured by the BIOS.

I'm using direct IO ports instead of the PCI BIOS functions - I only use the PCI BIOS during boot to find out which access mechanism is supported (even though it'll autodetect the mechanism without this). I also need to finish & test the code for PCI mechanism #2 - I can't find a computer that supports it .

As for scanning VENDOR.TXT, it's a good idea but I can't implement it yet. The idea is that a minimal "universal" version of the OS will fit on a 1440 KB floppy, and once it boots it will get other things from much larger storage. This means the installation floppy will need a heap of device drivers, file system code, network protocols, etc. I've already blown 500 KB for the boot code and kernels alone, and I'll be lucky if I can fit enough device drivers, etc on the remaining space. It's better for me if VENDORS.TXT (200 KB) comes from the larger storage later (after these device drivers, etc are running)...

I'm not actually not too sure where it was having problems running on Bochs for Bubach - if it was PCI detection, ISA Plug & Play detection or something else (serial port detection, PS/2 device detection or trouble displaying results, etc). The ISA Plug and Play code always has problems on Bochs and QEMU, but...



Ahhh - I will need to check this out!. I figured the alternative to the Intel PCI chipset was no PCI ::)...

BTW for Bochs 2.2 I'm getting an Intel PCI host controller, Intel PCI to LPC bridge, Intel IDE controller, Intel USB controller and Cirrus Logic video adapter (see http://bcos.hopto.org/screens.html second from top).


Thanks,

Brendan

Just a quick note, since I am at work !

I am in the development stage of a device manager. From you screen shots and your text, it appears you've nearly completed your. It looks great! I haven't worked out the details yet, I am in the research/planning stage of this module of my system. As for conflict resolution, I intend, at this point, to reassign to my needs and not be subserviant to the BIOS setup. But these are details I'm working on currently.

I imagine that the majority of your code size is tied up in your GUI development. This forces your requirements, especially in using the VENDORS.TXT file, as it is relatively huge. This may require you to make your OS use more that one disk for install, use CD-ROM, or something else, in order to facilitate device ID-ing. You can certainly generically identify basics for intial driver loading without the need for VENDORS.TXT (or other database). BTW, I haven't entirely tested my parsing capabilities against VENDORS.TXT, as there are some anomalies within the text that I know I do not capture, they get ignored, for now.

I am not supporting ISA at all...so you may have a point on what may be causing the problem.

Hi,

I must also be quick - must sleep before the grey matter turns brown...

Don't be fooled by the screen shots too much - where it says "Scanning USB bus" it's just a place holder (it does nothing more than determine the relevant specification for the host controller). There's also a major section for ISA cards that don't support Plug & Play, then PCMCIA, cardbus, parallel ports, FDC, ATA, ATAPI, SCSI, etc, etc. When it comes to device detection, the term "nearly completed" is similar to "half way to infinity" .

The exact order of events for resource assignment can be quite tricky (especially if ISA support is in the way). As is my way, I tried to raise a discussion to see if anyone could point out flaws in my methods - see http://www.mega-tokyo.com/forum/index.p ... eadid=7745. Not sure if it'll help, but hopefully it will highlight at least a few of the problems.

Part of my code size problems is that there's currently 6 different kernels in there (between 45 KB and 64 KB each), for different paging modes (with/without PAE) and different CPU configurations (single-CPU/multi-CPU/NUMA). A lot is graphics code, 24 KB for the boot menu but a lot more to support all possible video modes throughout the 4 stage boot - all designed to make it look as close to 80*50 text mode as possible regardless of which bit of code is controlling the video at the time or what colour depth and resolution is in use. Then there's a regional database that's currently 100 Kb (for internationalization). Today it adds up to 575 KB, but that regional database may need to be shifted before long.

As for booting, the OS is intended to be distributed such that a group of computers behave as one. Once one computer is operational the remaining computers will be able to use the distributed file system for that "larger storage". The "ideal" installation method would be to install the OS on the first computer with a boot CD and then use it to create one or more customized boot floppies. The customized boot floppies would be used to boot all other machines, and would only need the boot code, kernels and minimal networking. The first computer might take an hour to configure, but an extra 20 computers might only take 5 minutes each (stick the floppy in, turn the computer on, once it's loaded remove the floppy and move onto the next computer). It's my "Rapid Deployment World Domination" plan - complete automated hardware detection is a requirement.

The overall idea is that I'd be able to walk into your place of business with a CD and a blank floppy, and turn your entire LAN into a fully working distributed cluster while you're at lunch ::).


Cheers,

Brendan