* [KJ][Patch] fix kbuild warnings in savagefb.o
From: Darren Jenkins\ @ 2006-04-01 4:28 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
G'day list
There are a few kbuild warnings in drivers/video/savage/
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.data:savagefb_devices from .data between 'savagefb_driver' (at
offset 0x38) and 'savagefb_ops'
This one is the same false positive for the pci device id as before.
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .exit.text after 'savagefb_remove' (at offset 0x6e)
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .exit.text after 'savagefb_remove' (at offset 0x66)
These two are caused by savagefb_remove() which is marked __devexit
calling savage_unmap_mmio() and savage_unmap_video() which are marked as
__devinit.
WARNING: drivers/video/savage/savagefb.o - Section mismatch: reference
to .init.text: from .text between 'savagefb_resume' (at offset 0x232b)
and 'savage4_gpio_getscl'
This one is caused by savagefb_resume() which is un-annotated calling
savage_init_hw() which is marked as __devinit.
The patch below removes the __devinit annotations in all three cases.
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
--- linux-2.6.16-git13/drivers/video/savage/savagefb_driver.c.orig 2006-04-01 14:12:39.000000000 +1100
+++ linux-2.6.16-git13/drivers/video/savage/savagefb_driver.c 2006-04-01 14:41:24.000000000 +1100
@@ -1545,7 +1545,7 @@ static int __devinit savage_map_mmio (st
return 0;
}
-static void __devinit savage_unmap_mmio (struct fb_info *info)
+static void savage_unmap_mmio (struct fb_info *info)
{
struct savagefb_par *par = info->par;
DBG ("savage_unmap_mmio");
@@ -1597,7 +1597,7 @@ static int __devinit savage_map_video (s
return 0;
}
-static void __devinit savage_unmap_video (struct fb_info *info)
+static void savage_unmap_video (struct fb_info *info)
{
struct savagefb_par *par = info->par;
@@ -1614,7 +1614,7 @@ static void __devinit savage_unmap_video
}
}
-static int __devinit savage_init_hw (struct savagefb_par *par)
+static int savage_init_hw (struct savagefb_par *par)
{
unsigned char config1, m, n, n1, n2, sr8, cr3f, cr66 = 0, tmp;
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: Default remote branch for local branch
From: Pavel Roskin @ 2006-04-01 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzmngfp.fsf@assigned-by-dhcp.cox.net>
Hello, Junio!
On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
> - Multiple subsystem maintainer trees tracked in the same local
> repository. Most generally, two local branches per each
> remote head can be used (one tracking branch to fetch into,
> another to build your changes based on it). Alternatively,
> you can use one local branch per each remote head without
> using any tracking branch.
>
> Your proposal to give default branch to pull from per the local
> branch would help only the last case.
Exactly. I tried to track the main Linus repository and Jeff Garzik's
netdev in one place. Then I discovered that my repository if full of
unintended merges made by "stg pull".
> The first one you do not
> switch between local branches at all and pull from many
> different places; the second is to merge from different topic
> branches from time to time and does not benefit from fixed
> configuration; the third does not even need configuration.
>
> Maybe you would want something like this.
>
> In $GIT_DIR/config:
>
> [pull]
> origin = linus for master
> origin = irq-pio of libata for ata-irq-pio
> origin = pata-drivers of libata for ata-pata
First of all, using "origin" on every line carries to little
information.
Secondly, I think the relationship should be between a local development
branch and a local tracking branch. After all, all remote data is
placed on a local tracking branch first. It's better not to jump over
layers of abstraction. Suppose I want to update "masterB". I tell git
to sync "originB" first. git already has rules what to do if it should
sync "originB". Let's not supersede those rules.
I would write the config like this:
[branch-upstream]
master = linus
ata-irq-pio = irq-pio
ata-pata = pata-drivers
> While we are on the topic, it _might_ be worthwhile to think
> about revamping the syntax of $GIT_DIR/remotes file, maybe even
> breaking backward compatibility. The Pull: lines can be
> independently specified which gives flexibility, but I suspect
> local tracking branches from the same remote tend to live in the
> same place; IOW, you would probably not do something like:
>
> URL: git://git.kernel.org/.../jgarzik/libata-dev.git
> Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
> Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
>
> in practice.
Sorry, I don't understand this part.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [CMT 00/16] qla4xxx: driver review
From: Doug Maxey @ 2006-04-01 4:18 UTC (permalink / raw)
To: Ravi Anand; +Cc: Linux SCSI Mailing List
Howdy!
I know the driver works very well for this stage of maturity. It survived
96+ hours of I/O stress test on a power5 system, driving 2 targets
through 2 402x cards.
Now lets make the code look as good as it works. :->
Here is my review of the qla4xxx driver as patched up through the
0011-Updated-scsi-Kconfig-to-include-qla4xxx-Kconfig-path.txt.
The breakdown is by alphabetical filenames from a diff of all the
files with the latest patches.
Followups in this series:
[CMT 01/16] qla4xxx: driver review ql4_attr.c
[CMT 02/16] qla4xxx: driver review ql4_dbg.c
[CMT 03/16] qla4xxx: driver review ql4_dbg.h
[CMT 04/16] qla4xxx: driver review ql4_def.h
[CMT 05/16] qla4xxx: driver review ql4_fw.h
[CMT 06/16] qla4xxx: driver review ql4_glbl.h
[CMT 07/16] qla4xxx: driver review ql4_init.c
[CMT 08/16] qla4xxx: driver review ql4_inline.h
[CMT 09/16] qla4xxx: driver review ql4_iocb.c
[CMT 10/16] qla4xxx: driver review ql4_isr.c
[CMT 11/16] qla4xxx: driver review ql4_mbx.c
[CMT 12/16] qla4xxx: driver review ql4_nvram.c
[CMT 13/16] qla4xxx: driver review ql4_nvram.h
[CMT 14/16] qla4xxx: driver review ql4_os.c
[CMT 15/16] qla4xxx: driver review ql4_setting.h
[CMT 16/16] qla4xxx: driver review ql4_version.h
++doug
^ permalink raw reply
* Re: [patch] make evtchn_upcall_pending arch-specific type
From: Jimi Xenidis @ 2006-04-01 3:55 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, Hollis Blanchard, xen-ppc-devel
In-Reply-To: <5764fe373f0ae77a75e8a9a8e2826900@cl.cam.ac.uk>
On Mar 31, 2006, at 7:46 AM, Keir Fraser wrote:
>
> On 30 Mar 2006, at 20:13, Hollis Blanchard wrote:
>
>> evtchn_upcall_pending is another variable that bitops are used on,
>> so PowerPC
>> wants it to be a long. Unfortunately, it's also part of the guest/
>> hypervisor
>> interface, so we can't change it for architectures with existing
>> guests.
>>
>> Compile-tested on x86(-32). Please apply.
>
> Before going down this route, what about just casting the field to
> long, since it is actually aligned on a suitable boundary, as it
> happens?
We tried that, but to get the right bit we would have to use 56 not 0.
So this brings me to a possible solution:
Since both evtchn_upcall_pending and mask are paired and aligned and
padded to long we could group them together, like:
unsigned long evtchn_upcall_bits;
Then:
#define EVTCHN_UPCALL_PENDING 0
#define EVTCHN_UPCALL_MASK 8
use the macros to define the bit arg of the bitop_*().
I chose these values because they would be completely compatible with
any assembler that exist for the itty bitty byte arches. :) As for
PPC the values don't matter to us, at this early stage.
We could also get into magical union/structs with more abstracted
interfaces, but the above is rather simple.
> And what will your solution be for fields in grant_entry structure?
yeah, grant_entry.flags will be a pain because it is 16 bit and you
also use cmpxchg() on it.
I suppose we could abstract those bit changes, but yeah, this one is
gonna hurt :(
> That's another one where the fields to be atomically updated are at
> least 8-byte aligned, and where using longer types will bloat a
> structure that we'd prefer to pack nicely.
The I'd rather bloat (for PPC only) then come up with some nasty read/
calculate-the-actual-bit-and-modify/write.
>
> If this is the best way for ppc then I think atomic_bit_t would be
> a nicer typedef.
I think a context specific typedef would be better, in most cases.
Also,
- I'd like to see more use of DECLARE_BITMAP() for stuff like
pirq_mask
- more use of BITS_PER_LONG instead of (sizeof(long)*8) that
occurs in many places like evtchn_pending[]
-JX
^ permalink raw reply
* The US Economy WIll Collapse, Be Prepared qzu7b
From: Jamaal E. Kendrick @ 2006-04-01 3:49 UTC (permalink / raw)
To: sparclinux
Newsletter Subscriber,
As we all know the real estate market is about to crash.
In Feb 2006 there were 117,259 foreclosures alone(68% higher
than 2005 and rates are going higher everyday). Many investors
are now playing the stock market which is expected to explode
25 to 50% over the next 3 years. Now is the time to get in the
game and we will show you step by step so you can profit very
big. We also give you the very best picks all around the world
on every exchange that are profitable not just the U.S. Markets.
This is your chance to learn the game and make huge daily returns.
Now you can "Profit Like A Pro" And Win Big! We will not only
give you the very best daily picks around the world that have
the most profit potential but you will become financially savvy
and learn the inside of the markets how they work and how your
broker makes a fortune if you win or lose. Now you can win!
Get A Complimentary Copy Our 195 Page Book By Going Too:
http://www.superstockprofits.com
^ permalink raw reply
* Fwd: Complete Guide To Stock Investing. wmqgy
From: Phil T. Rushing @ 2006-04-01 3:48 UTC (permalink / raw)
To: sparclinux
Newsletter Subscriber,
As we all know the real estate market is about to crash.
In Feb 2006 there were 117,259 foreclosures alone(68% higher
than 2005 and rates are going higher everyday). Many investors
are now playing the stock market which is expected to explode
25 to 50% over the next 3 years. Now is the time to get in the
game and we will show you step by step so you can profit very
big. We also give you the very best picks all around the world
on every exchange that are profitable not just the U.S. Markets.
This is your chance to learn the game and make huge daily returns.
Now you can "Profit Like A Pro" And Win Big! We will not only
give you the very best daily picks around the world that have
the most profit potential but you will become financially savvy
and learn the inside of the markets how they work and how your
broker makes a fortune if you win or lose. Now you can win!
Get A Complimentary Copy Our 195 Page Book By Going Too:
http://www.superstockprofits.com
^ permalink raw reply
* Re: addendum: was Re: recovering data on a failed raid-0 installation
From: Technomage @ 2006-04-01 3:44 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <200603311901.03360.technomage-hawke@cox.net>
ok,
seems I made a mistake in how this silly mail client is configured.
so, in that, I do apologize for having this show up on the list (doh!)
this was meant to be private and should have remained that way.
On Friday 31 March 2006 19:01, Technomage wrote:
> Jeff,
> I would if I could. but I live on a rather limited income here . :(
>
> also, my chances for employment (other than self-contracted services) in
> phoenix are slim and none (being disabled in a market with a very soft tech
> sector can lead to that).
>
> now, I don't mean to be abrasive, but, so far, I haven't seen much other
> than: 1. it can't be done or
> 2. hire a paid consultant.
>
> as for 1, if a pro can do it, it stands to reason that someone, somewhere
> (not a pro) found the way and made his millions on it.
>
> as for 2, not going to be possible on $600.00 a month.
>
> On Friday 31 March 2006 15:10, Jeff Breidenbach wrote:
> > Technomage, I recommend hiring a paid consultant; your attitude is a
> > little too abrasive for a communal support channel.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* power consumption trivia
From: David Mosberger-Tang @ 2006-04-01 3:40 UTC (permalink / raw)
To: linux-ia64
In case you ever wondered how much power your Itanium machine draws, here are
measurements for 2 "random" machines, measured with a P4400 Kill A
Watt^{TM} meter:
plugged in: booted: make -j4:
HP zx2000 (1x900MHz McKinley): 10W
210W 250W
SGI Prism (2x1.6GHz Madison, 2x ATI X2 graphics): 20W
377W 385W
I won't vouch for the accuracy of the P4400, but at least it some numbers... ;-)
Enjoy,
--david
--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
^ permalink raw reply
* Re: [patch] avoid unaligned access when accessing poll stack
From: Mitchell Blank Jr @ 2006-04-01 3:39 UTC (permalink / raw)
To: Jes Sorensen
Cc: Andi Kleen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <20060401023538.GB3157@gaz.sfgoth.com>
Here's a slightly updated version of my patch: it changes the
if (size < sizeof(stack_fds) / 6)
to:
if (size <= sizeof(stack_fds) / 6)
Otherwise this is exactly the same as the version I just posted. The old
code had this problem too but before it only mattered if SELECT_STACK_ALLOC
was a multiple of six.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
diff --git a/fs/select.c b/fs/select.c
index 071660f..c46d40c 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -311,7 +311,8 @@ static int core_sys_select(int n, fd_set
{
fd_set_bits fds;
char *bits;
- int ret, size, max_fdset;
+ int ret, max_fdset;
+ unsigned int size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -335,8 +336,8 @@ static int core_sys_select(int n, fd_set
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
- if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ if (size <= sizeof(stack_fds) / 6)
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +374,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
^ permalink raw reply related
* Re: [patch] avoid unaligned access when accessing poll stack
From: Mitchell Blank Jr @ 2006-04-01 3:39 UTC (permalink / raw)
To: Jes Sorensen
Cc: Andi Kleen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <20060401023538.GB3157@gaz.sfgoth.com>
Here's a slightly updated version of my patch: it changes the
if (size < sizeof(stack_fds) / 6)
to:
if (size <= sizeof(stack_fds) / 6)
Otherwise this is exactly the same as the version I just posted. The old
code had this problem too but before it only mattered if SELECT_STACK_ALLOC
was a multiple of six.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
diff --git a/fs/select.c b/fs/select.c
index 071660f..c46d40c 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -311,7 +311,8 @@ static int core_sys_select(int n, fd_set
{
fd_set_bits fds;
char *bits;
- int ret, size, max_fdset;
+ int ret, max_fdset;
+ unsigned int size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -335,8 +336,8 @@ static int core_sys_select(int n, fd_set
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
- if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ if (size <= sizeof(stack_fds) / 6)
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +374,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
^ permalink raw reply related
* Re: Moving to BK
From: Alexander Litvinov @ 2006-04-01 3:17 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
> April 1st is upon us again.
Damn, I have forgot about this. Good joke !
^ permalink raw reply
* Re: Moving to BK
From: David S. Miller @ 2006-04-01 3:14 UTC (permalink / raw)
To: pasky, junio; +Cc: linux-kernel, git
In-Reply-To: <200604010311.k313BYeS026266@hera.kernel.org>
April 1st is upon us again.
^ permalink raw reply
* Moving to BK
From: Petr Baudis, Junio C Hamano @ 2006-04-01 0:00 UTC (permalink / raw)
To: linux-kernel; +Cc: git
We are pleased to announce that both of us will be working for
BitMover Inc., starting this month.
Petr, the author of the popular Cogito front-end for git, will
be modifying Cogito so that it natively works on BK
repositories. The superior Cogito user interface will
extensively increase added business value of BK by enabling a
variety of innovative workflows for smooth and economical
developer cooperation.
Junio, the current maintainer of git "stupid content tracker",
will first be working on a gateway to import development
histories stored in git into BK. This move adds value to BK by
freeing the data so far locked in git repositories and making
them available to the BK users. He may later work on
reimplementing some parts of the git for BK, but it is expected
that there aren't that many. For example, the "rename
detection" part is not necessary -- BK natively supports rename
tracking, which is a far superiour approach.
There currently is no plan for either of us to be working on the
conversion from BK to git. There is no technical reason to do
so, and it does not make business sense for BitMover Inc.
either.
- 30 -
^ permalink raw reply
* Re: Default remote branch for local branch
From: Junio C Hamano @ 2006-04-01 3:05 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1143856098.3555.48.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> This is not a ready-to-use proposal, but I think my message can prompt
> useful changes in GIT or in the "porcelain".
>...
> I think it would be convenient to have git remember the remote branch
> for the given local branch. git should know that if HEAD points to
> "local-B", "git-fetch" should fetch from "remote-B", not from "origin".
I am in favor of the general direction this is going. Something
like this was mentioned on the list in the past twice (I think
Johannes was involved in the discussion but I do not remember
the details offhand).
My understanding is that Cogito uses $GIT_DIR/branches/$name
file as a configuration file per branch - currently it only
records which remote repository's what remote branch the local
branch $name interfaces with.
The $GIT_DIR/remotes/$name file is to describe each remote
repository, and it _wants_ to be able to describe all the
branches we are interested in, primarily because uploading and
downloading multiple, related heads at once is more efficient.
How remote branches are kept track of with the local tracking
branch, and how remote branches are updated from the local
branch heads, are described by Push/Pull lines there.
As you pointed out, we do not have a convenient way to tell git
where you typically merge things from per local branch. There
are different patterns I've seen:
- Promiscous. For example, "master" branch of Linus repository
pulls from many subsystem maintainers. Linus could have one
"remotes" file per subsystem maintainer he often pulls from
(and "for-linus" branch name in each remote repository tends
to stay the same), and unlike the rest of us he does not seem
to pull into many local branches. The current "remotes"
setup is really optimized for this mode of usage (you can use
"remotes" without having local tracking branches).
- Merging topic branches into "master" (or "release") branch
and "next" (or "testing") branch -- inside local repository.
- CVS-like remote tracking. A single "primary" remote branch
is tracked using local "origin", merged into local "master"
and pushed back to the remote. Both Cogito-like branches/
setup and having a single $GIT_DIR/remotes/origin file with
single Push/Pull line would work equally well.
- Multiple subsystem maintainer trees tracked in the same local
repository. Most generally, two local branches per each
remote head can be used (one tracking branch to fetch into,
another to build your changes based on it). Alternatively,
you can use one local branch per each remote head without
using any tracking branch.
Your proposal to give default branch to pull from per the local
branch would help only the last case. The first one you do not
switch between local branches at all and pull from many
different places; the second is to merge from different topic
branches from time to time and does not benefit from fixed
configuration; the third does not even need configuration.
Maybe you would want something like this.
In $GIT_DIR/config:
[pull]
origin = linus for master
origin = irq-pio of libata for ata-irq-pio
origin = pata-drivers of libata for ata-pata
In $GIT_DIR/remotes/linus:
URL: git://git.kernel.org/.../torvalds/linux-2.6.git
Pull: refs/heads/master:refs/heads/linus
In $GIT_DIR/remotes/libata
URL: git://git.kernel.org/.../jgarzik/libata-dev.git
Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
Pull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers
This is to maintain three local branches: master, ata-irq-pio
and ata-pata.
You are obviously interested in the mainline Linus kernel, so
while you are on your "master" branch, we will look for
"pull.origin .* for master" and find out you would want
remotes/linus file to be used. His "master" is copied to your
local "linus" branch, and merged into your "master" branch.
$ git pull
becomes equivalent to:
$ git pull linus
You are also interested in the libata work by Jeff, and while
you are on your ata-pata branch
$ git pull
becomes roughly equivalent to:
$ git pull libata pata-drivers
While we are on the topic, it _might_ be worthwhile to think
about revamping the syntax of $GIT_DIR/remotes file, maybe even
breaking backward compatibility. The Pull: lines can be
independently specified which gives flexibility, but I suspect
local tracking branches from the same remote tend to live in the
same place; IOW, you would probably not do something like:
URL: git://git.kernel.org/.../jgarzik/libata-dev.git
Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
in practice.
^ permalink raw reply
* [PATCH] mdadm 2.4: fix write mostly for add and re-add
From: Paul Clements @ 2006-04-01 3:02 UTC (permalink / raw)
To: neilb; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 182 bytes --]
The following patch makes it possible to tag a device as write-mostly on
--add and --re-add with a non-persistent superblock array. Previously,
this was not working.
Thanks,
Paul
[-- Attachment #2: mdadm-2.4-fix-write-mostly.diff --]
[-- Type: text/plain, Size: 563 bytes --]
Signed-Off-By: Paul Clements <paul.clements@steeleye.com>
Manage.c | 2 ++
1 files changed, 2 insertions(+)
--- mdadm-2.4/Manage.c 2006-03-28 01:11:11.000000000 -0500
+++ mdadm-2.4-fix-write-mostly/Manage.c 2006-03-31 21:56:37.000000000 -0500
@@ -341,6 +341,8 @@ int Manage_subdevs(char *devname, int fd
break;
}
}
+ if (dv->writemostly)
+ disc.state |= (1 << MD_DISK_WRITEMOSTLY);
if (ioctl(fd,ADD_NEW_DISK, &disc)) {
fprintf(stderr, Name ": add new device failed for %s as %d: %s\n",
dv->devname, j, strerror(errno));
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Nick Piggin @ 2006-04-01 2:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: Zoltan Menyhart, Boehm, Hans, Grundler, Grant G, Chen, Kenneth W,
akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603310939570.6628@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Nick Piggin wrote:
>>You acknowledge that you have to fix ia64 to match current semantics
>>first, right?
>
>
> Right. I believe I have done so by making both smb_mb_* full barriers.
All bitop and atomic test_and_set, inc_return, etc etc (ie. everything
that modifies the operand and returns something) needs to be a full
barrier before and after too.
>>Now people seem to be worried about the performance impact that will
>>have, so I simply suggest that adding two or three new macros for the
>>important cases to give you a 90% solution.
>
>
> We could transition some key locations of core code to use _mode bitops
> if there are performance problems.
>
>
>>I think Documentation/atomic_ops.txt isn't bad. smp_mb__* really
>>is a smp_mb, which can be optimised sometimes.
>
>
> Ok. Then we are on the same page and the solution I presented may be
> acceptable. I have a new rev here that changes the naming a bit but I
> think we are okay right?
Not sure, to be honest. I think it is probably something which needs
input from all the other arch people, and Linus, if you intend to use
it to introduce new types of barriers.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: Synchronizing Bit operations V2
From: Nick Piggin @ 2006-04-01 2:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: Zoltan Menyhart, Boehm, Hans, Grundler, Grant G, Chen, Kenneth W,
akpm, linux-kernel, linux-ia64
In-Reply-To: <Pine.LNX.4.64.0603310939570.6628@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Fri, 31 Mar 2006, Nick Piggin wrote:
>>You acknowledge that you have to fix ia64 to match current semantics
>>first, right?
>
>
> Right. I believe I have done so by making both smb_mb_* full barriers.
All bitop and atomic test_and_set, inc_return, etc etc (ie. everything
that modifies the operand and returns something) needs to be a full
barrier before and after too.
>>Now people seem to be worried about the performance impact that will
>>have, so I simply suggest that adding two or three new macros for the
>>important cases to give you a 90% solution.
>
>
> We could transition some key locations of core code to use _mode bitops
> if there are performance problems.
>
>
>>I think Documentation/atomic_ops.txt isn't bad. smp_mb__* really
>>is a smp_mb, which can be optimised sometimes.
>
>
> Ok. Then we are on the same page and the solution I presented may be
> acceptable. I have a new rev here that changes the naming a bit but I
> think we are okay right?
Not sure, to be honest. I think it is probably something which needs
input from all the other arch people, and Linus, if you intend to use
it to introduce new types of barriers.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [RESEND][2.6.15] New ATA error messages on upgrade to 2.6.15
From: Kyle Moffett @ 2006-04-01 2:54 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel
In-Reply-To: <442DD58B.7070801@shaw.ca>
On Mar 31, 2006, at 20:21:15, Robert Hancock wrote:
> Kyle Moffett wrote:
>> hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hdg: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> Hmm, are these new? Sure you don't have a bad IDE cable?
Oh, those aren't the errors I'm worried about; I've had those for a
while and they're harmless. Those are due to the kernel running the
IDE controller at a higher-than-supported speed. It gets errors for
a couple seconds and automatically drops the bus down to a lower and
safer speed. The cable's aren't bad, I've tried at least 6 different
80-conductor cables that all work fine in other systems. The errors
I _am_ worried about are these:
> Mar 28 03:15:13 penelope kernel: hdi: status timeout: status=0xd0
> { Busy }
> Mar 28 03:15:13 penelope kernel: PDC202XX: Secondary channel reset.
> Mar 28 03:15:13 penelope kernel: hdi: no DRQ after issuing
> MULTWRITE_EXT
> Mar 28 03:15:13 penelope kernel: ide4: reset: success
> Mar 28 03:30:13 penelope kernel: hdi: status timeout: status=0xd0
> { Busy }
> Mar 28 03:30:13 penelope kernel: PDC202XX: Secondary channel reset.
> Mar 28 03:30:13 penelope kernel: hdi: no DRQ after issuing
> MULTWRITE_EXT
> Mar 28 03:30:13 penelope kernel: ide4: reset: success
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [RFC] sched.c : procfs tunables
From: Mike Galbraith @ 2006-04-01 2:49 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-smp
In-Reply-To: <200603311723.49049.a1426z@gawab.com>
On Fri, 2006-03-31 at 17:23 +0300, Al Boldi wrote:
> Proper scheduling in a multi-tasking environment is critical to the success
> of a desktop OS. Linux, being mainly a server OS, is currently tuned to
> scheduling defaults that may be appropriate only for the server scenario.
>
> To enable Linux to play an effective role on the desktop, a more flexible
> approach is necessary. An approach that would allow the end-User the
> freedom to adjust the OS to the specific environment at hand.
>
> So instead of forcing a one-size fits all approach on the end-User, would not
> exporting sched.c tunables to the procfs present a flexible approach to the
> scheduling dilemma?
Nope, not the existing tunables anyway. The full effect of even a tiny
scheduler knob tweak is hard to predict even if you've studied the code
carefully. These knobs are just not generic enough to be exposed IMHO.
-Mike
^ permalink raw reply
* Re: [patch] avoid unaligned access when accessing poll stack
From: Andi Kleen @ 2006-04-01 2:44 UTC (permalink / raw)
To: Mitchell Blank Jr
Cc: Jes Sorensen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <20060401023538.GB3157@gaz.sfgoth.com>
On Saturday 01 April 2006 04:35, Mitchell Blank Jr wrote:
> * I also changed "size" to be unsigned since that makes more sense and
> is less prone to overflow bugs. I'm also a little scared by the
> "kmalloc(6 * size)" since that type of call is a classic multiply-overflow
> security hole (hence libc's calloc() API). However "size" is constrained
> by fdt->max_fdset so I think it isn't exploitable. The kernel doesn't
> have an overflow-safe API for kmalloc'ing arrays, does it?
kcalloc. But it's slow since it memsets.
-Andi
^ permalink raw reply
* Re: [patch] avoid unaligned access when accessing poll stack
From: Andi Kleen @ 2006-04-01 2:44 UTC (permalink / raw)
To: Mitchell Blank Jr
Cc: Jes Sorensen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <20060401023538.GB3157@gaz.sfgoth.com>
On Saturday 01 April 2006 04:35, Mitchell Blank Jr wrote:
> * I also changed "size" to be unsigned since that makes more sense and
> is less prone to overflow bugs. I'm also a little scared by the
> "kmalloc(6 * size)" since that type of call is a classic multiply-overflow
> security hole (hence libc's calloc() API). However "size" is constrained
> by fdt->max_fdset so I think it isn't exploitable. The kernel doesn't
> have an overflow-safe API for kmalloc'ing arrays, does it?
kcalloc. But it's slow since it memsets.
-Andi
^ permalink raw reply
* Re: [patch] avoid unaligned access when accessing poll stack
From: Mitchell Blank Jr @ 2006-04-01 2:35 UTC (permalink / raw)
To: Jes Sorensen
Cc: Andi Kleen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <yq0odzmtwni.fsf@jaguar.mkp.net>
Jes Sorensen wrote:
> I assume you mean select().
>
> Updated patch attached.
This fixes a few problems introduced by this patch.
* Fixes two warnings caused by mixing "char *" and "long *" pointers
* If SELECT_STACK_ALLOC is not a multiple of sizeof(long) then stack_fds[]
would be less than SELECT_STACK_ALLOC bytes and could overflow later in
the function. Fixed by simply rearranging the test later to work on
sizeof(stack_fds)
Currently SELECT_STACK_ALLOC is 256 so this doesn't happen, but it's
nasty to have things like this hidden in the code. What if later
someone decides to change SELECT_STACK_ALLOC to 300?
* I also changed "size" to be unsigned since that makes more sense and
is less prone to overflow bugs. I'm also a little scared by the
"kmalloc(6 * size)" since that type of call is a classic multiply-overflow
security hole (hence libc's calloc() API). However "size" is constrained
by fdt->max_fdset so I think it isn't exploitable. The kernel doesn't
have an overflow-safe API for kmalloc'ing arrays, does it?
Patch is vs current git HEAD. Only compile/boot tested.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
diff --git a/fs/select.c b/fs/select.c
index 071660f..bd9c7db 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -311,7 +311,8 @@ static int core_sys_select(int n, fd_set
{
fd_set_bits fds;
char *bits;
- int ret, size, max_fdset;
+ int ret, max_fdset;
+ unsigned int size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -335,8 +336,8 @@ static int core_sys_select(int n, fd_set
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
- if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ if (size < sizeof(stack_fds) / 6)
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +374,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
^ permalink raw reply related
* Re: Avoid excessive time spend on concurrent slab shrinking
From: Nick Piggin @ 2006-04-01 2:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Lameter, linux-mm, Nathan Scott
In-Reply-To: <20060331172518.40a5b03d.akpm@osdl.org>
Andrew Morton wrote:
> c) go back to single-threading shrink_slab (or just shrink_icache_memory())
>
> For this one we'd need to understand which observations prompted Nick
> to make shrinker_rwsem an rwsem?
>
This was when I was looking for reasons why inode and dentry caches
would sometimes apparently explode on people and consume most of their
memory. One of the reasons was here, when slab caches did build up, and
multiple processes would start reclaim, scanning would skew away from
slab.
Considering the actual slab shrinkers are single threaded, I agree this
could cause more semaphore contention.
One thing we could do is ensure shrinker->nr gets incremented, but not
actually have more than one thread enter slab reclaim at once.
Or have the trylock&abort behaviour pushed down into the actual
shrinkers themselves, then at least we can get concurrent icache and
dcache scanning happening.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] avoid unaligned access when accessing poll stack
From: Mitchell Blank Jr @ 2006-04-01 2:35 UTC (permalink / raw)
To: Jes Sorensen
Cc: Andi Kleen, Linus Torvalds, Andrew Morton, linux-kernel,
linux-ia64
In-Reply-To: <yq0odzmtwni.fsf@jaguar.mkp.net>
Jes Sorensen wrote:
> I assume you mean select().
>
> Updated patch attached.
This fixes a few problems introduced by this patch.
* Fixes two warnings caused by mixing "char *" and "long *" pointers
* If SELECT_STACK_ALLOC is not a multiple of sizeof(long) then stack_fds[]
would be less than SELECT_STACK_ALLOC bytes and could overflow later in
the function. Fixed by simply rearranging the test later to work on
sizeof(stack_fds)
Currently SELECT_STACK_ALLOC is 256 so this doesn't happen, but it's
nasty to have things like this hidden in the code. What if later
someone decides to change SELECT_STACK_ALLOC to 300?
* I also changed "size" to be unsigned since that makes more sense and
is less prone to overflow bugs. I'm also a little scared by the
"kmalloc(6 * size)" since that type of call is a classic multiply-overflow
security hole (hence libc's calloc() API). However "size" is constrained
by fdt->max_fdset so I think it isn't exploitable. The kernel doesn't
have an overflow-safe API for kmalloc'ing arrays, does it?
Patch is vs current git HEAD. Only compile/boot tested.
Signed-off-by: Mitchell Blank Jr <mitch@sfgoth.com>
diff --git a/fs/select.c b/fs/select.c
index 071660f..bd9c7db 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -311,7 +311,8 @@ static int core_sys_select(int n, fd_set
{
fd_set_bits fds;
char *bits;
- int ret, size, max_fdset;
+ int ret, max_fdset;
+ unsigned int size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -335,8 +336,8 @@ static int core_sys_select(int n, fd_set
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
- if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ if (size < sizeof(stack_fds) / 6)
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +374,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
^ permalink raw reply related
* [ALSA - utils 0001990]: aplay/arecord cannot play/capture A_LAW
From: bugtrack @ 2006-04-01 2:26 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1990>
======================================================================
Reported By: Raymond
Assigned To:
======================================================================
Project: ALSA - utils
Issue ID: 1990
Category: aplay/arecord
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 04-01-2006 04:26 CEST
Last Modified: 04-01-2006 04:26 CEST
======================================================================
Summary: aplay/arecord cannot play/capture A_LAW
Description:
aplay/arecord can play MU_LAW and the sound card support MU_LAW and A_LAW
arecord -D hw:0,0 -f MU_LAW -t au -c 1 -r 8000 test.au
aplay -D hw:0,0 test.au
Try to use -t raw but the quality of A_LAW is very bad when compare with
MU_LAW
arecord -D hw:0,0 -f A_LAW -t raw -c 1 -r 8000 test.raw
aplay -D hw:0,0 test.raw
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-01-06 04:26 Raymond New Issue
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.