82546GB tx startup

[kostikbel]

I wrote a special purpose driver for 82546GB (Linux/x86, 2.6.x kernels) for some proprietary appplication. I reused e1000_hw from Linux e1000 driver for PHY/MAC handling. The TX/RX rings management
is mine.

Driver works with some strange glitch: tx unit starts only after several hw resets. More details: after
I put device UP, rx unit starts ok and receive packets. tx descriptors are programmed in legacy mode (DEXT == 0) with RS | IDE | EOP bits set in cmd field. After filling descs, I increment TDT. After 1 sec, I got the following strange situation:
TDH == TDT > 0, but status.DD bit for descriptors behind TDH is still zero, and packets are not sent to the wire. Below is appropriate log with semi-obvious field tags:

E1000 02:05.1: Tx HANG TDH 4 TDT 4 next_to_use 4 next_to_clean 0 dma 1dc02000 timestamp 172dcb2 jiffies 172dea7 status 0 cmd 89 length 64 cso 0 css 0 spec 0

On tx hang, I do a full hw reset (DOWN/UP cycle). After several (usually 1-2) resets on timeouts, tx unit starts working. I obtain full 1Gb bandwith without further tx hangs.

I'm completely out of ideas why. The most fishy issue is that the TDH is moved by card (I do clear TDT and TDH on reset). If it stall, it would be definitely my bug. But TDH moves.

Any help ?

[Intel_Software_Netw1]

Greetings from the Intel Software Network.

Your design inquiry will require a closer look by an Intel Product Representative.

If your company has its own Intel representative, you may wish to inquire whether they are able to assist with this inquiry. Your company's Purchasing Department will normally have your Intel representative's contact information. If you have no contact, please see http://www.intel.com/buy/networking/design.htm under "Design Components".

If your location is not listed, please see an Intel Authorized Distributor and ask for a Field Application Engineer (FAE). Our Intel Authorized Distributor list is also linked from the URL above.

I hope this helps.

Best regards,
Jim A
Intel Software Network Support
http://www.intel.com/software

Intel is a registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.

*Other names and brands may be claimed as the property of others.

Message Edited by intel.software.network.support on 12-07-2005 12:41 PM

[wschen]

I have the same problem with TX descriptor write back hang.
When I up port A and port B, then port A will have no ICR.TXDW interrupts after one or two TX packets. The status.DD bit for descriptors behind TDH is still zero, and port B always works fine.
When I only up port A and let port B down, the TX hang will not happen.
Any help ?

[kostikbel]

Just for history, I did found the reason for my problem. As usual, theinsight come in immediately after the question is asked. In my case, I turned transmitter on before initializing TDH/TDT registers (just two lines were swapped - stupid me). As result, TDT was forwarded over garbage Tx descriptors to the TDH. Both ports on my 82546GB work without problems since then, providing full 1Gb throughput on each port !

[wschen]

Thanks for your reply.
I'm sure that I initialize TDH/TDT registers before turn on TCTL.EN.
The strange thing is that TX hang of Port A only take place when Port B is UP.
Is this a hardware problem?

[kostikbel]

In this situation I would start checking whether you programmed the right PCI device function (i.e, does your code selects right port when accessing registers). Otherwise, I have no idea why this could happens.

[wschen]

I use Intel official release linux driver(6.2.15).
I think the driver is O.K.
In order to verify the driver, I buy an Intel PRO/1000 MT dual port adapter(82546GB based).
On the evaluation board with Intel adapter, both ports work fine at the same time.
On the other side only one port work correctly on our target board.
The difference of two platform are :
1.datecode of 82546gb chip 0502 FH41681.1 (target board)
2.different IDSEL and IRQ pin of CPU
3.power supply circuit
4.the other is based on Intel reference design

BTW, the ICR.TXQE seems could happen even I did not turn on this interrupt.

[kostikbel]

Aha. Embedded board ? Then, it could be bios. Check whether both functions are correctly configured. Especially look at the equal io and memory ranges for PCI resources.