Date: Wed, 27 Aug 2003 18:27:57 +0100 (BST) From: Duncan Barclay <dmlb@dmlb.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-mobile@freebsd.org Subject: Re: bcm4400 driver and Dell 8500 Message-ID: <XFMail.20030827182757.dmlb@dmlb.org> In-Reply-To: <20030827131039.GA17250@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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.
Do we think that cardbus is trashing the memory space somehow?
> 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
>
--
________________________________________________________________________
Duncan Barclay |
dmlb@dmlb.org |
dmlb@freebsd.org|
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030827182757.dmlb>