FreeBSD 5.x installation hangs on Toshiba Tecra A2

[John Baldwin]

On Friday 20 May 2005 11:32 pm, M. Warner Losh wrote:
> In message: <79e6b51a7fb7d0233cb0c9e886d92ddf at FreeBSD.org>
>
>             John Baldwin <jhb at FreeBSD.org> writes:
> : On May 18, 2005, at 2:56 AM, Munehiro Matsuda wrote:
> : > Hello Jamil,
> : >
> : > How about setting 'hw.pci.enable_io_modes=0' at loader prompt or
> : > set it in loader.conf? Toshiba laptops seems to need this.
> : >
> : > Hope this helps,
> : >   Haro
> : > =----------------------------------------------------------------------
> : > --------
> : >            _ _    Munehiro (haro) Matsuda
> : >  -|- /_\  |_|_|   Internet Solution Dept., KGT Inc.
> : >  /|\ |_|  |_|_|   2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan
> : >                   Tel: +81-3-3225-0767  Fax: +81-3-3225-0740
> : >                   Email: haro at kgt.co.jp
> : >
> : > From: "Jamil Ahmed" <jamil.ahmed at hotmail.co.uk>
> : > Date: Wed, 18 May 2005 07:42:41 +0100
> : >
> : > ::Hello,
> : > ::
> : > ::I am having trouble installing FreeBSD 5.x on my laptop (the
> : >
> : > processor is
> : >
> : > ::Intel Centrino 1.7GHz). I have tried 5.3 and now 5.4, the load stops
> : >
> : > at the
> : >
> : > ::same place for both. FreeBSD 4.10 installs fine. I have tried the
> : >
> : > normal
> : >
> : > ::boot and also boot with ACPI disabled without luck. The following is
> : >
> : > the
> : >
> : > ::tail end of the output when booting with verbose output
> : > ::
> : > ::pcib0: slot 2 INTA routed to irq 10 via \_SB_.LNKA
> : > ::found-> vendor=0x8086, dev=0x3582, revid=0x02
> : > ::        bus=0, slot=2, func=0
> : > ::        class=03-00-00, hdrtype=0x00, mfdev=1
> : > ::        cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords)
> : > ::        lattimer=0x00 (0 ns), mingnt-0x00 (0 ns), maxlat=0x00 (0 ns)
> : > ::        intpin=a, irq=10
> : > ::        powerspec 1 supports D0 D1 D3 current D0
> : > ::        map[10]: type 3, range 32, base 00000000, size 27, memory
> : >
> : > disabled
> : >
> : > ::the install just stalls at this point.
> :
> : So, the problem is that we turn on the memory BARs by default.  Note
> : that the BAR has a base address of 0, so I wonder if it starts
> : "answering" to mem access to low memory.  Note it has a range of 27
> : bits, or 128 MB.  We could probably just move the check for a base of 0
> : up above the pci_enable_io_modes code to do that.  Warner, what do you
> : think?
>
> Sounds reasonable to me on its surface.  Wanna shoot me a patch?

Index: pci.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.289
diff -u -r1.289 pci.c
--- pci.c	29 Apr 2005 06:22:41 -0000	1.289
+++ pci.c	27 May 2005 19:50:04 -0000
@@ -823,6 +823,13 @@
 	}
 
 	/*
+	 * 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;
+	/*
 	 * 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
@@ -847,13 +854,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;

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org