On 07-01-04 12:36 Jon Smirl wrote:

> I'm having a hard time tracking down why my copy tests keep failing.
> The Ralink based hardware I ordered has shown up and it is failing in
> exactly the same way as the Zd1211b hardware.
> 
> The failure seems to be aggravated by another task using the link. For
> example I have a copy test running and IM is polling in the background
> or I use a browser. After a random number of actions from the other
> tasks the copy commands hang. Copy commands still hang without the
> other tasks but it takes much longer.
> 
> This made me suspect SMP. So I turned it off and nothing changed.
> 
> Also, it is only the copy session that is fatally disrupted. The
> wireless link is still there. The copy command can be hung but the
> browser still works.
> 
> If I boot WIndows on the same hardware I can copy all day without
> failure and at higher rates.
> 
> I have no proof but I starting to suspect that the problem may be in
> the 80211 stack and not the drivers. Maybe an error return is being
> reported by the driver and the 80211 stack is not properly acting on
> it.
> 
> dmesg from hung copy attempt:
> [  343.470323] usb 5-1.4: handle_retry_failed_int() retry failed interrupt
> [  343.874560] usb 5-1.4: handle_retry_failed_int() retry failed interrupt
> [  358.009828] usb 5-1.4: handle_retry_failed_int() retry failed interrupt
> [  369.019011] usb 5-1.4: handle_retry_failed_int() retry failed interrupt
> [  373.874327] usb 5-1.4: rx_urb_complete() *** first fragment ***
> [  373.874340] usb 5-1.4: rx_urb_complete() *** second fragment ***
> [  376.299253] usb 5-1.4: handle_retry_failed_int() retry failed interrupt
> [  453.389178] smb_add_request: request [f5096e80, mid=24158] timed out!
> [  483.338505] smb_add_request: request [f5096e80, mid=24159] timed out!
> [  513.292077] smb_add_request: request [f5096e80, mid=24160] timed out!
> [  524.723562] zd1211rw 5-1.4:1.0: zd_mac_rx() Packet with length 22 to small.
> [  530.917599] zd1211rw 5-1.4:1.0: zd_mac_rx() Packet with length 22 to small.
> [  543.241833] smb_add_request: request [f5096e80, mid=24161] timed out!
> [  573.191172] smb_add_request: request [f5096e80, mid=24162] timed out!
> [  584.477938] zd1211rw 5-1.4:1.0: zd_mac_rx() Packet with length 22 to small.
> [EMAIL PROTECTED]:~/foo$
> 
> Could the fragmented urb not have gotten reassembled correctly?
> I also don't understand why the retry of the smb commands doesn't get 
> restarted.

Jon, I add to Daniel's mail some explanations. Network interfaces
don't guarantee packet delivery. This is not a problem for TCP,
because TCP will automatically retransmit packets not delivered to
the other side. UDP doesn't have such mechanism and classical SMB
is an UDP protocol, so the upper layer protocols need to handle
the retransmits. smbfs seems to have a very simple strategy
retransmit the request after 30 seconds. This is far to long. Try
CIFS as an alternative.

Uli

-- 
Uli Kunitz

-------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Reply via email to