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?
No way but at least "emulate" the queue controls...
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?
It seems that having queue control working as usual is dangerous in case
of KGDB being active: this leads to wake_softirqd() being called, which seems
undesirable (there has been report about the eventual lockup trying to get
runqueue lock).
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.
Well, I hadn't yet discovered npinfo member of net_device before saying
that. :-)
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
