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] 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 present in IDE aec62xx driver.
> >
> > Have you tested this ??
>
> -ENODEV so no and testing is welcomed.
>
> However I went over both drivers to make sure that this change is safe
> and correct.
>
> 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.
Tested on ATP865 (1191:0008 rev 07) in a DS101 box (an ARM-based NAS).
Seems to work fine.
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:
WARNING: at arch/arm/mm/consistent.c:364 dma_free_coherent()
[<c001fe7c>] (dump_stack+0x0/0x14) from [<c00210ec>] (dma_free_coherent+0x38/0x200)
[<c00210b4>] (dma_free_coherent+0x0/0x200) from [<c00253a8>] (dma_unmap_sg+0x15c/0x198)
[<c002524c>] (dma_unmap_sg+0x0/0x198) from [<c0111984>] (ata_sg_clean+0xe4/0x1dc)
[<c01118a0>] (ata_sg_clean+0x0/0x1dc) from [<c0111ac8>] (__ata_qc_complete+0x4c/0xcc)
r8:c02eca20 r7:00000004 r6:c02ec000 r5:c02ec000 r4:c02eca20
[<c0111a7c>] (__ata_qc_complete+0x0/0xcc) from [<c0111be8>] (ata_qc_complete+0xa0/0xe4)
r5:c02eca20 r4:c02eca20
[<c0111b48>] (ata_qc_complete+0x0/0xe4) from [<c01121b8>] (ata_hsm_qc_complete+0x104/0x10c)
r4:00000000
[<c01120b4>] (ata_hsm_qc_complete+0x0/0x10c) from [<c01127fc>] (ata_hsm_move+0x63c/0x694)
r6:c02ec000 r5:00000050 r4:00000000
[<c01121c0>] (ata_hsm_move+0x0/0x694) from [<c0116628>] (ata_interrupt+0x188/0x240)
[<c01164a0>] (ata_interrupt+0x0/0x240) from [<c0051b24>] (handle_IRQ_event+0x44/0x84)
[<c0051ae0>] (handle_IRQ_event+0x0/0x84) from [<c005339c>] (handle_level_irq+0xb0/0x108)
r7:c02250e8 r6:00000000 r5:0000001c r4:c020e600
[<c00532ec>] (handle_level_irq+0x0/0x108) from [<c001b044>] (__exception_text_start+0x44/0x60)
r5:c020e600 r4:0000001c
[<c001b000>] (__exception_text_start+0x0/0x60) from [<c001ba44>] (__irq_svc+0x24/0x60)
Exception stack(0xc0209f64 to 0xc0209fac)
9f60: 00000000 00000002 00000000 00000000 c001cfa0 c0208000 c0018de8
9f80: c02250e8 00017570 690541f1 0001746c c0209fc0 c0209fac c0209fac c001cd38
9fa0: c001cfa4 60000013 ffffffff
r6:10000000 r5:0000001f r4:ffffffff
[<c001cce4>] (cpu_idle+0x0/0x8c) from [<c018f020>] (rest_init+0x48/0x58)
r5:c02174d0 r4:c021fa58
[<c018efd8>] (rest_init+0x0/0x58) from [<c0008b7c>] (start_kernel+0x238/0x294)
[<c0008944>] (start_kernel+0x0/0x294) from [<00008038>] (0x8038)
So far I've only seen this happen when I run hdparm -Tt /dev/sda.
So something's still not quite right.
aec62xx is perfectly reliable on this box.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
