From: Florian Fainelli <florian@openwrt.org>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: netdev@vger.kernel.org, kyle@mcmartin.ca
Subject: Re: tulip_rxtx_stop() on Cobalt Qube2
Date: Sun, 31 May 2009 23:02:22 +0200 [thread overview]
Message-ID: <200905312302.22608.florian@openwrt.org> (raw)
In-Reply-To: <20090531014036.GA23050@lackof.org>
Hi Grant,
Le Sunday 31 May 2009 03:40:36 Grant Grundler, vous avez écrit :
> Florian,
> Summary: proposed patch below for you to test (I've not tested it yet)
> and some explanation on what I think is happening.
>
>
> On Fri, May 01, 2009 at 12:38:57PM +0200, Florian Fainelli wrote:
> ...
>
> > Linux Tulip driver version 1.1.15-NAPI (Feb 27, 2007)
>
> ...
>
> > PCI: Enabling device 0000:00:0c.0 (0005 -> 0007)
> > tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using
> > substitute media control info.
> > tulip1: EEPROM default media type Autosense.
> > tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
> > block. tulip1: MII transceiver #1 config 1000 status 7809 advertising
> > 01e1. eth1: Digital DS21142/43 Tulip rev 65 at MMIO 0x12082400,
> > 00:10:e0:00:88:b9, IRQ 20.
> > [snip]
> > 0000:00:07.0: tulip_stop_rxtx() failed (CSR5 0xf0660000 CSR6 0xb20e2202)
>
> Looking up these bits in the publicly available manual:
> ftp://download.intel.com/design/network/manuals/27807401.pdf
>
> "Rev 65" == 0x41 == 21143-PD or 21143-TD (page 3-7)
>
> Operation Mode Register (CSR6ÂOffset 30H)
> ----
> bit : Val
> 31 : 1 Special Capture Effect Enable
> 30 : 1 Receive All
> 13 : 1 ST - Start Transmission
> 9 : 1 Full Duplex
> 1 : 1 SR - Start Receive
>
> Status Register (CSR5ÂOffset 28H)
> ----
> 28-31 : reserved
> 23-25 : 0x6 TX State = Suspended--Transmit FIFO underflow, or an
> unavailable transmit descriptor 20-22 : 0x3 RX State = Running--Waiting for
> receive packet
> 1 : 0x0 TX isn't stopped
> 0 : 0x0 No TX Interrupt pending
>
> The RX/TX engines are in a wedged state to begin with. :(
I suppose this is due to the Bootloader, either CoLo or the original Cobalt
microservers bootloader.
>
> The normal calling path here is tulip_init() to register the driver
> callbacks and tulip_init_one() gets called immediately by pci subsystem.
> tulip_up() gets called after netdev registration when someone ifconfig's
> the device (ifconfig up). I don't know when else tulip_up() is called.
>
> I have two ideas on how to fix this:
> 1) reset the RX/TX engines in tulip_init_one() before tulip_stop_rxtx().
> 2) reset the RX/TX engines in tulip_stop_rxtx() if they are "wedged".
> 3) remove tulip_stop_rxtx() call in tulip_init_one()
>
>
> (1) seems like a reasonable thing to do at init time anyway.
> (2) feels like a pretty big hammer and I don't know all the side effects.
> (3) tulip_up() will reset the RX/TX engine and call tulip_stop_rxtx()
> when the NIC is opene/ifconfig'd. Calling pci_set_master()
> will allow the device to scribble into Host Memory...probably
> should move that call to tulip_up() as well. But I don't see anything
> in tulip_init_one() that requires DMA (and thus pci_set_master()).
>
> Is there any reason for NOT implementing (1) and (3)?
>
> I still need to work out where to call pci_set_master() in
> tulip_up(). If that's feasible,
>
> hrm. WTF. tulip_stop_rxtx() is called again from tulip_up() right before
> CSR6 is written. Earlier in tulip_up() we reset the chip. Removed.
>
> Can you test the patch below?
>
> I have not tested or even compiled this patch...will do so on parisc/ia64
> machines once I get some feedback on this patch.
>
> And I just noticed pci_clear_master() is not called *anywhere*. :(
> Need to add such a call after tulip_stop_rxtx() some place (many places?).
> This patch is just RFC and not suitable for merging upstream.
The patch below does not help on my Qube2, I am still having the same message
appearing.
>
> many thanks,
> grant
>
>
> diff --git a/drivers/net/tulip/tulip_core.c
> b/drivers/net/tulip/tulip_core.c index 2abb5d3..1aa058e 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -470,11 +470,12 @@ media_picked:
> tulip_select_media(dev, 1);
>
> /* Start the chip's Tx to process setup frame. */
> - tulip_stop_rxtx(tp);
> barrier();
> udelay(5);
> iowrite32(tp->csr6 | TxOn, ioaddr + CSR6);
>
> + pci_set_master(pdev); /* enabled DMA */
> +
> /* Enable interrupts by setting the interrupt mask. */
> iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR5);
> iowrite32(tulip_tbl[tp->chip_id].valid_intrs, ioaddr + CSR7);
> @@ -1422,11 +1423,6 @@ static int __devinit tulip_init_one (struct pci_dev
> *pdev, tulip_mwi_config (pdev, dev);
> #endif
>
> - /* Stop the chip's Tx and Rx processes. */
> - tulip_stop_rxtx(tp);
> -
> - pci_set_master(pdev);
> -
> #ifdef CONFIG_GSC
> if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP) {
> switch (pdev->subsystem_device) {
--
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------
next prev parent reply other threads:[~2009-05-31 21:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 10:38 tulip_rxtx_stop() on Cobalt Qube2 Florian Fainelli
2009-05-03 11:32 ` Grant Grundler
2009-05-03 19:45 ` Florian Fainelli
2009-05-31 1:40 ` Grant Grundler
2009-05-31 21:02 ` Florian Fainelli [this message]
2009-05-31 23:43 ` Grant Grundler
2009-06-07 18:27 ` Florian Fainelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200905312302.22608.florian@openwrt.org \
--to=florian@openwrt.org \
--cc=grundler@parisc-linux.org \
--cc=kyle@mcmartin.ca \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.