Re: [linux-usb-devel] [usb-storage] schedule_timeout: wrong timeout value c1a95554

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[linux-usb-devel] [PATCH][RFC] make config vars uniformly SAFE_SERIAL

[Robert P. J. Day]

/safe_serial.c
@@ -74,13 +74,13 @@
 #include linux/usb/serial.h


-#ifndef CONFIG_USB_SAFE_PADDED
-#define CONFIG_USB_SAFE_PADDED 0
+#ifndef CONFIG_USB_SAFE_SERIAL_PADDED
+#define CONFIG_USB_SAFE_SERIAL_PADDED 0
 #endif

 static int debug;
 static int safe = 1;
-static int padded = CONFIG_USB_SAFE_PADDED;
+static int padded = CONFIG_USB_SAFE_SERIAL_PADDED;

 #define DRIVER_VERSION v0.0b
 #define DRIVER_AUTHOR [EMAIL PROTECTED], [EMAIL PROTECTED]
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] [PATCH][RFC] make config vars uniformly SAFE_SERIAL

[Robert P. J. Day]

On Wed, 1 Aug 2007, Greg KH wrote:

 On Wed, Aug 01, 2007 at 05:13:51AM -0400, Robert P. J. Day wrote:
 
  just a preliminary strike, trying to make some of these names
  uniform. that includes having to change some of the settings in
  various defconfig files.
 
  not compile tested, i'm just interested if this is acceptable.

 If you look at how the other USB_SERIAL_* Kconfig entries are
 specified, I think the Kconfig is correct, but the code is
 incorrect.  Care to switch it the other way around?

no problem, just note that the actual source file is safe_serial.c.
so, all entries will then contain the uniform string SERIAL_SAFE
rather than SAFE_SERIAL, that's what you're after?  just making
sure.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH] Remove dead references to SAFE_SERIAL CONFIG variables.

[Robert P. J. Day]

Remove the references to CONFIG_USBD_SAFE_SERIAL_{VENDOR,PRODUCT},
which aren't defined in any Kconfig file.

Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]

---

  this simple deletion takes care of most of what we've been
discussing until now.  not compile tested, but it's pretty
straightforward.

  with this patch, there are no occurrences of the string
SAFE_SERIAL anywhere in the tree anymore.



diff --git a/drivers/usb/serial/safe_serial.c b/drivers/usb/serial/safe_serial.c
index 86899d5..65e5f93 100644
--- a/drivers/usb/serial/safe_serial.c
+++ b/drivers/usb/serial/safe_serial.c
@@ -90,18 +90,12 @@ MODULE_AUTHOR (DRIVER_AUTHOR);
 MODULE_DESCRIPTION (DRIVER_DESC);
 MODULE_LICENSE(GPL);

-#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)  
!defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
-#error SAFE_SERIAL_VENDOR defined without SAFE_SERIAL_PRODUCT
-#endif
-
-#if ! defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)
 static __u16 vendor;   // no default
 static __u16 product;  // no default
 module_param(vendor, ushort, 0);
 MODULE_PARM_DESC(vendor, User specified USB idVendor (required));
 module_param(product, ushort, 0);
 MODULE_PARM_DESC(product, User specified USB idProduct (required));
-#endif

 module_param(debug, bool, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(debug, Debug enabled or not);
@@ -145,11 +139,6 @@ static struct usb_device_id id_table[] = {
{MY_USB_DEVICE (0x4dd, 0x8003, CDC_DEVICE_CLASS, LINEO_INTERFACE_CLASS, 
LINEO_INTERFACE_SUBCLASS_SAFESERIAL)},  // Collie
{MY_USB_DEVICE (0x4dd, 0x8004, CDC_DEVICE_CLASS, LINEO_INTERFACE_CLASS, 
LINEO_INTERFACE_SUBCLASS_SAFESERIAL)},  // Collie
{MY_USB_DEVICE (0x5f9, 0x, CDC_DEVICE_CLASS, LINEO_INTERFACE_CLASS, 
LINEO_INTERFACE_SUBCLASS_SAFESERIAL)},  // Sharp tmp
-#if defined(CONFIG_USB_SAFE_SERIAL_VENDOR)
-   {MY_USB_DEVICE
-(CONFIG_USB_SAFE_SERIAL_VENDOR, CONFIG_USB_SAFE_SERIAL_PRODUCT, 
CDC_DEVICE_CLASS,
- LINEO_INTERFACE_CLASS, LINEO_INTERFACE_SUBCLASS_SAFESERIAL)},
-#endif
// extra null entry for module
// vendor/produc parameters
{MY_USB_DEVICE (0, 0, CDC_DEVICE_CLASS, LINEO_INTERFACE_CLASS, 
LINEO_INTERFACE_SUBCLASS_SAFESERIAL)},
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH] USB: Typo: USB_SAFE_PADDED - USB_SERIAL_SAFE_PADDED.

[Robert P. J. Day]

Fix typo in safe_serial.c to match the actual CONFIG variable.

Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]

---

diff --git a/drivers/usb/serial/safe_serial.c b/drivers/usb/serial/safe_serial.c
index 86899d5..51669b7 100644
--- a/drivers/usb/serial/safe_serial.c
+++ b/drivers/usb/serial/safe_serial.c
@@ -74,13 +74,13 @@
 #include linux/usb/serial.h


-#ifndef CONFIG_USB_SAFE_PADDED
-#define CONFIG_USB_SAFE_PADDED 0
+#ifndef CONFIG_USB_SERIAL_SAFE_PADDED
+#define CONFIG_USB_SERIAL_SAFE_PADDED 0
 #endif

 static int debug;
 static int safe = 1;
-static int padded = CONFIG_USB_SAFE_PADDED;
+static int padded = CONFIG_USB_SERIAL_SAFE_PADDED;

 #define DRIVER_VERSION v0.0b
 #define DRIVER_AUTHOR [EMAIL PROTECTED], [EMAIL PROTECTED]
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] undefined USB-related CONFIG variables

[Robert P. J. Day]

  the latest output of the dead CONFIG variable script run against
the directory drivers/usb (obviously some false positives, but some
definitely dead variables):



== 440EPX ==
drivers/usb/host/ehci-hcd.c:1014:#ifdef CONFIG_440EPX
drivers/usb/host/ehci-ppc-soc.c:67:#if defined(CONFIG_440EPX)
== MACH_OMAP_H4_OTG ==
drivers/usb/gadget/omap_udc.c:2051:#ifndef CONFIG_MACH_OMAP_H4_OTG
== USBD_SAFE_SERIAL_PRODUCT ==
drivers/usb/serial/safe_serial.c:93:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR) 
 !defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
== USBD_SAFE_SERIAL_VENDOR ==
drivers/usb/serial/safe_serial.c:93:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR) 
 !defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
drivers/usb/serial/safe_serial.c:97:#if ! 
defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)
== USB_GADGET_ATMEL_USBA ==
drivers/usb/gadget/gadget_chips.h:91:#ifdef CONFIG_USB_GADGET_ATMEL_USBA
drivers/usb/gadget/ether.c:280:#ifdef CONFIG_USB_GADGET_ATMEL_USBA
== USB_GADGET_IMX ==
drivers/usb/gadget/gadget_chips.h:110:#ifdef CONFIG_USB_GADGET_IMX
== USB_GADGET_MPC8272 ==
drivers/usb/gadget/gadget_chips.h:138:#ifdef CONFIG_USB_GADGET_MPC8272
== USB_GADGET_MQ11XX ==
drivers/usb/gadget/gadget_chips.h:65:#ifdef CONFIG_USB_GADGET_MQ11XX
drivers/usb/gadget/ether.c:248:#ifdef CONFIG_USB_GADGET_MQ11XX
== USB_GADGET_MUSB_HDRC ==
drivers/usb/gadget/gadget_chips.h:131:#ifdef CONFIG_USB_GADGET_MUSB_HDRC
drivers/usb/gadget/ether.c:276:#ifdef CONFIG_USB_GADGET_MUSB_HDRC
== USB_GADGET_MUSBHSFC ==
drivers/usb/gadget/gadget_chips.h:124:#ifdef CONFIG_USB_GADGET_MUSBHSFC
drivers/usb/gadget/ether.c:272:#ifdef CONFIG_USB_GADGET_MUSBHSFC
== USB_GADGET_N9604 ==
drivers/usb/gadget/gadget_chips.h:78:#ifdef CONFIG_USB_GADGET_N9604
drivers/usb/gadget/ether.c:256:#ifdef CONFIG_USB_GADGET_N9604
== USB_GADGET_PXA27X ==
drivers/usb/gadget/gadget_chips.h:85:#ifdef CONFIG_USB_GADGET_PXA27X
drivers/usb/gadget/ether.c:260:#ifdef CONFIG_USB_GADGET_PXA27X
== USB_GADGET_SA1100 ==
arch/arm/configs/h7202_defconfig:561:# CONFIG_USB_GADGET_SA1100 is not set
arch/arm/configs/lubbock_defconfig:595:# CONFIG_USB_GADGET_SA1100 is not set
drivers/usb/gadget/gadget_chips.h:52:#ifdef CONFIG_USB_GADGET_SA1100
drivers/usb/gadget/ether.c:299:#ifdef CONFIG_USB_GADGET_SA1100
== USB_GADGET_SUPERH ==
drivers/usb/gadget/gadget_chips.h:45:#ifdef CONFIG_USB_GADGET_SUPERH
drivers/usb/gadget/ether.c:295:#ifdef CONFIG_USB_GADGET_SUPERH
== USB_SAFE_PADDED ==
drivers/usb/serial/safe_serial.c:77:#ifndef CONFIG_USB_SAFE_PADDED
drivers/usb/serial/safe_serial.c:78:#define CONFIG_USB_SAFE_PADDED 0
drivers/usb/serial/safe_serial.c:83:static int padded = CONFIG_USB_SAFE_PADDED;
== USB_SAFE_SERIAL_VENDOR ==
drivers/usb/serial/safe_serial.c:148:#if defined(CONFIG_USB_SAFE_SERIAL_VENDOR)
drivers/usb/serial/safe_serial.c:150:(CONFIG_USB_SAFE_SERIAL_VENDOR, 
CONFIG_USB_SAFE_SERIAL_PRODUCT, CDC_DEVICE_CLASS,

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] undefined USB-related CONFIG variables

