Re: bcm4400 driver and Dell 8500
On Wed, Aug 27, 2003 at 12:24:11 -0500, James Nobis wrote: 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-0xfaff irq 11 at device 0.0 on pci2 bcm0: Ethernet address: ff:ff:ff:ff:ff:ff panic: bcm0: Strange type for core 0x 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 Ahh. I've had DDB on the whole time, but I've found that I don't get a crash (i.e. the all ff's problem) if I don't have my fxp card plugged in when I load the bcm module. dhclient doesn't cause the system to run out of mbufs, but then again it hangs. If I ifconfig the interface manually things work fine. 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]
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
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-0xfaff 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]
Re: bcm4400 driver and Dell 8500
From: Kenneth D. Merry [EMAIL PROTECTED] 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. Unfortunately I don't know how the chips works wither. This method comes from the drivers I used as a reference. I have recoded the loop a little so it doesn't DELAY and I've never had a timeout from it. 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. Me neither, but my laptop needs some help in that area, so that's what I'm going to look at next. 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]
Re: bcm4400 driver and Dell 8500
(apologies for the large cc list, im only subbed to -mobile so not sure who is where) On Thu Aug 28, 08:21P +0100, Duncan Barclay wrote: From: Kenneth D. Merry [EMAIL PROTECTED] 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. Unfortunately I don't know how the chips works wither. This method comes from the drivers I used as a reference. I have recoded the loop a little so it doesn't DELAY and I've never had a timeout from it. That is how this chip works. It rxes a packet, prepends an rxheader to it, DMAs it and then updates the index and generates an interrupt. If it reaches the last descriptor(marked by an end of table flag) it resets it 0. The chip does have a 'lazy rx' mode which can be set to interrupt after a certain amount of frames or a certain amount of data. These problems may or may not mystically disappear when I finish merging Duncan and I's drivers, but I wouldn't hold your breath. :) Regards, Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11 at device 0.0 on pci2 bcm0: Ethernet address: ff:ff:ff:ff:ff:ff panic: bcm0: Strange type for core 0x 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? Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
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
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-0xfaff 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
[EMAIL PROTECTED]
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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
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
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-0xfaff 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
[EMAIL PROTECTED]
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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
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-0xfaff 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
[EMAIL PROTECTED]
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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe,
Re: bcm4400 driver and Dell 8500
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-0xfaff irq 11
at device 0.0 on pci2
bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
panic: bcm0: Strange type for core 0x
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-0xfaff 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
[EMAIL PROTECTED]
--
Duncan Barclay |
[EMAIL PROTECTED] |
[EMAIL PROTECTED]|
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
