Thanks, David. Some questions are as following:
> It depends, the locking changed significantly in the current > 2.6.13-rcX version of the driver. But before that: > > 1) ->hard_start_xmit() needs to hold the tx_lock with hard IRQs > disabled, as does tg3_tx(). It uses NETIF_F_LLTX locking, > thus the callers do not grab netdev->xmit_lock and thus do > not guarentee atomic invocation of the driver's > ->hard_start_xmit method. So the tg3_tx() and tg3_start_xmit do not include any code of reprogramming the hardware? > > 2) Interrupt processing needs to hold ->lock with hard IRQs > disabled. As does any code which wants to reprogram the > hardware. > What kinds of code can be classifed to reprogramming the hardware? Should the tw32_t/rx_mbox and tw32_mailbox operation be classified into this catalog? > 3) tg3_rx() runs without locks held because ->poll() calls are > guarenteed to be atomic. > > 4) Any piece of code which wants to significantly reprogram the > tg3 chip must: > > a) shut down ->poll() processing by doing tg3_netif_stop() > b) grabbing ->lock with HW irqs disabled > c) grabbing ->tx_lock > > The unlocking afterwards must be done in the precise reverse > order. > > You could have figured this out by simply reading the driver > and looking at how the locks are used. I merely translated the > code into english, and also there is a big fat comment at the > top of "struct tg3" describing how the locks are used. I did > not put that comment there for my health. :-) > > You also can turn on spinlock debugging to try and figure out > any SMP hang problems you might be seeing as well. > Should I recompile the kernel to turn on splinlock debugging? Another problem is about the Flushing the Status block to host memory. In your original code, this is done by tr32(MAILBOX_INTERRUPT_0+TG3_64BIT_REG_LOW). However, as I add this line into my tx_clean code, if there is no packet comming in, it can only send out about 5000 packets/s. If this line is removed, then I cannot clean anything if no packet comming in. In both case, if there are packets comming in, .ie. the rx code is executed, the tx buffer can be cleaned correctly, and packets can be sent out fastly. What's the possible problem do you think? Thanks. Qinghua - 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