[Robert P. J. Day]

On Sun, 29 Jul 2007, Greg KH wrote:

 On Sun, Jul 29, 2007 at 04:17:57PM -0400, Robert P. J. Day wrote:
 
the latest output of the dead CONFIG variable script run against
  the directory drivers/usb (obviously some false positives, but some
  definitely dead variables):

 Care to make up some patches to fix these?

which ones?  are you saying they're *all* dead?  that can't be
possible since at least one is a fake CONFIG variable:

== USB_SAFE_PADDED ==
drivers/usb/serial/safe_serial.c:77:#ifndef CONFIG_USB_SAFE_PADDED
drivers/usb/serial/safe_serial.c:78:#define CONFIG_USB_SAFE_PADDED 0
drivers/usb/serial/safe_serial.c:83:static int padded = CONFIG_USB_SAFE_PADDED;

  in cases like that, i prefer to just rename the variable so it no
longer resembles a Kconfig variable.  but the rest of them are all
removable?  i'd probably submit a small set of patches, each one to
handle a related set of those variables, if that's what you want.

rday

--


Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] SERIAL_SAFE versus SAFE_SERIAL

[Robert P. J. Day]

  i think someone higher up the food chain might want to handle what
appear to be typoes here:

$ grep -r SAFE_SERIAL *
drivers/usb/serial/safe_serial.c:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)  
!defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
drivers/usb/serial/safe_serial.c:#error SAFE_SERIAL_VENDOR defined without 
SAFE_SERIAL_PRODUCT
drivers/usb/serial/safe_serial.c:#if ! defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)
drivers/usb/serial/safe_serial.c:#if defined(CONFIG_USB_SAFE_SERIAL_VENDOR)
drivers/usb/serial/safe_serial.c:(CONFIG_USB_SAFE_SERIAL_VENDOR, 
CONFIG_USB_SAFE_SERIAL_PRODUCT, CDC_DEVICE_CLASS,

$ grep -r SERIAL_SAFE *
... lots of defconfig's deleted ...
drivers/usb/serial/Makefile:obj-$(CONFIG_USB_SERIAL_SAFE)   
+= safe_serial.o
drivers/usb/serial/Kconfig:config USB_SERIAL_SAFE
drivers/usb/serial/Kconfig:config USB_SERIAL_SAFE_PADDED
drivers/usb/serial/Kconfig: depends on USB_SERIAL_SAFE

  i mean, is it *deliberate* to mix both USB_SAFE_SERIAL and
USB_SERIAL_SAFE as above?  yeesh.

rday
--

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] undefined USB-related CONFIG variables

[Robert P. J. Day]

On Sun, 29 Jul 2007, Greg KH wrote:

 On Sun, Jul 29, 2007 at 05:15:41PM -0400, Robert P. J. Day wrote:
  On Sun, 29 Jul 2007, Greg KH wrote:
 
   On Sun, Jul 29, 2007 at 04:17:57PM -0400, Robert P. J. Day wrote:
   
  the latest output of the dead CONFIG variable script run against
the directory drivers/usb (obviously some false positives, but some
definitely dead variables):
  
   Care to make up some patches to fix these?
 
  which ones?  are you saying they're *all* dead?  that can't be
  possible since at least one is a fake CONFIG variable:
 
  == USB_SAFE_PADDED ==
  drivers/usb/serial/safe_serial.c:77:#ifndef CONFIG_USB_SAFE_PADDED
  drivers/usb/serial/safe_serial.c:78:#define CONFIG_USB_SAFE_PADDED 0
  drivers/usb/serial/safe_serial.c:83:static int padded = 
  CONFIG_USB_SAFE_PADDED;
 
in cases like that, i prefer to just rename the variable so it no
  longer resembles a Kconfig variable.  but the rest of them are all
  removable?  i'd probably submit a small set of patches, each one to
  handle a related set of those variables, if that's what you want.

 It all depends, some of them might just be typos, just like this one
 (hint, it is a Kconfig option, just mis-named...)

yes, i just noticed that, and i now recall that i identified that
particular misspelling months ago:

http://lkml.org/lkml/2007/1/16/72

so why it's still there is a bit of a mystery, but i'll put in a patch
to fix it.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Volunteer to be the new usb.ids maintainer!!

[Stephen J. Gowdy]

Hi David  Vojtech,
I can do it if it is just updating the file and responding to 
requests. I get a bunch of them too and forward them to Vojtech. I'd 
probably not find new classes to add but if prompted would.

regards,

Stephen.

On Sat, 28 Jul 2007, Vojtech Pavlik wrote:

 On Fri, Jul 27, 2007 at 11:10:46AM -0700, David Brownell wrote:

 I think we need a new usb.ids maintainer ... I get way too much
 email from folk saying Vojtech hasn't responded so would I please
 merge the IDs.  (Vojtech, if you disagree, please speak up!)

 Yes, I'm perfectly fine with that, and I already offered the role to a
 couple people that contacted me about it, but got no positive replies in
 the end.

 What's required?  Be a member of the sourceforge linux-usb project,
 so you can update the CVS for http://www.linux-usb.org/usb.ids ...
 and respond to the emails periodically.  Maybe read new USB.org
 class specs to collect new IDs they assign.  Other members of that
 project will update that file periodically, but there needs to
 be a designated lead contact.

 So -- someone, please volunteer!



--
   /+-\
|Stephen J. Gowdy, SLAC   | CERN Office: 32-2-A22|
|http://www.slac.stanford.edu/~gowdy/ | CH-1211 Geneva 23|
| | Switzerland  |
|EMail: [EMAIL PROTECTED]   | Tel: +41 22 767 5840 |
   \+-/

-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Volunteer to be the new usb.ids maintainer!!

[Stephen J. Gowdy]

Cheers. I'll divide them up later and send you them off list.

Thanks, Vojtech, even though you seem to be on holiday!

On Sat, 28 Jul 2007, jidong xiao wrote:

 If you accept the role, I'll send you my backlog of approximately 370
 requests ...

 Stephen,
I can help to update it. we can work together to deal with so
 many requests.

 Regards
 Jason Xiao

 --
 Vojtech Pavlik
 Director SuSE Labs



--
   /+-\
|Stephen J. Gowdy, SLAC   | CERN Office: 32-2-A22|
|http://www.slac.stanford.edu/~gowdy/ | CH-1211 Geneva 23|
| | Switzerland  |
|EMail: [EMAIL PROTECTED]   | Tel: +41 22 767 5840 |
   \+-/

-
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 unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] [2.6.22-rc7] khubd NULL deref oops...

[Daniel J Blueman]

On 11/07/07, Chuck Ebbert [EMAIL PROTECTED] wrote:
 On 07/08/2007 05:45 PM, Daniel J Blueman wrote:
  When plugging in a USB 2 mass-storage device which I've been seeing
  problems with, I caught a khubd oops [1]. Kernel is 2.6.22-rc7 on ia32
  built with Ubuntu's 2.6.22 .config.

  [ 4769.252000] sd 6:0:0:0: [sdb] Assuming drive cache: write through
  [ 4769.252000]  sdb: sdb1  sdb5 sdb66usb 5-3: reset high speed USB
  device using ehci_hcd and address 8

 So the device got reset right in the middle of scanning for partitions.

  [ 4769.544000] usb 5-3: device descriptor read/64, error -71
  [ 4769.76] usb 5-3: device descriptor read/64, error -71
  [ 4769.976000] usb 5-3: reset high speed USB device using ehci_hcd and
  address 8
  [ 4770.088000] usb 5-3: device descriptor read/64, error -71
  [ 4770.304000] usb 5-3: device descriptor read/64, error -71
  [ 4770.52] usb 5-3: reset high speed USB device using ehci_hcd and
  address 8
  [ 4770.928000] usb 5-3: device not accepting address 8, error -71
  [ 4771.04] usb 5-3: reset high speed USB device using ehci_hcd and
  address 8

 Then a whole slew of these by-now-familiar messages.

 Try disabling CONFIG_USB_SUSPEND.  It makes lots of USB bugs go away

