Re: [linux-usb-devel] [usb-storage] schedule_timeout: wrong timeout value c1a95554
On Thursday, 9 August 2007 16:43, Alan Stern wrote:
On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
Hello,
Happens every time I reattach usb pen drive.
usb 1-2: new high speed USB device using ehci_hcd and address 10
usb 1-2: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
usb 1-2: new device found, idVendor=13fe, idProduct=1a00
usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: GEIL USB DISK
usb 1-2: Manufacturer:
usb-storage: device found at 10
usb-storage: waiting for device to settle before scanning
schedule_timeout: wrong timeout value c1a95554
[c010456a] show_trace_log_lvl+0x1a/0x30
[c010508d] show_trace+0x12/0x14
[c01051e0] dump_stack+0x15/0x17
[c04174d1] schedule_timeout+0x8c/0xa2
[c032aeec] usb_stor_scan_thread+0x100/0x160
[c0127f2e] kthread+0x36/0x58
[c0104233] kernel_thread_helper+0x7/0x14
===
scsi 6:0:0:0: Direct-Access GEIL USB DISK2.0 PQ: 0 ANSI:
0 CCS
sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 6:0:0:0: [sda] Assuming drive cache: write through
sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 6:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 6:0:0:0: [sda] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
This is a known problem. See
http://marc.info/?l=linux-kernelm=118641424414399w=2
Rafael, has this been fixed yet?
No, I wasn't aware of it.
I think that something like the appended patch is necessary.
Mariusz, please see if that helps.
Greetings,
Rafael
---
include/linux/freezer.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.23-rc2/include/linux/freezer.h
===
--- linux-2.6.23-rc2.orig/include/linux/freezer.h
+++ linux-2.6.23-rc2/include/linux/freezer.h
@@ -134,28 +134,28 @@ static inline void set_freezable(void)
#define wait_event_freezable(wq, condition)\
({ \
- int __ret; \
+ int __retval; \
do {\
- __ret = wait_event_interruptible(wq,\
+ __retval = wait_event_interruptible(wq, \
(condition) || freezing(current)); \
- if (__ret !freezing(current))\
+ if (__retval !freezing(current)) \
break; \
else if (!(condition)) \
- __ret = -ERESTARTSYS; \
+ __retval = -ERESTARTSYS;\
} while (try_to_freeze()); \
- __ret; \
+ __retval; \
})
#define wait_event_freezable_timeout(wq, condition, timeout) \
({ \
- long __ret = timeout; \
+ long __retval = timeout;\
do {\
- __ret = wait_event_interruptible_timeout(wq,\
+ __retval = wait_event_interruptible_timeout(wq, \
(condition) || freezing(current), \
- __ret); \
+ __retval); \
} while (try_to_freeze()); \
- __ret; \
+ __retval; \
})
#else /* !CONFIG_PM_SLEEP */
static inline int frozen(struct task_struct *p) { return 0; }
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To
Re: [linux-usb-devel] [usb-storage] schedule_timeout: wrong timeout value c1a95554
On Thursday, 9 August 2007 17:20, Mariusz Kozlowski wrote:
Happens every time I reattach usb pen drive.
usb 1-2: new high speed USB device using ehci_hcd and address 10
usb 1-2: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
usb 1-2: new device found, idVendor=13fe, idProduct=1a00
usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: GEIL USB DISK
usb 1-2: Manufacturer:
usb-storage: device found at 10
usb-storage: waiting for device to settle before scanning
schedule_timeout: wrong timeout value c1a95554
[c010456a] show_trace_log_lvl+0x1a/0x30
[c010508d] show_trace+0x12/0x14
[c01051e0] dump_stack+0x15/0x17
[c04174d1] schedule_timeout+0x8c/0xa2
[c032aeec] usb_stor_scan_thread+0x100/0x160
[c0127f2e] kthread+0x36/0x58
[c0104233] kernel_thread_helper+0x7/0x14
===
scsi 6:0:0:0: Direct-Access GEIL USB DISK2.0 PQ: 0
ANSI: 0 CCS
sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 6:0:0:0: [sda] Assuming drive cache: write through
sd 6:0:0:0: [sda] 1007616 512-byte hardware sectors (516 MB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 6:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 6:0:0:0: [sda] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
This is a known problem. See
http://marc.info/?l=linux-kernelm=118641424414399w=2
Rafael, has this been fixed yet?
No, I wasn't aware of it.
I think that something like the appended patch is necessary.
Mariusz, please see if that helps.
Yes - this patch fixes the bug.
OK, thanks for the confirmation.
Here it goes again with a changelog etc.
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Fix a bug in freezer-introduce-freezer-firendly-waiting-macros.patch which
uses a wrong variable name in wait_event_freezable() and
wait_event_freezable_timeout() (this name is also used in
wait_event_interruptible() and wait_event_interruptible_timeout() which are
macros and the names clash).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
include/linux/freezer.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.23-rc2/include/linux/freezer.h
===
--- linux-2.6.23-rc2.orig/include/linux/freezer.h
+++ linux-2.6.23-rc2/include/linux/freezer.h
@@ -134,28 +134,28 @@ static inline void set_freezable(void)
#define wait_event_freezable(wq, condition)\
({ \
- int __ret; \
+ int __retval; \
do {\
- __ret = wait_event_interruptible(wq,\
+ __retval = wait_event_interruptible(wq, \
(condition) || freezing(current)); \
- if (__ret !freezing(current))\
+ if (__retval !freezing(current)) \
break; \
else if (!(condition)) \
- __ret = -ERESTARTSYS; \
+ __retval = -ERESTARTSYS;\
} while (try_to_freeze()); \
- __ret; \
+ __retval; \
})
#define wait_event_freezable_timeout(wq, condition, timeout) \
({ \
- long __ret = timeout; \
+ long __retval = timeout;\
do {\
- __ret = wait_event_interruptible_timeout(wq,\
+ __retval = wait_event_interruptible_timeout(wq, \
(condition) || freezing(current), \
- __ret); \
+ __retval); \
} while (try_to_freeze()); \
- __ret; \
+ __retval
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Thursday, 21 June 2007 21:39, Alan Stern wrote: On Thu, 21 Jun 2007, Rafael J. Wysocki wrote: I'll see if I can reproduce your problem here. Yes, I can. It's only necessary to load usb-storage (without any devices actually using it) and it fails device_suspend() immediately (I don't think it's freezer-related). I've got the following trace from it: usb_endpoint usbdev3.2_ep81: PM: suspend 0-1, parent 3-1:1.0 already 2 Suspending device 3-1:1.0 Suspending device usbdev3.2_ep00 Suspending device 3-1 Suspending device eth1 Suspending device eth0 Suspending device usbdev3.1 Suspending device usbdev3.1_ep81 Suspending device 3-0:1.0 Suspending device usbdev3.1_ep00 Suspending device usb3 hub 3-0:1.0: hub_suspend ohci_hcd :00:02.1: needs reinit! usb usb3: suspend fail, err -16 usb usb3: 'global' suspend -16 hub 3-0:1.0: hub_resume hub 3-0:1.0: activate -- -108 suspend_device(): usb_suspend+0x0/0x30() returns -16 Could not suspend device usb3: error -16 WARNING: at /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 usb_submit_urb() Well, a large part of the problem is that usb-try-to-debug-bug-8561.patch hasn't been reverted in 2.6.22-rc4-mm2. Yes, the problem is not present after reverting this patch. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 16:01, Alan Stern wrote: On Wed, 20 Jun 2007, Mattia Dongili wrote: On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? The usb-storage thread is supposed to be unfreezable. Recent changes may have messed up the code that checks for which threads need to be frozen and which don't. I don't really think so, but well ... That's why I asked Mattia to test the hibernation/suspend patches without the rest of -mm. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote: On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? Can you please try 2.6.22-rc5 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ applied. That should allow us to eliminate some suspects. ;-) you're safe then! .22-rc5 + your suspend patch-set can suspend and resume happily. OK, thanks. OTOH, that would have been less patches to check ... ;-) I'll see if I can reproduce your problem here. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 22:50, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote: On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? Can you please try 2.6.22-rc5 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ applied. That should allow us to eliminate some suspects. ;-) you're safe then! .22-rc5 + your suspend patch-set can suspend and resume happily. OK, thanks. OTOH, that would have been less patches to check ... ;-) I'll see if I can reproduce your problem here. Yes, I can. It's only necessary to load usb-storage (without any devices actually using it) and it fails device_suspend() immediately (I don't think it's freezer-related). I've got the following trace from it: usb_endpoint usbdev3.2_ep81: PM: suspend 0-1, parent 3-1:1.0 already 2 Suspending device 3-1:1.0 Suspending device usbdev3.2_ep00 Suspending device 3-1 Suspending device eth1 Suspending device eth0 Suspending device usbdev3.1 Suspending device usbdev3.1_ep81 Suspending device 3-0:1.0 Suspending device usbdev3.1_ep00 Suspending device usb3 hub 3-0:1.0: hub_suspend ohci_hcd :00:02.1: needs reinit! usb usb3: suspend fail, err -16 usb usb3: 'global' suspend -16 hub 3-0:1.0: hub_resume hub 3-0:1.0: activate -- -108 suspend_device(): usb_suspend+0x0/0x30() returns -16 Could not suspend device usb3: error -16 WARNING: at /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 usb_submit_urb() Call Trace: [80409dd3] usb_submit_urb+0x363/0x3b0 [881e21cf] :usbhid:hid_start_in+0x8f/0xb0 [881e221a] :usbhid:hid_resume+0x2a/0x30 [8040c832] usb_resume_interface+0x92/0x100 [8040c93e] usb_external_resume_device+0x9e/0x170 [8040ca3b] usb_resume+0x2b/0x40 [803ed097] resume_device+0x87/0x190 [803ed239] dpm_resume+0x99/0xc0 [803ecef7] device_suspend+0x147/0x190 [803c1891] tty_ldisc_deref+0x61/0x80 [80268e1e] hibernation_snapshot+0x3e/0xe0 [802e7fce] dnotify_parent+0x3e/0x90 [8026c059] snapshot_ioctl+0x379/0x540 [8026bce0] snapshot_ioctl+0x0/0x540 [802b2b72] do_ioctl+0x92/0xe0 [802b2c33] vfs_ioctl+0x73/0x2d0 [804b2c7a] trace_hardirqs_on_thunk+0x35/0x37 [802b2f21] sys_ioctl+0x91/0xb0 [8020bc6e] system_call+0x7e/0x83 usbhid 3-1:1.0: resume error -16 usb_endpoint usbdev3.2_ep81: PM: resume from 0, parent 3-1:1.0 still 2 input input4: PM: resume from 0, parent 3-1:1.0 still 2 Restarting tasks ... 7hub 3-0:1.0: state 7 ports 3 chg evt hub 3-0:1.0: hub_port_status failed (err = -108) hub 3-0:1.0: hub_port_status failed (err = -108) hub 3-0:1.0: hub_port_status failed (err = -108) done. swsusp: Basic memory bitmaps freed Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Thursday, 21 June 2007 00:03, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 22:50, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote: On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? Can you please try 2.6.22-rc5 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ applied. That should allow us to eliminate some suspects. ;-) you're safe then! .22-rc5 + your suspend patch-set can suspend and resume happily. OK, thanks. OTOH, that would have been less patches to check ... ;-) I'll see if I can reproduce your problem here. Yes, I can. It's only necessary to load usb-storage (without any devices actually using it) and it fails device_suspend() immediately (I don't think it's freezer-related). It seems to be 100% reproducible in arbitrary configuration. Here's a dmesg snippet from another machine: Suspending device usbdev4.1 Suspending device usbdev4.1_ep81 Suspending device 4-0:1.0 Suspending device usbdev4.1_ep00 Suspending device usb4 hub 4-0:1.0: activate -- -108 suspend_device(): usb_suspend+0x0/0x30() returns -16 Could not suspend device usb4: error -16 PM: Image restored successfully. Restarting tasks ... 3hub 4-0:1.0: hub_port_status failed (err = -108) hub 4-0:1.0: hub_port_status failed (err = -108) hub 4-0:1.0: hub_port_status failed (err = -108) done. swsusp: Basic memory bitmaps freed Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Monday, 11 June 2007 22:10, Alan Stern wrote: On Mon, 11 Jun 2007, Rafael J. Wysocki wrote: At that point, does lspci -vv show that the controller is trying to signal a wakeup event? That is, is the PME# signal asserted? (Not that knowing this will help very much -- I'm not sure what we could do with that information, and in any case there are other ways besides PME# for on-board devices to report wakeup requests. I ask mainly out of curiousity.) It shows this literally: 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 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- Interrupt: pin D routed to IRQ 20 Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D3 PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [58] Debug port Which means that the controller is in D3 and it supports PME#, but PME# isn't turned on. But as I said, Intel controllers may signal wakeup requests in a different way (UHCI controllers definitely do, but maybe not EHCI). The simplest workaround should be to disable remote wakeup for that controller: echo disable /sys/bus/pci/devices/.../power/wakeup I tried that but it didn't help. Namely, the box resumed right after suspending as it had done before. The only way to prevent it from resuming immediately after the suspend is to 'rmmod ehci_hcd' before the suspend. Hmmm... If you turn on CONFIG_USB_DEBUG, what shows up in /sys/class/usb_host/usb_hostN/registers where N is the bus number of the controller? bus pci, device :00:1d.7 (driver 10 Dec 2004) EHCI Host Controller EHCI 1.00, hcd state 4 ownership 0001 SMI sts/enable 0x8008 structural params 0x00103206 capability params 0x6871 status 1008 Halt FLR command 01 (park)=0 ithresh=1 period=1024 HALT intrenable 37 IAA FATAL PCD ERR INT uframe 36f1 port 1 status 701000 POWER sig=se0 port 2 status 701000 POWER sig=se0 port 3 status 701000 POWER sig=se0 port 4 status 701000 POWER sig=se0 port 5 status 701000 POWER sig=se0 port 6 status 701000 POWER sig=se0 irq normal 0 err 0 reclaim 0 (lost 0) complete 0 unlink 0 Also, can you post a dmesg log (with CONFIG_USB_DEBUG enabled) showing what happens during the suspend and immediate resume? [That's after I have disabled the wakeup on the EHCI controller.] PM: Preparing system for mem sleep Stopping tasks ... done. Suspending console(s) pnp: Device 00:07 disabled. pnp: Device 00:05 disabled. ehci_hcd :00:1d.7: -- PCI D3 uhci_hcd :00:1d.2: uhci_suspend uhci_hcd :00:1d.2: -- PCI D0/legacy uhci_hcd :00:1d.1: uhci_suspend uhci_hcd :00:1d.1: -- PCI D0/legacy uhci_hcd :00:1d.0: uhci_suspend uhci_hcd :00:1d.0: -- PCI D0/legacy PM: Entering mem sleep Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Back to C! PM: Finishing wakeup. uhci_hcd :00:1d.0: PCI legacy resume ACPI: PCI Interrupt :00:1d.0[A] - GSI 16 (level, low) - IRQ 18 PCI: Setting latency timer of device :00:1d.0 to 64 uhci_hcd :00:1d.0: uhci_resume uhci_hcd :00:1d.0: uhci_check_and_reset_hc: legsup = 0x2f00 uhci_hcd :00:1d.0: Performing full reset usb usb2: root hub lost power or was reset usb usb2: suspend_rh uhci_hcd :00:1d.1: PCI legacy resume ACPI: PCI Interrupt :00:1d.1[B] - GSI 19 (level, low) - IRQ 19 PCI: Setting latency timer of device :00:1d.1 to 64 uhci_hcd :00:1d.1: uhci_resume uhci_hcd :00:1d.1: uhci_check_and_reset_hc: legsup = 0x2000 uhci_hcd :00:1d.1: Performing full reset usb usb3: root hub lost power or was reset usb usb3: suspend_rh uhci_hcd :00:1d.2: PCI legacy resume ACPI: PCI Interrupt :00:1d.2[C] - GSI 18 (level, low) - IRQ 16 PCI: Setting latency timer of device :00:1d.2 to 64 uhci_hcd :00:1d.2: uhci_resume uhci_hcd :00:1d.2: uhci_check_and_reset_hc: legsup = 0x2000 uhci_hcd :00:1d.2: Performing full reset usb usb4: root hub lost power or was reset usb usb4: suspend_rh ehci_hcd :00:1d.7: PCI D0, from previous PCI D3 ACPI: PCI Interrupt :00:1d.7[D] - GSI 23 (level, low) - IRQ 17 PCI: Setting latency timer of device :00:1d.7 to 64 PM: Writing back config space on device :00:1e.0 at offset 7 (was 2280d0d0, writing 280d0d0) PCI: Setting latency timer of device :00:1e.0 to 64 PM: Writing back config space on device :00:1f.1 at offset 9 (was 0, writing 3000) PM: Writing back config
Re: [linux-usb-devel] [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM
On Tuesday, 12 June 2007 03:50, Zhang Rui wrote: I've tried to suspend with the controller in that state, but it's resumed immediately, as before. Maybe also see what ACPI reports. How can I see that? I wish I knew. Maybe you can try asking on the ACPI mailing list. The simplest workaround should be to disable remote wakeup for that controller: echo disable /sys/bus/pci/devices/.../power/wakeup I tried that but it didn't help. Namely, the box resumed right after suspending as it had done before. The only way to prevent it from resuming immediately after the suspend is to 'rmmod ehci_hcd' before the suspend. Interestingly enough, I have no such problems with EHCI on the other test box that is able to suspend to RAM and resume. What's the kernel version you are using? Is it the same problem shown here? http://lkml.org/lkml/2007/5/18/55 2.6.22-rc1-mm1 may have this problem. Yes, I remeber this thread. The kernel is 2.6.22-rc4 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/ applied. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM
On Tuesday, 12 June 2007 13:59, Rafael J. Wysocki wrote: On Tuesday, 12 June 2007 03:50, Zhang Rui wrote: I've tried to suspend with the controller in that state, but it's resumed immediately, as before. Maybe also see what ACPI reports. How can I see that? I wish I knew. Maybe you can try asking on the ACPI mailing list. The simplest workaround should be to disable remote wakeup for that controller: echo disable /sys/bus/pci/devices/.../power/wakeup I tried that but it didn't help. Namely, the box resumed right after suspending as it had done before. The only way to prevent it from resuming immediately after the suspend is to 'rmmod ehci_hcd' before the suspend. Interestingly enough, I have no such problems with EHCI on the other test box that is able to suspend to RAM and resume. What's the kernel version you are using? Is it the same problem shown here? http://lkml.org/lkml/2007/5/18/55 2.6.22-rc1-mm1 may have this problem. Yes, I remeber this thread. s/remeber/remember/ The kernel is 2.6.22-rc4 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/ applied. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 0/7] PM: Remove unused and unnecessary features from suspend and resume core
Hi, The following series of patches removes some unused and unnecessary features from the suspend and resume core code. Comments welcome. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 2/7] PM: Remove saved_state from struct dev_pm_info
From: Rafael J. Wysocki [EMAIL PROTECTED]
The saved_state member of struct dev_pm_info, defined in include/linux/pm.h, is
not used anywhere, so it can be removed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
include/linux/pm.h |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.22-rc4/include/linux/pm.h
===
--- linux-2.6.22-rc4.orig/include/linux/pm.h2007-06-09 21:12:45.0
+0200
+++ linux-2.6.22-rc4/include/linux/pm.h 2007-06-09 22:26:13.0 +0200
@@ -236,7 +236,6 @@ struct dev_pm_info {
#ifdef CONFIG_PM
unsignedshould_wakeup:1;
pm_message_tprev_state;
- void* saved_state;
struct list_headentry;
#endif
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 3/7] PM: Simplify suspend_device
From: Rafael J. Wysocki [EMAIL PROTECTED]
Reduce code duplication in drivers/base/suspend.c by introducing a separate
function for printing diagnostic messages.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/suspend.c | 49 +++
1 file changed, 18 insertions(+), 31 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
13:30:45.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
18:50:45.0 +0200
@@ -40,6 +40,14 @@ static inline char *suspend_verb(u32 eve
}
+static void
+suspend_device_dbg(struct device * dev, pm_message_t state, char *info)
+{
+ dev_dbg(dev, %s%s%s\n, info, suspend_verb(state.event),
+ ((state.event == PM_EVENT_SUSPEND) device_may_wakeup(dev)) ?
+ , may wakeup : );
+}
+
/**
* suspend_device - Save state of one device.
* @dev: Device.
@@ -66,37 +74,21 @@ int suspend_device(struct device * dev,
dev-power.prev_state = dev-power.power_state;
if (dev-class dev-class-suspend !dev-power.power_state.event)
{
- dev_dbg(dev, class %s%s\n,
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
-device_may_wakeup(dev))
- ? , may wakeup
- :
- );
+ suspend_device_dbg(dev, state, class );
error = dev-class-suspend(dev, state);
suspend_report_result(dev-class-suspend, error);
}
- if (!error dev-type dev-type-suspend
!dev-power.power_state.event) {
- dev_dbg(dev, %s%s\n,
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
-device_may_wakeup(dev))
- ? , may wakeup
- :
- );
+ if (!error dev-type dev-type-suspend
+!dev-power.power_state.event) {
+ suspend_device_dbg(dev, state, type );
error = dev-type-suspend(dev, state);
suspend_report_result(dev-type-suspend, error);
}
- if (!error dev-bus dev-bus-suspend
!dev-power.power_state.event) {
- dev_dbg(dev, %s%s\n,
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
-device_may_wakeup(dev))
- ? , may wakeup
- :
- );
+ if (!error dev-bus dev-bus-suspend
+!dev-power.power_state.event) {
+ suspend_device_dbg(dev, state, );
error = dev-bus-suspend(dev, state);
suspend_report_result(dev-bus-suspend, error);
}
@@ -114,14 +106,9 @@ static int suspend_device_late(struct de
{
int error = 0;
- if (dev-bus dev-bus-suspend_late
!dev-power.power_state.event) {
- dev_dbg(dev, LATE %s%s\n,
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
-device_may_wakeup(dev))
- ? , may wakeup
- :
- );
+ if (dev-bus dev-bus-suspend_late
+!dev-power.power_state.event) {
+ suspend_device_dbg(dev, state, LATE );
error = dev-bus-suspend_late(dev, state);
suspend_report_result(dev-bus-suspend_late, error);
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/base/power/main.c| 36 ++--
drivers/base/power/resume.c |7 +++
drivers/base/power/suspend.c |7 +++
include/linux/pm.h |3 ---
4 files changed, 16 insertions(+), 37 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/main.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/main.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/main.c 2007-06-09 22:19:44.0
+0200
@@ -31,28 +31,7 @@ DEFINE_MUTEX(dpm_list_mtx);
int (*platform_enable_wakeup)(struct device *dev, int is_on);
-
-/**
- * device_pm_set_parent - Specify power dependency.
- * @dev: Device who needs power.
- * @parent:Device that supplies power.
- *
- * This function is used to manually describe a power-dependency
- * relationship. It may be used to specify a transversal relationship
- * (where the power supplier is not the physical (or electrical)
- * ancestor of a specific device.
- * The effect of this is that the supplier will not be powered down
- * before the power dependent.
- */
-
-void device_pm_set_parent(struct device * dev, struct device * parent)
-{
- put_device(dev-power.pm_parent);
- dev-power.pm_parent = get_device(parent);
-}
-EXPORT_SYMBOL_GPL(device_pm_set_parent);
-
-int device_pm_add(struct device * dev)
+int device_pm_add(struct device *dev)
{
int error;
@@ -61,21 +40,26 @@ int device_pm_add(struct device * dev)
kobject_name(dev-kobj));
mutex_lock(dpm_list_mtx);
list_add_tail(dev-power.entry, dpm_active);
- device_pm_set_parent(dev, dev-parent);
- if ((error = dpm_sysfs_add(dev)))
+ /*
+* The device's parent must not be released until the device itself is
+* removed from the dpm_active list.
+*/
+ get_device(dev-parent);
+ error = dpm_sysfs_add(dev);
+ if (error)
list_del(dev-power.entry);
mutex_unlock(dpm_list_mtx);
return error;
}
-void device_pm_remove(struct device * dev)
+void device_pm_remove(struct device *dev)
{
pr_debug(PM: Removing info for %s:%s\n,
dev-bus ? dev-bus-name : No Bus,
kobject_name(dev-kobj));
mutex_lock(dpm_list_mtx);
dpm_sysfs_remove(dev);
- put_device(dev-power.pm_parent);
+ put_device(dev-parent);
list_del_init(dev-power.entry);
mutex_unlock(dpm_list_mtx);
}
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-09
21:12:43.0 +0200
@@ -29,12 +29,11 @@ int resume_device(struct device * dev)
down(dev-sem);
- if (dev-power.pm_parent
-dev-power.pm_parent-power.power_state.event) {
+ if (dev-parent dev-parent-power.power_state.event) {
dev_err(dev, PM: resume from %d, parent %s still %d\n,
dev-power.power_state.event,
- dev-power.pm_parent-bus_id,
- dev-power.pm_parent-power.power_state.event);
+ dev-parent-bus_id,
+ dev-parent-power.power_state.event);
}
if (dev-bus dev-bus-resume) {
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-09
21:12:40.0 +0200
@@ -55,13 +55,12 @@ int suspend_device(struct device * dev,
dev_dbg(dev, PM: suspend %d--%d\n,
dev-power.power_state.event, state.event);
}
- if (dev-power.pm_parent
-dev-power.pm_parent-power.power_state.event) {
+ if (dev-parent dev-parent-power.power_state.event) {
dev_err(dev,
PM: suspend %d-%d, parent %s already %d\n,
dev-power.power_state.event, state.event,
- dev-power.pm_parent-bus_id,
- dev-power.pm_parent-power.power_state.event
[linux-usb-devel] [RFC][PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type
From: Rafael J. Wysocki [EMAIL PROTECTED]
The suspend and resume support in struct device_type (include/linux/device.h)
is not used anywhere. It is also undocumented, so it can be removed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/resume.c |5 -
drivers/base/power/suspend.c |7 ---
include/linux/device.h |2 --
3 files changed, 14 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-10
15:00:23.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-10
15:02:04.0 +0200
@@ -41,11 +41,6 @@ int resume_device(struct device * dev)
error = dev-bus-resume(dev);
}
- if (!error dev-type dev-type-resume) {
- dev_dbg(dev,resuming\n);
- error = dev-type-resume(dev);
- }
-
if (!error dev-class dev-class-resume) {
dev_dbg(dev,class resume\n);
error = dev-class-resume(dev);
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
15:00:40.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
15:02:04.0 +0200
@@ -79,13 +79,6 @@ int suspend_device(struct device * dev,
suspend_report_result(dev-class-suspend, error);
}
- if (!error dev-type dev-type-suspend
-!dev-power.power_state.event) {
- suspend_device_dbg(dev, state, type );
- error = dev-type-suspend(dev, state);
- suspend_report_result(dev-type-suspend, error);
- }
-
if (!error dev-bus dev-bus-suspend
!dev-power.power_state.event) {
suspend_device_dbg(dev, state, );
Index: linux-2.6.22-rc4/include/linux/device.h
===
--- linux-2.6.22-rc4.orig/include/linux/device.h2007-06-10
15:00:23.0 +0200
+++ linux-2.6.22-rc4/include/linux/device.h 2007-06-10 15:02:04.0
+0200
@@ -343,8 +343,6 @@ struct device_type {
int (*uevent)(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size);
void (*release)(struct device *dev);
- int (*suspend)(struct device * dev, pm_message_t state);
- int (*resume)(struct device * dev);
};
/* interface for exporting device attributes */
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 5/7] PM: Remove prev_state from struct dev_pm_info
From: Rafael J. Wysocki [EMAIL PROTECTED]
The prev_state member of struct dev_pm_info (defined in include/linux/pm.h) is
only used during a resume to check if the device's state before the suspend was
'off', in which case the device is not resumed. However, in such cases the
decision whether or not to resume the device should be made on the driver level
and the resume callbacks from the device's bus and class should be executed
anyway (the may be needed for some things other than just powering on the
device).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/resume.c |3 +--
drivers/base/power/suspend.c |2 --
drivers/usb/core/hub.c |5 -
include/linux/pm.h |1 -
4 files changed, 1 insertion(+), 10 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-10
19:36:52.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-10
19:53:57.0 +0200
@@ -83,8 +83,7 @@ void dpm_resume(void)
list_move_tail(entry, dpm_active);
mutex_unlock(dpm_list_mtx);
- if (!dev-power.prev_state.event)
- resume_device(dev);
+ resume_device(dev);
mutex_lock(dpm_list_mtx);
put_device(dev);
}
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
19:36:52.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
19:53:09.0 +0200
@@ -71,8 +71,6 @@ int suspend_device(struct device * dev,
dev-parent-power.power_state.event);
}
- dev-power.prev_state = dev-power.power_state;
-
if (dev-class dev-class-suspend !dev-power.power_state.event)
{
suspend_device_dbg(dev, state, class );
error = dev-class-suspend(dev, state);
Index: linux-2.6.22-rc4/drivers/usb/core/hub.c
===
--- linux-2.6.22-rc4.orig/drivers/usb/core/hub.c2007-06-08
13:09:18.0 +0200
+++ linux-2.6.22-rc4/drivers/usb/core/hub.c 2007-06-10 19:54:08.0
+0200
@@ -1110,11 +1110,6 @@ void usb_root_hub_lost_power(struct usb_
dev_warn(rhdev-dev, root hub lost power or was reset\n);
- /* Make sure no potential wakeup events get lost,
-* by forcing the root hub to be resumed.
-*/
- rhdev-dev.power.prev_state.event = PM_EVENT_ON;
-
spin_lock_irqsave(device_state_lock, flags);
hub = hdev_to_hub(rhdev);
for (port1 = 1; port1 = rhdev-maxchild; ++port1) {
Index: linux-2.6.22-rc4/include/linux/pm.h
===
--- linux-2.6.22-rc4.orig/include/linux/pm.h2007-06-10 19:36:52.0
+0200
+++ linux-2.6.22-rc4/include/linux/pm.h 2007-06-10 19:52:56.0 +0200
@@ -235,7 +235,6 @@ struct dev_pm_info {
unsignedcan_wakeup:1;
#ifdef CONFIG_PM
unsignedshould_wakeup:1;
- pm_message_tprev_state;
struct list_headentry;
#endif
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 7/7] PM: Do not check parent state in suspend and resume core code
From: Rafael J. Wysocki [EMAIL PROTECTED]
The checks if the device's parent is in the right state done in
drivers/base/power/suspend.c and drivers/base/power/resume.c serve no particular
purpose, since if the parent is in a wrong power state, the device's suspend or
resume callbacks are supposed to return an error anyway. Moreover, they are
also useless from the sanity checking point of view, because they rely on the
code being checked to set dev-parent-power.power_state.event appropriately,
which need not happen if that code is buggy. For these reasons they can be
removed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/resume.c |7 ---
drivers/base/power/suspend.c |7 ---
2 files changed, 14 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-11
09:59:54.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-11
10:19:37.0 +0200
@@ -29,13 +29,6 @@ int resume_device(struct device * dev)
down(dev-sem);
- if (dev-parent dev-parent-power.power_state.event) {
- dev_err(dev, PM: resume from %d, parent %s still %d\n,
- dev-power.power_state.event,
- dev-parent-bus_id,
- dev-parent-power.power_state.event);
- }
-
if (dev-bus dev-bus-resume) {
dev_dbg(dev,resuming\n);
error = dev-bus-resume(dev);
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-11
10:18:11.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-11
10:19:30.0 +0200
@@ -63,13 +63,6 @@ int suspend_device(struct device * dev,
dev_dbg(dev, PM: suspend %d--%d\n,
dev-power.power_state.event, state.event);
}
- if (dev-parent dev-parent-power.power_state.event) {
- dev_err(dev,
- PM: suspend %d-%d, parent %s already %d\n,
- dev-power.power_state.event, state.event,
- dev-parent-bus_id,
- dev-parent-power.power_state.event);
- }
if (dev-class dev-class-suspend) {
suspend_device_dbg(dev, state, class );
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 6/7] PM: Remove power_state.event checks from suspend core code
From: Rafael J. Wysocki [EMAIL PROTECTED]
The suspend routines should be called for every device during a system sleep
transition, regardless of the device's state, so that drivers can regard these
method calls as notifications that the system is about to go to sleep, rather
than as directives to put their devices into the 'off' state.
This is documented in Documentation/power/devices.txt and is already done in
the core resume code, so it seems reasonable to make the core suspend code
behave accordingly.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/suspend.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-11
09:59:54.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-11
10:18:11.0 +0200
@@ -71,14 +71,13 @@ int suspend_device(struct device * dev,
dev-parent-power.power_state.event);
}
- if (dev-class dev-class-suspend !dev-power.power_state.event)
{
+ if (dev-class dev-class-suspend) {
suspend_device_dbg(dev, state, class );
error = dev-class-suspend(dev, state);
suspend_report_result(dev-class-suspend, error);
}
- if (!error dev-bus dev-bus-suspend
-!dev-power.power_state.event) {
+ if (!error dev-bus dev-bus-suspend) {
suspend_device_dbg(dev, state, );
error = dev-bus-suspend(dev, state);
suspend_report_result(dev-bus-suspend, error);
@@ -97,8 +96,7 @@ static int suspend_device_late(struct de
{
int error = 0;
- if (dev-bus dev-bus-suspend_late
-!dev-power.power_state.event) {
+ if (dev-bus dev-bus-suspend_late) {
suspend_device_dbg(dev, state, LATE );
error = dev-bus-suspend_late(dev, state);
suspend_report_result(dev-bus-suspend_late, error);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
On Monday, 11 June 2007 17:59, Alan Stern wrote: On Mon, 11 Jun 2007, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is only used to check if the device's parent is in the right state while the device is being suspended or resumed. However, this can be done just as well with the help of the parent pointer in struct device, so pm_parent can be removed along with some code that handles it. @@ -61,21 +40,26 @@ int device_pm_add(struct device * dev) kobject_name(dev-kobj)); mutex_lock(dpm_list_mtx); list_add_tail(dev-power.entry, dpm_active); - device_pm_set_parent(dev, dev-parent); - if ((error = dpm_sysfs_add(dev))) + /* +* The device's parent must not be released until the device itself is +* removed from the dpm_active list. +*/ + get_device(dev-parent); + error = dpm_sysfs_add(dev); + if (error) list_del(dev-power.entry); mutex_unlock(dpm_list_mtx); return error; } The error pathway here does an unbalanced get_device on dev-parent. Anyway, I don't think you need to do this get_device at all (or the coresponding put in device_pm_remove). As long as a device is registered it retains a reference to its parent, and unregistration always calls device_pm_remove. Yes, I've just come to the same conclusion. I'll remove the get_device(dev-parent) and the correspondint put_device(dev-parent) from device_pm_remove(). Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Saturday, 9 June 2007 23:26, Alan Stern wrote: On Sat, 9 Jun 2007, Rafael J. Wysocki wrote: You can try using the patch below to see what happens when you manually suspend the controller. It enables PCI devices to respond to the legacy power/state attribute. You should look at what lspci -vv says about the controller's power management signals, both before and after suspending the PCI device entry. It works as expected, AFAICS. That is, after I echo '2' to the 'state' file, it shows that the controller is in D3. At that point, does lspci -vv show that the controller is trying to signal a wakeup event? That is, is the PME# signal asserted? (Not that knowing this will help very much -- I'm not sure what we could do with that information, and in any case there are other ways besides PME# for on-board devices to report wakeup requests. I ask mainly out of curiousity.) It shows this literally: 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 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- Interrupt: pin D routed to IRQ 20 Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D3 PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [58] Debug port I've tried to suspend with the controller in that state, but it's resumed immediately, as before. Maybe also see what ACPI reports. How can I see that? I wish I knew. Maybe you can try asking on the ACPI mailing list. The simplest workaround should be to disable remote wakeup for that controller: echo disable /sys/bus/pci/devices/.../power/wakeup I tried that but it didn't help. Namely, the box resumed right after suspending as it had done before. The only way to prevent it from resuming immediately after the suspend is to 'rmmod ehci_hcd' before the suspend. Interestingly enough, I have no such problems with EHCI on the other test box that is able to suspend to RAM and resume. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
On Monday, 11 June 2007 20:52, Rafael J. Wysocki wrote:
On Monday, 11 June 2007 17:59, Alan Stern wrote:
On Mon, 11 Jun 2007, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in
include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as
well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.
@@ -61,21 +40,26 @@ int device_pm_add(struct device * dev)
kobject_name(dev-kobj));
mutex_lock(dpm_list_mtx);
list_add_tail(dev-power.entry, dpm_active);
- device_pm_set_parent(dev, dev-parent);
- if ((error = dpm_sysfs_add(dev)))
+ /*
+ * The device's parent must not be released until the device itself is
+ * removed from the dpm_active list.
+ */
+ get_device(dev-parent);
+ error = dpm_sysfs_add(dev);
+ if (error)
list_del(dev-power.entry);
mutex_unlock(dpm_list_mtx);
return error;
}
The error pathway here does an unbalanced get_device on dev-parent.
Anyway, I don't think you need to do this get_device at all (or the
coresponding put in device_pm_remove). As long as a device is
registered it retains a reference to its parent, and unregistration
always calls device_pm_remove.
Yes, I've just come to the same conclusion. I'll remove the
get_device(dev-parent) and the correspondint put_device(dev-parent)
from device_pm_remove().
OK
The updated patch follows.
Greetings,
Rafael
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/base/power/main.c| 30 --
drivers/base/power/resume.c |7 +++
drivers/base/power/suspend.c |7 +++
include/linux/pm.h |3 ---
4 files changed, 10 insertions(+), 37 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/main.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/main.c 2007-06-10
19:35:49.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/main.c 2007-06-11 21:05:10.0
+0200
@@ -31,28 +31,7 @@ DEFINE_MUTEX(dpm_list_mtx);
int (*platform_enable_wakeup)(struct device *dev, int is_on);
-
-/**
- * device_pm_set_parent - Specify power dependency.
- * @dev: Device who needs power.
- * @parent:Device that supplies power.
- *
- * This function is used to manually describe a power-dependency
- * relationship. It may be used to specify a transversal relationship
- * (where the power supplier is not the physical (or electrical)
- * ancestor of a specific device.
- * The effect of this is that the supplier will not be powered down
- * before the power dependent.
- */
-
-void device_pm_set_parent(struct device * dev, struct device * parent)
-{
- put_device(dev-power.pm_parent);
- dev-power.pm_parent = get_device(parent);
-}
-EXPORT_SYMBOL_GPL(device_pm_set_parent);
-
-int device_pm_add(struct device * dev)
+int device_pm_add(struct device *dev)
{
int error;
@@ -61,21 +40,20 @@ int device_pm_add(struct device * dev)
kobject_name(dev-kobj));
mutex_lock(dpm_list_mtx);
list_add_tail(dev-power.entry, dpm_active);
- device_pm_set_parent(dev, dev-parent);
- if ((error = dpm_sysfs_add(dev)))
+ error = dpm_sysfs_add(dev);
+ if (error)
list_del(dev-power.entry);
mutex_unlock(dpm_list_mtx);
return error;
}
-void device_pm_remove(struct device * dev)
+void device_pm_remove(struct device *dev)
{
pr_debug(PM: Removing info for %s:%s\n,
dev-bus ? dev-bus-name : No Bus,
kobject_name(dev-kobj));
mutex_lock(dpm_list_mtx);
dpm_sysfs_remove(dev);
- put_device(dev-power.pm_parent);
list_del_init(dev-power.entry);
mutex_unlock(dpm_list_mtx);
}
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-10
19:35:49.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-11
21:04:44.0 +0200
@@ -29,12 +29,11 @@ int resume_device(struct device * dev)
down(dev-sem);
- if (dev-power.pm_parent
-dev-power.pm_parent-power.power_state.event
Re: [linux-usb-devel] [2/2] 2.6.22-rc4: known regressions with patches v2
On Saturday, 9 June 2007 19:40, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc4 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions SATA/PATA Subject: disk on promise pdc20378 disabled at boot References : http://bugzilla.kernel.org/show_bug.cgi?id=8587 Submitter : Jean-Luc Coulon [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit 464cf177df7727efcc5506322fc5d0c8b896f545 Patch : http://lkml.org/lkml/2007/6/6/112 Status : patch available SELinux Subject: very high non-preempt latency in context_struct_compute_av() References : http://lkml.org/lkml/2007/6/4/78 Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Stephen Smalley [EMAIL PROTECTED] James Morris [EMAIL PROTECTED] Patch : http://lkml.org/lkml/2007/6/7/334 Status : patch available Suspend Subject: panic on s3 resume with uhci_hcd module References : http://bugzilla.kernel.org/show_bug.cgi?id=8565 Submitter : Simon [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Patch : http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/21-firewire-implement-suspend-resume-hooks.patch Status : patch available The patch is already in 2.6.22-rc4, AFAICS. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Sunday, 3 June 2007 17:31, Alan Stern wrote: On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: Hi, One of my test boxes suspends to RAM just fine except that if ehci_hcd is loaded before the suspend, the box resumes immediately after going to sleep. Evidently the hardware thinks a wakeup event has occurred. It is possible to disable remote wakeup via sysfs, but it would be more interesting to find out the real reason for the wakeup. I don't know how to go about doing that, however. It might be some interaction at the ACPI level, and it might involve the PCI PME# signal. Do you have any USB devices attached when you suspend? You can try using the patch below to see what happens when you manually suspend the controller. It enables PCI devices to respond to the legacy power/state attribute. You should look at what lspci -vv says about the controller's power management signals, both before and after suspending the PCI device entry. It works as expected, AFAICS. That is, after I echo '2' to the 'state' file, it shows that the controller is in D3. I've tried to suspend with the controller in that state, but it's resumed immediately, as before. Maybe also see what ACPI reports. How can I see that? Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
Hi, One of my test boxes suspends to RAM just fine except that if ehci_hcd is loaded before the suspend, the box resumes immediately after going to sleep. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Sunday, 3 June 2007 17:31, Alan Stern wrote: On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: Hi, One of my test boxes suspends to RAM just fine except that if ehci_hcd is loaded before the suspend, the box resumes immediately after going to sleep. Evidently the hardware thinks a wakeup event has occurred. It is possible to disable remote wakeup via sysfs, but it would be more interesting to find out the real reason for the wakeup. I don't know how to go about doing that, however. It might be some interaction at the ACPI level, and it might involve the PCI PME# signal. Do you have any USB devices attached when you suspend? Not that I know of. You can try using the patch below to see what happens when you manually suspend the controller. It enables PCI devices to respond to the legacy power/state attribute. You should look at what lspci -vv says about the controller's power management signals, both before and after suspending the PCI device entry. Maybe also see what ACPI reports. I'll be able to do this in a couple of days, when I have access to the machine again. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8565] New: panic on s3 resume with uhci_hcd module
On Saturday, 2 June 2007 00:12, Andrew Morton wrote: On Fri, 1 Jun 2007 14:08:37 -0700 [EMAIL PROTECTED] wrote: Please follow up via emailed reply-to-all, rather than via the bugzilla web interface, thanks. Michal, please track this as a post-2.6.21 regression. http://bugzilla.kernel.org/show_bug.cgi?id=8565 Summary: panic on s3 resume with uhci_hcd module Kernel Version: 2.6.22.rc3 / git 2007-06-01 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: FC6 2.6.20 kernels / 2.6.21.3 Distribution: Fedora 7 Hardware Environment: Dell Inspiron 8500 Software Environment: Problem Description: I have just done a clean install of fedora 7 on my machine, replacing Fedora Core 6. When I resume my machine from suspend, it panics. My display is not reiinitialised, so using /sys/power/pm_trace I identified that the device is the following; 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) With the current fedora kernel (kernel-2.6.21-1.3194.fc7) I see the following backtrace on bootup: Jun 1 09:00:39 echo kernel: ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 Jun 1 09:00:39 echo kernel: BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted) Jun 1 09:00:39 echo kernel: [c042b0cf] local_bh_enable+0x45/0x92 Jun 1 09:00:39 echo kernel: [c06002bd] cond_resched_softirq+0x2c/0x42 Jun 1 09:00:39 echo kernel: [c059adf3] release_sock+0x4f/0x9d Jun 1 09:00:39 echo kernel: [c05c670d] tcp_sendmsg+0x90b/0x9f9 Jun 1 09:00:39 echo kernel: [c05dec95] inet_sendmsg+0x3b/0x45 Jun 1 09:00:39 echo kernel: [c0598731] sock_aio_write+0xf6/0x102 Jun 1 09:00:39 echo kernel: [c04754ee] do_sync_write+0xc7/0x10a Jun 1 09:00:39 echo kernel: [c0436e71] autoremove_wake_function+0x0/0x35 Jun 1 09:00:39 echo kernel: [c0475d47] vfs_write+0xbc/0x154 Jun 1 09:00:39 echo kernel: [c0476342] sys_write+0x41/0x67 Jun 1 09:00:39 echo kernel: [c0404f70] syscall_call+0x7/0xb Jun 1 09:00:39 echo kernel: [c060] __sched_text_start+0x6e8/0x89e Jun 1 09:00:39 echo kernel: === I wouldn't worry about this warning. There was a busted Ingo patch whcih later got fixed - I suspect it leaked into this Fedora release and it hasn't got fixed yet. I have since pulled Linus' git linux-2.6 tree (version no was 2.6.22-rc3). I built this using the default config options. In this version I still get the kernel panic, but I do not see the backtrace during bootup. Removing the uhci_hcd module allows the machine to resume without panic'ing. Hmm, strange. I have at least one test box with uhci_hcd that suspends (to RAM) and resumes successfully. Still, I've tested it with the hibernation and suspend patchset applied only. Simon, can you test 2.6.22-rc3 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/ applied? Greetings, Rafael - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wednesday, 23 May 2007 09:48, Andrew Morton wrote: On Wed, 23 May 2007 00:42:33 -0700 Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ This is intermittently getting resume-from-RAM failures. It is not sufficiently repeatable to be able to bisect. [ 1381.119362] PM: Preparing system for mem sleep [ 2331.798452] Stopping tasks ... [ 2351.760431] Stopping kernel threads timed out after 20 seconds (2 tasks refusing to freeze): [ 2351.762385] ksuspend_usbd [ 2351.764374] khubd [ 2351.766338] Restarting tasks ... done. Hmm, that seems to be related to usb-fix-suspend-to-ram.patch (probably one of the threads is waiting for a completion by some other thread that has been frozen already). Greetings, Rafael - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB: on suspend to ram/disk all usb devices are replugged
On Monday, 2 April 2007 04:54, Alan Stern wrote: On Sun, 1 Apr 2007, Rafael J. Wysocki wrote: Hi, On Sunday, 1 April 2007 20:34, Pavel Machek wrote: Hi! Problem is that suspending _with_ removable mass storage devices attached just will not work. User will unplug them, then complain about corruption. Advanced user will unplug them, work with them somewhere else, replug them, then loose filesystem. Feel free to send patch to teach filesystems to handle this. Actually what's needed is a Persistent Logical Volume Manager. With it, you could even mount a filesystem on a USB device, unplug the device, plug it back into a different port, and still be able to use the filesystem. But you're still likely to run into trouble if you unplug a storage device, move it to another system and write on it, then plug it back into the original system. The PLVM would somehow have to recognize that the data had been changed. I don't know a foolproof way of doing that. Such detection should be possible when done at filesystem level. I.e. ext3 would notice that someone replayed the journal. Or we could create ext5 where each r/w mount would update mount time... actually we probably already have last mount time in ext3, so... I'm thinking we'll need to introduce something like freezing notifiers, ie. the ability to register a notifier by an interested subsystem that will be called right after user space processes have been frozen and right before we start to thaw them (that may allow us to handle the microcode issue in a clean way, for example). Now if a filesystem registers a freezing notifier, it may be unmounted during the suspend and remounted during the resume in more or less transparent way. I think an additional mount flag would be needed for filesystem that should install such notifiers, like removable. Unmounted and remounted aren't quite the right words. All you really need to do is check (during the resume) that the superblock is still in the same state as it was when the suspend occurred. Yes, I was thinking of something more sophisticated, but this is what we need. After all, if someone else had mounted the dirty filesystem during the interim, they surely would have altered the superblock. Note that even a read-only mount of a dirty ext3 filesystem will recover the journal; presumably that will alter the superblock too. I don't think a removable flag is needed. There's no reason not to do this for every mounted filesystem. Well, I'm afraid about such filesystems as vfat ... (Also removable isn't the right word either, since hot-pluggable devices with non-removable media would need the same treatment. In fact, while the system is hibernating someone could even remove an internal IDE drive and then put it back!) I meant the filesystems could be marked as removable rather than the devices containing them, so that the users could tell us which filesystems might need special handling. One final nit: It's possible for someone to alter the data sectors directly, without mounting the filesystem. This is sufficiently perverse that we probably shouldn't worry about it. Agreed. Greetings, Rafael - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB: on suspend to ram/disk all usb devices are replugged
Hi, On Sunday, 1 April 2007 20:34, Pavel Machek wrote: Hi! Problem is that suspending _with_ removable mass storage devices attached just will not work. User will unplug them, then complain about corruption. Advanced user will unplug them, work with them somewhere else, replug them, then loose filesystem. Feel free to send patch to teach filesystems to handle this. Actually what's needed is a Persistent Logical Volume Manager. With it, you could even mount a filesystem on a USB device, unplug the device, plug it back into a different port, and still be able to use the filesystem. But you're still likely to run into trouble if you unplug a storage device, move it to another system and write on it, then plug it back into the original system. The PLVM would somehow have to recognize that the data had been changed. I don't know a foolproof way of doing that. Such detection should be possible when done at filesystem level. I.e. ext3 would notice that someone replayed the journal. Or we could create ext5 where each r/w mount would update mount time... actually we probably already have last mount time in ext3, so... I'm thinking we'll need to introduce something like freezing notifiers, ie. the ability to register a notifier by an interested subsystem that will be called right after user space processes have been frozen and right before we start to thaw them (that may allow us to handle the microcode issue in a clean way, for example). Now if a filesystem registers a freezing notifier, it may be unmounted during the suspend and remounted during the resume in more or less transparent way. I think an additional mount flag would be needed for filesystem that should install such notifiers, like removable. Greetings, Rafael - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 0/3] Change ohci-hcd autosuspend mechanism
Hi, On Monday, 25 September 2006 21:40, Alan Stern wrote: Greg and Andrew: This series of patches completely reworks the way ohci-hcd carries out root-hub autosuspends. The existing code is not compatible with the new core USB autosuspend mechanism. Patch 1 is a simple one-line change to usbcore with no harmful effects. It can go directly into both Greg's and Andrew's trees. Patch 2 removes the existing autosuspend code in ohci-hcd. It is essentially the same as a patch Rafael tried out; he confirmed that it got ohci-hcd to work on his machine both with CONFIG_USB_SUSPEND unset and with it set. This patch also can go directly into both trees. If anybody has been having trouble using their OHCI controllers with the recent -mm kernels, this should fix it. The downside is that now the controllers won't automatically get turned off when no devices are attached. Hopefully this state of affairs will be relatively short-lived. Patch 3 adds new auto-stop code to ohci-hcd. This will stop the controller only when no devices are attached, unlike the existing code which will also suspend the controller when all the attached devices are themselves suspended. That's okay, because auto-stop is meant to be used when CONFIG_USB_SUSPEND isn't set -- which means attached devices would _never_ be suspended. Patch 3 is much more experimental than the first two, and probably also more controversial (I expect David will have a lot to say about it, even if no one else does). In fact, I won't even CC: Andrew on this one; let's just keep it in the USB tree at first. More details will appear in the patch message. Alan Stern P.S.: Raphael, these three patches will apply to 2.6.18-mm1. In addition to these you might want to add this patch, which hasn't yet been accepted: http://marc.theaimsgroup.com/?l=linux-usb-develm=115867525727045w=2 I'm running 2.6.18-mm1 with the three patches and the additional one applied. So far, everything has been working just fine. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Friday, 22 September 2006 17:18, Alan Stern wrote: On Fri, 22 Sep 2006, Rafael J. Wysocki wrote: I have tested 2.6.18-rc6-mm2 with your patch applied (it is called 2.6.18-rc6 in the attached dmesg outputs, but that's because I have a customized 2.6.18-rc6-mm2 installed and I didn't want to replace it). I have tested both with and without CONFIG_USB_SUSPEND set. In either case I booted the system without my USB mouse. Then, I plugged the mouse in and checked if it worked. Next, I suspended and resumed the system twice checking if the mouse worked after each resume, without unplugging it. Finally, after the second resume I unplugged and replugged the mouse. The results are the following: 1) The kernel compiled without CONFIG_USB_SUSPEND works just fine, suspends and resumes correctly, and the mouse always works (ie. is correctly detected every time). Good. 2) The kernel compiled with CONFIG_USB_SUSPEND set doesn't detect the mouse plugged in after a fresh boot. However, if the mouse is connected to a USB port during an entire suspend/resume cycle, it works after the resume, but when it's unplugged after the resume and replugged, the kernel fails to detect it. The outputs of dmesg for each case are attached. This helped. I think I figured out the problem. Below is a new version of the patch I asked you to try. It's the same as before except that I removed a bunch of extra code. Some weird interactions between the driver and usbcore prevented status-change interrupts from being enabled; hence the connect-change events just get lost. Anyway, this should solve the problem. It does. Now the kernel with CONFIG_USB_SUSPEND set works fine. Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
On Tuesday, 19 September 2006 02:04, David Brownell wrote: On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote: Hi, It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Where I've seen such issues in the past has been with one specific device: a UPS that seems unhappy if it doesn't get a VBUS power cycle, so that OHCI implementations that don't implement power switching are bad choices for connecting that particular UPS. I believe that's not the issue in your case. I compared the boot sequence you sent with one for the NF3-150 I use a lot (also x86_64) which does not exhibit this failure, and the differences I noticed were: - NOCP set in roothub.a ... your BIOS reports no overcurrent protection - different 2.6.18 prepatches ... you used rc6-mm2, not rc7 - different irqs (you used PIC not IOAPIC) - driver registration sequence different ... I registered EHCI first - yours came _up_ with RHSC irq pending on one root (device present) And re those last two, it didn't finish mouse enumeration with OHCI before starting to do it with EHCI. I could easily see how that would lead to timing-dependent/intermittent failures. Now, registering EHCI first is not supposed to matter, but I'm thinking it started to matter a while back, since a few folk have reported as much. One suspicion being that some of the hub driver changes have had some bad consequences. (My suspicions there were highlighted by noticing some of the misbehavior associated with an embedded USB controller I was testing, which provoked failures in those same code paths...) The root hub handoff relies on the usb/core/hub.c code to do the right things, notably treating disconnect-during-reset (handoff to companion) as routine, but I think I noticed that fault handling logic has changed. At any rate, that suggests a few experiments to me. - First, does this still show up with the stock RC7 code? There are a bunch of IMO rather experimental USB patches in the MM tree... including several affecting usbcore hub support. - Second does it appear without EHCI loaded? If not, that would tend to confirm an issue usbcore hub driver handoff logic. - Third, does it appear if EHCI is loaded _first_ (as the distro should already have been doing just to avoid thrashing during system startup)? Similar comment re previous experiment, though it'd provide a potential workaround. I'd kind of suspect that the generic RC7 code, with EHCI loaded first as it should be, would just work. Yes, I think the problem resulted from the experimental patches in -mm. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Saturday, 16 September 2006 10:13, Rafael J. Wysocki wrote: On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote: It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged into the USB ports. For example, if I unplug and replug a mouse (that worked before unplugging), it doesn't work any more. I have to reload ohci_hcd to make it work again. This is 100% reproducible and occurs on the two boxes above. I have carried out a binary search and found that the problem is caused by gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Monday, 18 September 2006 08:50, Jan De Luyck wrote: On Monday 18 September 2006 08:27, Rafael J. Wysocki wrote: On Saturday, 16 September 2006 10:13, Rafael J. Wysocki wrote: On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote: It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged into the USB ports. For example, if I unplug and replug a mouse (that worked before unplugging), it doesn't work any more. I have to reload ohci_hcd to make it work again. This is 100% reproducible and occurs on the two boxes above. I can confirm this behaviour. I've also seen that sometimes my USB keyboard/mouse doesn't work after booting up. Reloading the module solves the problem. This is on an amd64 box, ABIT kn9-sli, nForce 550. This is with 2.6.17.13. I have carried out a binary search and found that the problem is caused by gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch Will this work against 2.6.17.13 vanilla? No, this patch is not present in vanilla. Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Monday, 18 September 2006 17:07, Alan Stern wrote: On Mon, 18 Sep 2006, Rafael J. Wysocki wrote: Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged into the USB ports. For example, if I unplug and replug a mouse (that worked before unplugging), it doesn't work any more. I have to reload ohci_hcd to make it work again. This is 100% reproducible and occurs on the two boxes above. I have carried out a binary search and found that the problem is caused by gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch Tell me, what happens if you leave that patch installed, and you use the patch I sent last week (the one that removes a chunk of code from ohci-hub.c), and you also set CONFIG_USB_SUSPEND? The problem continues to happen. Moreover, if I revert the above patch and apply the patch removing code from ohci-hub.c, the problem reappears. I think the real underlying problem here is that David's implementation of root-hub suspend in ohci-hcd is incompatible with the overall scheme I've been working on. In the end I'll probably have to rewrite the ohci-hcd code. Well, at this point I can only help you by testing some code. ;-) Seriously, if you have any new patches to test, please let me know. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
Hi, On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote: It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged into the USB ports. For example, if I unplug and replug a mouse (that worked before unplugging), it doesn't work any more. I have to reload ohci_hcd to make it work again. This is 100% reproducible and occurs on the two boxes above. Appended in a snippet from a dmesg output that I think is relevant to this issue. It covers the unplugging and replugging of a USB mouse (there are no more USB-related messages in the dmesg). Greetings, Rafael hub 3-0:1.0: state 7 ports 4 chg evt 0010 ohci_hcd :00:13.1: GetStatus roothub.portstatus [3] = 0x00030100 PESC CSC PPS hub 3-0:1.0: port 4, status 0100, change 0003, 12 Mb/s usb 3-4: USB disconnect, address 2 usb 3-4: unregistering device usb 3-4: usb_disable_device nuking all URBs ohci_hcd :00:13.1: shutdown urb 81002f77d4b8 pipe 40408280 ep1in-intr usb 3-4: unregistering interface 3-4:1.0 PM: Removing info for No Bus:usbdev3.2_ep81 usbdev3.2_ep81: ep_device_release called for usbdev3.2_ep81 PM: Removing info for usb:3-4:1.0 usb 3-4:1.0: uevent PM: Removing info for No Bus:usbdev3.2 PM: Removing info for No Bus:usbdev3.2_ep00 usbdev3.2_ep00: ep_device_release called for usbdev3.2_ep00 PM: Removing info for usb:3-4 usb 3-4: uevent hub 3-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x100 hub 1-0:1.0: state 7 ports 8 chg evt 0100 ehci_hcd :00:13.2: GetStatus port 8 status 001403 POWER sig=k CSC CONNECT hub 1-0:1.0: port 8, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 8: total 100ms stable 100ms status 0x501 ehci_hcd :00:13.2: port 8 low speed -- companion ehci_hcd :00:13.2: GetStatus port 8 status 003002 POWER OWNER sig=se0 CSC -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Saturday, 16 September 2006 00:45, Pete Zaitcev wrote: On Thu, 14 Sep 2006 13:19:53 +0200, Rafael J. Wysocki [EMAIL PROTECTED] wrote: In fact I can reproduce it on two different boxes now. How about the attached? Apparently works. :-) Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
Hi, It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Thursday, 14 September 2006 00:31, Pete Zaitcev wrote: On Wed, 13 Sep 2006 14:44:48 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: This problem has already been identified by Pete Zaitcev in this thread: http://marc.theaimsgroup.com/?t=11576951281r=1w=2 Perhaps Pete has an updated patch to fix the problem. If not, I could write one. No, not yet. I am working on getting David's approach with irq = -1 tested at Stratus. Since it was the only reproducer known to me, I wanted to test. Now that Rafael has a fault case, I'll expedite. In fact I can reproduce it on two different boxes now. Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 23:55, Alan Stern wrote: On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: Try this patch instead. It looks for problems occurring a little earlier in the call chain. I've applied both patches at a time (I hope they don't conflict). The dmesg output is attached. The dmesg output shows the root-hub device state is set wrong. I have to leave now, so I can't give you another patch to try. You can experiment as follows... Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume(). The part of interest is everything following the restart: statement label. Try adding some ehci_dbg() lines in there (copy the form of the line just after restart:). We want to follow the value of hcd-self.root_hub-state. Initially it should be equal to USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but almost certainly somewhere in this routine. If you can find out where that happens, I'd appreciate it. Done, but it shows hcd-self.root_hub-state is already 7 right after restart. I've used the following patch to verify this: --- drivers/usb/host/ehci-pci.c |8 1 file changed, 8 insertions(+) Index: linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c === --- linux-2.6.18-rc6-mm2.orig/drivers/usb/host/ehci-pci.c +++ linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c @@ -291,14 +291,19 @@ static int ehci_pci_resume(struct usb_hc restart: ehci_dbg(ehci, lost power, restarting\n); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); usb_root_hub_lost_power(hcd-self.root_hub); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); /* Else reset, to cope with power loss or flush-to-storage * style resume having let BIOS kick in during reboot. */ (void) ehci_halt(ehci); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); (void) ehci_reset(ehci); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); (void) ehci_pci_reinit(ehci, pdev); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); /* emptying the schedule aborts any urbs */ spin_lock_irq(ehci-lock); @@ -306,12 +311,15 @@ restart: ehci-reclaim_ready = 1; ehci_work(ehci, NULL); spin_unlock_irq(ehci-lock); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); /* restart; khubd will disconnect devices */ retval = ehci_run(hcd); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); /* here we know root ports should always stay powered */ ehci_port_power(ehci, 1); + ehci_dbg(ehci, root hub state: %d\n, hcd-self.root_hub-state); return retval; } The output of dmesg is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug-3.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 15:14, Rafael J. Wysocki wrote: On Wednesday, 13 September 2006 23:55, Alan Stern wrote: On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: Try this patch instead. It looks for problems occurring a little earlier in the call chain. I've applied both patches at a time (I hope they don't conflict). The dmesg output is attached. The dmesg output shows the root-hub device state is set wrong. I have to leave now, so I can't give you another patch to try. You can experiment as follows... Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume(). The part of interest is everything following the restart: statement label. Try adding some ehci_dbg() lines in there (copy the form of the line just after restart:). We want to follow the value of hcd-self.root_hub-state. Initially it should be equal to USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but almost certainly somewhere in this routine. If you can find out where that happens, I'd appreciate it. Done, but it shows hcd-self.root_hub-state is already 7 right after restart. BTW, all of the systems on which the problem shows up seem to be 64-bit. If you can't reproduce it on a 32-bit system, some type casting may be wrong somewhere. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 17:04, Alan Stern wrote: On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: Try adding some ehci_dbg() lines in there (copy the form of the line just after restart:). We want to follow the value of hcd-self.root_hub-state. Initially it should be equal to USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but almost certainly somewhere in this routine. If you can find out where that happens, I'd appreciate it. Done, but it shows hcd-self.root_hub-state is already 7 right after restart. BTW, all of the systems on which the problem shows up seem to be 64-bit. If you can't reproduce it on a 32-bit system, some type casting may be wrong somewhere. I realized last night what the problem must be. It's extremely obvious in retrospect, but I happen to have a blind spot in this particular area. All you guys must have CONFIG_USB_SUSPEND turned off. Mattis certainly does; I checked his .config. Now I hardly ever do any testing without CONFIG_USB_SUSPEND, since there's not much point working on power management code if your kernel isn't set up to actually suspend devices. As a result I missed seeing the problems caused by the autosuspend changes. Well, on my box the USB suspend also doesn't work with USB_SUSPEND set, but the reason is different: sb usb2: 'global' suspend -16 hub 2-0:1.0: suspend error -16 suspend_device(): usb_suspend+0x0/0x5b [usbcore]() returns -16 Could not suspend device usb2: error -16 The .config and full dmesg output (with the three debug patches applied) are attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-usb-suspend.log.gz Description: GNU Zip compressed data kernel-config.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 18:17, Alan Stern wrote: On Thu, 14 Sep 2006, Alan Stern wrote: Now of course, the autosuspend stuff has to work properly no matter what the kernel configuration is. I'll go back and rebuild the drivers with USB_SUSPEND turned off and see what happens. With any luck I'll have a fix ready in the near future. This should start fixing things, but I'm not certain it will solve the entire problem. If it doesn't work, send another dmesg log. Now USB didn't work after the first resume (kernel configured with USB_SUSPEND unset). The dmesg output is attached. Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-with-fix.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 19:08, Rafael J. Wysocki wrote: On Thursday, 14 September 2006 18:17, Alan Stern wrote: On Thu, 14 Sep 2006, Alan Stern wrote: Now of course, the autosuspend stuff has to work properly no matter what the kernel configuration is. I'll go back and rebuild the drivers with USB_SUSPEND turned off and see what happens. With any luck I'll have a fix ready in the near future. This should start fixing things, but I'm not certain it will solve the entire problem. If it doesn't work, send another dmesg log. Now USB didn't work after the first resume (kernel configured with USB_SUSPEND unset). Okay, this is not reproducible, so I gather it was due to my other problem with the USB resume (sigh). Anyway, the second suspend/resume worked just fine, so the patch apparently helps. Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 19:22, Alan Stern wrote: On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: Now USB didn't work after the first resume (kernel configured with USB_SUSPEND unset). The dmesg output is attached. This is getting too confusing. :-( Sorry for the confusion. Let's try a simpler test. Leave USB_SUSPEND unset. First rmmod ohci-hcd. None of your full-speed USB devices will work, but that's okay. Try the suspend-twice test and see what happens. Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the suspend-twice test. Done, works (with USB_SUSPEND unset). Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 20:28, Alan Stern wrote: On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: Let's try a simpler test. Leave USB_SUSPEND unset. First rmmod ohci-hcd. None of your full-speed USB devices will work, but that's okay. Try the suspend-twice test and see what happens. Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the suspend-twice test. Done, works (with USB_SUSPEND unset). Okay, good. Well, sorry. This test has been passed, but after a reboot it refused to suspend just once giving the same messages that I've got from the kernel with USB_SUSPEND set (the relevant dmesg output is attached). Then for the next stage, repeat the same tests but with USB_SUSPEND set. Compiling. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-first-suspend-failure.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 21:37, Rafael J. Wysocki wrote: On Thursday, 14 September 2006 20:28, Alan Stern wrote: On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: Let's try a simpler test. Leave USB_SUSPEND unset. First rmmod ohci-hcd. None of your full-speed USB devices will work, but that's okay. Try the suspend-twice test and see what happens. Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the suspend-twice test. Done, works (with USB_SUSPEND unset). Okay, good. Well, sorry. This test has been passed, but after a reboot it refused to suspend just once giving the same messages that I've got from the kernel with USB_SUSPEND set (the relevant dmesg output is attached). This only happens if _both_ ohci_hcd and ehci_hcd are loaded before the suspend. Then for the next stage, repeat the same tests but with USB_SUSPEND set. Compiling. The results are now the same with and without USB_SUSPEND set. Namely, if one hcd is loaded before a suspend (either ehci or ohci), it succeeds (repeatable arbitrary number of times in a row). However, if both hcds are loaded before a suspend, it fails (100% of the time) and the messages are like in the dmesg output attached to the previous message. I've reproduced this behavior on another x86_64 box. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 22:55, Alan Stern wrote: On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: Well, sorry. This test has been passed, but after a reboot it refused to suspend just once giving the same messages that I've got from the kernel with USB_SUSPEND set (the relevant dmesg output is attached). Then for the next stage, repeat the same tests but with USB_SUSPEND set. Okay, hang on, let's try to solve this first. This actually is a completely different problem from what I've been attacking up to now, and we definitely should resolve it. It's purely a question of the ohci-hcd driver, nothing (or very little) to do with usbcore or ehci-hcd or uhci-hcd. I'm asking David to chime in, because this is his code and his driver. Here's an explanation of the problem. Basically it boils down to the way ohci-hcd rolls its own root-hub autosuspend. I'm referring to the call to ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data(). Things go wrong because that call totally bypasses usbcore. It's a layering violation. The corresponding root-hub autoresume code, i.e., the call to usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through usbcore. It fails for two reasons. First, resume_root_hub does its job by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND isn't set that routine is a no-op. Second, since usbcore was never notified when the root hub was suspended, the root hub's device state isn't USB_STATE_SUSPENED and the interface is still marked as active -- so even if usb_autoresume_device() did get called it wouldn't do anything. As I see it, there are two ways to resolve the problem. The easiest is to rip out the autosuspend stuff from ohci-hcd entirely. When my generic autosuspend patches are accepted, the HCD-specific stuff won't be needed so much. This has the disadvantage that the root hub will never get suspended if CONFIG_USB_SUSPEND isn't set. On the other hand, this is how ehci_hcd works already. This isn't a big deal as far as I'm concerned, but I think that dependancy will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND gets selected automatically if CONFIG_PM is set). The second way is to copy what I did in uhci-hcd. There is a special root hub is stopped mode which kicks in only when no ports are connected. It isn't a full-fledged suspend, in the sense that usbcore isn't notified -- just like what happens in ohci-hcd. The difference is, since we know no devices are attached, the driver can go back to normal operation while in interrupt context. It doesn't have to sleep because no attached devices means no TRSMRCY delay is needed and the controller's hardware can be reset directly. As a result, the corresponding auto-restart code doesn't need to go through usbcore either and so usb_autoresume_device() never enters the picture. I don't know if this is feasible with OHCI. For now, I'll include a patch that takes the first approach and disables the ohci-hcd autosuspend entirely. I think it will solve your problem above. Yes it does. Now I'm able to suspend/resume several times in a row with both ohci and ehci hcds loaded all the time. Thanks a lot! Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: On Friday, 8 September 2006 22:44, Alan Stern wrote: On Fri, 8 Sep 2006, Andrew Morton wrote: Alan, is this likely to be due to your USB PM changes? It's possible. Most of those changes are innocuous. They add routines that don't get used until a later patch. However one of them might be responsible. Well, after recompiling the kernel for several times (because of a different problem) I'm no longer able to reproduce the problem. I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens. It's not readily reproducible, as I said before, and it apparently doesn't happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 14:07, Rafael J. Wysocki wrote: On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: On Friday, 8 September 2006 22:44, Alan Stern wrote: On Fri, 8 Sep 2006, Andrew Morton wrote: Alan, is this likely to be due to your USB PM changes? It's possible. Most of those changes are innocuous. They add routines that don't get used until a later patch. However one of them might be responsible. Well, after recompiling the kernel for several times (because of a different problem) I'm no longer able to reproduce the problem. I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens. It's not readily reproducible, as I said before, and it apparently doesn't happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted. Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted too. Attached is the output of dmesg from the failing case with USB_DEBUG set. It covers two attempts to suspend to disk, the second one being unsuccessful, with reloading the ohci_hcd module in between. [This kernel also has your other patch to prevent the second suspend from failing applied, but it doesn't help.] Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Tuesday, 12 September 2006 09:06, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/ 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every time (happens also on -rc6-mm1, does not happen on -rc7): Unable to handle kernel NULL pointer dereference at 0274 RIP: [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b PGD 35ca9067 PUD 369a4067 PMD 0 Oops: [1] SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies CPU 0 Modules linked in: netconsole cpufreq_ondemand cpufreq_userspace cpufreq_powersa ve powernow_k8 freq_table button af_packet edd battery snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_man gle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_ tables ip6table_filter ip6_tables x_tables ipv6 loop dm_mod usbhid ff_memless hc i_usb bluetooth snd_hda_intel snd_hda_codec bcm43xx ohci1394 ohci_hcd shpchp pci _hotplug pcmcia ehci_hcd i2c_piix4 ieee1394 firmware_class ieee80211softmac usbc ore tg3 sdhci ieee80211 ieee80211_crypt mmc_core ide_cd k8temp yenta_socket rsrc _nonstatic pcmcia_core i2c_core hwmon snd_pcm snd_timer snd soundcore snd_page_a lloc cdrom ext3 jbd fan thermal processor atiixp ide_disk ide_core sg Pid: 3667, comm: rmmod Tainted: G M 2.6.18-rc6-mm2 #19 RIP: 0010:[8822c185] [8822c185] :ohci_hcd:ohci_hub_status_d ata+0x25/0x27b RSP: 0018:805c7e18 EFLAGS: 00010296 RAX: RBX: 81003485c508 RCX: RDX: 0064 RSI: 805c7e68 RDI: 81003485c640 RBP: 805c7e58 R08: R09: 810037438138 R10: 80701c40 R11: 81003263bc88 R12: 81003485c640 R13: 805c7e68 R14: c203c000 R15: 81003485c508 FS: 2ba0d06fa6d0() GS:8066f000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0274 CR3: 2f153000 CR4: 06e0 Process rmmod (pid: 3667, threadinfo 81003263a000, task 81003697c810) Stack: 802813b0 805c7e40 80281258 81003485c508 81003485c508 81003485c508 c203c000 805c7e68 805c7ea8 8818e03f 003d09e3f5998950 80509860 Call Trace: [8818e03f] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b [8822c01b] :ohci_hcd:ohci_irq+0xcb/0x210 [8818e78b] :usbcore:usb_hcd_irq+0x2f/0x5f [8020ef13] handle_IRQ_event+0x33/0x66 [802af5f8] handle_fasteoi_irq+0x9d/0xe3 [80267c85] do_IRQ+0x104/0x11f [80259621] ret_from_intr+0x0/0xa DWARF2 unwinder stuck at ret_from_intr+0x0/0xa Leftover inexact backtrace: IRQ EOI [802ee4ac] sysfs_hash_and_remove+0x9/0x137 [802eed13] sysfs_remove_file+0x10/0x12 [8038baf7] class_device_remove_file+0x12/0x14 [8822aa02] :ohci_hcd:ohci_stop+0xf5/0x17b [8818d9d2] :usbcore:usb_remove_hcd+0xdc/0x114 [8040f8eb] klist_release+0x0/0x82 [88197f45] :usbcore:usb_hcd_pci_remove+0x1e/0x7d [803204d8] pci_device_remove+0x25/0x3c [8038b1b5] __device_release_driver+0x80/0x9c [8038b617] driver_detach+0xac/0xee [8038ad92] bus_remove_driver+0x75/0x98 [8038b696] driver_unregister+0x15/0x21 [80320686] pci_unregister_driver+0x13/0x8e [8822cd1c] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 [8029b281] sys_delete_module+0x1b5/0x1e6 [8025910e] system_call+0x7e/0x83 Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4 RIP [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b RSP 805c7e18 CR2: 0274 0Kernel panic - not syncing: Aiee, killing interrupt handler! where (gdb) l *ohci_hub_status_data+0x25 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316). 311 struct ohci_hcd *ohci = hcd_to_ohci (hcd); 312 int i, changed = 0, length = 1; 313 int can_suspend; 314 unsigned long flags; 315 316 can_suspend = device_may_wakeup(hcd-self.root_hub-dev); 317 spin_lock_irqsave (ohci-lock, flags); 318 319 /* handle autosuspended root: finish resuming before 320 * letting khubd or root hub timer see state changes. I guess it may be related to the suspend issues? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at:
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Wednesday, 13 September 2006 15:58, Rafael J. Wysocki wrote: On Tuesday, 12 September 2006 09:06, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/ 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every time (happens also on -rc6-mm1, does not happen on -rc7): So far, I have verified that the problem already happened on -rc5-mm1. Greetings, Rafael Unable to handle kernel NULL pointer dereference at 0274 RIP: [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b PGD 35ca9067 PUD 369a4067 PMD 0 Oops: [1] SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies CPU 0 Modules linked in: netconsole cpufreq_ondemand cpufreq_userspace cpufreq_powersa ve powernow_k8 freq_table button af_packet edd battery snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_man gle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_ tables ip6table_filter ip6_tables x_tables ipv6 loop dm_mod usbhid ff_memless hc i_usb bluetooth snd_hda_intel snd_hda_codec bcm43xx ohci1394 ohci_hcd shpchp pci _hotplug pcmcia ehci_hcd i2c_piix4 ieee1394 firmware_class ieee80211softmac usbc ore tg3 sdhci ieee80211 ieee80211_crypt mmc_core ide_cd k8temp yenta_socket rsrc _nonstatic pcmcia_core i2c_core hwmon snd_pcm snd_timer snd soundcore snd_page_a lloc cdrom ext3 jbd fan thermal processor atiixp ide_disk ide_core sg Pid: 3667, comm: rmmod Tainted: G M 2.6.18-rc6-mm2 #19 RIP: 0010:[8822c185] [8822c185] :ohci_hcd:ohci_hub_status_d ata+0x25/0x27b RSP: 0018:805c7e18 EFLAGS: 00010296 RAX: RBX: 81003485c508 RCX: RDX: 0064 RSI: 805c7e68 RDI: 81003485c640 RBP: 805c7e58 R08: R09: 810037438138 R10: 80701c40 R11: 81003263bc88 R12: 81003485c640 R13: 805c7e68 R14: c203c000 R15: 81003485c508 FS: 2ba0d06fa6d0() GS:8066f000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0274 CR3: 2f153000 CR4: 06e0 Process rmmod (pid: 3667, threadinfo 81003263a000, task 81003697c810) Stack: 802813b0 805c7e40 80281258 81003485c508 81003485c508 81003485c508 c203c000 805c7e68 805c7ea8 8818e03f 003d09e3f5998950 80509860 Call Trace: [8818e03f] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b [8822c01b] :ohci_hcd:ohci_irq+0xcb/0x210 [8818e78b] :usbcore:usb_hcd_irq+0x2f/0x5f [8020ef13] handle_IRQ_event+0x33/0x66 [802af5f8] handle_fasteoi_irq+0x9d/0xe3 [80267c85] do_IRQ+0x104/0x11f [80259621] ret_from_intr+0x0/0xa DWARF2 unwinder stuck at ret_from_intr+0x0/0xa Leftover inexact backtrace: IRQ EOI [802ee4ac] sysfs_hash_and_remove+0x9/0x137 [802eed13] sysfs_remove_file+0x10/0x12 [8038baf7] class_device_remove_file+0x12/0x14 [8822aa02] :ohci_hcd:ohci_stop+0xf5/0x17b [8818d9d2] :usbcore:usb_remove_hcd+0xdc/0x114 [8040f8eb] klist_release+0x0/0x82 [88197f45] :usbcore:usb_hcd_pci_remove+0x1e/0x7d [803204d8] pci_device_remove+0x25/0x3c [8038b1b5] __device_release_driver+0x80/0x9c [8038b617] driver_detach+0xac/0xee [8038ad92] bus_remove_driver+0x75/0x98 [8038b696] driver_unregister+0x15/0x21 [80320686] pci_unregister_driver+0x13/0x8e [8822cd1c] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 [8029b281] sys_delete_module+0x1b5/0x1e6 [8025910e] system_call+0x7e/0x83 Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4 RIP [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b RSP 805c7e18 CR2: 0274 0Kernel panic - not syncing: Aiee, killing interrupt handler! where (gdb) l *ohci_hub_status_data+0x25 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316). 311 struct ohci_hcd *ohci = hcd_to_ohci (hcd); 312 int i, changed = 0, length = 1; 313 int can_suspend; 314 unsigned long flags; 315 316 can_suspend = device_may_wakeup(hcd-self.root_hub-dev); 317 spin_lock_irqsave (ohci-lock, flags); 318 319 /* handle autosuspended root: finish resuming before 320 * letting khubd or root hub timer see state changes. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Tuesday, 12 September 2006 22:10, Alan Stern wrote: On Tue, 12 Sep 2006, Mattia Dongili wrote: No luck here. I'll give -mm2 a run just to full dmesg with patch applied[1]: http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3-2 without it (it's almost identical :)): http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3 .config: http://oioio.altervista.org/linux/config-2.6.18-rc6-mm1-3 [1]: I didn't rebuild fully, just applied the patch and re-run make bzImage modules I can't reproduce your results here with my configuration. I used 2.6.18-rc6-mm2 instead of -mm1 but I don't think that should matter. On my box the issue (the second suspend of USB controllers in a row fails 100% of the time) went away after I had reverted the following patches (I'm using 2.6.18-rc6-mm2 now): fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch gregkh-usb-usbcore-non-hub-specific-uses-of-autosuspend.patch gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Wednesday, 13 September 2006 20:44, Alan Stern wrote: On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every time (happens also on -rc6-mm1, does not happen on -rc7): Unable to handle kernel NULL pointer dereference at 0274 RIP: [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b PGD 35ca9067 PUD 369a4067 PMD 0 Call Trace: [8818e03f] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b [8822c01b] :ohci_hcd:ohci_irq+0xcb/0x210 [8818e78b] :usbcore:usb_hcd_irq+0x2f/0x5f [8020ef13] handle_IRQ_event+0x33/0x66 [802af5f8] handle_fasteoi_irq+0x9d/0xe3 [80267c85] do_IRQ+0x104/0x11f [80259621] ret_from_intr+0x0/0xa DWARF2 unwinder stuck at ret_from_intr+0x0/0xa Leftover inexact backtrace: IRQ EOI [802ee4ac] sysfs_hash_and_remove+0x9/0x137 [802eed13] sysfs_remove_file+0x10/0x12 [8038baf7] class_device_remove_file+0x12/0x14 [8822aa02] :ohci_hcd:ohci_stop+0xf5/0x17b [8818d9d2] :usbcore:usb_remove_hcd+0xdc/0x114 [8040f8eb] klist_release+0x0/0x82 [88197f45] :usbcore:usb_hcd_pci_remove+0x1e/0x7d [803204d8] pci_device_remove+0x25/0x3c [8038b1b5] __device_release_driver+0x80/0x9c [8038b617] driver_detach+0xac/0xee [8038ad92] bus_remove_driver+0x75/0x98 [8038b696] driver_unregister+0x15/0x21 [80320686] pci_unregister_driver+0x13/0x8e [8822cd1c] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 [8029b281] sys_delete_module+0x1b5/0x1e6 [8025910e] system_call+0x7e/0x83 Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4 RIP [8822c185] :ohci_hcd:ohci_hub_status_data+0x25/0x27b RSP 805c7e18 CR2: 0274 0Kernel panic - not syncing: Aiee, killing interrupt handler! where (gdb) l *ohci_hub_status_data+0x25 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316). 311 struct ohci_hcd *ohci = hcd_to_ohci (hcd); 312 int i, changed = 0, length = 1; 313 int can_suspend; 314 unsigned long flags; 315 316 can_suspend = device_may_wakeup(hcd-self.root_hub-dev); 317 spin_lock_irqsave (ohci-lock, flags); 318 319 /* handle autosuspended root: finish resuming before 320 * letting khubd or root hub timer see state changes. I guess it may be related to the suspend issues? No, this is completely separate. The suspend issue involved ehci-hcd, not ohci-hcd. Well, on my box it's ohci-hcd too. This problem has already been identified by Pete Zaitcev in this thread: http://marc.theaimsgroup.com/?t=11576951281r=1w=2 Ah, thanks. Perhaps Pete has an updated patch to fix the problem. If not, I could write one. For now I can use the original Pete's patch, but it would be nice to have a fix in -mm. ;-) Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 20:38, Alan Stern wrote: On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted too. Attached is the output of dmesg from the failing case with USB_DEBUG set. It covers two attempts to suspend to disk, the second one being unsuccessful, with reloading the ohci_hcd module in between. [This kernel also has your other patch to prevent the second suspend from failing applied, but it doesn't help.] Okay. Your problem, and probably Mattia's too, is something other than what that recent patch addressed. I can't tell from the dmesg log exactly what went wrong, but I can tell you where to look. In drivers/usb/core/driver.c, resume_device() is not succeeding. That is, the lines near the end which do if (status == 0) udev-dev.power.power_state.event = PM_EVENT_ON; aren't running during the first resume. You can see this in the dmesg log; lines 1173-1175 say usb usb1: resuming usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1 hub 1-0:1.0: PM: resume from 0, parent usb1 still 1 If power_state.event had gotten set to PM_EVENT_ON then the parent state would be 0, not 1. This is the source of your problem. During your second suspend attempt, usb1 didn't get handled correctly because its state was set wrong. (I suspect the mishandling took place in usbcore rather than the PM core, but it doesn't matter. The state should not have been wrong to begin with.) Consequently its parent device :00:13.2 refused to freeze, which aborted the suspend attempt. For the usb1 device, udriver-resume should point to the generic_resume() routine in drivers/usb/core/generic.c. In fact, this should be true for every device that driver.c:resume_device() sees. But generic_resume() simply calls usb_port_resume() in hub.c, and the log doesn't contain any of the USB debugging messages that usb_port_resume() would produce. So I can't tell what happened. The patch below will add some extra debugging information. We need to find out why the resume didn't succeed. Oh -- and of course, you should reinstate all those autosuspend patches. Otherwise this patch won't apply! OK Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied. It covers two consecutive attempts to suspend (the second one obviously failed). Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 23:01, Alan Stern wrote: On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: The patch below will add some extra debugging information. We need to find out why the resume didn't succeed. Oh -- and of course, you should reinstate all those autosuspend patches. Otherwise this patch won't apply! OK Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied. It covers two consecutive attempts to suspend (the second one obviously failed). Hmm... The patch didn't yield any output. Unlike Mattia's log, yours doesn't include any lines saying usb usb1: wakeup_rh so I can't be sure whether the patch code should have run or not. Try this patch instead. It looks for problems occurring a little earlier in the call chain. I've applied both patches at a time (I hope they don't conflict). The dmesg output is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug-2.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: On Friday, 8 September 2006 22:44, Alan Stern wrote: On Fri, 8 Sep 2006, Andrew Morton wrote: Alan, is this likely to be due to your USB PM changes? It's possible. Most of those changes are innocuous. They add routines that don't get used until a later patch. However one of them might be responsible. Well, after recompiling the kernel for several times (because of a different problem) I'm no longer able to reproduce the problem. Now I have another symtom: during the _second_ suspend the suspending of USB controllers fails with messages like this: usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22 pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22 suspend_device(): pci_device_suspend+0x0/0x4b() returns -22 Could not suspend device :00:13.2: error -22 Could you please tell me which patches might have caused this, in your opinion? Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Friday, 8 September 2006 10:13, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/ ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on 2.6.18-rc5-mm1. It helps if I rmmod and modprobe it after the resume. Here's the relevant part of the dmesg output: usb usb1: resuming usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1 hub 1-0:1.0: PM: resume from 0, parent usb1 still 1 hub 1-0:1.0: resuming usbdev1.1: PM: resume from 0, parent usb1 still 1 usb usb2: resuming usb usb2: root hub lost power or was reset usbdev2.1_ep00: PM: resume from 0, parent usb2 still 1 hub 2-0:1.0: PM: resume from 0, parent usb2 still 1 hub 2-0:1.0: resuming usbdev2.1: PM: resume from 0, parent usb2 still 1 usb usb3: resuming usb usb3: root hub lost power or was reset usbdev3.1_ep00: PM: resume from 0, parent usb3 still 1 hub 3-0:1.0: PM: resume from 0, parent usb3 still 1 hub 3-0:1.0: resuming usbdev3.1: PM: resume from 0, parent usb3 still 1 usb 2-2: PM: resume from 1, parent usb2 still 1 usb 2-2: resuming usbdev2.2_ep00: PM: resume from 0, parent 2-2 still 1 hci_usb 2-2:1.0: PM: resume from 1, parent 2-2 still 1 hci_usb 2-2:1.0: resuming usbdev2.2_ep81: PM: resume from 0, parent 2-2:1.0 still 1 usbdev2.2_ep82: PM: resume from 0, parent 2-2:1.0 still 1 usbdev2.2_ep02: PM: resume from 0, parent 2-2:1.0 still 1 hci_usb 2-2:1.1: PM: resume from 1, parent 2-2 still 1 hci_usb 2-2:1.1: resuming usb 2-2:1.2: PM: resume from 1, parent 2-2 still 1 usb 2-2:1.2: resuming usbdev2.2_ep84: PM: resume from 0, parent 2-2:1.2 still 1 usbdev2.2_ep04: PM: resume from 0, parent 2-2:1.2 still 1 usb 2-2:1.3: PM: resume from 1, parent 2-2 still 1 usb 2-2:1.3: resuming usbdev2.2: PM: resume from 0, parent 2-2 still 1 platform bluetooth: resuming usb 3-1: PM: resume from 1, parent usb3 still 1 usb 3-1: resuming usbdev3.2_ep00: PM: resume from 0, parent 3-1 still 1 usb 3-1:1.0: PM: resume from 1, parent 3-1 still 1 usb 3-1:1.0: resuming usbdev3.2_ep81: PM: resume from 0, parent 3-1:1.0 still 1 usbdev3.2_ep02: PM: resume from 0, parent 3-1:1.0 still 1 usbdev3.2: PM: resume from 0, parent 3-1 still 1 usb 3-4: PM: resume from 1, parent usb3 still 1 usb 3-4: resuming usbdev3.3_ep00: PM: resume from 0, parent 3-4 still 1 usbhid 3-4:1.0: PM: resume from 1, parent 3-4 still 1 usbhid 3-4:1.0: resuming usbdev3.3_ep81: PM: resume from 0, parent 3-4:1.0 still 1 usbdev3.3: PM: resume from 0, parent 3-4 still 1 usbdev2.2_ep83: PM: resume from 0, parent 2-2:1.1 still 1 usbdev2.2_ep03: PM: resume from 0, parent 2-2:1.1 still 1 hci0: PM: resume from 0, parent 2-2:1.0 still 1 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Friday, 8 September 2006 22:44, Alan Stern wrote: On Fri, 8 Sep 2006, Andrew Morton wrote: Alan, is this likely to be due to your USB PM changes? It's possible. Most of those changes are innocuous. They add routines that don't get used until a later patch. However one of them might be responsible. Well, after recompiling the kernel for several times (because of a different problem) I'm no longer able to reproduce the problem. Sorry for the noise. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc1-mm2
On Friday 14 July 2006 07:48, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm2/ - Patches were merged, added, dropped and fixed. Nothing particularly exciting. This happens on my box at startup, every time: ehci_hcd :00:02.2: EHCI Host Controller ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3 ehci_hcd :00:02.2: debug port 1 ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00 ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb 2-1: USB disconnect, address 2 Unable to handle kernel NULL pointer dereference at 0038 RIP: [8024a07b] __lock_acquire+0x7b/0xd30 PGD 0 Oops: [1] PREEMPT last sysfs file: /devices/pci:00/:00:0a.0/subsystem_vendor CPU 0 Modules linked in: ehci_hcd snd_page_alloc ip6t_REJECT xt_tcpudp i2c_nforce2 i2c_core ipt_REJECT xt_state ohci_hcd iptable_mangle iptable_n at ip_nat iptable_filter ip6table_mangle ip_conntrack ip_tables parport_pc lp ip6table_filter parport ip6_tables x_tables ipv6 dm_mod Pid: 110, comm: khubd Not tainted 2.6.18-rc1-mm2 #3 RIP: 0010:[8024a07b] [8024a07b] __lock_acquire+0x7b/0xd30 RSP: 0018:81005feb1c18 EFLAGS: 00010046 RAX: 0002 RBX: 0246 RCX: RDX: RSI: RDI: 0030 RBP: 81005feb1c88 R08: 0002 R09: R10: R11: 0001 R12: 8046e23f R13: R14: 81005fe92040 R15: 0030 FS: 2b0df5390b00() GS:808c() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0038 CR3: 5dc35000 CR4: 06e0 Process khubd (pid: 110, threadinfo 81005feb, task 81005fe92040) Stack: 81005fe92040 81005febe7a8 80470079 0002 80470038 0246 81005a701680 0246 8046e23f 0002 Call Trace: [8024b0bb] lock_acquire+0x8b/0xc0 [8047193f] _spin_lock+0x2f/0x40 [8046e23f] klist_remove+0x1f/0x50 [803b9817] bus_remove_device+0xa7/0xe0 [803b80f9] device_del+0x149/0x180 [803d2d95] usb_disconnect+0x105/0x150 [803d5cc6] hub_thread+0x616/0xfd0 [80243809] kthread+0xd9/0x110 [8020a316] child_rip+0x8/0x12 Code: 48 8b 5f 08 48 85 db 0f 85 48 03 00 00 8b 05 12 c0 63 00 85 RIP [8024a07b] __lock_acquire+0x7b/0xd30 RSP 81005feb1c18 CR2: 0038 6note: khubd[110] exited with preempt_count 1 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc1-mm2
On Friday 14 July 2006 20:36, Michal Piotrowski wrote: Hi Andrew, On 14/07/06, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 14 Jul 2006 13:36:08 +0200 Rafael J. Wysocki [EMAIL PROTECTED] wrote: Unable to handle kernel NULL pointer dereference at 0038 RIP: [8024a07b] __lock_acquire+0x7b/0xd30 PGD 0 Oops: [1] PREEMPT last sysfs file: /devices/pci:00/:00:0a.0/subsystem_vendor CPU 0 Modules linked in: ehci_hcd snd_page_alloc ip6t_REJECT xt_tcpudp i2c_nforce2 i2c_core ipt_REJECT xt_state ohci_hcd iptable_mangle iptable_n at ip_nat iptable_filter ip6table_mangle ip_conntrack ip_tables parport_pc lp ip6table_filter parport ip6_tables x_tables ipv6 dm_mod Pid: 110, comm: khubd Not tainted 2.6.18-rc1-mm2 #3 RIP: 0010:[8024a07b] [8024a07b] __lock_acquire+0x7b/0xd30 RSP: 0018:81005feb1c18 EFLAGS: 00010046 RAX: 0002 RBX: 0246 RCX: RDX: RSI: RDI: 0030 RBP: 81005feb1c88 R08: 0002 R09: R10: R11: 0001 R12: 8046e23f R13: R14: 81005fe92040 R15: 0030 FS: 2b0df5390b00() GS:808c() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0038 CR3: 5dc35000 CR4: 06e0 Process khubd (pid: 110, threadinfo 81005feb, task 81005fe92040) Stack: 81005fe92040 81005febe7a8 80470079 0002 80470038 0246 81005a701680 0246 8046e23f 0002 Call Trace: [8024b0bb] lock_acquire+0x8b/0xc0 [8047193f] _spin_lock+0x2f/0x40 [8046e23f] klist_remove+0x1f/0x50 [803b9817] bus_remove_device+0xa7/0xe0 [803b80f9] device_del+0x149/0x180 [803d2d95] usb_disconnect+0x105/0x150 [803d5cc6] hub_thread+0x616/0xfd0 [80243809] kthread+0xd9/0x110 [8020a316] child_rip+0x8/0x12 I seem to have made a programming mistake. Thanks! Problem solved. Confirmed. Thanks, Rafael - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] revert-gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
On Friday 02 June 2006 06:19, David Brownell wrote: On Thursday 01 June 2006 8:46 pm, Andrew Morton wrote: fyi, I continue to revert this patch from Greg's tree. Here's a somewhat better version, FYI. Still has some issues, but seemingly nothing quite as nasty as Rafael reported. Tested, works for me. :-) Thanks, Rafael ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Friday 26 May 2006 05:06, David Brownell wrote: On Tuesday 02 May 2006 9:12 am, Patrick Mochel wrote: On Thu, Apr 27, 2006 at 12:41:28PM -0700, David Brownell wrote: There does seem to be agreement that the current FREEZE invocation is not sufficient. I'm looking at a slightly different solution now ... one which unfortunately involves changing drivers, but can indeed allow swsusp resume paths to do the right thing (instead of what it does now). It's Ok if it involves a drive change, so long as its an optional change, which means that it shouldn't affect the interface very much (i.e. the calling convention). That's why it'd be good to augment and/or modify pm_message_t to implement the changes, so we wouldn't have to change every single driver again.. I'll post more patches after I sort out some oddness -- why is swsusp_suspend() leaving preempt_count() == 1, code I was nowhere near? -- but the patch appended here shows what I'm pursuing. Same calling convention, new PRETHAW message that pm-naive drivers (most of them!) can handle just like FREEZE. Frankly I thought you'd add a new member to pm_message_t, to be ignored by the drivers that didn't care. That said I also see the point in what you're doing. :-) Greetings, Rafael --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.17-rc4-mm2 (hard lockup after resume from disk on AMD64)
On Thursday 25 May 2006 22:29, Alan Stern wrote:
On Sun, 21 May 2006, Rafael J. Wysocki wrote:
On Saturday 20 May 2006 23:30, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday 20 May 2006 14:41, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm2/
My box (Asus L5D, x86_64 kernel) locks up hard after the resume from
suspend
to disk. This happens right after the console has been restored and
only if
all modules are loaded before suspend (eg. it doesn't lock up when
booted with
init=/bin/bash). Also it's caught by the softlockup watchdog which
produces
traces similar to the appended one.
Greetings,
Rafael
BUG: soft lockup detected on CPU#0!
Call Trace: IRQ 8025b2f1{softlockup_tick+193}
802360a3{run_local_timers+19}
802362c7{update_process_times+87}
8020e174{main_timer_handler+548}
8020e3c5{timer_interrupt+21}
8025b4e3{handle_IRQ_event+51}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65}
80209d5e{ret_from_intr+0}
803cb8d0{urb_destroy+0}
803ca84a{usb_hcd_poll_rh_status+250}
880dafa2{:ohci_hcd:ohci_irq+194}
803c9ce2{usb_hcd_irq+50}
8025b4e3{handle_IRQ_event+51}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65}
80209d5e{ret_from_intr+0}
8025b4d4{handle_IRQ_event+36}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65}
80209d5e{ret_from_intr+0}
8025b4d4{handle_IRQ_event+36}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65}
80209d5e{ret_from_intr+0} EOI
803cb8d0{urb_destroy+0}
803cb788{hcd_submit_urb+2072}
80463d4d{_spin_unlock_irqrestore+29}
803cb9a5{usb_free_urb+21}
803ca0ab{usb_hcd_giveback_urb+315}
80463d4d{_spin_unlock_irqrestore+29}
803cbd2b{usb_submit_urb+859}
803cc66a{usb_start_wait_urb+122}
8027c58d{dbg_redzone1+29}
8027d804{cache_alloc_debugcheck_after+532}
8027c58d{dbg_redzone1+29}
803cca40{usb_control_msg+240}
803c5e74{set_port_feature+68}
803c61f9{hub_port_reset+57}
803c64d1{hub_port_init+129}
803c8b31{hub_thread+2241}
80242140{autoremove_wake_function+0}
803c8270{hub_thread+0}
80241f29{kthread+217}
80463d84{_spin_unlock_irq+20}
80228d99{schedule_tail+73}
8020a38a{child_rip+8}
80241e50{kthread+0} 8020a382{child_rip+0}
BUG: soft lockup detected on CPU#0!
What a revolting backtrace. There were some x86_64 precise-backtrace
patches floating around on the list this week.
They seem to reappear and get squashed by Andi on a regular basis. ;-)
Still, it would appear that USB has become confused. If you have the time
to do a bisection search, I'd start in on gregkh-usb-*.patch.
Obviously it's this one:
gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
[Well, looks like it hasn't been tested properly before posting ... :-(]
Did this ever get settled?
The patch has been dropped by Andrew.
Although I'm not familiar with the details of the driver, this doesn't seem
like the sort of thing that should cause any problems with suspend/resume.
Still it does (100% reproducible). I think Dave knows the reason why. ;-)
Greetings,
Rafael
---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.17-rc4-mm2 (hard lockup after resume from disk on AMD64)
On Saturday 20 May 2006 23:30, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Saturday 20 May 2006 14:41, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm2/
My box (Asus L5D, x86_64 kernel) locks up hard after the resume from
suspend
to disk. This happens right after the console has been restored and only
if
all modules are loaded before suspend (eg. it doesn't lock up when booted
with
init=/bin/bash). Also it's caught by the softlockup watchdog which
produces
traces similar to the appended one.
Greetings,
Rafael
BUG: soft lockup detected on CPU#0!
Call Trace: IRQ 8025b2f1{softlockup_tick+193}
802360a3{run_local_timers+19}
802362c7{update_process_times+87}
8020e174{main_timer_handler+548}
8020e3c5{timer_interrupt+21}
8025b4e3{handle_IRQ_event+51}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65} 80209d5e{ret_from_intr+0}
803cb8d0{urb_destroy+0}
803ca84a{usb_hcd_poll_rh_status+250}
880dafa2{:ohci_hcd:ohci_irq+194}
803c9ce2{usb_hcd_irq+50}
8025b4e3{handle_IRQ_event+51}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65} 80209d5e{ret_from_intr+0}
8025b4d4{handle_IRQ_event+36}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65} 80209d5e{ret_from_intr+0}
8025b4d4{handle_IRQ_event+36}
8025b5d2{__do_IRQ+162}
8020c3b1{do_IRQ+65} 80209d5e{ret_from_intr+0}
EOI
803cb8d0{urb_destroy+0}
803cb788{hcd_submit_urb+2072}
80463d4d{_spin_unlock_irqrestore+29}
803cb9a5{usb_free_urb+21}
803ca0ab{usb_hcd_giveback_urb+315}
80463d4d{_spin_unlock_irqrestore+29}
803cbd2b{usb_submit_urb+859}
803cc66a{usb_start_wait_urb+122}
8027c58d{dbg_redzone1+29}
8027d804{cache_alloc_debugcheck_after+532}
8027c58d{dbg_redzone1+29}
803cca40{usb_control_msg+240}
803c5e74{set_port_feature+68}
803c61f9{hub_port_reset+57}
803c64d1{hub_port_init+129}
803c8b31{hub_thread+2241}
80242140{autoremove_wake_function+0}
803c8270{hub_thread+0}
80241f29{kthread+217}
80463d84{_spin_unlock_irq+20}
80228d99{schedule_tail+73} 8020a38a{child_rip+8}
80241e50{kthread+0} 8020a382{child_rip+0}
BUG: soft lockup detected on CPU#0!
What a revolting backtrace. There were some x86_64 precise-backtrace
patches floating around on the list this week.
They seem to reappear and get squashed by Andi on a regular basis. ;-)
Still, it would appear that USB has become confused. If you have the time
to do a bisection search, I'd start in on gregkh-usb-*.patch.
Obviously it's this one:
gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
[Well, looks like it hasn't been tested properly before posting ... :-(]
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Wednesday 26 April 2006 00:56, David Brownell wrote: On Tuesday 25 April 2006 2:55 pm, Rafael J. Wysocki wrote: On Tuesday 25 April 2006 23:04, David Brownell wrote: The third state is the problem scenario, kicking in when the driver was statically linked (or modprobed from initramfs, etc), but not during your scenario. The problem, as I see it, is that too many devices may be initialized at the kernel startup. That's a fair observation. In the same way, swsusp resumes too many devices before writing the snapshot. In both cases, it only needs the resume partition, not every random bit of hardware in the system. That's right, and I think we should make it resume only what's needed at some point in the future. But it's not the root cause of the problem either. The same problem appears if the device holding the resume partition gets forced into this broken suspend state. Well, IMO the state may or may not be broken depending on the device, so we should not assume it will always be broken. I think we _can_ reset some of them before the image is restored, but at least some of them need to be treated more carefully. Maybe; but remember they _were_ just reset ... and that if a driver doesn't know how to re-init a device that it has just reset, then it has other problems! It's a common practice to reset on entrance to probe() ... if that works, it's just a simple matter of code cleanup/reorg to let the init code be used if resume() detects the device hardware has been reset. Agreed. For example, rmmod/modprobe cycles wouldn't behave sanely ... and it'd likely break with kexec(). If they need careful treatment, that'd seem to me most like a driver bug ... Now, if you have specific examples of things that shouldn't be reset, that could be interesting. The resume device and friends (ie. controller, bus, etc.). I don't seem to have tripped over any, and from first principles it's clear to me there _shouldn't_ be such drivers (modulo bugs). If you're going to argue that there are enough buggy drivers around that we can't rely on them to behave correctly here ... well, we don't have an example of even one such driver, much less a flood of them. And the thing to do with bugs is fix them, not coddle them. ;) Agreed. Right: the first two safe cases kick in. This is the partial workaround I had identified: dodging the code paths for that third state, where suspend() is being used to put the hardware into a broken suspend state. So perhaps we should just make them enter a state that's not broken? That may be reset for some devices (eg. USB) and something else for some others (eg. storage). Sure, but I'm not sure what something else would ever be. Examples? Not of cases where something else _could_ be done, but where it _must_ be. My point is that it need not be _necessary_ to reset all devices. We should reset only those which need to be reset. It may help to think of two distinct types of device hardware suspend states (only the first is real, the second is just a software bug): - Correct, with internal state corresponding to what the driver suspend() did; what a normal hardware suspend/resume cycle (not powercycle!) could do. - Broken, with any other internal state (except reset). This is what swsusp currently forces, by adding **AND HIDING** a reset and reinit cycle, because of the extra suspend() call in (7). Still there are drivers that have no problems with it, so why we should we forcibly reset their devices? Can any driver can really justify not handling the case where resume() sees hardware that's been reset? That is, _exactly_ as would be the case if its driver were only loaded as a module after the kernel booted? I think not... Of course every driver should handle this but that's not the point. The point is whether we should _force_ the reset on every device. My patch/suggestion just ensures that instead of that broken state, reset is used. in all cases ... not just the driver not initialized before snapshot resume case. As I said before I generally agree with this except I think some more fine grained approach is needed in this case. You've not convinced me of that; might be right, but nothing proves it to me. Fair enough. :-) Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Wednesday 26 April 2006 16:38, Alan Stern wrote: On Wed, 26 Apr 2006, Rafael J. Wysocki wrote: Now, if you have specific examples of things that shouldn't be reset, that could be interesting. The resume device and friends (ie. controller, bus, etc.). I presume the freeze/reset we're talking about occurs immediately after the memory snapshot has been read from the swap partition and immediately before it is installed/activated. (If occurs before the snapshot is read in, then how would you actually manage to read it?) So under these circumstances, how does it hurt anything to reset the resume device rather than to freeze it? It just shouldn't be necessary. Actually I think the resume device shouldn't be frozen too. My point is that it need not be _necessary_ to reset all devices. We should reset only those which need to be reset. Of course every driver should handle this but that's not the point. The point is whether we should _force_ the reset on every device. I'm not convinced that it hurts anything. But in any case, it wouldn't hurt to follow Pavel's advice and add a flags field to pm_message_t. Exactly. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Wednesday 26 April 2006 17:38, Alan Stern wrote: On Wed, 26 Apr 2006, Rafael J. Wysocki wrote: So under these circumstances, how does it hurt anything to reset the resume device rather than to freeze it? It just shouldn't be necessary. Actually I think the resume device shouldn't be frozen too. Well, you wouldn't want it doing DMA to unknown memory areas while you're trying to place the image data in those same areas, would you? And when the image is reactivated, you wouldn't want the device generating interrupt requests while its driver still thinks it is suspended. (Or if it doesn't even have a driver in the image.) I think it'll always have a driver in the image, because we use it on suspend to save the image. Also IMHO, theoretically, the driver need not think the device is suspended. And don't say that no resume device would ever do DMA or generate IRQs while it was idle! What if it was a remote disk accessible via a network interface? I think at least some devices may be told not to do DMA and/or generate IRQs without being reset or put into a low(er) power state. Ayway, as of today, we have no infrastructure allowing us to handle resume devices in a special way. However, if we decide to reset all devices before restoring the image, we'll probably make such things harder to implement in the future. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Wednesday 26 April 2006 21:06, Alan Stern wrote: On Wed, 26 Apr 2006, Rafael J. Wysocki wrote: It just shouldn't be necessary. Actually I think the resume device shouldn't be frozen too. Well, you wouldn't want it doing DMA to unknown memory areas while you're trying to place the image data in those same areas, would you? And when the image is reactivated, you wouldn't want the device generating interrupt requests while its driver still thinks it is suspended. (Or if it doesn't even have a driver in the image.) I think it'll always have a driver in the image, because we use it on suspend to save the image. True. Also IMHO, theoretically, the driver need not think the device is suspended. It does have to think the device is frozen, however. The device _has_ to be frozen while the memory image is created, for the same reasons as mentioned before: it mustn't do DMA or generate IRQs. I think at least some devices may be told not to do DMA and/or generate IRQs without being reset or put into a low(er) power state. That is in fact the very definition of FREEZE. From Documentation/power/devices.txt: FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from scratch. Agreed, general devices do not need to be reset or put into a lower power state when they enter FREEZE. Ah, my bad. I wasn't referring to this definition, sorry for the confusion. Ayway, as of today, we have no infrastructure allowing us to handle resume devices in a special way. However, if we decide to reset all devices before restoring the image, we'll probably make such things harder to implement in the future. Given the definition above, if a driver that has problems resuming from a FREEZE when the device has been reset then the driver is wrong. Agreed. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Wednesday 26 April 2006 23:31, David Brownell wrote: On Wednesday 26 April 2006 4:26 am, Rafael J. Wysocki wrote: On Wednesday 26 April 2006 00:56, David Brownell wrote: But it's not the root cause of the problem either. The same problem appears if the device holding the resume partition gets forced into this broken suspend state. Well, IMO the state may or may not be broken depending on the device, so we should not assume it will always be broken. Not so. See my previous emails. The broken suspend state is broken by definition. Maybe you're referring to a different issue ... whether or not its driver would notice that bug. It is a bug from your point of view, and I was referring to the fact that it apparently doesn't matter for many drivers. Now, if you have specific examples of things that shouldn't be reset, that could be interesting. The resume device and friends (ie. controller, bus, etc.). Bad answer. If its driver would notice, then it must be reset. And if the driver wouldn't notice, resetting won't matter. There's still no example of a device that should not be reset (a second time). OK, so I have no any. Which doesn't seem to matter as far as your patch is concerned, as Pavel doesn't like it anyway. ;-) Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Tuesday 25 April 2006 00:31, Nigel Cunningham wrote: On Tuesday 25 April 2006 07:29, David Brownell wrote: I've noticed a bunch of problem reports that go like this: - boot system with some USB devices attached - echo disk /sys/power/state - ... later resume ... - now those USB devices don't work right - unplug them/replug them, all is OK I recently observed this myself and tracked down one problem. The solution involves what kexec() does in much the same situation: before starting a new kernel, most hardware needs to be reset. Today, swsusp will suspend it instead, which is the root cause of the problem. I'm not sure that it is. If we switched to not freezing devices, we'd then cause issues with hardware such as hard drives. They need to know that we just want things quiesced, mainly because we don't want to spin down drives. That's right. And kernel_restart_prepare(NULL) will make them spin down? If so, they have to be treated in a special way. OTOH I think at least some device driver writers assume that .resume() will always be called after .suspend() which only is true for non-modular drivers (or for modular drivers loaded from an initrd before resume). The David's change makes this assumptions explicitly invalid and that's why I said I agreed with it. However you're absolutely right about hard disks. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Tuesday 25 April 2006 18:11, David Brownell wrote: On Tuesday 25 April 2006 1:32 am, Rafael J. Wysocki wrote: just want things quiesced, mainly because we don't want to spin down drives. That's right. And kernel_restart_prepare(NULL) will make them spin down? If so, they have to be treated in a special way. Seems every time that someone turns up one of the problems with this freeze thing, the same responses come back: we can't fix that because we don't want to spin down drives. I didn't say we couldn't fix that, did I? I've begun thinking that calls like pm_should_I_spin_down_drives() would be a better structural approach than continually redefining this freeze thing so it makes less and less sense to all other drivers ... who nonethless need to clutter themselves up with a growing list of special cases, to accomodate rotating media that may not even exist in the target system. I think we should do something different to device_power_down(PMSG_FREEZE) there, but I'm not sure it should be kernel_restart_prepare(NULL). Actually spinning down disks during resume is a problem for some users (yes, we've had such bug reports recently), so it's better to avoid this. OTOH I think at least some device driver writers assume that .resume() will always be called after .suspend() which only is true for non-modular drivers (or for modular drivers loaded from an initrd before resume). Say what? Of _course_ resume() should only be called after suspend(). If that's not true in any case, the code wrongly issuing the resume() is buggy. Well, suppose we have a modular driver that's not loaded before resume. Then it goes like that (approximately): (1) We activate swsusp which calls .suspend() for all devices including our driver (this is a real suspend). (2) swsusp snapshots the system and creates the image. (3) swsusp calls .resume() for all devices in order to be able to save the image (.resume() for our driver is also called which is OK). (4) swsusp turns off the system. (5) (some time later) We start a new kernel and tell it to resume. (6) It activates swsusp which reads the image. (7) (without your change) swsusp calls .suspend() for all device drivers that are present at that time, but our driver is not there, so its .suspend() _won't_ be called. [Of course with your change .suspend() won't be called for any driver.] (8) swsusp restores the image. (9) swsusp calls .resume() for all devices _including_ our driver, because it was in memory before suspend. For our driver this .resume() is not called after .suspend(), is it? You're saying that (9) is wrong, so could you please suggest what to do instead of it? I don't see where you're collecting that list of special cases. I have no such list ... It doesn't match what I've observed ... and even if it were correct, I'd say that's yet another case where special casing reflects bugs. ... and I'm against special casing as far as it's avoidable. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote: On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote: You're saying that (9) is wrong, so could you please suggest what to do instead of it? 'scuse me for butting in, but here's my suggested modified version: Well, suppose we have a modular driver that's not loaded before resume. Then it goes like that (approximately): (1) We activate swsusp which calls .suspend() for all devices including our driver (this is a real suspend). (2) swsusp snapshots the system and creates the image. (3) swsusp calls .resume() for all devices in order to be able to save the image (.resume() for our driver is also called which is OK). (4) swsusp turns off the system. (5) (some time later) We start a new kernel and tell it to resume. (6) It activates swsusp which reads the image. (7) (without your change) swsusp calls .suspend() for all device drivers that are present at that time, but our driver is not there, so its .suspend() _won't_ be called. [Of course with your change .suspend() won't be called for any driver.] We also make a list that is safely available after the atomic restore of drivers that have had .suspend methods called. Do you mean we place the list in a __nosave area? Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
On Tuesday 25 April 2006 23:04, David Brownell wrote: On Tuesday 25 April 2006 11:56 am, Rafael J. Wysocki wrote: I've begun thinking that calls like pm_should_I_spin_down_drives() would be a better structural approach than continually redefining this freeze thing so it makes less and less sense to all other drivers ... who nonethless need to clutter themselves up with a growing list of special cases, to accomodate rotating media that may not even exist in the target system. I think we should do something different to device_power_down(PMSG_FREEZE) there, but I'm not sure it should be kernel_restart_prepare(NULL). Actually spinning down disks during resume is a problem for some users (yes, we've had such bug reports recently), so it's better to avoid this. Well, if we had a pm_should_I_spin_down_drives() it would make sense to me that it return FALSE during kernel_restart_prepare() too ... surely kexec users have the same issues! If you currently have users who object to spindown-during-resume, then it'd seem that my patch couldn't change anything except maybe details. Fortunately this particular problem has been fixed in the driver. ;-) And that switching over to a call like pm_should_I_spin_down_drives() should fix it all. Agreed, but I have to learn quite a bit to implement such a thing. OTOH I think at least some device driver writers assume that .resume() will always be called after .suspend() which only is true for non-modular drivers (or for modular drivers loaded from an initrd before resume). Say what? Of _course_ resume() should only be called after suspend(). If that's not true in any case, the code wrongly issuing the resume() is buggy. Well, suppose we have a modular driver that's not loaded before resume. That's not the problem case though; it works correctly, since the device hardware is already being left in an appropriate (RESET) state. Then it goes like that (approximately): (1) We activate swsusp which calls .suspend() for all devices including our driver (this is a real suspend). (2) swsusp snapshots the system and creates the image. (3) swsusp calls .resume() for all devices in order to be able to save the image (.resume() for our driver is also called which is OK). (4) swsusp turns off the system. (5) (some time later) We start a new kernel and tell it to resume. (6) It activates swsusp which reads the image. And assuming this is an x86 PC, at this point every device is in one of three states: - initialized by BIOS. This is a particular PITA for USB, but one that's handled OK (mostly) except when BIOS bugs kick in. There's some nasty code that kicks in along with PCI quirk handling, which ensures that by the time Linux-USB driver could see this state (or the input subsystem needs to care about it), the state has morphed to reset. Video cards have funky issues here too. - (powerup) reset. This is the ideal state, in terms of truth to convey to the image we're about to restore ... no ambiguity, every driver will need to re-init. As if there were (thank you!!) no BIOS. - initialized by Linux ... which leads to the case my patch addresses. Those first two states are legit for any resume() call, and they apply in your scenario restriction. IIRC, there were some ALSA problems with .resume() called on a reseted device, but they seem to be fixed now. The third state is the problem scenario, kicking in when the driver was statically linked (or modprobed from initramfs, etc), but not during your scenario. The problem, as I see it, is that too many devices may be initialized at the kernel startup. I think we _can_ reset some of them before the image is restored, but at least some of them need to be treated more carefully. (7) (without your change) swsusp calls .suspend() for all device drivers that are present at that time, ... the current troublesome consequence of that third state ... but our driver is not there, so its .suspend() _won't_ be called. [Of course with your change .suspend() won't be called for any driver.] Right: the first two safe cases kick in. This is the partial workaround I had identified: dodging the code paths for that third state, where suspend() is being used to put the hardware into a broken suspend state. So perhaps we should just make them enter a state that's not broken? That may be reset for some devices (eg. USB) and something else for some others (eg. storage). Note that with that third state, there are actually two suspend() calls, but only one resume() call. (Suspend before snapshot, suspend before resume snapshot, resume after activating snapshot.) Such an extra suspend() call is a small hint that something's odd, and maybe wrong. Agreed. (8) swsusp restores the image. (9) swsusp calls .resume() for all devices
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Tuesday 25 April 2006 23:03, Nigel Cunningham wrote: On Wednesday 26 April 2006 06:53, Rafael J. Wysocki wrote: On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote: On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote: You're saying that (9) is wrong, so could you please suggest what to do instead of it? 'scuse me for butting in, but here's my suggested modified version: Well, suppose we have a modular driver that's not loaded before resume. Then it goes like that (approximately): (1) We activate swsusp which calls .suspend() for all devices including our driver (this is a real suspend). (2) swsusp snapshots the system and creates the image. (3) swsusp calls .resume() for all devices in order to be able to save the image (.resume() for our driver is also called which is OK). (4) swsusp turns off the system. (5) (some time later) We start a new kernel and tell it to resume. (6) It activates swsusp which reads the image. (7) (without your change) swsusp calls .suspend() for all device drivers that are present at that time, but our driver is not there, so its .suspend() _won't_ be called. [Of course with your change .suspend() won't be called for any driver.] We also make a list that is safely available after the atomic restore of drivers that have had .suspend methods called. Do you mean we place the list in a __nosave area? Well, I wasn't wanting to get bogged down in the details yet, but let's see what we can come up with. How about this: At the point where we do the drivers resume at resume time, we're still atomic, right? Since that's the case, we can just use get_safe_page() prior to the restore to store the list and a __nosave pointer to retain the location across the atomic restore. If we are concerned about resuming drivers allocating memory and overwriting our list (and I think that's a valid concern), space could be allocated and the list copied between doing the atomic restore and the device pwoerup/resume. This one seems to look better. Still the problem is we need to know what to do with the devices that have had .suspend() routines called. Some of them would have to be reset, some of them might be left in the current state, and for some of them we'd have to do something special. Frankly, only the driver writer will know what's appropriate. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Wednesday 26 April 2006 00:18, Nigel Cunningham wrote: On Wednesday 26 April 2006 08:06, Rafael J. Wysocki wrote: On Tuesday 25 April 2006 23:03, Nigel Cunningham wrote: On Wednesday 26 April 2006 06:53, Rafael J. Wysocki wrote: On Tuesday 25 April 2006 22:28, Nigel Cunningham wrote: On Wednesday 26 April 2006 04:56, Rafael J. Wysocki wrote: You're saying that (9) is wrong, so could you please suggest what to do instead of it? 'scuse me for butting in, but here's my suggested modified version: Well, suppose we have a modular driver that's not loaded before resume. Then it goes like that (approximately): (1) We activate swsusp which calls .suspend() for all devices including our driver (this is a real suspend). (2) swsusp snapshots the system and creates the image. (3) swsusp calls .resume() for all devices in order to be able to save the image (.resume() for our driver is also called which is OK). (4) swsusp turns off the system. (5) (some time later) We start a new kernel and tell it to resume. (6) It activates swsusp which reads the image. (7) (without your change) swsusp calls .suspend() for all device drivers that are present at that time, but our driver is not there, so its .suspend() _won't_ be called. [Of course with your change .suspend() won't be called for any driver.] We also make a list that is safely available after the atomic restore of drivers that have had .suspend methods called. Do you mean we place the list in a __nosave area? Well, I wasn't wanting to get bogged down in the details yet, but let's see what we can come up with. How about this: At the point where we do the drivers resume at resume time, we're still atomic, right? Since that's the case, we can just use get_safe_page() prior to the restore to store the list and a __nosave pointer to retain the location across the atomic restore. If we are concerned about resuming drivers allocating memory and overwriting our list (and I think that's a valid concern), space could be allocated and the list copied between doing the atomic restore and the device pwoerup/resume. This one seems to look better. Still the problem is we need to know what to do with the devices that have had .suspend() routines called. Some of them would have to be reset, some of them might be left in the current state, and for some of them we'd have to do something special. Frankly, only the driver writer will know what's appropriate. I saw the 2 suspends, 1 resume comment in another part of the thread, but don't believe a driver would be able to detect that 2 suspends and 1 resume call had been made - at least not without some non volatile ram. In fact we know when the second .suspend() is going to be called from the driver, so we can tell it to take care, for example by passing a special value to .suspend(). If that value is passed to .suspend(), the driver should prepare the device for .resume() being called after the snapshot image is restored (eg. reset it). Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()
Hi, On Monday 24 April 2006 23:29, David Brownell wrote: I've noticed a bunch of problem reports that go like this: - boot system with some USB devices attached - echo disk /sys/power/state - ... later resume ... - now those USB devices don't work right - unplug them/replug them, all is OK I recently observed this myself and tracked down one problem. The solution involves what kexec() does in much the same situation: before starting a new kernel, most hardware needs to be reset. Today, swsusp will suspend it instead, which is the root cause of the problem. This seems like something that might need to sit in the MM tree for a while, as it's a longstanding bug and the fix could shake loose driver goofs. Luckily there's a partial workaround already in wide use: link drivers as modules if they use true suspend states (like all USB HCDs), don't link them statically into the kernel image. That workaround is partial because when BIOS takes over a controller, the resume() method has to handle that nasty case too! Last I checked, all the USB HCDs do handle that case; and few drivers other than those HCDs would ever need to worry about such issues. I agree with this change but I think it'll cause some strange things to happen for some time. Greetings, Rafael --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Linux 2.6.16-rc3
On Monday 13 February 2006 13:02, Takashi Iwai wrote: At Sun, 12 Feb 2006 19:05:20 -0800, Andrew Morton wrote: - Patrizio Bassi [EMAIL PROTECTED] has an alsa suspend regression (alsa suspend/resume continues to fail for ens1370) It's not a regression. PM didn't work with ens1370 at all in the eralier version. About the problem there, I have no idea now what's wrong. The suspend-to-disk works fine if the driver is built as module but not as built-in kernel. That may be related to the fact that modular drivers are not present in memory during resume (just a thought). Greetings, Rafael --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Linux 2.6.16-rc3
On Monday 13 February 2006 14:51, Takashi Iwai wrote: At Mon, 13 Feb 2006 14:09:51 +0100, Rafael J. Wysocki wrote: On Monday 13 February 2006 13:02, Takashi Iwai wrote: At Sun, 12 Feb 2006 19:05:20 -0800, Andrew Morton wrote: - Patrizio Bassi [EMAIL PROTECTED] has an alsa suspend regression (alsa suspend/resume continues to fail for ens1370) It's not a regression. PM didn't work with ens1370 at all in the eralier version. About the problem there, I have no idea now what's wrong. The suspend-to-disk works fine if the driver is built as module but not as built-in kernel. That may be related to the fact that modular drivers are not present in memory during resume (just a thought). I think the modular drivers are on memory but the order of re-initialization is different. No, they are not (this is the part I'm sure of). software_resume() is called before any modules have a chance to be loaded unless you boot with noresume, load them from an initrd and start the resume manually. Greetings, Rafael --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
On Tuesday, 13 December 2005 07:52, David Brownell wrote:
if ((status STS_PCD) device_may_wakeup(hcd-self.root_hub-dev)) {
What happens if you make that line read
if ((status STS_PCD) != 0) {
and ignore the root hub thing?
So far, so good. It works and hasn't triggered the oops yet. I'll report if
there's
anything wrong with it.
Greetings,
Rafael
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
On Tuesday, 13 December 2005 23:22, David Brownell wrote:
On Tuesday 13 December 2005 2:10 pm, Rafael J. Wysocki wrote:
On Tuesday, 13 December 2005 07:52, David Brownell wrote:
if ((status STS_PCD)
device_may_wakeup(hcd-self.root_hub-dev)) {
What happens if you make that line read
if ((status STS_PCD) != 0) {
and ignore the root hub thing?
So far, so good. It works and hasn't triggered the oops yet. I'll report
if there's
anything wrong with it.
I suspect that should be safe to merge for 2.6.15, and it might be
worth considering that. You were using kexec() right?
No, I was not. Why would that be important?
Rafael
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
On Sunday, 11 December 2005 21:38, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI Host Controller
ehci_hcd :00:02.2: debug port 1
ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3
ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00
usb 2-2: Product: USB Receiver
usb 2-2: Manufacturer: Logitech
usb 2-2: configuration #1 chosen from 1 choice
ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Unable to handle kernel NULL pointer dereference at 02a4 RIP:
880ad9d0{:ehci_hcd:ehci_irq+224}
Can you poke around in gdb, see which line it's dying at?
It looks like at the line 620. At least here's what gdb told me:
Line 620 of ehci-hcd.c starts at address 0x69c3 ehci_irq+211
and ends at 0x69e2 ehci_irq+242.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
On Monday, 12 December 2005 21:29, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Sunday, 11 December 2005 21:38, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI Host Controller
ehci_hcd :00:02.2: debug port 1
ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3
ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00
usb 2-2: Product: USB Receiver
usb 2-2: Manufacturer: Logitech
usb 2-2: configuration #1 chosen from 1 choice
ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Unable to handle kernel NULL pointer dereference at 02a4
RIP:
880ad9d0{:ehci_hcd:ehci_irq+224}
Can you poke around in gdb, see which line it's dying at?
It looks like at the line 620. At least here's what gdb told me:
Line 620 of ehci-hcd.c starts at address 0x69c3 ehci_irq+211
and ends at 0x69e2 ehci_irq+242.
On my tree that's
if ((status STS_PCD) device_may_wakeup(hcd-self.root_hub-dev)) {
Yes, that's it.
It's best to actually send a copy of line 620 - kernels vary a lot, and
many developers won't have that particualr -mm tree handy.
The way I normally do this is to do `gdb vmlinux' and then `l
*0x880ad9d0'.
Does it work for modules too?
If that lands you in some inline function then poke
around, displacing the EIP by +/- amounts until it lands outside the
inlined function so you can see the callsite.
Anyway. Greg's tree seems rather buggy lately..
Well ...
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
On Monday, 12 December 2005 22:09, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
It's best to actually send a copy of line 620 - kernels vary a lot, and
many developers won't have that particualr -mm tree handy.
The way I normally do this is to do `gdb vmlinux' and then `l
*0x880ad9d0'.
Does it work for modules too?
Ah. There are certainly ways of doing this - see the kgdb documentation.
Or you can work out the module load address, gdb the module and do the
appropriate arithmetic I guess.
Generally I just statically link anything which I want to play with.
Still, the oops is from a module. I could link it statically for debugging,
but then the address would be different to the one in the oops.
Anyway, please tell me if my reasoning was correct: I thought I couldn't
figure it out based on the absolute address, but I could use the
displacements. Namely, it followed from the oops that the problem
occured at the address {:ehci_hcd:ehci_irq+224}, which is at the
offset 224 wrt ehci_irq, so I did:
gdb drivers/usb/host/ehci-hcd.o
In gdb I did:
info line ehci_irq
and it told me the address the line started at, so I added 224 to it and
got the line 620.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.15-rc5-mm2: ehci_hcd crashes on load sometimes
The ehci_hcd driver causes problems like this:
ehci_hcd :00:02.2: EHCI Host Controller
ehci_hcd :00:02.2: debug port 1
ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3
ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00
usb 2-2: Product: USB Receiver
usb 2-2: Manufacturer: Logitech
usb 2-2: configuration #1 chosen from 1 choice
ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Unable to handle kernel NULL pointer dereference at 02a4 RIP:
880ad9d0{:ehci_hcd:ehci_irq+224}
PGD 2dba6067 PUD 2d477067 PMD 0
Oops: [1] PREEMPT
CPU 0
Modules linked in: ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom
dm_mod parport_pc lp parport
Pid: 1336, comm: modprobe Not tainted 2.6.15-rc5-mm2 #2
RIP: 0010:[880ad9d0] 880ad9d0{:ehci_hcd:ehci_irq+224}
RSP: 0018:80481e08 EFLAGS: 00010202
RAX: RBX: 0004 RCX:
RDX: c207ac20 RSI: RDI: 81002c5d3c78
RBP: 80481ee8 R08: 0001 R09:
R10: R11: 0246 R12: 81002c5d3c78
R13: 81002c5d3c58 R14: 81002c5d3b08 R15:
FS: 2ade8b00() GS:8050f000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02a4 CR3: 2cc54000 CR4: 06e0
Process modprobe (pid: 1336, threadinfo 81002dac6000, task 81002fdf2790)
Stack: 80481e38 81002dac7b88 801819e0 810001c365c0
81002fdf32f0 81002fdf3000 80481e78 8017b5f5
80481e58 810001c365c0
Call Trace: IRQ 801819e0{filp_dtor+0}
8017b5f5{cache_free_debugcheck+597}
80181516{file_free_rcu+22} 802dbe04{usb_hcd_irq+52}
8015b563{handle_IRQ_event+51} 8015b652{__do_IRQ+162}
801114b7{do_IRQ+55} 8010f0b0{ret_from_intr+0}
EOI 801c1a01{sysfs_add_file+1}
801c1aad{sysfs_create_file+61}
802bfd47{class_device_create_file+23}
880ae0c9{:ehci_hcd:ehci_run+377}
802d6a86{usb_alloc_dev+262}
802dd4df{usb_add_hcd+1007}
802e6f53{usb_hcd_pci_probe+691}
802584da{pci_device_probe+106}
802bed79{driver_probe_device+89}
802bedf0{__driver_attach+0}
802bee51{__driver_attach+97}
802be68f{bus_for_each_dev+79}
802bec0c{driver_attach+28}
802be058{bus_add_driver+136}
802beff9{driver_register+121}
8025878e{__pci_register_driver+206}
88011050{:ehci_hcd:ehci_hcd_pci_init+80}
80150a1d{sys_init_module+253}
8010eb0e{system_call+126}
Code: 0f b6 80 a4 02 00 00 83 e0 03 3c 03 0f 85 9e 00 00 00 45 8b
RIP 880ad9d0{:ehci_hcd:ehci_irq+224} RSP 80481e08
CR2: 02a4
0Kernel panic - not syncing: Aiee, killing interrupt handler!
to appear from time to time when it's being loaded (20% of times or so).
If it loads successfully, it seems to work fine.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)
Hi, On Tuesday, 18 of October 2005 03:01, Alan Stern wrote: On Mon, 17 Oct 2005, Rafael J. Wysocki wrote: On Monday, 17 of October 2005 20:54, Alan Stern wrote: On Mon, 17 Oct 2005, Pavel Machek wrote: Hi! In -mm, usb breaks suspend to disk. Compiled without CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it actually tries to suspend USB, but it fails and machine refuses to suspend. Is it known or is it worth debugging? More details please. Fails for me too on x86-64, with the following messages: Stopping tasks: | Freeing memory... done (14642 pages freed) Suspending device card0-0 Suspending device 2-2:1.0 Suspending device 2-2 Suspending device 3-0:1.0 hub 3-0:1.0: no suspend? Suspending device usb3 Could not suspend device usb3: error -16 Some devices failed to suspend Restarting tasks... done where the USB-related info returned by the kernel is this: ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 11 ACPI: PCI Interrupt :00:02.0[A] - Link [LUS0] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :00:02.0 to 64 ohci_hcd :00:02.0: OHCI Host Controller ohci_hcd :00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:02.0: irq 11, io mem 0xfebfb000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 11 ACPI: PCI Interrupt :00:02.1[B] - Link [LUS1] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :00:02.1 to 64 ohci_hcd :00:02.1: OHCI Host Controller ohci_hcd :00:02.1: new USB bus registered, assigned bus number 2 ohci_hcd :00:02.1: irq 11, io mem 0xfebfc000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 5 usb 2-2: new low speed USB device using ohci_hcd and address 2 PCI: setting IRQ 5 as level-triggered ACPI: PCI Interrupt :00:02.2[C] - Link [LUS2] - GSI 5 (level, low) - IRQ 5 PCI: Setting latency timer of device :00:02.2 to 64 ehci_hcd :00:02.2: EHCI Host Controller ehci_hcd :00:02.2: debug port 1 ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3 ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00 PCI: cache line size of 64 is not supported by device :00:02.2 ehci_hcd :00:02.2: park 0 ehci_hcd :00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 usb 2-2: device descriptor read/all, error -110 hub 3-0:1.0: USB hub found hub 3-0:1.0: 6 ports detected ohci_hcd :00:02.1: wakeup usb 2-2: new low speed USB device using ohci_hcd and address 4 usbcore: registered new driver hiddev input: Logitech USB Receiver//class/input_dev as input3 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:02.1-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver Greetings, Rafael Weird. I can't tell what happened. But I can tell you that USB development goes on in Greg K-H's tree. The current version is available as a patch based on 2.6.14-rc4: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.14-rc4.patch On top of that you should apply the patch for uhci-hcd that I mentioned before. With this combination I have had no problem suspending three different machines. Sometimes they even wake up, too! :-) Thanks a lot for all the information. Still I'd rather like to figure out what causes the problem to appear in -rc4-mm1. So far I have identified the offending patch which is: gregkh-usb-usb-power-state-03.patch (ie. with the patch the problem occurs 100% of the time and without the patch it doesn't). I don't know which change in the patch is at fault (yet). [Note: the patch didn't revert cleanly so I changed the 7th chunk in drivers/usb/core/hub.c a bit.] The devices that refuse to suspend (with the above patch) are: usb usb3: Product: EHCI Host Controller usb usb3: Manufacturer: Linux 2.6.14-rc4-mm1 ehci_hcd usb usb3: SerialNumber: :00:02.2 usb usb2: Product: OHCI Host Controller usb usb2: Manufacturer: Linux 2.6.14-rc4-mm1 ohci_hcd usb usb2: SerialNumber: :00:02.1 Greetings, Rafael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)
Hi,
On Wednesday, 19 of October 2005 18:18, Alan Stern wrote:
[Trimmed the CC: list]
}-- snip --{
Stopping tasks: |
Freeing memory... done (14642 pages freed)
Suspending device card0-0
Suspending device 2-2:1.0
Suspending device 2-2
Suspending device 3-0:1.0
hub 3-0:1.0: no suspend?
This line is the puzzle. It indicates that the driver bound to the
3-0:1.0 device (which is a root hub interface for one of your USB
controllers) doesn't have a suspend or resume method. But the hub driver
_does_ have these methods!
Unless someone, like me, has CONFIG_USB_SUSPEND unset,
in which case they are #defined as NULLs (of course if I'm not missing
anything). Is now CONFIG_USB_SUSPEND mandatory for being able to suspend?
Unless you somehow screwed up the build. Take a look inside
drivers/usb/core/hub.c and make sure that the hub_suspend() and
hub_resume() routines are listed in the hub_driver table, and that they
haven't been preprocessed away into NULLs. You might end up needing to do
a clean rebuild.
This already is a clean build, on top of 2.6.13 unpacked from scratch (well,
I have some patches applied, but they don't touch USB).
Suspending device usb3
Could not suspend device usb3: error -16
Some devices failed to suspend
These errors occurred, naturally enough, because the driver for usb3
refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't
suspended.
I've figured out that too. However, if something has no _suspend() routine,
verify_suspended() could return 0 for it, I think, instead of -EBUSY.
Greetings,
Rafael
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: 2.6.14-rc4-mm1: USB suspend regression (was: Re: 2.6.14-rc1-mm1: usb breaks suspend)
Hi,
On Wednesday, 19 of October 2005 22:46, Alan Stern wrote:
On Wed, 19 Oct 2005, Rafael J. Wysocki wrote:
}-- snip --{
There has been a lot of development on USB
suspend/resume in 2.6.14, and you don't have all the patches applied. In
particular, you are missing usb-pm-05.patch (probably a bunch of others as
well).
If I'm missing any patches that's becasue they are not in 2.6.14-rc4-mm1
for some reason (I assume an important one).
Take my advice: Start from 2.6.14-rc4, apply gregkh-all-2.6.14-rc4.patch
(it gets updated fairly often, so retrieve a fresh copy), and also apply
the PF_NOFREEZE patch (as585) I posted on lkml and linux-pm.
From my POV this means there's no point in testing USB suspend/resume
on 2.6.14-rc4-mm1, because it's potentially broken. Which is fair enough,
BTW.
These errors occurred, naturally enough, because the driver for usb3
refused to suspend since one of the children -- namely 3-0:1.0 -- wasn't
suspended.
I've figured out that too. However, if something has no _suspend() routine,
verify_suspended() could return 0 for it, I think, instead of -EBUSY.
Dave Brownell would probably give you an argument, but I tend to agree.
Alternatively, if something has no -suspend then we could just set its
-power.power_state value directly so it would _appear_ to be suspended.
Well, that depends. If the driver has a _resume() routine, it's
-power.power_state
should be set on suspend. However, if it has neither _resume() nor _suspend(),
it's -power.power_state is not really well defined, so it's just easier to
ignore it.
Greetings,
Rafael
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [linux-pm] 2.6.14-rc1-mm1: usb breaks suspend
Hi, On Monday, 17 of October 2005 20:54, Alan Stern wrote: On Mon, 17 Oct 2005, Pavel Machek wrote: Hi! In -mm, usb breaks suspend to disk. Compiled without CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it actually tries to suspend USB, but it fails and machine refuses to suspend. Is it known or is it worth debugging? More details please. Fails for me too on x86-64, with the following messages: Stopping tasks: | Freeing memory... done (14642 pages freed) Suspending device card0-0 Suspending device 2-2:1.0 Suspending device 2-2 Suspending device 3-0:1.0 hub 3-0:1.0: no suspend? Suspending device usb3 Could not suspend device usb3: error -16 Some devices failed to suspend Restarting tasks... done where the USB-related info returned by the kernel is this: ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 11 ACPI: PCI Interrupt :00:02.0[A] - Link [LUS0] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :00:02.0 to 64 ohci_hcd :00:02.0: OHCI Host Controller ohci_hcd :00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:02.0: irq 11, io mem 0xfebfb000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ACPI: PCI Interrupt Link [LUS1] enabled at IRQ 11 ACPI: PCI Interrupt :00:02.1[B] - Link [LUS1] - GSI 11 (level, low) - IRQ 11 PCI: Setting latency timer of device :00:02.1 to 64 ohci_hcd :00:02.1: OHCI Host Controller ohci_hcd :00:02.1: new USB bus registered, assigned bus number 2 ohci_hcd :00:02.1: irq 11, io mem 0xfebfc000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 5 usb 2-2: new low speed USB device using ohci_hcd and address 2 PCI: setting IRQ 5 as level-triggered ACPI: PCI Interrupt :00:02.2[C] - Link [LUS2] - GSI 5 (level, low) - IRQ 5 PCI: Setting latency timer of device :00:02.2 to 64 ehci_hcd :00:02.2: EHCI Host Controller ehci_hcd :00:02.2: debug port 1 ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3 ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00 PCI: cache line size of 64 is not supported by device :00:02.2 ehci_hcd :00:02.2: park 0 ehci_hcd :00:02.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 usb 2-2: device descriptor read/all, error -110 hub 3-0:1.0: USB hub found hub 3-0:1.0: 6 ports detected ohci_hcd :00:02.1: wakeup usb 2-2: new low speed USB device using ohci_hcd and address 4 usbcore: registered new driver hiddev input: Logitech USB Receiver//class/input_dev as input3 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:02.1-2 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver Greetings, Rafael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.13-mm2
Hi, On Wednesday, 28 of September 2005 22:23, David Brownell wrote: BTW, please have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=4416#c36 and http://bugzilla.kernel.org/show_bug.cgi?id=4416#c37 What's with the bogus dates in those reports ... claiming some of you were testing 2.6.13-rc2-mm2 more than two months ago, mid-July ? Nothing. :-) 2.6.13-rc2-mm2 was out exactly on July 12, and that's when I tested it (please see: http://www.ussg.iu.edu/hypermail/linux/kernel/0507.1/1177.html). Greetings, Rafael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.13-mm2
Hi, On Wednesday, 28 of September 2005 22:56, David Brownell wrote: On Wednesday, 28 of September 2005 22:23, David Brownell wrote: BTW, please have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=4416#c36 and http://bugzilla.kernel.org/show_bug.cgi?id=4416#c37 What's with the bogus dates in those reports ... claiming some of you were testing 2.6.13-rc2-mm2 more than two months ago, mid-July ? Nothing. :-) 2.6.13-rc2-mm2 was out exactly on July 12, and that's when I tested it ... OK, sorry; pardon me! Then the right question to ask is more like So does this still happen in **2.6.14-rc2** ??. 2.6.13-rc is marginally more recent than 2.4.20, but it still feels old. :) My other point still stands though. The IRQ for all HCDs _are_ freed on suspend, and re-requested on resume ... so lack of such free/request calls can't possibly be an issue. Yes it can. Apparently on my box the call to request_irq() from a USB HCD driver (OHCI or EHCI) causes a screaming interrupt to be generated, which kills any other driver that shares the IRQ with the USB and has not called free_irq() on suspend. Of course this only happens with the patch at http://www.ussg.iu.edu/hypermail/linux/kernel/0507.3/2234.html unapplied, as it masks the problem. Actually it also depends on the order in which the drivers' resume routines are called, but unfortunately on my box the USB drivers' are called first. Still, if _none_ of the drivers (including USB HCD) calls request_irq() on resume, the box survives _even_ _without_ the above-mentioned patch. The old rule of thumb with USB does still apply though: be sure to test with BIOS support for it disabled. AFAICT, in this particular case it doesn't matter. Greetings, Rafael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: 2.6.13-mm2
Hi, On Wednesday, 28 of September 2005 23:07, David Brownell wrote: ok. i didn't look too close, but i think ohci-hcd does not fully disable interrupts in it's suspend callback...needs a closer look. cc:ing linux-usb-devel... It's handled in hcd-pci.c ... All PCI based HCDs release their IRQs when they suspend. Including OHCI. Your diagnosis is incorrect. would you be kind enough to tell me where? There's only one free_irq() line, and it gets called the first time through usb_hcd_pci_suspend(). QED. my point is: the test patch i sent to rafael which comments out the free_irq-on-suspend thing in hcd-pci.c shows that something is wrong with USB (i think only OHCI. UHCI looks ok and about EHCI i have no data). Your logic escapes me, since your patch affected all three PCI HCDs. If that's wrong for one, its wrong for all three. And as I just commented to Rafael, here are two better things to try instead of believing a diagnosis that's clearly wrong: - 2.6.14-rc2 This one works obviously, as it contains the patch that adds acpi_pci_link_resume() (http://www.ussg.iu.edu/hypermail/linux/kernel/0507.3/2234.html). The patch is not present in -mm though, AFAIK, so I can test the latest one, if you want me to, but I think it won't work. Greetings, Rafael --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.10-rc1-mm4: USB storage not working on AMD64
Hi, There seems to be a problem in 2.6.10-rc1-mm4 with either USB storage (eg a pendrive) or hotplug on AMD64 (NForce3 chipset, ohci-hcd, SuSE 9.1). Namely, if a USB pendrive is inserted into a socket, the kernel does not even detect it. Here's what appears in dmesg after it's inserted: ohci_hcd :00:02.0: wakeup Other USB devices (eg a mouse) seem to work normally. Of course such problems do not occur on 2.6.10-rc1. On 2.6.10-rc1-mm3 I've had this problem only on a dual-Opteron box, but on 2.6.10-rc1-mm4 I see it on a one-processor box either. Greets, RJW -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.10-rc1-mm4: USB storage not working on AMD64
On Wednesday 10 of November 2004 14:58, David Brownell wrote: On Wednesday 10 November 2004 02:54, Rafael J. Wysocki wrote: Hi, There seems to be a problem in 2.6.10-rc1-mm4 with either USB storage (eg a pendrive) or hotplug on AMD64 (NForce3 chipset, ohci-hcd, SuSE 9.1). Namely, if a USB pendrive is inserted into a socket, the kernel does not even detect it. Here's what appears in dmesg after it's inserted: ohci_hcd :00:02.0: wakeup Other USB devices (eg a mouse) seem to work normally. I recently posted several USB PM fixes that make things work better in my testing, and it sounds like they'd probably help here too. Are they available as stand-alone patches? I'd like to test ... Greets, RJW -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.10-rc1-mm4: USB storage not working on AMD64
On Wednesday 10 of November 2004 16:36, David Brownell wrote: On Wednesday 10 November 2004 06:57, Rafael J. Wysocki wrote: On Wednesday 10 of November 2004 14:58, David Brownell wrote: I recently posted several USB PM fixes that make things work better in my testing, and it sounds like they'd probably help here too. Are they available as stand-alone patches? I'd like to test ... Yes, check the linux-usb-devel archives from Sunday evening. Thanks a lot. These patches evidently fix the problem described in this thread (verified on two different AMD64-based configurations). Greets, RJW -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [2.6.9-rc3] suspend-to-disk oddities
On Monday 04 of October 2004 14:22, Jan De Luyck wrote: [-- snip --] Does cat /proc/bus/usb/devices give you an empty file or does it hang? Is that modular USB or is it compiled into the kernel? OHCI or UHCI? UHCI. I just did a test-suspend-resume, currently plugged USB devices don't work, but it does show up in the devices file. It also responds to replugging I don't get it. I had no response whatsoever earlier. Mouse doesn't work until replugged, lots of messages like this in dmesg: Oct 4 14:16:49 precious kernel: drivers/usb/input/hid-core.c: input irq status -84 received Oct 4 14:16:54 precious last message repeated 209 times Have you tried booting with pci=routeirq? It may help. Greets, RJW -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.9-rc3: USB OHCI failure on suspend on AMD64
On Thursday 30 of September 2004 23:58, David Brownell wrote:
On Thursday 30 September 2004 1:51 pm, Rafael J. Wysocki wrote:
Hi,
It seems there's a problem with USB OHCI driver that causes these traces
to
appear on suspend on an AMD64-based box:
Not all parts of power management integrate well yet with each other,
though it's acting better. Plus there are some OHCI updates in the USB
patches (you'll have those in the MM tree) that help address some of
the more perverse ways that suspend-to-disk kicks USB around, and
a few similar usbcore changes that need re-integration with the RC3
swsusp/pmdisk updates.
Keep using the rmmod workaround for now. And don't combine
CONFIG_USB_SUSPEND with suspend-to-{disk,ram} unless you're
feeling like debugging the results.
I'm doing just this. And reporting. ;-)
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.9-rc3: USB OHCI failure on suspend on AMD64
Hi,
It seems there's a problem with USB OHCI driver that causes these traces to
appear on suspend on an AMD64-based box:
..7PM: Image restored successfully.
PCI: Setting latency timer of device :00:02.0 to 64
ohci_hcd :00:02.0: HC died; cleaning up
usb 1-2: USB disconnect, address 3
Badness in hcd_endpoint_disable at drivers/usb/core/hcd.c:1310
Call Trace:7Losing some ticks... checking if CPU frequency changed.
803455fb{hcd_endpoint_disable+107}
80346729{usb_disable_endpoint+41}
803468aa{usb_disable_device+26}
803422fc{usb_disconnect+188}
803441b0{hcd_panic+0} 803441fa{hcd_panic+74}
8015824d{worker_thread+733}
80137c00{default_wake_function+0}
80137c00{default_wake_function+0}
80157f70{worker_thread+0}
8015f51d{kthread+205} 80111b43{child_rip+8}
8015f450{kthread+0} 80111b3b{child_rip+0}
[-- several times the above --]
Call Trace:80345c3e{hcd_unlink_urb+494}
803463dc{usb_kill_urb+380}
80345a37{hcd_endpoint_disable+1191}
8019ed6e{invalidate_inode_buffers+14}
80346729{usb_disable_endpoint+41}
a022374c{:usbhid:hid_disconnect+44}
8033f4e9{usb_unbind_interface+73}
8030b95e{device_release_driver+94}
8030baf4{bus_remove_device+164}
8030a898{device_del+88}
8034690b{usb_disable_device+123}
803422fc{usb_disconnect+188}
803441b0{hcd_panic+0} 803441fa{hcd_panic+74}
8015824d{worker_thread+733}
80137c00{default_wake_function+0}
80137c00{default_wake_function+0}
80157f70{worker_thread+0}
8015f51d{kthread+205} 80111b43{child_rip+8}
8015f450{kthread+0} 80111b3b{child_rip+0}
[-- once again the above --]
The workaround is to explicitly unload the driver before suspend and reload it
after resume. It is possible that it's fixed in -mm kernels, as I haven't
seen such symptoms there, recently (since 2.6.9-rc2-mm1 at least).
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
