Stephen Hemminger wrote:

This thread came up on kgdb-bugreport mailing list. Could you please suggest us what's the correct way of fixing this problem?

1. When running a kgdb on RTL8139 ethernet interface: 8139too driver prints too many "Out-of-sync dirty pointer" messages on console and gdb can't connect to kgdb stub. These messages can be suppressed, though it still results in connection failures frequently.

We think this comes from calling the driver while the queue is stopped. Drivers should not do horrible things when hard start is called with the queue stopped, but unfortunately, at this time, at least some drivers do explode or complain under that condition.

The kernel is built on a set of assumptions about calling context. Your
out of tree code is violating one of them. Why not check for stopped queue
and do some action to try and clear it, that is what netconsole does.

The queue can't be stopped when the netpoll traffic trapping is enabled (cause this effectively bypasses queue control), So, the stopped queue indoication doesn't work also -- *that* is the problem. It's not at all specific to KGBoE -- only to traffic trapping.

You can't ask a device to send a packet when it has no resources.

When traffic trapping is enabled, and driver stops the queue, the __LINK_STATE_XOFF flag does *not* get set, so netif_queue_stopped() resturns *zero*. What may be done in this situation?

Read netpoll_send_skb()

        int status = NETDEV_TX_BUSY;
...
                if (netif_tx_trylock(dev)) {
                        /* try until next clock tick */
                        for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
                                        tries > 0; --tries) {
                                if (!netif_queue_stopped(dev))
                                        status = dev->hard_start_xmit(skb, dev);

                                if (status == NETDEV_TX_OK)
                                        break;

                                /* tickle device maybe there is some cleanup */
                                netpoll_poll(np);

                                udelay(USEC_PER_POLL);
                        }
                        netif_tx_unlock(dev);

netpoll_poll() allows device to try and cleanup transmit resources.

   Read <linux/netdevice.h>:

static inline void netif_stop_queue(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL_TRAP
        if (netpoll_trap())
                return;
#endif
        set_bit(__LINK_STATE_XOFF, &dev->state);
}

static inline int netif_queue_stopped(const struct net_device *dev)
{
        return test_bit(__LINK_STATE_XOFF, &dev->state);
}

When the driver calls netif_stop_queue() having his TX queue filled to the brim (4 buffers in case of 8139too) and netpoll_trap() returns 1, what will happen?

WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to