I'll give it a shot. For the record, I wasn't trying to perform a
suspend at this time (or since booting).

Thanks for your help,
  Daniel
-- 
Daniel J Blueman

-
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]

[Rafael J. Wysocki]

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]

[Rafael J. Wysocki]

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]

[Rafael J. Wysocki]

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]

[Rafael J. Wysocki]

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]

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

Re: [linux-usb-devel] blank filenames in /sys/modules, kernel 2.6.21

[Robert P. J. Day]

On Fri, 8 Jun 2007, Chuck Ebbert wrote:

 We just found a file with this name in 2.6.21:

 Directory name: /sys/module/nousb/parameters
 File name:  

 IOW the file has an empty name. Is this intentional?
 It sure confuses updatedb...

 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242715

that appears to be the result of:

$ grep -r __module_param_call *
drivers/usb/core/usb.c:__module_param_call(, nousb, param_set_bool, 
param_get_bool, nousb, 0444);
include/linux/moduleparam.h:#define __module_param_call(prefix, name, set, get, 
arg, perm)  \
include/linux/moduleparam.h:__module_param_call(MODULE_PARAM_PREFIX, name, 
set, get, arg, perm)

  and from drivers/usb/core/usb.c:

/* format to disable USB on kernel command line is: nousb */
__module_param_call(, nousb, param_set_bool, param_get_bool, nousb, 0444);

  one has to wonder about the value of a macro that is invoked only
once throughout the entire tree.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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] blank filenames in /sys/modules, kernel 2.6.21

[Robert P. J. Day]

On Fri, 8 Jun 2007, Pete Zaitcev wrote:

 On Fri, 8 Jun 2007 11:32:32 -0700, Greg KH [EMAIL PROTECTED] wrote:

 and from drivers/usb/core/usb.c:
  
   /* format to disable USB on kernel command line is: nousb */
   __module_param_call(, nousb, param_set_bool, param_get_bool, nousb, 
   0444);

  Pete added that back in December of 2005 (git-blame rocks...).  So what
  has changed recently to cause this to do different things in sysfs?
 
  Robert, what do you suggest we change this usage to look like?

 Aww. I thought it was a nice patch, but my foresight was inadequate.

 The problem I tried to fix was related to strncmp used in the code which
 supported __setup(). Our installer, Anaconda, recognizes both nousb and
 nousbstorage - in theory. In practice, passing nousbstorage switched
 USB completely off because of improper strncmp(). If we back out my patch,
 this problem is going to reoccur.

 We might want to ask Jeremy Katz if nousbstorage is even used anymore,
 then revert all this if not. Or, we can add a name somehow and live
 with it visible in sysfs...

there appears to be no reference to nousbstorage anywhere in the
tree.  go for it.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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] blank filenames in /sys/modules, kernel 2.6.21

[Robert P. J. Day]

On Fri, 8 Jun 2007, Greg KH wrote:

 On Fri, Jun 08, 2007 at 02:05:22PM -0400, Robert P. J. Day wrote:
  On Fri, 8 Jun 2007, Chuck Ebbert wrote:
 
   We just found a file with this name in 2.6.21:
  
   Directory name: /sys/module/nousb/parameters
   File name:  
  
   IOW the file has an empty name. Is this intentional?
   It sure confuses updatedb...
  
   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242715
 
  that appears to be the result of:
 
  $ grep -r __module_param_call *
  drivers/usb/core/usb.c:__module_param_call(, nousb, param_set_bool, 
  param_get_bool, nousb, 0444);
  include/linux/moduleparam.h:#define __module_param_call(prefix, name, set, 
  get, arg, perm)  \
  include/linux/moduleparam.h:__module_param_call(MODULE_PARAM_PREFIX, 
  name, set, get, arg, perm)
 
and from drivers/usb/core/usb.c:
 
  /* format to disable USB on kernel command line is: nousb */
  __module_param_call(, nousb, param_set_bool, param_get_bool, nousb, 
  0444);
 
one has to wonder about the value of a macro that is invoked only
  once throughout the entire tree.

 Pete added that back in December of 2005 (git-blame rocks...).  So what
 has changed recently to cause this to do different things in sysfs?

 Robert, what do you suggest we change this usage to look like?

um ... i'm fairly sure i'm totally the wrong person to be asked about
this, but what does any of the above have to do with disabling USB on
the kernel command line?  wouldn't you typically define a kernel
command line option with something like:
...
arch/i386/kernel/traps.c:__setup(kstack=, kstack_setup);
arch/i386/kernel/traps.c:__setup(code_bytes=, code_bytes_setup);
arch/i386/kernel/nmi.c:__setup(nmi_watchdog=, setup_nmi_watchdog);
arch/i386/kernel/reboot.c:__setup(reboot=, reboot_setup);
arch/i386/kernel/tsc.c:__setup(notsc, tsc_setup);
...

you know -- that sort of thing.  i mean, that's where *i'd* introduce
a nousb option.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[linux-usb-devel] [PATCH 2.6.21.1] host: remove EHCI atomic reference counting

[Steven J. Hill]

On Thu, Apr 26, 2007 at 11:30:03AM -0700, David Brownell wrote:
 
 Looks OK except it's missing a comment about why standard
 atomic refcount utilities (kref, atomic_t, etc) must not
 be used.  (That's in addition to the patch comment.)
 
Dave,

The patch to remove atomic operations on the reference counter for EHCI
is attached. Thank you.

-Steve

Signed-off-by: Steven J. Hill [EMAIL PROTECTED]
diff -ur linux-2.6.21.1/drivers/usb/host/ehci.h linux-2.6.21.1-patched/drivers/usb/host/ehci.h
--- linux-2.6.21.1/drivers/usb/host/ehci.h	2007-05-08 09:22:05.0 -0500
+++ linux-2.6.21.1-patched/drivers/usb/host/ehci.h	2007-05-08 09:31:51.0 -0500
@@ -418,7 +418,14 @@
 	struct ehci_qh		*reclaim;	/* next to reclaim */
 
 	struct ehci_hcd		*ehci;
-	struct kref		kref;
+
+	/*
+	 * Do NOT use atomic operations for reference counting. On some CPUs
+	 * (PPC7448 for example), atomic operations cannot be performed on
+	 * memory that is cache-inhibited (i.e. being used for DMA). Currently
+	 * spinlocks are sufficient to protect the counter.
+	 */
+	u32			refcount;
 	unsigned		stamp;
 
 	u8			qh_state;
diff -ur linux-2.6.21.1/drivers/usb/host/ehci-mem.c linux-2.6.21.1-patched/drivers/usb/host/ehci-mem.c
--- linux-2.6.21.1/drivers/usb/host/ehci-mem.c	2007-02-04 12:44:54.0 -0600
+++ linux-2.6.21.1-patched/drivers/usb/host/ehci-mem.c	2007-05-08 09:31:51.0 -0500
@@ -63,9 +63,8 @@
 }
 
 
-static void qh_destroy (struct kref *kref)
+static void qh_destroy (struct ehci_qh *qh)
 {
-	struct ehci_qh *qh = container_of(kref, struct ehci_qh, kref);
 	struct ehci_hcd *ehci = qh-ehci;
 
 	/* clean qtds first, and know this is not linked */
@@ -89,7 +88,7 @@
 		return qh;
 
 	memset (qh, 0, sizeof *qh);
-	kref_init(qh-kref);
+	qh-refcount = 1;
 	qh-ehci = ehci;
 	qh-qh_dma = dma;
 	// INIT_LIST_HEAD (qh-qh_list);
@@ -108,13 +107,16 @@
 /* to share a qh (cpu threads, or hc) */
 static inline struct ehci_qh *qh_get (struct ehci_qh *qh)
 {
-	kref_get(qh-kref);
+	WARN_ON(!qh-refcount);
+	qh-refcount++;
 	return qh;
 }
 
 static inline void qh_put (struct ehci_qh *qh)
 {
-	kref_put(qh-kref, qh_destroy);
+	if(!(qh-refcount--)) {
+		qh_destroy(qh);
+	}
 }
 
 /*-*/
-
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] [PATCH 0/6] Composite Gadget Support

[Stephen J. Gowdy]

This was partly my fault. They were all queued up as the author had bcced 
the list (at least that is what lists.sf.net thought). I rejected on set 
but didn't realise there was eight copies in each of the two sets...

