i386/74829: FreeBSD 5.3-RELEASE hangs during boot/install on Tyan Thunder i7520 (S5360) motherboard

[Jon Kuroda]

Attached are a patch and readme (written by Vadim Kogan).  Many thanks to
Vadim Kogan and Bill Paul for doing the bulk of the work on this.

This and other 5.3 patches can also be found here:
http://www.csua.berkeley.edu/~vadim/soda-diffs/

On Wed, Dec 08, 2004 at 01:10:30AM +0000, FreeBSD-gnats-submit at FreeBSD.org wrote:
> Thank you very much for your problem report.
> It has the internal identification `i386/74829'.
> The individual assigned to look at your
> report is: freebsd-i386. 
> 
> You can access the state of your problem report at any time
> via this link:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=74829
> 
> >Category:       i386
> >Responsible:    freebsd-i386
> >Synopsis:       FreeBSD 5.3-RELEASE hangs during boot/install on Tyan Thunder i7520 (S5360) motherboard
> >Arrival-Date:   Wed Dec 08 01:10:30 GMT 2004
-------------- next part --------------
This is a fix for a bug in FreeBSD 5.3, which prevents it from
booting on soda without special flags.

The bug is triggered by a PCI EXPRESS DMA Controller on soda's
motherboard. It has a bad resource, which is (properly) disabled.
However, FreeBSD (improperly) enables it without checking that the
resource is a happy one, causing physical page 0 to go to lala land,
vm86 mode to screw up, keyboard not be initialized and a complete
hang on boot right in the middle of keyboard initialization.

You can also prevent any resource from being enabled by means of
setting hw.pci.enable_io_modes to 0 before booting the kernel.

Note that due to an unrelated bug (discussed elsewhere), an UP
kernel will not boot on soda.

	- Vadim

-------------- next part --------------
--- /usr/src/sys/dev/pci/pci.c.vsave	Tue Dec 14 21:39:20 2004
+++ /usr/src/sys/dev/pci/pci.c	Tue Dec 14 18:56:00 2004
@@ -688,6 +688,7 @@
 		    cfg->mfdev);
 		printf("\tcmdreg=0x%04x, statreg=0x%04x, cachelnsz=%d (dwords)\n", 
 		    cfg->cmdreg, cfg->statreg, cfg->cachelnsz);
+
 		printf("\tlattimer=0x%02x (%d ns), mingnt=0x%02x (%d ns), maxlat=0x%02x (%d ns)\n",
 		    cfg->lattimer, cfg->lattimer * 30, cfg->mingnt,
 		    cfg->mingnt * 250, cfg->maxlat, cfg->maxlat * 250);
@@ -792,6 +793,16 @@
 	}
 
 	/*
+	 * If base is 0 or is all 1s, then we have problems.  It is best to ignore
+	 * such entires for the moment.  These will be allocated later if
+	 * the driver specifically requests them.
+	 */
+	if( base == 0ull || base == ~( ~0ull << ln2range ) ) {
+		printf( "\tVadim: bogus map - ignoring..\n" );
+		return 1;
+	}
+
+	/*
 	 * This code theoretically does the right thing, but has
 	 * undesirable side effects in some cases where peripherals
 	 * respond oddly to having these bits enabled.  Let the user
@@ -816,13 +827,6 @@
 		if (type == SYS_RES_MEMORY && !pci_memen(pcib, b, s, f))
 			return (1);
 	}
-	/*
-	 * If base is 0, then we have problems.  It is best to ignore
-	 * such entires for the moment.  These will be allocated later if
-	 * the driver specifically requests them.
-	 */
-	if (base == 0)
-		return 1;
 
 	start = base;
 	end = base + (1 << ln2size) - 1;
@@ -960,9 +964,8 @@
 			pcifunchigh = PCI_FUNCMAX;
 		for (f = 0; f <= pcifunchigh; f++) {
 			dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
-			if (dinfo != NULL) {
-				pci_add_child(dev, dinfo);
-			}
+			if (dinfo != NULL)
+				 pci_add_child(dev, dinfo);
 		}
 	}
 #undef REG