Date: Sun, 05 Oct 2008 23:00:18 +0200 From: Andreas Tobler <andreast-list@fgznet.ch> To: Marcel Moolenaar <xcllnt@mac.com>, Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: grehan@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: Call for testers: Apple ATA DMA Message-ID: <48E92AE2.108@fgznet.ch> In-Reply-To: <0D5AE023-0D54-43BA-A325-0E1BEEC39D28@mac.com> References: <48D389EE.9000207@FreeBSD.org> <645CD2B8-11A0-42E8-B5F9-C04DCF21F763@mac.com> <48D84C12.7070207@freebsd.org> <0DD89065-9CF3-45E4-89A0-70D6BBB9621D@mac.com> <48D92D44.6080807@freebsd.org> <b9c23c9f0809240338g61e93beoba429ea319a9d56@mail.gmail.com> <48DA4037.9000508@freebsd.org> <b9c23c9f0809240632h77f091dawe54887d0a7f51c1d@mail.gmail.com> <48DBD6C0.5070005@freebsd.org> <b9c23c9f0809261048v366a3cc9i4db8a16cd4eda03@mail.gmail.com> <b9c23c9f0809261053j121ce31fpb62382ff30e6ef76@mail.gmail.com> <48DD2DF7.2020901@freebsd.org> <48DDAC14.9070604@freebsd.org> <48DE7C93.5050506@freebsd.org> <0D5AE023-0D54-43BA-A325-0E1BEEC39D28@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E92AE2.108>