On Fri, 4 May 2007, David Brownell wrote:

 On Thursday 03 May 2007, Ragner Magalhaes wrote:
 Hi, all

 There follows a series of patches for USB Composite Gadget Support.

 [PATCH 1/6] USB gadget driver.
 [PATCH 2/6] Composite gadget driver.
 [PATCH 3/6] Composite gadget driver upgrade.
 [PATCH 4/6] Kconfig modifications for USB Composite gadget support.
 [PATCH 5/6] Composite File Storage gadget support.
 [PATCH 6/6] Composite Ether gadget support.

 I seem to have gotten about eight copies of each of these ...

 The first one gave me an excuse to delete the older versions
 from my review queue, but the rest were a bit excessive.  Some
 mailer seems to be having a few issues...

 - Dave



 -
 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


--
  /+-\
|Stephen J. Gowdy, SLAC   | CERN Office: 32-2-A22|
|http://www.slac.stanford.edu/~gowdy/ | CH-1211 Geneva 23|
|http://calendar.yahoo.com/gowdy  | Switzerland  |
|EMail: [EMAIL PROTECTED]   | Tel: +41 22 767 5840 |
  \+-/

-
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] dead CONFIG_ variables: drivers/usb/

[Robert P. J. Day]

$ ../dead_config.sh drivers/usb
== MACH_OMAP_H4_OTG ==
drivers/usb/gadget/omap_udc.c:2159:#ifndef CONFIG_MACH_OMAP_H4_OTG
== USBD_SAFE_SERIAL_PRODUCT ==
drivers/usb/serial/safe_serial.c:93:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR) 
 !defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
== USBD_SAFE_SERIAL_VENDOR ==
drivers/usb/serial/safe_serial.c:93:#if defined(CONFIG_USBD_SAFE_SERIAL_VENDOR) 
 !defined(CONFIG_USBD_SAFE_SERIAL_PRODUCT)
drivers/usb/serial/safe_serial.c:97:#if ! 
defined(CONFIG_USBD_SAFE_SERIAL_VENDOR)
== USB_GADGETFS_PXA2XX ==
drivers/usb/gadget/inode.c:1508:#ifndef CONFIG_USB_GADGETFS_PXA2XX
== USB_GADGET_HUSB2DEV ==
drivers/usb/gadget/gadget_chips.h:78:#ifdef CONFIG_USB_GADGET_HUSB2DEV
drivers/usb/gadget/ether.c:281:#ifdef CONFIG_USB_GADGET_HUSB2DEV
== USB_GADGET_IMX ==
drivers/usb/gadget/gadget_chips.h:96:#ifdef CONFIG_USB_GADGET_IMX
== USB_GADGET_MPC8272 ==
drivers/usb/gadget/gadget_chips.h:122:#ifdef CONFIG_USB_GADGET_MPC8272
== USB_GADGET_MQ11XX ==
drivers/usb/gadget/gadget_chips.h:54:#ifdef CONFIG_USB_GADGET_MQ11XX
drivers/usb/gadget/ether.c:249:#ifdef CONFIG_USB_GADGET_MQ11XX
== USB_GADGET_MUSB_HDRC ==
drivers/usb/gadget/gadget_chips.h:116:#ifdef CONFIG_USB_GADGET_MUSB_HDRC
drivers/usb/gadget/ether.c:277:#ifdef CONFIG_USB_GADGET_MUSB_HDRC
== USB_GADGET_MUSBHSFC ==
drivers/usb/gadget/gadget_chips.h:109:#ifdef CONFIG_USB_GADGET_MUSBHSFC
drivers/usb/gadget/ether.c:273:#ifdef CONFIG_USB_GADGET_MUSBHSFC
== USB_GADGET_N9604 ==
drivers/usb/gadget/gadget_chips.h:66:#ifdef CONFIG_USB_GADGET_N9604
drivers/usb/gadget/ether.c:257:#ifdef CONFIG_USB_GADGET_N9604
== USB_GADGET_PXA27X ==
drivers/usb/gadget/gadget_chips.h:72:#ifdef CONFIG_USB_GADGET_PXA27X
drivers/usb/gadget/ether.c:261:#ifdef CONFIG_USB_GADGET_PXA27X
== USB_GADGET_S3C2410 ==
drivers/usb/gadget/gadget_chips.h:84:#ifdef CONFIG_USB_GADGET_S3C2410
drivers/usb/gadget/ether.c:265:#ifdef CONFIG_USB_GADGET_S3C2410
== USB_GADGET_SA1100 ==
drivers/usb/gadget/gadget_chips.h:42:#ifdef CONFIG_USB_GADGET_SA1100
drivers/usb/gadget/ether.c:300:#ifdef CONFIG_USB_GADGET_SA1100
== USB_GADGET_SH ==
drivers/usb/gadget/ether.c:296:#ifdef CONFIG_USB_GADGET_SH
== USB_GADGET_SUPERH ==
drivers/usb/gadget/gadget_chips.h:36:#ifdef CONFIG_USB_GADGET_SUPERH
== USB_SAFE_PADDED ==
drivers/usb/serial/safe_serial.c:77:#ifndef CONFIG_USB_SAFE_PADDED
drivers/usb/serial/safe_serial.c:78:#define CONFIG_USB_SAFE_PADDED 0
drivers/usb/serial/safe_serial.c:83:static int padded = CONFIG_USB_SAFE_PADDED;
== USB_SAFE_SERIAL_VENDOR ==
drivers/usb/serial/safe_serial.c:148:#if defined(CONFIG_USB_SAFE_SERIAL_VENDOR)
drivers/usb/serial/safe_serial.c:150:(CONFIG_USB_SAFE_SERIAL_VENDOR, 
CONFIG_USB_SAFE_SERIAL_PRODUCT, CDC_DEVICE_CLASS,

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page


-
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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[linux-usb-devel] 【 在宅で収入 基盤 】 「２０歳〜７０ 歳位まで」

[digital-j]

独占広告―



≪  パソコンを利用して、在宅での仕事に興味のある方　≫

「 空いた時間に　収入基盤を作りませんか？　」



募集要項
 　　 http://www.j-netshop.com/digital-j.html



 　　  ■空いた時間で、自宅から収入を希望される方
　　
　　　 ■今の仕事を続けながら無理なく独立開業を希望される方



　　　 ※未成年・学生は不可です。
　（今年の新卒者は資料請求までで卒業してからスタート）

　　　 ※インターネット・メール　レベルのパソコンスキル必須



　
を限定募集しております。(２００７年４月 先着４８名限定）
特別な能力や資格は必要ありません。【研修制度有】
　　
まじめで真剣な方を募集しております。
  　http://www.j-netshop.com/digital-j.html






---マガジン解除---

■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
  トへ投稿された方、無料投稿された方に配信させていただいております。
  投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
  します。解除につきましては、２日から３日程お時間を頂くこともござ
  いますのでご了承ください。

　　解除URL:http://formlan.com/form2/aoyama3/

■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
   確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
   責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
   ーム、損害等は当方では一切受け付けておりません。 
★━━★

─PR─　
┃オ┃ス┃ス┃メ┃　急な出費に素早く対応！　三菱東京UFJ銀行系 モビット
┗━┗━┗━┗━┻━━

　　　§ネットで24時間申込可能！コールセンター24時間対応だから安心§
　　　───

…┏━┓┏━━┓　　◆ご融資は1万円から最高300万円まで
…┗┓┃┃┏┓┃　　◆年利15.0-18.0％
……┃┃　　◆三菱東京UFJ銀行系だから安心
……┃┃┃┗┛┃
……┗┛┗━━┛秒で審査結果表示　『その場』でわかる！

　↓お申込はコチラ↓［入会金・年会費・ATM手数料無料］
　http://px.a8.net/svt/ejp?a8mat=6M66T+F467OY+1I6+626XV

　　　＊＊＊　いつでもどこでもキャッシング＆ご返済　＊＊＊

　　　お近くの銀行、コンビニなど全国68,000台の提携ATMでご利用可能
※三菱東京UFJ銀行、プロミス、セブンイレブン（セブン銀行）、
　その他の都市銀行、地方銀行、コンビニでも利用できるから便利！
───

　

★━━★
このご案内は、提携マガジン一般広告購読希望者様とDigital-j.netにご参加
頂いている方に送信させて頂いております。 

発行元　　：【K-NET】
　
E-Mail： [EMAIL PROTECTED]


-
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] 【 パソコンで 副収入 】 「２０歳〜７ ０歳位まで」

[digital-j]

独占広告―



「  あなたも、パソコンを利用して

　　　空いた時間に　収入基盤を作りませんか？　」


募集要項
 　　 http://www.j-netshop.com/digital-j.html



 　　  ■空いた時間で、自宅から収入を希望される方
　　
　　　 ■今の仕事を続けながら無理なく独立開業を希望される方



　　　 ※未成年・学生は不可
　（今年の新卒者は資料請求までで卒業してからスタート）

　　　 ※インターネット・メール　レベルのパソコンスキル必須



　
を限定募集しております。(２００７年４月 先着４８名限定）
特別な能力や資格は必要ありません。【研修制度有】
　　
まじめで真剣な方を募集しております。
  　http://www.j-netshop.com/digital-j.html






---マガジン解除---

■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
  トへ投稿された方、無料投稿された方に配信させていただいております。
  投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
  します。解除につきましては、２日から３日程お時間を頂くこともござ
  いますのでご了承ください。

　　解除URL:http://formlan.com/form2/aoyama3/

■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
   確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
   責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
   ーム、損害等は当方では一切受け付けておりません。 
★━━★

─PR─　
┃オ┃ス┃ス┃メ┃　急な出費に素早く対応！　三菱東京UFJ銀行系 モビット
┗━┗━┗━┗━┻━━

　　　§ネットで24時間申込可能！コールセンター24時間対応だから安心§
　　　───

…┏━┓┏━━┓　　◆ご融資は1万円から最高300万円まで
…┗┓┃┃┏┓┃　　◆年利15.0-18.0％
……┃┃　　◆三菱東京UFJ銀行系だから安心
……┃┃┃┗┛┃
……┗┛┗━━┛秒で審査結果表示　『その場』でわかる！

　↓お申込はコチラ↓［入会金・年会費・ATM手数料無料］
　http://px.a8.net/svt/ejp?a8mat=6M66T+F467OY+1I6+626XV

　　　＊＊＊　いつでもどこでもキャッシング＆ご返済　＊＊＊

　　　お近くの銀行、コンビニなど全国68,000台の提携ATMでご利用可能
※三菱東京UFJ銀行、プロミス、セブンイレブン（セブン銀行）、
　その他の都市銀行、地方銀行、コンビニでも利用できるから便利！
───

　

★━━★
このご案内は、提携マガジン一般広告購読希望者様とDigital-j.netにご参加
頂いている方に送信させて頂いております。 

発行元　　：【K-NET】
　
E-Mail： [EMAIL PROTECTED]


-
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] 【 自宅で 収入 】 メンバー募 集 ※１７期 残り５ 名

[digital-j]

独占広告━━━

　
　

　　　◆家のパソコンを利用して、収入を得たい方
　
　　　◆空いた時間を利用して副業したい方
　
　　　◆自由な時間を利用しておこづかいを稼ぎたい主婦の方




　　　   FSS　Home Office World Office inc.
  　  　　≪第１７期募集要項≫
   　 http://www.j-netshop.com/business.htm
　


　　※すでにアメリカとヨーロッパで成功しているシステムを
自宅のパソコンで、収入ツールとして利用してください。



　　　または、自宅で仕事をしたい方をご紹介下さい。
 　http://www.j-netshop.com/business.htm



　　　実際に収入を得られている方々（１５期までの方）の
　　　実際の声を参考にしていただけますので、
　　　不安な方は、安心して始められるかと思います。




--[PR]--
 フリーメール 【Eqqu】(エキュ)のご案内です。　　↓　　↓　　↓
 無料でメールアドレスが持てて実に便利です。http://www.eqqu.com/?Harbar
 ---

★━━★
このご案内は、提携マガジン一般広告購読希望者様とキャプテンーk.net
にご参加頂いているメンバー様に送信させて頂いております。 

発行元　　：【K-NET】
　
E-Mail： [EMAIL PROTECTED]

---マガジン解除と免責事項-

■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
  トへ投稿された方、無料投稿された方に配信させていただいております。
  投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
  します。解除につきましては、２日から３日程お時間を頂くこともござ
  いますのでご了承ください。

　　解除URL:http://formlan.com/form2/aoyama3/

■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
   確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
   責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
   ーム、損害等は当方では一切受け付けておりません。 
★━━★


--[PR]--
★☆★＿＿┌─┬─┬─┬─┬─┬─┬─┬─┬─┐★☆★
　　　話題の作るヨーグルト│ケ│フ│ィ│ア│ヨ│ー│グ│ル│ト│
★☆★￣￣└─┴─┴─┴─┴─┴─┴─┴─┴─┘★☆★
トライアルキット好評発売中！カナダ農場直輸入ピュアメープルシロップ付！
 http://ad.freeml.com/cgi-bin/ad.cgi?id=djYud
--[PR]--
■GMO GROUP■ Global Media Online  www.gmo.jp


-
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] 【自宅で収入】 メンバー募集※１７期 残 り８名

