USB-related problems with i440bx chipset in Windows 98

[Vort]

After Windows 98 SE successfully installed with chipset=i440bx, it hangs during desktop loading.
When rebooted, it starts fine, but refuses to start Intel 82371AB/EB PCI to USB Universal Host Controller:

Windows stopped responding while attempting to start this device, and therefore will never attempt to start this device again (Code 11.)

In cases when Windows 98 SE was installed with chipset=i440fx and then switched to chipset=i440bx, it tries to install driver for the same controller and then BSODs:

Related discussion: #447.

Version: 035f0bf

[luibgn]

But I don't think that this is a bug. Probably the i440bx and agp stuff is still a work in progress.

[fysnet]

After Windows 98 SE successfully installed with chipset=i440bx, it hangs during desktop loading. When rebooted, it starts fine, but refuses to start Intel 82371AB/EB PCI to USB Universal Host Controller:

I remember once working on this exact issue, but can't remember the outcome. I will investigate.

In cases when Windows 98 SE was installed with chipset=i440fx and then switched to chipset=i440bx, ...

As far as this is concerned, in my opinion, there is no need to worry here, because in theory you should not change the chipset without re-installing all effected software. i.e.: Most likely, you will (nearly) never switch out a mobo with a different chipset without re-installing the OS.

[fysnet]

After some research and trial and error, I believe this issue is the cause of two items.

First, as you have stated before, I think the AGP has something to do with this.
At the following line,

Bochs/bochs/iodev/pci.cc

Line 87 in b348432

if (DEV_agp_present()) {

I commented it out to return FALSE so that the 0x8086:0x7192 was used instead (Line 101). The 0x7192 is a very similar chipset except the AGP is disabled.

I was able to get Win98 to boot almost exactly as you mentioned, except instead

Windows stopped responding while attempting to start this device, and therefore will never attempt to start this device again

now it states that the PIR is bad, which brings us to the second reason it doesn't work.

Bochs/bochs/bios/rombios32.c

Lines 791 to 805 in b348432

	BX_INFO("Modify pir_table at: 0x%08lx\n", addr);
	writeb(pir + 0x09, 0x38); // IRQ router DevFunc
	writeb(pir + 0x1f, 0x07); // Checksum
	writeb(pir + 0x21, 0x38); // 1st entry: PCI2ISA
	writeb(pir + 0x31, 0x40); // 2nd entry: 1st slot
	writeb(pir + 0x41, 0x48); // 3rd entry: 2nd slot
	writeb(pir + 0x51, 0x50); // 4th entry: 3rd slot
	writeb(pir + 0x61, 0x58); // 5th entry: 4th slot
	if (device_id == PCI_DEVICE_ID_INTEL_82443) {
	writeb(pir + 0x70, 0x01); // 6th entry: AGP bus
	writeb(pir + 0x71, 0x00); // 6th entry: AGP slot
	pci_config_writeb(d, 0xb4, 0x30); /* AGP aperture size 64 MB */
	} else {
	writeb(pir + 0x71, 0x60); // 6th entry: 5th slot
	}

The 0x07 in line 93 should be 0xE7. Also, if we are the 82443 (which is the 0x7190), it needs another CRC value, so add:

        if (device_id == PCI_DEVICE_ID_INTEL_82443) {
          writeb(pir + 0x70, 0x01); // 6th entry: AGP bus
          writeb(pir + 0x71, 0x00); // 6th entry: AGP slot
          pci_config_writeb(d, 0xb4, 0x30); /* AGP aperture size 64 MB */
+         writeb(pir + 0x1f, 0x46); // Checksum
        } else {

Or even better yet, remove line 793 and add after line 805, something like this:

         writeb(pir + 0x1f, 0x00);
         writeb(pir + 0x1f, calculate_crc(addr, readw(pir + 0x06));

so that the values can be changed on the fly without worrying about the crc.

I didn't take the time to re-install Windows again to verify the fix, but if you make sure DEV_agp_present() returns false and fix the CRC in the PIR table in the BIOS, I believe it will boot and allow the USB to work.

On a side note, I tried my BIOS and Win98 posted:

While initializing device CONFIGMG:
Windows protection error. You need to restart your computer.

This particular error is mentioned by an older Microsoft website that something is wrong with the AGP initialization.

If you have the time, please make the two fixes I mention above, do a clean install, and see if it works this time.

Either way, I would close this issue until the AGP can be worked on.

[Vort]

I commented it out to return FALSE

No need to disable AGP with hacks, when it can be done by specifying , advopts=noagp in .bxrc file.

now it states that the PIR is bad, which brings us to the second reason it doesn't work.

In my case, lots of devices got yellow exclamation marks and code 31 because of ACPI IRQ device with code 10.

The 0x07 in line 93 should be 0xE7. Also, if we are the 82443 (which is the 0x7190), it needs another CRC value

Such changes made no difference in my tests.

Either way, I would close this issue until the AGP can be worked on.

Issues are closed when problems are solved.
If problem with 82371AB/EB depends on problem with 82443, then separate issue can be created and linked here.

[fysnet]

No need to disable AGP with hacks, when it can be done by specifying , advopts=noagp in .bxrc file.

Ya, I should have remembered that. I was in a 'hack' type mood checking various things trying to eliminate variables.

Anyway, I don't disagree with you. I am just saying that due to my tests, I believe this issue is mostly caused by an incomplete AGP emulation and until it is in working order, I will not pursue this any further.

One other thing I noticed, if my memory is correct, is that the mobo was based on the 82371AB (emphasis on the AB), while the PCI-to-ISA bridge was based on the 82371EB (emphasis on the EB), or the other way around. This might be an issue too, though further research will need to be done.

[Vort]

I am just saying that due to my tests, I believe this issue is mostly caused by an incomplete AGP emulation

During my tests with disabled 82371AB/EB PCI to USB controller, I noticed that Windows 98 tends to reboot without any apparent reason. More precisely, 3rd (14) exception with no resolution occurs.
Maybe it worth to fix this crash first.

[Vort]

Turned out, reboots are related to ne2k (RTL8029) device.
When I disable or remove it, random reboots disappear.

upd. Reboots are related to IRQ number, not chipset variety.
I made more detailed description of this problem in #452.