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 [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"