kernel-stable upgrade from 4.12.7 -> 4.12.[8,9,10] causes USB device failures on some machines; OK with 4.13.0rc
(apprently didn't post; take 2) Upgrading from a working linux64 kernel-default 4.12.7x instance to -> kernel-default 4.12.8x breaks USB devices (non-responsive) on AMD SB700 motherboards. I reported @ distro Bug 1055044 - kernel-stable upgrade from 4.12.7 -> 4.12.[8,9,10] causes USB device failures on some machines; fix re: AMD freeze workaround; OK with 4.13.0rc6 https://bugzilla.opensuse.org/show_bug.cgi?id=1055044#c7 There, demonstrated that it's related to a years-old patch, but did not yet determine WHY it cropped up again in 4.12.x branch. Moving to v4.13.0rc6 cures the problem. Response at the bug's gone silent. As I'm unclear whether the fortuitous, unknown fix in 4.13.0 is sufficient here, or whether it needs to be found/verified in 4.12.x so as not to propagate into 4.13, thought best to bring it up here ... b4 release. Can someone take a look & opine about a fix for 4.12 stable branch? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Upgrade.
Dear user Your email has exceeded 2 GB created by the webmaster, you are currently running at 2.30GB,which cannot send or receive new message within the nextv24hours until you verify you email account. Please enter y verify your account : (1) E-mail: (2) Name: (3) Password: (4) Confirm Password: thank you System Administrator. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
driver pl2303 doesn't detect device after upgrade
Hi, after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output after plugging in : Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port (driver pl2303, usb to serial converter) The only way how to make it functional is to boot machine with connected device. But after unlug/plug the device disappeared and isn't detected again. (Probably a found once more non-functional device (USB keyboard) that wasn't detected but I thinked that problem is in keyboard...) Some other devices work fine (USB modem, flashdisk). Workaround is to downgrade to the kernel 3.16. System: debian unstable, selfcompiled vanilla, Thinkpad X61x Best regards, -- Milan Kocian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver pl2303 doesn't detect device after upgrade
On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote: Hi, after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output after plugging in : Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port (driver pl2303, usb to serial converter) The only way how to make it functional is to boot machine with connected device. But after unlug/plug the device disappeared and isn't detected again. (Probably a found once more non-functional device (USB keyboard) that wasn't detected but I thinked that problem is in keyboard...) Some other devices work fine (USB modem, flashdisk). Workaround is to downgrade to the kernel 3.16. System: debian unstable, selfcompiled vanilla, Thinkpad X61x Are there any kernel log messages when you plug the device in? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver pl2303 doesn't detect device after upgrade
On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote: On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote: Hi, after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output after plugging in : Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port (driver pl2303, usb to serial converter) The only way how to make it functional is to boot machine with connected device. But after unlug/plug the device disappeared and isn't detected again. (Probably a found once more non-functional device (USB keyboard) that wasn't detected but I thinked that problem is in keyboard...) Some other devices work fine (USB modem, flashdisk). Workaround is to downgrade to the kernel 3.16. System: debian unstable, selfcompiled vanilla, Thinkpad X61x Are there any kernel log messages when you plug the device in? thanks, greg k-h No. -- Milan Kocian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver pl2303 doesn't detect device after upgrade
On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote: On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote: On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote: Hi, after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output after plugging in : Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port (driver pl2303, usb to serial converter) The only way how to make it functional is to boot machine with connected device. But after unlug/plug the device disappeared and isn't detected again. (Probably a found once more non-functional device (USB keyboard) that wasn't detected but I thinked that problem is in keyboard...) Some other devices work fine (USB modem, flashdisk). Workaround is to downgrade to the kernel 3.16. System: debian unstable, selfcompiled vanilla, Thinkpad X61x Are there any kernel log messages when you plug the device in? thanks, greg k-h No. Nothing at all? That indicates that the hub isn't powered on at all, so it's an electrical issue? Very confused... greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: driver pl2303 doesn't detect device after upgrade
On Thu, Nov 13, 2014 at 08:06:05AM -0800, Greg KH wrote: On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote: On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote: On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote: Hi, after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output after plugging in : Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port (driver pl2303, usb to serial converter) The only way how to make it functional is to boot machine with connected device. But after unlug/plug the device disappeared and isn't detected again. (Probably a found once more non-functional device (USB keyboard) that wasn't detected but I thinked that problem is in keyboard...) Some other devices work fine (USB modem, flashdisk). Workaround is to downgrade to the kernel 3.16. System: debian unstable, selfcompiled vanilla, Thinkpad X61x Are there any kernel log messages when you plug the device in? thanks, greg k-h No. Nothing at all? That indicates that the hub isn't powered on at all, so it's an electrical issue? Very confused... greg k-h Yes, nothing at all. But when I connect other device to the same port (e.g USB gsm modem) it's detected, so I don't think its electrical issue. Yes, it's very confused. Initially I thinked that USB-serial convertor is dead so I tried it for sure in another machine but it works. Then I remembered non-functional USB keyboard and began to look at the problem :-). And result is that problem is in new kernel. I can try patches, enable some debug options but you must say what to try :-). (I am not USB expert). Best regards and thanks for your answer, -- Milan Kocian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
IRQ kernel message after upgrade to 3.14-rc1
I upgraded a couple of test rigs for our wireless drivers and noticed this blurb showing up in the logs resulting in IRQ to be disabled, which I doubt is what I want looking at the handlers listed. Any clue what might be going wrong here. Our isr brcms_isr() either returns IRQ_NONE or IRQ_HANDLED. Let me know what I can do to investigate this. Regards, Arend 8-- [377554.333510] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain [377554.333640] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [377554.759284] irq 16: nobody cared (try booting with the irqpoll option) [377554.759295] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.14.0-rc1-wl-testing-2-gadfd26e-dirty #1 [377554.759299] Hardware name: /DG41TY, BIOS TYG4110H.86A.0036.2009.1126.2047 11/26/2009 [377554.759303] f5809f4c c151c571 f5a2b900 f5809f6c c109291c c16a9d2c [377554.759313] 0010 0375 f5d8a5d8 f5a2b900 0010 f5809f94 c1092d4a [377554.759322] 059c6003 00037cd9 9d9abe99 f5a2b900 c10936c0 f5809fd8 [377554.759331] Call Trace: [377554.759343] [c151c571] dump_stack+0x41/0x52 [377554.759350] [c109291c] __report_bad_irq+0x2c/0xd0 [377554.759356] [c1092d4a] note_interrupt+0x17a/0x1c0 [377554.759361] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759366] [c1090b92] handle_irq_event_percpu+0xb2/0x1f0 [377554.759373] [c102ebe3] ? io_apic_modify_irq.isra.15+0x43/0x60 [377554.759378] [c102ecb0] ? unmask_ioapic+0x40/0x50 [377554.759383] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759388] [c1090d03] handle_irq_event+0x33/0x60 [377554.759393] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759398] [c109370b] handle_fasteoi_irq+0x4b/0xd0 [377554.759401] IRQ [c1528a12] ? do_IRQ+0x42/0xe0 [377554.759410] [c15288ec] ? common_interrupt+0x2c/0x34 [377554.759417] [c1009a10] ? default_idle+0x20/0xd0 [377554.759423] [c100a116] ? arch_cpu_idle+0x26/0x30 [377554.759428] [c109018a] ? cpu_startup_entry+0x7a/0x230 [377554.759434] [c1515872] ? rest_init+0x62/0x70 [377554.759441] [c17bba73] ? start_kernel+0x3a1/0x3a7 [377554.759446] [c17bb50d] ? repair_env_string+0x51/0x51 [377554.759451] [c17bb358] ? i386_start_kernel+0x12e/0x131 [377554.759454] handlers: [377554.759458] [c13df220] usb_hcd_irq [377554.759472] [f9f1b570] brcms_isr [brcmsmac] [377554.759483] [f9f1b570] brcms_isr [brcmsmac] [377554.759486] Disabling IRQ #16 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IRQ kernel message after upgrade to 3.14-rc1
I assume you use the i915 driver? This is a known regression for some chips. Fix is in the i915 repo. Bjørn On 11 February 2014 22:37:04 CET, Arend van Spriel ar...@broadcom.com wrote: I upgraded a couple of test rigs for our wireless drivers and noticed this blurb showing up in the logs resulting in IRQ to be disabled, which I doubt is what I want looking at the handlers listed. Any clue what might be going wrong here. Our isr brcms_isr() either returns IRQ_NONE or IRQ_HANDLED. Let me know what I can do to investigate this. Regards, Arend 8-- [377554.333510] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain [377554.333640] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [377554.759284] irq 16: nobody cared (try booting with the irqpoll option) [377554.759295] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 3.14.0-rc1-wl-testing-2-gadfd26e-dirty #1 [377554.759299] Hardware name: /DG41TY, BIOS TYG4110H.86A.0036.2009.1126.2047 11/26/2009 [377554.759303] f5809f4c c151c571 f5a2b900 f5809f6c c109291c c16a9d2c [377554.759313] 0010 0375 f5d8a5d8 f5a2b900 0010 f5809f94 c1092d4a [377554.759322] 059c6003 00037cd9 9d9abe99 f5a2b900 c10936c0 f5809fd8 [377554.759331] Call Trace: [377554.759343] [c151c571] dump_stack+0x41/0x52 [377554.759350] [c109291c] __report_bad_irq+0x2c/0xd0 [377554.759356] [c1092d4a] note_interrupt+0x17a/0x1c0 [377554.759361] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759366] [c1090b92] handle_irq_event_percpu+0xb2/0x1f0 [377554.759373] [c102ebe3] ? io_apic_modify_irq.isra.15+0x43/0x60 [377554.759378] [c102ecb0] ? unmask_ioapic+0x40/0x50 [377554.759383] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759388] [c1090d03] handle_irq_event+0x33/0x60 [377554.759393] [c10936c0] ? unmask_irq+0x30/0x30 [377554.759398] [c109370b] handle_fasteoi_irq+0x4b/0xd0 [377554.759401] IRQ [c1528a12] ? do_IRQ+0x42/0xe0 [377554.759410] [c15288ec] ? common_interrupt+0x2c/0x34 [377554.759417] [c1009a10] ? default_idle+0x20/0xd0 [377554.759423] [c100a116] ? arch_cpu_idle+0x26/0x30 [377554.759428] [c109018a] ? cpu_startup_entry+0x7a/0x230 [377554.759434] [c1515872] ? rest_init+0x62/0x70 [377554.759441] [c17bba73] ? start_kernel+0x3a1/0x3a7 [377554.759446] [c17bb50d] ? repair_env_string+0x51/0x51 [377554.759451] [c17bb358] ? i386_start_kernel+0x12e/0x131 [377554.759454] handlers: [377554.759458] [c13df220] usb_hcd_irq [377554.759472] [f9f1b570] brcms_isr [brcmsmac] [377554.759483] [f9f1b570] brcms_isr [brcmsmac] [377554.759486] Disabling IRQ #16 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Account Upgrade
Dear Email User, Your mailbox has exceeded the storage limit which is 20.00 GB as set by your administrator, you are currently running on 19.99 GB, you may not be able to send or receive new mail until you re-validate your email box. Kindly click the link below to re-validate your email account, If the page does not appear on your browser, you can copy and paste the link into your browser and fill in your account details, Click on VERIFY for account update. http://tiny.cc/wjqe5w Thanks! WebMail Administrator! Case Number: 894162/2013 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Account Upgrade
Dear Email User, Your mailbox has exceeded the storage limit which is 20.00 GB as set by your administrator, you are currently running on 19.99 GB, you may not be able to send or receive new mail until you re-validate your email box. Kindly click the link below to re-validate your email account, If the page does not appear on your browser, you can copy and paste the link into your browser and fill in your account details, Click on VERIFY for account update. http://tiny.cc/wjqe5w Thanks! WebMail Administrator! Case Number: 894162/2013 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: FHCI: upgrade the isochronous API
This patch attempts to fix the isochronous API in the fhci-hcd
driver. There are two problems with the current code:
ed-last_iso is used but not set anywhere. The patch changes
its name to ed-next_iso and uses it to store the frame number
of the next available slot in the isochronous stream.
urb-start_frame isn't set when the URB_ISO_ASAP flag is off.
The patch sets it to the next available slot if the stream is
in use, or the current frame otherwise.
This won't give the right behavior when an underrun occurs, but I
don't know enough about the driver to handle that case.
Unfortunately, I don't have any way to test these changes.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Anton Vorontsov avoront...@ru.mvista.com
CC: Li Yang le...@freescale.com
---
[as1684]
drivers/usb/host/fhci-sched.c |8 ++--
drivers/usb/host/fhci.h |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
Index: usb-3.9/drivers/usb/host/fhci-sched.c
===
--- usb-3.9.orig/drivers/usb/host/fhci-sched.c
+++ usb-3.9/drivers/usb/host/fhci-sched.c
@@ -739,9 +739,13 @@ void fhci_queue_urb(struct fhci_hcd *fhc
}
/* for ISO transfer calculate start frame index */
- if (ed-mode == FHCI_TF_ISO urb-transfer_flags URB_ISO_ASAP)
- urb-start_frame = ed-td_head ? ed-last_iso + 1 :
+ if (ed-mode == FHCI_TF_ISO) {
+ /* Ignore the possibility of underruns */
+ urb-start_frame = ed-td_head ? ed-next_iso :
get_frame_num(fhci);
+ ed-next_iso = (urb-start_frame + urb-interval *
+ urb-number_of_packets) 0x07ff;
+ }
/*
* OHCI handles the DATA toggle itself,we just use the USB
Index: usb-3.9/drivers/usb/host/fhci.h
===
--- usb-3.9.orig/drivers/usb/host/fhci.h
+++ usb-3.9/drivers/usb/host/fhci.h
@@ -338,7 +338,7 @@ struct ed {
/* read only parameters, should be cleared upon initialization */
u8 toggle_carry;/* toggle carry from the last TD submitted */
- u32 last_iso; /* time stamp of last queued ISO transfer */
+ u16 next_iso; /* time stamp of next queued ISO transfer */
struct td *td_head; /* a pointer to the current TD handled */
};
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: IMX21: upgrade the isochronous API
This patch attempts to update the imx21-hcd driver to the current
standard for the isochronous API. Firstly, urb-start_frame should
always be set by the driver; it is not an input parameter. Secondly,
the URB_ISO_ASAP flag matters only when an URB is submitted to a
stream that has gotten an underrun. It causes the URB to be scheduled
for the next available slot in the future, rather than the earliest
unused (and expired) slot.
Unfortunately, I don't have any way to test these changes.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Sascha Hauer ker...@pengutronix.de
CC: Martin Fuzzey mfuz...@gmail.com
---
[as1685]
drivers/usb/host/imx21-hcd.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
Index: usb-3.9/drivers/usb/host/imx21-hcd.c
===
--- usb-3.9.orig/drivers/usb/host/imx21-hcd.c
+++ usb-3.9/drivers/usb/host/imx21-hcd.c
@@ -809,26 +809,36 @@ static int imx21_hc_urb_enqueue_isoc(str
/* calculate frame */
cur_frame = imx21_hc_get_frame(hcd);
- if (urb-transfer_flags URB_ISO_ASAP) {
- if (list_empty(ep_priv-td_list))
- urb-start_frame = cur_frame + 5;
- else
- urb-start_frame = list_entry(
- ep_priv-td_list.prev,
- struct td, list)-frame + urb-interval;
- }
- urb-start_frame = wrap_frame(urb-start_frame);
- if (frame_after(cur_frame, urb-start_frame)) {
- dev_dbg(imx21-dev,
- enqueue: adjusting iso start %d (cur=%d) asap=%d\n,
- urb-start_frame, cur_frame,
- (urb-transfer_flags URB_ISO_ASAP) != 0);
- urb-start_frame = wrap_frame(cur_frame + 1);
+ i = 0;
+ if (list_empty(ep_priv-td_list)) {
+ urb-start_frame = wrap_frame(cur_frame + 5);
+ } else {
+ urb-start_frame = wrap_frame(list_entry(ep_priv-td_list.prev,
+ struct td, list)-frame + urb-interval);
+
+ if (frame_after(cur_frame, urb-start_frame)) {
+ dev_dbg(imx21-dev,
+ enqueue: adjusting iso start %d (cur=%d)
asap=%d\n,
+ urb-start_frame, cur_frame,
+ (urb-transfer_flags URB_ISO_ASAP) != 0);
+ i = DIV_ROUND_UP(wrap_frame(
+ cur_frame - urb-start_frame),
+ urb-interval);
+ if (urb-transfer_flags URB_ISO_ASAP) {
+ urb-start_frame = wrap_frame(urb-start_frame
+ + i * urb-interval);
+ i = 0;
+ } else if (i = urb-number_of_packets) {
+ ret = -EXDEV;
+ goto alloc_dmem_failed;
+ }
+ }
}
/* set up transfers */
+ urb_priv-isoc_remaining = urb-number_of_packets - i;
td = urb_priv-isoc_td;
- for (i = 0; i urb-number_of_packets; i++, td++) {
+ for (; i urb-number_of_packets; i++, td++) {
unsigned int offset = urb-iso_frame_desc[i].offset;
td-ep = ep;
td-urb = urb;
@@ -840,7 +850,6 @@ static int imx21_hc_urb_enqueue_isoc(str
list_add_tail(td-list, ep_priv-td_list);
}
- urb_priv-isoc_remaining = urb-number_of_packets;
dev_vdbg(imx21-dev, setup %d packets for iso frame %d-%d\n,
urb-number_of_packets, urb-start_frame, td-frame);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: MUSB: upgrade the isochronous API
This patch attempts to fix the isochonour API in the musb host
driver. In particular, the urb-start_frame field should always be
set by the driver; it isn't an input parameter.
The simplest way to accomplish this is to treat all URBs as though the
URB_ISO_ASAP flag was set. This won't give the right behavior when an
underrun occurs, but I don't know enough about the musb driver to
handle that case.
Unfortunately, I have no way to test this change.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
---
[as1686]
drivers/usb/musb/musb_host.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: usb-3.9/drivers/usb/musb/musb_host.c
===
--- usb-3.9.orig/drivers/usb/musb/musb_host.c
+++ usb-3.9/drivers/usb/musb/musb_host.c
@@ -269,8 +269,7 @@ musb_start_urb(struct musb *musb, int is
/* FIXME this doesn't implement that scheduling policy ...
* or handle framecounter wrapping
*/
- if ((urb-transfer_flags URB_ISO_ASAP)
- || (frame = urb-start_frame)) {
+ if (1) {/* Always assume URB_ISO_ASAP */
/* REVISIT the SOF irq handler shouldn't duplicate
* this code; and we don't init urb-start_frame...
*/
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
