Hello, I 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.
2. Here is how kgdb uses polling mechanism for communication to gdb.
kgdb calls netpoll_set_trap(1) just before entering a loop where it
communicates to gdb. It calls netpoll_set_trap(0) after it is done and
wants to resume a kernel. The communication to gdb goes through
netpoll_poll (which calls kgdb rx_hook) and netpoll_send_udp functions.
3. A queue for an interface may have been stopped by it's driver by
calling netif_stop_queue. After this if kgdb attempts to enter
communication with gdb, it'll call netpoll_set_trap(1), after which
the queue can't be started again. This is a potential deadlock
situation. Is there a way out of this?
4. Is it necessary to call netpoll_set_trap(1) at all before entering
gdb communication loop? Even if a driver stops the queue in middle of
the communication netpoll_poll and netpoll_send_udp calls can recover
from that by calling driver's interrupt and poll routines. Is this a
valid statement?
I'd like to return to this again (having received no feedback)...
The idea is to change how CONFIG_NETPOLL_TRAP is implemented: instead of
completely bypassing queue locking after netpoll_set_trap(1) has been
called, how about we set and chack some other flag (internal to netpoll)
telling it that the queue is frozen, i.e. watch the queue state using a
separate mechanism when traffic trapping is engaged? This certainly
Well, this certainly won't work, as the bit should be tied to struct
net_device. The first idea was more sound: just set/reset __LINK_STATE_XOFF
flag, not calling __netif_schedule(), i.e. remove #ifdef from
netif_stop_queue() and replace return stmt in netif_wake_queue() by
clear_bit(__LINK_STATE_XOFF, &dev->state).
would avoid TX queue overflows in drivers while also avoiding any
dev->state changes and even worse evil __netif_schedule() call, i.e.
things that CONFIG_NETPOLL_TRAP is currectly trying to avoid, AFAIU...
I think I'll submit a patch -- netpoll traffic trapping is pretty broken
as it is now.
Thanks a lot.
-Amit
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
