[U-Boot] e1000 Rx timeout with 82541ER

Roy, Ben,
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes.
**** This is output of today's version :
U-Boot 2009.08-rc2-00025-g2bcbd42-dirty (Aug 19 2009 - 11:28:10)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0 ... Random delay: 734 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ###T T T T T T T T T T Retry count exceeded; starting again
**** This is output of v2009.6 :
U-Boot 2009.06-00185-g57fe301-dirty (Jun 22 2009 - 12:07:54)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0
Random delay: 815 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ################################################################# ##################################### done Bytes transferred = 1487889 (16b411 hex)
Using drivers/net/e1000.c from v2009.6 gives me back a working NIC, i.e. the problem is likely to be there.
Have you tried some PCI cards after the PCIe changes ?
Any ideas ?
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1250683805.22118.22.camel@swa-m460 you wrote:
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes.
Well, it should be straightforward to git-bisect this issue...
Best regards,
Wolfgang Denk

On Wed, 2009-08-19 at 14:58 +0200, Wolfgang Denk wrote:
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1250683805.22118.22.camel@swa-m460 you wrote:
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes.
Well, it should be straightforward to git-bisect this issue...
... not quickly ... and not straightforward for me. Never done this before and currently don't have much time. To start bisecting things I first need a clean sync with the public repository before I'll mess up my repo again ;-)
Maybe somebody already has a clue - I'm just asking.
Regards, André
Best regards,
Wolfgang Denk
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, August 19, 2009 7:58 AM To: André Schwarz Cc: Zang Roy-R61911; Ben Warren; U-Boot List Subject: Re: [U-Boot] e1000 Rx timeout with 82541ER
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1250683805.22118.22.camel@swa-m460 you wrote:
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot
of changes.
Well, it should be straightforward to git-bisect this issue...
Could you help to send me the error log? I do not have 82541ER card to try. Thank.s roy

On Thu, 2009-08-20 at 10:36 +0800, Zang Roy-R61911 wrote:
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, August 19, 2009 7:58 AM To: André Schwarz Cc: Zang Roy-R61911; Ben Warren; U-Boot List Subject: Re: [U-Boot] e1000 Rx timeout with 82541ER
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz,
In message 1250683805.22118.22.camel@swa-m460 you wrote:
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot
of changes.
Well, it should be straightforward to git-bisect this issue...
Could you help to send me the error log? I do not have 82541ER card to try.
ok - please give me some days. Hopefully I can send you some output/questions on tuesday.
Regards, André
Thank.s roy
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

-----Original Message----- From: André Schwarz [mailto:andre.schwarz@matrix-vision.de] Sent: Wednesday, August 19, 2009 7:10 AM To: Zang Roy-R61911; Ben Warren Cc: U-Boot List Subject: e1000 Rx timeout with 82541ER
Roy, Ben,
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes.
**** This is output of today's version :
U-Boot 2009.08-rc2-00025-g2bcbd42-dirty (Aug 19 2009 - 11:28:10)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0 ... Random delay: 734 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ###T T T T T T T T T T Retry count exceeded; starting again
**** This is output of v2009.6 :
U-Boot 2009.06-00185-g57fe301-dirty (Jun 22 2009 - 12:07:54)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0
Random delay: 815 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ################################################################# ##################################### done Bytes transferred = 1487889 (16b411 hex)
Using drivers/net/e1000.c from v2009.6 gives me back a working NIC, i.e. the problem is likely to be there.
Have you tried some PCI cards after the PCIe changes ?
I have tried 82545EM_COPPER, 82541GI_LF PCI card on 8544DS and 8536DS board.
Any ideas ?
Try to increase tx_pool and rx_pool to see whether there is improment. static char tx_pool[128 + 16]; static char rx_pool[128 + 16];
Change 128 to 256 or 512 to see. How about ping command?
Roy

