Bug 4785
Summary: | Errors when using firewire disk on ppc32 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Anton Blanchard (anton) |
Component: | IEEE1394 | Assignee: | Ben Collins (bcollins) |
Status: | REJECTED UNREPRODUCIBLE | ||
Severity: | normal | CC: | akpm, stefanr |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.12-git (20050623) | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Anton Blanchard
2005-06-23 08:55:20 UTC
Is this still happening in 2.6.13-rc4? Thanks. Does one of the hints given at http://www.linux1394.org/faq.php#sbp2abort help? Thanks for the suggestions. It looks like current -git is working fine. If I can recreate I'll reopen <looks at the webpage>. Why on earth does the use of the CFQ I/O scheduler help? How exactly the CFQ scheduler helps is unknown. It helped only in _some_ cases of "aborting sbp2 command syndrom" anyway. Keep in mind that there are three fundamentally different classes of causes for the syndrom, like the FAQ says. I have two hypotheses how the CFQ scheduler might make a difference: a) It might enqueue commands in a way that is easier to process for some firmwares of SBP-2 bridges. b) It may mask a weakness or bug in sbp2 that is somehow related to I/O latency. I have even seen once that reducing the 1394 bus arbitration gaps stopped a series of "aborting sbp2 command"s. Back to Anton's case: It seems very unlikely to me that the two suggestions of the FAQ which modify the behaviour of the Linux initiator (serialized I/O, CFQ scheduler) help in a situation where "aborting sbp2 command" appears together with "sbp2util_node_write_no_wait failed". But there are other suggestions in the FAQ that might apply. |