Bug 193539

Summary: Problem Promise SATAII150 SX8
Product: [Fedora] Fedora Reporter: Alexandr Sadkov <saalan>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 5CC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-11 00:37:34 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 Alexandr Sadkov 2006-05-30 10:12:36 UTC
I am sorry for bad English.
Problem in work of module SX8.

Hardware:
SuperMicro 370DLE, 2xIntel PIII800EB
Promise SATAII150 SX8 (latest firmware 1.00.0.37, Command Query â Disabled)
System HDD - Western Digital WD1500ADFD (SATA)
Data HDD â 4 x Seagate Barracuda 7200.9 ST3500641AS (SATA)

The equipment was tested under Windows XP in various modes.
All perfectly worked except that it Windows...

In Fedora Core 5 kernels 2.6.16-1.2096_FC5smp, 2.6.16-1.2111_FC5smp and 
2.6.16-1.2122_FC5smp.

If to connect only system HDD Western Digital that all works, but I periodically 
receive messages of type:
cell kernel: end_request: I/O error, dev sx8/0, sector 220064
cell kernel: Buffer I/O error on device sx8/0, logical block 27508

If to connect all HDD it quickly enough leads to lag of one, several or all HDD 
connected to controller SX8. 
The system does not give out any mistakes, any operation with HDD leads to 
freezing of the console, helps only reset.

Following recommendations (google), I have tried to transfer module SX8 
parameter max_queue = 30. 
During loading the system has destroyed root file system. 

Having restored with Backup, I tried to establish max_queue = 2, that also have 
destroyed root file system.

Comment 1 Dave Jones 2006-09-11 00:37:34 UTC

*** This bug has been marked as a duplicate of 193538 ***