Re: tg3: link is permanently down after ifdown and ifup
On Thu, 2009-11-19 at 08:08 -0800, Felix Radensky wrote: > Hi, > > The problem goes away if I remove the call to > > tg3_set_power_state(tp, PCI_D3hot); > > from tg3_close(). Added Matt to CC. He is on vacation and may not be able to look into this right away. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Strange tg3 regression with UMP fw. link reporting
On Fri, 2008-08-08 at 15:05 -0700, Benjamin Herrenschmidt wrote: > On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote: > > We really shouldn't be displaying any error messages in the event of a > > timeout though. Earlier versions of the UMP firmware did not support > > the link update interface. The best thing the driver can do for all > > cases is give the firmware a chance to service the event but continue > > as if the event were serviced if it did not get an explicit ACK. > > But that means that the driver will continuously spin 2.5ms every > timer tick or so ? Or do I miss something ? Could it be possible to > count timeouts and if after N attempts at an ack, they all timed out, > disable the feature completely ? Please see my other email. Matt and I will fix it in a way to minimize the spin as much as possible regardless of firmware version. > > Or is there a way to test the version of the firmware ? > > In any case, the fix should go into -stable as the problem is hurting > 2.6.26. Also, should we consider updating the tg3 firmware on those > machines ? > Right, we'll take care of -stable as well. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange tg3 regression with UMP fw. link reporting
On Fri, 2008-08-08 at 11:43 -0700, Matthew Carlson wrote: > Segher is right. The code should be 2.5 milliseconds but is actually > much longer. This fix is actually already in my patch queue and needs > to be sent upstream. > Matt, I think we can optimize this a little more. The heart beat event is sent every second and the link event is sent whenever the link changes. the spin wait is only needed in rare cases when the link event is closer than 2.5 msec from the heart beat event. We can save the jiffies time stamp right after sending each event. Next time we need to send a heart beat or a link event, we check the jiffies with the stored time stamp. If they are less than 2.5 msec apart and we haven't received the ACK from the previous event yet, we just wait up to the remainder. It should be very rare that we have to wait. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
Olaf Hering wrote: > Yes, this patch fixes nfsroot for me. Thanks. > mii-tool is not shipped anymore, even in SLES10. > I assume that ethtool is the replacement? > Thanks. We'll send the patch to DaveM and to stable as well. ethtool can provide some high level link parameters. But in this case, I was trying to use mii-tool to look at the PHY registers to help debug the problem. ethtool would not provide that kind of information. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 10:15 -0700, Matt Carlson wrote:
> If you were to start with the original file, does the following patch
> fix the problem?
>
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 07b3f77..4c248d7 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int
> force_reset)
> err |= tg3_readphy(tp, MII_BMCR, &bmcr);
>
> if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset &&
> - (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT) &&
> - tp->link_config.flowctrl == tp->link_config.active_flowctrl) {
> + (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT)) {
> /* do nothing, just check for link up at the end */
> } else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
> u32 adv, new_adv;
>
Matt, I think that's very likely the problem. If we are trying to
establish link in parallel detect mode, the flow control settings may
not match. If we do not enter the if statement to do nothing, we will
keep autonegotiating forever and never establish link.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 17:49 +0200, Olaf Hering wrote: > On Thu, May 15, Michael Chan wrote: > > > Olaf Hering wrote: > > > > > Any ideas how to fix this? > > > What info do you need from the system? > > > > Are you using eth0 or eth1? The dmesg below shows that > > link came up on eth1 and IP address from DHCP was received. > > I'm using eth1. > The log was done with the patch reverted. > In that case, please re-apply the patch and provide mii-tool -vvv eth1. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
Olaf Hering wrote: > Any ideas how to fix this? > What info do you need from the system? Are you using eth0 or eth1? The dmesg below shows that link came up on eth1 and IP address from DHCP was received. > Sending DHCP requests .<6>tg3: eth1: Link is up at 1000 Mbps, > full duplex. > tg3: eth1: Flow control is off for TX and off for RX. > ., OK > IP-Config: Got DHCP answer from 10.10.4.97, my address is 10.10.1.110 > IP-Config: Complete: If you're using eth0 and link did not come up, please provide mii-tool -vvv eth0. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Sat, 2007-10-20 at 16:43 +1000, Michael Ellerman wrote:
> On Fri, 2007-10-19 at 17:53 -0700, David Miller wrote:
> > I don't see this, in all cases write_msi_msg() will transfer
> > the given "*msg" to entry->msg by this assignment in
> > drivers/pci/msi.c:
> >
> > void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> > {
> > ...
> > entry->msg = *msg;
> > }
> >
> > So as long as write_msi_msg() is invoked, it will be saved
> > properly.
> >
> > Platforms need not do this explicitly.
>
> I'm short on context here, and it's Saturday, so excuse me if I'm
> missing the point somewhere.
>
> On pseries machines we don't call write_msi_msg(), because we don't
> control the contents of the message, firmware does. So entry->msg will
> be bogus.
>
> That's a pity, but AFAIK it shouldn't be a problem because we don't
> enable CONFIG_PM on those machines anyway. If we ever want to we'll need
> to sort out with firmware how that will work WRT restoring MSI state.
>
The PCI error recovery that Linas is working on requires the MSI state
to be restored after we do PCI reset to recover from PCI errors.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
