H/W availability: Prototype units will becoming available starting in late January. HP has plans to make systems available to RH.
*** This bug has been marked as a duplicate of 112063 ***
*** Bug 112066 has been marked as a duplicate of this bug. ***
Argh, reopening due to recursive duplicates.
Feature review meeting waiting for code and hardware so putting in needinfo
Jeff has all required ICH6 documentation. He had an ICH6 system from Dell, but Dell needed it back. We've got an ICH6 system (Copper River) coming from Intel, but it's not here yet 2 weeks and 2 days before dev close for U2. I've requested that this ship from Intel overnight (today) to Jeff.
Ditto comments in 112062 about ICH5 SATA RAID: kernel portion is OK to add, but the installer portion may not be ready by U2. Still waiting on ICH6 hardware, should arrive today.
Note: created corresponding bug #115265 to represent the corresponding installer portion.
Re-opening and throwing back into New Requests bucket for RHEL 3 U3.
And this from Jeff Garzik in response on 1 March 04: March 01: Wanted to also make it clear that we will be providing ACHI support in simple -- not full -- mode only in U2. We have deferred "full mode" AHCI support to U3. And to re-confirm: We ARE providing all necessary ICH5R/6R *hardware* support in U2. We discussed all of the above during a phone call today with Steve Carbonari and Dave Patterson; will also confirm this in email today and copy Shan Hemphill, Keve, and Diana.
Created attachment 99882 [details] ICH6R patch (simplified, plus short doc)
Sent to Intel 5/24: Urgent: We need Intel to provide a patch built against RHEL 3 codebase (not just upstream) that **safely maintains compatibility**. The iswraid feature was posted to rhkernel-list a while ago and upon review, RH kernel engineers found some problems that could cause data corruption. These exact same problems still exist. The author of the patch at Intel was correct in saying that the patch as posted (why isn't it attached here in the IT?) doesn't introduce data corruption. The problem lies in the upstream 2.4.x having a special "BH_Sync" flag that RHEL 3 cannot add without breaking a key ABI data structure. So the data corruption comes in via the backport of the patch to RHEL 3. Putting this same note in FZ 112062 for "RHEL 3 U3 ICH5R SATA" support feature request.
Setting to closed/deferred because code freeze is a week away and we haven't recieved compatible code based against our tree.
Reopening for U4 per partner request.
Dell specifically doesn't need this for U4.
Dell not sure whether ataraid used by w/s; not used by servers. (ignore previous comment).
Sent in mail to Tim B and Jeff Garzik 8/19 (also posted at 112062): Per comment 24 in 112062 (related), I sent mail to Intel to let them know our objections. The Intel developer (Martin Krikis) replied on 7/9: "Attaching a patch containing version 0.1.4 of iswraid. The patch is taken against 2.4.26 with the libata patch already applied. It applies cleanly to RHEL3 update 3 source as well and seems to work fine with it. There is new documentation in the patch which is worth the read, several bug fixes and several enhancements. >> TIM AND JEFF, PAY SPECIAL NOTE --> Martin goes on to say, "However, because I haven't been able to understand what were RedHat's objections to version 0.1.3 minus the BH_Sync flag, there are no magic fixes against the so-called "potential data corrupter" and are not being planned either. The interested persons were all copied on my last email and I am waiting for a response." Sue here. I see nothing posted back to FZ 112064 capturing a resolution of the potential data corrupter issue (companion is 112062). Did anyone respond to Martin Krikis of Intel who says in IT 29924 that he sent us ("interested persons") mail on 7/9? Dell doesn't need this, but HP either needs this in U4 or wants Intel to agree that there's another solution (md) that's just as good. (HP looking for alignment with Intel or consistent message that Linux users don't really need SATA RAID.)
Moving to Investigate; the blocking FZ bug #112062 is ASSIGNED for U4. As Tim said, for U4, we need to a) communicate back to Intel specifically what the issues were. b) see if we can get a fix version from them. If the Intel developer is stuck, and we can unstick him, we should. If not, then it won't make it in, and will just jump to RHEL3 U5 in INVESTIGATE as desired. Either way, we need to resolve it.
Intel has agreed that the Linux software RAID function is preferred to their proprietary software driver. FZ was closed based on this. Will reopen FZ and ask Enginering if anything has changed. HP requesting for U5.
Note that this FZ has been identified as breaking the kABI.
Per Sue Denham, Intel no longer plans to provide the "R" software for ICH5 or ICH6. They agree that the Linux software RAID function is preferred to their proprietary software driver. I'm therefore reclosing this FZ as WONTFIX.