Date: Wed, 27 Aug 2003 12:02:08 -0400 From: Joe Marcus Clarke <marcus@marcuscom.com> To: James Nobis <quel@quelrod.net> Cc: dcswest@gmx.net Subject: Re: bcm4400 driver and Dell 8500 Message-ID: <1062000128.717.4.camel@gyros> In-Reply-To: <Pine.BSO.4.53.0308270823360.19094@quelrod.net> References: <Pine.BSO.4.53.0308262257210.24387@quelrod.net> <009c01c36c6e$7a882150$4bc8a8c0@orac> <20030827131039.GA17250@panzer.kdm.org> <Pine.BSO.4.53.0308270823360.19094@quelrod.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-OXROxTjxZDgmWp8dYTOe
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2003-08-27 at 09:27, James Nobis wrote:
> On Wed, 27 Aug 2003, Kenneth D. Merry wrote:
>=20
> > 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 i=
rq 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 t=
he
> > > > 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 configurati=
on of
> > > the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates t=
hat the
> > > memory map is not right.
> > >
> > > > Before sending this email I was going to obtain a backtrace. I rec=
ompiled
> > > > with the symbol table and kernel debugger and now the driver appear=
s to
> > > > work fine. Should it work this way?
> > >
> > > Hmm interesting. Ken can you try this and see if the driver then work=
s?
> >
> > I've already got the kernel debugger on. Do you mean changing the modu=
le
> > compile somehow so that more symbols are included? (It seems to resolv=
e
> > the function addresses in the module fine.)
> >
>=20
> compiling with options DDB and makeoptions DEBUG=3D-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
>=20
> > 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 car=
bus
> > 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 i=
s
> > identical to location used when the module loads (above), but the ether=
net
> > address is properly decoded:
> >
> > bcm0: <Broadcom 10/100 Base-T Ethernet> mem 0xfaffe000-0xfaffffff irq 1=
1 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 cardbu=
s
> > initialization fails, and then I get the following messages over and ov=
er
> > again:
> >
> > "eek j=3D6, 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
> >
> 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=
.
>=20
> -James
> _______________________________________________
> freebsd-mobile@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
--=20
PGP Key : http://www.marcuscom.com/pgp.asc
--=-OXROxTjxZDgmWp8dYTOe
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQA/TNYAb2iPiv4Uz4cRAivHAKCEz8BrwMw5rUGHGHoOnV7I36AZxwCfVb7m
CnyZ9UcWKuVWkVlBAelcrFY=
=ZxRk
-----END PGP SIGNATURE-----
--=-OXROxTjxZDgmWp8dYTOe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1062000128.717.4.camel>