On Thu, Dec 8, 2011 at 10:02 AM, Greg KH <greg@xxxxxxxxx> wrote:
> On Wed, Dec 07, 2011 at 02:40:49PM -0800, Grant Grundler wrote:
>> Hi,
>> I'm testing asix (USB 100BT ethernet adapter with AX88772) driver
>> initialization (and shut down) paths and reproduced a
>> "skb_queue_purge" panic 3 times after a few hundred/thousand
>> iterations of rmmod/modprobe. I'm inclined to believe
>> skb_queue_purge() is a victim and not a culprit here.
>>
>> I don't know if all 3 "spontaneous reboots" I've seen have the same
>> stack trace as the one I have a record for:
>
> Have you tried this on 3.1, and especially, 3.2-rc?
Hi Greg,
I haven't tried any thing later yet. I would consider it if someone
could point at a change(s) that might be relevant to the symptom.
> A number of asix
> patches have gone into the 3.2-rc series, perhaps they might have
> resolved this problem already?
I'm the one who submitted those changes. :)
asix.c driver I'm testing was pulled directly from davem's net-next
tree and I believe that's what is in 3.2-rc series now.
Those changes only relate to AX88772 and AX88178 bind and reset code.
suspend/resume support is unchanged - though I suspect ax*_reset
functions get called in resume.
It's possible this code path in asix.c has *always* been broken. I see
two drivesr/net/usbnet USB drivers that do this:
drivers/net/usb/cdc_ether.c 614 .reset_resume = usbnet_resume,
drivers/net/usb/cdc_ncm.c 1193 .reset_resume = usbnet_resume,
Even though most usbnet drivers don't, I'm tempted to add this code
and "just try it":
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index e6fed4d..b2de65f 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -1666,6 +1666,7 @@ static struct usb_driver asix_driver = {
.probe = usbnet_probe,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
+ .reset_resume = usbnet_reset_resume,
.disconnect = usbnet_disconnect,
.supports_autosuspend = 1,
};
thanks!
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
