cvs commit: src/sys/dev/aic7xxx ahc_pci.c ahd_pci.c src/sys/dev/ath if_ath_pci.c src/sys/dev/firewire fwohci_pci.c src/sys/dev/fxp if_fxp.c src/sys/dev/puc puc_pci.c src/sys/dev/re if_re.c src/sys/dev/sio sio_pci.c src/sys/dev/uart uart_bus_pci.c ...

Andreas Klemm andreas at FreeBSD.org
Sat Nov 29 00:20:26 PST 2003


On Fri, Nov 28, 2003 at 03:04:04PM -0800, Don Lewis wrote:
> > Indeed, seems to be the case:
> > bge0 mem 0xfaff0000-0xfaffffff
> > cbb0     0xf6000000-0xfbffffff
> 
> My R40 located both cbb0 and an0 at 0xc0400000.  Warner tracked down the
> problem while I was at BSDCon and found an open address range where cbb0
> could be relocated.  I've now got the following magic incantation in my
> /boot/loader.conf:
> 	hw.cbb.start_memory=0xC0800000
> Look at what address ranges have been allocated and find an open spot.
> You can type in the above command at the loader prompt for testing
> purposes.

Will analyse consumed address space.

On Fri, Nov 28, 2003 at 07:20:26PM -0700, M. Warner Losh wrote:
> I've isolated the problem, and have a non-working fix/workaround in my
> tree.  I need to make it work, however.  In summary, the BIOS is
> assigning addresses, and so is FreeBSD and FreeBSD doesn't know about
> the BIOS' allocation.  Double allocation -> bad things happen.

Well, good look for making it work, in the meantime I look at the
address spaces.

Feel free to take me as a tester, if you think you got rid of the
rough edges in the patch. The Dell seems to be an excellent candidat
for such fixes, since it already has a lot of stuff included.

BTW, two more things:

- /dev/acpictl can't be found
- after closing and reopening, the laptop it doesn't work again

	Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? -> http://www.apsfilter.org/


More information about the cvs-src mailing list