[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45F7FBC8.9050700@ru.mvista.com>
Date: Wed, 14 Mar 2007 16:42:32 +0300
From: Sergei Shtylyov <sshtylyov@...mvista.com>
To: "Amit S. Kale" <amitkale@...syssoft.com>
Cc: netdev@...r.kernel.org, Mithlesh Thukral <mithlesh@...syssoft.com>,
Vitaly Wool <vwool@...mvista.com>, Mark Huth <mhuth@...sta.com>
Subject: Re: [Kgdb-bugreport] [PATCH 2.6.20-rc7] 8139too KGDBoE fix
Hello.
Amit S. Kale 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 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...
> Thanks a lot.
> -Amit
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists