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