[digital-j]

独占広告━━━

　
　

　　　◆家のパソコンを利用して、収入を得たい方
　
　　　◆空いた時間を利用して副業したい方
　
　　　◆自由な時間を利用しておこづかいを稼ぎたい主婦の方




　　　   FSS　Home Office World Office inc.
  　  　　≪第１７期募集要項≫
   　 http://www.j-netshop.com/business.htm
　


　　※すでにアメリカとヨーロッパで成功しているシステムを
自宅のパソコンで、収入ツールとして利用してください。



　　　または、自宅で仕事をしたい方をご紹介下さい。
 　http://www.j-netshop.com/business.htm



　　　先に参加された方々が、実際に収入を得ておりますので、
　　　不安な方は、安心して始められるかと思います。




--[PR]--
 フリーメール 【Eqqu】(エキュ)のご案内です。　　↓　　↓　　↓
 無料でメールアドレスが持てて実に便利です。http://www.eqqu.com/?Harbar
 ---

★━━★
このご案内は、提携マガジン一般広告購読希望者様とキャプテンーk.net
にご参加頂いているメンバー様に送信させて頂いております。 

発行元　　：【K-NET】
　
E-Mail： [EMAIL PROTECTED]

---マガジン解除と免責事項-

■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
  トへ投稿された方、無料投稿された方に配信させていただいております。
  投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
  します。解除につきましては、２日から３日程お時間を頂くこともござ
  いますのでご了承ください。

　　解除URL:http://formlan.com/form2/aoyama3/

■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
   確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
   責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
   ーム、損害等は当方では一切受け付けておりません。 
★━━★


--[PR]--
★☆★＿＿┌─┬─┬─┬─┬─┬─┬─┬─┬─┐★☆★
　　　話題の作るヨーグルト│ケ│フ│ィ│ア│ヨ│ー│グ│ル│ト│
★☆★￣￣└─┴─┴─┴─┴─┴─┴─┴─┴─┘★☆★
トライアルキット好評発売中！カナダ農場直輸入ピュアメープルシロップ付！
 http://ad.freeml.com/cgi-bin/ad.cgi?id=djYud
--[PR]--
■GMO GROUP■ Global Media Online  www.gmo.jp


-
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] pl2303 usb serial - bad tty numbers starting at 2.6.20-git3

[Adam J. Richter]

On Sat, 3 Mar 2007 08:24:00 +0100, Oliver Neukum wrote:
Am Freitag, 2. März 2007 22:12 schrieb Adam J. Richter:
  When I plug in a pl2303-based usb serial device, the device is
 supposed to appear as /dev/tts/USB0 (character device 188, 0).
 However, under kernels that I have tried from 2.6.20-git3 through
 2.6.21-rc2-git1, /dev/tts/USBsome-random-number is created, [...]

Please try this patch. It is needed in any case and it may be your problem's
cause.

   Regards
   Oliver

--- linux-2.6.21-rc1/drivers/usb/serial/usb-serial.c.alt   2007-02-21 
05:32:30.0 +0100
+++ linux-2.6.21-rc1/drivers/usb/serial/usb-serial.c   2007-02-26 
15:32:50.0 +0100
@@ -826,7 +826,6 @@
   num_ports = type-num_ports;
   }
 
-  serial-minor = minor;
   serial-num_ports = num_ports;
   serial-num_bulk_in = num_bulk_in;
   serial-num_bulk_out = num_bulk_out;
@@ -980,6 +979,7 @@
   dev_err(interface-dev, No more free serial devices\n);
   goto probe_error;
   }
+  serial-minor = minor;
 
   /* register all of the individual ports with the driver core */
   for (i = 0; i  num_ports; ++i) {


I tried your patch on 2.6.21-rc2-git1, and it fixed my
problem.  Thank you!

Adam Richter

-
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] plx2303 usb serial - bad tty numbers starting at 2.6.20-git3

[Adam J. Richter]

When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USBsome-random-number is created, and
attempting to open that file returns a no such device error.  I have
not seen that random number exceed 256, by the way.  Doing mknod
/dev/tts/USB0 c 188 0 and then opening that file resulted kernel oops
on the one kernel version on which I tried it (I think around
2.6.20-git11).

I remember seeing almost exactly these symptoms a few years
ago.

I imagine that this is some kind of tty unit number not be
initialized, so I guess it's worth mentioning that all of the USB
things in my configuration are built as loadable modules.

   Here is a list of the kernels that I have tried, and the results:

