| Electronic Components Datasheet Search |
|
C200 Datasheet(PDF) 18 Page - Intel Corporation |
|
|
|||||||||||||||||||||||||||||
C200 Datasheet(HTML) 18 Page - Intel Corporation |
|
18 / 82 page ![]() Errata 18 Specification Update 6. Asynchronous Retries Prioritized Over Periodic Transfers Problem: The integrated USB RMH incorrectly prioritizes full-speed and low-speed asynchronous retries over dispatchable periodic transfers. Implication: Periodic transfers may be delayed or aborted. If the asynchronous retry latency causes the periodic transfer to be aborted, the impact varies depending on the nature of periodic transfer: • If a periodic interrupt transfer is aborted, the data may be recovered by the next instance of the interrupt or the data could be dropped. • If a periodic isochronous transfer is aborted, the data will be dropped. A single dropped periodic transaction should not be noticeable by end user. Note: This issue has only been seen in a synthetic environment. The USB spec does not consider the occasional loss of periodic traffic a violation. Workaround: None. Status: No Plan to Fix. 7. USB FS/LS Incorrect Number of Retries Problem: A USB low-speed Transaction may be retried more than three times, and a USB full-speed transaction may be retried less than three times if all of the following conditions are met: • A USB low-speed transaction with errors, or the first retry of the transaction occurs near the end of a microframe, and there is not enough time to complete another retry of the low-speed transaction in the same microframe. • There is pending USB full-speed traffic and there is enough time left in the microframe to complete one or more attempts of the full-speed transaction. • Both the low-speed and full-speed transactions must be asynchronous (Bulk/Control) and must have the same direction either in or out. Note: Note: Per the USB EHCI Specification a transaction with errors should be attempted a maximum of 3 times if it continues to fail. Implication: • For low-speed transactions the extra retry(s) allow a transaction additional chance(s) to recover regardless of if the full-speed transaction has errors or not. • If the full-speed transactions also have errors, the PCH may retry the transaction fewer times than required, stalling the device prematurely. Once stalled, the implication is software dependent, but the device may be reset by software. Workaround: None. Status: No Plan to Fix. |
|
Link URL |
| Does ALLDATASHEET help your business so far? [ DONATE ] |
About Alldatasheet | Advertisement | Contact us | Privacy Policy | Link to Datasheet | Link Exchange | Manufacturer List All Rights Reserved©Alldatasheet.com |
| Russian : Alldatasheetru.com | Korean : Alldatasheet.co.kr | Spanish : Alldatasheet.es | French : Alldatasheet.fr | Italian : Alldatasheetit.com Portuguese : Alldatasheetpt.com | Polish : Alldatasheet.pl | Vietnamese : Alldatasheet.vn Indian : Alldatasheet.in | Mexican : Alldatasheet.com.mx | British : Alldatasheet.co.uk | New Zealand : Alldatasheet.co.nz |
|
Family Site : ic2ic.com |
icmetro.com |