IT8212/ITE RAID

IT8212/ITE RAID

[CaT]

Having an IDE card with one of these chipsets has left me with a bit of
a quandry. I've seen 2 different patch, both seemingly not going
anywhere.

1. Alan Cox's IDE driver that was included in his ac patchset, which
   seems to have died at 2.6.11ac7.
2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
   It lived a brief but noted life before being taken out without any
   reason (that I spotted) in 2.6.12-rc4-mm1

Now, I'd like to upgrade my kernel to cover the security patches
releases since 11ac7 but... do I extract the ac driver or the mm driver
and try to use it? Will my data be eaten? Is there any chance of seeing
either driver in the kernel, proper?

Just wondering which way to go and stuff. :/

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: IT8212/ITE RAID

[Daniel Drake]

CaT wrote:
> 1. Alan Cox's IDE driver that was included in his ac patchset, which
>    seems to have died at 2.6.11ac7.
> 2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
>    It lived a brief but noted life before being taken out without any
>    reason (that I spotted) in 2.6.12-rc4-mm1

Alan's driver has been merged into 2.6.13. You can get the up-to-date patches 
here:

http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch

Daniel

Re: IT8212/ITE RAID

[CaT]

On Sun, Aug 14, 2005 at 12:08:42PM +0100, Daniel Drake wrote:
> CaT wrote:
> >1. Alan Cox's IDE driver that was included in his ac patchset, which
> >   seems to have died at 2.6.11ac7.
> >2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
> >   It lived a brief but noted life before being taken out without any
> >   reason (that I spotted) in 2.6.12-rc4-mm1
> 
> Alan's driver has been merged into 2.6.13. You can get the up-to-date 

Wooooooooooooooooooooooooooo!

> patches here:
> 
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch

Didn't use these patches. Just went to 13-rc6 for now to test. All works
as before with the following errors on bootup:

