Bug 163031
Summary: | iPod difficulties on 2.6.9-11.EL, iPod works great on prior 2.6.9-5.0.5.EL | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | brian mccue <bmccue> | ||||
Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4.0 | CC: | jbaron, kent, matt_domsch, rmonk, zaitcev | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-12-02 15:58:13 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: | |||||||
Attachments: |
|
Description
brian mccue
2005-07-12 12:24:28 UTC
hmmm. Can you please try and test our latest rhel4 u2 kernel. http://people.redhat.com/~jbaron/rhel4/ thanks, -Jason I tried the latest kernel that you posted with no luck. One of the things that I have noticed is that the kernel needs to be compiled with CONFIG_EFI_PARTITION disabled. I have had some luck with that, but no consistent hits though. hmmm, there was a 'large' patch against efi in U1: linux-2.6.9-gpt-partition-noprobe.patch. That patch brought us into line with the upstream code. and fixes a serious off-by-one error. I belived by passing 'gpt' at the command line you can restore the old behavior. Well, the problem is that I put a lot of work into getting my systems working with my iPod. I don't want to try anything else unless something has been found different between 2.6.9-5.EL and 2.6.9-11.EL. In -11.EL, I could get it to recognize the iPod very occasionally (1 in 10 times, at best). Even when I could get it to recognize it, I could not disconnect it without rebooting. Hope this helps. Jason, -11 doesn't have all the Apple iPod drivers/usb/storage/unusual_devs.h workarounds that are in mainline. Specifically these are to deal with the fact that it misreports its size by one sector. The kernel partitioning code is OK now, but other items (kernel or userspace) that care won't work without this patch. Kent, what does your /proc/bus/usb/devices show when the device is plugged in and working (even on -5.0.5) ? --- linux-2.6.9-11.EL/drivers/usb/storage/unusual_devs.h Fri May 27 14:58:04 2005 +++ linux-2.6.9-11.EL/drivers/usb/storage/unusual_devs.h Tue Aug 9 22:58:07 2005 @@ -414,8 +525,32 @@ 0 ), #endif +/* Submitted by Sven Anderson <sven-linux> + * There are at least four ProductIDs used for iPods, so I added 0x1202 and + * 0x1204. They just need the US_FL_FIX_CAPACITY. As the bcdDevice appears + * to change with firmware updates, I changed the range to maximum for all + * iPod entries. + */ +UNUSUAL_DEV( 0x05ac, 0x1202, 0x0000, 0x9999, + "Apple", + "iPod", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY ), + /* Reported by Avi Kivity <avi.il> */ -UNUSUAL_DEV( 0x05ac, 0x1203, 0x0001, 0x0001, +UNUSUAL_DEV( 0x05ac, 0x1203, 0x0000, 0x9999, + "Apple", + "iPod", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY ), + +UNUSUAL_DEV( 0x05ac, 0x1204, 0x0000, 0x9999, + "Apple", + "iPod", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_FIX_CAPACITY ), + +UNUSUAL_DEV( 0x05ac, 0x1205, 0x0000, 0x9999, "Apple", "iPod", US_SC_DEVICE, US_PR_DEVICE, NULL, Created attachment 117606 [details]
/proc/bus/usb/devices file with iPod attached
I've attached my /proc/bus/usb/devices. I tried that fix to unusual-devs.h in .11-EL with no success. To describe what would happen consistently is this. I would attach my iPod. It would be detected and usb_storage would attempt to load. If I disconnected my iPod at that time, usb_storage would finish loading. Otherwise, it would not. When I reconnect the iPod, 90% of the time, the system would not even recognize that it had been plugged back in. The other 10% of the time, it would typically load ok. However, once I disconnect it, I could never reconnect it and get it to even be recognized by the system. (In reply to comment #7) I have identical issues with my 4th gen 20Gb iPod photo. So far, I have tried the following: 2.6.9-11 -> no go 2.6.9-11 with patched unusual_devs.h -> no go 2.6.9-22 -. no go 2.6.9-22 without RFI -> no go 2.6.9-22 with patched unusual_devs.h -> no go 2.6.9-22 without RFI and with patched unusual_devs.h -> no go 2.6.9-5.0.5 -> it tried to work, but lots of sda block errors. I think this is the error the unusual_devs.h patch is supposed to fix. I'll post an update when I try this. 2.6.9-5.0.5 + patched unusual_devs.h works just fine. Something I noticed: I loaded 2.6.9-5.0.5 and insmodded the patched usb-storage.ko from 2.6.9-11. It acted -exactly- like 2.6.9-11 (see comment #7). could there be something that changed in usb-storage between those two that has broken it? I tend to agree with that supposition. To get -5.0.5 to work all the time for any usb device, I had to recompile it with CONFIG_EFI_PARTITION set to N. Hope this helps. I was able to get it working reliably with stock 2.6.9-22 by using the usb-storage.ko from stock 2.6.9-5.0.5 that had the patched unusual_devs.h. it's not EFI, it must be something inside usb-storage that's broken between 5.0.5 and 11/22. Ideas? This is a well known problem. Certain iPods fail because of halt clearing which I added to fix a problem with installations from a USB device to a SCSI based system, see bug 129165. Dell's favourite CD TEAC-210PU was later found to have an issue with this, so I made an exclusion, see bug 155870. However, continuting these exclusions sounds not sustainable, so I am looking at an entirely different fix. Not all iPods fail: my own 3rd Gen white 10GB works, but my daughter's Mini fails. This is a telltale sign of the bug I'm talking about. We still do not know if Brian's problem is this one, as the bug was taken over by more active users... See also bug 160308, which may be the same problem (DO NOT DUP!). ping - is this still a problem? Closing, this has gone cold. |