Acer Aspire 5672 and FreeBSD 6.2-beta1

[John Baldwin]

On Thursday 12 October 2006 11:08, Bruno Ducrot wrote:
> On Tue, Oct 10, 2006 at 09:21:53AM -0400, John Baldwin wrote:
> > On Tuesday 10 October 2006 05:52, Bruno Ducrot wrote:
> > > On Mon, Oct 09, 2006 at 04:11:46PM -0400, John Baldwin wrote:
> > > > On Saturday 07 October 2006 15:03, Bruno Ducrot wrote:
> > > > > On Sat, Oct 07, 2006 at 06:46:42PM +0200, Torfinn Ingolfsen wrote:
> > > > > > On Sat, 07 Oct 2006 17:01:03 +0200
> > > > > > Bruno Ducrot <ducrot at poupinou.org> wrote:
> > > > > > 
> > > > > > > Thanks. The device do not have a BAR when acpi is enabled.  We
> > > > > > > therefore have to enable one.  I think just by poking aroud some pci
> > > > > > > config registers onto the pci bridge will do the trick.  Your
> > > > > > 
> > > > > > Ok. I'm wondering; will output from lspci under Linux help you get at
> > > > > > the info more easily? I have Xubuntu installed on a partition on this
> > > > > > machine, so it is easy for me to do that, if you wish.
> > > > > 
> > > > > Well, I don't know if that will be helpful.  Humm, maybe a dmesg?
> > > > > 
> > > > > > > Looking at this datasheet I think we have to look more carrefully to
> > > > > > > register 0x04 (halfword), 0x20h, 0x24, 0x28 and 0x2c.
> > > > > > > Looking them both with and without acpi and comparing them will allows
> > > > > > > us to know hopefully how to enable the first BAR to the correct adress
> > > > > > > for your ethernet card.  In short, if you can first boot without ACPI,
> > > > > > > then perform
> > > > > > > pciconf -r -h pci0:28:2 4
> > > > > > > pciconf -r pci0:28:2 0x20
> > > > > > > pciconf -r pci0:28:2 0x24
> > > > > > > pciconf -r pci0:28:2 0x28
> > > > > > > pciconf -r pci0:28:2 0x2c
> > > > > > > 
> > > > > > > Also do a dump in order to check if something else might be needed:
> > > > > > > pciconf -r -b pci0:28:2 0:256
> > > > > > > 
> > > > > > > Boot with ACPI enabled:
> > > > > > > do the same pciconf stuff, then send me the output.
> > > > > > 
> > > > > > Done. I've sent you the files via email, and also uploaded them to the
> > > > > > web page, in case anyone else wants them for some reason. Webpage:
> > > > > > http://tingox.googlepages.com/aceraspireas5672andfreebsd
> > > > > > 
> > > > > > > After that, we should be able to correct your problem, either by
> > > > > > > 1- hacking the DSDT,
> > > > > > > OR
> > > > > > > 2- hacking pcib.c.
> > > > > > > (at your option).
> > > > > > 
> > > > > > I think hacking the DSDT is the more politically correct option, but
> > > > > > either one will work for me.
> > > > > 
> > > > > Ok.  First remove device bge in your kernel config.  For example create a
> > > > > config file with:
> > > > > 
> > > > > >>> BEGIN
> > > > > include		GENERIC
> > > > > ident		MYKERNEL (or what you like)
> > > > > nodevice	bge
> > > > > <<< END
> > > > > 
> > > > > After rebuilding and installing your kernel,
> > > > > you can do something like that:
> > > > > 
> > > > > pciconf -w pci0:28:2 0xd8 0x04110008
> > > > > 
> > > > > pciconf -w -h pci0:28:2 0x58 0x0000
> > > > > 
> > > > > pciconf -w pci0:28:2 0x24 0x0001fff1
> > > > > pciconf -w pci0:28:2 0x20 0xc830c830
> > > > > 
> > > > > pciconf -w -h pci0:28:2 0x04 0x0007
> > > > > 
> > > > > 
> > > > > After that, you should be able to kldload if_bge and report back if
> > > > > this work.  In that case I will modify the DSDT so that you won't to
> > > > > worry about all of those pciconf stuff.
> > > > 
> > > > You really shouldn't change BAR registers directly.  First of all, the PCI
> > > > bus driver already knows how to allocate resources for a BAR if it is set
> > > > to 0 and when doing so will make sure to not allocate an address that
> > > > conflicts with another device.  Secondly, a lot of PCI config registers are
> > > > cached in the ivars by the PCI bus, so it may not even read the values you
> > > > write into it (though writing those values will turn on the address decode
> > > > for the device, and if another device is using that address things will go
> > > > downhill quick).
> > > 
> > > You are indeed right.  The issue therefore seems to be, when ACPI is enabled,
> > > then the PCI bus driver doesn't set up correctly a BAR.
> > > FYI the bridge is one of the four PCIe embedded to an ICH-7.
> > 
> > The PCI bus driver does the same thing regardless of ACPI.  When the NIC driver
> > does its bus_alloc_resource() the PCI bus should then go allocate resources for
> > it.  At this point you will probably want to get a boot -v so you can see what
> > the bus prints out when it first looks at the device first.  If the BAR is
> > listed (but with a base of 0), then you will want to look at the stuff in
> > pci_alloc_resource().
> > 
> 
> John,  the relevant info. is (I think) :
> 
> pcib4: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
> pcib4:   secondary bus     4
> pcib4:   subordinate bus   4
> pcib4:   I/O decode        0x0-0x0
> pcib4:   memory decode     0x0-0x0
> pcib4:   prefetched decode 0x0-0x0
> pci4: <ACPI PCI bus> on pcib4
> pci4: physical bus=4
> found->	vendor=0x14e4, dev=0x169d, revid=0x21
> 	bus=4, slot=0, func=0
> 	class=02-00-00, hdrtype=0x00, mfdev=0
> 	cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords)
> 	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> 	intpin=a, irq=10
> 	powerspec 2  supports D0 D3  current D0
> 	MSI supports 8 messages, 64 bit
> 	map[10]: type 1, range 64, base 00000000, size 16, memory disabled
> bge0: <Broadcom BCM5750 C1, ASIC rev. 0x4201> irq 18 at device 0.0 on pci4
> pcib4: bge0 requested unsupported memory range 0x0-0xffffffff (decoding 0x0-0x0, 0x0-0x0)
> bge0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
> bge0: couldn't map memory
> device_attach: bge0 attach returned 6
> 
> 
> Sound like the PCI-PCI bridge is not setup correct to me at first.

Yeah, it's not recursively allocating resources from its parent.   Warner
might be able to look into this when he recovers from the new munchkin.

-- 
John Baldwin