VOGONS


Reply 20 of 25, by DenizOezmen

User metadata
Rank Newbie
Rank
Newbie
vitalm wrote on 2020-04-05, 19:46:

Is it possible to mod BIOS to properly set and report unlocked Klamath as 2x with L2 enabled?

I tried to implement such a modification. Would you have the opportunity to give it a try? (Please note, though: You would really need a recovery procedure. I still don't have access to my P3B-F, so it's a purely theoretical mod. It is very possible that the board won't even post after flashing.)
Uploaded to first post.

Reply 21 of 25, by elcrys

User metadata
Rank Newbie
Rank
Newbie

Hi, today I've been testing my CUBX-E with modified BIOS. Everything works well except POST after cold boot is usually interrupted and BIOS/Advanced section is shown with the red note saying CPU was reinstalled or improper frequency combination set (neither is true). Motherboard is correctly set for JumperFree mode and saving CPU speed (manual or pre-defined) in BIOS doesn't help (battery is good and other settings are saved correctly). This behaviour is the same for both testing processors - Celeron 366 MHz and Pentium III 1.1 GHz. OS is Windows 98 + DOS. Am I doing something wrong? I understand there is some fail-safe feature in BIOS, but how does it work? Thank you.

Reply 22 of 25, by DenizOezmen

User metadata
Rank Newbie
Rank
Newbie
elcrys wrote on 2020-10-17, 15:57:

Hi, today I've been testing my CUBX-E with modified BIOS. Everything works well except POST after cold boot is usually interrupted and BIOS/Advanced section is shown with the red note saying CPU was reinstalled or improper frequency combination set (neither is true). Motherboard is correctly set for JumperFree mode and saving CPU speed (manual or pre-defined) in BIOS doesn't help (battery is good and other settings are saved correctly). This behaviour is the same for both testing processors - Celeron 366 MHz and Pentium III 1.1 GHz. OS is Windows 98 + DOS. Am I doing something wrong? I understand there is some fail-safe feature in BIOS, but how does it work? Thank you.

Hi. That is indeed odd. I don't have a CUBX-E at hand right now, but did some tests on a CUBX, using a Pentium 650 MHz and one at 1.1 GHz (SL5QW; I assume you use the same). Up to now I haven't been able to reproduce the problem.

There are indeed some fail-safes. Some of them (there are probably more) work by storing CPU parameters in CMOS and comparing them to the values actually reported by the CPU during POST. The modified BIOS for the CUBX-E changes one of these to allow for undervolting. (Usually, the BIOS would reset VCore to the default value reported by the CPU if the last value selected in the setup menu was lower than that.)

The phenomenon you describe sounds like it might relate to this change. One interesting thing to note about setting VCore from the setup menu is that the setting is applied relatively late in the startup sequence, notably after the point where the user can enter the setup menu. Up to this point, VCore stays at the same value it had before (in case of a soft reset) or at the CPU default value (in case of booting from a power-off state). (This also means that you cannot reliably see which VCore will be applied when looking at the hardware monitor menu in setup, since it hasn't been applied yet.) This might be somehow related to the problem you are experiencing.

I assume the problem does not occur when using the official BIOS. Have you altered any setting relating to either VCore or the onboard ROMs (Symbios, UltraATA)? (The other changes are mostly of cosmetic nature.)

Reply 23 of 25, by elcrys

User metadata
Rank Newbie
Rank
Newbie

Today I spent a few hours trying to replicate this issue again, but I was unsuccessful. I had CMOS battery removed overnight so I started with a clean slate. My HW test setup includes ISA ESS soundcard, PCI S3 Virge/DX VGA, 1x 256 MB 133 MHz CL2 SD-RAM and Celeron 366 MHz SL35S (I also tried Celeron 900 MHz SL633 and Pentium III 1.1 GHz SL5QW).

Step by step I was modifying BIOS settings to previous state and after every change I did a cold boot to pinpoint the problem. I think I can safely say that BIOS setting itself is not the problem. Originally (yesterday) I didn't do any changes to voltage, I only tried differences between pre-defined and manual CPU setting (always setting nominal values), but the problem was still there. Today I additionally tried to change voltage (undervolt), but the problem didn't appear. However yesterday I did change settings regarding SCSI/Promise UATA controller (pretty much every possible combination) because I was testing compatibility of this controller with SATA/IDE and SD/IDE adapters. This was quite problematic and involved aforementioned settings, resets at various stages and data corruption - it turned out that every adapter I have here is incompatible with the Promise controller. Some work only in Windows, in DOS they corrupt data, some don't work at all. But the controller works with IDE HDD, so it shouldn't be some HW problem of motherboard (apart from compatibility). Today I tried some of the settings combination for this controller, this time without these IDE adapters, and without any problems.

I can only guess that the testing yesterday got the motherboard's fail-safe feature into some kind of loop. When I got this motherboard a few weeks ago I also encountered this problem with interrupted boot (also extensively testing Promise controller), but I thought the fail-safe is triggered by Celeron 366 itself (fail-safe value = nominal value at 66 MHz FSB for this CPU) and using faster CPU will solve the problem. Unfortunately I don't remember what BIOS version I had flashed at that time (I was testing 1007.A, official 1008.004 and your modified version). Today I also wanted to test official BIOS in this regard, but since I am unable to reproduce the issue, it will have to wait 😀. Anyway thank you for your help/explanation and I hope I won't see this issue again.

Reply 24 of 25, by DenizOezmen

User metadata
Rank Newbie
Rank
Newbie

Thanks for the extensive tests!

One of the fail-safe mechanisms includes the detection of an interrupted POST. (The BIOS takes note of ongoing/succesful boots via a CMOS value.) If the system experiences hangs during startup, this might trigger the "... CPU/frequency combination ..." message. The BIOS really doesn't differentiate *why* the boot process did not succeed.

Another thing to note: The modification for the Symbios adapter requires an additional (previously unused) storage bit in CMOS. When flashing the modified BIOS over the stock one, it *might* be advisable to load the default settings and start from there.

Anyway, I hope the isse stays fixed for you.

Reply 25 of 25, by elcrys

User metadata
Rank Newbie
Rank
Newbie

Basically there are two types of warnings. Today I saw only one (excluding boot after swapping CPUs) - as the last resort in attempt to replicate the issue I rebooted computer during POST. Then, as expected, I was welcomed with:

During the last boot-up, your system hung for improper frequency combination. Your system is now working in safe mode. To optimize the system performance and reliability, make sure the frequency combination conforms to the specifications of your CPU, DIMM and other connected devices.

After another cold boot, POST was done without any interruptions, so this wasn't it.

But yesterday it was all about this one:

Since you use a new CPU or reinstall your CPU, the system boots up at the CPU bus frequency of 66MHz to make sure the system can enter setup menu. Now, you can adjust the CPU speed as you wish. If the speed is adjusted too high, the system may hang. Please turn off the system and then restart to set the CPU speed.

Something just got stuck in BIOS. I have to say I messed around also with Symbios setting yesterday but testing today didn't prove anything. Of course, after every flash I load the defaults as per instructions in AFLASH.EXE, maybe the cause was really some weird combination of flashing, crashing and settings.