On 2009-07-02 18:42, Matt Carlson wrote:
quoted text
> On Tue, Jun 30, 2009 at 02:20:45AM -0700, Jean-Louis Dupond wrote:
>> # ethtool -i eth0
>> driver: tg3
>> version: 3.97
>> firmware-version: 5722-v3.08, ASFIPMI v6.02
>> bus-info: 0000:01:00.0
>>
>> Kernel version 2.6.29.4
>
> Rats.  I mirrored your setup here, but I still can't reproduce the
> problem.  I still suspect this is a bad driver<=>  firmware interaction.
>
> Can you apply the following patch and show me the resulting syslog
> entries?  The patch is just making sure the firmware request to shutdown
> really goes through.
>
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 46a3f86..900e28b 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -1124,6 +1124,9 @@ static void tg3_wait_for_event_ack(struct tg3 *tp)
>   			break;
>   		udelay(8);
>   	}
> +
> +	if (i == delay_cnt)
> +		printk( KERN_WARNING "Firmware didn't ack driver event!\n" );
>   }
>
>   /* tp->lock is held. */
> @@ -6330,12 +6333,16 @@ static void tg3_stop_fw(struct tg3 *tp)
>   		/* Wait for RX cpu to ACK the previous event. */
>   		tg3_wait_for_event_ack(tp);
>
> +		printk( KERN_NOTICE "%s: Stopping firmware.\n", tp->dev->name );
> +
>   		tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX, FWCMD_NICDRV_PAUSE_FW);
>
>   		tg3_generate_fw_event(tp);
>
>   		/* Wait for RX cpu to ACK this event. */
>   		tg3_wait_for_event_ack(tp);
> +
> +		printk( KERN_NOTICE "%s: Operation completed.\n", tp->dev->name );
>   	}
>   }
>
> @@ -7537,6 +7544,8 @@ static void tg3_timer(unsigned long __opaque)
>   		    !(tp->tg3_flags3&  TG3_FLG3_ENABLE_APE)) {
>   			tg3_wait_for_event_ack(tp);
>
> +			printk( KERN_NOTICE "%s: Sending keepalive event.\n", tp->dev->name );
> +
>   			tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX,
>   				      FWCMD_NICDRV_ALIVE3);
>   			tg3_write_mem(tp, NIC_SRAM_FW_CMD_LEN_MBOX, 4);

Hello,

Have you been able to solve this issue? I have a similar problem with 
Dell PowerEdge R300 servers connected to HP2610 100Mbps switches. The 
servers contain two BCM5722 NICs and after a reboot, with probability 
about 70%, I end up with 10Mbps HD mainly on the first NIC.

I discovered that it is enough to run:
  /sbin/mii-tool -R eth0
  /sbin/mii-tool -R eth1
to trigger renegotiation that brings expected 100Mbps FD. For now, I 
added this to my startups scripts as a workaround.

This problem exists in 2.6.30-stable, 2.6.31-stable and 2.6.34-stable 
which I'm currently running.

Best regards,

			Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html