2.6.20  OK
2.6.20-git1 OK
2.6.20-git2 OK
2.6.20-git3 fail
2.6.20-git7 fail
2.6.20-git11fail
2.6.21-rc1  fail
2.6.21-rc2-git1 fail

There are moderate to substantial changes to
drivers/usb/serial/usb-serial.c in 2.6.20-git3, and only a couple of
innocuous looking lines changed in linux/usb/serial/.  I will be
investigating the usb-serial.c changes, if nobody beats me to a fix,
although the time that I can put into this may be rather limited over
the next few days.

Adam Richter

-
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] pl2303 usb serial - bad tty numbers starting at 2.6.20-git3

[Adam J. Richter]

When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USBsome-random-number is created, and
attempting to open that file returns a no such device error.  I have
not seen that random number exceed 256, by the way.  Doing mknod
/dev/tts/USB0 c 188 0 and then opening that file resulted kernel oops
on the one kernel version on which I tried it (I think around
2.6.20-git11).

I remember seeing almost exactly these symptoms a few years
ago.

I imagine that this is some kind of tty unit number not be
initialized, so I guess it's worth mentioning that all of the USB
things in my configuration are built as loadable modules.

   Here is a list of the kernels that I have tried, and the results:

2.6.20  OK
2.6.20-git1 OK
2.6.20-git2 OK
2.6.20-git3 fail
2.6.20-git7 fail
2.6.20-git11fail
2.6.21-rc1  fail
2.6.21-rc2-git1 fail

There are moderate to substantial changes to
drivers/usb/serial/usb-serial.c in 2.6.20-git3, and only a couple of
innocuous looking lines changed in linux/usb/serial/.  I will be
investigating the usb-serial.c changes, if nobody beats me to a fix,
although the time that I can put into this may be rather limited over
the next few days.

Adam Richter

-
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] 【 パソコンで 副収入 】 「２０歳〜７ ０歳位まで」

[digital-j]

独占広告―



「  あなたも、パソコンを利用して

　　　空いた時間に　収入基盤を作りませんか？　」


募集要項
 　　 http://www.j-netshop.com/digital-j.html



 　　  ■空いた時間で、自宅から収入を希望される方
　　
　　　 ■今の仕事を続けながら無理なく独立開業を希望される方



　　　 ※未成年・学生は不可
　（今年の新卒者は資料請求までで卒業してからスタート）

　　　 ※インターネット・メール　レベルのパソコンスキル必須



　
を限定募集しております。(２００７年２月 先着２４名限定）
特別な能力や資格は必要ありません。【研修制度有】
　　
まじめで真剣な方を募集しております。
  　http://www.j-netshop.com/digital-j.html






---マガジン解除---

■メールマガジンの購読、解除について当メールマガジンは一括投稿サイ
  トへ投稿された方、無料投稿された方に配信させていただいております。
  投稿または登録した覚えのない方は、お手数ですが下記のURLよりお願い
  します。解除につきましては、２日から３日程お時間を頂くこともござ
  いますのでご了承ください。

　　解除URL:http://formlan.com/form2/aoyama3/

■免責事項とお願いお客様ご依頼のＰＲ本文中に含まれるＨＰ情報等は、
   確認の上掲載しておりますが、トラブルが発生した場合、当方では一切の
   責任は負いかねます。ＰＲ投稿本文やＨＰリンクの内容等についてのクレ
   ーム、損害等は当方では一切受け付けておりません。 
★━━★

─PR─　
┃オ┃ス┃ス┃メ┃　急な出費に素早く対応！　三菱東京UFJ銀行系 モビット
┗━┗━┗━┗━┻━━

　　　§ネットで24時間申込可能！コールセンター24時間対応だから安心§
　　　───

…┏━┓┏━━┓　　◆ご融資は1万円から最高300万円まで
…┗┓┃┃┏┓┃　　◆年利15.0-18.0％
……┃┃　　◆三菱東京UFJ銀行系だから安心
……┃┃┃┗┛┃
……┗┛┗━━┛秒で審査結果表示　『その場』でわかる！

　↓お申込はコチラ↓［入会金・年会費・ATM手数料無料］
　http://px.a8.net/svt/ejp?a8mat=6M66T+F467OY+1I6+626XV

　　　＊＊＊　いつでもどこでもキャッシング＆ご返済　＊＊＊

　　　お近くの銀行、コンビニなど全国68,000台の提携ATMでご利用可能
※三菱東京UFJ銀行、プロミス、セブンイレブン（セブン銀行）、
　その他の都市銀行、地方銀行、コンビニでも利用できるから便利！
───

　

★━━★
このご案内は、提携マガジン一般広告購読希望者様とDigital-j.netにご参加
頂いている方に送信させて頂いております。 

発行元　　：【K-NET】
　
E-Mail： [EMAIL PROTECTED]


-
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] testing of fixes for race conditions in usb serial driver #0

[J]

Hi,

During the last few days me and Oliver Neukum
exchanged some messages about fixing the usb-serial.c.
We came to an agreement and I made a patch
(which should be applied after 3 patches, which
were posted by Oliver on 1/2/07 at
linux-usb-devel@lists.sourceforge.net)

We agreed that usb-serial had the following errors:
1) serial table is not protected by locks. 
kref_get() may be called on freed memory
2) probe() exposes uninitialized devices
3) disconnect() does not make sure there's no more IO
to unbound devices
4) try_module_get() is called with unprotected
pointers
5) there's a race between write() and disconnect()

Oliver fixed most of these issues in 1/2/07 patch.

After that I also fixed in the following errors:

6) pointers in serial_table were not ref-counted,
that is when a pointer was copied to serial_table,
ref count was not incremented, which resulted
in ref count reaching 0 while there were still
pointers in serial_table and serial_open taking
an invalid pointer from there.

The solution to that is to add kref_get to
get_free_serial:
+  kref_get(serial-kref);
  serial_table[i] = serial;

and usb_serial_put to return_serial:
  serial_table[serial-minor + i] = NULL;
+ usb_serial_put(serial);

7) serial-type-shutdown called from destroy_serial,
which may be called after usb_serial_disconnect
already
exited, which means that client drivers have no
way to kill outstanding URBs before
usb_serial_disconnect exists, which 
means that IO
may continue when it should not.

The solution to this is to add the following variables
to usb_serial structure:
 spinlock_t  lock;
 intlock_count;
 intshutdown_called;
 wait_queue_head_t shutdown_wait;

and provide routines serial_lock and serial_unlock
to be called by every serial_* routine
before and after using serial pointer.

Also routine serial_lock_and_wait_before_shutdown
to be called from usb_serial_disconnect
to block it until all serial_* routines finish
using serial pointer.

Then usb_serial_disconnect calls
serial-type-shutdown,
which I moved back from destroy_serial.

I attached my patches, which should be applied
after 3 Oliver's patches.

Please, comment.

Thank you
John


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

usb-serial.c_20070104.diff
Description: 4284928108-usb-serial.c_20070104.diff


serial.h_20070104.diff
Description: 827676511-serial.h_20070104.diff
-
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] testing of fixes for race conditions in usb serial driver #1

[J]

Hi,
Sorry, I don't see how table_lock will fix the
original problem, which I reported (race between
serial_open and  usb_serial_disconnect). I copied my
original sequence of events below and I don't think
that the proposed
table_lock will change anything.

As I wrote before, the error is that usb-serial 
does not use ref counting consistently because 
it does not count every outstanding pointer.
Specifically, it does not count pointers in
serial_table. This means that when 
usb_serial_disconnect calls usb_serial_put,
ref count will go to 0 and object deleted.
At the same time (but before call to return_serial)
serial_open will call usb_serial_get_by_index and
increment the ref count from 0 to 1 
(which should never happen if ref counting is
implemented correctly).

Please, tell me is I am wrong.

Another think I wanted to clarify is whether it is
safe to call serial-type-shutdown after
usb_serial_disconnect already returned.
You wrote that it is OK to call usb_kill_urb count,
but it is not OK to do any IO. 

So, if we continue to call serial-type-shutdown
after disconnect, how can we ensure that client
serial usb drivers do not call any IO?
Are there any documented rules for what clients
are supposed to call and when?

I feel that it would be beneficial to ensure that
shutdown is always called within disconnect
to simplify task of client driver writers.
This, however, will require diconnect to wait on
a semaphore to ensure that all serial_* operations
finished.

What do you think?

Thank you
John

