Hello Oliver, I have attached a kernel log that covers the scenario I described below. Basically, this consists in the following steps: - connect USB device (T=~14:53:02) - send a command to the device to activate network connection (T=~14:53:33) - run "dhclient" on "usb0" interface (T=~14:54:00) The kernel I'm using is 2.6.30.5+your patch. I am hoping that you can make something out of it. There does not seem to be traces related with running the "dhclient" command. Instead, the device seems to remain in suspend state. Besides, dhclient is just telling me: DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 16 No DHCPOFFERS received. Thanks in advance, Regards, Greg. -----Original Message----- From: Greg Heinrich Sent: 09 September 2009 18:37 To: 'Oliver Neukum' Cc: Nicolas Chevillot; David Brownell; linux-usb@xxxxxxxxxxxxxxx; Carl Nordbeck Subject: RE: [rft]aggressive autosuspend for cdc-ether Hi Oliver, thanks for the speedy answer! I'll try to do as you suggest and report on progress later. Hopefully some time tomorrow! Regards, Greg. -----Original Message----- From: Oliver Neukum [mailto:oliver@xxxxxxxxxx] Sent: 09 September 2009 16:55 To: Greg Heinrich Cc: Nicolas Chevillot; David Brownell; linux-usb@xxxxxxxxxxxxxxx; Carl Nordbeck Subject: Re: [rft]aggressive autosuspend for cdc-ether Am Mittwoch, 9. September 2009 15:21:33 schrieb Greg Heinrich: Hi, > I have been playing with your cdc-ether patch for autosuspend. This is > mostly working however I have experienced some issues especially when > autosuspend is enabled before the cdc-ether virtual cable is connected. > In that case, the host usually fails to get an IP address from the DHCP > server. Sometimes it works, most of the times it doesn't. I have not yet > managed to understand what makes it fail/succeed. Please recompile your kernel with CONFIG_USB_DEBUG. This will increase debugging. It sounds like this happens if the device is suspended when the dhcp request should be done. But while this is very likely we need to confirm it. > I collected wireshark logs a few of the failing cases and it turns out > that the host does not send any DHCP_Discovery packets over the > cdc-ether interface. There are no obvious errors in the kernel logs. If nothing is sent, wireshark won't help. Verbosity of kernel logging must be increased. If CONFIG_USB_DEBUG doesn't do the job, you'll have to remove the comments from these lines // #define DEBUG // error path messages, extra info // #define VERBOSE // more; success messages in drivers/net/usb/usbnet.c > Am I using your patch beyond its intended use, or doing anything wrong? Nope, this has to work. You've found a bug. ;-) Regards Oliver -- ****************************************************************************************** This e-mail (including any attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender by telephone (+44-1454-284800) and destroy the original message. Any statement and/or opinion not related to this company's business and expressed in this message is that of the author and does not necessarily reflect those of Icera. This company does not take any responsibility for the views of the author in any matter not related to the company's objective. ******************************************************************************************
Attachment:
dhcp.kern.log
Description: dhcp.kern.log
