Bartlomiej Zolnierkiewicz wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right naming (s/626/628/).
* Bump driver version.
Fixes
Bartlomiej Zolnierkiewicz wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right naming (s/626/628/).
* Bump driver version.
Fixes
> > It would be nice to know why - is the cable detet coming out right on
> > this ?
>
> The box has a short 40-wire cable, so pata_artop drops to udma/33
> while aec62xx does udma/100 without intervention. I added an override
Curious as both use the same cable detect logic.
> to
It would be nice to know why - is the cable detet coming out right on
this ?
The box has a short 40-wire cable, so pata_artop drops to udma/33
while aec62xx does udma/100 without intervention. I added an override
Curious as both use the same cable detect logic.
to
On Fri, 10 Aug 2007 18:33:43 +0100, Alan Cox wrote:
> > However, I'm gettting consistently lower read throughput with pata_artop
> > (13-19 MB/s) than with aec62xx (22 MB/s) on an oldish WD drive, and using
> > pata_artop triggers a WARN_ON(irqs_disabled()) in arch/arm/mm/consistent.c:
>
> It
On Fri, 10 Aug 2007 18:33:43 +0100, Alan Cox wrote:
However, I'm gettting consistently lower read throughput with pata_artop
(13-19 MB/s) than with aec62xx (22 MB/s) on an oldish WD drive, and using
pata_artop triggers a WARN_ON(irqs_disabled()) in arch/arm/mm/consistent.c:
It would be
> Tested on ATP865 (1191:0008 rev 07) in a DS101 box (an ARM-based NAS).
> Seems to work fine.
Its tested fairly hard on several NAS boxes (and still needs a fix for
one)
> However, I'm gettting consistently lower read throughput with pata_artop
> (13-19 MB/s) than with aec62xx (22 MB/s) on an
On Fri, 10 Aug 2007 01:45:38 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday 10 August 2007, Alan Cox wrote:
> > On Thu, 9 Aug 2007 23:19:34 +0200
> > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> > >
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> and for AEC6880[R] it is UDMA6 (not UDMA5):
>
> * Fix the problem by adding missing struct ata_port_info to artop_init_one().
>
> * Use
> BTW presence of the above bugs would strongly indicate that pata_artop has
> never been tested (properly) with AEC6x80[R], otherwise these bugs should
> have been noticed and fixed much earlier.
People don't seem to notice minor speed limiting errors, and its a pretty
obscure controller too.
Tested on ATP865 (1191:0008 rev 07) in a DS101 box (an ARM-based NAS).
Seems to work fine.
Its tested fairly hard on several NAS boxes (and still needs a fix for
one)
However, I'm gettting consistently lower read throughput with pata_artop
(13-19 MB/s) than with aec62xx (22 MB/s) on an
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right
BTW presence of the above bugs would strongly indicate that pata_artop has
never been tested (properly) with AEC6x80[R], otherwise these bugs should
have been noticed and fixed much earlier.
People don't seem to notice minor speed limiting errors, and its a pretty
obscure controller too. Not
On Fri, 10 Aug 2007 01:45:38 +0200, Bartlomiej Zolnierkiewicz wrote:
On Friday 10 August 2007, Alan Cox wrote:
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R]
On Friday 10 August 2007, Alan Cox wrote:
> On Thu, 9 Aug 2007 23:19:34 +0200
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> >
> > Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> > and for AEC6880[R] it is UDMA6 (not UDMA5):
> >
> > * Fix the problem by adding
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
> and for AEC6880[R] it is UDMA6 (not UDMA5):
>
> * Fix the problem by adding missing struct ata_port_info to artop_init_one().
>
> * Use
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right naming (s/626/628/).
* Bump driver version.
Fixes IDE->libata regression, problem was never
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right naming (s/626/628/).
* Bump driver version.
Fixes IDE-libata regression, problem was never
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right
On Friday 10 August 2007, Alan Cox wrote:
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct
20 matches
Mail list logo
