Re: Linux 3.13-rc1 is out
This combination: # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_TRUSTED_KEYS=m (acquired by oldconfig and N to system keyring) fails with: Pass 2 CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o CC [M] crypto/asymmetric_keys/x509_cert_parser.o CC [M] crypto/asymmetric_keys/x509_public_key.o crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’: crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function) ret = x509_validate_trust(cert, system_trusted_keyring); ^ crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1 make[1]: *** [crypto/asymmetric_keys] Error 2 make: *** [crypto] Error 2 Perhaps include/keys/system_keyring.h should have a definition for system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING case (which may entail just removing the #ifdef). Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.13-rc1 is out
This combination: # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_TRUSTED_KEYS=m (acquired by oldconfig and N to system keyring) fails with: Pass 2 CC [M] crypto/asymmetric_keys/x509_rsakey-asn1.o CC [M] crypto/asymmetric_keys/x509_cert_parser.o CC [M] crypto/asymmetric_keys/x509_public_key.o crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’: crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function) ret = x509_validate_trust(cert, system_trusted_keyring); ^ crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [crypto/asymmetric_keys/x509_public_key.o] Error 1 make[1]: *** [crypto/asymmetric_keys] Error 2 make: *** [crypto] Error 2 Perhaps include/keys/system_keyring.h should have a definition for system_trusted_keyring in the #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING case (which may entail just removing the #ifdef). Commits b56e5a17b6b9acd1 and 09fbc47373826d67 are relevant. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely mem leak in 3.7
I've extensively tested 2844a48706e5 (tip at the time I compiled) for the last few days and have been unable to reproduce. This bug appears to be fixed. Thanks. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely mem leak in 3.7
I've extensively tested 2844a48706e5 (tip at the time I compiled) for the last few days and have been unable to reproduce. This bug appears to be fixed. Thanks. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely mem leak in 3.7
2048 168 : tunables000 : slabdata 0 0 0 dma-kmalloc-1024 0 0 1024 328 : tunables000 : slabdata 0 0 0 dma-kmalloc-512 32 32512 324 : tunables000 : slabdata 1 1 0 dma-kmalloc-2560 0256 322 : tunables000 : slabdata 0 0 0 dma-kmalloc-1280 0128 321 : tunables000 : slabdata 0 0 0 dma-kmalloc-64 0 0 64 641 : tunables000 : slabdata 0 0 0 dma-kmalloc-32 0 0 32 1281 : tunables000 : slabdata 0 0 0 dma-kmalloc-16 0 0 16 2561 : tunables000 : slabdata 0 0 0 dma-kmalloc-8 0 0 8 5121 : tunables000 : slabdata 0 0 0 dma-kmalloc-1920 0192 211 : tunables000 : slabdata 0 0 0 dma-kmalloc-96 0 0 96 421 : tunables000 : slabdata 0 0 0 kmalloc-8192 67 84 819248 : tunables000 : slabdata 21 21 0 kmalloc-4096 399520 409688 : tunables000 : slabdata 65 65 0 kmalloc-2048 526592 2048 168 : tunables000 : slabdata 37 37 0 kmalloc-10242012 2560 1024 328 : tunables000 : slabdata 80 80 0 kmalloc-512 1815 1920512 324 : tunables000 : slabdata 60 60 0 kmalloc-256 7960 9280256 322 : tunables000 : slabdata290290 0 kmalloc-128 4383 5216128 321 : tunables000 : slabdata163163 0 kmalloc-64 20326 40576 64 641 : tunables000 : slabdata634634 0 kmalloc-32 5760 5760 32 1281 : tunables000 : slabdata 45 45 0 kmalloc-16 5888 5888 16 2561 : tunables000 : slabdata 23 23 0 kmalloc-8 10752 10752 8 5121 : tunables000 : slabdata 21 21 0 kmalloc-192 4108 4935192 211 : tunables000 : slabdata235235 0 kmalloc-96 4701 6762 96 421 : tunables000 : slabdata161161 0 kmem_cache 224224256 322 : tunables000 : slabdata 7 7 0 kmem_cache_node 320320 64 641 : tunables000 : slabdata 5 5 0 free(1) reports: total used free sharedbuffers cached Mem: 12047072 11705824 341248 0 1742525542092 -/+ buffers/cache:59894806057592 Swap: 3670008 1298323540176 So the missing ram is un used (2nd row totals 12047072). I tried creating and deleting a large (1G) file on an ext4 and the xfs partition; the ram moved from cached to free in top(1). Doing the same thing on a btrfs partition lost about 200M of ram. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely mem leak in 3.7
000 : slabdata 0 0 0 dma-kmalloc-2048 0 0 2048 168 : tunables000 : slabdata 0 0 0 dma-kmalloc-1024 0 0 1024 328 : tunables000 : slabdata 0 0 0 dma-kmalloc-512 32 32512 324 : tunables000 : slabdata 1 1 0 dma-kmalloc-2560 0256 322 : tunables000 : slabdata 0 0 0 dma-kmalloc-1280 0128 321 : tunables000 : slabdata 0 0 0 dma-kmalloc-64 0 0 64 641 : tunables000 : slabdata 0 0 0 dma-kmalloc-32 0 0 32 1281 : tunables000 : slabdata 0 0 0 dma-kmalloc-16 0 0 16 2561 : tunables000 : slabdata 0 0 0 dma-kmalloc-8 0 0 8 5121 : tunables000 : slabdata 0 0 0 dma-kmalloc-1920 0192 211 : tunables000 : slabdata 0 0 0 dma-kmalloc-96 0 0 96 421 : tunables000 : slabdata 0 0 0 kmalloc-8192 67 84 819248 : tunables000 : slabdata 21 21 0 kmalloc-4096 399520 409688 : tunables000 : slabdata 65 65 0 kmalloc-2048 526592 2048 168 : tunables000 : slabdata 37 37 0 kmalloc-10242012 2560 1024 328 : tunables000 : slabdata 80 80 0 kmalloc-512 1815 1920512 324 : tunables000 : slabdata 60 60 0 kmalloc-256 7960 9280256 322 : tunables000 : slabdata290290 0 kmalloc-128 4383 5216128 321 : tunables000 : slabdata163163 0 kmalloc-64 20326 40576 64 641 : tunables000 : slabdata634634 0 kmalloc-32 5760 5760 32 1281 : tunables000 : slabdata 45 45 0 kmalloc-16 5888 5888 16 2561 : tunables000 : slabdata 23 23 0 kmalloc-8 10752 10752 8 5121 : tunables000 : slabdata 21 21 0 kmalloc-192 4108 4935192 211 : tunables000 : slabdata235235 0 kmalloc-96 4701 6762 96 421 : tunables000 : slabdata161161 0 kmem_cache 224224256 322 : tunables000 : slabdata 7 7 0 kmem_cache_node 320320 64 641 : tunables000 : slabdata 5 5 0 free(1) reports: total used free sharedbuffers cached Mem: 12047072 11705824 341248 0 1742525542092 -/+ buffers/cache:59894806057592 Swap: 3670008 1298323540176 So the missing ram is un used (2nd row totals 12047072). I tried creating and deleting a large (1G) file on an ext4 and the xfs partition; the ram moved from cached to free in top(1). Doing the same thing on a btrfs partition lost about 200M of ram. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Likely mem leak in 3.7
Starting with 3.7 rc1, my workstation seems to loose ram. Up until (and including) 3.6, used-(buffers+cached) was roughly the same as sum(rss) (taking shared into account). Now there is an approx 6G gap. When the box first starts, it is clearly less swappy than with <= 3.6; I can't tell whether that is related. The reduced swappiness persists. It seems to get worse when I update packages (it runs Gentoo). The portage tree and overlays are on btrfs filesystems. As is /var/log (with compression, except for the distfiles fs). The compilations themselves are done in a tmpfs. I CCed l-b because of that apparent correlation. My postgress db is on xfs (tested faster) and has a 3G shared segment, but that recovers when the pg process is stopped; neither of those seem to be implicated. There are also several ext4 partitions, including / and /home. Cgroups are configured, and openrc does put everything it starts into its own directory under /sys/fs/cgroup/openrc. But top(1) shows all of the processes, and its idea of free mem does change with pg's use of its shared segment. So it doesn't *look* like the ram is hiding in some cgroup. The kernel does not log anything relevant to this. Slabinfo gives some odd output. It seems to think there are negative quantities of some slabs: Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg :at-016 5632 1690.1K 18446744073709551363/0/275 256 0 0 100 *a :t-0483386 48 249.8K 18446744073709551558/22/119 85 0 36 65 * :t-1201022 120 167.9K 18446744073709551604/14/53 34 0 34 73 * blkdev_requests182 376 122.8K 18446744073709551604/7/27 21 1 46 55 ext4_io_end3481128 393.2K 18446744073709551588/0/40 29 3 0 99 a The largest entries it reports are: Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg ext4_inode_cache 38448 864 106.1M3201/566/39 37 3 17 31 a :at-104 316429 10436.5M 8840/3257/92 39 0 36 89 *a btrfs_inode 13271 98435.7M 1078/0/14 33 3 0 36 a radix_tree_node 43785 56034.7M 2075/1800/45 28 2 84 70 a dentry 64281 19214.3M 3439/1185/55 21 0 33 86 a proc_inode_cache 15695 60812.1M 693/166/51 26 2 22 78 a inode_cache 10730 544 6.0M 349/0/21 29 2 0 96 a task_struct6285896 4.3M 123/23/105 3 17 84 The total Space is much smaller than the missing ram. The only other difference I see is that one process has left behind several score zombies. It is structured as a parent with several worker kids, but the kids stay zombie even when the parent process is stopped and restarted. wchan shows that they are stuck in exit. Their normal rss isn't enough to account for the missing ram, even if it isn't reclaimed. (Not to mention, ram != brains. :) I haven't tried bisecting because of the time it takes to confirm the problem (several hours of uptime). I've only compiled (each of) the rc tags, so v3.6 is that last known good and v3.7-rc1 is the first known bad. If there is anything that I missed, please let me know! -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Likely mem leak in 3.7
Starting with 3.7 rc1, my workstation seems to loose ram. Up until (and including) 3.6, used-(buffers+cached) was roughly the same as sum(rss) (taking shared into account). Now there is an approx 6G gap. When the box first starts, it is clearly less swappy than with = 3.6; I can't tell whether that is related. The reduced swappiness persists. It seems to get worse when I update packages (it runs Gentoo). The portage tree and overlays are on btrfs filesystems. As is /var/log (with compression, except for the distfiles fs). The compilations themselves are done in a tmpfs. I CCed l-b because of that apparent correlation. My postgress db is on xfs (tested faster) and has a 3G shared segment, but that recovers when the pg process is stopped; neither of those seem to be implicated. There are also several ext4 partitions, including / and /home. Cgroups are configured, and openrc does put everything it starts into its own directory under /sys/fs/cgroup/openrc. But top(1) shows all of the processes, and its idea of free mem does change with pg's use of its shared segment. So it doesn't *look* like the ram is hiding in some cgroup. The kernel does not log anything relevant to this. Slabinfo gives some odd output. It seems to think there are negative quantities of some slabs: Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg :at-016 5632 1690.1K 18446744073709551363/0/275 256 0 0 100 *a :t-0483386 48 249.8K 18446744073709551558/22/119 85 0 36 65 * :t-1201022 120 167.9K 18446744073709551604/14/53 34 0 34 73 * blkdev_requests182 376 122.8K 18446744073709551604/7/27 21 1 46 55 ext4_io_end3481128 393.2K 18446744073709551588/0/40 29 3 0 99 a The largest entries it reports are: Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg ext4_inode_cache 38448 864 106.1M3201/566/39 37 3 17 31 a :at-104 316429 10436.5M 8840/3257/92 39 0 36 89 *a btrfs_inode 13271 98435.7M 1078/0/14 33 3 0 36 a radix_tree_node 43785 56034.7M 2075/1800/45 28 2 84 70 a dentry 64281 19214.3M 3439/1185/55 21 0 33 86 a proc_inode_cache 15695 60812.1M 693/166/51 26 2 22 78 a inode_cache 10730 544 6.0M 349/0/21 29 2 0 96 a task_struct6285896 4.3M 123/23/105 3 17 84 The total Space is much smaller than the missing ram. The only other difference I see is that one process has left behind several score zombies. It is structured as a parent with several worker kids, but the kids stay zombie even when the parent process is stopped and restarted. wchan shows that they are stuck in exit. Their normal rss isn't enough to account for the missing ram, even if it isn't reclaimed. (Not to mention, ram != brains. :) I haven't tried bisecting because of the time it takes to confirm the problem (several hours of uptime). I've only compiled (each of) the rc tags, so v3.6 is that last known good and v3.7-rc1 is the first known bad. If there is anything that I missed, please let me know! -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why not creating a GIT RT tree ?
>>>>> "Francis" == Francis Moreau <[EMAIL PROTECTED]> writes: >> It is in the one-head per patch style, and has the single-file >> patches applied rather than the quilt queue. Francis> Why don't you have one commit per patch ? I started it before they had the broken out patches and haven't spent the time to put together a process for the broken out patches akin to what I figured out for the all-in-one patches. In other words, intertia. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 -- 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/
Re: Why not creating a GIT RT tree ?
Francis == Francis Moreau [EMAIL PROTECTED] writes: It is in the one-head per patch style, and has the single-file patches applied rather than the quilt queue. Francis Why don't you have one commit per patch ? I started it before they had the broken out patches and haven't spent the time to put together a process for the broken out patches akin to what I figured out for the all-in-one patches. In other words, intertia. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- 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/
Re: Why not creating a GIT RT tree ?
>>>>> "Francis" == Francis Moreau <[EMAIL PROTECTED]> writes: Francis> I can't find a rt tree anywhere and all new rt release spoke Francis> about a patchset to apply on mainline kernels. It is not perfect, but I do have a git repo of the rt history-of-patches up at: git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git Gitweb URL is: http://git.kernel.org/?p=linux/kernel/git/cloos/rt-2.6.git It is in the one-head per patch style, and has the single-file patches applied rather than the quilt queue. But it will at least allow comparisons among the various versions. The master head matches the most current patch. (I try to keep it updated the same day as patches are announced, but it does sometimes lag a day or two.) -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 -- 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/
Re: Why not creating a GIT RT tree ?
Francis == Francis Moreau [EMAIL PROTECTED] writes: Francis I can't find a rt tree anywhere and all new rt release spoke Francis about a patchset to apply on mainline kernels. It is not perfect, but I do have a git repo of the rt history-of-patches up at: git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git Gitweb URL is: http://git.kernel.org/?p=linux/kernel/git/cloos/rt-2.6.git It is in the one-head per patch style, and has the single-file patches applied rather than the quilt queue. But it will at least allow comparisons among the various versions. The master head matches the most current patch. (I try to keep it updated the same day as patches are announced, but it does sometimes lag a day or two.) -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- 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/
Re: [discuss] [PATCH] spelling fixes: arch/x86_64/
>>>>> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: Alan> Re-enable is definitely "more correct". I don't disagree. Had I been more awake I expect I'd've :^) made that more clear. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [discuss] [PATCH] spelling fixes: arch/x86_64/
Alan == Alan Cox [EMAIL PROTECTED] writes: Alan Re-enable is definitely more correct. I don't disagree. Had I been more awake I expect I'd've :^) made that more clear. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [discuss] [PATCH] spelling fixes: arch/x86_64/
>>>>> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes: >> -/* Reenable any watchpoints before delivering the >> +/* Re-enable any watchpoints before delivering the Andi> reenable gets >140k google hits so it seems to be an really Andi> used word. Essentially all commonly used English words which start out with hyphens loose them over time. It starts out with typos and progresses until the non-hyphenated form becomes the exclusively used form. It does seem that re-enable → reenable is occurring, based on those search hits. Andi> Similar with upto. I’ve a *much* harder time agreeing with «upto» in place of «up to». That should be treated as a typo in need of fixing. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [discuss] [PATCH] spelling fixes: arch/x86_64/
Andi == Andi Kleen [EMAIL PROTECTED] writes: -/* Reenable any watchpoints before delivering the +/* Re-enable any watchpoints before delivering the Andi reenable gets 140k google hits so it seems to be an really Andi used word. Essentially all commonly used English words which start out with hyphens loose them over time. It starts out with typos and progresses until the non-hyphenated form becomes the exclusively used form. It does seem that re-enable → reenable is occurring, based on those search hits. Andi Similar with upto. I’ve a *much* harder time agreeing with «upto» in place of «up to». That should be treated as a typo in need of fixing. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [patch] CFS scheduler, -v10
>>>>> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes: >> If instead of pulling master into the cfs branch, I rather switch to >> the master branch and pull the cfs branch into that, it works. Ingo> ah! Could you please do a git-diff between the broken and the working Ingo> tree, to see what got mismerged? Yes, I can work on that tonight. There will be some noise, but at least both have master == dc87c3985e9b442c60994308a96f887579addc39. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [patch] CFS scheduler, -v10
|> git checkout -b git checkout -b cfs v2.6.21 Damn, sorry about the typo. That should of course be: #!/bin/sh git clone -l -s -n \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ 2.6.21-cfs-master cd 2.6.21-cfs-master git checkout -b cfs v2.6.21 git pull git://people.freedesktop.org/~cloos/cfs-2.6.git git checkout master git pull . cfs -JimC - 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/
Re: [patch] CFS scheduler, -v10
I finally had time to try bisecting the problem I was having with cfs8 and master Sunday, and was able to eliminate the problem. I had first done: clone branch checkout apply commit pull If instead of pulling master into the cfs branch, I rather switch to the master branch and pull the cfs branch into that, it works. I'll try updating to the current master with v10 to confirm. For those who want to follow, do: #!/bin/sh git clone -l -s -n \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ 2.6.21-cfs-master cd 2.6.21-cfs-master git checkout -b git checkout -b cfs v2.6.21 git pull git://people.freedesktop.org/~cloos/cfs-2.6.git git checkout master git pull . cfs The master branch of git://people.freedesktop.org/~cloos/cfs-2.6.git has 2.6.21 with the sched-cfs-v10-v2.6.21.1.patch. Cf gitweb at: http://gitweb.freedesktop.org/?p=/users/cloos/cfs-2.6.git -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [patch] CFS scheduler, -v10
I finally had time to try bisecting the problem I was having with cfs8 and master Sunday, and was able to eliminate the problem. I had first done: clone branch checkout apply commit pull If instead of pulling master into the cfs branch, I rather switch to the master branch and pull the cfs branch into that, it works. I'll try updating to the current master with v10 to confirm. For those who want to follow, do: #!/bin/sh git clone -l -s -n \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ 2.6.21-cfs-master cd 2.6.21-cfs-master git checkout -b git checkout -b cfs v2.6.21 git pull git://people.freedesktop.org/~cloos/cfs-2.6.git git checkout master git pull . cfs The master branch of git://people.freedesktop.org/~cloos/cfs-2.6.git has 2.6.21 with the sched-cfs-v10-v2.6.21.1.patch. Cf gitweb at: http://gitweb.freedesktop.org/?p=/users/cloos/cfs-2.6.git -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [patch] CFS scheduler, -v10
| git checkout -b git checkout -b cfs v2.6.21 Damn, sorry about the typo. That should of course be: #!/bin/sh git clone -l -s -n \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ 2.6.21-cfs-master cd 2.6.21-cfs-master git checkout -b cfs v2.6.21 git pull git://people.freedesktop.org/~cloos/cfs-2.6.git git checkout master git pull . cfs -JimC - 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/
Re: [patch] CFS scheduler, -v10
Ingo == Ingo Molnar [EMAIL PROTECTED] writes: If instead of pulling master into the cfs branch, I rather switch to the master branch and pull the cfs branch into that, it works. Ingo ah! Could you please do a git-diff between the broken and the working Ingo tree, to see what got mismerged? Yes, I can work on that tonight. There will be some noise, but at least both have master == dc87c3985e9b442c60994308a96f887579addc39. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
keyboard and mouse regresions as of dc87c398 plus cfs-v7
I just tried out git as of commit dc87c398 plus Ingo's cfs v6 patch. I'll try out w/o the patch to confirm later this morning. The kernel log shows no indication of a problem, but the (ps/2) mice do not work, and the keyboard repeat is *very* slow, and will not speed up if changed with xset(1x). >From dmesg(1): [ 25.448092] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 25.460470] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 25.466816] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 25.473262] mice: PS/2 mouse device common for all mice [ 25.484605] input: AT Translated Set 2 keyboard as /class/input/input3 [ 25.497339] input: PC Speaker as /class/input/input4 but no /class/input entry gets generated for the mice. /proc/interupts shows 5 ints for irq 12, and that does not increment no matter what is done to the trackpoint, syn pad or external ps/2 mouse. My last known good version was 0f851021c0f91e5073fa89f26b5ac68e23df8e11 plus the rt patch. To get dc87c398 plus cfs-v7 I cloned, checked out v2.6.21, applied the cfs-v7 patch and then pulled in master. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
keyboard and mouse regresions as of dc87c398 plus cfs-v7
I just tried out git as of commit dc87c398 plus Ingo's cfs v6 patch. I'll try out w/o the patch to confirm later this morning. The kernel log shows no indication of a problem, but the (ps/2) mice do not work, and the keyboard repeat is *very* slow, and will not speed up if changed with xset(1x). From dmesg(1): [ 25.448092] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 25.460470] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 25.466816] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 25.473262] mice: PS/2 mouse device common for all mice [ 25.484605] input: AT Translated Set 2 keyboard as /class/input/input3 [ 25.497339] input: PC Speaker as /class/input/input4 but no /class/input entry gets generated for the mice. /proc/interupts shows 5 ints for irq 12, and that does not increment no matter what is done to the trackpoint, syn pad or external ps/2 mouse. My last known good version was 0f851021c0f91e5073fa89f26b5ac68e23df8e11 plus the rt patch. To get dc87c398 plus cfs-v7 I cloned, checked out v2.6.21, applied the cfs-v7 patch and then pulled in master. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
using the rt patch with rc7 (or git HEAD)
This recipe results in only two conflicts. The obvious and easily fixed
EXTRAVERSION conflict as well as the conflict shown below from kernel/sched.c:
#!/bin/sh
git clone -n
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
2.6.21-rc7-rt
cd 2.6.21-rc7-rt
git branch rc6 v2.6.21-rc6
git branch rc7 v2.6.21-rc7
git branch rc6-rt0 rc6
git checkout rc6-rt0
git pull git://people.freedesktop.org/~cloos/rt-2.6.git 2.6.21-rc6-rt0
git branch rc7-rt
git checkout rc7-rt
git pull . rc7
The conlict is:
,( conflict from kernel/sched.c from pulling rc7 into rc6-rt0 )
| <<<<<<< HEAD:kernel/sched.c
| static inline struct task_struct *eldest_child(struct task_struct *p)
| {
| if (list_empty(>children))
| return NULL;
| return list_entry(p->children.next,struct task_struct,sibling);
| }
|
| static inline struct task_struct *older_sibling(struct task_struct *p)
| {
| if (p->sibling.prev==>parent->children)
| return NULL;
| return list_entry(p->sibling.prev,struct task_struct,sibling);
| }
|
| static inline struct task_struct *younger_sibling(struct task_struct *p)
| {
| if (p->sibling.next==>parent->children)
| return NULL;
| return list_entry(p->sibling.next,struct task_struct,sibling);
| }
|
| static const char stat_nam[] = "RMSDTtZX";
| ===
| static const char stat_nam[] = "RSDTtZX";
| >>>>>>> 94a05509a9e11806acd797153d03019706e466f1:kernel/sched.c
`
Resolving that conflict (I tried using the <<<<<<< version) and the
EXTRAVERSION conflict allows a subsequent git pull . master to complete
w/o conflicts.
Obviously keeping the three functions in won't harm the resulting
kernel, but is leaving the M in stat_nam[] the correct resolution?
I'll be testing this kernel later this afternoon. (As soon as I
can do the reboot.)
Incidently, has anyone tried combining the rt patches with any of
the scheduler patches?
-JimC
--
James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6
-
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/
using the rt patch with rc7 (or git HEAD)
This recipe results in only two conflicts. The obvious and easily fixed
EXTRAVERSION conflict as well as the conflict shown below from kernel/sched.c:
#!/bin/sh
git clone -n
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
2.6.21-rc7-rt
cd 2.6.21-rc7-rt
git branch rc6 v2.6.21-rc6
git branch rc7 v2.6.21-rc7
git branch rc6-rt0 rc6
git checkout rc6-rt0
git pull git://people.freedesktop.org/~cloos/rt-2.6.git 2.6.21-rc6-rt0
git branch rc7-rt
git checkout rc7-rt
git pull . rc7
The conlict is:
,( conflict from kernel/sched.c from pulling rc7 into rc6-rt0 )
| HEAD:kernel/sched.c
| static inline struct task_struct *eldest_child(struct task_struct *p)
| {
| if (list_empty(p-children))
| return NULL;
| return list_entry(p-children.next,struct task_struct,sibling);
| }
|
| static inline struct task_struct *older_sibling(struct task_struct *p)
| {
| if (p-sibling.prev==p-parent-children)
| return NULL;
| return list_entry(p-sibling.prev,struct task_struct,sibling);
| }
|
| static inline struct task_struct *younger_sibling(struct task_struct *p)
| {
| if (p-sibling.next==p-parent-children)
| return NULL;
| return list_entry(p-sibling.next,struct task_struct,sibling);
| }
|
| static const char stat_nam[] = RMSDTtZX;
| ===
| static const char stat_nam[] = RSDTtZX;
| 94a05509a9e11806acd797153d03019706e466f1:kernel/sched.c
`
Resolving that conflict (I tried using the version) and the
EXTRAVERSION conflict allows a subsequent git pull . master to complete
w/o conflicts.
Obviously keeping the three functions in won't harm the resulting
kernel, but is leaving the M in stat_nam[] the correct resolution?
I'll be testing this kernel later this afternoon. (As soon as I
can do the reboot.)
Incidently, has anyone tried combining the rt patches with any of
the scheduler patches?
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
-
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/
Re: 2.6.21-rc3-mm1 RSDL results
|> See: |> http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37=markup OK. Mesa is in git, now, but that still applies. The gitweb url is: http://gitweb.freedesktop.org/?p=mesa/mesa.git and for the version of the above file in the master branch: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;f=src/mesa/drivers/dri/r200/r200_ioctl.c The recursive grep(1) on mesa shows: ,[grep -r sched_yield mesa] | mesa/mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchpool.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchbuffer.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include/* for sched_yield() */ | mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include/* for sched_yield() */ | mesa/mesa/src/mesa/drivers/dri/common/vblank.h: sched_yield(); \ | mesa/mesa/src/mesa/drivers/dri/unichrome/via_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915/intel_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/r200/r200_ioctl.c: sched_yield(); ` Thanks for the heads up. I must've grep(1)ed the xorg subdir rather than the parent dir, and so missed mesa. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: 2.6.21-rc3-mm1 RSDL results
| See: | http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c?revision=1.37view=markup OK. Mesa is in git, now, but that still applies. The gitweb url is: http://gitweb.freedesktop.org/?p=mesa/mesa.git and for the version of the above file in the master branch: http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;f=src/mesa/drivers/dri/r200/r200_ioctl.c The recursive grep(1) on mesa shows: ,[grep -r sched_yield mesa] | mesa/mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchpool.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchbuffer.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include sched.h /* for sched_yield() */ | mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include sched.h /* for sched_yield() */ | mesa/mesa/src/mesa/drivers/dri/common/vblank.h: sched_yield(); \ | mesa/mesa/src/mesa/drivers/dri/unichrome/via_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/i915/intel_ioctl.c: sched_yield(); | mesa/mesa/src/mesa/drivers/dri/r200/r200_ioctl.c: sched_yield(); ` Thanks for the heads up. I must've grep(1)ed the xorg subdir rather than the parent dir, and so missed mesa. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: 2.6.21-rc3-mm1 RSDL results
>>>>> "Con" == Con Kolivas <[EMAIL PROTECTED]> writes: Con> It's sad that sched_yield is still in our graphics card drivers ... I just did a recursive grep(1) on my mirror of the freedesktop git repos for sched_yield. This only checked the master branches as I did not bother to script up something to clone each, check out all branches in turn, and grep(1) each possibility. The output is just: :; grep -r sched_yield FDO/xorg FDO/xorg/xserver/hw/kdrive/via/viadraw.c: sched_yield(); FDO/xorg/driver/xf86-video-glint/src/pm2_video.c:if (sync) /* sched_yield? */ Is there something else I should grep(1) for? If not, it looks as if sched_yield(2) has been evicted from the drivers. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: 2.6.21-rc3-mm1 RSDL results
Con == Con Kolivas [EMAIL PROTECTED] writes: Con It's sad that sched_yield is still in our graphics card drivers ... I just did a recursive grep(1) on my mirror of the freedesktop git repos for sched_yield. This only checked the master branches as I did not bother to script up something to clone each, check out all branches in turn, and grep(1) each possibility. The output is just: :; grep -r sched_yield FDO/xorg FDO/xorg/xserver/hw/kdrive/via/viadraw.c: sched_yield(); FDO/xorg/driver/xf86-video-glint/src/pm2_video.c:if (sync) /* sched_yield? */ Is there something else I should grep(1) for? If not, it looks as if sched_yield(2) has been evicted from the drivers. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [Fwd: escape key]
>>>>> "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes: Jan> HOWEVER, unix people probably _had a reason_ to make ESC generate Jan> part of what function keys do. You are looking at it backwards. The Escape key generates an ASCII escape. The funtion keys (including the cursor keys) generate escape sequences because the vt100 won out the title as the most ubiquitous async serial terminal, and linux devs chose to have the console be (mostly) vt100 compatable. As xterm, et al had done before. The terminals (the actual hardware) used ASCII, so it was normal to use Escape to initiate the sequences used by the function keys. And that concept goes back a *lot* longer than unix. (Hmm. I can't remember. Did TOPS-20 or its predecessor have glass terminals in the day? I did get to use a DEC paper terminal a couple of times, but that was connected to a VMS box back in the '80s; most of the time it sat in the corner collecting dust) At any rate, given that Escape was used to initiate sequences sent to the terminal for funtions such as moving the cursor around the screen, clearing rows or cols, et al it must have only seemed natural to also have it initiate sequences /from/ the terminal which did not fit into standard ASCII. That was after all Escape's purpose in the ASCII std. If you do want to change the console's terminal emulation, a good first step would be to check whether any existing terminal already uses something other than Escape to initiate function key sequences, and, if so, promote that as the alternative to vt100-esque emulation. Finally, note that the reason vt100 was chosen for the console was to make it more useful for users who were physically at a linux box, were logged in on the console, and from there logged in to remote servers. That does remain something which the console *must* support. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
Re: [Fwd: escape key]
Jan == Jan Engelhardt [EMAIL PROTECTED] writes: Jan HOWEVER, unix people probably _had a reason_ to make ESC generate Jan part of what function keys do. You are looking at it backwards. The Escape key generates an ASCII escape. The funtion keys (including the cursor keys) generate escape sequences because the vt100 won out the title as the most ubiquitous async serial terminal, and linux devs chose to have the console be (mostly) vt100 compatable. As xterm, et al had done before. The terminals (the actual hardware) used ASCII, so it was normal to use Escape to initiate the sequences used by the function keys. And that concept goes back a *lot* longer than unix. (Hmm. I can't remember. Did TOPS-20 or its predecessor have glass terminals in the day? I did get to use a DEC paper terminal a couple of times, but that was connected to a VMS box back in the '80s; most of the time it sat in the corner collecting dust) At any rate, given that Escape was used to initiate sequences sent to the terminal for funtions such as moving the cursor around the screen, clearing rows or cols, et al it must have only seemed natural to also have it initiate sequences /from/ the terminal which did not fit into standard ASCII. That was after all Escape's purpose in the ASCII std. If you do want to change the console's terminal emulation, a good first step would be to check whether any existing terminal already uses something other than Escape to initiate function key sequences, and, if so, promote that as the alternative to vt100-esque emulation. Finally, note that the reason vt100 was chosen for the console was to make it more useful for users who were physically at a linux box, were logged in on the console, and from there logged in to remote servers. That does remain something which the console *must* support. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: drivers/video/aty/radeon_backlight.c
>>>>> "Michael" == Michael Hanselmann <[EMAIL PROTECTED]> writes: JimC> Are there any dependencies in $subject which would preclude JimC> changing drivers/video/Kconfig Michael> Yes. Ok. Thanks. JimC> is radeon_backlight.c only functional when -DCONFIG_PMAC_BACKLIGHT, JimC> even though the pmac routines are all ifdef'ed? Michael> Did you actually test wether it works? As far as I know, Michael> only Apple (PowerPC) hardware uses these registers yet Michael> and have no use anywhere else. No, I only noticed the file by coincidence and wanted to find out about it before testing. Thanks for the quick reply! -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
drivers/video/aty/radeon_backlight.c
Are there any dependencies in $subject which would preclude changing drivers/video/Kconfig with: config FB_RADEON_BACKLIGHT bool "Support for backlight control" -depends on FB_RADEON && PMAC_BACKLIGHT +depends on FB_RADEON select FB_BACKLIGHT default y help Say Y here if you want to control the backlight of your display. or is radeon_backlight.c only functional when -DCONFIG_PMAC_BACKLIGHT, even though the pmac routines are all ifdef'ed? -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 - 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/
drivers/video/aty/radeon_backlight.c
Are there any dependencies in $subject which would preclude changing drivers/video/Kconfig with: config FB_RADEON_BACKLIGHT bool Support for backlight control -depends on FB_RADEON PMAC_BACKLIGHT +depends on FB_RADEON select FB_BACKLIGHT default y help Say Y here if you want to control the backlight of your display. or is radeon_backlight.c only functional when -DCONFIG_PMAC_BACKLIGHT, even though the pmac routines are all ifdef'ed? -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: drivers/video/aty/radeon_backlight.c
Michael == Michael Hanselmann [EMAIL PROTECTED] writes: JimC Are there any dependencies in $subject which would preclude JimC changing drivers/video/Kconfig Michael Yes. Ok. Thanks. JimC is radeon_backlight.c only functional when -DCONFIG_PMAC_BACKLIGHT, JimC even though the pmac routines are all ifdef'ed? Michael Did you actually test wether it works? As far as I know, Michael only Apple (PowerPC) hardware uses these registers yet Michael and have no use anywhere else. No, I only noticed the file by coincidence and wanted to find out about it before testing. Thanks for the quick reply! -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 - 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/
Re: State of Linux graphics
> "Ian" == Ian Romanick <[EMAIL PROTECTED]> writes: Ian> I'd really like to see a list of areas where OpenGL Ian> isn't up to snuff for 2D operations. Is that OpenVR spec from Khronos a reasonable baseline for such a list? -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> - 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/
Re: State of Linux graphics
Ian == Ian Romanick [EMAIL PROTECTED] writes: Ian I'd really like to see a list of areas where OpenGL Ian isn't up to snuff for 2D operations. Is that OpenVR spec from Khronos a reasonable baseline for such a list? -JimC -- James H. Cloos, Jr. [EMAIL PROTECTED] - 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/
Re: [Patch] Support UTF-8 scripts
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes: Alan> The command line console mappings may not include them by Alan> default (you can obviously add them if your keyboard lacks Alan> them). The X keyboard however does include compose functionality Alan> for » and « and many other symbols that might be useful eg ± Not to mention that many editors, including emacs and vim, have their own support for entering such non-ascii characters no matter what the console or X11 keyboards look like. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> - 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/
Re: [Patch] Support UTF-8 scripts
Alan == Alan Cox [EMAIL PROTECTED] writes: Alan The command line console mappings may not include them by Alan default (you can obviously add them if your keyboard lacks Alan them). The X keyboard however does include compose functionality Alan for » and « and many other symbols that might be useful eg ± Not to mention that many editors, including emacs and vim, have their own support for entering such non-ascii characters no matter what the console or X11 keyboards look like. -JimC -- James H. Cloos, Jr. [EMAIL PROTECTED] - 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/
Re: [PATCH] Wireless Security Lock driver.
> "Pavel" == Pavel Machek <[EMAIL PROTECTED]> writes: >> Would /dev/input/mice not also be affected? Pavel> Yes, /dev/input/mice == /dev/psaux. What I get for looking in /dev (c 10 1 vs c 13 63) rather than /usr/src/linux. :-/ -JimC - 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/
Re: [PATCH] Wireless Security Lock driver.
> "Pavel" == Pavel Machek <[EMAIL PROTECTED]> writes: Pavel> Well, that is if you use /dev/psaux, right? Using event devices Pavel> you should be able to access it from userland. Would /dev/input/mice not also be affected? Until X can hotplug input devices /dev/input/mice rather than evdev will remain necessary in many cases for a reasonable user experience. So at least a quirk/whatever to keep that device from being included in mice (and psaux) should be added. -JimC -- James H. Cloos, Jr. <[EMAIL PROTECTED]> - 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/
Re: [PATCH] Wireless Security Lock driver.
Pavel == Pavel Machek [EMAIL PROTECTED] writes: Pavel Well, that is if you use /dev/psaux, right? Using event devices Pavel you should be able to access it from userland. Would /dev/input/mice not also be affected? Until X can hotplug input devices /dev/input/mice rather than evdev will remain necessary in many cases for a reasonable user experience. So at least a quirk/whatever to keep that device from being included in mice (and psaux) should be added. -JimC -- James H. Cloos, Jr. [EMAIL PROTECTED] - 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/
Re: [PATCH] Wireless Security Lock driver.
Pavel == Pavel Machek [EMAIL PROTECTED] writes: Would /dev/input/mice not also be affected? Pavel Yes, /dev/input/mice == /dev/psaux. What I get for looking in /dev (c 10 1 vs c 13 63) rather than /usr/src/linux. :-/ -JimC - 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/
from line script for git commits
I've been using a script grabbed from here for some time to alter the From: line on mail sent to bk-head-commits and bk-24-commits to show the author's name and email rather than LKML's address. Below is my script for doing the same with git commit emails. -JimC set-git-from.pl Description: Perl program
from line script for git commits
I've been using a script grabbed from here for some time to alter the From: line on mail sent to bk-head-commits and bk-24-commits to show the author's name and email rather than LKML's address. Below is my script for doing the same with git commit emails. -JimC set-git-from.pl Description: Perl program
