+++ This bug was initially created as a clone of Bug #651332 +++ On AMD SB700/SB800/Hudson-2/3 platforms, USB EHCI controller may read/write to memory space not allocated to USB controller if there is longer than normal latency on DMA read encountered. In this condition the exposure will be encountered only if the driver has following format of Periodic Frame List link pointer structure: For any idle periodic schedule, the Frame List link pointers that have the T-bit set to 1 intending to terminate the use of frame list link pointer as a physical memory pointer. Idle periodic schedule Frame List Link pointer shoule be in the following format to avoid the issue: Frame list link pointer should be always contains a valid pointer to a inactive QHead with T-bit set to 0. Steps to Reproduce: It is SW workaround of HW issue, it is difficult to reproduce from driver point. Patch has been accepted by EHCI maintainer: http://www.spinics.net/lists/linux-usb/msg38405.html http://www.spinics.net/lists/linux-usb/msg38414.html --- Additional comment from shane.huang on 2010-11-09 04:47:33 EST --- We will provide the git link here once it is available, suppose the patch will appear from kernel 2.6.37 if everything is ok.
Created attachment 462287 [details] ehci_frame_list_fix_RHEL4.patch Please find the patch attached.
Here is the git link, which will appear from 2.6.37: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3d091a6f703906c5680855ff29bd94d051c8c6d8
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Shane, when this is added to one of our official builds can AMD test?
Yes, we can test it, please provide us the test rpm packages. thanks
Committed in 96.EL . RPMS are available at http://people.redhat.com/dhoward/rhel4/
Verified OK with kernel-smp-2.6.9-96.EL.x86_64.rpm, thanks.
(In reply to comment #9) > Verified OK with kernel-smp-2.6.9-96.EL.x86_64.rpm, thanks. Hi, any reproducing step for our Red Hat QE to reproduce/verify the bug? If no, I think we'd do code review only.
Caspar, Since this issue is difficult to be reproduced under Linux, you can only check the dmesg after system boot. If you see such message below on boards with SB700/SB800 or Hudson-2/3, then the fix works. "applying AMD SB700/SB800 USB dummy qh workaround" or "applying AMD Hudson-2/3 USB dummy qh workaround"
(In reply to comment #11) > Caspar, > > Since this issue is difficult to be reproduced under Linux, > you can only check the dmesg after system boot. > If you see such message below on boards with SB700/SB800 or Hudson-2/3, > then the fix works. > "applying AMD SB700/SB800 USB dummy qh workaround" or > "applying AMD Hudson-2/3 USB dummy qh workaround" Thanks Shane! Does that mean we could only confirm the bug is fixed in new kernel but no way to reproduce in buggy kernel?
Yes, I think so.
Caspar, Can you help to check why there is no update to BZ #651333, which is the similar fix for RHEL 5.x? Thanks,
(In reply to comment #14) > Caspar, > > Can you help to check why there is no update to BZ #651333, > which is the similar fix for RHEL 5.x? > > Thanks, I can answer that. :-) RHEL-5 just shipped so I was focusing on the RHEL's that have deadlines. I can try to post the RHEL-5 next week or so. I don't think there is a rush just yet. Cheers, Don
According to comment 11,test on a new kernel version,2.6.9-96.ELlargesmp, test procedure: [root@hp-dl585g7-01 ~]# dmesg | grep "applying AMD SB700/SB800 USB dummy qh workaround" ehci_hcd 0000:00:12.2: applying AMD SB700/SB800 USB dummy qh workaround ehci_hcd 0000:00:13.2: applying AMD SB700/SB800 USB dummy qh workaround from the output, we can see there is no problem existed on kernel 2.6.9-96.ELlargesmp . And because Shane said the bug is difficult to be reproduced on old version and there is no way to verify the situation on new version. So we just verify as above way on new kernel version. According to comment 9,change the bug status to verified on kernel 2.6.9-96.ELlargesmp.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0263.html