Re: bcm4400 driver and Dell 8500

• Previous message: Kenneth D. Merry: "Re: bcm4400 driver and Dell 8500"
• In reply to: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Next in thread: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Reply: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 27 Aug 2003 21:30:38 -0600
To: Duncan Barclay <dmlb@dmlb.org>

On Wed, Aug 27, 2003 at 18:27:57 +0100, Duncan Barclay wrote:
>
> On 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.)
> >
> > 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:
>
> This is still smelling of memory stuff outside of my experience.
>
> > 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
>
> Just checked dhclient and it works fine for me.

I just had another failure case (when I loaded bcm(4) as a module but
didn't have my fxp card inserted) where dhclient just hung up. I didn't
get any out of mbufs errors.

> > 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.
>
> Cool, thats about right.
>
> > 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"
>
> This is a little loop that waits for the card to finish DMAing a packet. There
> should be a DELAY(1) in there. But it may be commented out.

That's bad...in general the chip should DMA the packet and then update the
consumer index and generate an interrupt. I don't know how this particular
chip works, though. The DELAY is commented out.

> Do we think that cardbus is trashing the memory space somehow?

That could very well be the case. I don't know anything about cardbus,
though.

Ken

-- 
Kenneth Merry
ken@kdm.org
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

• Previous message: Kenneth D. Merry: "Re: bcm4400 driver and Dell 8500"
• In reply to: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Next in thread: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Reply: Duncan Barclay: "Re: bcm4400 driver and Dell 8500"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]