Re: [linux-usb-devel] [usb-storage] schedule_timeout: wrong timeout value c1a95554
On Thursday, 9 August 2007 17:20, Mariusz Kozlowski wrote:
> > > > Happens every time I reattach usb pen drive.
> > > >
> > > > usb 1-2: new high speed USB device using ehci_hcd and address 10
> > > > usb 1-2: configuration #1 chosen from 1 choice
> > > > scsi6 : SCSI emulation for USB Mass Storage devices
> > > > usb 1-2: new device found, idVendor=13fe, idProduct=1a00
> > > > usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
> > > > usb 1-2: Product: GEIL USB DISK
> > > > usb 1-2: Manufacturer:
> > > > usb-storage: device found at 10
> > > > usb-storage: waiting for device to settle before scanning
> > > > schedule_timeout: wrong timeout value c1a95554
> > > > [] show_trace_log_lvl+0x1a/0x30
> > > > [] show_trace+0x12/0x14
> > > > [] dump_stack+0x15/0x17
> > > > [] schedule_timeout+0x8c/0xa2
> > > > [] usb_stor_scan_thread+0x100/0x160
> > > > [] kthread+0x36/0x58
> > > > [] kernel_thread_helper+0x7/0x14
> > > > ===
> > > > scsi 6:0:0:0: Direct-Access GEIL USB DISK>2.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-kernel&m=118641424414399&w=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; \
Re: [linux-usb-devel] [usb-storage] schedule_timeout: wrong timeout value c1a95554
On Thursday, 9 August 2007 16:43, Alan Stern wrote:
> On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
>
> > Hello,
> >
> > Happens every time I reattach usb pen drive.
> >
> > usb 1-2: new high speed USB device using ehci_hcd and address 10
> > usb 1-2: configuration #1 chosen from 1 choice
> > scsi6 : SCSI emulation for USB Mass Storage devices
> > usb 1-2: new device found, idVendor=13fe, idProduct=1a00
> > usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0
> > usb 1-2: Product: GEIL USB DISK
> > usb 1-2: Manufacturer:
> > usb-storage: device found at 10
> > usb-storage: waiting for device to settle before scanning
> > schedule_timeout: wrong timeout value c1a95554
> > [] show_trace_log_lvl+0x1a/0x30
> > [] show_trace+0x12/0x14
> > [] dump_stack+0x15/0x17
> > [] schedule_timeout+0x8c/0xa2
> > [] usb_stor_scan_thread+0x100/0x160
> > [] kthread+0x36/0x58
> > [] kernel_thread_helper+0x7/0x14
> > ===
> > scsi 6:0:0:0: Direct-Access GEIL USB DISK>2.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-kernel&m=118641424414399&w=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-d
[linux-usb-devel] [PATCH] Remove dead references to "SAFE_SERIAL" CONFIG variables.
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
Re: [linux-usb-devel] [PATCH][RFC] make config vars uniformly "SAFE_SERIAL"
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][RFC] make config vars uniformly "SAFE_SERIAL"
rial/safe_serial.c +++ b/drivers/usb/serial/safe_serial.c @@ -74,13 +74,13 @@ #include -#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
[linux-usb-devel] [PATCH] USB: Typo: "USB_SAFE_PADDED" -> "USB_SERIAL_SAFE_PADDED".
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 -#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
Re: [linux-usb-devel] undefined USB-related CONFIG variables
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
[linux-usb-devel] "SERIAL_SAFE" versus "SAFE_SERIAL"
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
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] undefined USB-related CONFIG variables
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] Volunteer to be the new usb.ids maintainer!!
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] Volunteer to be the new usb.ids maintainer!!
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] [2.6.22-rc7] khubd NULL deref oops...
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 sdb6<6>usb 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]
On Thursday, 21 June 2007 21:39, Alan Stern wrote: > On Thu, 21 Jun 2007, Rafael J. Wysocki wrote: > > > > I'll see if I can reproduce your problem here. > > > > Yes, I can. It's only necessary to load usb-storage (without any devices > > actually using it) and it fails device_suspend() immediately (I don't think > > it's freezer-related). > > > > I've got the following trace from it: > > > > usb_endpoint usbdev3.2_ep81: PM: suspend 0->1, parent 3-1:1.0 already 2 > > Suspending device 3-1:1.0 > > Suspending device usbdev3.2_ep00 > > Suspending device 3-1 > > Suspending device eth1 > > Suspending device eth0 > > Suspending device usbdev3.1 > > Suspending device usbdev3.1_ep81 > > Suspending device 3-0:1.0 > > Suspending device usbdev3.1_ep00 > > Suspending device usb3 > > hub 3-0:1.0: hub_suspend > > ohci_hcd :00:02.1: needs reinit! > > usb usb3: suspend fail, err -16 > > usb usb3: 'global' suspend -16 > > hub 3-0:1.0: hub_resume > > hub 3-0:1.0: activate --> -108 > > suspend_device(): usb_suspend+0x0/0x30() returns -16 > > Could not suspend device usb3: error -16 > > WARNING: at > > /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 > > usb_submit_urb() > > Well, a large part of the problem is that > > usb-try-to-debug-bug-8561.patch > > hasn't been reverted in 2.6.22-rc4-mm2. Yes, the problem is not present after reverting this patch. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On 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 ... <3>hub 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] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 22:50, Rafael J. Wysocki wrote: > On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote: > > On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: > > > On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: > > > > On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > > > > > > > > Hello, > > > > on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting > > > > is becoming troublesome as different sets have slightly different > > > > problems. > > > > At one point (with the GREGKH usb stuff built) I had the kernel > > > > reporting it cannot stop the usb-storage thread so I guess that > > > > something later in the series made things worse (freezable workqueues?). > > > > > > > > Clues? > > > > > > Can you please try 2.6.22-rc5 with the patches from > > > > > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ > > > > > > applied. That should allow us to eliminate some suspects. ;-) > > > > you're safe then! .22-rc5 + your suspend patch-set can suspend and > > resume happily. > > OK, thanks. OTOH, that would have been less patches to check ... ;-) > > I'll see if I can reproduce your problem here. Yes, I can. It's only necessary to load usb-storage (without any devices actually using it) and it fails device_suspend() immediately (I don't think it's freezer-related). I've got the following trace from it: usb_endpoint usbdev3.2_ep81: PM: suspend 0->1, parent 3-1:1.0 already 2 Suspending device 3-1:1.0 Suspending device usbdev3.2_ep00 Suspending device 3-1 Suspending device eth1 Suspending device eth0 Suspending device usbdev3.1 Suspending device usbdev3.1_ep81 Suspending device 3-0:1.0 Suspending device usbdev3.1_ep00 Suspending device usb3 hub 3-0:1.0: hub_suspend ohci_hcd :00:02.1: needs reinit! usb usb3: suspend fail, err -16 usb usb3: 'global' suspend -16 hub 3-0:1.0: hub_resume hub 3-0:1.0: activate --> -108 suspend_device(): usb_suspend+0x0/0x30() returns -16 Could not suspend device usb3: error -16 WARNING: at /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 usb_submit_urb() Call Trace: [] usb_submit_urb+0x363/0x3b0 [] :usbhid:hid_start_in+0x8f/0xb0 [] :usbhid:hid_resume+0x2a/0x30 [] usb_resume_interface+0x92/0x100 [] usb_external_resume_device+0x9e/0x170 [] usb_resume+0x2b/0x40 [] resume_device+0x87/0x190 [] dpm_resume+0x99/0xc0 [] device_suspend+0x147/0x190 [] tty_ldisc_deref+0x61/0x80 [] hibernation_snapshot+0x3e/0xe0 [] dnotify_parent+0x3e/0x90 [] snapshot_ioctl+0x379/0x540 [] snapshot_ioctl+0x0/0x540 [] do_ioctl+0x92/0xe0 [] vfs_ioctl+0x73/0x2d0 [] trace_hardirqs_on_thunk+0x35/0x37 [] sys_ioctl+0x91/0xb0 [] 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 ... <7>hub 3-0:1.0: state 7 ports 3 chg evt hub 3-0:1.0: hub_port_status failed (err = -108) hub 3-0:1.0: hub_port_status failed (err = -108) hub 3-0:1.0: hub_port_status failed (err = -108) done. swsusp: Basic memory bitmaps freed Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 17:38, Mattia Dongili wrote: > On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: > > On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: > > > On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > > > > > > Hello, > > > on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting > > > is becoming troublesome as different sets have slightly different > > > problems. > > > At one point (with the GREGKH usb stuff built) I had the kernel > > > reporting it cannot stop the usb-storage thread so I guess that > > > something later in the series made things worse (freezable workqueues?). > > > > > > Clues? > > > > Can you please try 2.6.22-rc5 with the patches from > > > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ > > > > applied. That should allow us to eliminate some suspects. ;-) > > you're safe then! .22-rc5 + your suspend patch-set can suspend and > resume happily. OK, thanks. OTOH, that would have been less patches to check ... ;-) I'll see if I can reproduce your problem here. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wednesday, 20 June 2007 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] ehci_hcd causes box to resume immediately after suspend to RAM
On Monday, 11 June 2007 22:10, Alan Stern wrote: > On Mon, 11 Jun 2007, Rafael J. Wysocki wrote: > > > > At that point, does "lspci -vv" show that the controller is trying to > > > signal a wakeup event? That is, is the PME# signal asserted? > > > > > > (Not that knowing this will help very much -- I'm not sure what we > > > could do with that information, and in any case there are other ways > > > besides PME# for on-board devices to report wakeup requests. I ask > > > mainly out of curiousity.) > > > > It shows this literally: > > > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > > EHCI Controller (rev 02) (prog-if 20 [EHCI]) > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- SERR+ FastB2B- > > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > > SERR- > 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
Re: [linux-usb-devel] [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM
On Tuesday, 12 June 2007 13:59, Rafael J. Wysocki wrote: > On Tuesday, 12 June 2007 03:50, Zhang Rui wrote: > > > > > I've tried to suspend with the controller in that state, but it's > > > > > resumed > > > > > immediately, as before. > > > > > > > > > > > Maybe also see what ACPI reports. > > > > > > > > > > How can I see that? > > > > > > > > I wish I knew. Maybe you can try asking on the ACPI mailing list. > > > > > > > > The simplest workaround should be to disable remote wakeup for that > > > > controller: > > > > > > > > echo disable >/sys/bus/pci/devices/.../power/wakeup > > > > > > I tried that but it didn't help. Namely, the box resumed right after > > > suspending as it had done before. > > > > > > The only way to prevent it from resuming immediately after the suspend is > > > to > > > 'rmmod ehci_hcd' before the suspend. > > > > > > Interestingly enough, I have no such problems with EHCI on the other test > > > box > > > that is able to suspend to RAM and resume. > > > > > What's the kernel version you are using? > > Is it the same problem shown here? > > http://lkml.org/lkml/2007/5/18/55 > > 2.6.22-rc1-mm1 may have this problem. > > Yes, I remeber this thread. s/remeber/remember/ > The kernel is 2.6.22-rc4 with the patches from > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/ > applied. > > Greetings, > Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [linux-pm] Re: ehci_hcd causes box to resume immediately after suspend to RAM
On Tuesday, 12 June 2007 03:50, Zhang Rui wrote: > > > > I've tried to suspend with the controller in that state, but it's > > > > resumed > > > > immediately, as before. > > > > > > > > > Maybe also see what ACPI reports. > > > > > > > > How can I see that? > > > > > > I wish I knew. Maybe you can try asking on the ACPI mailing list. > > > > > > The simplest workaround should be to disable remote wakeup for that > > > controller: > > > > > > echo disable >/sys/bus/pci/devices/.../power/wakeup > > > > I tried that but it didn't help. Namely, the box resumed right after > > suspending as it had done before. > > > > The only way to prevent it from resuming immediately after the suspend is to > > 'rmmod ehci_hcd' before the suspend. > > > > Interestingly enough, I have no such problems with EHCI on the other test > > box > > that is able to suspend to RAM and resume. > > > What's the kernel version you are using? > Is it the same problem shown here? > http://lkml.org/lkml/2007/5/18/55 > 2.6.22-rc1-mm1 may have this problem. Yes, I remeber this thread. The kernel is 2.6.22-rc4 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc4/patches/ applied. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
On Monday, 11 June 2007 20:52, Rafael J. Wysocki wrote:
> On Monday, 11 June 2007 17:59, Alan Stern wrote:
> > On Mon, 11 Jun 2007, Rafael J. Wysocki wrote:
> >
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > The pm_parent member of struct dev_pm_info (defined in
> > > include/linux/pm.h) is
> > > only used to check if the device's parent is in the right state while the
> > > device is being suspended or resumed. However, this can be done just as
> > > well
> > > with the help of the parent pointer in struct device, so pm_parent can be
> > > removed along with some code that handles it.
> >
> > > @@ -61,21 +40,26 @@ int device_pm_add(struct device * dev)
> > >kobject_name(&dev->kobj));
> > > mutex_lock(&dpm_list_mtx);
> > > list_add_tail(&dev->power.entry, &dpm_active);
> > > - device_pm_set_parent(dev, dev->parent);
> > > - if ((error = dpm_sysfs_add(dev)))
> > > + /*
> > > + * The device's parent must not be released until the device itself is
> > > + * removed from the dpm_active list.
> > > + */
> > > + get_device(dev->parent);
> > > + error = dpm_sysfs_add(dev);
> > > + if (error)
> > > list_del(&dev->power.entry);
> > > mutex_unlock(&dpm_list_mtx);
> > > return error;
> > > }
> >
> > The error pathway here does an unbalanced get_device on dev->parent.
> >
> > Anyway, I don't think you need to do this get_device at all (or the
> > coresponding put in device_pm_remove). As long as a device is
> > registered it retains a reference to its parent, and unregistration
> > always calls device_pm_remove.
>
> Yes, I've just come to the same conclusion. I'll remove the
> get_device(dev->parent) and the correspondint put_device(dev->parent)
> from device_pm_remove().
OK
The updated patch follows.
Greetings,
Rafael
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/main.c| 30 --
drivers/base/power/resume.c |7 +++
drivers/base/power/suspend.c |7 +++
include/linux/pm.h |3 ---
4 files changed, 10 insertions(+), 37 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/main.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/main.c 2007-06-10
19:35:49.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/main.c 2007-06-11 21:05:10.0
+0200
@@ -31,28 +31,7 @@ DEFINE_MUTEX(dpm_list_mtx);
int (*platform_enable_wakeup)(struct device *dev, int is_on);
-
-/**
- * device_pm_set_parent - Specify power dependency.
- * @dev: Device who needs power.
- * @parent:Device that supplies power.
- *
- * This function is used to manually describe a power-dependency
- * relationship. It may be used to specify a transversal relationship
- * (where the power supplier is not the physical (or electrical)
- * ancestor of a specific device.
- * The effect of this is that the supplier will not be powered down
- * before the power dependent.
- */
-
-void device_pm_set_parent(struct device * dev, struct device * parent)
-{
- put_device(dev->power.pm_parent);
- dev->power.pm_parent = get_device(parent);
-}
-EXPORT_SYMBOL_GPL(device_pm_set_parent);
-
-int device_pm_add(struct device * dev)
+int device_pm_add(struct device *dev)
{
int error;
@@ -61,21 +40,20 @@ int device_pm_add(struct device * dev)
kobject_name(&dev->kobj));
mutex_lock(&dpm_list_mtx);
list_add_tail(&dev->power.entry, &dpm_active);
- device_pm_set_parent(dev, dev->parent);
- if ((error = dpm_sysfs_add(dev)))
+ error = dpm_sysfs_add(dev);
+ if (error)
list_del(&dev->power.entry);
mutex_unlock(&dpm_list_mtx);
return error;
}
-void device_pm_remove(struct device * dev)
+void device_pm_remove(struct device *dev)
{
pr_debug("PM: Removing info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus",
kobject_name(&dev->kobj));
mutex_lock(&dpm_list_mtx);
dpm
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Saturday, 9 June 2007 23:26, Alan Stern wrote: > On Sat, 9 Jun 2007, Rafael J. Wysocki wrote: > > > > You can try using the patch below to see what happens when you manually > > > suspend the controller. It enables PCI devices to respond to the > > > legacy power/state attribute. You should look at what "lspci -vv" says > > > about the controller's power management signals, both before and after > > > suspending the PCI device entry. > > > > It works as expected, AFAICS. That is, after I echo '2' to the 'state' > > file, > > it shows that the controller is in D3. > > At that point, does "lspci -vv" show that the controller is trying to > signal a wakeup event? That is, is the PME# signal asserted? > > (Not that knowing this will help very much -- I'm not sure what we > could do with that information, and in any case there are other ways > besides PME# for on-board devices to report wakeup requests. I ask > mainly out of curiousity.) It shows this literally: 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- > I've tried to suspend with the controller in that state, but it's resumed > > immediately, as before. > > > > > Maybe also see what ACPI reports. > > > > How can I see that? > > I wish I knew. Maybe you can try asking on the ACPI mailing list. > > The simplest workaround should be to disable remote wakeup for that > controller: > > echo disable >/sys/bus/pci/devices/.../power/wakeup I tried that but it didn't help. Namely, the box resumed right after suspending as it had done before. The only way to prevent it from resuming immediately after the suspend is to 'rmmod ehci_hcd' before the suspend. Interestingly enough, I have no such problems with EHCI on the other test box that is able to suspend to RAM and resume. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
On Monday, 11 June 2007 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
[linux-usb-devel] [RFC][PATCH -mm 6/7] PM: Remove power_state.event checks from suspend core code
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The suspend routines should be called for every device during a system sleep
transition, regardless of the device's state, so that drivers can regard these
method calls as notifications that the system is about to go to sleep, rather
than as directives to put their devices into the 'off' state.
This is documented in Documentation/power/devices.txt and is already done in
the core resume code, so it seems reasonable to make the core suspend code
behave accordingly.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/suspend.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-11
09:59:54.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-11
10:18:11.0 +0200
@@ -71,14 +71,13 @@ int suspend_device(struct device * dev,
dev->parent->power.power_state.event);
}
- if (dev->class && dev->class->suspend && !dev->power.power_state.event)
{
+ if (dev->class && dev->class->suspend) {
suspend_device_dbg(dev, state, "class ");
error = dev->class->suspend(dev, state);
suspend_report_result(dev->class->suspend, error);
}
- if (!error && dev->bus && dev->bus->suspend
- && !dev->power.power_state.event) {
+ if (!error && dev->bus && dev->bus->suspend) {
suspend_device_dbg(dev, state, "");
error = dev->bus->suspend(dev, state);
suspend_report_result(dev->bus->suspend, error);
@@ -97,8 +96,7 @@ static int suspend_device_late(struct de
{
int error = 0;
- if (dev->bus && dev->bus->suspend_late
- && !dev->power.power_state.event) {
+ if (dev->bus && dev->bus->suspend_late) {
suspend_device_dbg(dev, state, "LATE ");
error = dev->bus->suspend_late(dev, state);
suspend_report_result(dev->bus->suspend_late, error);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 7/7] PM: Do not check parent state in suspend and resume core code
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The checks if the device's parent is in the right state done in
drivers/base/power/suspend.c and drivers/base/power/resume.c serve no particular
purpose, since if the parent is in a wrong power state, the device's suspend or
resume callbacks are supposed to return an error anyway. Moreover, they are
also useless from the sanity checking point of view, because they rely on the
code being checked to set dev->parent->power.power_state.event appropriately,
which need not happen if that code is buggy. For these reasons they can be
removed.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/resume.c |7 ---
drivers/base/power/suspend.c |7 ---
2 files changed, 14 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-11
09:59:54.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-11
10:19:37.0 +0200
@@ -29,13 +29,6 @@ int resume_device(struct device * dev)
down(&dev->sem);
- if (dev->parent && dev->parent->power.power_state.event) {
- dev_err(dev, "PM: resume from %d, parent %s still %d\n",
- dev->power.power_state.event,
- dev->parent->bus_id,
- dev->parent->power.power_state.event);
- }
-
if (dev->bus && dev->bus->resume) {
dev_dbg(dev,"resuming\n");
error = dev->bus->resume(dev);
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-11
10:18:11.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-11
10:19:30.0 +0200
@@ -63,13 +63,6 @@ int suspend_device(struct device * dev,
dev_dbg(dev, "PM: suspend %d-->%d\n",
dev->power.power_state.event, state.event);
}
- if (dev->parent && dev->parent->power.power_state.event) {
- dev_err(dev,
- "PM: suspend %d->%d, parent %s already %d\n",
- dev->power.power_state.event, state.event,
- dev->parent->bus_id,
- dev->parent->power.power_state.event);
- }
if (dev->class && dev->class->suspend) {
suspend_device_dbg(dev, state, "class ");
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 5/7] PM: Remove prev_state from struct dev_pm_info
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The prev_state member of struct dev_pm_info (defined in include/linux/pm.h) is
only used during a resume to check if the device's state before the suspend was
'off', in which case the device is not resumed. However, in such cases the
decision whether or not to resume the device should be made on the driver level
and the resume callbacks from the device's bus and class should be executed
anyway (the may be needed for some things other than just powering on the
device).
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/resume.c |3 +--
drivers/base/power/suspend.c |2 --
drivers/usb/core/hub.c |5 -
include/linux/pm.h |1 -
4 files changed, 1 insertion(+), 10 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-10
19:36:52.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-10
19:53:57.0 +0200
@@ -83,8 +83,7 @@ void dpm_resume(void)
list_move_tail(entry, &dpm_active);
mutex_unlock(&dpm_list_mtx);
- if (!dev->power.prev_state.event)
- resume_device(dev);
+ resume_device(dev);
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
19:36:52.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
19:53:09.0 +0200
@@ -71,8 +71,6 @@ int suspend_device(struct device * dev,
dev->parent->power.power_state.event);
}
- dev->power.prev_state = dev->power.power_state;
-
if (dev->class && dev->class->suspend && !dev->power.power_state.event)
{
suspend_device_dbg(dev, state, "class ");
error = dev->class->suspend(dev, state);
Index: linux-2.6.22-rc4/drivers/usb/core/hub.c
===
--- linux-2.6.22-rc4.orig/drivers/usb/core/hub.c2007-06-08
13:09:18.0 +0200
+++ linux-2.6.22-rc4/drivers/usb/core/hub.c 2007-06-10 19:54:08.0
+0200
@@ -1110,11 +1110,6 @@ void usb_root_hub_lost_power(struct usb_
dev_warn(&rhdev->dev, "root hub lost power or was reset\n");
- /* Make sure no potential wakeup events get lost,
-* by forcing the root hub to be resumed.
-*/
- rhdev->dev.power.prev_state.event = PM_EVENT_ON;
-
spin_lock_irqsave(&device_state_lock, flags);
hub = hdev_to_hub(rhdev);
for (port1 = 1; port1 <= rhdev->maxchild; ++port1) {
Index: linux-2.6.22-rc4/include/linux/pm.h
===
--- linux-2.6.22-rc4.orig/include/linux/pm.h2007-06-10 19:36:52.0
+0200
+++ linux-2.6.22-rc4/include/linux/pm.h 2007-06-10 19:52:56.0 +0200
@@ -235,7 +235,6 @@ struct dev_pm_info {
unsignedcan_wakeup:1;
#ifdef CONFIG_PM
unsignedshould_wakeup:1;
- pm_message_tprev_state;
struct list_headentry;
#endif
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 4/7] PM: Remove suspend and resume support from struct device_type
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The suspend and resume support in struct device_type (include/linux/device.h)
is not used anywhere. It is also undocumented, so it can be removed.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/resume.c |5 -
drivers/base/power/suspend.c |7 ---
include/linux/device.h |2 --
3 files changed, 14 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-10
15:00:23.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-10
15:02:04.0 +0200
@@ -41,11 +41,6 @@ int resume_device(struct device * dev)
error = dev->bus->resume(dev);
}
- if (!error && dev->type && dev->type->resume) {
- dev_dbg(dev,"resuming\n");
- error = dev->type->resume(dev);
- }
-
if (!error && dev->class && dev->class->resume) {
dev_dbg(dev,"class resume\n");
error = dev->class->resume(dev);
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
15:00:40.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
15:02:04.0 +0200
@@ -79,13 +79,6 @@ int suspend_device(struct device * dev,
suspend_report_result(dev->class->suspend, error);
}
- if (!error && dev->type && dev->type->suspend
- && !dev->power.power_state.event) {
- suspend_device_dbg(dev, state, "type ");
- error = dev->type->suspend(dev, state);
- suspend_report_result(dev->type->suspend, error);
- }
-
if (!error && dev->bus && dev->bus->suspend
&& !dev->power.power_state.event) {
suspend_device_dbg(dev, state, "");
Index: linux-2.6.22-rc4/include/linux/device.h
===
--- linux-2.6.22-rc4.orig/include/linux/device.h2007-06-10
15:00:23.0 +0200
+++ linux-2.6.22-rc4/include/linux/device.h 2007-06-10 15:02:04.0
+0200
@@ -343,8 +343,6 @@ struct device_type {
int (*uevent)(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size);
void (*release)(struct device *dev);
- int (*suspend)(struct device * dev, pm_message_t state);
- int (*resume)(struct device * dev);
};
/* interface for exporting device attributes */
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 1/7] PM: Remove pm_parent from struct dev_pm_info
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The pm_parent member of struct dev_pm_info (defined in include/linux/pm.h) is
only used to check if the device's parent is in the right state while the
device is being suspended or resumed. However, this can be done just as well
with the help of the parent pointer in struct device, so pm_parent can be
removed along with some code that handles it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/base/power/main.c| 36 ++--
drivers/base/power/resume.c |7 +++
drivers/base/power/suspend.c |7 +++
include/linux/pm.h |3 ---
4 files changed, 16 insertions(+), 37 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/main.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/main.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/main.c 2007-06-09 22:19:44.0
+0200
@@ -31,28 +31,7 @@ DEFINE_MUTEX(dpm_list_mtx);
int (*platform_enable_wakeup)(struct device *dev, int is_on);
-
-/**
- * device_pm_set_parent - Specify power dependency.
- * @dev: Device who needs power.
- * @parent:Device that supplies power.
- *
- * This function is used to manually describe a power-dependency
- * relationship. It may be used to specify a transversal relationship
- * (where the power supplier is not the physical (or electrical)
- * ancestor of a specific device.
- * The effect of this is that the supplier will not be powered down
- * before the power dependent.
- */
-
-void device_pm_set_parent(struct device * dev, struct device * parent)
-{
- put_device(dev->power.pm_parent);
- dev->power.pm_parent = get_device(parent);
-}
-EXPORT_SYMBOL_GPL(device_pm_set_parent);
-
-int device_pm_add(struct device * dev)
+int device_pm_add(struct device *dev)
{
int error;
@@ -61,21 +40,26 @@ int device_pm_add(struct device * dev)
kobject_name(&dev->kobj));
mutex_lock(&dpm_list_mtx);
list_add_tail(&dev->power.entry, &dpm_active);
- device_pm_set_parent(dev, dev->parent);
- if ((error = dpm_sysfs_add(dev)))
+ /*
+* The device's parent must not be released until the device itself is
+* removed from the dpm_active list.
+*/
+ get_device(dev->parent);
+ error = dpm_sysfs_add(dev);
+ if (error)
list_del(&dev->power.entry);
mutex_unlock(&dpm_list_mtx);
return error;
}
-void device_pm_remove(struct device * dev)
+void device_pm_remove(struct device *dev)
{
pr_debug("PM: Removing info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus",
kobject_name(&dev->kobj));
mutex_lock(&dpm_list_mtx);
dpm_sysfs_remove(dev);
- put_device(dev->power.pm_parent);
+ put_device(dev->parent);
list_del_init(&dev->power.entry);
mutex_unlock(&dpm_list_mtx);
}
Index: linux-2.6.22-rc4/drivers/base/power/resume.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/resume.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/resume.c2007-06-09
21:12:43.0 +0200
@@ -29,12 +29,11 @@ int resume_device(struct device * dev)
down(&dev->sem);
- if (dev->power.pm_parent
- && dev->power.pm_parent->power.power_state.event) {
+ if (dev->parent && dev->parent->power.power_state.event) {
dev_err(dev, "PM: resume from %d, parent %s still %d\n",
dev->power.power_state.event,
- dev->power.pm_parent->bus_id,
- dev->power.pm_parent->power.power_state.event);
+ dev->parent->bus_id,
+ dev->parent->power.power_state.event);
}
if (dev->bus && dev->bus->resume) {
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-08
13:09:16.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-09
21:12:40.0 +0200
@@ -55,13 +55,12 @@ int suspend_device(struct device * dev,
dev_dbg(dev, "PM: suspend %d-->%d\n",
dev->power.power_state.event, state.event);
}
- if (dev->power.pm_parent
- && dev->power.pm_parent->power.power_state.event) {
+ if (dev->parent
[linux-usb-devel] [RFC][PATCH -mm 3/7] PM: Simplify suspend_device
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Reduce code duplication in drivers/base/suspend.c by introducing a separate
function for printing diagnostic messages.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
drivers/base/power/suspend.c | 49 +++
1 file changed, 18 insertions(+), 31 deletions(-)
Index: linux-2.6.22-rc4/drivers/base/power/suspend.c
===
--- linux-2.6.22-rc4.orig/drivers/base/power/suspend.c 2007-06-10
13:30:45.0 +0200
+++ linux-2.6.22-rc4/drivers/base/power/suspend.c 2007-06-10
18:50:45.0 +0200
@@ -40,6 +40,14 @@ static inline char *suspend_verb(u32 eve
}
+static void
+suspend_device_dbg(struct device * dev, pm_message_t state, char *info)
+{
+ dev_dbg(dev, "%s%s%s\n", info, suspend_verb(state.event),
+ ((state.event == PM_EVENT_SUSPEND) && device_may_wakeup(dev)) ?
+ ", may wakeup" : "");
+}
+
/**
* suspend_device - Save state of one device.
* @dev: Device.
@@ -66,37 +74,21 @@ int suspend_device(struct device * dev,
dev->power.prev_state = dev->power.power_state;
if (dev->class && dev->class->suspend && !dev->power.power_state.event)
{
- dev_dbg(dev, "class %s%s\n",
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
- && device_may_wakeup(dev))
- ? ", may wakeup"
- : ""
- );
+ suspend_device_dbg(dev, state, "class ");
error = dev->class->suspend(dev, state);
suspend_report_result(dev->class->suspend, error);
}
- if (!error && dev->type && dev->type->suspend &&
!dev->power.power_state.event) {
- dev_dbg(dev, "%s%s\n",
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
- && device_may_wakeup(dev))
- ? ", may wakeup"
- : ""
- );
+ if (!error && dev->type && dev->type->suspend
+ && !dev->power.power_state.event) {
+ suspend_device_dbg(dev, state, "type ");
error = dev->type->suspend(dev, state);
suspend_report_result(dev->type->suspend, error);
}
- if (!error && dev->bus && dev->bus->suspend &&
!dev->power.power_state.event) {
- dev_dbg(dev, "%s%s\n",
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
- && device_may_wakeup(dev))
- ? ", may wakeup"
- : ""
- );
+ if (!error && dev->bus && dev->bus->suspend
+ && !dev->power.power_state.event) {
+ suspend_device_dbg(dev, state, "");
error = dev->bus->suspend(dev, state);
suspend_report_result(dev->bus->suspend, error);
}
@@ -114,14 +106,9 @@ static int suspend_device_late(struct de
{
int error = 0;
- if (dev->bus && dev->bus->suspend_late &&
!dev->power.power_state.event) {
- dev_dbg(dev, "LATE %s%s\n",
- suspend_verb(state.event),
- ((state.event == PM_EVENT_SUSPEND)
- && device_may_wakeup(dev))
- ? ", may wakeup"
- : ""
- );
+ if (dev->bus && dev->bus->suspend_late
+ && !dev->power.power_state.event) {
+ suspend_device_dbg(dev, state, "LATE ");
error = dev->bus->suspend_late(dev, state);
suspend_report_result(dev->bus->suspend_late, error);
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 2/7] PM: Remove saved_state from struct dev_pm_info
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The saved_state member of struct dev_pm_info, defined in include/linux/pm.h, is
not used anywhere, so it can be removed.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
include/linux/pm.h |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.22-rc4/include/linux/pm.h
===
--- linux-2.6.22-rc4.orig/include/linux/pm.h2007-06-09 21:12:45.0
+0200
+++ linux-2.6.22-rc4/include/linux/pm.h 2007-06-09 22:26:13.0 +0200
@@ -236,7 +236,6 @@ struct dev_pm_info {
#ifdef CONFIG_PM
unsignedshould_wakeup:1;
pm_message_tprev_state;
- void* saved_state;
struct list_headentry;
#endif
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [RFC][PATCH -mm 0/7] PM: Remove unused and unnecessary features from suspend and resume core
Hi, The following series of patches removes some unused and unnecessary features from the suspend and resume core code. Comments welcome. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2/2] 2.6.22-rc4: known regressions with patches v2
On Saturday, 9 June 2007 19:40, Michal Piotrowski wrote: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc4 > with patches available. > > Feel free to add new regressions/remove fixed etc. > http://kernelnewbies.org/known_regressions > > > > SATA/PATA > > Subject: disk on promise pdc20378 disabled at boot > References : http://bugzilla.kernel.org/show_bug.cgi?id=8587 > Submitter : Jean-Luc Coulon <[EMAIL PROTECTED]> > Handled-By : Tejun Heo <[EMAIL PROTECTED]> > Caused-By : Tejun Heo <[EMAIL PROTECTED]> > commit 464cf177df7727efcc5506322fc5d0c8b896f545 > Patch : http://lkml.org/lkml/2007/6/6/112 > Status : patch available > > > > SELinux > > Subject: very high non-preempt latency in context_struct_compute_av() > References : http://lkml.org/lkml/2007/6/4/78 > Submitter : Ingo Molnar <[EMAIL PROTECTED]> > Handled-By : Stephen Smalley <[EMAIL PROTECTED]> > James Morris <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/6/7/334 > Status : patch available > > > > Suspend > > Subject: panic on s3 resume with uhci_hcd module > References : http://bugzilla.kernel.org/show_bug.cgi?id=8565 > Submitter : Simon <[EMAIL PROTECTED]> > Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> > Patch : > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/21-firewire-implement-suspend-resume-hooks.patch > Status : patch available The patch is already in 2.6.22-rc4, AFAICS. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Sunday, 3 June 2007 17:31, Alan Stern wrote: > On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > One of my test boxes suspends to RAM just fine except that if ehci_hcd is > > loaded before the suspend, the box resumes immediately after going to sleep. > > Evidently the hardware thinks a wakeup event has occurred. It is > possible to disable remote wakeup via sysfs, but it would be more > interesting to find out the real reason for the wakeup. > > I don't know how to go about doing that, however. It might be some > interaction at the ACPI level, and it might involve the PCI PME# > signal. > > Do you have any USB devices attached when you suspend? > > You can try using the patch below to see what happens when you manually > suspend the controller. It enables PCI devices to respond to the > legacy power/state attribute. You should look at what "lspci -vv" says > about the controller's power management signals, both before and after > suspending the PCI device entry. It works as expected, AFAICS. That is, after I echo '2' to the 'state' file, it shows that the controller is in D3. I've tried to suspend with the controller in that state, but it's resumed immediately, as before. > Maybe also see what ACPI reports. How can I see that? Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] blank filenames in /sys/modules, kernel 2.6.21
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
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
Re: [linux-usb-devel] blank filenames in /sys/modules, kernel 2.6.21
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] ehci_hcd causes box to resume immediately after suspend to RAM
On Sunday, 3 June 2007 17:31, Alan Stern wrote: > On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > One of my test boxes suspends to RAM just fine except that if ehci_hcd is > > loaded before the suspend, the box resumes immediately after going to sleep. > > Evidently the hardware thinks a wakeup event has occurred. It is > possible to disable remote wakeup via sysfs, but it would be more > interesting to find out the real reason for the wakeup. > > I don't know how to go about doing that, however. It might be some > interaction at the ACPI level, and it might involve the PCI PME# > signal. > > Do you have any USB devices attached when you suspend? Not that I know of. > You can try using the patch below to see what happens when you manually > suspend the controller. It enables PCI devices to respond to the > legacy power/state attribute. You should look at what "lspci -vv" says > about the controller's power management signals, both before and after > suspending the PCI device entry. Maybe also see what ACPI reports. I'll be able to do this in a couple of days, when I have access to the machine again. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
Hi, One of my test boxes suspends to RAM just fine except that if ehci_hcd is loaded before the suspend, the box resumes immediately after going to sleep. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8565] New: panic on s3 resume with uhci_hcd module
On Saturday, 2 June 2007 00:12, Andrew Morton wrote: > On Fri, 1 Jun 2007 14:08:37 -0700 > [EMAIL PROTECTED] wrote: > > > > Please follow up via emailed reply-to-all, rather than via the bugzilla web > interface, thanks. > > Michal, please track this as a post-2.6.21 regression. > > > http://bugzilla.kernel.org/show_bug.cgi?id=8565 > > > >Summary: panic on s3 resume with uhci_hcd module > > Kernel Version: 2.6.22.rc3 / git 2007-06-01 > > Status: NEW > > Severity: normal > > Owner: [EMAIL PROTECTED] > > Submitter: [EMAIL PROTECTED] > > > > > > Most recent kernel where this bug did *NOT* occur: FC6 2.6.20 kernels / > > 2.6.21.3 > > Distribution: Fedora 7 > > Hardware Environment: Dell Inspiron 8500 > > Software Environment: > > Problem Description: I have just done a clean install of fedora 7 on my > > machine, > > replacing Fedora Core 6. > > When I resume my machine from suspend, it panics. My display is not > > reiinitialised, so using /sys/power/pm_trace I identified that the device > > is the > > following; > > > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM > > (ICH4/ICH4-L/ICH4-M) > > USB UHCI Controller #1 (rev 03) > > > > With the current fedora kernel (kernel-2.6.21-1.3194.fc7) I see the > > following > > backtrace on bootup: > > > > Jun 1 09:00:39 echo kernel: ACPI: PCI Interrupt :01:00.0[A] -> Link > > [LNKA] > > -> GSI 11 (level, low) -> IRQ 11 > > Jun 1 09:00:39 echo kernel: BUG: warning at > > kernel/softirq.c:138/local_bh_enable() (Not tainted) > > Jun 1 09:00:39 echo kernel: [] local_bh_enable+0x45/0x92 > > Jun 1 09:00:39 echo kernel: [] cond_resched_softirq+0x2c/0x42 > > Jun 1 09:00:39 echo kernel: [] release_sock+0x4f/0x9d > > Jun 1 09:00:39 echo kernel: [] tcp_sendmsg+0x90b/0x9f9 > > Jun 1 09:00:39 echo kernel: [] inet_sendmsg+0x3b/0x45 > > Jun 1 09:00:39 echo kernel: [] sock_aio_write+0xf6/0x102 > > Jun 1 09:00:39 echo kernel: [] do_sync_write+0xc7/0x10a > > Jun 1 09:00:39 echo kernel: [] autoremove_wake_function+0x0/0x35 > > Jun 1 09:00:39 echo kernel: [] vfs_write+0xbc/0x154 > > Jun 1 09:00:39 echo kernel: [] sys_write+0x41/0x67 > > Jun 1 09:00:39 echo kernel: [] syscall_call+0x7/0xb > > Jun 1 09:00:39 echo kernel: [] __sched_text_start+0x6e8/0x89e > > Jun 1 09:00:39 echo kernel: === > > I wouldn't worry about this warning. There was a busted Ingo patch whcih > later got fixed - I suspect it leaked into this Fedora release and it > hasn't got fixed yet. > > > > I have since pulled Linus' git linux-2.6 tree (version no was 2.6.22-rc3). I > > built this using the default config options. In this version I still get the > > kernel panic, but I do not see the backtrace during bootup. > > > > Removing the uhci_hcd module allows the machine to resume without panic'ing. Hmm, strange. I have at least one test box with uhci_hcd that suspends (to RAM) and resumes successfully. Still, I've tested it with the hibernation and suspend patchset applied only. Simon, can you test 2.6.22-rc3 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/ applied? Greetings, Rafael - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wednesday, 23 May 2007 09:48, Andrew Morton wrote: > On Wed, 23 May 2007 00:42:33 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ > > This is intermittently getting resume-from-RAM failures. It is not > sufficiently repeatable to be able to bisect. > > [ 1381.119362] PM: Preparing system for mem sleep > [ 2331.798452] Stopping tasks ... > [ 2351.760431] Stopping kernel threads timed out after 20 seconds (2 tasks > refusing to freeze): > [ 2351.762385] ksuspend_usbd > [ 2351.764374] khubd > [ 2351.766338] Restarting tasks ... done. Hmm, that seems to be related to usb-fix-suspend-to-ram.patch (probably one of the threads is waiting for a completion by some other thread that has been frozen already). Greetings, Rafael - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 2.6.21.1] host: remove EHCI atomic reference counting
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
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/
$ ../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
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.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB: on suspend to ram/disk all usb devices are replugged
Hi, On Sunday, 1 April 2007 20:34, Pavel Machek wrote: > Hi! > > > > Problem is that suspending _with_ removable mass storage devices > > > attached just will not work. User will unplug them, then complain > > > about corruption. Advanced user will unplug them, work with them > > > somewhere else, replug them, then loose filesystem. > > > > > > Feel free to send patch to teach filesystems to handle this. > > > > Actually what's needed is a Persistent Logical Volume Manager. With it, > > you could even mount a filesystem on a USB device, unplug the device, plug > > it back into a different port, and still be able to use the filesystem. > > > > But you're still likely to run into trouble if you unplug a storage > > device, move it to another system and write on it, then plug it back into > > the original system. The PLVM would somehow have to recognize that the > > data had been changed. I don't know a foolproof way of doing that. > > Such detection should be possible when done at filesystem level. > > I.e. ext3 would notice that someone replayed the journal. > > Or we could create ext5 where each r/w mount would update mount > time... actually we probably already have last mount time in ext3, > so... I'm thinking we'll need to introduce something like freezing notifiers, ie. the ability to register a notifier by an interested subsystem that will be called right after user space processes have been frozen and right before we start to thaw them (that may allow us to handle the microcode issue in a clean way, for example). Now if a filesystem registers a freezing notifier, it may be unmounted during the suspend and remounted during the resume in more or less transparent way. I think an additional mount flag would be needed for filesystem that should install such notifiers, like "removable". Greetings, Rafael - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=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] 【 在宅で収入 基盤 】 「２０歳〜７０ 歳位まで」
独占広告― ≪ パソコンを利用して、在宅での仕事に興味のある方 ≫ 「 空いた時間に 収入基盤を作りませんか？ 」 募集要項 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.php&p=sourceforge&CID=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] 【 パソコンで 副収入 】 「２０歳〜７ ０歳位まで」
独占広告― 「 あなたも、パソコンを利用して 空いた時間に 収入基盤を作りませんか？ 」 募集要項 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.php&p=sourceforge&CID=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] 【 自宅で 収入 】 メンバー募 集 ※１７期 残り５ 名
独占広告━━━ ◆家のパソコンを利用して、収入を得たい方 ◆空いた時間を利用して副業したい方 ◆自由な時間を利用しておこづかいを稼ぎたい主婦の方 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.php&p=sourceforge&CID=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] 【自宅で収入】 メンバー募集※１７期 残 り８名
独占広告━━━ ◆家のパソコンを利用して、収入を得たい方 ◆空いた時間を利用して副業したい方 ◆自由な時間を利用しておこづかいを稼ぎたい主婦の方 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.php&p=sourceforge&CID=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
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/USB 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.php&p=sourceforge&CID=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
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/USB 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.php&p=sourceforge&CID=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
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/USB 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.php&p=sourceforge&CID=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] 【 パソコンで 副収入 】 「２０歳〜７ ０歳位まで」
独占広告― 「 あなたも、パソコンを利用して 空いた時間に 収入基盤を作りませんか？ 」 募集要項 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.php&p=sourceforge&CID=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
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.php&p=sourceforge&CID=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
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;
> }
Re: [linux-usb-devel] Possible race condition in usb-serial.c
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.php&p=sourceforge&CID=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
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.php&p=sourceforge&CID=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
> 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.php&p=sourceforge&CID=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
> 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.php&p=sourceforge&CID=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
> 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.php&p=sourceforge&CID=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
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.php&p=sourceforge&CID=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
> 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.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 0/3] Change ohci-hcd autosuspend mechanism
Hi, On Monday, 25 September 2006 21:40, Alan Stern wrote: > Greg and Andrew: > > This series of patches completely reworks the way ohci-hcd carries out > root-hub autosuspends. The existing code is not compatible with the new > core USB autosuspend mechanism. > > Patch 1 is a simple one-line change to usbcore with no harmful effects. > It can go directly into both Greg's and Andrew's trees. > > Patch 2 removes the existing autosuspend code in ohci-hcd. It is > essentially the same as a patch Rafael tried out; he confirmed that it got > ohci-hcd to work on his machine both with CONFIG_USB_SUSPEND unset and > with it set. This patch also can go directly into both trees. If anybody > has been having trouble using their OHCI controllers with the recent -mm > kernels, this should fix it. The downside is that now the controllers > won't automatically get turned off when no devices are attached. > Hopefully this state of affairs will be relatively short-lived. > > Patch 3 adds new "auto-stop" code to ohci-hcd. This will stop the > controller only when no devices are attached, unlike the existing code > which will also suspend the controller when all the attached devices are > themselves suspended. That's okay, because "auto-stop" is meant to be > used when CONFIG_USB_SUSPEND isn't set -- which means attached devices > would _never_ be suspended. > > Patch 3 is much more experimental than the first two, and probably also > more controversial (I expect David will have a lot to say about it, even > if no one else does). In fact, I won't even CC: Andrew on this one; let's > just keep it in the USB tree at first. More details will appear in the > patch message. > > Alan Stern > > P.S.: Raphael, these three patches will apply to 2.6.18-mm1. In addition > to these you might want to add this patch, which hasn't yet been accepted: > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=115867525727045&w=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.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Friday, 22 September 2006 17:18, Alan Stern wrote: > On Fri, 22 Sep 2006, Rafael J. Wysocki wrote: > > > I have tested 2.6.18-rc6-mm2 with your patch applied (it is called > > 2.6.18-rc6 > > in the attached dmesg outputs, but that's because I have a "customized" > > 2.6.18-rc6-mm2 installed and I didn't want to replace it). > > > > I have tested both with and without CONFIG_USB_SUSPEND set. In either case > > I booted the system without my USB mouse. Then, I plugged the mouse in > > and checked if it worked. Next, I suspended and resumed the system twice > > checking if the mouse worked after each resume, without unplugging it. > > Finally, after the second resume I unplugged and replugged the mouse. > > > > The results are the following: > > > > 1) The kernel compiled without CONFIG_USB_SUSPEND works just fine, suspends > > and resumes correctly, and the mouse always works (ie. is correctly detected > > every time). > > Good. > > > 2) The kernel compiled with CONFIG_USB_SUSPEND set doesn't detect the mouse > > plugged in after a fresh boot. However, if the mouse is connected to a USB > > port during an entire suspend/resume cycle, it works after the resume, but > > when it's unplugged after the resume and replugged, the kernel fails to > > detect > > it. > > > > The outputs of dmesg for each case are attached. > > This helped. I think I figured out the problem. Below is a new version > of the patch I asked you to try. It's the same as before except that I > removed a bunch of extra code. Some weird interactions between the driver > and usbcore prevented status-change interrupts from being enabled; hence > the connect-change events just get lost. > > Anyway, this should solve the problem. It does. Now the kernel with CONFIG_USB_SUSPEND set works fine. Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On Thursday, 21 September 2006 16:56, Alan Stern wrote: > [Trimmed down the CC list] > > On Mon, 18 Sep 2006, Rafael J. Wysocki wrote: > > > 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'm working on this, but it's slow going because I'm not very familiar > with ohci-hcd. One of my computers does have OHCI controllers but I can't > reproduce your problem. > > In the meantime, let's make sure I understand the symptoms properly. > Let's say you start with pure 2.6.18-rc6-mm2 and apply the patch below. > (Two of the parts have already been submitted and the third is for > testing.) Let's also say you start with a clean boot and don't do any > suspends. Finally, let's say you leave the mouse unplugged while you boot > and then plug it in afterward. Does it work? If it does, what happens if > you unplug it and then replug it several seconds later? > > Do you see the problem is CONFIG_USB_SUSPEND isn't set? What about if it > is set? What do the kernel logs show? > > Assuming the symptoms do not appear, if you do suspend-to-disk do they > appear afterward? 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). 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. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg.log.gz Description: GNU Zip compressed data dmesg-usb_suspend.log.gz Description: GNU Zip compressed data - 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.php&p=sourceforge&CID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
On Tuesday, 19 September 2006 02:04, David Brownell wrote: > On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote: > > Hi, > > > > It looks like the ohci_hcd driver sometimes has problems with the > > initialization (eg. USB mouse doesn't work after a fresh boot and reloading > > of the driver helps). > > > > I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), > > but it is not readily reproducible. Anyway I've got a dmesg output from a > > failing case which is attached. > > Where I've seen such issues in the past has been with one specific > device: a UPS that seems unhappy if it doesn't get a VBUS power cycle, > so that OHCI implementations that don't implement power switching are > bad choices for connecting that particular UPS. > > I believe that's not the issue in your case. I compared the boot > sequence you sent with one for the NF3-150 I use a lot (also x86_64) > which does not exhibit this failure, and the differences I noticed > were: > > - NOCP set in roothub.a ... your BIOS reports no overcurrent protection > - different 2.6.18 prepatches ... you used rc6-mm2, not rc7 > - different irqs (you used PIC not IOAPIC) > - driver registration sequence different ... I registered EHCI first > - yours came _up_ with RHSC irq pending on one root (device present) > > And re those last two, it didn't finish mouse enumeration with OHCI before > starting to do it with EHCI. I could easily see how that would lead to > timing-dependent/intermittent failures. > > Now, registering EHCI first is not "supposed" to matter, but I'm thinking > it started to matter a while back, since a few folk have reported as much. > > One suspicion being that some of the hub driver changes have had some bad > consequences. (My suspicions there were highlighted by noticing some of > the misbehavior associated with an embedded USB controller I was testing, > which provoked failures in those same code paths...) The root hub handoff > relies on the usb/core/hub.c code to do the right things, notably treating > disconnect-during-reset (handoff to companion) as routine, but I think I > noticed that fault handling logic has changed. > > At any rate, that suggests a few experiments to me. > > - First, does this still show up with the stock RC7 code? There are > a bunch of IMO rather experimental USB patches in the MM tree... > including several affecting usbcore hub support. > > - Second does it appear without EHCI loaded? If not, that would > tend to confirm an issue usbcore hub driver handoff logic. > > - Third, does it appear if EHCI is loaded _first_ (as the distro > should already have been doing just to avoid thrashing during > system startup)? Similar comment re previous experiment, though > it'd provide a potential workaround. > > I'd kind of suspect that the generic RC7 code, with EHCI loaded first > as it should be, would "just work". Yes, I think the problem resulted from the experimental patches in -mm. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=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.
-- 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.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On 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.php&p=sourceforge&CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On 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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd does not recognize new devices
On 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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Saturday, 16 September 2006 00:45, Pete Zaitcev wrote: > On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > In fact I can reproduce it on two different boxes now. > > How about the attached? Apparently works. :-) Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=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 does not recognize new devices
Hi, On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote: > It looks like the ohci_hcd driver sometimes has problems with the > initialization (eg. USB mouse doesn't work after a fresh boot and reloading > of the driver helps). > > I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), > but it is not readily reproducible. Anyway I've got a dmesg output from a > failing case which is attached. Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged into the USB ports. For example, if I unplug and replug a mouse (that worked before unplugging), it doesn't work any more. I have to reload ohci_hcd to make it work again. This is 100% reproducible and occurs on the two boxes above. Appended in a snippet from a dmesg output that I think is relevant to this issue. It covers the unplugging and replugging of a USB mouse (there are no more USB-related messages in the dmesg). Greetings, Rafael hub 3-0:1.0: state 7 ports 4 chg evt 0010 ohci_hcd :00:13.1: GetStatus roothub.portstatus [3] = 0x00030100 PESC CSC PPS hub 3-0:1.0: port 4, status 0100, change 0003, 12 Mb/s usb 3-4: USB disconnect, address 2 usb 3-4: unregistering device usb 3-4: usb_disable_device nuking all URBs ohci_hcd :00:13.1: shutdown urb 81002f77d4b8 pipe 40408280 ep1in-intr usb 3-4: unregistering interface 3-4:1.0 PM: Removing info for No Bus:usbdev3.2_ep81 usbdev3.2_ep81: ep_device_release called for usbdev3.2_ep81 PM: Removing info for usb:3-4:1.0 usb 3-4:1.0: uevent PM: Removing info for No Bus:usbdev3.2 PM: Removing info for No Bus:usbdev3.2_ep00 usbdev3.2_ep00: ep_device_release called for usbdev3.2_ep00 PM: Removing info for usb:3-4 usb 3-4: uevent hub 3-0:1.0: debounce: port 4: total 100ms stable 100ms status 0x100 hub 1-0:1.0: state 7 ports 8 chg evt 0100 ehci_hcd :00:13.2: GetStatus port 8 status 001403 POWER sig=k CSC CONNECT hub 1-0:1.0: port 8, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 8: total 100ms stable 100ms status 0x501 ehci_hcd :00:13.2: port 8 low speed --> companion ehci_hcd :00:13.2: GetStatus port 8 status 003002 POWER OWNER sig=se0 CSC -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.18-rc6-mm2 (-mm1): ohci_hcd sometimes does not initialize properly on x86_64
Hi, It looks like the ohci_hcd driver sometimes has problems with the initialization (eg. USB mouse doesn't work after a fresh boot and reloading of the driver helps). I have observed this on two different x86_64 boxes (HPC 6325, Asus L5D), but it is not readily reproducible. Anyway I've got a dmesg output from a failing case which is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 22:55, Alan Stern wrote: > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > Well, sorry. This test has been passed, but after a reboot it refused to > > suspend just once giving the same messages that I've got from the kernel > > with USB_SUSPEND set (the relevant dmesg output is attached). > > > > > Then for the next stage, repeat the same tests but with > > > USB_SUSPEND set. > > Okay, hang on, let's try to solve this first. > > This actually is a completely different problem from what I've been > attacking up to now, and we definitely should resolve it. It's purely a > question of the ohci-hcd driver, nothing (or very little) to do with > usbcore or ehci-hcd or uhci-hcd. > > I'm asking David to chime in, because this is his code and his driver. > > Here's an explanation of the problem. Basically it boils down to the way > ohci-hcd rolls its own root-hub autosuspend. I'm referring to the call to > ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data(). > Things go wrong because that call totally bypasses usbcore. It's a > layering violation. > > The corresponding root-hub autoresume code, i.e., the call to > usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through > usbcore. It fails for two reasons. First, resume_root_hub does its job > by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND > isn't set that routine is a no-op. Second, since usbcore was never > notified when the root hub was suspended, the root hub's device state > isn't USB_STATE_SUSPENED and the interface is still marked as active -- so > even if usb_autoresume_device() did get called it wouldn't do anything. > > As I see it, there are two ways to resolve the problem. The easiest is to > rip out the autosuspend stuff from ohci-hcd entirely. When my generic > autosuspend patches are accepted, the HCD-specific stuff won't be needed > so much. This has the disadvantage that the root hub will never get > suspended if CONFIG_USB_SUSPEND isn't set. On the other hand, this is how > ehci_hcd works already. This isn't a big deal as far as I'm concerned, but I think that dependancy will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND gets selected automatically if CONFIG_PM is set). > The second way is to copy what I did in uhci-hcd. There is a special > "root hub is stopped" mode which kicks in only when no ports are > connected. It isn't a full-fledged suspend, in the sense that usbcore > isn't notified -- just like what happens in ohci-hcd. The difference is, > since we know no devices are attached, the driver can go back to normal > operation while in interrupt context. It doesn't have to sleep because no > attached devices means no TRSMRCY delay is needed and the controller's > hardware can be reset directly. As a result, the corresponding > "auto-restart" code doesn't need to go through usbcore either and so > usb_autoresume_device() never enters the picture. > > I don't know if this is feasible with OHCI. For now, I'll include a patch > that takes the first approach and disables the ohci-hcd autosuspend > entirely. I think it will solve your problem above. Yes it does. Now I'm able to suspend/resume several times in a row with both ohci and ehci hcds loaded all the time. Thanks a lot! Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 21:37, Rafael J. Wysocki wrote: > On Thursday, 14 September 2006 20:28, Alan Stern wrote: > > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > > > > Let's try a simpler test. Leave USB_SUSPEND unset. > > > > > > > > First rmmod ohci-hcd. None of your full-speed USB devices will work, > > > > but > > > > that's okay. Try the suspend-twice test and see what happens. > > > > > > > > Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the > > > > suspend-twice > > > > test. > > > > > > Done, works (with USB_SUSPEND unset). > > > > Okay, good. > > Well, sorry. This test has been passed, but after a reboot it refused to > suspend just once giving the same messages that I've got from the kernel > with USB_SUSPEND set (the relevant dmesg output is attached). This only happens if _both_ ohci_hcd and ehci_hcd are loaded before the suspend. > > Then for the next stage, repeat the same tests but with > > USB_SUSPEND set. > > Compiling. The results are now the same with and without USB_SUSPEND set. Namely, if one hcd is loaded before a suspend (either ehci or ohci), it succeeds (repeatable arbitrary number of times in a row). However, if both hcds are loaded before a suspend, it fails (100% of the time) and the messages are like in the dmesg output attached to the previous message. I've reproduced this behavior on another x86_64 box. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 20:28, Alan Stern wrote: > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > > Let's try a simpler test. Leave USB_SUSPEND unset. > > > > > > First rmmod ohci-hcd. None of your full-speed USB devices will work, but > > > that's okay. Try the suspend-twice test and see what happens. > > > > > > Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the > > > suspend-twice > > > test. > > > > Done, works (with USB_SUSPEND unset). > > Okay, good. Well, sorry. This test has been passed, but after a reboot it refused to suspend just once giving the same messages that I've got from the kernel with USB_SUSPEND set (the relevant dmesg output is attached). > Then for the next stage, repeat the same tests but with > USB_SUSPEND set. Compiling. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-first-suspend-failure.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 19:22, Alan Stern wrote: > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > Now USB didn't work after the first resume (kernel configured with > > USB_SUSPEND > > unset). > > > > The dmesg output is attached. > > This is getting too confusing. :-( Sorry for the confusion. > Let's try a simpler test. Leave USB_SUSPEND unset. > > First rmmod ohci-hcd. None of your full-speed USB devices will work, but > that's okay. Try the suspend-twice test and see what happens. > > Second, rmmod ehci-hcd and modprobe ohci-hcd. Again try the suspend-twice > test. Done, works (with USB_SUSPEND unset). Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 19:08, Rafael J. Wysocki wrote: > On Thursday, 14 September 2006 18:17, Alan Stern wrote: > > On Thu, 14 Sep 2006, Alan Stern wrote: > > > > > Now of course, the autosuspend stuff has to work properly no matter what > > > the kernel configuration is. I'll go back and rebuild the drivers with > > > USB_SUSPEND turned off and see what happens. With any luck I'll have a > > > fix ready in the near future. > > > > This should start fixing things, but I'm not certain it will solve the > > entire problem. If it doesn't work, send another dmesg log. > > Now USB didn't work after the first resume (kernel configured with USB_SUSPEND > unset). Okay, this is not reproducible, so I gather it was due to my other problem with the USB resume (sigh). Anyway, the second suspend/resume worked just fine, so the patch apparently helps. Thanks, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 18:17, Alan Stern wrote: > On Thu, 14 Sep 2006, Alan Stern wrote: > > > Now of course, the autosuspend stuff has to work properly no matter what > > the kernel configuration is. I'll go back and rebuild the drivers with > > USB_SUSPEND turned off and see what happens. With any luck I'll have a > > fix ready in the near future. > > This should start fixing things, but I'm not certain it will solve the > entire problem. If it doesn't work, send another dmesg log. Now USB didn't work after the first resume (kernel configured with USB_SUSPEND unset). The dmesg output is attached. Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-with-fix.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 17:04, Alan Stern wrote: > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > > > Try adding some ehci_dbg() lines in there (copy the form of the line > > > > just > > > > after restart:). We want to follow the value of > > > > hcd->self.root_hub->state. Initially it should be equal to > > > > USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is > > > > getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but > > > > almost > > > > certainly somewhere in this routine. If you can find out where that > > > > happens, I'd appreciate it. > > > > > > Done, but it shows hcd->self.root_hub->state is already 7 right after > > > restart. > > > > BTW, all of the systems on which the problem shows up seem to be 64-bit. > > > > If you can't reproduce it on a 32-bit system, some type casting may be wrong > > somewhere. > > I realized last night what the problem must be. It's extremely obvious in > retrospect, but I happen to have a blind spot in this particular area. > > All you guys must have CONFIG_USB_SUSPEND turned off. Mattis certainly > does; I checked his .config. Now I hardly ever do any testing without > CONFIG_USB_SUSPEND, since there's not much point working on power > management code if your kernel isn't set up to actually suspend devices. > As a result I missed seeing the problems caused by the autosuspend > changes. Well, on my box the USB suspend also doesn't work with USB_SUSPEND set, but the reason is different: sb usb2: 'global' suspend -16 hub 2-0:1.0: suspend error -16 suspend_device(): usb_suspend+0x0/0x5b [usbcore]() returns -16 Could not suspend device usb2: error -16 The .config and full dmesg output (with the three debug patches applied) are attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-usb-suspend.log.gz Description: GNU Zip compressed data kernel-config.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Thursday, 14 September 2006 15:14, Rafael J. Wysocki wrote: > On Wednesday, 13 September 2006 23:55, Alan Stern wrote: > > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: > > > > > > Try this patch instead. It looks for problems occurring a little > > > > earlier > > > > in the call chain. > > > > > > I've applied both patches at a time (I hope they don't conflict). > > > > > > The dmesg output is attached. > > > > The dmesg output shows the root-hub device state is set wrong. > > > > I have to leave now, so I can't give you another patch to try. You can > > experiment as follows... > > > > Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume(). The part of > > interest is everything following the "restart:" statement label. > > > > Try adding some ehci_dbg() lines in there (copy the form of the line just > > after restart:). We want to follow the value of > > hcd->self.root_hub->state. Initially it should be equal to > > USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is > > getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but almost > > certainly somewhere in this routine. If you can find out where that > > happens, I'd appreciate it. > > Done, but it shows hcd->self.root_hub->state is already 7 right after restart. BTW, all of the systems on which the problem shows up seem to be 64-bit. If you can't reproduce it on a 32-bit system, some type casting may be wrong somewhere. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 23:55, Alan Stern wrote: > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: > > > > Try this patch instead. It looks for problems occurring a little earlier > > > in the call chain. > > > > I've applied both patches at a time (I hope they don't conflict). > > > > The dmesg output is attached. > > The dmesg output shows the root-hub device state is set wrong. > > I have to leave now, so I can't give you another patch to try. You can > experiment as follows... > > Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume(). The part of > interest is everything following the "restart:" statement label. > > Try adding some ehci_dbg() lines in there (copy the form of the line just > after restart:). We want to follow the value of > hcd->self.root_hub->state. Initially it should be equal to > USB_STATE_SUSPENDED (= 8), and it shouldn't change. But somewhere it is > getting set to USB_STATE_CONFIGURED (= 7). I don't know where, but almost > certainly somewhere in this routine. If you can find out where that > happens, I'd appreciate it. Done, but it shows hcd->self.root_hub->state is already 7 right after restart. I've used the following patch to verify this: --- drivers/usb/host/ehci-pci.c |8 1 file changed, 8 insertions(+) Index: linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c === --- linux-2.6.18-rc6-mm2.orig/drivers/usb/host/ehci-pci.c +++ linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c @@ -291,14 +291,19 @@ static int ehci_pci_resume(struct usb_hc restart: ehci_dbg(ehci, "lost power, restarting\n"); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); usb_root_hub_lost_power(hcd->self.root_hub); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); /* Else reset, to cope with power loss or flush-to-storage * style "resume" having let BIOS kick in during reboot. */ (void) ehci_halt(ehci); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); (void) ehci_reset(ehci); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); (void) ehci_pci_reinit(ehci, pdev); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); /* emptying the schedule aborts any urbs */ spin_lock_irq(&ehci->lock); @@ -306,12 +311,15 @@ restart: ehci->reclaim_ready = 1; ehci_work(ehci, NULL); spin_unlock_irq(&ehci->lock); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); /* restart; khubd will disconnect devices */ retval = ehci_run(hcd); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); /* here we "know" root ports should always stay powered */ ehci_port_power(ehci, 1); + ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state); return retval; } The output of dmesg is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug-3.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Thursday, 14 September 2006 00:31, Pete Zaitcev wrote: > On Wed, 13 Sep 2006 14:44:48 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> > wrote: > > > This problem has already been identified by Pete Zaitcev in this thread: > > > > http://marc.theaimsgroup.com/?t=11576951281&r=1&w=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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 23:01, Alan Stern wrote: > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: > > > > The patch below will add some extra debugging information. We need to > > > find out why the resume didn't succeed. Oh -- and of course, you should > > > reinstate all those autosuspend patches. Otherwise this patch won't > > > apply! > > > > OK > > > > Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied. > > It covers two consecutive attempts to suspend (the second one obviously > > failed). > > Hmm... The patch didn't yield any output. Unlike Mattia's log, yours > doesn't include any lines saying "usb usb1: wakeup_rh" so I can't be sure > whether the patch code should have run or not. > > Try this patch instead. It looks for problems occurring a little earlier > in the call chain. I've applied both patches at a time (I hope they don't conflict). The dmesg output is attached. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug-2.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 20:38, Alan Stern wrote: > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: > > > Well, I have reproduced it with > > gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch > > reverted too. > > > > Attached is the output of dmesg from the failing case with USB_DEBUG set. > > It covers two attempts to suspend to disk, the second one being > > unsuccessful, > > with reloading the ohci_hcd module in between. [This kernel also has your > > other patch to prevent the second suspend from failing applied, but it > > doesn't > > help.] > > Okay. Your problem, and probably Mattia's too, is something other than > what that recent patch addressed. I can't tell from the dmesg log exactly > what went wrong, but I can tell you where to look. > > In drivers/usb/core/driver.c, resume_device() is not succeeding. That is, > the lines near the end which do > > if (status == 0) > udev->dev.power.power_state.event = PM_EVENT_ON; > > aren't running during the first resume. You can see this in the dmesg > log; lines 1173-1175 say > > usb usb1: resuming >usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1 > hub 1-0:1.0: PM: resume from 0, parent usb1 still 1 > > If power_state.event had gotten set to PM_EVENT_ON then the parent state > would be 0, not 1. This is the source of your problem. During your > second suspend attempt, usb1 didn't get handled correctly because its > state was set wrong. (I suspect the mishandling took place in usbcore > rather than the PM core, but it doesn't matter. The state should not have > been wrong to begin with.) Consequently its parent device :00:13.2 > refused to freeze, which aborted the suspend attempt. > > For the usb1 device, udriver->resume should point to the generic_resume() > routine in drivers/usb/core/generic.c. In fact, this should be true for > every device that driver.c:resume_device() sees. But generic_resume() > simply calls usb_port_resume() in hub.c, and the log doesn't contain any > of the USB debugging messages that usb_port_resume() would produce. So I > can't tell what happened. > > The patch below will add some extra debugging information. We need to > find out why the resume didn't succeed. Oh -- and of course, you should > reinstate all those autosuspend patches. Otherwise this patch won't > apply! OK Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied. It covers two consecutive attempts to suspend (the second one obviously failed). Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg-debug.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Wednesday, 13 September 2006 20:44, Alan Stern wrote: > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote: > > > 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every > > time (happens also on -rc6-mm1, does not happen on -rc7): > > > > Unable to handle kernel NULL pointer dereference at 0274 RIP: > > [] :ohci_hcd:ohci_hub_status_data+0x25/0x27b > > PGD 35ca9067 PUD 369a4067 PMD 0 > > > Call Trace: > > [] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b > > [] :ohci_hcd:ohci_irq+0xcb/0x210 > > [] :usbcore:usb_hcd_irq+0x2f/0x5f > > [] handle_IRQ_event+0x33/0x66 > > [] handle_fasteoi_irq+0x9d/0xe3 > > [] do_IRQ+0x104/0x11f > > [] ret_from_intr+0x0/0xa > > DWARF2 unwinder stuck at ret_from_intr+0x0/0xa > > > > Leftover inexact backtrace: > > > > [] sysfs_hash_and_remove+0x9/0x137 > > [] sysfs_remove_file+0x10/0x12 > > [] class_device_remove_file+0x12/0x14 > > [] :ohci_hcd:ohci_stop+0xf5/0x17b > > [] :usbcore:usb_remove_hcd+0xdc/0x114 > > [] klist_release+0x0/0x82 > > [] :usbcore:usb_hcd_pci_remove+0x1e/0x7d > > [] pci_device_remove+0x25/0x3c > > [] __device_release_driver+0x80/0x9c > > [] driver_detach+0xac/0xee > > [] bus_remove_driver+0x75/0x98 > > [] driver_unregister+0x15/0x21 > > [] pci_unregister_driver+0x13/0x8e > > [] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 > > [] sys_delete_module+0x1b5/0x1e6 > > [] 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 [] :ohci_hcd:ohci_hub_status_data+0x25/0x27b > > RSP > > CR2: 0274 > > <0>Kernel 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=11576951281&r=1&w=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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On 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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Wednesday, 13 September 2006 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: > [] :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:[] [] > :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: > [] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b > [] :ohci_hcd:ohci_irq+0xcb/0x210 > [] :usbcore:usb_hcd_irq+0x2f/0x5f > [] handle_IRQ_event+0x33/0x66 > [] handle_fasteoi_irq+0x9d/0xe3 > [] do_IRQ+0x104/0x11f > [] ret_from_intr+0x0/0xa > DWARF2 unwinder stuck at ret_from_intr+0x0/0xa > > Leftover inexact backtrace: > > [] sysfs_hash_and_remove+0x9/0x137 > [] sysfs_remove_file+0x10/0x12 > [] class_device_remove_file+0x12/0x14 > [] :ohci_hcd:ohci_stop+0xf5/0x17b > [] :usbcore:usb_remove_hcd+0xdc/0x114 > [] klist_release+0x0/0x82 > [] :usbcore:usb_hcd_pci_remove+0x1e/0x7d > [] pci_device_remove+0x25/0x3c > [] __device_release_driver+0x80/0x9c > [] driver_detach+0xac/0xee > [] bus_remove_driver+0x75/0x98 > [] driver_unregister+0x15/0x21 > [] pci_unregister_driver+0x13/0x8e > [] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 > [] sys_delete_module+0x1b5/0x1e6 > [] 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 [] :ohci_hcd:ohci_hub_status_data+0x25/0x27b > RSP > CR2: 0274 > <0>Kernel 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 on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325
On Tuesday, 12 September 2006 09:06, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/ 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every time (happens also on -rc6-mm1, does not happen on -rc7): Unable to handle kernel NULL pointer dereference at 0274 RIP: [] :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:[] [] :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: [] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b [] :ohci_hcd:ohci_irq+0xcb/0x210 [] :usbcore:usb_hcd_irq+0x2f/0x5f [] handle_IRQ_event+0x33/0x66 [] handle_fasteoi_irq+0x9d/0xe3 [] do_IRQ+0x104/0x11f [] ret_from_intr+0x0/0xa DWARF2 unwinder stuck at ret_from_intr+0x0/0xa Leftover inexact backtrace: [] sysfs_hash_and_remove+0x9/0x137 [] sysfs_remove_file+0x10/0x12 [] class_device_remove_file+0x12/0x14 [] :ohci_hcd:ohci_stop+0xf5/0x17b [] :usbcore:usb_remove_hcd+0xdc/0x114 [] klist_release+0x0/0x82 [] :usbcore:usb_hcd_pci_remove+0x1e/0x7d [] pci_device_remove+0x25/0x3c [] __device_release_driver+0x80/0x9c [] driver_detach+0xac/0xee [] bus_remove_driver+0x75/0x98 [] driver_unregister+0x15/0x21 [] pci_unregister_driver+0x13/0x8e [] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12 [] sys_delete_module+0x1b5/0x1e6 [] 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 [] :ohci_hcd:ohci_hub_status_data+0x25/0x27b RSP CR2: 0274 <0>Kernel 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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Wednesday, 13 September 2006 14:07, Rafael J. Wysocki wrote: > On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: > > On Friday, 8 September 2006 22:44, Alan Stern wrote: > > > On Fri, 8 Sep 2006, Andrew Morton wrote: > > > > > > > Alan, is this likely to be due to your USB PM changes? > > > > > > It's possible. Most of those changes are innocuous. They add routines > > > that don't get used until a later patch. However one of them might be > > > responsible. > > > > Well, after recompiling the kernel for several times (because of a different > > problem) I'm no longer able to reproduce the problem. > > I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens. > It's not readily reproducible, as I said before, and it apparently doesn't > happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch > reverted. Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted too. Attached is the output of dmesg from the failing case with USB_DEBUG set. It covers two attempts to suspend to disk, the second one being unsuccessful, with reloading the ohci_hcd module in between. [This kernel also has your other patch to prevent the second suspend from failing applied, but it doesn't help.] Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller dmesg.log.gz Description: GNU Zip compressed data - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: > On Friday, 8 September 2006 22:44, Alan Stern wrote: > > On Fri, 8 Sep 2006, Andrew Morton wrote: > > > > > Alan, is this likely to be due to your USB PM changes? > > > > It's possible. Most of those changes are innocuous. They add routines > > that don't get used until a later patch. However one of them might be > > responsible. > > Well, after recompiling the kernel for several times (because of a different > problem) I'm no longer able to reproduce the problem. I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens. It's not readily reproducible, as I said before, and it apparently doesn't happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch reverted. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote: > On Friday, 8 September 2006 22:44, Alan Stern wrote: > > On Fri, 8 Sep 2006, Andrew Morton wrote: > > > > > Alan, is this likely to be due to your USB PM changes? > > > > It's possible. Most of those changes are innocuous. They add routines > > that don't get used until a later patch. However one of them might be > > responsible. > > Well, after recompiling the kernel for several times (because of a different > problem) I'm no longer able to reproduce the problem. Now I have another symtom: during the _second_ suspend the suspending of USB controllers fails with messages like this: usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22 pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22 suspend_device(): pci_device_suspend+0x0/0x4b() returns -22 Could not suspend device :00:13.2: error -22 Could you please tell me which patches might have caused this, in your opinion? Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Friday, 8 September 2006 22:44, Alan Stern wrote: > On Fri, 8 Sep 2006, Andrew Morton wrote: > > > Alan, is this likely to be due to your USB PM changes? > > It's possible. Most of those changes are innocuous. They add routines > that don't get used until a later patch. However one of them might be > responsible. Well, after recompiling the kernel for several times (because of a different problem) I'm no longer able to reproduce the problem. Sorry for the noise. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc6-mm1
On Friday, 8 September 2006 10:13, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/ ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on 2.6.18-rc5-mm1. It helps if I rmmod and modprobe it after the resume. Here's the relevant part of the dmesg output: usb usb1: resuming usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1 hub 1-0:1.0: PM: resume from 0, parent usb1 still 1 hub 1-0:1.0: resuming usbdev1.1: PM: resume from 0, parent usb1 still 1 usb usb2: resuming usb usb2: root hub lost power or was reset usbdev2.1_ep00: PM: resume from 0, parent usb2 still 1 hub 2-0:1.0: PM: resume from 0, parent usb2 still 1 hub 2-0:1.0: resuming usbdev2.1: PM: resume from 0, parent usb2 still 1 usb usb3: resuming usb usb3: root hub lost power or was reset usbdev3.1_ep00: PM: resume from 0, parent usb3 still 1 hub 3-0:1.0: PM: resume from 0, parent usb3 still 1 hub 3-0:1.0: resuming usbdev3.1: PM: resume from 0, parent usb3 still 1 usb 2-2: PM: resume from 1, parent usb2 still 1 usb 2-2: resuming usbdev2.2_ep00: PM: resume from 0, parent 2-2 still 1 hci_usb 2-2:1.0: PM: resume from 1, parent 2-2 still 1 hci_usb 2-2:1.0: resuming usbdev2.2_ep81: PM: resume from 0, parent 2-2:1.0 still 1 usbdev2.2_ep82: PM: resume from 0, parent 2-2:1.0 still 1 usbdev2.2_ep02: PM: resume from 0, parent 2-2:1.0 still 1 hci_usb 2-2:1.1: PM: resume from 1, parent 2-2 still 1 hci_usb 2-2:1.1: resuming usb 2-2:1.2: PM: resume from 1, parent 2-2 still 1 usb 2-2:1.2: resuming usbdev2.2_ep84: PM: resume from 0, parent 2-2:1.2 still 1 usbdev2.2_ep04: PM: resume from 0, parent 2-2:1.2 still 1 usb 2-2:1.3: PM: resume from 1, parent 2-2 still 1 usb 2-2:1.3: resuming usbdev2.2: PM: resume from 0, parent 2-2 still 1 platform bluetooth: resuming usb 3-1: PM: resume from 1, parent usb3 still 1 usb 3-1: resuming usbdev3.2_ep00: PM: resume from 0, parent 3-1 still 1 usb 3-1:1.0: PM: resume from 1, parent 3-1 still 1 usb 3-1:1.0: resuming usbdev3.2_ep81: PM: resume from 0, parent 3-1:1.0 still 1 usbdev3.2_ep02: PM: resume from 0, parent 3-1:1.0 still 1 usbdev3.2: PM: resume from 0, parent 3-1 still 1 usb 3-4: PM: resume from 1, parent usb3 still 1 usb 3-4: resuming usbdev3.3_ep00: PM: resume from 0, parent 3-4 still 1 usbhid 3-4:1.0: PM: resume from 1, parent 3-4 still 1 usbhid 3-4:1.0: resuming usbdev3.3_ep81: PM: resume from 0, parent 3-4:1.0 still 1 usbdev3.3: PM: resume from 0, parent 3-4 still 1 usbdev2.2_ep83: PM: resume from 0, parent 2-2:1.1 still 1 usbdev2.2_ep03: PM: resume from 0, parent 2-2:1.1 still 1 hci0: PM: resume from 0, parent 2-2:1.0 still 1 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc1-mm2
On Friday 14 July 2006 20:36, Michal Piotrowski wrote: > Hi Andrew, > > On 14/07/06, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Fri, 14 Jul 2006 13:36:08 +0200 > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > Unable to handle kernel NULL pointer dereference at 0038 RIP: > > > [] __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:[] [] > > > __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: > > > [] lock_acquire+0x8b/0xc0 > > > [] _spin_lock+0x2f/0x40 > > > [] klist_remove+0x1f/0x50 > > > [] bus_remove_device+0xa7/0xe0 > > > [] device_del+0x149/0x180 > > > [] usb_disconnect+0x105/0x150 > > > [] hub_thread+0x616/0xfd0 > > > [] kthread+0xd9/0x110 > > > [] 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=lnk&kid=120709&bid=263057&dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18-rc1-mm2
On Friday 14 July 2006 07:48, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm2/ > > - Patches were merged, added, dropped and fixed. Nothing particularly > exciting. This happens on my box at startup, every time: ehci_hcd :00:02.2: EHCI Host Controller ehci_hcd :00:02.2: new USB bus registered, assigned bus number 3 ehci_hcd :00:02.2: debug port 1 ehci_hcd :00:02.2: irq 5, io mem 0xfebfdc00 ehci_hcd :00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb 2-1: USB disconnect, address 2 Unable to handle kernel NULL pointer dereference at 0038 RIP: [] __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:[] [] __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: [] lock_acquire+0x8b/0xc0 [] _spin_lock+0x2f/0x40 [] klist_remove+0x1f/0x50 [] bus_remove_device+0xa7/0xe0 [] device_del+0x149/0x180 [] usb_disconnect+0x105/0x150 [] hub_thread+0x616/0xfd0 [] kthread+0xd9/0x110 [] 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 [] __lock_acquire+0x7b/0xd30 RSP CR2: 0038 <6>note: 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=lnk&kid=120709&bid=263057&dat=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
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=lnk&kid=120709&bid=263057&dat=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
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
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