[227523.229512] hda: max request size: 128KiB
[227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
[227523.229631] hda: cache flushes not supported
[227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
[227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
[227523.230952] ide: failed opcode was: unknown
[227524.379085]  hda1
[227524.379710] hdc: max request size: 128KiB
[227524.379752] hdc: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, BUG
[227524.379825] hdc: cache flushes not supported
[227524.379991]  hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete Error }
[227524.380702] hdc: recal_intr: error=0x04 { DriveStatusError }
[227524.380748] ide: failed opcode was: unknown
[227525.536757]  hdc1 hdc2


/dev/hda:

 Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
 IORDY=on/off
 PIO modes:  pio0 pio1 pio2 
 DMA modes:  mdma0 mdma1 mdma2 
 AdvancedPM=no
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 

 * signifies the current active mode


/dev/hdc:

 Model=IC35L060AVV207-0, FwRev=V22OA63A, SerialNo=VNVB01G2RAK8XH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
 BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
 IORDY=on/off
 PIO modes:  pio0 pio1 pio2 
 DMA modes:  mdma0 mdma1 mdma2 
 AdvancedPM=no
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: 

 * signifies the current active mode

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: IT8212/ITE RAID

[Daniel Drake]

CaT wrote:
>>>1. Alan Cox's IDE driver that was included in his ac patchset, which
>>>  seems to have died at 2.6.11ac7.
>>
>>Alan's driver has been merged into 2.6.13. You can get the up-to-date 
> 
> 
> Wooooooooooooooooooooooooooo!
> 
> 
>>patches here:
>>
>>http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
>>http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch
> 
> 
> Didn't use these patches. Just went to 13-rc6 for now to test. All works
> as before with the following errors on bootup:

Alan Cox might be interested in these, adding to CC.

> 
> [227523.229512] hda: max request size: 128KiB
> [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
> [227523.229631] hda: cache flushes not supported
> [227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> [227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
> [227523.230952] ide: failed opcode was: unknown
> [227524.379085]  hda1
> [227524.379710] hdc: max request size: 128KiB
> [227524.379752] hdc: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, BUG
> [227524.379825] hdc: cache flushes not supported
> [227524.379991]  hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> [227524.380702] hdc: recal_intr: error=0x04 { DriveStatusError }
> [227524.380748] ide: failed opcode was: unknown
> [227525.536757]  hdc1 hdc2
> 
> 
> /dev/hda:
> 
>  Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
>  BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
>  CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
>  IORDY=on/off
>  PIO modes:  pio0 pio1 pio2 
>  DMA modes:  mdma0 mdma1 mdma2 
>  AdvancedPM=no
>  Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: 
> 
>  * signifies the current active mode
> 
> 
> /dev/hdc:
> 
>  Model=IC35L060AVV207-0, FwRev=V22OA63A, SerialNo=VNVB01G2RAK8XH
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
>  BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
>  IORDY=on/off
>  PIO modes:  pio0 pio1 pio2 
>  DMA modes:  mdma0 mdma1 mdma2 
>  AdvancedPM=no
>  Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: 
> 
>  * signifies the current active mode
> 

Re: IT8212/ITE RAID

[Alan Cox]

On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote:
> > [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG

Thats probably the fact other patches from -ac are missing in base. It
should be harmless. 

> > [227523.229631] hda: cache flushes not supported
> > [227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> > [227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
> > [227523.230952] ide: failed opcode was: unknown

Yep - on my "wtf" list. In some cases we send a strange command to the
IT8212 drive. I'm still trying to find the guilty command we send (none
of my drives do this), so that I can fix the ident adjustment to stop
it. The noise is just the command being rejected which is ok but messy
and wants stomping.

What does a full identify data set for the drive look like ?

Re: IT8212/ITE RAID

[Bartlomiej Zolnierkiewicz]

On 8/14/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote:
> > > [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
> 
> Thats probably the fact other patches from -ac are missing in base. It
> should be harmless.

Therefore please submit them.

> > > [227523.229631] hda: cache flushes not supported
> > > [227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> > > [227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
> > > [227523.230952] ide: failed opcode was: unknown
> 
> Yep - on my "wtf" list. In some cases we send a strange command to the
> IT8212 drive. I'm still trying to find the guilty command we send (none
> of my drives do this), so that I can fix the ident adjustment to stop
> it. The noise is just the command being rejected which is ok but messy
> and wants stomping.

small hint: WIN_RESTORE

Re: IT8212/ITE RAID

[Alan Cox]

On Sul, 2005-08-14 at 17:01 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Thats probably the fact other patches from -ac are missing in base. It
> > should be harmless.
> 
> Therefore please submit them.

Cut the crap, you know I've submitted the stuff again and again and
again along with other fixes, reports of stuff you broke you ignored
etc. So I got bored of playing your games.

> 
> > > > [227523.229631] hda: cache flushes not supported
> > > > [227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> > > > [227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
> > > > [227523.230952] ide: failed opcode was: unknown
> > 
> > Yep - on my "wtf" list. In some cases we send a strange command to the
> > IT8212 drive. I'm still trying to find the guilty command we send (none
> > of my drives do this), so that I can fix the ident adjustment to stop
> > it. The noise is just the command being rejected which is ok but messy
> > and wants stomping.
> 
> small hint: WIN_RESTORE

Would make sense, but I thought I had the right bits masked. Will take a
look tomorrow however.

Re: IT8212/ITE RAID

[Bartlomiej Zolnierkiewicz]

On 8/14/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sul, 2005-08-14 at 17:01 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > Thats probably the fact other patches from -ac are missing in base. It
> > > should be harmless.
> >
> > Therefore please submit them.
> 
> Cut the crap, you know I've submitted the stuff again and again and
> again along with other fixes, reports of stuff you broke you ignored
> etc. So I got bored of playing your games.

* your stuff was accepted after all (and some stuff like ide-cd
  fixes was never splitted from the -ac patchset and submitted)

* you've never provided any technical details on "the stuff I broke"

Can't you get over this bullshit please?  Life goes on.

> > > > > [227523.229631] hda: cache flushes not supported
> > > > > [227523.229932]  hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> > > > > [227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
> > > > > [227523.230952] ide: failed opcode was: unknown
> > >
> > > Yep - on my "wtf" list. In some cases we send a strange command to the
> > > IT8212 drive. I'm still trying to find the guilty command we send (none
> > > of my drives do this), so that I can fix the ident adjustment to stop
> > > it. The noise is just the command being rejected which is ok but messy
> > > and wants stomping.
> >
> > small hint: WIN_RESTORE
> 
> Would make sense, but I thought I had the right bits masked. Will take a

WIN_RESTORE is send unconditionally (as it always was),

This is not the right thing, somebody should go over all ATA/ATAPI
drafts and come with the correct strategy of handling WIN_RESTORE.

> look tomorrow however.

Re: IT8212/ITE RAID

[James Tabor]

Daniel Drake wrote:
> CaT wrote:
> 
>> 1. Alan Cox's IDE driver that was included in his ac patchset, which
>>    seems to have died at 2.6.11ac7.
>> 2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
>>    It lived a brief but noted life before being taken out without any
>>    reason (that I spotted) in 2.6.12-rc4-mm1
> 
> 
> Alan's driver has been merged into 2.6.13. You can get the up-to-date 
> patches here:
> 
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch
> 
> Daniel
Hi All!
So far I'm having good luck with Alans patch, 2.6.11ac7. I have all the
ports used and it boots and writes Cd's too.

Thanks Alan,
James

Re: IT8212/ITE RAID

[Alan Cox]

On Sul, 2005-08-14 at 17:56 +0200, Bartlomiej Zolnierkiewicz wrote:
> * your stuff was accepted after all (and some stuff like ide-cd
>   fixes was never splitted from the -ac patchset and submitted)

They were.

> * you've never provided any technical details on "the stuff I broke"

I did, several times. I had some detailed locking discussions with
Manfred and others on it as a result. The locking in the base IDE is
still broken, in fact its become worse - the random locking around
timing changes now causes some PIIX users to see double spinlock debug
with the base kernel as an example.


> > Would make sense, but I thought I had the right bits masked. Will take a
> 
> WIN_RESTORE is send unconditionally (as it always was),
> 
> This is not the right thing, somebody should go over all ATA/ATAPI
> drafts and come with the correct strategy of handling WIN_RESTORE.

Ok that would make sense. Matthew Garrett also reported some problems in
that area with suspend/resume (BIOS restoring its idea of things...)

Re: IT8212/ITE RAID

[Bartlomiej Zolnierkiewicz]

On 8/14/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sul, 2005-08-14 at 17:56 +0200, Bartlomiej Zolnierkiewicz wrote:
> > * your stuff was accepted after all (and some stuff like ide-cd
> >   fixes was never splitted from the -ac patchset and submitted)
> 
> They were.

I remember discussion about end-of-media ide-cd fixes but the patch
was never submitted.  If you have *URL* to the patch I'll work on the patch.

> > * you've never provided any technical details on "the stuff I broke"
> 
> I did, several times. I had some detailed locking discussions with
> Manfred and others on it as a result. The locking in the base IDE is
> still broken, in fact its become worse - the random locking around
> timing changes now causes some PIIX users to see double spinlock debug
> with the base kernel as an example.

Huh?  *WHICH* my patch causes this?

I don't remember this discussion et all, care to give some pointers?

> > > Would make sense, but I thought I had the right bits masked. Will take a
> >
> > WIN_RESTORE is send unconditionally (as it always was),
> >
> > This is not the right thing, somebody should go over all ATA/ATAPI
> > drafts and come with the correct strategy of handling WIN_RESTORE.
> 
> Ok that would make sense. Matthew Garrett also reported some problems in
> that area with suspend/resume (BIOS restoring its idea of things...)

Quite likely, WIN_RESTORE is not sent on resume etc.

Re: IT8212/ITE RAID

[CaT]

On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote:
> What does a full identify data set for the drive look like ?

Here it is for the two drives. Please note that multisect was turned on
manually as well as the security freeze.


/dev/hda:

ATA device, with non-removable media
        Model Number:       ST3200822A                              
        Serial Number:      3LJ22Y8F
        Firmware Revision:  3.01    
Standards:
        Used: ATA/ATAPI-6 T13 1410D revision 2 
        Supported: 6 5 4 3 
Configuration:
        Logical         max     current
        cylinders       16383   65535
        heads           16      1
        sectors/track   63      63
        --
        CHS current addressable sectors:    4128705
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  390721968
        device size with M = 1024*1024:      190782 MBytes
        device size with M = 1000*1000:      200049 MBytes (200 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        bytes avail on r/w long: 4      Queue depth: 1
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 128, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    READ BUFFER cmd
           *    WRITE BUFFER cmd
           *    Host Protected Area feature set
           *    Look-ahead
           *    Write cache
           *    Power Management feature set
                Security Mode feature set
           *    FLUSH CACHE EXT command
           *    Mandatory FLUSH CACHE command 
           *    48-bit Address feature set 
                SET MAX security extension
Security: 
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
        not     supported: enhanced erase
HW reset results:
        CBLID- above Vih
        Device num = 0 determined by CSEL
Checksum: correct

/dev/hdc:

ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
        Model Number:       IC35L060AVV207-0                        
        Serial Number:      VNVB01G2RAK8XH
        Firmware Revision:  V22OA63A
Standards:
        Used: ATA/ATAPI-6 T13 1410D revision 3a 
        Supported: 6 5 4 3 
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  120103200
        LBA48  user addressable sectors:  120103200
        device size with M = 1024*1024:       58644 MBytes
        device size with M = 1000*1000:       61492 MBytes (61 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        bytes avail on r/w long: 52     Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: unknown setting (0x0000)
        Recommended acoustic management value: 128, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    NOP cmd
           *    READ BUFFER cmd
           *    WRITE BUFFER cmd
           *    Host Protected Area feature set
                Release interrupt
           *    Look-ahead
           *    Write cache
           *    Power Management feature set
                Security Mode feature set
           *    FLUSH CACHE EXT command
           *    Mandatory FLUSH CACHE command 
           *    48-bit Address feature set 
                Automatic Acoustic Management feature set 
                SET MAX security extension
                Address Offset Reserved Area Boot
                SET FEATURES subcommand required to spinup after power up
                Power-Up In Standby feature set
                Advanced Power Management feature set
           *    General Purpose Logging feature set
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
        not     supported: enhanced erase
        30min for SECURITY ERASE UNIT. 
HW reset results:
        CBLID- above Vih
        Device num = 0 determined by the jumper
Checksum: correct

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: IT8212/ITE RAID

[CaT]

On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote:
> On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote:
> > > [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
> 
> Thats probably the fact other patches from -ac are missing in base. It
> should be harmless. 

Just remembered that I was seeing the above with 11ac7 aswell.

-- 
    "To the extent that we overreact, we proffer the terrorists the
    greatest tribute."
    	- High Court Judge Michael Kirby

Re: IT8212/ITE RAID

[Bartlomiej Zolnierkiewicz]

Any news about URLs?  It shouldn't be too hard find them unless they
never existed in the first place. I will work on the issues immediately.

Bartlomiej

On 8/14/05, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> On 8/14/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Sul, 2005-08-14 at 17:56 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > * your stuff was accepted after all (and some stuff like ide-cd
> > >   fixes was never splitted from the -ac patchset and submitted)
> >
> > They were.
> 
> I remember discussion about end-of-media ide-cd fixes but the patch
> was never submitted.  If you have *URL* to the patch I'll work on the patch.
> 
> > > * you've never provided any technical details on "the stuff I broke"
> >
> > I did, several times. I had some detailed locking discussions with
> > Manfred and others on it as a result. The locking in the base IDE is
> > still broken, in fact its become worse - the random locking around
> > timing changes now causes some PIIX users to see double spinlock debug
> > with the base kernel as an example.
> 
> Huh?  *WHICH* my patch causes this?
> 
> I don't remember this discussion et all, care to give some pointers?
> 
> > > > Would make sense, but I thought I had the right bits masked. Will take a
> > >
> > > WIN_RESTORE is send unconditionally (as it always was),
> > >
> > > This is not the right thing, somebody should go over all ATA/ATAPI
> > > drafts and come with the correct strategy of handling WIN_RESTORE.
> >
> > Ok that would make sense. Matthew Garrett also reported some problems in
> > that area with suspend/resume (BIOS restoring its idea of things...)
> 
> Quite likely, WIN_RESTORE is not sent on resume etc.
>

Re: IT8212/ITE RAID

[Bartlomiej Zolnierkiewicz]

On 8/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Llu, 2005-08-22 at 11:28 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Any news about URLs?  It shouldn't be too hard find them unless they
> > never existed in the first place. I will work on the issues immediately.
> 
> Please learn to use the linux-kernel archive. It's quite user friendly

I did this before sending original mail.

Re: IT8212/ITE RAID

[Alan Cox]

On Llu, 2005-08-22 at 11:28 +0200, Bartlomiej Zolnierkiewicz wrote:
> Any news about URLs?  It shouldn't be too hard find them unless they
> never existed in the first place. I will work on the issues immediately.

Please learn to use the linux-kernel archive. It's quite user friendly

Re: IT8212/ITE RAID

[Andre Hedrick]

WHOA Gents!

Let me get some popcorn to watch this p-contest.
The way you guys are sniping at each other sounds like the good-old days,
when everyone railed me and the subsystem and ended up railing back

Guess nothing was learned from the 6+ years of flamage.

I have mellowed out with age ...

Bart, give Alan a break ... his is genrally right at the end of the day.

Alan, give Bart a break ... cause there is no way I am coming back for a
three-pete.

Cheers,

Andre

On Mon, 22 Aug 2005, Bartlomiej Zolnierkiewicz wrote:

> Any news about URLs?  It shouldn't be too hard find them unless they
> never existed in the first place. I will work on the issues immediately.
> 
> Bartlomiej
> 
> On 8/14/05, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > On 8/14/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > On Sul, 2005-08-14 at 17:56 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > * your stuff was accepted after all (and some stuff like ide-cd
> > > >   fixes was never splitted from the -ac patchset and submitted)
> > >
> > > They were.
> > 
> > I remember discussion about end-of-media ide-cd fixes but the patch
> > was never submitted.  If you have *URL* to the patch I'll work on the patch.
> > 
> > > > * you've never provided any technical details on "the stuff I broke"
> > >
> > > I did, several times. I had some detailed locking discussions with
> > > Manfred and others on it as a result. The locking in the base IDE is
> > > still broken, in fact its become worse - the random locking around
> > > timing changes now causes some PIIX users to see double spinlock debug
> > > with the base kernel as an example.
> > 
> > Huh?  *WHICH* my patch causes this?
> > 
> > I don't remember this discussion et all, care to give some pointers?
> > 
> > > > > Would make sense, but I thought I had the right bits masked. Will take a
> > > >
> > > > WIN_RESTORE is send unconditionally (as it always was),
> > > >
> > > > This is not the right thing, somebody should go over all ATA/ATAPI
> > > > drafts and come with the correct strategy of handling WIN_RESTORE.
> > >
> > > Ok that would make sense. Matthew Garrett also reported some problems in
> > > that area with suspend/resume (BIOS restoring its idea of things...)
> > 
> > Quite likely, WIN_RESTORE is not sent on resume etc.
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>