Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Wheezy issue with broadcom 5720 nic on new dell PowerEdge R720
856 views
Skip to first unread message
Casper Langemeijer
Mar 16, 2013, 7:20:03 AM3/16/13
to
Hi List,
I've run into an issue trying to install a new PowerEdge R720 server that arrived this week. It is equipped with a broadcom 5720 quad port network interface daughter card. I installed wheezy on it. No problems! The network interface works, and does not require any non-free firmware.
Then I installed a xen kernel, and because of that update-initramfs was ran. I noticed these warnings:
root@server:~# update-initramfs -uk all
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64
W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3
These files are listed in the firmware-linux-nonfree package description for squeeze, I thought I'd give this package a try and install it.
From that moment on eth0 is not working anymore. I get these kernel messages:
[ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
[ 1797.840909] tg3 0000:01:00.0: eth0: 0x00000000: 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
[ 1797.841066] tg3 0000:01:00.0: eth0: 0x00000010: 0xd91a000c, 0x00000000, 0xd91b000c, 0x00000000
....
[ 1797.935588] tg3 0000:01:00.0: eth0: 0x00007030: 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
[ 1797.935745] tg3 0000:01:00.0: eth0: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
[ 1797.935911] tg3 0000:01:00.0: eth0: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(00e9:0000:0000:0000)]
[ 1797.936070] tg3 0000:01:00.0: eth0: 1: Host status block [00000001:0000001c:(0000:0000:0000):(001b:0000)]
[ 1797.936226] tg3 0000:01:00.0: eth0: 1: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.936383] tg3 0000:01:00.0: eth0: 2: Host status block [00000001:00000003:(0002:0000:0000):(0000:0000)]
[ 1797.936540] tg3 0000:01:00.0: eth0: 2: NAPI info [00000001:00000001:(0001:0000:01ff):0000:(0000:0000:0000:0000)]
[ 1797.936697] tg3 0000:01:00.0: eth0: 3: Host status block [00000001:0000000e:(0000:0000:0000):(0000:0000)]
[ 1797.936853] tg3 0000:01:00.0: eth0: 3: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.937012] tg3 0000:01:00.0: eth0: 4: Host status block [00000001:00000011:(0000:0000:0010):(0000:0000)]
[ 1797.937168] tg3 0000:01:00.0: eth0: 4: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.980164] tg3 0000:01:00.0: eth0: Link is down
[ 1802.092252] tg3 0000:01:00.0: eth0: Link is up at 1000 Mbps, full duplex
[ 1802.092257] tg3 0000:01:00.0: eth0: Flow control is on for TX and on for RX
[ 1802.092261] tg3 0000:01:00.0: eth0: EEE is disabled
[ 1807.591630] tg3 0000:01:00.0: eth0: transmit timed out, resetting
... and so on
I tried the debian installer again, but even then it's not able to get a DHCP IP address using eth0. eth1 is working fine.
I booted back into the machine, purged the firmware-linux-nonfree package and am currently using eth1, that is still working:
[ 1856.825856] tg3 0000:01:00.1: eth1: Link is up at 1000 Mbps, full duplex
Now what happened?
My *guess* is that the Broadcom 5720 for some reason is detected as one of these cards
* Broadcom BCM5703/BCM5704 TSO firmware for tigon/tg3_tso.bin)
* Broadcom BCM5701A0 firmware (tigon/tg3.bin)
* Broadcom BCM5705 TSO firmware (tigon/tg3_tso5.bin)
Then it loads that firmware blob onto the network card, breaking it.
And now what?
I have a bricked eth0. I really like to repair before the machine goes into production. Suggestions anyone?
Should a debian package be fixed? It appears that the Broadcom 5720 does not need a firmware blob to operate. http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/tigon has the same files as the firmware-linux-nonfree package plus one added 7 days ago for '57766 cards'. So nothing important there.
There must be some code somewhere that decides what firmware to use. Possibly the tg3.ko driver in linux-image-3.2.0-4-amd64?
Hope you can help me and avoid more broken Broadcom 5720's.
Greetings, Casper
I've run into an issue trying to install a new PowerEdge R720 server that arrived this week. It is equipped with a broadcom 5720 quad port network interface daughter card. I installed wheezy on it. No problems! The network interface works, and does not require any non-free firmware.
Then I installed a xen kernel, and because of that update-initramfs was ran. I noticed these warnings:
root@server:~# update-initramfs -uk all
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64
W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3
W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3
These files are listed in the firmware-linux-nonfree package description for squeeze, I thought I'd give this package a try and install it.
From that moment on eth0 is not working anymore. I get these kernel messages:
[ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
[ 1797.840909] tg3 0000:01:00.0: eth0: 0x00000000: 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
[ 1797.841066] tg3 0000:01:00.0: eth0: 0x00000010: 0xd91a000c, 0x00000000, 0xd91b000c, 0x00000000
....
[ 1797.935588] tg3 0000:01:00.0: eth0: 0x00007030: 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
[ 1797.935745] tg3 0000:01:00.0: eth0: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
[ 1797.935911] tg3 0000:01:00.0: eth0: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(00e9:0000:0000:0000)]
[ 1797.936070] tg3 0000:01:00.0: eth0: 1: Host status block [00000001:0000001c:(0000:0000:0000):(001b:0000)]
[ 1797.936226] tg3 0000:01:00.0: eth0: 1: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.936383] tg3 0000:01:00.0: eth0: 2: Host status block [00000001:00000003:(0002:0000:0000):(0000:0000)]
[ 1797.936540] tg3 0000:01:00.0: eth0: 2: NAPI info [00000001:00000001:(0001:0000:01ff):0000:(0000:0000:0000:0000)]
[ 1797.936697] tg3 0000:01:00.0: eth0: 3: Host status block [00000001:0000000e:(0000:0000:0000):(0000:0000)]
[ 1797.936853] tg3 0000:01:00.0: eth0: 3: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.937012] tg3 0000:01:00.0: eth0: 4: Host status block [00000001:00000011:(0000:0000:0010):(0000:0000)]
[ 1797.937168] tg3 0000:01:00.0: eth0: 4: NAPI info [0000000c:0000000c:(0000:0000:01ff):000b:(000b:000b:0000:0000)]
[ 1797.980164] tg3 0000:01:00.0: eth0: Link is down
[ 1802.092252] tg3 0000:01:00.0: eth0: Link is up at 1000 Mbps, full duplex
[ 1802.092257] tg3 0000:01:00.0: eth0: Flow control is on for TX and on for RX
[ 1802.092261] tg3 0000:01:00.0: eth0: EEE is disabled
[ 1807.591630] tg3 0000:01:00.0: eth0: transmit timed out, resetting
... and so on
I tried the debian installer again, but even then it's not able to get a DHCP IP address using eth0. eth1 is working fine.
I booted back into the machine, purged the firmware-linux-nonfree package and am currently using eth1, that is still working:
[ 1856.825856] tg3 0000:01:00.1: eth1: Link is up at 1000 Mbps, full duplex
Now what happened?
My *guess* is that the Broadcom 5720 for some reason is detected as one of these cards
* Broadcom BCM5703/BCM5704 TSO firmware for tigon/tg3_tso.bin)
* Broadcom BCM5701A0 firmware (tigon/tg3.bin)
* Broadcom BCM5705 TSO firmware (tigon/tg3_tso5.bin)
Then it loads that firmware blob onto the network card, breaking it.
And now what?
I have a bricked eth0. I really like to repair before the machine goes into production. Suggestions anyone?
Should a debian package be fixed? It appears that the Broadcom 5720 does not need a firmware blob to operate. http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/tigon has the same files as the firmware-linux-nonfree package plus one added 7 days ago for '57766 cards'. So nothing important there.
There must be some code somewhere that decides what firmware to use. Possibly the tg3.ko driver in linux-image-3.2.0-4-amd64?
Hope you can help me and avoid more broken Broadcom 5720's.
Greetings, Casper
Brian
Mar 16, 2013, 2:30:02 PM3/16/13
to
On Sat 16 Mar 2013 at 12:08:19 +0100, Casper Langemeijer wrote:
[Snip]
> From that moment on eth0 is not working anymore. I get these kernel
> messages:
>
> [ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
A search with "tg3 transmit timed out resetting" turns up some
possibilities for you to investigate.
[Snip]
> Then it loads that firmware blob onto the network card, breaking it.
>
> And now what?
>
> I have a bricked eth0. I really like to repair before the machine
> goes into production. Suggestions anyone?
You are suggesting the loading of firmware has permanently damaged the
network card but I wonder whether this can be so. My understanding is
similar to what is expressed in this post:
http://lists.debian.org/debian-user/2013/01/msg00028.html
>> 2) What happens with the firmware when card becomes operational? I
>> mean by definition it should be written to device non-volatile
>> memory(for example flash memory), but I doubt that this is the case
>> for Wi-Fi adapters.. Or is it?
> No. The image is simply loaded into the adapter's ram. After the
> device loses power the memory evaporates. When power is applied again
> the device is once again blank or back to the default power on state
> and the firmware must be loaded again.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130316181950.GS32477@desktop
[Snip]
> From that moment on eth0 is not working anymore. I get these kernel
> messages:
>
> [ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
possibilities for you to investigate.
[Snip]
> Then it loads that firmware blob onto the network card, breaking it.
>
> And now what?
>
> I have a bricked eth0. I really like to repair before the machine
> goes into production. Suggestions anyone?
network card but I wonder whether this can be so. My understanding is
similar to what is expressed in this post:
http://lists.debian.org/debian-user/2013/01/msg00028.html
>> 2) What happens with the firmware when card becomes operational? I
>> mean by definition it should be written to device non-volatile
>> memory(for example flash memory), but I doubt that this is the case
>> for Wi-Fi adapters.. Or is it?
> No. The image is simply loaded into the adapter's ram. After the
> device loses power the memory evaporates. When power is applied again
> the device is once again blank or back to the default power on state
> and the firmware must be loaded again.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130316181950.GS32477@desktop
Casper Langemeijer
Mar 17, 2013, 11:40:02 AM3/17/13
to
On 03/16/2013 07:19 PM, Brian wrote:
>> From that moment on eth0 is not working anymore. I get these kernel
>> messages:
>>
>> [ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
> A search with "tg3 transmit timed out resetting" turns up some
> possibilities for you to investigate.
Seriously? Are to telling me to f* off too google? No, I am assuming you
>> From that moment on eth0 is not working anymore. I get these kernel
>> messages:
>>
>> [ 1796.583881] tg3 0000:01:00.0: eth0: transmit timed out, resetting
> A search with "tg3 transmit timed out resetting" turns up some
> possibilities for you to investigate.
are trying to be helpful in suggesting that I could find a solution that
is already documented online somewhere. Well, I looked around, read all
there is to know about the "tg3 transmit timed out resetting" subject.
Nothing relevant to my issue. I spent a good half day looking for
relevant sources.
>> Then it loads that firmware blob onto the network card, breaking it.
>>
>> And now what?
>>
>> I have a bricked eth0. I really like to repair before the machine
>> goes into production. Suggestions anyone?
> You are suggesting the loading of firmware has permanently damaged the
> network card but I wonder whether this can be so. My understanding is
> similar to what is expressed in this post:
>
> http://lists.debian.org/debian-user/2013/01/msg00028.html
>
> >> 2) What happens with the firmware when card becomes operational? I
> >> mean by definition it should be written to device non-volatile
> >> memory(for example flash memory), but I doubt that this is the case
> >> for Wi-Fi adapters.. Or is it?
>
> > No. The image is simply loaded into the adapter's ram. After the
> > device loses power the memory evaporates. When power is applied again
> > the device is once again blank or back to the default power on state
> > and the firmware must be loaded again.
repeat from my first email: "I tried the debian installer again, but
even then it's not able to get a DHCP IP address using eth0. eth1 is
working fine." This is after a cold boot.
Evidently the NIC has some non-volatile state, it's not just RAM. It
could well be that the firmware in RAM did something to the NIC that
brought it into this broken state. The firmware blob could even have
fried it, but I think that's unlikely.
Bottom line is that installing the firmware blob for the network card is
breaking it.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Mar 17, 2013, 12:20:02 PM3/17/13
to
On 3/17/2013 10:34 AM, Casper Langemeijer wrote:
> Which has alway been my understanding of it until so far. But I like to
> repeat from my first email: "I tried the debian installer again, but
> even then it's not able to get a DHCP IP address using eth0. eth1 is
> working fine." This is after a cold boot.
>
> Evidently the NIC has some non-volatile state, it's not just RAM. It
> could well be that the firmware in RAM did something to the NIC that
> brought it into this broken state. The firmware blob could even have
> fried it, but I think that's unlikely.
>
> Bottom line is that installing the firmware blob for the network card is
> breaking it.
Have you performed sufficient troubleshooting to make this claim?
> Which has alway been my understanding of it until so far. But I like to
> repeat from my first email: "I tried the debian installer again, but
> even then it's not able to get a DHCP IP address using eth0. eth1 is
> working fine." This is after a cold boot.
>
> Evidently the NIC has some non-volatile state, it's not just RAM. It
> could well be that the firmware in RAM did something to the NIC that
> brought it into this broken state. The firmware blob could even have
> fried it, but I think that's unlikely.
>
> Bottom line is that installing the firmware blob for the network card is
> breaking it.
If the firmware is the problem conventional wisdom says it will brick
all 4 ports, not just one. You've never mentioned the other two ports
eth2/3. Are they working? Also, dhclient not receiving a lease doesn't
mean eth0 is dead or broken. What does ifconfig tell you? How about
/etc/network/interfaces?
Also, all modern servers retain power while the cord is jacked in. This
is what enables wake-on-LAN, etc. As long as the daughterboard has
standby power it will retain the firmware in its onboard RAM. Pull the
power cord and wait 60 seconds, then plug it back in.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Casper Langemeijer
Mar 18, 2013, 5:00:02 AM3/18/13
to
On 03/17/2013 05:12 PM, Stan Hoeppner wrote:
>> Which has alway been my understanding of it until so far. But I like to
>> repeat from my first email: "I tried the debian installer again, but
>> even then it's not able to get a DHCP IP address using eth0. eth1 is
>> working fine." This is after a cold boot.
>>
>> Evidently the NIC has some non-volatile state, it's not just RAM. It
>> could well be that the firmware in RAM did something to the NIC that
>> brought it into this broken state. The firmware blob could even have
>> fried it, but I think that's unlikely.
>>
>> Bottom line is that installing the firmware blob for the network card is
>> breaking it.
> Have you performed sufficient troubleshooting to make this claim?
I ruled out a faulty cable or switch. What do you mean by your question?
>> Which has alway been my understanding of it until so far. But I like to
>> repeat from my first email: "I tried the debian installer again, but
>> even then it's not able to get a DHCP IP address using eth0. eth1 is
>> working fine." This is after a cold boot.
>>
>> Evidently the NIC has some non-volatile state, it's not just RAM. It
>> could well be that the firmware in RAM did something to the NIC that
>> brought it into this broken state. The firmware blob could even have
>> fried it, but I think that's unlikely.
>>
>> Bottom line is that installing the firmware blob for the network card is
>> breaking it.
> Have you performed sufficient troubleshooting to make this claim?
I run two racks of servers, I'm a full-time linux professional. I do
stuff like linux interface bonding, have setup linux bridging, advanced
firewalling. I know my stuff.
> If the firmware is the problem conventional wisdom says it will brick
> all 4 ports, not just one. You've never mentioned the other two ports
> eth2/3. Are they working?
> Also, dhclient not receiving a lease doesn't
> mean eth0 is dead or broken. What does ifconfig tell you? How about
> /etc/network/interfaces?
If I ifup both eth0 and eth1, ifconfig shows both interfaces. No
> mean eth0 is dead or broken. What does ifconfig tell you? How about
> /etc/network/interfaces?
difference between output for them. (except ip/mac of course) The
counters get reset every few seconds for the broken eth0. Also: ethtool
shows nothing out off the ordinary except that it cannot detect Speed
and Duplex.
/etc/network/interfaces is configured as following:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 172.24.2.241
netmask 255.255.0.0
auto eth1
iface eth1 inet static
address 172.24.2.242
netmask 255.255.0.0
gateway 172.24.1.1
Gateway is missing for eth0. That is intentional. I don't need it for
local operation.
> Also, all modern servers retain power while the cord is jacked in. This
> is what enables wake-on-LAN, etc. As long as the daughterboard has
> standby power it will retain the firmware in its onboard RAM. Pull the
> power cord and wait 60 seconds, then plug it back in.
I was pretty sure I did that, but just to be sure this morning I pulled
> is what enables wake-on-LAN, etc. As long as the daughterboard has
> standby power it will retain the firmware in its onboard RAM. Pull the
> power cord and wait 60 seconds, then plug it back in.
the power cord. No change in the situation.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Mar 18, 2013, 8:00:01 AM3/18/13
to
On 3/18/2013 3:57 AM, Casper Langemeijer wrote:
> If I ifup both eth0 and eth1, ifconfig shows both interfaces. No
> difference between output for them. (except ip/mac of course) The
> counters get reset every few seconds for the broken eth0. Also: ethtool
> shows nothing out off the ordinary except that it cannot detect Speed
> and Duplex.
Do you see link flapping in dmesg, something like this, continuously?
> If I ifup both eth0 and eth1, ifconfig shows both interfaces. No
> difference between output for them. (except ip/mac of course) The
> counters get reset every few seconds for the broken eth0. Also: ethtool
> shows nothing out off the ordinary except that it cannot detect Speed
> and Duplex.
...kernel: e100 0000:00:0d.0: eth0: NIC Link is Down
...kernel: e100 0000:00:0d.0: eth0: NIC Link is Up 100 Mbps Full Duplex
It's beginning to like you simply have a port that failed, and that
loading the firmware blob was coincidental.
Remember the old maxim: If ICs are going to fail in normal operation,
they typically do so within 72 hours. Which is why custom shops for
years advertised that they burn their servers in with real workloads for
72 hours (though few actually did). With the information I have so far,
I'd guess the transceiver for port0 on the card failed. It's a $0.25
IC. This would tend to explain why you can't get link/duplex status.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Casper Langemeijer
Mar 18, 2013, 9:30:02 AM3/18/13
to
On 03/18/2013 12:57 PM, Stan Hoeppner wrote:
> On 3/18/2013 3:57 AM, Casper Langemeijer wrote:
>
>> If I ifup both eth0 and eth1, ifconfig shows both interfaces. No
>> difference between output for them. (except ip/mac of course) The
>> counters get reset every few seconds for the broken eth0. Also: ethtool
>> shows nothing out off the ordinary except that it cannot detect Speed
>> and Duplex.
> Do you see link flapping in dmesg, something like this, continuously?
>
> ....kernel: e100 0000:00:0d.0: eth0: NIC Link is Down
> On 3/18/2013 3:57 AM, Casper Langemeijer wrote:
>
>> If I ifup both eth0 and eth1, ifconfig shows both interfaces. No
>> difference between output for them. (except ip/mac of course) The
>> counters get reset every few seconds for the broken eth0. Also: ethtool
>> shows nothing out off the ordinary except that it cannot detect Speed
>> and Duplex.
> Do you see link flapping in dmesg, something like this, continuously?
>
> ....kernel: e100 0000:00:0d.0: eth0: NIC Link is Up 100 Mbps Full Duplex
>
> It's beginning to like you simply have a port that failed, and that
> loading the firmware blob was coincidental.
>
> Remember the old maxim: If ICs are going to fail in normal operation,
> they typically do so within 72 hours. Which is why custom shops for
> years advertised that they burn their servers in with real workloads for
> 72 hours (though few actually did). With the information I have so far,
> I'd guess the transceiver for port0 on the card failed. It's a $0.25
> IC. This would tend to explain why you can't get link/duplex status.
>
Every 5 seconds, the NIC is Down and Up again.
> It's beginning to like you simply have a port that failed, and that
> loading the firmware blob was coincidental.
>
> Remember the old maxim: If ICs are going to fail in normal operation,
> they typically do so within 72 hours. Which is why custom shops for
> years advertised that they burn their servers in with real workloads for
> 72 hours (though few actually did). With the information I have so far,
> I'd guess the transceiver for port0 on the card failed. It's a $0.25
> IC. This would tend to explain why you can't get link/duplex status.
>
It gets even more weird: I had the NIC daughter card replaced, and the
problem still exists. I think I will use the machine in production as it
is now. Since I'm not using 4 ethernet ports, for me the issue is not
blocking. I hope someday someone encounters the same problem and finds a
solution.
I will receive a second server any day now. I will not be installing the
firmware-linux-nonfree package on that one...
Thank you for your time. If anyone else stumbles on this issue and wants
to contact me: Please do so off-list via personal email.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Casper Langemeijer
Mar 18, 2013, 3:50:01 PM3/18/13
to
On 03/18/2013 02:23 PM, Casper Langemeijer wrote:
>
> It gets even more weird: I had the NIC daughter card replaced, and the
> problem still exists. I think I will use the machine in production as
> it is now. Since I'm not using 4 ethernet ports, for me the issue is
> not blocking. I hope someday someone encounters the same problem and
> finds a solution.
>
This story has a happy end. I fixed it by running the firmware
>
> It gets even more weird: I had the NIC daughter card replaced, and the
> problem still exists. I think I will use the machine in production as
> it is now. Since I'm not using 4 ethernet ports, for me the issue is
> not blocking. I hope someday someone encounters the same problem and
> finds a solution.
>
installer. The firmware installer is in the 'Lifecycle controller' BIOS.
It can download the firmware from a dell ftp server, and allows a
firmware 'upgrade' even if the newest firmware version is the same as
currently installed.
Now that I can restore the situation, I could replay this again if
anyone is interested. I could install the firmware-linux-nonfree package
and see if the problem occurs again. I will have physical access to this
machine on Wednesday only. After that, it's co-located.
Greetings, Casper
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
Mar 19, 2013, 1:00:01 AM3/19/13
to
On 3/18/2013 2:44 PM, Casper Langemeijer wrote:
> On 03/18/2013 02:23 PM, Casper Langemeijer wrote:
>>
>> It gets even more weird: I had the NIC daughter card replaced, and the
>> problem still exists. I think I will use the machine in production as
>> it is now. Since I'm not using 4 ethernet ports, for me the issue is
>> not blocking. I hope someday someone encounters the same problem and
>> finds a solution.
>>
> This story has a happy end. I fixed it by running the firmware
> installer. The firmware installer is in the 'Lifecycle controller' BIOS.
> It can download the firmware from a dell ftp server, and allows a
> firmware 'upgrade' even if the newest firmware version is the same as
> currently installed.
>
> Now that I can restore the situation, I could replay this again if
> anyone is interested. I could install the firmware-linux-nonfree package
> and see if the problem occurs again. I will have physical access to this
> machine on Wednesday only. After that, it's co-located.
There are two different, or should I say separate, firmware. One is
> On 03/18/2013 02:23 PM, Casper Langemeijer wrote:
>>
>> It gets even more weird: I had the NIC daughter card replaced, and the
>> problem still exists. I think I will use the machine in production as
>> it is now. Since I'm not using 4 ethernet ports, for me the issue is
>> not blocking. I hope someday someone encounters the same problem and
>> finds a solution.
>>
> This story has a happy end. I fixed it by running the firmware
> installer. The firmware installer is in the 'Lifecycle controller' BIOS.
> It can download the firmware from a dell ftp server, and allows a
> firmware 'upgrade' even if the newest firmware version is the same as
> currently installed.
>
> Now that I can restore the situation, I could replay this again if
> anyone is interested. I could install the firmware-linux-nonfree package
> and see if the problem occurs again. I will have physical access to this
> machine on Wednesday only. After that, it's co-located.
permanent, either in EPROM or flash, and one is volatile. The permanent
one is what you upgraded from FTP. I'd guess that what happened here is
that the version of the volatile firmware loaded by the Xen kernel isn't
compatible with this permanent firmware rev, for one reason or another,
or the wrong volatile firmware was loaded due to device
mis-identification, i.e. volatile firmware for one of the other
Broadcomm NICs was loaded. Some of the output you posted seemed to
suggest this may have been the case. I have seen such a problem before
but it is pretty rare.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lukas Zita
Apr 26, 2013, 1:20:01 PM4/26/13
to
I have encountered exactly the same problem. Got four new Dell servers
(2xR820, 2xR620), all with Broadcom 5720. I have installed Wheezy on all of
them, including Xen. But only on two of them, I have installed
firmware-linux-nonfree and only on ONE of them (namely R820), the NIC
behaves like Casper described. Which leads me to assumption, that it is not
related to Debian firmware package, but I can't confirm that, because i
don't know for sure if the problem has existed before the installation. To
clarify: it gets more complicated, because if I run Lifecycle Manager, the
NIC initializes to some state where it can be used in Wheezy, until next
complete power disconnect. And before first installation I was of course in
LCM.
I have spent last few days with thorough testing and got to these
conclusions:
- downgrading/upgrading firmware through Dell firmware utility didn't help
for me
- under 2.6.32 kernel (tested with Centos), NIC works ok
- under 3.x.x kernel NIC fails (tested with stock kernel in Wheezy, Ubuntu
12.04 and ELREPO kernel 3.8.8 in Centos)
- drivers ver.3.124 directly from Broadcom compiled against Wheezy kernel,
behave the same
Then I have noticed small patch in 3.2.43: "tg3: fix length overflow in VPD
firmware parsing", so I have compiled vanilla kernel and got the NIC working
correctly. I will yet try to apply this patch on stock Wheezy kernel, but I
believe that the problem lies there. Hard to tell why only one card from
four tested should return bad value to break the driver, but who knows.
--
View this message in context: http://debian.2.n7.nabble.com/Wheezy-issue-with-broadcom-5720-nic-on-new-dell-PowerEdge-R720-tp2892237p2922675.html
Sent from the Debian User mailing list archive at Nabble.com.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1366996406918...@n7.nabble.com
(2xR820, 2xR620), all with Broadcom 5720. I have installed Wheezy on all of
them, including Xen. But only on two of them, I have installed
firmware-linux-nonfree and only on ONE of them (namely R820), the NIC
behaves like Casper described. Which leads me to assumption, that it is not
related to Debian firmware package, but I can't confirm that, because i
don't know for sure if the problem has existed before the installation. To
clarify: it gets more complicated, because if I run Lifecycle Manager, the
NIC initializes to some state where it can be used in Wheezy, until next
complete power disconnect. And before first installation I was of course in
LCM.
I have spent last few days with thorough testing and got to these
conclusions:
- downgrading/upgrading firmware through Dell firmware utility didn't help
for me
- under 2.6.32 kernel (tested with Centos), NIC works ok
- under 3.x.x kernel NIC fails (tested with stock kernel in Wheezy, Ubuntu
12.04 and ELREPO kernel 3.8.8 in Centos)
- drivers ver.3.124 directly from Broadcom compiled against Wheezy kernel,
behave the same
Then I have noticed small patch in 3.2.43: "tg3: fix length overflow in VPD
firmware parsing", so I have compiled vanilla kernel and got the NIC working
correctly. I will yet try to apply this patch on stock Wheezy kernel, but I
believe that the problem lies there. Hard to tell why only one card from
four tested should return bad value to break the driver, but who knows.
--
View this message in context: http://debian.2.n7.nabble.com/Wheezy-issue-with-broadcom-5720-nic-on-new-dell-PowerEdge-R720-tp2892237p2922675.html
Sent from the Debian User mailing list archive at Nabble.com.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lukáš Zíta
Apr 27, 2013, 7:10:01 AM4/27/13
to
Dne 26.4.2013 19:13, Lukas Zita napsal(a):
unfortunately applying mentioned fix didn't solve the problem. But after
comparing Wheezy source of tg3.c with vanilla 3.2.44 and some searching,
I have found that these patches:
http://patchwork.ozlabs.org/patch/108859/
http://patchwork.ozlabs.org/patch/144848/
Are applied in Wheezy, but not in vanilla. Can't find why, but maybe
because the support for queue limit was buggy?
It is beyond my knowledge of current kernel development to do more
debugging and try to find why these calls fail only on some NIC, but
maybe it could be safe to remove those two patches from Wheezy? It's
just a guess based on their absence in upstream.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/517BAD63...@archa.cz
> Then I have noticed small patch in 3.2.43: "tg3: fix length overflow in VPD
> firmware parsing", so I have compiled vanilla kernel and got the NIC working
> correctly. I will yet try to apply this patch on stock Wheezy kernel, but I
> believe that the problem lies there.
So I have finished more tests with compilation of Wheezy kernel and
> firmware parsing", so I have compiled vanilla kernel and got the NIC working
> correctly. I will yet try to apply this patch on stock Wheezy kernel, but I
> believe that the problem lies there.
unfortunately applying mentioned fix didn't solve the problem. But after
comparing Wheezy source of tg3.c with vanilla 3.2.44 and some searching,
I have found that these patches:
http://patchwork.ozlabs.org/patch/108859/
http://patchwork.ozlabs.org/patch/144848/
Are applied in Wheezy, but not in vanilla. Can't find why, but maybe
because the support for queue limit was buggy?
It is beyond my knowledge of current kernel development to do more
debugging and try to find why these calls fail only on some NIC, but
maybe it could be safe to remove those two patches from Wheezy? It's
just a guess based on their absence in upstream.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lukáš Zíta
May 2, 2013, 9:30:04 AM5/2/13
to
After some more tests, I have discovered, that those missing
patches are part of BQL backport to 3.2 kernel (therefore their absence
in upstream 3.2). In the end it turned out, that the NIC is buggy even
with BQL disabled. Strange thing is, that the bug only appears on newer
types of Dell servers, namely R820 and R720. Same card (I have even
switched them between machines) although do work on R320 and R620 with
same version of the kernel.
I can not think another way to handle this, so I will have to switch toa card from Intel.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51826920...@archa.cz
patches are part of BQL backport to 3.2 kernel (therefore their absence
in upstream 3.2). In the end it turned out, that the NIC is buggy even
with BQL disabled. Strange thing is, that the bug only appears on newer
types of Dell servers, namely R820 and R720. Same card (I have even
switched them between machines) although do work on R320 and R620 with
same version of the kernel.
I can not think another way to handle this, so I will have to switch toa card from Intel.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
May 3, 2013, 3:10:01 AM5/3/13
to
On 5/2/2013 8:24 AM, Lukáš Zíta wrote:
> After some more tests, I have discovered, that those missing
> patches are part of BQL backport to 3.2 kernel (therefore their absence
> in upstream 3.2). In the end it turned out, that the NIC is buggy even
> with BQL disabled. Strange thing is, that the bug only appears on newer
> types of Dell servers, namely R820 and R720. Same card (I have even
> switched them between machines) although do work on R320 and R620 with
> same version of the kernel.
>
> I can not think another way to handle this, so I will have to
> switch toa card from Intel.
To those people who may wonder why/how others often end up with boxes
> After some more tests, I have discovered, that those missing
> patches are part of BQL backport to 3.2 kernel (therefore their absence
> in upstream 3.2). In the end it turned out, that the NIC is buggy even
> with BQL disabled. Strange thing is, that the bug only appears on newer
> types of Dell servers, namely R820 and R720. Same card (I have even
> switched them between machines) although do work on R320 and R620 with
> same version of the kernel.
>
> I can not think another way to handle this, so I will have to
> switch toa card from Intel.
full of brand new 'perfectly good' hardware that may never be used...
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Helmut Wollmersdorfer
May 6, 2013, 3:50:02 AM5/6/13
to
Am 03.05.2013 um 09:01 schrieb Stan Hoeppner:
> On 5/2/2013 8:24 AM, Lukáš Zíta wrote:
>>
>> I can not think another way to handle this, so I will have to
>> switch toa card from Intel.
>
> To those people who may wonder why/how others often end up with boxes
> full of brand new 'perfectly good' hardware that may never be used...
In my case the two Dell Poweredge R520 have the built in BCM5716 (2
heads), and an Intel 82576 (2 heads). For more performance I ordered
additional 2 Intel 82576. But two Intel 82576 do not work in one
machine (AFAIK a known kernel module problem of kernel 2.6.32.
So I use these expensive NICs in spare/testing machines;-)
BTW: Is there an easy way to get the version of a kernel module
directly from kernel source tree? I.e. without installing the kernel.
Helmut Wollmersdorfer
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages