swsusp regression [Was: 2.6.17-mm1]

swsusp regression [Was: 2.6.17-mm1]

[Jiri Slaby]

Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

[32512.214000] Suspending device usbdev3.2_ep81
[32512.214040] Suspending device 3-2:1.0
[32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
[32512.214128] Suspending device usbdev3.2_ep00
[32512.214169] Suspending device 3-2
[32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
[32512.214319] Could not suspend device 3-2: error -16
[32512.214361] wacom 3-2:1.0: no resume for driver wacom?
[32512.242552] Some devices failed to suspend

Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2

Wacom messages are not new, but it now causes not suspending.

2.6.17-rc6-mm2 was OK.

Is there any more info needed?

-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: swsusp regression [Was: 2.6.17-mm1]

[Mattia Dongili]

On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> 
> [32512.214000] Suspending device usbdev3.2_ep81
> [32512.214040] Suspending device 3-2:1.0
> [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> [32512.214128] Suspending device usbdev3.2_ep00
> [32512.214169] Suspending device 3-2
> [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> [32512.214319] Could not suspend device 3-2: error -16
> [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> [32512.242552] Some devices failed to suspend
> 
> Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
> 
> Wacom messages are not new, but it now causes not suspending.

me too (again!)

[   95.408000] Suspending device 3-1
[   95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
[   95.408000] Could not suspend device 3-1: error -16
[   95.412000] Some devices failed to suspend
[   95.412000] Restarting tasks... done

rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
and resume (s2ram).
usbcore tells it is in use (count=1) and can't remove it.
The device is a memory stick reader.

I have the same problems also with suspend to disk. BTW I can't resume
from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
tomorrow, as it seems removing the usb stuff makes it do some more steps
toward resumimg (eg: with usb modules this laptop immediately reboots
after reading all pages, without them I can reach "resuming device.."
stage).

-- 
mattia
:wq!

Re: swsusp regression [Was: 2.6.17-mm1]

[Mattia Dongili]

On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
[...]
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).

doh, sorry. I meant "suspend to ram".

-- 
mattia
:wq!

Re: swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> > Andrew Morton napsal(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> > 
> > [32512.214000] Suspending device usbdev3.2_ep81
> > [32512.214040] Suspending device 3-2:1.0
> > [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> > [32512.214128] Suspending device usbdev3.2_ep00
> > [32512.214169] Suspending device 3-2
> > [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> > [32512.214319] Could not suspend device 3-2: error -16
> > [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> > [32512.242552] Some devices failed to suspend
> > 
> > Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
> > 
> > Wacom messages are not new, but it now causes not suspending.
> 
> me too (again!)
> 
> [   95.408000] Suspending device 3-1
> [   95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
> [   95.408000] Could not suspend device 3-1: error -16
> [   95.412000] Some devices failed to suspend
> [   95.412000] Restarting tasks... done
> 
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).
> usbcore tells it is in use (count=1) and can't remove it.
> The device is a memory stick reader.
> 
> I have the same problems also with suspend to disk. BTW I can't resume
> from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> tomorrow, as it seems removing the usb stuff makes it do some more steps
> toward resumimg (eg: with usb modules this laptop immediately reboots
> after reading all pages, without them I can reach "resuming device.."
> stage).

Removing uhci-hcd causes all USB devices to be removed from the system.

Alan, you've been working in the "generic usb" section lately, any ideas
why we can't suspend that kind of device now?

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Wed, 21 Jun 2006 23:19:05 -0700
Greg KH <greg@kroah.com> wrote:

> > I have the same problems also with suspend to disk. BTW I can't resume
> > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > toward resumimg (eg: with usb modules this laptop immediately reboots
> > after reading all pages, without them I can reach "resuming device.."
> > stage).
> 
> Removing uhci-hcd causes all USB devices to be removed from the system.
> 
> Alan, you've been working in the "generic usb" section lately, any ideas
> why we can't suspend that kind of device now?

My laptop has the same problem.

This:

--- a/drivers/usb/core/usb.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/usb.c
@@ -991,7 +991,11 @@ void usb_buffer_unmap_sg (struct usb_dev
 
 static int verify_suspended(struct device *dev, void *unused)
 {
-	return (dev->power.power_state.event == PM_EVENT_ON) ? -EBUSY : 0;
+	if (dev->power.power_state.event == PM_EVENT_ON) {
+		dev_printk(KERN_ERR, dev, "not suspended\n");
+		return -EBUSY;
+	}
+	return 0;
 }
 
 static int usb_generic_suspend(struct device *dev, pm_message_t message)
@@ -1005,13 +1009,18 @@ static int usb_generic_suspend(struct de
 	 * But those semantics are useless, so we equate the two (sigh).
 	 */
 	if (dev->driver == &usb_generic_driver) {
+		int ret;
+
 		if (dev->power.power_state.event == message.event)
 			return 0;
 		/* we need to rule out bogus requests through sysfs */
 		status = device_for_each_child(dev, NULL, verify_suspended);
+		suspend_report_result(verify_suspended, status);
 		if (status)
 			return status;
- 		return usb_suspend_device (to_usb_device(dev));
+		ret = usb_suspend_device(to_usb_device(dev));
+		suspend_report_result(usb_suspend_device, ret);
+		return ret;
 	}
 
 	if ((dev->driver == NULL) ||
@@ -1027,6 +1036,7 @@ static int usb_generic_suspend(struct de
 
 	if (driver->suspend && driver->resume) {
 		status = driver->suspend(intf, message);
+		suspend_report_result(driver->suspend, status);
 		if (status)
 			dev_err(dev, "%s error %d\n", "suspend", status);
 		else
diff -puN drivers/usb/core/hub.c~usb-more-suspend-debugging drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/hub.c
@@ -1638,6 +1638,7 @@ static int hub_port_suspend(struct usb_h
 				USB_DEVICE_REMOTE_WAKEUP, 0,
 				NULL, 0,
 				USB_CTRL_SET_TIMEOUT);
+		suspend_report_result(usb_control_msg, status);
 		if (status)
 			dev_dbg(&udev->dev,
 				"won't remote wakeup, status %d\n",
@@ -1646,6 +1647,7 @@ static int hub_port_suspend(struct usb_h
 
 	/* see 7.1.7.6 */
 	status = set_port_feature(hub->hdev, port1, USB_PORT_FEAT_SUSPEND);
+	suspend_report_result(set_port_feature, status);
 	if (status) {
 		dev_dbg(hub->intfdev,
 			"can't suspend port %d, status %d\n",
@@ -1706,6 +1708,8 @@ static int __usb_suspend_device (struct 
 			intf = udev->actconfig->interface[i];
 			if (is_active(intf)) {
 				dev_dbg(&intf->dev, "nyet suspended\n");
+				suspend_report_result(__usb_suspend_device,
+							-EBUSY);
 				return -EBUSY;
 			}
 		}
@@ -1714,9 +1718,11 @@ static int __usb_suspend_device (struct 
 	/* we only change a device's upstream USB link.
 	 * root hubs have no upstream USB link.
 	 */
-	if (udev->parent)
+	if (udev->parent) {
 		status = hub_port_suspend(hdev_to_hub(udev->parent), port1,
 				udev);
+		suspend_report_result(hub_port_suspend, status);
+	}
 
 	if (status == 0)
 		udev->dev.power.power_state = PMSG_SUSPEND;
_


Says:

Shrinking memory... done (0 pages freed)
hci_usb 3-1:1.1: no suspend for driver hci_usb?
hci_usb 3-1:1.0: no suspend for driver hci_usb?
 usbdev3.2_ep00: not suspended
usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
Could not suspend device 3-1: error -16
hci_usb 3-1:1.0: no resume for driver hci_usb?
hci_usb 3-1:1.1: no resume for driver hci_usb?
Some devices failed to suspend
Restarting tasks... done


What's a usbdev3.2_ep00?

sony:/home/akpm> lsusb
Bus 005 Device 001: ID 0000:0000  
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 002: ID 044e:300c Alps Electric Co., Ltd 
Bus 003 Device 001: ID 0000:0000  
Bus 002 Device 003: ID 045e:00e1 Microsoft Corp. 
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000  

sony:/home/akpm> l /sys/bus/usb/devices
total 0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.2

Seems to be this:

00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI])
        Subsystem: Sony Corporation Unknown device 81b9
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 16
        Region 4: I/O ports at 1860 [size=32]
00: 86 80 5a 26 05 00 80 02 03 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 18 00 00 00 00 00 00 00 00 00 00 4d 10 b9 81
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00

I don't see anything in this patchpile which would break the bluetooth driver,
and drivers/usb/core/usb.c is effectively unchanged.

I can bisect it if we're stuck, but that'll require beer or something.

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> My laptop has the same problem.
>   
Mine too.  I wonder if its related to the (apparently) bluetooth-caused 
oops I reported earlier today?

Though I'm seeing the suspend problem on a system with no bluetooth 
module loaded; the only USB device on the bus is the fingerprint-reader.

My suspend script removes the uhci_hcd module on suspend.  The device 
complaining EBUSY is the ehci hub, which has nothing hanging off it.

    J

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Andrew Morton wrote:

> On Wed, 21 Jun 2006 23:19:05 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > > I have the same problems also with suspend to disk. BTW I can't resume
> > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > after reading all pages, without them I can reach "resuming device.."
> > > stage).
> > 
> > Removing uhci-hcd causes all USB devices to be removed from the system.
> > 
> > Alan, you've been working in the "generic usb" section lately, any ideas
> > why we can't suspend that kind of device now?

See below...

> My laptop has the same problem.

> Shrinking memory... done (0 pages freed)
> hci_usb 3-1:1.1: no suspend for driver hci_usb?
> hci_usb 3-1:1.0: no suspend for driver hci_usb?
>  usbdev3.2_ep00: not suspended
> usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> Could not suspend device 3-1: error -16
> hci_usb 3-1:1.0: no resume for driver hci_usb?
> hci_usb 3-1:1.1: no resume for driver hci_usb?
> Some devices failed to suspend
> Restarting tasks... done
> 
> 
> What's a usbdev3.2_ep00?

Evidently the regression was caused by Greg's patch making endpoints into 
real struct devices.  usbdev3.2_ep00 is the device corresponding to 
endpoint 0 on device 2 of USB bus 3.

Is it really true that this patch has been sitting in -mm for several
months (as stated in the cover message to Linus for the new batch of
changes for 2.6.17 sent in yesterday)?

There are several possible ways to fix this.  One is to add suspend and 
resume routines to the endpoint-device driver.  Another is to change the 
code that checks for the children being suspended, to make it check only 
for child USB devices and not child endpoints.

Alan Stern

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Jeremy Fitzhardinge]

Alan Stern wrote:
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?
>   
2.6.17-pre6-mm2 works perfectly for me.  17-mm1 has this problem.

    J

Re: swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Andrew Morton wrote:
> 
> > On Wed, 21 Jun 2006 23:19:05 -0700
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > after reading all pages, without them I can reach "resuming device.."
> > > > stage).
> > > 
> > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > > 
> > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > why we can't suspend that kind of device now?
> 
> See below...
> 
> > My laptop has the same problem.
> 
> > Shrinking memory... done (0 pages freed)
> > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> >  usbdev3.2_ep00: not suspended
> > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > Could not suspend device 3-1: error -16
> > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > Some devices failed to suspend
> > Restarting tasks... done
> > 
> > 
> > What's a usbdev3.2_ep00?
> 
> Evidently the regression was caused by Greg's patch making endpoints into 
> real struct devices.  usbdev3.2_ep00 is the device corresponding to 
> endpoint 0 on device 2 of USB bus 3.
> 
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?

Ugh, no, you are right, the endpoint change was not in for that long,
sorry.  I thought it did make at least one -mm though.

> There are several possible ways to fix this.  One is to add suspend and 
> resume routines to the endpoint-device driver.  Another is to change the 
> code that checks for the children being suspended, to make it check only 
> for child USB devices and not child endpoints.

I think it needs to check for _USB_ devices, not just any old device
that could possibly be attached to the main USB device (as this one is.)
What's to stop any other struct device to bind here and cause the same
problem?

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 11:46:49AM -0700, Greg KH wrote:
> On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> > On Thu, 22 Jun 2006, Andrew Morton wrote:
> > 
> > > On Wed, 21 Jun 2006 23:19:05 -0700
> > > Greg KH <greg@kroah.com> wrote:
> > > 
> > > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > > after reading all pages, without them I can reach "resuming device.."
> > > > > stage).
> > > > 
> > > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > > > 
> > > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > > why we can't suspend that kind of device now?
> > 
> > See below...
> > 
> > > My laptop has the same problem.
> > 
> > > Shrinking memory... done (0 pages freed)
> > > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> > >  usbdev3.2_ep00: not suspended
> > > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > > Could not suspend device 3-1: error -16
> > > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > > Some devices failed to suspend
> > > Restarting tasks... done
> > > 
> > > 
> > > What's a usbdev3.2_ep00?
> > 
> > Evidently the regression was caused by Greg's patch making endpoints into 
> > real struct devices.  usbdev3.2_ep00 is the device corresponding to 
> > endpoint 0 on device 2 of USB bus 3.
> > 
> > Is it really true that this patch has been sitting in -mm for several
> > months (as stated in the cover message to Linus for the new batch of
> > changes for 2.6.17 sent in yesterday)?
> 
> Ugh, no, you are right, the endpoint change was not in for that long,
> sorry.  I thought it did make at least one -mm though.
> 
> > There are several possible ways to fix this.  One is to add suspend and 
> > resume routines to the endpoint-device driver.  Another is to change the 
> > code that checks for the children being suspended, to make it check only 
> > for child USB devices and not child endpoints.
> 
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?

Ok, the problem is in verify_suspended(), we are not detecting what type
of device this is.

Alan, what are you trying to check for here?  What "bogus requests" were
you seeing from sysfs that you are trying to filter out?

thanks,

greg k-h

Re: swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Greg KH wrote:

> > There are several possible ways to fix this.  One is to add suspend and 
> > resume routines to the endpoint-device driver.  Another is to change the 
> > code that checks for the children being suspended, to make it check only 
> > for child USB devices and not child endpoints.
> 
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?

In my upcoming patches for USB core suspend improvements, one of the 
changes affects this very piece of code.  Instead of looping over all 
child devices in the driver-model sense, it loops over all interfaces in 
the active configuration, which is all we care about right here.

> Ok, the problem is in verify_suspended(), we are not detecting what type
> of device this is.
> 
> Alan, what are you trying to check for here?  What "bogus requests" were
> you seeing from sysfs that you are trying to filter out?

I didn't write that routine, Dave Brownell did.  It has been there for
ages.  The "bogus requests" are attempts by the user to suspend a USB
device (by writing to /sys/devices/.../power/state) without first
suspending all its children and interfaces.

(This can't happen when doing a global suspend because the PM core 
iterates through the entire device tree.  It matters only for "runtime" or 
"selective" suspend.)

The two easiest ways to fix the problem are:

	Change the code to look through the interfaces in the active
	configuration instead of using device_for_each_child;

or

	Revert your "endpoints are devices" patch until my upcoming
	changes are in place.

Alan Stern

Re: swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 03:57:24PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Greg KH wrote:
> 
> > > There are several possible ways to fix this.  One is to add suspend and 
> > > resume routines to the endpoint-device driver.  Another is to change the 
> > > code that checks for the children being suspended, to make it check only 
> > > for child USB devices and not child endpoints.
> > 
> > I think it needs to check for _USB_ devices, not just any old device
> > that could possibly be attached to the main USB device (as this one is.)
> > What's to stop any other struct device to bind here and cause the same
> > problem?
> 
> In my upcoming patches for USB core suspend improvements, one of the 
> changes affects this very piece of code.  Instead of looping over all 
> child devices in the driver-model sense, it loops over all interfaces in 
> the active configuration, which is all we care about right here.
> 
> > Ok, the problem is in verify_suspended(), we are not detecting what type
> > of device this is.
> > 
> > Alan, what are you trying to check for here?  What "bogus requests" were
> > you seeing from sysfs that you are trying to filter out?
> 
> I didn't write that routine, Dave Brownell did.  It has been there for
> ages.

Sorry for the misattribution, I should have checked closer.

> The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
> 
> (This can't happen when doing a global suspend because the PM core 
> iterates through the entire device tree.  It matters only for "runtime" or 
> "selective" suspend.)

Then why is people hitting this now?  I guess no one had hooked a struct
device to a struct usb_device before, only interfaces.

> The two easiest ways to fix the problem are:
> 
> 	Change the code to look through the interfaces in the active
> 	configuration instead of using device_for_each_child;

Or at least verify that they are looking at an interface, just blindly
poking at a child device isn't very nice :(

> or
> 
> 	Revert your "endpoints are devices" patch until my upcoming
> 	changes are in place.

I'll work on a fix-up patch based on the first option :)

thanks,

greg k-h

Re: swsusp regression [Was: 2.6.17-mm1]

[Jiri Slaby]

Alan Stern napsal(a):
>> Ok, the problem is in verify_suspended(), we are not detecting what type
>> of device this is.
>>
>> Alan, what are you trying to check for here?  What "bogus requests" were
>> you seeing from sysfs that you are trying to filter out?
> 
> I didn't write that routine, Dave Brownell did.  It has been there for
> ages.  The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
> 
> (This can't happen when doing a global suspend because the PM core 
> iterates through the entire device tree.  It matters only for "runtime" or 
> "selective" suspend.)

But everything I did is:
echo reboot > /sys/power/disk
echo disk > /sys/power/state

No writing anywhere else.

regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Jiri Slaby wrote:

> > ages.  The "bogus requests" are attempts by the user to suspend a USB
> > device (by writing to /sys/devices/.../power/state) without first
> > suspending all its children and interfaces.
> > 
> > (This can't happen when doing a global suspend because the PM core 
> > iterates through the entire device tree.  It matters only for "runtime" or 
> > "selective" suspend.)
> 
> But everything I did is:
> echo reboot > /sys/power/disk
> echo disk > /sys/power/state
> 
> No writing anywhere else.

You misunderstood.  I meant that attempts to suspend a USB device without 
first suspending all its children and interfaces can't happen when doing a 
global suspend.  That's still true.

Your problem occurred because even though the PM core did _attempt_ to 
suspend the new children added by Greg's patch, it didn't _succeed_ 
because the patch did not provide suspend or resume methods.

Alan Stern

Re: swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 05:09:43PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Jiri Slaby wrote:
> 
> > > ages.  The "bogus requests" are attempts by the user to suspend a USB
> > > device (by writing to /sys/devices/.../power/state) without first
> > > suspending all its children and interfaces.
> > > 
> > > (This can't happen when doing a global suspend because the PM core 
> > > iterates through the entire device tree.  It matters only for "runtime" or 
> > > "selective" suspend.)
> > 
> > But everything I did is:
> > echo reboot > /sys/power/disk
> > echo disk > /sys/power/state
> > 
> > No writing anywhere else.
> 
> You misunderstood.  I meant that attempts to suspend a USB device without 
> first suspending all its children and interfaces can't happen when doing a 
> global suspend.  That's still true.
> 
> Your problem occurred because even though the PM core did _attempt_ to 
> suspend the new children added by Greg's patch, it didn't _succeed_ 
> because the patch did not provide suspend or resume methods.

Which because they are virtual "devices" they do not need a suspend or
resume method, so not having any is just fine.  If we abort because of
something like this, the core logic is quite broken...

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> I can bisect it if we're stuck, but that'll require beer or something.

FWIW, my laptop (Dell D610) gave the following results:
2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17: oops
2.6.17.1: oops

2.6.17-rc6-mm2: suspends correctly


Regards,
Frederik

Re: swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Thu, 22 Jun 2006 18:04:03 +0200
Frederik Deweerdt <deweerdt@free.fr> wrote:

> Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > I can bisect it if we're stuck, but that'll require beer or something.
> 
> FWIW, my laptop (Dell D610) gave the following results:
> 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16

So it's in mainline already - hence it's some recently-written thing which
was not tested in rc6-mm2.

> 2.6.17: oops
> 2.6.17.1: oops

2.6.17 wasn't supposed to oops.  Do you have details on this?

> 2.6.17-rc6-mm2: suspends correctly

Good kernel, that.

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 2.6.17: oops
> > 2.6.17.1: oops
> 
> 2.6.17 wasn't supposed to oops.  Do you have details on this?
> 
No, sorry I didn't have a serial cable handy. I'll post the 
.config and the oops tomorrow.

Regards,
Frederik

Re: swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
> 
> > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > I can bisect it if we're stuck, but that'll require beer or something.
> > 
> > FWIW, my laptop (Dell D610) gave the following results:
> > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> 
> So it's in mainline already - hence it's some recently-written thing which
> was not tested in rc6-mm2.
> 
> > 2.6.17: oops
> > 2.6.17.1: oops
> 
> 2.6.17 wasn't supposed to oops.  Do you have details on this?
> 
For some reason, unknown to me, the oops won't display on the serial link :(.

Here's what I could hand copy (I've suppressed printk timing information):
x1b9/0x1be
<c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
<3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():0, irqs_disabled():1
 <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
 <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
 <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
 <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
 <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
 <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
 <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
 <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
 <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

This is triggered on a 2.6.17.1 kernel by:
echo mem > /sys/power/state

.config and dmesg are here:
http://fdeweerdt.free.fr/suspend_oops/

Regards,
Frederik

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

Hi!

> > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 
> > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > I can bisect it if we're stuck, but that'll require beer or something.
> > > 
> > > FWIW, my laptop (Dell D610) gave the following results:
> > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > 
> > So it's in mainline already - hence it's some recently-written thing which
> > was not tested in rc6-mm2.
> > 
> > > 2.6.17: oops
> > > 2.6.17.1: oops
> > 
> > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > 
> For some reason, unknown to me, the oops won't display on the serial
> link :(.

Serial console is currently broken by suspend, resume. _But_ I have a
patch I'd like you to try.... pretty please?

> Here's what I could hand copy (I've suppressed printk timing information):
> x1b9/0x1be
> <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> in_atomic():0, irqs_disabled():1
>  <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
>  <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
>  <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
>  <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
>  <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
>  <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
>  <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
>  <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
>  <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

That is not an oops, rather a kernel BUG(). Can you just remove
might_sleep line and see what happens?

Unfortunately, backtrace does not tell me which notifier chain did
that :-(. Are you using audit or something like that?

/*
 * lock for reading
 */
static inline void down_read(struct rw_semaphore *sem)
{
        might_sleep();
~~~~~~~~~~~~~~~~~~~~~~
        rwsemtrace(sem,"Entering down_read");
        __down_read(sem);
        rwsemtrace(sem,"Leaving down_read");
}

										Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Fri, 23 Jun 2006 11:10:21 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> > Here's what I could hand copy (I've suppressed printk timing information):
> > x1b9/0x1be
> > <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> > 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> > 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> > EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> > <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> > in_atomic():0, irqs_disabled():1
> >  <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
> >  <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
> >  <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
> >  <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
> >  <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
> >  <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
> >  <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
> >  <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
> >  <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> 
> That is not an oops, rather a kernel BUG().

It's not a BUG().  It's a BUG.

IOW, it's just a WARN_ON().  Ingo decided all the scary messages should
start with the text "BUG".  That doesn't correlate with BUG().  Confused
yet?

That trace is odd.  It kinda looks like we got a segfault when entering the
do_suspend_lowlevel() assembly.  Or something.

> Can you just remove
> might_sleep line and see what happens?
> 
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?

No, that's all a consequence of something which happened earlier.

Re: swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > > 
> > > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > > I can bisect it if we're stuck, but that'll require beer or something.
> > > > 
> > > > FWIW, my laptop (Dell D610) gave the following results:
> > > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > 
> > > So it's in mainline already - hence it's some recently-written thing which
> > > was not tested in rc6-mm2.
> > > 
> > > > 2.6.17: oops
> > > > 2.6.17.1: oops
> > > 
> > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > 
> > For some reason, unknown to me, the oops won't display on the serial
> > link :(.
> 
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?
> 
Sure :)... I applied it but the output went to the laptop's screen anyway...
 
> That is not an oops, rather a kernel BUG(). Can you just remove
> might_sleep line and see what happens?
> 
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?
> 
> /*
>  * lock for reading
>  */
> static inline void down_read(struct rw_semaphore *sem)
> {
>         might_sleep();
> ~~~~~~~~~~~~~~~~~~~~~~
>         rwsemtrace(sem,"Entering down_read");
>         __down_read(sem);
>         rwsemtrace(sem,"Leaving down_read");
> }
> 
Here's the (hand copied) dump when the might_sleep is removed:

esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
ds: 007b  es: 007b  ss: 0068
Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
        00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
        c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
Call Trace:
 <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
 <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
 <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
 <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
 <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
 <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
 <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4

Regards,
Frederik

Re: swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

Hi!

> > > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > > 
> > > For some reason, unknown to me, the oops won't display on the serial
> > > link :(.
> > 
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> > 
> Sure :)... I applied it but the output went to the laptop's screen anyway...

Do you need some kernel command line options? This is s2ram, do I
recall it correctly?

> > That is not an oops, rather a kernel BUG(). Can you just remove
> > might_sleep line and see what happens?
> > 
> > Unfortunately, backtrace does not tell me which notifier chain did
> > that :-(. Are you using audit or something like that?
> > 
> > /*
> >  * lock for reading
> >  */
> > static inline void down_read(struct rw_semaphore *sem)
> > {
> >         might_sleep();
> > ~~~~~~~~~~~~~~~~~~~~~~
> >         rwsemtrace(sem,"Entering down_read");
> >         __down_read(sem);
> >         rwsemtrace(sem,"Leaving down_read");
> > }
> > 
> Here's the (hand copied) dump when the might_sleep is removed:
> 
> esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
> ds: 007b  es: 007b  ss: 0068
> Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)

This stack lines are not really interesting (can you comment them from
sources?) and they make interesting info scroll away :-(. Or maybe
vga=1 can help?

> Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
>         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
>         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> Call Trace:
>  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
>  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
>  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
>  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
>  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
>  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
>  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> 
> Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ha, wait a moment, this is interesting line. Can you trace down which
instruction causes this?

We recently changed pagetable handling during swsusp, perhaps thats
it? It went to Linus few minutes ago...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 02:57:01PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > > > 
> > > > For some reason, unknown to me, the oops won't display on the serial
> > > > link :(.
> > > 
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> > > 
> > Sure :)... I applied it but the output went to the laptop's screen anyway...
> 
> Do you need some kernel command line options? This is s2ram, do I
> recall it correctly?
I think the options are ok: I'm passing console=tty0 console=ttyS0,9600 and
everything works fine in cu(1). Until the 'echo mem > /sys/power/state', that is :)
> > esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
> > ds: 007b  es: 007b  ss: 0068
> > Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
> 
> This stack lines are not really interesting (can you comment them from
> sources?) and they make interesting info scroll away :-(. 
I'll comment them out and send you the trace, but I won't get the time to
do it today, I'll try to get it done by monday.
> Or maybe vga=1 can help?
I've tried it. But somehow, the suspend process resets the resolution to the
lowest one.
> 
> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
c0229b71 is in acpi_pm_enter:
        case PM_SUSPEND_MEM:
-->             do_suspend_lowlevel();
                break;

c013b242 is in suspend_enter:
	}
-->     error = pm_ops->enter(state);
	device_power_up();


c013b2e8 is in enter_state
        pr_debug("PM: Entering %s sleep\n", pm_states[state]);
-->     error = suspend_enter(state);


c013b481 is in state_store
        if (state < PM_SUSPEND_MAX && *s)
-->            error = enter_state(state);
        else


> > Call Trace:
> >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > 
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
This disassembles as follows:
c043431c <do_suspend_lowlevel>:
c043431c:       e8 6d 38 ea ff          call   c02d7b8e <save_processor_state>
c0434321:       e8 a2 ff ff ff          call   c04342c8 <save_registers>
c0434326:       6a 03                   push   $0x3
c0434328:       e8 ec b6 de ff          call   c021fa19 <acpi_enter_sleep_state>
c043432d:       83 c4 04                add    $0x4,%esp
c0434330:       c3                      ret
So it looks like where crashing when calling save_processor_state. 
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...
Sorry, I don't understand what you mean: do you want me to try the latest git?

Regards,
Frederik

Re: swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Fri, 23 Jun 2006 14:57:01 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > Call Trace:
> >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > 
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
> 
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...

That's a good possibility.  It does appear to be oopsing at the first
instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel(). 
Perhaps there's enough info in that oops trace to tell us whether it was
the instruction fetch which oopsed.

One wonders whether this will help...

--- a/arch/i386/kernel/acpi/wakeup.S~a
+++ a/arch/i386/kernel/acpi/wakeup.S
@@ -270,6 +270,7 @@ ALIGN
 ENTRY(saved_magic)	.long	0
 ENTRY(saved_eip)	.long	0
 
+.text
 save_registers:
 	leal	4(%esp), %eax
 	movl	%eax, saved_context_esp
@@ -304,6 +305,7 @@ ret_point:
 	call	restore_processor_state
 	ret
 
+.data
 ALIGN
 # saved registers
 saved_gdt:	.long	0,0
_

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 12:57:06PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 14:57:01 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> > >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> > >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > > Call Trace:
> > >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> > >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> > >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> > >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> > >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> > >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> > >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > > 
> > > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
> >   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Ha, wait a moment, this is interesting line. Can you trace down which
> > instruction causes this?
> > 
> > We recently changed pagetable handling during swsusp, perhaps thats
> > it? It went to Linus few minutes ago...
> 
> That's a good possibility.  It does appear to be oopsing at the first
> instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel(). 
> Perhaps there's enough info in that oops trace to tell us whether it was
> the instruction fetch which oopsed.
> 
> One wonders whether this will help...
> 
I've tried 2.6.17-git10 which appears to have the fix and the laptop 
suspends correctly. Looks like that was it :).

Thanks,
Frederik

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Russell King]

On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?

Did you bother trying my patch, which was done the Right(tm) way?
There wasn't any feedback on it so I can only assume not.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: swsusp regression [Was: 2.6.17-mm1]

[Dave Jones]

On Fri, Jun 23, 2006 at 08:41:01PM +0100, Russell King wrote:
 > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
 > > Serial console is currently broken by suspend, resume. _But_ I have a
 > > patch I'd like you to try.... pretty please?
 > 
 > Did you bother trying my patch, which was done the Right(tm) way?
 > There wasn't any feedback on it so I can only assume not.

I thought I had replied to that.   It didn't make any difference for me.
I recall seeing a posting from someone else saying the same thing.

		Dave


-- 
http://www.codemonkey.org.uk

Re: swsusp regression [Was: 2.6.17-mm1]

[Rafael J. Wysocki]

Hi,

On Friday 23 June 2006 21:41, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> 
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.

Sorry for that, I just couldn't test it earlier.  Works for me. :-)

Thanks,
Rafael

Re: swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

On Fri 2006-06-23 20:41:01, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> 
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.

(I actually forwarded him your patch in private email).
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> On Fri 2006-06-23 20:41:01, Russell King wrote:
> > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> > 
> > Did you bother trying my patch, which was done the Right(tm) way?
> > There wasn't any feedback on it so I can only assume not.
> 
> (I actually forwarded him your patch in private email).
And I did try it, but it make no difference: the output would still
appear on the laptop.

Regards,
Frederik

Re: swsusp regression [Was: 2.6.17-mm1]

[Rafael J. Wysocki]

On Saturday 24 June 2006 01:53, Frederik Deweerdt wrote:
> On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> > On Fri 2006-06-23 20:41:01, Russell King wrote:
> > > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > > patch I'd like you to try.... pretty please?
> > > 
> > > Did you bother trying my patch, which was done the Right(tm) way?
> > > There wasn't any feedback on it so I can only assume not.
> > 
> > (I actually forwarded him your patch in private email).
> And I did try it, but it make no difference: the output would still
> appear on the laptop.

You can try to use the hack at
http://www.sisk.pl/kernel/patches/2.6.17-mm1/hack-serial-suspend.patch
and see if that makes the messages get to the serial console.

Greetings,
Rafael