bcm4400 driver and Dell 8500

James Nobis quel at quelrod.net
Wed Aug 27 10:24:01 PDT 2003



On Wed, 27 Aug 2003, Joe Marcus Clarke wrote:

> On Wed, 2003-08-27 at 09:27, James Nobis wrote:
> > On Wed, 27 Aug 2003, Kenneth D. Merry wrote:
> >
> > > 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.)
> > >
> >
> > compiling with options DDB and makeoptions DEBUG=-g is what i mean
>
> Note, on my 5150, I also have a kernel built with -g.  I do not have DDB
> compiled in, but I have never tried a kernel without -g.  I may be
> susceptible to the same "all-ffs" problem.
>
> Joe

When i just did a -g, it still would crash when i tried to load the
module.  The crashes stopped entirely once I also added DDB.

-James

 > >
> > > 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 at kdm.org
> > >
> > I don't have a docking station.  The built in ethernet is which uses the
> > bcm driver.  I only have used it as a module and have not tried otherwise.
> >
> > -James
> > _______________________________________________
> > freebsd-mobile at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe at freebsd.org"
> --
> PGP Key : http://www.marcuscom.com/pgp.asc
>
>
>


More information about the freebsd-hackers mailing list