Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Aug 2003 07:10:39 -0600
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        Duncan Barclay <dmlb@dmlb.org>
Cc:        dcswest@gmx.net
Subject:   Re: bcm4400 driver and Dell 8500
Message-ID:  <20030827131039.GA17250@panzer.kdm.org>
In-Reply-To: <009c01c36c6e$7a882150$4bc8a8c0@orac>
References:  <Pine.BSO.4.53.0308262257210.24387@quelrod.net> <009c01c36c6e$7a882150$4bc8a8c0@orac>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote:
> Hello James and Ken,
> 
> Both of you are having real problems with the bcm driver and both of you
> have a Dell 8500.
> 
> This is James' dmesg output, which from memory looks very similar to your
> Ken?
> 
> > bcm0: <Broadcom 10/100 Base-T Ethernet> mem 0xfaffe000-0xfaffffff irq 11
> > at device 0.0 on pci2
> > bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
> > panic: bcm0: Strange type for core 0xffffffff

Yep, the messages I get are identical when I load it as a module.

> > I'm running 5.1-current from august 22nd.  I can try pulling down the
> > latest 5.1 tommorow if you think this might help.  This is the same result
> > as when I tried the driver from over a month ago.
> 
> We think that the problem is something to do with the PCI configuration of
> the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the
> memory map is not right.
> 
> > Before sending this email I was going to obtain a backtrace.  I recompiled
> > with the symbol table and kernel debugger and now the driver appears to
> > work fine.  Should it work this way?
> 
> Hmm interesting. Ken can you try this and see if the driver then works?

I've already got the kernel debugger on.  Do you mean changing the module
compile somehow so that more symbols are included?  (It seems to resolve
the function addresses in the module fine.)

The stack trace from the module load is:

panic()
bcm_chip_get_core()
bcm_chip_reset()
bcm_attach()
device_probe_and_attach()
etc.

If I boot a kernel with the bcm driver compiled in, and don't attach to the
docking station, it comes up fine until I insert my fxp card in the carbus
slot.  Then I get the panic in bcm_ring_rx_eof() that I reported last
night.  FWIW, when I have the driver compiled in, the memory location is
identical to location used when the module loads (above), but the ethernet
address is properly decoded:

bcm0: <Broadcom 10/100 Base-T Ethernet> mem 0xfaffe000-0xfaffffff irq 11 at device 0.0 on pci2
bcm0: Ethernet address: 00:0b:db:94:bf:42
miibus0: <MII bus> on bcm0

If I boot a kernel with the bcm driver compiled in, and don't attach to the
docking station, and don't insert my fxp card, I get slightly further.  I
tried running dhclient, and got:

All mbufs or mbuf clusters exhausted, please see tuning(7).
bcm0: initialization failed: no memory for rx buffers

Then I tried just manually ifconfiging the interface, and it works!

Here's what netstat -m says:

{erebor:/usr/home/ken:1:0} netstat -nm
mbuf usage:
        GEN cache:      0/0 (in use/in pool)
        CPU #0 cache:   576/608 (in use/in pool)
        Total:          576/608 (in use/in pool)
        Mbuf cache high watermark: 512
        Maximum possible: 34304
        Allocated mbuf types:
          576 mbufs allocated to data
        1% of mbuf map consumed
mbuf cluster usage:
        GEN cache:      0/0 (in use/in pool)
        CPU #0 cache:   575/584 (in use/in pool)
        Total:          575/584 (in use/in pool)
        Cluster cache high watermark: 128
        Maximum possible: 17152
        3% of cluster map consumed
1320 KBytes of wired memory reserved (98% in use)
1 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

Performance, once I manually assigned an address seems okay; I was able to
ftp a file over from another machine at a little over 11MB/sec.

If I insert the fxp card after the bcm driver is configured, the cardbus
initialization fails, and then I get the following messages over and over
again:

"eek j=6, macCurrent 511, con288"

At that point I can 't even break into the debugger.

That's all the time I have for tinkering with it this morning...

Looks like things are working somewhat better, but there is still some
weird stuff going on...

Ken
-- 
Kenneth Merry
ken@kdm.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030827131039.GA17250>