From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; Q312461)
Description of problem:
When using the standard kernel & modules it seems like data block are not being
flushed to disk. The i2o drivers hangs.
Version-Release number of selected component (if applicable):2.4.7-10
Steps to Reproduce:
1.Run the 2.4.7-10 sandard kernel and dump a large amount (>100MB) to disk.
Actual Results: The machine is unable to read or write any data to disk.
for i2o it is recommended to use the erratum kernel 2.4.9-31.
Version-Release number of selected component (if applicable):2.4.9-31
I can reproduce the problem on two different boxes. The boxes are Intel Quad
Xeon (P3), the platform is the "4-way Intel SRKA4".
They use the Intel Server i2o RAID U3-1 controller.
With the 2.4.9-13 errata kernel, I did NOT have the problem. I never tried the
-21 errata kernel, but the 2.4.9-31 errata kernel definately has the hang.
I've got a collection of known problems with the intel SCU2. Intel have
discontinued it and don't appear keen on helping debug it. The traces I have
show us issuing the card a command and the board then stopping talking to us.
Its definitely related to long linear writes.
I've been doing a fair bit of I2O rewriting to clean up all the crud and have
fixed a few things along the way. Unfortunately I don't think I've fixed
anything which would explain why this specific card fails
I take back the comment about -13 working. I just rebooted to it and tried to
copy a 500MB apache log file located on the raid volume to another dir on the
The new file stopped growing after about 190MB or so. The "cp" command became
unkillable even with '-9'.
ps -eo name,wchan showed the cp in "lock_page".
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at
Changing bug status to ASSIGNED.
There is simply insufficient info to fix this problem. Plus I am informed by
Intel that their later firmware no longer uses i2o but gdth