This is the copy of my original race sequence:
A:-usb_serial_disconnect
A: - usb_serial_put (serial);
A: - kref_put
A: if ((atomic_read(kref-refcount) == 1)
Suppose refcount is 1
A: - release - destroy_serial

B: - serial_open
B: - usb_serial_get_by_index
B: serial = serial_table[index]
B: - kref_get(serial-kref);

A: - return_serial(serial);
A: serial_table[serial-minor + i] = NULL;
A: - kfree (serial);

B: continue to use serial, which was already freed.



--- Oliver Neukum [EMAIL PROTECTED] wrote:

 Hi,
 
 this fixes:
 
 1) serial table is not protected by locks.
 kref_get() may be called on freed memory
 2) probe() exposes uninitialized devices
 3) disconnect() does not make sure there's no more
 IO to unbound devices
 
 Please test. It's against 2.6.20-rc3 but should
 apply widely.
 
   Regards
   Oliver
  --- a/drivers/usb/serial/usb-serial.c   2007-01-01
 01:53:20.0 +0100
 +++ b/drivers/usb/serial/usb-serial.c 2007-01-02
 10:44:08.0 +0100
 @@ -59,14 +59,19 @@
  
  static int debug;
  static struct usb_serial
 *serial_table[SERIAL_TTY_MINORS]; /* initially all
 NULL */
 +static spinlock_t table_lock;
  static LIST_HEAD(usb_serial_driver_list);
  
  struct usb_serial *usb_serial_get_by_index(unsigned
 index)
  {
 - struct usb_serial *serial = serial_table[index];
 + struct usb_serial *serial;
 +
 + spin_lock(table_lock);
 + serial = serial_table[index];
  
   if (serial)
   kref_get(serial-kref);
 + spin_unlock(table_lock);
   return serial;
  }
  
 @@ -78,6 +83,7 @@
   dbg(%s %d, __FUNCTION__, num_ports);
  
   *minor = 0;
 + spin_lock(table_lock);
   for (i = 0; i  SERIAL_TTY_MINORS; ++i) {
   if (serial_table[i])
   continue;
 @@ -96,8 +102,10 @@
   dbg(%s - minor base = %d, __FUNCTION__,
 *minor);
   for (i = *minor; (i  (*minor + num_ports))  (i
  SERIAL_TTY_MINORS); ++i)
   serial_table[i] = serial;
 + spin_unlock(table_lock);
   return serial;
   }
 + spin_unlock(table_lock);
   return NULL;
  }
  
 @@ -110,9 +118,11 @@
   if (serial == NULL)
   return;
  
 + spin_lock(serial_table);
   for (i = 0; i  serial-num_ports; ++i) {
   serial_table[serial-minor + i] = NULL;
   }
 + spin_unlock(serial_table);
  }
  
  static void destroy_serial(struct kref *kref)
 @@ -559,15 +569,20 @@
   port_free(port);
  }
  
 -static void port_free(struct usb_serial_port *port)
 +static void kill_traffic(struct usb_serial_port
 *port)
  {
   usb_kill_urb(port-read_urb);
 - usb_free_urb(port-read_urb);
   usb_kill_urb(port-write_urb);
 - usb_free_urb(port-write_urb);
   usb_kill_urb(port-interrupt_in_urb);
 - usb_free_urb(port-interrupt_in_urb);
   usb_kill_urb(port-interrupt_out_urb);
 +}
 +
 +static void port_free(struct usb_serial_port *port)
 +{
 + kill_traffic(port);
 + usb_free_urb(port-read_urb);
 + usb_free_urb(port-write_urb);
 + usb_free_urb(port-interrupt_in_urb);
   usb_free_urb(port-interrupt_out_urb);
   kfree(port-bulk_in_buffer);
   kfree(port-bulk_out_buffer);
 @@ -771,12 +786,6 @@
   num_ports = type-num_ports;
   }
  
 - if (get_free_serial (serial, num_ports, minor) ==
 NULL) {
 - dev_err(interface-dev, No more free serial
 devices\n);
 - kfree 

Re: [linux-usb-devel] Possible race condition in usb-serial.c

[J]

 This problem will need some deeper surgery probably
 involving
 removal of the refcounting.

Refcounting may be OK if used consistently. 
It is not OK when some pointers are ref-counted, 
but other (in serial_table) are not (like it is
in the current version).

As for the deeper surgery, what do you think about my
earlier suggestion to start by rewriting
usb_serial_probe
to fully initialize usb_serial before it is added to 
serial_table? 

So, instead of the current:
1. create_serial
...
2. mutex_lock(table_lock);
3. get_free_serial (which inserts serial to
serial_table)
...
4. initializes serial
5. mutex_unlock(table_lock);

we will get:

1. create_serial
2. initializes serial

3. add_serial_toserial_table  (with internal mutex
lock if needed)

Similar approach should be used in other places to
minimize the code executed under the mutex.

John

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

   if (!port || port-serial-dev-state ==
 USB_STATE_NOTATTACHED)

 There's no use checking for attachement. The state
 may have changed.
 In fact, if a device is disconnected via sysfs, this
 code will happily write
 to a device somebody else has claimed.

I don't understand. serial-dev is usb_device*
and it is protected by ref counting (using
usb_get_dev).
So, it should not disappear or be claimed by
anybody else, right?

As for the USB_STATE_NOTATTACHED, there is a long
comment in hub.c about it. Also I see plenty of
code, which checks it without any lock.
So, I guess, it should not kill anybody.

John



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

OK, if I got you right, usb-serial is not supposed to
access any USB stuff after usb_serial_disconnect
because device to driver association is already broken
(even if usb_device structure is still 
in memory by means of ref counting),


In fact, I just noticed the following comment
(in usb_get_dev):

 * usb_get_dev - increments the reference count of the
usb device structure
 * @dev: the device being referenced
 *
 * Each live reference to a device should be
refcounted.
 *
 * Drivers for USB interfaces should normally record
such references in
 * their probe() methods, when they bind to an
interface, and release
 * them by calling usb_put_dev(), in their
disconnect() methods.

But usb-serial.c breaks this rule because it calls
usb_put_dev not in usb_serial_disconnect, but in 
destroy_serial. destroy_serial is usually called
from usb_serial_disconnect except in case of
the serial_open/usb_serial_disconnect race condition.

So, this seems to prove that we cannot simply
ref-count usb_serial and execute destroy_serial
after usb_serial_disconnect already returned.

This means that usb_serial_disconnect have to wait
on serial_open and any other serial_* functions
to finish. And the body of destroy_serial
(or at least, most of it)
should be returned back to usb_serial_disconnect

Am I right this time?

John



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

 No, this is a fundamental problem. You don't
 refcount
 a pointer, you refcount a data structure.
 But this is insufficient. We need to make 
 sure the pointer points to valid memory.

I understand. But a typical definition of ref-count 
requires the count in the data structure to be
equal to the number of outstanding pointers to this
data structure.
Every time we create a new pointer, the ref count
should be incremented. When pointer is erased, count
is decremented. 
This is what I meant as ref counting a pointer.
If we follow this rule, then each pointer will
always point to a valid memory.

So, if we apply ref counting rules consistently,
then each pointer in serial_table should be
ref counted. This will completely break the current
code, which erases serial_table from destroy_serial,
which is called only when the ref count goes to 0,
which will never happen if serial_table is ref
counted.
However, this can be fixed if usb_serial_disconnect
will erase pointers in serial_table before
calling usb_serial_put.

Now, I am not yet 100% convinced that ref counting
will, indeed, work. Atomics are known to have
problems on SMP CPUs, which can reorder operations.
But I would not discard atomics yet.
Global mutex is go ugly.

John


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

Apparently, my earlier reply was lost, trying again:

 2. You must not do IO after returning from
 disconnect

Does usb_kill_urb count as IO?
Many drivers call it from their shutdown routines,
which may be called after disconnect.


 It is perfectly valid to do (in pseudocode)
 
 disconnect:
 lock()
 device-disconnect_flag = 1;
 unlock()
 rest()
 put()
 
 io-method:
 lock()
 if (device-disconnect_flag)
  goto err_no_dev;
 io()
 unlock()
 

Yes, this is similar to the mutex, which you added in
your earlier patch. My concern is that calling
external functions, such as shutdown, may cause
a deadlock if any of them will synchronize with TTY
stack. 

I think that safer way to use a lock or a mutex
is to protect short pieces of code, such as 
usb_serial_get_by_index or get_free_serial.

John



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

 Please send in a patch for 2.4. It's very important
 to have a
 very reliable ultraconservative tested kernel
 available.

I will try later. I am new to Linux driver development
and never submitted any patches before.
Also I am not yet 100% sure about the correct way
to solve this issue. I will have to study more.

 I suppose the last time I looked at that code, khubd
 still took BKL. Or I overlooked the race. 

Well, as I already mentioned, BKL/lock_kernel appears
to be completely compiled out of my build, so it is
no help for me.
Also, in my opinion, if usb-serial.c depends on
other modules for synchronization, it should have
a big warning in large font about this, otherwise
bugs are doomed to happen. Or, better yet,
it should have it's own proper synchronization
(as we are trying to come up with now).

 
 Look closer. If you build with preemption, taking
 BKL disables preemption.
 BKL is effective only until you schedule. On UP,
 without preemption
 ordinary kernel code will not reenter. You need no
 lock that doesn't guard
 against interrupts unless you schedule under these
 narrow conditions.

In my old 2.4 build CONFIG_SMP is not defined and,
therefore, lock_kernel is compiled out.
I am not sure about the definition of
CONFIG_LOCK_KERNEL in 2.6.
I tried googling for it, but it brings tons of junk.
 
 Could you test the attached patch against 2.6?

Alas, I only have an old 2.4 right now.
May be I will install 2.6 later (in few weeks).
Currently I am just trying to read 2.6 code with my
eyes.

I studied the patch, which you sent.
I don't see obvious errors, but, in my opinion, it is
not completely perfect.

This attempt to mix ref counting and mutex just does
not look right. For example, in few places you
wrap call to usb_serial_put (which decrements ref
count) with the mutex:

 mutex_lock(table_lock);
 usb_serial_put(port-serial);
 mutex_unlock(table_lock);

But in other cases it is called without any mutex.

Also there is a theoretical possibility of a deadlock
because some external functions are called when
the mutex is held
(such as serial-type-shutdown, device_unregister,
usb_put_dev, tty_hangup, etc).

What if these functions will call some TTY routines,
which will somehow synchronize with serial_open?
So, for example, usb_serial_disconnect will wait for 
tty_hangup, which will wait for serial_open,
which waits for usb_serial_disconnect.
Now, I see that in the current 2.6 tty_hangup simply
calls schedule_work, but it may change in the future.
And I don't have time to examine what various shutdown
routines in all the driver do.


So, I don't see a quick solution for this.
I guess, a cleaner way would be to modify the code,
which creates and deletes usb_serial structure.
In particular, currently usb_serial_probe is written
as:
create_serial
...
get_free_serial (which inserts serial to serial_table)
...
initializes serial

As the result a partially initialized serial is
inserted into the table. As the result you had to
lock almost the whole body of usb_serial_probe with
table_lock, which may lead to deadlocks.

It would be cleaner to allocate and fully initialize
usb_serial before inserting it into the table in 
one quick call under mutex (or using atomics).

However, I am not very familiar yet with this code,
so I may be wrong.

John


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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] Possible race condition in usb-serial.c

