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 ...

[Don Lewis]

On 28 Nov, Andreas Klemm wrote:
> On Fri, Nov 28, 2003 at 02:34:24PM -0800, Gordon Tetlow wrote:
>> On Fri, Nov 28, 2003 at 11:23:56AM +0100, Andreas Klemm wrote:
>> > 
>> > This reminds me about one problem with my DELL Latitude D600
>> > notebook that is still unsolved in -current of 1-2 weeks ago.
>> > 
>> > Maybe your commit is related to that problem ... I'll test ...
>> > 
>> > The internal broadcom 10/100/1000 works fine, no problem.
>> > 
>> > But .. if I add a 2nd Ethernet cardbus PCMCIA card and boot the
>> > device or - if I remember right - simply plug in the 3COM card
>> > into the PCMCIA slot, then PHY won't be found for the bge0
>> > interface anymore...
>> 
>> I had a similar problem with my IBM T40 laptop. It turned out that
>> the cardbus and ethernet controllers were trying to grab the same
>> region in memory. Try a boot -v and see if cbb and bge are trying
>> to grab the same region in memory.
> 
> 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.