Roy,
the problem is the modified PBA (packet buffer allocation) constant E1000_DEFAULT_PBA. It changed from 0x00000030 to 0x000a0026 lately.
Regarding to the Intel's software developer manual the chips come up with sane defaults. There are few which needs modification, like e.g. 82547GI/EI.
Having a look at the Kernel driver clearly shows that the programmed parameter depends on MAC type and using a fixed value for all chips is not reasonable at all.
In any case the 82540/1/2/3/4/5/6 are working perfectly fine with 0x00000030.
I'd recommend to revert this change and only apply the new default value to those MAC (PCIe ?) where you can verify functionality.
Regards, André
On Thu, 2009-08-20 at 23:41 +0800, Zang Roy-R61911 wrote:
-----Original Message----- From: André Schwarz [mailto:andre.schwarz@matrix-vision.de] Sent: Wednesday, August 19, 2009 7:10 AM To: Zang Roy-R61911; Ben Warren Cc: U-Boot List Subject: e1000 Rx timeout with 82541ER
Roy, Ben,
with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes.
**** This is output of today's version :
U-Boot 2009.08-rc2-00025-g2bcbd42-dirty (Aug 19 2009 - 11:28:10)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0 ... Random delay: 734 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ###T T T T T T T T T T Retry count exceeded; starting again
**** This is output of v2009.6 :
U-Boot 2009.06-00185-g57fe301-dirty (Jun 22 2009 - 12:07:54)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0
Random delay: 815 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x200000 Loading: ################################################################# ##################################### done Bytes transferred = 1487889 (16b411 hex)
Using drivers/net/e1000.c from v2009.6 gives me back a working NIC, i.e. the problem is likely to be there.
Have you tried some PCI cards after the PCIe changes ?
I have tried 82545EM_COPPER, 82541GI_LF PCI card on 8544DS and 8536DS board.
Any ideas ?
Try to increase tx_pool and rx_pool to see whether there is improment. static char tx_pool[128 + 16]; static char rx_pool[128 + 16];
Change 128 to 256 or 512 to see. How about ping command?
Roy
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

Andre and Roy, André Schwarz wrote:
Roy,
the problem is the modified PBA (packet buffer allocation) constant E1000_DEFAULT_PBA. It changed from 0x00000030 to 0x000a0026 lately.
Regarding to the Intel's software developer manual the chips come up with sane defaults. There are few which needs modification, like e.g. 82547GI/EI.
Having a look at the Kernel driver clearly shows that the programmed parameter depends on MAC type and using a fixed value for all chips is not reasonable at all.
In any case the 82540/1/2/3/4/5/6 are working perfectly fine with 0x00000030.
I'd recommend to revert this change and only apply the new default value to those MAC (PCIe ?) where you can verify functionality.
We're getting very close to the release date. Please supply a patch soon, or we'll revert Roy's original.
regards, Ben

I will provide a patch in two hours and need to andre to verify . Roy
-----Original Message----- From: Ben Warren [mailto:biggerbadderben@gmail.com] Sent: Friday, August 21, 2009 12:02 PM To: André Schwarz; Zang Roy-R61911 Cc: U-Boot List Subject: Re: e1000 Rx timeout with 82541ER
Andre and Roy, André Schwarz wrote:
Roy,
the problem is the modified PBA (packet buffer allocation) constant E1000_DEFAULT_PBA. It changed from 0x00000030 to 0x000a0026 lately.
Regarding to the Intel's software developer manual the chips come up with sane defaults. There are few which needs modification,
like e.g.
82547GI/EI.
Having a look at the Kernel driver clearly shows that the programmed parameter depends on MAC type and using a fixed value for
all chips is
not reasonable at all.
In any case the 82540/1/2/3/4/5/6 are working perfectly fine with 0x00000030.
I'd recommend to revert this change and only apply the new
default value
to those MAC (PCIe ?) where you can verify functionality.
We're getting very close to the release date. Please supply a patch soon, or we'll revert Roy's original.
regards, Ben
participants (4)
-
André Schwarz
-
Ben Warren
-
Wolfgang Denk
-
Zang Roy-R61911