Bug 663186
Summary: | USB disconnects | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | purpleidea |
Component: | kernel | Assignee: | David Woodhouse <dwmw2> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 14 | CC: | codemonkey, csaavedra, dougsland, gansalmon, grgoffe, itamar, jonathan, kernel-maint, madhu.chinakonda, purpleidea |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | kernel-2.6.35.14-100.fc14 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-10-30 00:30:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
purpleidea
2010-12-14 22:04:05 UTC
Do you have the same issue if you boot with intel_iommu=off? Hi Kyle, I apologize for my slow response, I was AFK and then busy for far too long. While testing today with intel_iommu=off, I haven't yet encountered the problem, and looking good so far! Can you provide any more info, and/or can I provide any more info to ultimately fix the underlying problem? Thanks, James Hi, I think I'm having the same problem but with completely different HW and device. I'm trying to copy many files (some large) to a microsd and after awhile (during copying) the device goes offline with a message like... Device offlined - not ready after error recovery ...the device remains mounted but the driver says... rejecting I/O to offline device ...many times and eventually the prog doing the copying (rsync, in my case) dies with i/o errors. To recover I need to umount, remove and reinsert the card, run fsck.vfat to fix the errors, re-mount, and then I can retry the copy operation, which gets a little farther but eventually dies again the same way. According to a thread on ubuntuforums (http://ubuntuforums.org/showthread.php?t=1214003#2) the problem is a bug in ehci_hcd and the following provides a work-around that works for me... echo -n 0000:00:02.2 > /sys/bus/pci/drivers/ehci_hcd/unbind ...(where '0000:00:02.2' is the usb 2.0 interface on my device). Of course, my i/o is then at usb 1.1 speeds, but at least I can complete the transfer. I will try intel_iommu=off and get back... ~ray intel_iommu=off did not work for me.. BTW, forgot to mention, I'm running an up-to-date Fedora 14, 32 bit AMD w/ nvidia chipset. ~ray I've been trying to troubleshoot something similar on F15 and I believe Bug 671923, Bug 718077, Bug 720054 are all duplicates of this bug. I've actually googled my way to this: https://bugzilla.kernel.org/show_bug.cgi?id=32432 Applying this patch takes care of the problem for me: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fgregkh%2Fusb-2.6.git;a=commitdiff_plain;h=004c19682884d4f40000ce1ded53f4a1d0b18206 Yun-Fong, This does look/sound like my problem. It STILL comes and goes and appears to be related to heavy I/O. How did you apply the patch you mention above? I'm using the latest FC 14 Kernel. Regards and thanks for your help (in advance). George... > How did you apply the patch you mention above? I'm using the latest FC 14 > Kernel. > > Regards and thanks for your help (in advance). > > George... Sorry to be brief but I'm getting ready to leave for vacation and won't really be able to be more detailed. Basically, I downloaded the kernel source with yumdownloader, unpacked it, added two patches (this one: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fgregkh%2Fusb-2.6.git;a=commitdiff_plain;h=1e12c910eed82da6971f1c0421a069c680faba2e, first, then the one above 2nd) to my own kernel.spec and generated a new source and used rpmbuild to build the package. This has more detailed instructions: http://fedoraproject.org/wiki/Building_a_custom_kernel Hi, I put this "intel_iommu=off" in my system on Friday... I have not seen this problem since then. FC 14, latest updates... 2.6.35.13-92.fc14.i686 #1 SMP Sat May 21 17:39:42 UTC 2011 i686 GNU/Linux I will report on this situation if it changes. Regards, George... F15 kernel 2.6.40.3-4 has the fix I mentioned. Hi, I'm still running FC 14. I added the intel_iommu=off to my grub kernel line. The problem has almost become non existent. I say almost because I occasionally experience this problem on the second usb/sata drive (sdb and sdc), it's sdc that has the problem but this is quite rare. THANKS for your help with this, George... Hi, The bug seems to have returned. I updated my FC14 system with their latest kernel and within 12 hours experienced this same problem. intel_iommu=off was specified on the kernel line of the grub.conf file. George... Do you need other settings? Other debug output? Please let me know and I'll try to get it for you. *** Bug 671923 has been marked as a duplicate of this bug. *** George, I've started a scratch build of the f14 kernel that has the two highlighted fixes backported to it. When this finishes, you might want to give it a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=3329354 Josh, Thank you SO MUCH! I'm downloading now and will test soon. You didn't mention whether I should retain the intel_iommu=off flag or not so I'll try both ways, first without then with. Regards, George... This is happening to me in F15 with 2.6.40.6-0.fc15.x86_64. I *think* it usually happens when my x201 is on it's dockstation, but I can't be so sure. Afterwards, USB drives are no longer recognized. This works it around: echo -n 0000:00:1a.0 > /sys/bus/pci/drivers/ehci_hcd/unbind echo -n 0000:00:1a.0 > /sys/bus/pci/drivers/ehci_hcd/bind Hi, Is this new code in the latest FC14 kernel? George... (In reply to comment #16) > Hi, > > Is this new code in the latest FC14 kernel? > > George... No. You didn't come back and let us know if it was working or not. The two commits that were backported for the scratch build were: 1e12c910eed82da6971f1c0421a069 004c19682884d4f40000ce1ded53f41 Josh, Oh man! I really fell down on this. Please accept my apologies. The test, I guess, kernel has been working WONDERFULLY. The newer kernel has shown some failures like this one but not as many. As far as I'm concerned, please push your fix from the test kernel to "production". I'm on a different system now, temporarily I hope, since I ran yum update last night and picked up something that breaks my X11 server so I have NO gui. Sigh. I haven't been able to make a bug report about this though. Regards, George... (In reply to comment #18) > Josh, > > Oh man! I really fell down on this. Please accept my apologies. No worries. > The test, I guess, kernel has been working WONDERFULLY. The newer kernel has > shown some failures like this one but not as many. Good to hear. > As far as I'm concerned, please push your fix from the test kernel to > "production". I've added the changes. They should be in the next official F14 kernel build. kernel-2.6.35.14-100.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.14-100.fc14 Josh, You are the MAN! Thanks, George... Package kernel-2.6.35.14-100.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-2.6.35.14-100.fc14' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14747 then log in and leave karma (feedback). kernel-2.6.35.14-100.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. Josh, Are you still around? Did your code make it to the FC16 kernels by any chance? I'm seeing similar behavior in my newly upgraded FC16 x86_64 system at this kernel: 3.1.5-6.fc16.x86_64 I'll try the intel_iommu=off workaround and report here. Regards, George... (In reply to comment #24) > Josh, > > Are you still around? > > Did your code make it to the FC16 kernels by any chance? Yes. Both commits are included in the 3.1 kernel, which is what F16 is based on. Josh, Happy New Year! I gave up on FC16 and went to FC14-x86_64... and then started having this problem. Did your changes make it into the FC14 kernel? 2.6.35.14-106.fc14.x86_64 If not, would it be too much of a hassle to get the FC14 kernel updated too? Regards, George... (In reply to comment #26) > Josh, > > Happy New Year! > > I gave up on FC16 and went to FC14-x86_64... and then started having this > problem. > > Did your changes make it into the FC14 kernel? 2.6.35.14-106.fc14.x86_64 They did. > If not, would it be too much of a hassle to get the FC14 kernel updated too? F14 is EOL now. There will be no more kernel updates (or any other updates) for F14. |