From: Denis V. <vd...@il...> - 2005-09-24 12:54:20
|
On Saturday 24 September 2005 15:22, Carlos Martin wrote: > On 24/09/05, Denis Vlasenko <vd...@il...> wrote: > > On Saturday 24 September 2005 14:17, Carlos Martin wrote: > > > > > > Can you try hot unplugging your usb device and look into log? > > > > > > > > > > issue_cmd says it fails and prints a trace for each command. The flag > > > > > to say it's unplugged seems like a very good idea now :) > > > > > > > > Please send me the log. Or logs of several unplugs, if they are different. > > > > For some stress testing, you may want to initiate a few parallel flood pings > > > > and large downloads, and then unpug and see what happens. > > > > > > I'll get some. There is also some locking badness going on on ip l set > > > wlan0 up, but I only hit it once, I'll try to get it to work later on. > > > I think I'll have to dig out the AP to see if it connects. I've been > > > trying using the wi-fi internet service we have here, but it's not > > > working. I think it's too far away. > > > > One easy (but tx only) test which does not require any peer > > is configuring master mode and pinging bcast addr: > > > > # iwconfig wlan0 essid acx mode master > > # ip l set dev wlan0 up > > # ip a a 2.2.2.1/24 brd + dev wlan0 > > # ping -b 2.2.2.255 -i0.01 -c1000 > > Yeah, but I was thinking about pushing megs through it. > > Here's the log of plug/unplug. On the first plug, there's no memory. > I'm running -rc2-mm1 so I don't know if it's a problem there. The > second and third time are alright, though. > > Think I should report the memory thing on lkml? it's a 4 order (16 _contiguous_ free pages, 64k total, were not found) allocation failure. Not surprising. That's because our struct wlandevice is too damn big. Mayor offenders are 32 client structures each with ~80 bytes of rarely used challenge field and USB transfer buffers (16 buffers of >2k each): struct client { ... /* FIXME: this one is too damn big */ char challenge_text[WLAN_CHALLENGE_LEN]; }; struct wlandevice { ... client_t sta_list[32]; ... rxbuffer_t rxtruncbuf; /* TODO: convert (bulkins,bulkrx_urbs,rxcons) triple into ** struct usb_rx (see struct usb_tx for an example) */ rxbuffer_t bulkins[ACX100_USB_NUM_BULK_URBS]; struct urb *bulkrx_urbs[ACX100_USB_NUM_BULK_URBS]; /* Used by rx urb completion handler in order to find ** corresponding priv/index pair */ acx_usb_bulk_context_t rxcons[ACX100_USB_NUM_BULK_URBS]; usb_tx_t usb_tx[ACX100_USB_NUM_BULK_URBS]; Feel free to allocate usb_tx's with separate kmalloc: - usb_tx_t usb_tx[ACX100_USB_NUM_BULK_URBS]; + usb_tx_t* usb_tx[ACX100_USB_NUM_BULK_URBS]; (Same for usb_rx_t when someone will heed that TODO above) About commands on unplug: usb 1-2: USB disconnect, address 5 18844835 ==> acx100usb_e_disconnect usb.c:661: sem_down 1 -> 0 18844835 ==> acxusb_s_issue_cmd_timeo_debug issue_cmd(cmd:ACX1xx_CMD_DISABLE_RX,buflen:0,type:0xFFFFFFFF) ctrl inpipe=0x80000580 outpipe=0x80000500 sending USB control msg (out) (blocklen=4) 05 00 00 00 wrote -19 bytes -19 == ENODEV wlan0: issue_cmd(cmd:ACX1xx_CMD_DISABLE_RX) FAILED [<ddc93f38>] acxusb_s_issue_cmd_timeo_debug+0x3a8/0x430 [acx] [<ddc944a3>] acx100usb_e_disconnect+0x63/0x270 [acx] [<c02e9266>] usb_disable_interface+0x26/0x40 [<c02e13a4>] usb_unbind_interface+0x74/0x80 [<c0294455>] __device_release_driver+0x85/0xb0 [<c02944a5>] device_release_driver+0x25/0x40 We may special case ENODEV so that we do not annoy user with stacktrace: + if (result == -ENODEV) { + acxlog(L_CTL, "ENODEV (device was unplugged?)\n"); + goto bad_silent; + } acxlog(L_CTL, "wrote %d bytes\n", result); if (result < 0) { goto bad; } ... dump_stack(); +bad_silent: FN_EXIT1(NOT_OK); return NOT_OK; } Stress tests: I suggest writing script which do while true; do <modprobe/configure wlan0>; <start some traffic for ~10 seconds (ping -cN ?)>; <rmmod>; done start it, and plug/unplug device randomly. May produce interesting fireworks in the logs. 8) -- vda |