Hi!
Upon attempt to swsusp, I get "Unable to handle kernel paging request
at virtual address fffffff4" in usb_device_suspend, called from
suspend_device, device_suspend, drivers_suspend, do_software_suspend,
....
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
> Upon attempt to swsusp, I get "Unable to handle kernel paging request
> at virtual address fffffff4" in usb_device_suspend, called from
> suspend_device, device_suspend, drivers_suspend, do_software_suspend,
> ....
Unfortunately, we don't have a 'taint' flag for when extra patches are
added to an official release.
The latter two functions do not exist in -test5. It would helpful if you
tried to reproduce with a virgin -test5. It would be courteous to state
what patches you applied on top of the virgin -test5 kernel.
The entire Oops would also help, captured either by hand or with e.g. a
digital camera. You may want to cc the usb-devel list, too.
Thanks,
Pat
Hi!
> > Upon attempt to swsusp, I get "Unable to handle kernel paging request
> > at virtual address fffffff4" in usb_device_suspend, called from
> > suspend_device, device_suspend, drivers_suspend, do_software_suspend,
> > ....
>
> Unfortunately, we don't have a 'taint' flag for when extra patches are
> added to an official release.
:-)
> The latter two functions do not exist in -test5. It would helpful if you
> tried to reproduce with a virgin -test5. It would be courteous to state
> what patches you applied on top of the virgin -test5 kernel.
Lot of them, but only "revert to -test3 swsusp" should be important
here.
> The entire Oops would also help, captured either by hand or with e.g. a
> digital camera. You may want to cc the usb-devel list, too.
Good news is that it only happens when there are devices plugged into
usb. I'll test other machines now.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
> > The latter two functions do not exist in -test5. It would helpful if you
> > tried to reproduce with a virgin -test5. It would be courteous to state
> > what patches you applied on top of the virgin -test5 kernel.
>
> Lot of them, but only "revert to -test3 swsusp" should be important
> here.
Then all bets are off. I cannot expect to reproduce the problems until you
narrow down which patch causes the problem or verify that it appears on a
standard kernel release.
Pat
Hi!
> > > The latter two functions do not exist in -test5. It would helpful if you
> > > tried to reproduce with a virgin -test5. It would be courteous to state
> > > what patches you applied on top of the virgin -test5 kernel.
> >
> > Lot of them, but only "revert to -test3 swsusp" should be important
> > here.
>
> Then all bets are off. I cannot expect to reproduce the problems until you
> narrow down which patch causes the problem or verify that it appears on a
> standard kernel release.
Meanwhile I reproduced it with echo -n mem > state; that does not
touch "my" codepaths at all. Oops in usb_device_suspend called from
suspend_device, device_suspend, suspend_prepare, enter_state. If I
unplug usb hub with acm modem and zaurus, it will not oops like that.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi!
> > > The latter two functions do not exist in -test5. It would helpful if you
> > > tried to reproduce with a virgin -test5. It would be courteous to state
> > > what patches you applied on top of the virgin -test5 kernel.
> >
> > Lot of them, but only "revert to -test3 swsusp" should be important
> > here.
>
> Then all bets are off. I cannot expect to reproduce the problems until you
> narrow down which patch causes the problem or verify that it appears on a
> standard kernel release.
Here's patch that should fix it. [First part of first hunk defitely
triggered twice during suspend, and made machine survive that.] Please
apply,
Pavel
--- clean/drivers/usb/core/usb.c 2003-09-09 12:45:35.000000000 +0200
+++ linux/drivers/usb/core/usb.c 2003-09-10 02:16:10.000000000 +0200
@@ -1429,9 +1429,11 @@
return 0;
intf = to_usb_interface(dev);
+ if (!dev->driver)
+ return 0;
driver = to_usb_driver(dev->driver);
- if (driver && driver->suspend)
+ if (driver->suspend)
return driver->suspend(intf, state);
return 0;
}
@@ -1446,9 +1448,11 @@
return 0;
intf = to_usb_interface(dev);
+ if (!dev->driver)
+ return 0;
driver = to_usb_driver(dev->driver);
- if (driver && driver->resume)
+ if (driver->resume)
return driver->resume(intf);
return 0;
}
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
Hi!
> > > The latter two functions do not exist in -test5. It would helpful if you
> > > tried to reproduce with a virgin -test5. It would be courteous to state
> > > what patches you applied on top of the virgin -test5 kernel.
> >
> > Lot of them, but only "revert to -test3 swsusp" should be important
> > here.
>
> Then all bets are off. I cannot expect to reproduce the problems until you
> narrow down which patch causes the problem or verify that it appears on a
> standard kernel release.
To follow up myself, patch attached to message sent about 5 minutes
ago indeed fixes the oops. [USB still does not survive suspend/resume,
but at least the kernel survives. Probably pm_send_all() stuff needs
to be cleaned up before USB can be fixed.]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Wed, Sep 10, 2003 at 02:19:56AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > The latter two functions do not exist in -test5. It would helpful if you
> > > > tried to reproduce with a virgin -test5. It would be courteous to state
> > > > what patches you applied on top of the virgin -test5 kernel.
> > >
> > > Lot of them, but only "revert to -test3 swsusp" should be important
> > > here.
> >
> > Then all bets are off. I cannot expect to reproduce the problems until you
> > narrow down which patch causes the problem or verify that it appears on a
> > standard kernel release.
>
> Here's patch that should fix it. [First part of first hunk defitely
> triggered twice during suspend, and made machine survive that.] Please
> apply,
Doh, thanks for catching this, I'll add this to my tree and send it in
my next batch to Linus.
This was my fault, nothing that Pat added.
thanks,
greg k-h