("dd if=/dev/zero bs=512 count=0" seems to cause unexpected results)
- use ${TOOL_STAT} to get file size instead of ls and awk
(1.6.x don't have ${TOOL_STAT} but they have been obsolete anyway)
Both are taken from sys/arch/i386/stand/bootxx/Makefile.bootxx.
volumes that are migrating such as when you change the stripe size.
While I'm here use the same string than we had in the old framework to
report status "online" vs "drive is online", because the sensor might be
a RAID volume and not just a drive.
- malloc(9) -> kmem(9) now that most of the bio code doesn't need to run
on interrupt context.
- Reduce code that runs in interrupt context to a small part in
arc_msgbuf() and is protected by arc_lock()/arc_unlock().
Reviewed and help by ad@.
break functionality. I've tested this on a PCIE R423 (X800).
- In drm_drv.c, check that the requested context lock matches the holder
of the lock.
- Unify radeon offset checking. (r300_cmdbuf.c, radeon_drv.h, radeon_state.c)
[Replace r300_check_offset() with generic radeon_check_offset(), which doesn't
reject valid offsets when the framebuffer area is at the very end of the card's
32 bit address space. Make radeon_check_and_fixup_offset() use
radeon_check_offset() as well.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=7697]
NOTE: There is another AGP fix that I didn't have time to merge
that I thought might help with getting this to work on macppc.
Contact me if you're interested. Hi macallan@! ;)
radeon_cp.c, radeon_drv.h: (GIT id: bb5f2158dbd30dbbffa3881fac75b71d71ecaaf9)
- set the address to access the aperture on the CPU side correctly
[This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
I wonder if this will fix some of those r4xx DRI issues we've seen in the past.]
- Commit the ring after earch partial texture. (radeon_state.c)
(GIT ID: ac8406420ea80ffe5ccaadc1ff0124f95709a23d)
[Commit the ring after each partial texture upload blit.
This makes sure each blit starts as early as possible, which may improve
texture upload performance in some cases.]
If anyone's having any issues in particular--especially those which
can be _teased apart from AGP driver issues--please let me know
and I'll investigate. Thanks. There are also tons of fixes for the i915,
but I don't want to change too much at once.
This is good since they are effectively the same as ...
lockmgr(&lock, LK_RELEASE);
lockmgr(&lock, LK_EXCLUSIVE);
.. and therefore don't behave as expected.
