ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc4/2.6.19-rc4-mm2/
- This is a bit of a rush job. Mainly to test the updates to the driver
tree, which do appear to have improved things.
- There's a huge update here to the hrtimers and dynticks code which I was
supposed to test to see if it fixes the Vaio-goes-deadly-slow problem, but I
forgot to. But it does boot with hrtimers disabled...
<quickly tests it>
Nope, doesn't work.
- Lots of fbdev updates. We haven't heard from Tony in several months, so I
went on a linux-fbdev-devel fishing expedition.
- `make headers_check' is known-broken on i386 (Rusty's fault, as always)
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.
- Semi-daily snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.
Changes since 2.6.19-rc4-mm1:
origin.patch
git-acpi.patch
git-alsa.patch
git-cifs.patch
git-cpufreq.patch
git-drm.patch
git-dvb.patch
git-gfs2.patch
git-ia64.patch
git-ieee1394.patch
git-infiniband.patch
git-jfs.patch
git-libata-all.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-netdev-all.patch
git-net.patch
git-ioat.patch
git-ocfs2.patch
git-pcmcia.patch
git-powerpc.patch
git-r8169.patch
git-pciseg.patch
git-s390.patch
git-scsi-misc.patch
git-scsi-target.patch
git-sas.patch
git-qla3xxx.patch
git-watchdog.patch
git-wireless.patch
git-cryptodev.patch
git-gccbug.patch
git trees
-find_bd_holder-fix.patch
-uml-ubd-driver-allow-using-up-to-16-ubd-devices.patch
-uml-ubd-driver-document-some-struct-fields.patch
-uml-ubd-driver-var-renames.patch
-uml-ubd-driver-give-better-names-to-some-functions.patch
-uml-ubd-driver-change-ubd_lock-to-be-a-mutex.patch
-uml-ubd-driver-ubd_io_lock-usage-fixup.patch
-uml-ubd-driver-reformat-ubd_config.patch
-uml-ubd-driver-convert-do_ubd-to-a-boolean-variable.patch
-uml-ubd-driver-use-bitfields-where-possible.patch
-uml-ubd-driver-do-not-store-error-codes-as-fd.patch
-uml-ubd-driver-various-little-changes.patch
-uml-add-_text-definition-to-linker-scripts.patch
-uml-add-initcalls.patch
-taskstats-fix-sub-threads-accounting.patch
-ecryptfs-clean-up-crypto-initialization.patch
-ecryptfs-hash-code-to-new-crypto-api.patch
-ecryptfs-cipher-code-to-new-crypto-api.patch
-ecryptfs-consolidate-lower-dentry_opens.patch
-ecryptfs-remove-ecryptfs_umount_begin.patch
-ecryptfs-fix-handling-of-lower-d_count.patch
-md-check-bio-address-after-mapping-through-partitions.patch
-ia64-cpu-hotplug-fix-conflict-between-cpu-hot-add-and-ipi.patch
-ohci1394-shortcut-irq-printing.patch
-sata_nv-adma-ncq-support-for-nforce4-v7.patch
-ata_piix-clean-up-port-flags.patch
-libata-unexport-ata_dev_revalidate.patch
-libata-convert-post_reset-to-flags-in-ata_dev_read_id.patch
-libata-implement-presence-detection-via-polling-identify.patch
-ata_piix-apply-device-detection-via-polling-identify.patch
-ata_piix-strip-now-unneded-map-related-stuff.patch
-libata-revamp-blacklist-support-to-allow-multiple-kinds.patch
-sata_sis-fix-flags-handling-for-the-secondary-port.patch
-ata-generic-platform_device-libata-driver-take-2.patch
-ehea-kzalloc-gfp_atomic-fix.patch
-net-s2io-return-on-null-dev_alloc_skb.patch
-n2-fix-confusing-error-code.patch
-tokenring-fix-module_init-error-handling.patch
-add-weida-microdrive-into-ide-csc.patch
-pci-error-recovery-symbios-scsi-device-driver.patch
-scsi-iscsi-build-failure.patch
-x86_64-irq-reset-more-to-default-when-clear-irq_vector-for-destroy_irq.patch
Merged into mainline or a subsystem tree
+ecryptfs-cipher-code-to-new-crypto-api-fix.patch
+cleanup-read_pages.patch
+cifs-readpages-fixes.patch
+fuse-readpages-cleanup.patch
+gfs2-readpages-fixes.patch
+edac_mc-fix-error-handling.patch
+nfs4-fix-for-recursive-locking-problem.patch
+ipmi_si_intfc-sets-bad-class_mask-with-pci_device_class.patch
+init_reap_node-initialization-fix.patch
+printk-timed-ratelimit.patch
+schedule-removal-of-futex_fd.patch
+acpi_noirq-section-fix.patch
+swsusp-debugging.patch
+swsusp-debugging-doc.patch
+spi-section-fix.patch
+reiserfs-reset-errval-after-initializing-bitmap-cache.patch
+usb-hub-build-fix.patch
+remove-hotplug-cpu-crap-from-cpufreq.patch
+uml-fix-i-o-hang.patch
+uml-include-tidying.patch
+revert-iscsi-build-failure-use-depends-instead-of.patch
2.6.19 queue
-lkdtm-module_param-fixes.patch
+lkdtm-cleanup-headers-and-module_param-module_parm_desc.patch
Updated
+acpi-clear-gpe-before-disabling-it.patch
ACPi fix
+hdspm-printk-warning-fix.patch
ALSA fix
+gregkh-driver-w1-ioremap-balanced-with-iounmap.patch
+gregkh-driver-driver-core-add-notification-of-bus-events.patch
+gregkh-driver-driver-link-sysfs-timing.patch
+gregkh-driver-cleanup-virtual_device_parent.patch
+gregkh-driver-config_sysfs_deprecated.patch
+gregkh-driver-udev-compatible-hack.patch
+gregkh-driver-config_sysfs_deprecated-bus.patch
+gregkh-driver-config_sysfs_deprecated-device.patch
+gregkh-driver-config_sysfs_deprecated-PHYSDEV.patch
+gregkh-driver-config_sysfs_deprecated-class.patch
+gregkh-driver-vt-device.patch
+gregkh-driver-vc-device.patch
+gregkh-driver-misc-devices.patch
+gregkh-driver-tty-device.patch
+gregkh-driver-raw-device.patch
+gregkh-driver-i2c-dev-device.patch
+gregkh-driver-msr-device.patch
+gregkh-driver-cpuid-device.patch
+gregkh-driver-ppp-device.patch
+gregkh-driver-ppdev-device.patch
+gregkh-driver-mmc-device.patch
+gregkh-driver-firmware-device.patch
+gregkh-driver-fb-device.patch
+gregkh-driver-mem-devices.patch
+gregkh-driver-sound-device.patch
+gregkh-driver-network-device.patch
+gregkh-driver-put_device-might_sleep.patch
+gregkh-driver-sysfs-crash-debugging.patch
+gregkh-driver-kobject-warn.patch
+gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch
+gregkh-driver-uio.patch
+gregkh-driver-nozomi.patch
Bring back the driver tree
+nozomi-warning-fixes.patch
+nozomi-irq-flags-fixes.patch
+call-platform_notify_remove-later.patch
+update-uio_interrupt.patch
Fixes thereto
+dvb-dibx000_common-fix.patch
DVB fix
+ps-2-driver-update-for-fujitsu-4-wire-touchscreen-on-hitachi-tablets.patch
+lifebook-learn-about-tabs.patch
Input driver fixes
+via-pata-controller-xfer-fixes-fix.patch
Fix via-pata-controller-xfer-fixes.patch
-nfs-fix-nfs_readpages-error-path.patch
Dropped, unneeded
+auth_gss-unregister-gss_domain-when-unloading-module-fix.patch
NFS fix
+pci-device-ensure-sysdata-initialised-v2.patch
Fix for git-pciseg.patch
-x86_64-mm-i386-reloc-abssym.patch
-x86_64-mm-i386-reloc-cleanup-align.patch
I suspect I droped these by accident - the x86_64 tree is a bit of a mess.
+x86_64-mm-paravirt-cpu-detect.patch
+x86_64-mm-clear-irq-vector.patch
+x86_64-mm-io-apic-reuse.patch
x86_64 tree additions
-x86_64-irq-reuse-vector-for-__assign_irq_vector.patch
Not sure where this went - the x86_64 tree is a bit of a mess.
-prep-for-paravirt-cpu_detect-extraction.patch
I might have dropped this by accident too.
+paravirtualization-header-and-stubs-for.patch
+paravirtualization-patch-inline-replacements-for.patch
+paravirtualization-patch-inline-replacements-for-fix.patch
+paravirtualization-more-generic-paravirtualization.patch
+paravirtualization-allow-selected-bug-checks-to-be.patch
+paravirtualization-allow-disabling-legacy-power.patch
+paravirtualization-add-apic-accessors-to-paravirt-ops.patch
+paravirtualization-add-apic-accessors-to-paravirt-ops-tidy.patch
+paravirtualization-add-mmu-virtualization-to.patch
hypervisor stuff
-make-x86_64-udelay-round-up-instead-of-down.patch
-i386-x86_64-comment-magic-constants-in-delayh.patch
Dropped.
+mm-arch-do_page_fault-vs-in_atomic.patch
+mm-pagefault_disableenable.patch
+mm-kummap_atomic-vs-in_atomic.patch
MM updates
+swsusp-freeze-filesystems-during-suspend-rev-2.patch
+swsusp-freeze-filesystems-during-suspend-rev-2-comments.patch
+swsusp-use-platform-mode-by-default.patch
swsusp updates
+drivers-add-lcd-support-update-5.patch
+drivers-add-lcd-support-update6.patch
LCD driver updates
+taskstats-cleanup-do_exit-path.patch
+taskstats-cleanup-signal-stats-allocation.patch
+taskstats-factor-out-reply-assembling.patch
+taskstats-use-nla_reserve-for-reply-assembling.patch
taskstats cleanups and tweaks
+aio-use-prepare_to_wait.patch
+exar-quad-port-serial.patch
+exar-quad-port-serial-fix.patch
+fs-trivial-vsnprintf-conversion.patch
+hpfs-bring-hpfs_error-into-shape.patch
+drivers-cdrom-trivial-vsnprintf-conversion.patch
+vfs-extra-check-inside-dentry_unhash.patch
+correct-misc_register-return-code-handling-in-several-drivers.patch
+more-list-debugging-context.patch
Misc
+log2-implement-a-general-integer-log2-facility-in-the-kernel-ppc-fix.patch
build fix
+tty-switch-to-ktermios-nozomi-fix.patch
Bring this back
+drivers-isdn-trivial-vsnprintf-conversion.patch
ISDN cleanup
+patch-for-nvidia-divide-by-zero-error-for-7600.patch
+radeonfb-support-24bpp-32bpp-minus-alpha.patch
+pmagb-b-fb-fix-a-default-clock.patch
+video-get-the-default-mode-from-the-right-database.patch
+s3c2410fb-add-support-for-stn-displays.patch
+fbcmapc-mark-structs-const-or.patch
+various-fbdev-files-mark-structs.patch
+constify-and-annotate-__read_mostly.patch
+annotate-some-variables-in-vesafb.patch
+constify-vga16fbc.patch
+au1100fb-fix-to-remove-flickering.patch
+mbxfb-fix-hscoeff3-register-address.patch
+mbxfb-add-more-registers-bits.patch
+mbxfb-add-more-registers-to-debugfs.patch
+mbxfb-add-yuv-video-overlay-support.patch
+mbxfb-document-the-new-ioctl.patch
+atyfb-remove-fixme.patch
+atyfb-fix-compiler-warnings.patch
+atyfb-fix-sparse-warnings.patch
+atyfb-fix-blanking-level.patch
+atyfb-remove-pointless-aty_init.patch
+atyfb-fix-__init-and-__devinit.patch
+atyfb-remove-aty_cmap_regs.patch
+atyfb-improve-atyfb_atari_probe.patch
+atyfb-improve-power-management.patch
fbdev updates
+highres-timer-core-fix-status-check.patch
+highres-timer-core-fix-commandline-setup.patch
+clockevents-smp-on-up-features.patch
+highres-depend-on-clockevents.patch
+i386-apic-cleanup.patch
+pm-timer-allow-early-access.patch
+i386-lapic-timer-calibration.patch
+clockevents-add-broadcast-support.patch
+acpi-include-apic-h.patch
+acpi-keep-track-of-timer-broadcast.patch
+i386-apic-timer-use-clockevents-broadcast.patch
+acpi-verify-lapic-timer.patch
+acpi-verify-lapic-timer-exports.patch
Attempt to make the hrtimer code work on my laptop (I forgot to test it).
+kevent_user_wait-retval-fix.patch
kevent fixlet.
All 1113 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc4/2.6.19-rc4-mm2/patch-list
From: Heiko Carstens <[email protected]>
arch/s390/lib/lib.a(uaccess_std.o)(.text+0x282): In function `futex_atomic_op':
: undefined reference to `pagefault_disable'
Cc: Peter Zijlstra <[email protected]>
Cc: Martin Schwidefsky <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
---
Looks like we want to replace all asm/uaccess.h with linux/uaccess.h...
arch/s390/lib/uaccess_std.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.19-rc4-mm2/arch/s390/lib/uaccess_std.c
===================================================================
--- linux-2.6.19-rc4-mm2.orig/arch/s390/lib/uaccess_std.c 2006-11-02 09:37:08.000000000 +0100
+++ linux-2.6.19-rc4-mm2/arch/s390/lib/uaccess_std.c 2006-11-02 09:48:31.000000000 +0100
@@ -11,7 +11,7 @@
#include <linux/errno.h>
#include <linux/mm.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
#include <asm/futex.h>
#ifndef __s390x__
On Thu, 2006-11-02 at 10:05 +0100, Heiko Carstens wrote:
> From: Heiko Carstens <[email protected]>
>
> arch/s390/lib/lib.a(uaccess_std.o)(.text+0x282): In function `futex_atomic_op':
> : undefined reference to `pagefault_disable'
>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Martin Schwidefsky <[email protected]>
> Signed-off-by: Heiko Carstens <[email protected]>
> ---
>
> Looks like we want to replace all asm/uaccess.h with linux/uaccess.h...
Bah, I knew that misery was upon us:
http://programming.kicks-ass.net/kernel-patches/mm_inatomic/
In particular:
http://programming.kicks-ass.net/kernel-patches/mm_inatomic/uaccess_asm_to_linux.patch
:-(
I'd just hoped that'd not be needed for these three patches...
Hello,
So far 2.6.19-rc4-mm2 works fine for me. I attached trivial warning fix to
address this:
drivers/acpi/events/evmisc.c: In function 'acpi_ev_global_lock_handler':
drivers/acpi/events/evmisc.c:334: warning: unused variable 'status'
The patch is against 2.6.19-rc4-mm2.
Regards,
Mariusz Kozlowski
Signed-off-by: Mariusz Kozlowski <[email protected]>
---
--- linux-2.6.19-rc4-orig/drivers/acpi/events/evmisc.c 2006-11-02
23:51:15.000000000 +0100
+++ linux-2.6.19-rc4/drivers/acpi/events/evmisc.c 2006-11-03
00:02:40.000000000 +0100
@@ -331,7 +331,6 @@ static void ACPI_SYSTEM_XFACE acpi_ev_gl
static u32 acpi_ev_global_lock_handler(void *context)
{
u8 acquired = FALSE;
- acpi_status status;
/*
* Attempt to get the lock
Just happened to be watching a console of a test box when it was
performing a post job reboot and caught the following panic. This
specific machine is a ppc64. Sadly these are not part of the job.
/me considers how we could fix that. Perhaps we could just shove a
plain reboot at the end of one of the jobs ... hmmm.
-apw
REISERFS: panic (device sda3): journal_begin called without kernel lock held
kernel BUG in reiserfs_panic at fs/reiserfs/prints.c:361!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=32 NUMA
Modules linked in:
NIP: C000000000125A60 LR: C000000000125A5C CTR: 00000000000D0274
REGS: c00000076e693640 TRAP: 0700 Not tainted (2.6.19-rc4-mm2-autokern1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 22008424 XER: 00000000
TASK = c00000003fb68250[16416] 'umount' THREAD: c00000076e690000 CPU: 2
GPR00: C000000000125A5C C00000076E6938C0 C0000000006662E8 0000000000000050
GPR04: 0000000000000000 FFFFFFFFFFFFFFFF 656C206C6F636B20 68656C640D0A726E
GPR08: 0000000000000000 C00000000054EAB8 C00000000068F810 C00000000068F808
GPR12: 00000000000D0274 C000000000545500 0000000000000000 0000000000000000
GPR16: 00000000100A7D10 00000000100A94E0 0000000010070000 0000000000000000
GPR20: 0000000010010000 00000000FFFFFFFF 0000000010019218 0000000000000000
GPR24: 0000000000000000 000000000000000A C00000076E693BC0 000000000000000A
GPR28: C000000000518800 C00000076E693BC0 C000000000579080 C000000000518800
NIP [C000000000125A60] .reiserfs_panic+0x6c/0x90
LR [C000000000125A5C] .reiserfs_panic+0x68/0x90
Call Trace:
[C00000076E6938C0] [C000000000125A5C] .reiserfs_panic+0x68/0x90 (unreliable)
[C00000076E693940] [C000000000134A38] .reiserfs_check_lock_depth+0x30/0x48
[C00000076E6939C0] [C00000000013A654] .do_journal_begin_r+0x58/0x434
[C00000076E693AB0] [C00000000013AC54] .journal_begin+0x108/0x170
[C00000076E693B50] [C000000000123130] .reiserfs_remount+0x194/0x460
[C00000076E693C50] [C0000000000B47D0] .do_remount_sb+0x1a8/0x224
[C00000076E693CF0] [C0000000000D0E98] .sys_umount+0x19c/0x2a0
[C00000076E693E30] [C00000000000872C] syscall_exit+0x0/0x40
Instruction dump:
f90100d8 f92100e0 f94100e8 4bfff11d 4192000c 389f0218 48000008 e89e8178
e87e8180 e8be8080 4bf289b5 60000000 <0fe00000> 4192000c 389f0218 48000008
<3>Badness in do_exit at kernel/exit.c:853
Call Trace:
[C00000076E692E70] [C00000000000F198] .show_stack+0x74/0x1b4 (unreliable)
[C00000076E692F20] [C000000000021688] .program_check_exception+0x194/0x634
[C00000076E692FD0] [C000000000004774] program_check_common+0xf4/0x100
--- Exception: 700 at .do_exit+0x50/0xa1c
LR = .do_exit+0x44/0xa1c
[C00000076E693380] [C000000000021038] .die+0x150/0x154
[C00000076E693410] [C000000000021264] ._exception+0x48/0x138
[C00000076E693520] [C000000000021B0C] .program_check_exception+0x618/0x634
[C00000076E6935D0] [C000000000004774] program_check_common+0xf4/0x100
--- Exception: 700 at .reiserfs_panic+0x6c/0x90
LR = .reiserfs_panic+0x68/0x90
[C00000076E693940] [C000000000134A38] .reiserfs_check_lock_depth+0x30/0x48
[C00000076E6939C0] [C00000000013A654] .do_journal_begin_r+0x58/0x434
[C00000076E693AB0] [C00000000013AC54] .journal_begin+0x108/0x170
[C00000076E693B50] [C000000000123130] .reiserfs_remount+0x194/0x460
[C00000076E693C50] [C0000000000B47D0] .do_remount_sb+0x1a8/0x224
[C00000076E693CF0] [C0000000000D0E98] .sys_umount+0x19c/0x2a0
[C00000076E693E30] [C00000000000872C] syscall_exit+0x0/0x40
/etc/init.d/boot.d/K15boot.localfs: line 217: 16416 Trace/breakpoint
trap umount -avt noproc,nonfs,nosmbfs
failed
Oops: umount failed :-( -- trying to remount readonly...
On Fri, 03 Nov 2006 15:08:06 +0000
Andy Whitcroft <[email protected]> wrote:
> Just happened to be watching a console of a test box when it was
> performing a post job reboot and caught the following panic. This
> specific machine is a ppc64. Sadly these are not part of the job.
>
> /me considers how we could fix that. Perhaps we could just shove a
> plain reboot at the end of one of the jobs ... hmmm.
>
> -apw
>
> REISERFS: panic (device sda3): journal_begin called without kernel lock held
> kernel BUG in reiserfs_panic at fs/reiserfs/prints.c:361!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=32 NUMA
> Modules linked in:
> NIP: C000000000125A60 LR: C000000000125A5C CTR: 00000000000D0274
> REGS: c00000076e693640 TRAP: 0700 Not tainted (2.6.19-rc4-mm2-autokern1)
> MSR: 8000000000029032 <EE,ME,IR,DR> CR: 22008424 XER: 00000000
> TASK = c00000003fb68250[16416] 'umount' THREAD: c00000076e690000 CPU: 2
> GPR00: C000000000125A5C C00000076E6938C0 C0000000006662E8 0000000000000050
> GPR04: 0000000000000000 FFFFFFFFFFFFFFFF 656C206C6F636B20 68656C640D0A726E
> GPR08: 0000000000000000 C00000000054EAB8 C00000000068F810 C00000000068F808
> GPR12: 00000000000D0274 C000000000545500 0000000000000000 0000000000000000
> GPR16: 00000000100A7D10 00000000100A94E0 0000000010070000 0000000000000000
> GPR20: 0000000010010000 00000000FFFFFFFF 0000000010019218 0000000000000000
> GPR24: 0000000000000000 000000000000000A C00000076E693BC0 000000000000000A
> GPR28: C000000000518800 C00000076E693BC0 C000000000579080 C000000000518800
> NIP [C000000000125A60] .reiserfs_panic+0x6c/0x90
> LR [C000000000125A5C] .reiserfs_panic+0x68/0x90
> Call Trace:
> [C00000076E6938C0] [C000000000125A5C] .reiserfs_panic+0x68/0x90 (unreliable)
> [C00000076E693940] [C000000000134A38] .reiserfs_check_lock_depth+0x30/0x48
> [C00000076E6939C0] [C00000000013A654] .do_journal_begin_r+0x58/0x434
> [C00000076E693AB0] [C00000000013AC54] .journal_begin+0x108/0x170
> [C00000076E693B50] [C000000000123130] .reiserfs_remount+0x194/0x460
> [C00000076E693C50] [C0000000000B47D0] .do_remount_sb+0x1a8/0x224
> [C00000076E693CF0] [C0000000000D0E98] .sys_umount+0x19c/0x2a0
> [C00000076E693E30] [C00000000000872C] syscall_exit+0x0/0x40
That thump you heard was the sound of
vfs-bkl-is-not-required-for-remount_fs.patch getting dropped. Thanks.
On Thursday 02 November 2006 02:54, Andrew Morton wrote:
> - Lots of fbdev updates. We haven't heard from Tony in several months, so I
> went on a linux-fbdev-devel fishing expedition.
radeonfb-support-24bpp-32bpp-minus-alpha.patch broke my video: my
screen ended up garbled. (vc1 was ok, strangely enough). Reverting
fixed things.
lspci -v:
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Radeon 7500
Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 16
Memory at d8000000 (32-bit, prefetchable) [size=128M]
I/O ports at d800 [size=256]
Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at d7fe0000 [disabled] [size=128K]
Capabilities: <available only to root>
-ajw
On Fri, 3 Nov 2006 16:42:33 -0500
Andrew James Wade <[email protected]> wrote:
> On Thursday 02 November 2006 02:54, Andrew Morton wrote:
> > - Lots of fbdev updates. We haven't heard from Tony in several months, so I
> > went on a linux-fbdev-devel fishing expedition.
>
> radeonfb-support-24bpp-32bpp-minus-alpha.patch broke my video: my
> screen ended up garbled. (vc1 was ok, strangely enough). Reverting
> fixed things.
>
> lspci -v:
>
> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (prog-if 00 [VGA])
> Subsystem: ATI Technologies Inc Radeon 7500
> Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 16
> Memory at d8000000 (32-bit, prefetchable) [size=128M]
> I/O ports at d800 [size=256]
> Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at d7fe0000 [disabled] [size=128K]
> Capabilities: <available only to root>
>
Great, thanks for working that out. I'll drop the patch.
Hello,
After allyesconfig I found this on one of my box'es. Not sure how to fix
that. Don't want to mess with headers ;-)
CC drivers/media/video/pwc/pwc-uncompress.o
In file included from drivers/media/video/pwc/pwc-uncompress.c:29:
include/asm/current.h: In function `get_current':
include/asm/current.h:11: error: `size_t' undeclared (first use in this
function)
include/asm/current.h:11: error: (Each undeclared identifier is reported only
once
include/asm/current.h:11: error: for each function it appears in.)
make[4]: *** [drivers/media/video/pwc/pwc-uncompress.o] Error 1
make[3]: *** [drivers/media/video/pwc] Error 2
make[2]: *** [drivers/media/video] Error 2
make[1]: *** [drivers/media] Error 2
make: *** [drivers] Error 2
Regards,
Mariusz Kozlowski
Matthew,
4 years ago you have patched the Locking document and changed the BKL rule for
remount_fs()
# ChangeSet
# 2003/08/21 00:28:27-07:00 [email protected]
# [PATCH] update Documentation/filesystems/Locking
# From: Matthew Wilcox <[email protected]>
locking rules:
All may block.
- BKL s_lock mount_sem
-remount_fs: yes yes maybe (see below)
+ BKL s_lock s_umount
+remount_fs: no yes maybe (see below)
As far as I understand it was a misprint, de-facto BKL is required at least for
reiserfs, where is a long-lived check. Also I've found that currently
remount_fs() is called only from do_remount_sb(), which is called with taken BKL
in all cases:
- do_umount() and do_emergency_remount() acquires BKL directly;
- do_remount() which called from do_mount() with taken BKL;
- get_sb_single() which called from .get_sb() and should have BKL too
If you have not any objections I would like to fix this issue by the patch from
the following letter.
thank you,
Vasily Averin
Andrew Morton wrote:
> On Fri, 03 Nov 2006 15:08:06 +0000
> Andy Whitcroft <[email protected]> wrote:
>
>> Just happened to be watching a console of a test box when it was
>> performing a post job reboot and caught the following panic. This
>> specific machine is a ppc64. Sadly these are not part of the job.
>>
>> /me considers how we could fix that. Perhaps we could just shove a
>> plain reboot at the end of one of the jobs ... hmmm.
>>
>> -apw
>>
>> REISERFS: panic (device sda3): journal_begin called without kernel lock held
>> kernel BUG in reiserfs_panic at fs/reiserfs/prints.c:361!
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> SMP NR_CPUS=32 NUMA
>> Modules linked in:
>> NIP: C000000000125A60 LR: C000000000125A5C CTR: 00000000000D0274
>> REGS: c00000076e693640 TRAP: 0700 Not tainted (2.6.19-rc4-mm2-autokern1)
>> MSR: 8000000000029032 <EE,ME,IR,DR> CR: 22008424 XER: 00000000
>> TASK = c00000003fb68250[16416] 'umount' THREAD: c00000076e690000 CPU: 2
>> GPR00: C000000000125A5C C00000076E6938C0 C0000000006662E8 0000000000000050
>> GPR04: 0000000000000000 FFFFFFFFFFFFFFFF 656C206C6F636B20 68656C640D0A726E
>> GPR08: 0000000000000000 C00000000054EAB8 C00000000068F810 C00000000068F808
>> GPR12: 00000000000D0274 C000000000545500 0000000000000000 0000000000000000
>> GPR16: 00000000100A7D10 00000000100A94E0 0000000010070000 0000000000000000
>> GPR20: 0000000010010000 00000000FFFFFFFF 0000000010019218 0000000000000000
>> GPR24: 0000000000000000 000000000000000A C00000076E693BC0 000000000000000A
>> GPR28: C000000000518800 C00000076E693BC0 C000000000579080 C000000000518800
>> NIP [C000000000125A60] .reiserfs_panic+0x6c/0x90
>> LR [C000000000125A5C] .reiserfs_panic+0x68/0x90
>> Call Trace:
>> [C00000076E6938C0] [C000000000125A5C] .reiserfs_panic+0x68/0x90 (unreliable)
>> [C00000076E693940] [C000000000134A38] .reiserfs_check_lock_depth+0x30/0x48
>> [C00000076E6939C0] [C00000000013A654] .do_journal_begin_r+0x58/0x434
>> [C00000076E693AB0] [C00000000013AC54] .journal_begin+0x108/0x170
>> [C00000076E693B50] [C000000000123130] .reiserfs_remount+0x194/0x460
>> [C00000076E693C50] [C0000000000B47D0] .do_remount_sb+0x1a8/0x224
>> [C00000076E693CF0] [C0000000000D0E98] .sys_umount+0x19c/0x2a0
>> [C00000076E693E30] [C00000000000872C] syscall_exit+0x0/0x40
>
> That thump you heard was the sound of
> vfs-bkl-is-not-required-for-remount_fs.patch getting dropped. Thanks.
From: Vasily Averin <[email protected]>
fixed long-lived typo: remount_fs() needs BKL
Signed-off-by: Vasily Averin <[email protected]>
--- linux-2.6.19-rc4/Documentation/filesystems/Locking.umntlk 2006-11-02
13:25:04.000000000 +0300
+++ linux-2.6.19-rc4/Documentation/filesystems/Locking 2006-11-06
13:22:35.000000000 +0300
@@ -124,7 +124,7 @@ sync_fs: no no read
write_super_lockfs: ?
unlockfs: ?
statfs: no no no
-remount_fs: no yes maybe (see below)
+remount_fs: yes yes maybe (see below)
clear_inode: no
umount_begin: yes no no
show_options: no (vfsmount->sem)
Hi, Andrew & Andrew -
Kimball said to work this through you; I modified this fix so that it
only applies to RV100-based Radeons, since evidently some of them (like
your RV200-based Radeon) really do NOT do 24bpp, as retro as that seems
to me. I'm certain this is actually overly-restrictive, but the only
Radeon chips I have here are ES1000s (RN50, device id 0x515E): I did
drivers
for three earlier Radeon chips at my previous job several years ago, all
of which did 24bpp just fine, but I do not recall what their device ids
were
anymore. What's the device id of your VC1? What I'd ideally like to do
is
to allow 24bpp for all the Radeons for which it works and disallow it
for
all the ones where it doesn't, rather than disallow it for ALL of them,
or
only allow it for the ES1000 (RN50) that we happen to have in our
hardware
here. Your thoughts?
/Charlotte
> -----Original Message-----
> From: Andrew Morton [mailto:[email protected]]
> Sent: Friday, November 03, 2006 4:52 PM
> To: [email protected]
> Cc: [email protected]; Richardson, Charlotte; Kimball
Murray;
> [email protected]
> Subject: Re: 2.6.19-rc4-mm2
>
> On Fri, 3 Nov 2006 16:42:33 -0500
> Andrew James Wade <[email protected]> wrote:
>
> > On Thursday 02 November 2006 02:54, Andrew Morton wrote:
> > > - Lots of fbdev updates. We haven't heard from Tony in several
> months, so I
> > > went on a linux-fbdev-devel fishing expedition.
> >
> > radeonfb-support-24bpp-32bpp-minus-alpha.patch broke my video: my
> > screen ended up garbled. (vc1 was ok, strangely enough). Reverting
> > fixed things.
> >
> > lspci -v:
> >
> > 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
> RV200 QW [Radeon 7500] (prog-if 00 [VGA])
> > Subsystem: ATI Technologies Inc Radeon 7500
> > Flags: bus master, stepping, 66MHz, medium devsel, latency
64,
> IRQ 16
> > Memory at d8000000 (32-bit, prefetchable) [size=128M]
> > I/O ports at d800 [size=256]
> > Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
> > Expansion ROM at d7fe0000 [disabled] [size=128K]
> > Capabilities: <available only to root>
> >
>
> Great, thanks for working that out. I'll drop the patch.
On 11/6/06, Richardson, Charlotte <[email protected]> wrote:
> What's the device id of your VC1?
I presume lscpi -n -v will tell you what you need to know. I don't know
how to read the output myself:
0000:01:00.0 0300: 1002:5157
Subsystem: 1002:013a
Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 16
Memory at d8000000 (32-bit, prefetchable) [size=128M]
I/O ports at d800 [size=256]
Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at d7fe0000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
My card is a dual-head card, but I'm only using one head. On that head, if
I switch to virtual console 1, everything is fine, but if I switch to any
other vitual console, the display is "garbled": each row of pixels is offset
from the row before, producing interlaced "ghost" images.
I hope this helps; feel free to ask further questions.
-ajw
Hi, Andrew -
Yours is PCI device id 0x5157. Mine is 0x515E - which is also dual-head-
capable, but we don't have it wired that way (it's on the motherboard).
0x1002 is ATI's PCI vendor id. Lspci is just printing out the PCI config
header in a nicer format (so that you can read it).
I think I remember something relevant from working on these chips
before:
there was some kind of a hardware bug in some of them that caused you to
have to pretend that unpacked 24-bit pixels were twice as many 16-bit
pixels. I think you had to double basically everything that dealt with
widths or offsets into a scan line. I don't remember the details
anymore,
and I can't really ask, since that company has a proprietary Unix. I'll
try
to remember what it was - and which ones it affected, since that is
probably
what's wrong with the 24bpp. Too bad the chip specs are so crummy...
How much is each line offset when you have the garbled stuff? I mean, is
it
a couple pixels, half the total width, something else? And is it always
the
same for each line (or can you tell)?
/Charlotte
> -----Original Message-----
> From: Andrew Wade [mailto:[email protected]]
> Sent: Monday, November 06, 2006 5:02 PM
> To: Richardson, Charlotte
> Cc: Andrew Morton; [email protected]; Kimball Murray;
linux-
> [email protected]
> Subject: Re: 2.6.19-rc4-mm2
>
> On 11/6/06, Richardson, Charlotte <[email protected]>
> wrote:
> > What's the device id of your VC1?
>
> I presume lscpi -n -v will tell you what you need to know. I don't
know
> how to read the output myself:
>
> 0000:01:00.0 0300: 1002:5157
> Subsystem: 1002:013a
> Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ
> 16
> Memory at d8000000 (32-bit, prefetchable) [size=128M]
> I/O ports at d800 [size=256]
> Memory at d7000000 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at d7fe0000 [disabled] [size=128K]
> Capabilities: [58] AGP version 2.0
> Capabilities: [50] Power Management version 2
>
> My card is a dual-head card, but I'm only using one head. On that
head, if
> I switch to virtual console 1, everything is fine, but if I switch to
any
> other vitual console, the display is "garbled": each row of pixels is
> offset
> from the row before, producing interlaced "ghost" images.
>
> I hope this helps; feel free to ask further questions.
>
> -ajw
On 11/6/06, Richardson, Charlotte <[email protected]> wrote:
...
> How much is each line offset when you have the garbled stuff? I mean,
> is it a couple pixels, half the total width, something else? And is
> it always the same for each line (or can you tell)?
Each ghost is 1/3 of a screen horizontally from the other ghosts. I've
been looking carefully at test patterns to figure out what is going on.
If
(1,1) (2,1) (3,1) (4,1) (5,1) (6,1) (7,1) (8,1)
(1,2) (2,2) (3,2) (4,2) (5,2) (6,2) (7,2) (8,2)
(1,3) (2,3) (3,3) (4,3) (5,3) (6,3) (7,3) (8,3)
(1,4) (2,4) (3,4) (4,4) (5,4) (6,4) (7,4) (8,4)
(1,5) (2,5) (3,5) (4,5) (5,5) (6,5) (7,5) (8,5)
(1,6) (2,6) (3,6) (4,6) (5,6) (6,6) (7,6) (8,6)
is what should be displayed, I'm getting instead
(1,1) (2,1) (3,1) black (4,1) (5,1) (6,1) black
(7,1) (8,1) (1,2) black (2,2) (3,2) (4,2) black
(5,2) (6,2) (7,2) black (8,2) (1,3) (2,3) black
(3,3) (4,3) (5,3) black (6,3) (7,3) (8,3) black
(1,4) (2,4) (3,4) black (4,4) (5,4) (6,4) black
(7,4) (8,4) (1,5) black (2,5) (3,5) (4,5) black
i.e., a black pixel is inserted every thee pixels.
However, it's not just a garbled display, the acceleration (I think) is
also bogus. When I tried setting a solid colour using echo -e '\e[47m',
instead of the above display, I got
(1,1) (2,1) (3,1) black (4,1) black black black
black black (1,2) black (2,2) (3,2) (4,2) black
black black black black black (1,3) (2,3) black
(3,3) (4,3) black black black black black black
(1,4) (2,4) (3,4) black (4,4) black black black
black black (1,5) black (2,5) (3,5) (4,5) black
i.e., in addition to a black pixel being inserted every three pixels,
one of the halves of the "source" image is black. And in the X virtual
console, the cursor is ungarbled.
Two other thing of note is that virtual consoles 2-6 are garbled after
only some boots. (vc7, the X server console, is always garbled). And
output below the as-displayed bottom of a garbled virtual console
prevents me from switching to a different vc. (I get "radeonfb FIFO
Timeout !"/"radeonfb Idle Timeout !" on the serial line).
Hope this helps,
ajw
Hi again, Andrew -
(Sorry, I don't know what timezone you're in, but I went home, cooked
supper, ate supper, did two loads of laundry, slept for about seven
hours, ate breakfast, did another load of laundry, and voted, and now
I'm back!)
I'll go investigate whether any virtual consoles do anything weird
in 24-bit TrueColor mode with our chip here. Of course, I don't remember
what the problem with the Radeon chips I worked on several years
ago (about 7 now!) looked like. I got a list of the device ids for those
Radeons from someone who is still at my old company, and your chip is
one of them, so it isn't surprising that there is a problem. I don't
recall
exactly what we had to do about it (and as I said I can't really ask).
If the chip we are using here works solidly in 24 bit mode, I won't
be able to test it, either. I hadn't messed much with using a graphical
console at all other than to make sure that the various modes we are
supposed to support (resolution, refresh rate, and bit depth) worked
- I didn't try switching virtual consoles, etc. The systems are early
protos and there are not many of them around yet, but I pretty much
have the use of one almost all of the time. So after I finish dealing
with
the morning's email, I'll go into the lab and beat on it a bit!
I'll email results later...
If I can't repro it with this chip, if you want to mess around with it
on yours, here's what I think we had to do... I believe the trick was
to use 16bpp mode as far as what mode you write to the chip, and then
double all the x coordinate values for things like offset, width, and
pitch. You would have to do that to the accelerated routines also.
(Btw we have to turn off the acceleration here anyhow because we
essentially are hot-plugging the boards.)
/Charlotte
> -----Original Message-----
> From: Andrew Wade [mailto:[email protected]]
> Sent: Monday, November 06, 2006 11:31 PM
> To: Richardson, Charlotte
> Cc: Andrew Morton; [email protected]; Kimball Murray;
linux-
> [email protected]
> Subject: Re: 2.6.19-rc4-mm2
>
> On 11/6/06, Richardson, Charlotte <[email protected]>
> wrote:
> ...
> > How much is each line offset when you have the garbled stuff? I
mean,
> > is it a couple pixels, half the total width, something else? And is
> > it always the same for each line (or can you tell)?
>
> Each ghost is 1/3 of a screen horizontally from the other ghosts. I've
> been looking carefully at test patterns to figure out what is going
on.
>
> If
>
> (1,1) (2,1) (3,1) (4,1) (5,1) (6,1) (7,1) (8,1)
> (1,2) (2,2) (3,2) (4,2) (5,2) (6,2) (7,2) (8,2)
> (1,3) (2,3) (3,3) (4,3) (5,3) (6,3) (7,3) (8,3)
> (1,4) (2,4) (3,4) (4,4) (5,4) (6,4) (7,4) (8,4)
> (1,5) (2,5) (3,5) (4,5) (5,5) (6,5) (7,5) (8,5)
> (1,6) (2,6) (3,6) (4,6) (5,6) (6,6) (7,6) (8,6)
>
> is what should be displayed, I'm getting instead
>
> (1,1) (2,1) (3,1) black (4,1) (5,1) (6,1) black
> (7,1) (8,1) (1,2) black (2,2) (3,2) (4,2) black
> (5,2) (6,2) (7,2) black (8,2) (1,3) (2,3) black
> (3,3) (4,3) (5,3) black (6,3) (7,3) (8,3) black
> (1,4) (2,4) (3,4) black (4,4) (5,4) (6,4) black
> (7,4) (8,4) (1,5) black (2,5) (3,5) (4,5) black
>
> i.e., a black pixel is inserted every thee pixels.
>
> However, it's not just a garbled display, the acceleration (I think)
is
> also bogus. When I tried setting a solid colour using echo -e
'\e[47m',
> instead of the above display, I got
>
> (1,1) (2,1) (3,1) black (4,1) black black black
> black black (1,2) black (2,2) (3,2) (4,2) black
> black black black black black (1,3) (2,3) black
> (3,3) (4,3) black black black black black black
> (1,4) (2,4) (3,4) black (4,4) black black black
> black black (1,5) black (2,5) (3,5) (4,5) black
>
> i.e., in addition to a black pixel being inserted every three pixels,
> one of the halves of the "source" image is black. And in the X virtual
> console, the cursor is ungarbled.
>
> Two other thing of note is that virtual consoles 2-6 are garbled after
> only some boots. (vc7, the X server console, is always garbled). And
> output below the as-displayed bottom of a garbled virtual console
> prevents me from switching to a different vc. (I get "radeonfb FIFO
> Timeout !"/"radeonfb Idle Timeout !" on the serial line).
>
> Hope this helps,
>
> ajw
Hello Charlotte,
> (Sorry, I don't know what timezone you're in, but I went home, cooked
> supper, ate supper, did two loads of laundry, slept for about seven
> hours, ate breakfast, did another load of laundry, and voted, and now
> I'm back!)
I'm EST (GMT-5). But the hours I'm online are somewhat erratic.
...
> If I can't repro it with this chip, if you want to mess around with it
> on yours, here's what I think we had to do... I believe the trick was
> to use 16bpp mode as far as what mode you write to the chip, and then
> double all the x coordinate values for things like offset, width, and
> pitch. You would have to do that to the accelerated routines also.
I'd be happy to mess around with the driver, but I won't have much
time to do so until tomorrow. I'll let you know if I find anything,
and of course I'll be happy to test patches.
-ajw
On Tue, 7 Nov 2006, Richardson, Charlotte wrote:
> If I can't repro it with this chip, if you want to mess around with it
> on yours, here's what I think we had to do... I believe the trick was
> to use 16bpp mode as far as what mode you write to the chip, and then
> double all the x coordinate values for things like offset, width, and
> pitch. You would have to do that to the accelerated routines also.
> > From: Andrew Wade [mailto:[email protected]]
> > On 11/6/06, Richardson, Charlotte <[email protected]>
> > wrote:
> > ...
> > > How much is each line offset when you have the garbled stuff? I
> mean,
> > > is it a couple pixels, half the total width, something else? And is
> > > it always the same for each line (or can you tell)?
> >
> > Each ghost is 1/3 of a screen horizontally from the other ghosts. I've
> > been looking carefully at test patterns to figure out what is going
> on.
Since the ghosts are 1/3 of a screen apart and not 1/2...
If this is similar to the old Mach64, for 24-bit you have to use 8-bit mode and
multiply all horizontal values by _3_.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi, Andrew -
I messed around with trying to recreate the workaround for the 24bpp
Radeon stuff for chips that have the problem (like yours does) all
afternoon yesterday, but I never did get it to work. I can't spend any
more time on this right now (boss is after me!) but I will try to do
some more poking around later or next week. Do you think I should submit
a patch that at least enables 24bpp for the chip I have where it
definitely does work? I'm sure that is overly restrictive, but I don't
know which ones work and which are broken at this point. I tried going
to the ATI web site (we have an OEM agreement with them, so I can get
more data that way) but their documents are no better now that they are
part of AMD than they ever were, and I didn't find anything useful.
Grumble! Actually, as more people use linux and Xfree86, they may have
to do a bit better with the specs. One can hope!
If you get a chance before I do, you might look at what Xfree86 does -
they might have the workaround.
/Charlotte
PS - You have your reply-to email address set to
[email protected]
which evidently is stale, 'cause replying to that bounces.
> -----Original Message-----
> From: Andrew Wade [mailto:[email protected]]
> Sent: Tuesday, November 07, 2006 10:58 AM
> To: Richardson, Charlotte
> Cc: Andrew Morton; [email protected]; Kimball Murray;
linux-
> [email protected]
> Subject: Re: 2.6.19-rc4-mm2
>
> Hello Charlotte,
>
> > (Sorry, I don't know what timezone you're in, but I went home,
cooked
> > supper, ate supper, did two loads of laundry, slept for about seven
> > hours, ate breakfast, did another load of laundry, and voted, and
now
> > I'm back!)
>
> I'm EST (GMT-5). But the hours I'm online are somewhat erratic.
>
> ...
> > If I can't repro it with this chip, if you want to mess around with
it
> > on yours, here's what I think we had to do... I believe the trick
was
> > to use 16bpp mode as far as what mode you write to the chip, and
then
> > double all the x coordinate values for things like offset, width,
and
> > pitch. You would have to do that to the accelerated routines also.
>
> I'd be happy to mess around with the driver, but I won't have much
> time to do so until tomorrow. I'll let you know if I find anything,
> and of course I'll be happy to test patches.
>
> -ajw
Hello Charlotte,
I have just noticed that the garbled X-server mode is different
than what I thought it was. rinfo->depth is 24, but rinfo->bpp is 32.
(measured in radeon_write_mode). I haven't yet thought through the
implications of this. I've been unable to get the display correct, but
I've been trying to fix the wrong mode.
The console mode is ->depth==8, ->bpp==8, and presumably the same
when it's garbled, but I've been unable to reproduce the problem since
instrumenting the kernel.
On Wednesday 08 November 2006 09:01, Richardson, Charlotte wrote:
> ... Do you think I should submit
> a patch that at least enables 24bpp for the chip I have where it
> definitely does work? I'm sure that is overly restrictive, but I don't
> know which ones work and which are broken at this point.
That sounds like a good idea to me, but I'm not very familiar with the
programming practices here.
...
> If you get a chance before I do, you might look at what Xfree86 does -
> they might have the workaround.
It looks like the X.org radeon driver doesn't support 24bpp.
-ajw