Call for testers: Apple ATA DMA

[Andreas Tobler]

Marcel Moolenaar wrote:
> 
> On Sep 27, 2008, at 11:33 AM, Nathan Whitehorn wrote:
> 
>> Peter Grehan wrote:
>>> Hi Nathan,
>>> > If I can get positive reports from a few more people who were
>>>> having trouble, I'll drop this in the tree.
>>> The imac's ata-4 is working solidly at UDMA-66. The difference in CPU 
>>> usage and i/o with dd at 32k block size is stunning: 2MB/7% idle 
>>> before, 18MB/75% idle with your patch.
>>
>> I guess DMA is a useful technology :)
>>
>> Thanks for testing -- I've committed the patch. I'll revisit it when 
>> Marcel tests it on Monday and it erases his hard drive...
> 
> Good and bad news.
> 
> The good: my Xserve is working fine and acd0 is now using UDMA33
> instead of BIOSPIO.
> 
> The bad: my Mac Mini G4 is still having the same problems. This
> is ad0 at UDMA66 and acd0 at UDMA33. I'll experiment with it a
> bit later...

I'll pick up here.

Here I have a imac slot-loading, don't know which revision offhand. It's 
a 500MHz piece w/o fan.


ad0: 78167MB <Maxtor 6Y080P0 YAR41BW0> at ata0-master UDMA66
acd0: DVDR <MATSHITADVD-ROM SR-8184/AA32> at ata0-slave UDMA33
GEOM_LABEL: Label for provider acd0 is iso9660/CDROM.
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0s10
lock order reversal:
  1st 0xe19000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372
  2nd 0xdcce2c devfs (devfs) @ /usr/src/sys/kern/vfs_lookup.c:428
  3rd 0xe18d48 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372
KDB: stack backtrace:
0xdf2cc898: at kdb_backtrace+0x4c
0xdf2cc8a8: at _witness_debugger+0x3c
0xdf2cc8c8: at witness_checkorder+0x878
0xdf2cc928: at __lockmgr_args+0x23c
0xdf2cc9a8: at vfs_busy+0x19c
0xdf2cc9c8: at vfs_mount_alloc+0x80
0xdf2cc9f8: at vfs_donmount+0xfe0
0xdf2ccba8: at kernel_mount+0x98
0xdf2ccbe8: at kernel_vmount+0xdc
0xdf2ccc28: at vfs_mountroot_try+0x110
0xdf2cccd8: at vfs_mountroot+0x424
0xdf2ccd38: at start_init+0x88
0xdf2ccd98: at fork_exit+0xf0
0xdf2ccdc8: at fork_trampoline+0xc
lock order reversal:
  1st 0xdcc9ec ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2051
  2nd 0xe19000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372
KDB: stack backtrace:
0xdf2cc928: at kdb_backtrace+0x4c
0xdf2cc938: at _witness_debugger+0x3c
0xdf2cc958: at witness_checkorder+0x878
0xdf2cc9b8: at __lockmgr_args+0x23c
0xdf2cca38: at vfs_busy+0x19c
0xdf2cca58: at lookup+0x86c
0xdf2ccae8: at namei+0x4a8
0xdf2ccb68: at kern_unlinkat+0x98
0xdf2ccc18: at kern_unlink+0x24
0xdf2ccc28: at vfs_mountroot_try+0x434
0xdf2cccd8: at vfs_mountroot+0x424
0xdf2ccd38: at start_init+0x88
0xdf2ccd98: at fork_exit+0xf0
0xdf2ccdc8: at fork_trampoline+0xc
lock order reversal:
  1st 0xc41048 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115
  2nd 0xdcc7cc ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2051
KDB: stack backtrace:
0xdf2cc960: at kdb_backtrace+0x4c
0xdf2cc970: at _witness_debugger+0x3c
0xdf2cc990: at witness_checkorder+0x878
0xdf2cc9f0: at __lockmgr_args+0x23c
0xdf2cca70: at ffs_lock+0x9c
0xdf2ccaa0: at VOP_LOCK1_APV+0xec
0xdf2ccac0: at _vn_lock+0x84
0xdf2ccb10: at vget+0xdc
0xdf2ccb50: at vnode_pager_lock+0x20c
0xdf2ccba0: at vm_fault+0x218
0xdf2cccb0: at trap_pfault+0x128
0xdf2ccce0: at trap+0x1ac
0xdf2ccda0: at powerpc_interrupt+0x15c
0xdf2ccdd0: user ISI trap by 0x1818714: srr1=0x4000d032
             r1=0x7fffdee0 cr=0x24000048 xer=0 ctr=0
lock order reversal:
  1st 0xd871c708 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443
  2nd 0xff32800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:254
KDB: stack backtrace:
0xe1748780: at kdb_backtrace+0x4c
0xe1748790: at _witness_debugger+0x3c
0xe17487b0: at witness_checkorder+0x878
0xe1748810: at _sx_xlock+0x90
0xe1748840: at ufsdirhash_acquire+0x40
0xe1748860: at ufsdirhash_add+0x30
0xe1748880: at ufs_direnter+0x6d4
0xe17488f0: at ufs_makeinode+0x498
0xe1748a50: at ufs_create+0x44
0xe1748a60: at VOP_CREATE_APV+0xe0
0xe1748a80: at vn_open_cred+0x208
0xe1748b70: at vn_open+0x20
0xe1748b80: at kern_openat+0x11c
0xe1748cc0: at kern_open+0x34
0xe1748cd0: at open+0x28
0xe1748ce0: at trap+0x460
0xe1748da0: at powerpc_interrupt+0x15c
0xe1748dd0: user SC trap by 0x21b17df8: srr1=0xd032
             r1=0x7f8f8dc0 cr=0x44002022 xer=0 ctr=0x21a08290


I did an upgrade from 7.0 with csup since the snapshots do not boot.

After that I tried a buildworld with several hassles, after all I 
managed to install the whole stuff and the only thing which makes me 
curious is the one above, the LOR's.

Do I have to worry about?


@ Nathan, hat off, it feels snappier with your DMA stuff, THANKS!

I'd like to help testing, especially the work from Nathan and Marco.

Regards,
Andreas