Hello, I wrote:
>>>>>>>Even with this patch, the packets probably get stuck somewhere in the
>>>>>>>driver, as cross-gdb sees tail of the $g packet reply only in reply to
>>>>>>>next packet...
>>> This wasn;t happeing on x86 probably because the register packet should
>>>be much shorted there than on PPC...
>>>>>> Argh! That's all because of the CONFIG_NETPOLL_TRAP that
>>>>>>CONFIG_KGDBOE* options select -- since the initial breakpoint enables
>>>>>>trapping via KGDBoE's pre_exception() handler, netif_{stop/wake}_queue()
>>>>>>stop to work and that causes KGDBoE to literally flood 8139too with
>>>>>>packets (although it can't queue up more than 4). Looks like a general
>>>>>>design issue to me... :-/
>>>>> Well, maybe not. But many drivers are surely unprepared to their
>>>>>hard_start_xmit() method being called with queue alraedy stopped and
>>>>>those with small TX queue (like natsemi with which we're also having
>>>>>trouble) would get flooded as well. I'm going to submit a patch to
>>>>>netdev adding extra check for TX ring being full -- after/if it gets
>>>>>accepted, this patch won't be needed anymore.
>>>>Here is what comes to my mind right away. It might need some more
>>>>polishing or cleaning up:
>>>>A potential solution will be to check the if hard_start_xmit() returns
>>>>NETDEV_TX_BUSY. In case transmit queue is busy (due to lot of threads or
>>>>queue getting full), we should wait in netpoll_send_skb(), call a cleanup
>>>>through poll() and then retry sending packet.
>>> This is already being done by netpoll iself. The thing is that
>>>hard_start_xmit() doesdn't return NETDEV_TX_BUSY in those drivers. :-/
>>In addition to that we set trapped. I wonder whether it is possible that a
>>queue is stopped and we enter kgdb. It would be a deadlock.
>>-Amit
> Why? Netpoll does call the driver's interrupt and NAPI handlers in that
> case (until the retry count is 0).
Ah, got it -- since the traffic trapping (when enabled) effectively
bypasses netif_wake_queue(), a queue would never be actually woken up.
Maybe it's worth to always return 0 from netif_queue_stopped() in this case?
Or maybe the correct thing to do when trapping is to just thiddle the
__LINK_STATE_XOFF bit, bypassing call to netif_schedule()?
>>>>Regards,
>>>>Mithlesh Thukral
WBR, Sergei
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