[J]

Thank you for your reply.

 Which usb-serial driver are you having problems
 with?  What is the oops trace?  
 What version of the 2.4 kernel are you using?

I was told to fix an old embedded device, which my
company bought from somebody many years ago. 
It appears to have kernel 2.4.9 and a patched version
of visor.c.

However, I would't bother you with my antiquated
setup. I posted this message only when I started
to think that 2.6 may have race conditions as well.

And I don't have any oops. All I have is a monitor
with 30 lines worse of printk messages. This is
enough,
however, to discover races if printk are in the right
places.

 And why are you taking the linux-usb-devel list out
 of the cc:?  :)

This is because it is my first post on linux.kernel.
I spent time reading FAQs on http://www.tux.org/lkml/.
It wastes many pages explaining netiquette, but does
not really explain how to post other then 
send to linux-kernel@vger.kernel.org. That's what I
did.

Thank you
John

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[linux-usb-devel] Fwd: USB device not getting detected.

[Jinesh K J]

-- Forwarded message --
From: pankaj chauhan [EMAIL PROTECTED]
Date: Sep 18, 2006 7:31 PM
Subject: USB device not getting detected.
To: [EMAIL PROTECTED]


hi all,

i am using 2.6.11, and EHCI HCD. during boot up i get
following message:

usb 1-0:1.0: over-current change on port 1

and after the system is up none of the USB device
connected to USB port are detected.

can you please tell me what over-current change mean.
and Is this error responsible for my device not
getting detected.

Thanks
PC

Vision without action is merely a dream, action without vision is
wastage of time, vision and action together can change the world 



__
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:   http://mail.nl.linux.org/kernelnewbies/
FAQ:   http://kernelnewbies.org/faq/

-
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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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

[Rafael J. Wysocki]

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] system hang when working with 32 devices connected to single root hub port

[Jinesh K J]

On 6/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hi,

hi,

 I am working on an tool which is used for end to end testing of a
 telephone network. As a part of the tool, we have mobiles connected to
 the system (with kernel-2.6.16.13). The mobiles(CDC devices) being used
 are USB 2.0 full speed devices and are connected to the system using USB
 2.0 high speed hubs. The device driver used to communicate to the
 mobiles is generic usb-serial driver. A maximum of 32 mobiles are
 connected to one root hub(UHCI port) using hubs.

 One of the basic tests performed using this application is continuous
 power-on/power-off of the mobiles for 200 cycles. From the application,
 AT commands(for power-on and power-off) are passed to the mobile through
 the generic usb serial driver. When this testing is in progress,
 suddenly system got hanged. We could not see any pointer for the system
 hang, from the logs(/var/log/messages). Till the point of time the
 system got hanged, everything seems to be normal from the logs. And as
 the system got hanged, the logging stopped suddenly.

is it your system or just the program that got hanged? since your
kernel is pre-emptible, there should be something really wrong going
on to hang your system completely. may be u should try enabling the
magic sysrq and use its SAK command. if there is any kernel oops, you
can also get the call trace which would be very nice.

also, since you've got oprofile enabled, if you could get back to a
normal system, you can analyse the dump of the collected statistics to
understand where your system was wandering during the hang period.

BTW, it'd be nice to post the relevant portions of your program source code too.

 What could be the reason for this behavior? Please find attached the
 .config file. Should I have to enable any debug options which may help
 to locate the pointer for system hang?
 Please let me know if any further information is required. Please share
 your experience.


jinesh.

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] boot from usb again

[Jinesh K J]

On 6/20/06, Ken Cobler [EMAIL PROTECTED] wrote:
 Wojciech Kromer wrote:
  Dnia 2006-06-19 13:13, Użytkownik Jinesh K J napisał:
 
  On 6/19/06, Wojciech Kromer [EMAIL PROTECTED] wrote:
 
 
  After reading lot of discusions on this issue, I can't still get
  why there is an error booting from root=/dev/sda1 or even root=8:1.
 
 
  Please append a correct root= boot option
  Kernel panic - not syncing: VFS: Unable to mount root fs on
  unknown-block(2,0)
 
  ^^^ Same error with root=8:1
 
 
  and I can mount it after booting  the same kernel from network.
 
 
 
  what does that mean?
 
 
 
 
  The same kernel (binary the same, and no modules loaded) can be loaded
  via network boot, and mounting my usb-storage device is possible.

  From the looks of your posting, the issue is not that you cannot boot
 from a USB device, but, rather you cannot mount the root filesystem when
 the filesystem is on a USB device.

 I think this issue comes from that fact that even though you have SCSI
 emulation for USB devices built into the kernel, the USB device is not
 registered with the kernel at the time when the root filesystem needs to
 be mounted.  Thus, the root filesystem mount fails.

 To get around this problem, I've solved it by building a ramdisk for the
 root filesystem.  Boot off the USB device, mount the ramdisk (initrd) as
 the root filesystem.

 Once the ramdisk is mounted, you can then mount the USB device or the
 hard drive.

 Don't forget to add some basic commands to your ramdisk image.


cool solution. remember that the initrd image is just a gzipped cpio
archive. just extract an already existing one and modify the init file
in it. add your modules. and rebuild the initrd out of it.

i hope i'm right...

best of luck...

___
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] boot from usb again

[Jinesh K J]

On 6/19/06, Wojciech Kromer [EMAIL PROTECTED] wrote:
 After reading lot of discusions on this issue, I can't still get
 why there is an error booting from root=/dev/sda1 or even root=8:1.

so, what is the error shown? i hope usb-storage module is built into the kernel!

 and I can mount it after booting  the same kernel from network.

what does that mean?


___
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] platform_device.dev.release not getting called under X Windows

[Jinesh K J]

hi,

are u using printk() for tracing the function calls. then it might
happen that xterm is just not displaying the output. i'm not familiar
with pcmcia, so please forgive me for any foolish comments.

On 6/9/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Hi all,

 We are developing a device driver for a PCMCIA based USB Host
 Controller.
 We are facing an issue in the operation of the driver under X Windows.

 In the PCMCIA client driver, we register a platform device.
 Through this platform device, we are passing the resources to the Host
 Controller Driver.
 The HCD is using these resources for driving the Host Controller.

 The issue arises for the following situation under X Windows.
 1. Insert a USB mass storage device
 2. Mount the device.
 3. While transfer is in progress, remove the PC card.

 In this situation, we have noted that the platform_device.dev.release
 function is not getting called.
 If we do not mount the device, then the release function is getting
 called.
 Can anyone please tell why this may be happening?

 When we operate from console, we are not facing the issue.
 In that case the release function is getting called properly.

ie, it gets called whether the device is mounted or not. right?

 Then does the issue have anything to do with X Windows?

BTW, i didn't understand what u meant by operating from console. what
are u operating. did u mean to say when not running X server?
normally X server should in no way affect the functioning of a device
driver.


___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel