Re: [ofa-general] Re: Demand paging for memory regions
On Tue, 12 Feb 2008, Roland Dreier wrote: > I don't know anything about the T3 internals, but it's not clear that > you could do this without a new chip design in general. Lot's of RDMA > devices were designed expecting that when a packet arrives, the HW can > look up the bus address for a given memory region/offset and place the > packet immediately. It seems like a major change to be able to > generate a "page fault" interrupt when a page isn't present, or even > just wait to scatter some data until the host finishes updating page > tables when the HW needs the translation. Well if the VM wants to invalidate a page then the remote end first has to remove its mapping. If a page has been removed then the remote end would encounter a fault and then would have to wait for the local end to reestablish its mapping before proceeding. So the packet would only be generated when both ends are in sync. -- 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 1/4] mempolicy: convert MPOL constants to enum
On Tue, 12 Feb 2008, Paul Jackson wrote:
> I tend to agree with Lee on this one. If I recall correctly, Christoph
> said something similar, regarding the change of the 'policy' field
> of struct mempolicy from a short to an enum.
>
I've already made the change in my patchset as a result of Christoph's
comment.
> I'm inclined toward the original types for the 'policy' field.
>
> Also, rather than trying to pack the new flag, MPOL_F_STATIC_NODES,
> into the existing 'policy' field, I'd suggest instead adding a new
> field to 'struct mempolicy' for this flag. Since 'policy' is only a
> short, and since the next field in that struct, is a union that
> includes a pointer that is aligned on most arch's to at least a 4 byte
> boundary, therefore there is a hole of at least two bytes, following
> the short policy field, in which another short or some flag bits can be
> placed, with no increase in the size of struct mempolicy.
>
I disagree, that space can be reserved for future use that will perhaps be
much needed at that time.
The type 'short' is obviously overkill to hold the value of the policy
mode since we only have four currently defined modes. We'll never exceed
the capacity of type 'unsigned char' if mempolicies are going to remain
useful.
If the flag bits are going to be stored in the same member as the mode, it
is necessary to make the change, as I have, to be unsigned to avoid
sign-extension when this is promoted to 'int' that is required as part of
the API.
> Specifically, I'd suggest adding the one line for 'mode_f_static_nodes'
> as below, and leaving the code involving the encoding of the policy
> field alone.
>
> struct mempolicy {
> atomic_t refcnt;
> short policy; /* See MPOL_* above */
> int mode_f_static_nodes:1; /* <== Added line <== */
> union {
> struct zonelist *zonelist; /* bind */
> shortpreferred_node; /* preferred */
> nodemask_t nodes; /* interleave */
> /* undefined for default */
> } v;
> nodemask_t cpuset_mems_allowed; /* mempolicy relative to these nodes
> */
> };
>
> Single bit fields (The ":1" above) provide the simplest way to add
> boolean flags to structs. Let the compiler do the work of packing
> and unpacking the field.
>
> Then, rather than having to code double-negative explicit masking
> operations such as:
>
> remap = !(mpol_flags(pol->policy) & MPOL_F_STATIC_NODES);
> if (!remap)
> blah blah ...
>
> one can simply code:
>
> if (pol->mode_f_static_nodes)
> blah blah ...
>
The problem with your approach is that we need to pass the optional mode
flags back to the user through get_mempolicy() and the user needs to pass
them to us via set_mempolicy() or mbind(). So we'll still need the
#define in linux/mempolicy.h:
#define MPOL_F_STATIC_NODES (1 << MPOL_FLAG_SHIFT)
We could deal with this as follows:
if (mode & MPOL_F_STATIC_NODES)
pol->mode_f_static_nodes = 1;
but that doesn't make much sense.
Once Christoph's comment is taken into consideration and we start passing
around 'int policy' instead of 'enum mempolicy_mode mode' again, I don't
think anybody will struggle with doing:
if (mode & MPOL_F_STATIC_NODES)
to check for the prescence of a flag.
David
--
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: [ofa-general] Re: Demand paging for memory regions
On Tue, Feb 12, 2008 at 05:01:17PM -0800, Christoph Lameter wrote: > On Tue, 12 Feb 2008, Jason Gunthorpe wrote: > > > Well, certainly today the memfree IB devices store the page tables in > > host memory so they are already designed to hang onto packets during > > the page lookup over PCIE, adding in faulting makes this time > > larger. > > You really do not need a page table to use it. What needs to be maintained > is knowledge on both side about what pages are currently shared across > RDMA. If the VM decides to reclaim a page then the notification is used to > remove the remote entry. If the remote side then tries to access the page > again then the page fault on the remote side will stall until the local > page has been brought back. RDMA can proceed after both sides again agree > on that page now being sharable. The problem is that the existing wire protocols do not have a provision for doing an 'are you ready' or 'I am not ready' exchange and they are not designed to store page tables on both sides as you propose. The remote side can send RDMA WRITE traffic at any time after the RDMA region is established. The local side must be able to handle it. There is no way to signal that a page is not ready and the remote should not send. This means the only possible implementation is to stall/discard at the local adaptor when a RDMA WRITE is recieved for a page that has been reclaimed. This is what leads to deadlock/poor performance.. Jason -- 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 4/4] hlist_for_each_entry_continue simplification
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:50:46 -0800 > All the users of hlist_for_each_entry_continue had to intialize pos > before use; change API so pos is a pure temporary variable which matches > the usage of other _for_each_entry routines. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> linux/list.h changes need to be reviewed on linux-kernel and merged into Linus's tree via some means other than the networking tree. I just got chewed out for a similar issue wrt. the rcupdate.h changes of yesterday and thus have to remove them from my tree. -- 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: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST) > The fact is, that "outlying code" is where we have all the bulk of the > code, and it's also where we have all those developers who aren't on the > "inside track". So we should help the outliers, not the core code. Good point. For the record I write drivers that use infrastructure too and have to deal with the API changes just as equally :-) -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Greg KH wrote: > > Perhaps you need to switch to using quilt. This is the main reason why > I use it. Btw, on that note: if some quilt user can send an "annotated history file" of their quilt usage, it's something that git really can do, and I'll see if I can merge (or rather, coax Junio to merge) the relevant part of stgit to make it possible to just basically get "quilt behaviour" for the parts of a git tree that you haven't pushed out yet. A pure patch-stack will be faster at that thing than git would be (it's simply easier to just track patches), but on the other hand, using git would get some other advantages outside of the integration issue (eg the cherry-pick thing really is a proper three-way merge, not just an "apply patch", so it can do better). It wasn't the original goal of git, but not only are really doing all the series management anyway (that is largely what "rebase" is all about, after all), but the git goals have obviously expanded over time too. Linus -- 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: currently active Linux kernel versions
On Tue, Feb 12, 2008 at 11:37:14PM +0100, Tomasz Chmielewski wrote: > Wagner Ferenc wrote: > > >which are the "currently active Linux kernel versions" at any point in > >time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > >Or more precisely: which are the "stable" versions I can depend on for > >a more or less critical server, those that have active security > >support or receive at least critical bugfixes? I know about the > >2.6.2[34].y stable git trees, but I wonder how long will those receive > >attention (that is, security fixes). Can I find a written policy > >somewhere? > > I would say: > > a) the kernel your distro provides, OK for this one > b) if you're not using a kernel provided by your distribution, the > newest kernel from kernel.org Hummm... he said "a more or less critical server, those that have active security support or receive at least critical bugfixes". So he does not want surprizes :-) > (there are some older, still maintaned kernels with security fixes, too). I would suggest stable - N-1 for most usages. 2.6.24.y is open, 2.6.23.y is supposed to be good. The advantage when you proceed like this is that you can jump from an older kernel to a more recent one which has already got its share of fixes and is still maintained for some time. Generally, I would trust Greg when he drops an old kernel, it means that he's confident enough in the next one. Willy -- 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: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 12:07:07 -0800 (PST) > > > On Tue, 12 Feb 2008, J. Bruce Fields wrote: > > > > But the "author" is still preserved, right? Why do you need the > > committer name to be preserved? (I'm not denying that there could be > > reasons, I'm just curious what they are.) > > It's not that the committer should be preserved, but: > > - the chain from author -> committer should be visible in the >Signed-off-by: lines. > >If you rebase somebody elses tree, you screw that up. You need to add >your sign-off, since now *you* are the new committer, and *you* took >somebody elses work! I agree with this and that is exactly what I screwed up by mistake this time around. Normally when I rebase I walk through the patches that came from other people's trees and add signoffs as needed. I understand that this is frowned upon to some extent as well. > Put another way: think of the absolute *chaos* that would happen if I were > to rebase instead of just merging. Every time I pull from you I'd > invalidate your whole tree, and you'd have to re-generate. It gets > unmaintainable very quickly. I actually wouldn't mind that, the first thing I do when sending a pull request is I stop putting things into my tree and as soon as the recipient pulls I wipe out my tree and clone a fresh copy of their's. It's really not a big deal. The pusher can queue patches and other stuff up in their mailbox or in a directory somewhere. This quiet period also allows those patches to have some time to be reviewed on the lists before they actually end up in anyone's tree. I really like that mode of operation. -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> Here are some odd-the-cuff
> suggestions:
>
> 1) Make feature-removal-schedule a directory with files in it.
>Everyone touches that file, creating merge issues.
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
>instead have each "thing" have it's own Kconfig.foo or
>Makefile.foo that gets automatically sucked into the main
>directory Makefile or Kconfig using file globs or similar.
>
>Even better, encode the building of things into the *.[ch]
>files themselves, and have the Kconfig/Makefile machinery
>automatically extract this information when you build.
3) teach people that you don't always have to add new includes right
at the end of the list
4) teach people that you don't have to add Makefile rules right at the
end of the list
5) ditto feature-removal
6) ditto lots of other things.
My usual way of fixing these things when they pop up is to just move the
offending addition to some random position other than end-of-list. I must
have done this hundreds of times and as yet I don't think anyone has noticed ;)
--
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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Andrew Morton wrote: > > So it would not be efficient for David to do all this queue-cleaning > *prior* to putting the tree into linux-next, because more stuff will pop up > anyway. Well, what others have done is to have special "temporary branches". This is what git itself does, for example. The "pu" branch in git is used for experimental stuff, and it's _declared_ to be rebased, redone, and generally just unsafe at any moment. So it is easy to have a special "testing" branch that is just declared to be unsafe. Make Linux-next pull that testing branch - it will pollute the Linux-next tree (and anybody else who just wants to see what the current state is), but since those are re-generatd from scratch every day _anyway_, so who cares? But don't make it something people pull by mistake (ie never call it "master", and when mentioning it in some email message, always mention the fact that it's not a stable branch, and never ask anybody to pull it without making it very clear that it's just for testing, not for real merging). So git does have support for those things. They are very much "secondary" branches (any tree they are pulled into will itself become "poisoned" and unstable), but it's easy enough to have something like that for testing purposes. And if it all tests out fine, you can just move it as-is into the "real" branch if you want to. Linus -- 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: [ofa-general] Re: Demand paging for memory regions
On Tue, 12 Feb 2008, Christian Bell wrote: > I think there are very potential clients of the interface when an > optimistic approach is used. Part of the trick, however, has to do > with being able to re-start transfers instead of buffering the data > or making guarantees about delivery that could cause deadlock (as was > alluded to earlier in this thread). InfiniBand is constrained in > this regard since it requires message-ordering between endpoints (or > queue pairs). One could argue that this is still possible with IB, > at the cost of throwing more packets away when a referenced page is > not in memory. With this approach, the worse case demand paging > scenario is met when the active working set of referenced pages is > larger than the amount physical memory -- but HPC applications are > already bound by this anyway. > > You'll find that Quadrics has the most experience in this area and > that their entire architecture is adapted to being optimistic about > demand paging in RDMA transfers -- they've been maintaining a patchset > to do this for years. The notifier patchset that we are discussing here was mostly inspired by their work. There is no need to restart transfers that you have never started in the first place. The remote side would never start a transfer if the page reference has been torn down. In order to start the transfer a fault handler on the remote side would have to setup the association between the memory on both ends again. -- 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: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST) > Btw, on that note: if some quilt user can send an "annotated history file" > of their quilt usage, it's something that git really can do, and I'll see > if I can merge (or rather, coax Junio to merge) the relevant part of stgit > to make it possible to just basically get "quilt behaviour" for the parts > of a git tree that you haven't pushed out yet. Sounds interesting and nice, but not relevant for my current workflow. I've always "already pushed out". -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > At 1500 changesets, a merge conflict shows up about once > every day or two as 2.6.N nears it's release into final > as bug fixes trickle in. > > I find using GIT to fixup merge errors on a tree of that > scale to be really painful. And it only fixes up the final > result in a merge changeset. Heh. I've had the reverse situation: "git rebase" often results in *more* conflicts than "git merge" (ie "pull"). But one issue is also that when conflicts happen, different people are used to different things. I'm particularly used to merge-type conflicts, and in fact there's some fairly advanced support in git for helping resolve them that people who *don't* do merge-level conflict resolution may not even be aware of. In particular, if you want to try it, do something that conflicts and then do gitk --merge to see what the conflict is all about. That is just fancy shorthand for gitk HEAD...MERGE_HEAD -- so what it does is to show only the relevant history (the three dots means that it's a _symmetric_ set difference from HEAD to MERGE_HEAD) for the merge, and only for the particular files that had conflicts! This often means that even when you merge a thousand commits (or the thing you merge *into* has thousands of commits since the merge base, which is the common case for me), you actually only see a couple of commits - only the ones that actually modified the conflicting files! (If you have many files that conflict, you can further narrow it down to just one at a time by explicitly listing the file/directory you want to work on, ie do "gitk --merge "). > Let me give you a good example, just yesterday I had to rebase > my net-2.6 tree a few times. It's because I put a patch in there > that the person said was OK but it broke the build. There is > zero reason for me to push that tree to Linus with the bad > commit and the revert, it's just noise and makes the tree harder > for people to review. Actually, better than rebase in that situation is to just remove the bad commit. Yes, you'd use "rebase" for it, but you'd use it not to move the whole series to a newer place, you'd use it just to rebase the commits *after* the commit you remove. This is something where I actually think git could and should do better: git has the capability to act as more of a "quilt replacement", but because it wasn't part of the original design, we never actualy exposed the simple queue management commands to do this (stgit does things like that, though). So if you haven't pushed out, right now you'd have to do this stupid thing: [ start (and activate) a 'fixup' branch at X ] git checkout -b fixup X [ edit edit edit to fix it up ] .. [ commit the fixed state ] git commit --amend [ go back to the old broken state ] git checkout master [ now, rebase 'master' on top of the fix ] git rebase fixup [ ok, done, forget the fixup branch ] git branch -d fixup and I don't discourage this kind of behaviour at all, but it is only good iff: - you have not pushed things out (obviously), so nobody ever even notices that you've fixed up stuff - you haven't pulled anything from outside (so you aren't trying to rebase other peoples commits). If you *really* want to try to do this even across merges you've done, there is fancy a "--preserve-merges" thing that you can try to use (needs "-i" to work, but "-i" is often cool for other reasons too!) Basically, what I'm trying to say is that "git rebase" can be used in fancy ways to do things that people outside your repository will never even *know* were done. It's only when outsiders can see the effects of git rebase that you're in trouble! Linus -- 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: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:47:26 -0800 > My usual way of fixing these things when they pop up is to just move > the offending addition to some random position other than > end-of-list. I must have done this hundreds of times and as yet I > don't think anyone has noticed ;) That sounds like a real useful usage of your time. I think my proposal saves everyone, including you, this time and the effort necessary to implement it would only need to be expended once instead of this ever present time and learning sink you seem to be advocating. -- 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: BTRFS partition usage...
On 13-02-08 00:42, Jan Engelhardt wrote: x86 MSDOS partition table layout starts counting with sector 1, which is (not so intuitively) starting at 0x7e00 (and there's no sector 0, probably for safety). Well, each ptable format with its own quirks. I haven't followed this thread, but in case it matters -- this sounds fairly confused. Not sure what you're saying, but the MSDOS partition table has its root table in the very first sector on the disk, at offset 0x1be = 0x200 - 4 * sizeof(struct partition) - 2 (that is, 4 entries at the end of that first sector, followed by a 2-byte signature). That 0x7e00 that you are speaking of sounds somewhat like the _memory_ address the BIOS loads that first sector to: 0x7c00. It then jumps there to start the ball rolling but 0x7c00 is not an on-disk reality or anything. MS-DOS partition tables are furthermore fully outside the actual partitions themselves and as such I believe not all together relevant to the issue? (as said, not following along though...) Rene -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 15:58:53 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > But right now I have to redo the include/linux/rcupdate.h that's in > there because it has a bug. Well there's a case in point. rcupdate.h is not a part of networking, and it is random tree-wandering like this which causes me problems and which will cause Stephen problems. Now, I don't know which tree "owns" rcupdate.h but it ain't networking. Probably git-sched. Nothing in networking depends upon that change (which has a typo in the comment, btw) hence it can and should have gone through whichever-tree-owns-that-file. For Stephen's sake: please. -- 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] infiniband: be*_add_cpu conversion
neat. applied... -- 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 1/4] mempolicy: convert MPOL constants to enum
Lee wrote:
> Why not leave it as an int. Will simplify this and subsequent patch.
I tend to agree with Lee on this one. If I recall correctly, Christoph
said something similar, regarding the change of the 'policy' field
of struct mempolicy from a short to an enum.
I'm inclined toward the original types for the 'policy' field.
Also, rather than trying to pack the new flag, MPOL_F_STATIC_NODES,
into the existing 'policy' field, I'd suggest instead adding a new
field to 'struct mempolicy' for this flag. Since 'policy' is only a
short, and since the next field in that struct, is a union that
includes a pointer that is aligned on most arch's to at least a 4 byte
boundary, therefore there is a hole of at least two bytes, following
the short policy field, in which another short or some flag bits can be
placed, with no increase in the size of struct mempolicy.
Specifically, I'd suggest adding the one line for 'mode_f_static_nodes'
as below, and leaving the code involving the encoding of the policy
field alone.
struct mempolicy {
atomic_t refcnt;
short policy; /* See MPOL_* above */
int mode_f_static_nodes:1; /* <== Added line <== */
union {
struct zonelist *zonelist; /* bind */
shortpreferred_node; /* preferred */
nodemask_t nodes; /* interleave */
/* undefined for default */
} v;
nodemask_t cpuset_mems_allowed; /* mempolicy relative to these nodes */
};
Single bit fields (The ":1" above) provide the simplest way to add
boolean flags to structs. Let the compiler do the work of packing
and unpacking the field.
Then, rather than having to code double-negative explicit masking
operations such as:
remap = !(mpol_flags(pol->policy) & MPOL_F_STATIC_NODES);
if (!remap)
blah blah ...
one can simply code:
if (pol->mode_f_static_nodes)
blah blah ...
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
--
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: currently active Linux kernel versions
On Tue, Feb 12, 2008 at 04:37:54PM -0500, Mike Snitzer wrote: > On Feb 12, 2008 4:18 PM, Ferenc Wagner <[EMAIL PROTECTED]> wrote: > > Xavier Bestel <[EMAIL PROTECTED]> writes: > > > > > On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > > > > > >> which are the "currently active Linux kernel versions" at any point in > > >> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > > >> Or more precisely: which are the "stable" versions I can depend on for > > >> a more or less critical server, those that have active security > > >> support or receive at least critical bugfixes? I know about the > > >> 2.6.2[34].y stable git trees, but I wonder how long will those receive > > >> attention (that is, security fixes). Can I find a written policy > > >> somewhere? > > > > > > The answer is at http://kernel.org/ > > > > Not quite, at least I can't find 2.6.23.y there, even though that > > branch seems to be maintained... > > 2.6.16.x is still maintained (2.6.16.60 was recently released). > > 2.6.22.x is still maintained but Greg KH is apparently going to be > ending his duties on it after the next release or so. There is some > confusion as to whether Willy Tarreau will be taking on the 2.6.22.x > tree once Greg is done, Willy?: > http://lwn.net/Articles/268003/ > http://kerneltrap.org/Linux/Stable_2.6_Branches Huh? I never said that! Maybe I did not explain myself well, but that was not what I was saying. I was simply saying that the good news about Greg keeping 2.6.22.y open was that I'd throw my 2.6.20.y away and rely on his tree instead. I'm not really sure there's a need for 2.6.22 for a longer time. I did that for 2.6.20 because .21 was crappy, people did not want to jump to the fresh new 2.6.22 and it was unfair to expect Greg to maintain 3 versions in parallel, it's already cool to have two of them. 2.6.23.y looks very good to me, so I don't see what particular reason people would have not to switch right now. But if there is a very good reason (not motivated by unfixed regressions) and *if* it does not take me too many hours a week, I'm not against this idea since I'm still using 2.6.22 on some machines right now. But don't expect too many releases though. > 2.6.23.x and 2.6.24.x are obviously quite active for [EMAIL PROTECTED] Regards, Willy -- 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] FLAT binaries: drop BINFMT_FLAT bad header magic warning
Mike Frysinger wrote:
The warning issued by fs/binfmt_flat.c when the format handler is given a
non-FLAT and non-script executable is annoying to say the least when working
with FDPIC ELF objects. If you build a kernel that supports both FLAT and
FDPIC ELFs on no-mmu, every time you execute an FDPIC ELF, the kernel spits
out this message. While I understand a lot of newcomers to the no-mmu world
screw up generation of FLAT binaries, this warning is not usable for systems
that support more than just FLAT.
I don't have a problem with this.
Acked-by: Greg Ungerer <[EMAIL PROTECTED]>
Signed-off-by: Jie Zhang <[EMAIL PROTECTED]>
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
CC: Bernd Schmidt <[EMAIL PROTECTED]>
CC: Greg Ungerer <[EMAIL PROTECTED]>
---
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index d8a02f1..0498b18 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -443,12 +443,12 @@ static int load_flat_file(struct linux_binprm * bprm,
if (strncmp(hdr->magic, "bFLT", 4)) {
/*
+* Previously, here was a printk to tell people
+* "BINFMT_FLAT: bad header magic".
+* But for the kernel which also use ELF FD-PIC format, this
+* error message is confusing.
* because a lot of people do not manage to produce good
-* flat binaries, we leave this printk to help them realise
-* the problem. We only print the error if its not a script
file
*/
- if (strncmp(hdr->magic, "#!", 2))
- printk("BINFMT_FLAT: bad header magic\n");
ret = -ENOEXEC;
goto err;
}
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
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/
pci_get_device_reverse(), why does Calgary need this?
On Tue, Feb 12, 2008 at 04:15:06PM -0800, Greg KH wrote: > Hi, > > I'm reworking the pci device list logic (we currently keep all PCI > devices in 2 lists, which isn't the nicest, we should be able to get > away with only 1 list.) > > The only bother I've found so far is the pci_get_device_reverse() > function, it's used in 2 places, IDE and the calgary driver. Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? thanks, greg k-h -- 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/
"ide=reverse" do we still need this?
Hi, I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called "pci=reverse" and no one else seems to miss it. Any thoughts? thanks, greg k-h -- 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 1/4] mempolicy: convert MPOL constants to enum
On Tue, 12 Feb 2008, Paul Jackson wrote:
> I'm inclined toward the original types for the 'policy' field.
Good. And remove the enum.
> Specifically, I'd suggest adding the one line for 'mode_f_static_nodes'
> as below, and leaving the code involving the encoding of the policy
> field alone.
>
> struct mempolicy {
> atomic_t refcnt;
> short policy; /* See MPOL_* above */
> int mode_f_static_nodes:1; /* <== Added line <== */
It would be better to add some sort of flags field?
> Single bit fields (The ":1" above) provide the simplest way to add
> boolean flags to structs. Let the compiler do the work of packing
> and unpacking the field.
We usually do that with unsigned XXX and constants. You may want to check
multiple flags at once or do other fancy things.
--
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: BTRFS partition usage...
David Miller wrote: From: Chris Mason <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 09:08:59 -0500 I've had requests to move the super down to 64k to make room for bootloaders, which may not matter for sparc, but I don't really plan on different locations for different arches. The Sun disk label sits in the first 512 bytes and the boot loader block sits in the second 512 bytes. I think leaving even more space is a good idea for several reasons. Yep. I chose 32K unused space in the prototype filesystem I wrote [1, 2.4 era]. I'm pretty sure I got that number from some other filesystem, maybe even some NTFS incarnation. It's just good practice to avoid the first and last "chunks" of a partition, FSVO chunk. Jeff [1] http://kernel.org/pub/linux/kernel/people/jgarzik/ibu/ -- 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: Latest kernel doesn't boot
On Sat, 2008-02-09 at 19:39 +0100, Thomas Meyer wrote: > H. Peter Anvin schrieb: > > Thomas Meyer wrote: > >> H. Peter Anvin schrieb: > >>> Thomas Meyer wrote: > > I can not revert the commit > e429795c68d3001ecae74f6465420c9f043b0ece. it gave me errors. > but i'm also not sure what could be wrong with this commit! > > my first idea was that the commit > "[2215e69d2cf5024647f9a034807990590d25dd4e] x86 boot: use E820 > memory map on EFI 32 platform" is the offender, because the macbook > pro doesn't provide a e820 memory map at all. but bisect showed > that i'm wrong here?! > > >>> > >>> ELILO is expected to convert the memory map from EFI to e820 format. > >> I'm using elilo-3.6-ia32.efi provided at the elilo homepage. i > >> wasn't able to create a working efi toolchain :-( > >> Does elilo-3.6 already do the converting of the memory map, or not? > > > > Don't know. > 3.6 doesn't do the mapping in ia32/system.c create_boot_params(). > 3.8 does. > > The problem is, that i wasn't able to produce a working elilo.efi files > with my gentoo toolchain. the files elilo-3.8.efi provided by the elilo > project also doesn't work (gives a load error from the efi runtime). > > So i guess i'm stuck here. Can you attach the error message with elilo 3.8? > It should be noted somewhere that with Huangs patches, elilo version 3.8 > is needed. Yes. I will add this. Best Regards, Huang Ying -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 17:57:19 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > - and you actually can help fix your issues by doing some simple things >*before* pushing out, rather than push out immediately. IOW, do your >whitespace sanity fixes, your compile checks etc early, and don't push >out until after you've done them. > One of the things which linux-next could/should do is to help weed out the silly build breaks, typos, missing documentation updates, missed checkpatch opportunities, etc, etc. As well as real bugs. So it would not be efficient for David to do all this queue-cleaning *prior* to putting the tree into linux-next, because more stuff will pop up anyway. So perhaps a better workflow would be keep the linux-next trees all messy, and then each developer can consolidate, rebase, join and drop things prior to sending their individual trees to Linus. If so, then git could perhaps help, by retaining sufficient metadata for the maintainer to track the fact that this-patch-here fixes that-patch-there. -- 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/
[PATCH 1/4] rcu_assign_pointer: null check fix
Goofed on last change, should avoid barrier only on rcu_assign_pointer(p, NULL)
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
include/linux/rcupdate.h | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
--- a/include/linux/rcupdate.h 2008-02-12 14:46:49.0 -0800
+++ b/include/linux/rcupdate.h 2008-02-12 14:56:17.0 -0800
@@ -178,7 +178,7 @@ struct rcu_head {
#define rcu_assign_pointer(p, v) \
({ \
- if (!(__builtin_constant_p(v) && v))\
+ if (!__builtin_constant_p(v) || v) \
smp_wmb(); \
(p) = (v); \
})
--
Stephen Hemminger <[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: [ofa-general] Re: Demand paging for memory regions
On Tue, 12 Feb 2008, Jason Gunthorpe wrote: > Well, certainly today the memfree IB devices store the page tables in > host memory so they are already designed to hang onto packets during > the page lookup over PCIE, adding in faulting makes this time > larger. You really do not need a page table to use it. What needs to be maintained is knowledge on both side about what pages are currently shared across RDMA. If the VM decides to reclaim a page then the notification is used to remove the remote entry. If the remote side then tries to access the page again then the page fault on the remote side will stall until the local page has been brought back. RDMA can proceed after both sides again agree on that page now being sharable. -- 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 3/4] mempolicy: add MPOL_F_STATIC_NODES flag
On Tue, 12 Feb 2008, Lee Schermerhorn wrote:
> PATCH mempolicy - consolidate mpol_new() error paths
>
> Use common error path in mpol_new() for errors that we discover
> after allocation the new mempolicy structure. Free the mempolicy
> in the common error path.
>
> Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]>
>
> mm/mempolicy.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> Index: Linux/mm/mempolicy.c
> ===
> --- Linux.orig/mm/mempolicy.c 2008-02-12 15:18:12.0 -0700
> +++ Linux/mm/mempolicy.c 2008-02-12 15:22:07.0 -0700
> @@ -156,6 +156,7 @@ static struct mempolicy *mpol_new(enum m
> {
> struct mempolicy *policy;
> nodemask_t cpuset_context_nmask;
> + void *error_code = ERR_PTR(-EINVAL);
>
> pr_debug("setting mode %d flags %d nodes[0] %lx\n",
>mode, flags, nodes ? nodes_addr(*nodes)[0] : -1);
> @@ -172,8 +173,7 @@ static struct mempolicy *mpol_new(enum m
> switch (mode) {
> case MPOL_INTERLEAVE:
> if (nodes_empty(*nodes) || nodes_empty(cpuset_context_nmask)) {
> - kmem_cache_free(policy_cache, policy);
> - return ERR_PTR(-EINVAL);
> + goto free_mpol;
> }
> policy->v.nodes = cpuset_context_nmask;
> break;
You can also get rid of the parentheses to make checkpatch.pl happy, too.
> @@ -184,14 +184,12 @@ static struct mempolicy *mpol_new(enum m
> break;
> case MPOL_BIND:
> if (nodes_empty(*nodes)) {
> - kmem_cache_free(policy_cache, policy);
> - return ERR_PTR(-EINVAL);
> + goto free_mpol;
> }
> policy->v.zonelist = bind_zonelist(_context_nmask);
> if (IS_ERR(policy->v.zonelist)) {
> - void *error_code = policy->v.zonelist;
> - kmem_cache_free(policy_cache, policy);
> - return error_code;
> + error_code = policy->v.zonelist;
> + goto free_mpol;
> }
> break;
> default:
> @@ -201,6 +199,10 @@ static struct mempolicy *mpol_new(enum m
> policy->cpuset_mems_allowed = cpuset_mems_allowed(current);
> policy->user_nodemask = *nodes;
> return policy;
> +
> +free_mpol:
> + kmem_cache_free(policy_cache, policy);
> + return error_code;
> }
>
> static void gather_stats(struct page *, void *, int pte_dirty);
>
I'll fold this into my patchset when I repost it, thanks.
David
--
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: Documentation about sysfs/procfs entries
Hi all... Here's my idea: what if we collaborate to extend and make the kernel documentation better? I have done (slow) start by editing profile= kernel param. It's not accepted by Adrian Bunk, but at least I did it. Feedback? regards, Mulyadi. -- 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] sm501: Add uart support
On Fri, 08 Feb 2008 18:57:42 +0900 Magnus Damm <[EMAIL PROTECTED]> wrote: > smdev = kzalloc(sizeof(struct sm501_device) + > - sizeof(struct resource) * res_count, GFP_KERNEL); > + (sizeof(struct resource) * res_count) + > + platform_data_size, GFP_KERNEL); > > ... > > + smdev->pdev.resource = (struct resource *)(smdev+1); So this driver plays party tricks with memory allocation and the C type system. We could at least add struct resource resources[0]; to the end of `struct sm501_device' to avoid the type abuse. Or we could even get radical and splurge four bytes on a `struct resource *'. But please, not this. Oh well. A pre-existing problem. -- 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] ACPI suspend: Execute _WAK with the right argument
On Wed 2008-02-13 00:32:16, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The _WAK global ACPI control method has to be called with the
> argument representing the sleep state being exited. Make it happen.
>
> Special thanks to Mirco Tischler <[EMAIL PROTECTED]> for reporting the
> problem and debugging.
>
> Reported-by: Mirco Tischler <[EMAIL PROTECTED]>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK. AFAICT this is 2.6.25 material.
Pavel
> ---
> drivers/acpi/hardware/hwsleep.c |1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> ===
> --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> @@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
> return_ACPI_STATUS(status);
> }
>
> + arg.integer.value = sleep_state;
> status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: BTRFS partition usage...
On Feb 12 2008 15:38, David Miller wrote: > >> I still don't like the idea of btrfs trying to be smarter than a user >> who can partition up his system according to >> (a) his likes >> (b) system or hardware requirements or recommendations >> to align the superblock to a specific location. > >All of your beliefs are unfortunately without the understanding >of restrictions that exist in several partition layouts such >as the Sun disk label one. (Time for Sun to switch!) >You have to start the superblock somewhere other than zero or >else you lose a huge chunk of your disk, and furthermore a >zero based partition is what all of the Sun disk label >creating programs make by default. > >"I make a default disk label, I put btrfs or XFS on there, my disk > label is gone." > >Real intuitive. > x86 MSDOS partition table layout starts counting with sector 1, which is (not so intuitively) starting at 0x7e00 (and there's no sector 0, probably for safety). Well, each ptable format with its own quirks. -- 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/
[PATCH] spufs support multiple probes markers
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> >
> > fyi, I have this on hold because I spotted spufs build breakage,
> > but I haven't had time to investigate. powerpc allmodconfig, iirc.
>
> Christoph told me he would update his sputrace accordingly. Christoph,
> should I do the changes or let you do it ?
>
> It's mostly the probe function prototype which changes from
>
> -typedef void marker_probe_func(const struct marker *mdata,
> - void *private_data, const char *fmt, ...);
>
> to
>
> +typedef void marker_probe_func(void *probe_private, void *call_private,
> + const char *fmt, va_list *args);
>
> Where you receive an already ready va_list instead of having to call
> va_start/va_end in the probe.
>
> Also, there is no more marker_arm/marker_disarm. It is now automatically
> done upon register/unregister.
>
> Mathieu
>
Update spufs to the new linux kernel markers API, which supports connecting
more than one probe to a single marker.
(compile-tested only)
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
CC: "Frank Ch. Eigler" <[EMAIL PROTECTED]>
CC: Steven Rostedt <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/spufs/sputrace.c | 31 +--
1 file changed, 11 insertions(+), 20 deletions(-)
Index: linux-2.6-lttng/arch/powerpc/platforms/cell/spufs/sputrace.c
===
--- linux-2.6-lttng.orig/arch/powerpc/platforms/cell/spufs/sputrace.c
2008-02-12 15:07:25.0 -0500
+++ linux-2.6-lttng/arch/powerpc/platforms/cell/spufs/sputrace.c
2008-02-12 15:11:39.0 -0500
@@ -146,34 +146,28 @@
wake_up(_wait);
}
-static void spu_context_event(const struct marker *mdata,
- void *private, const char *format, ...)
+static void spu_context_event(void *probe_private, void *call_data,
+ const char *format, va_list *args)
{
- struct spu_probe *p = mdata->private;
- va_list ap;
+ struct spu_probe *p = probe_private;
struct spu_context *ctx;
struct spu *spu;
- va_start(ap, format);
- ctx = va_arg(ap, struct spu_context *);
- spu = va_arg(ap, struct spu *);
+ ctx = va_arg(*args, struct spu_context *);
+ spu = va_arg(*args, struct spu *);
sputrace_log_item(p->name, ctx, spu);
- va_end(ap);
}
-static void spu_context_nospu_event(const struct marker *mdata,
- void *private, const char *format, ...)
+static void spu_context_nospu_event(void *probe_private, void *call_data,
+ const char *format, va_list *args)
{
- struct spu_probe *p = mdata->private;
- va_list ap;
+ struct spu_probe *p = probe_private;
struct spu_context *ctx;
- va_start(ap, format);
- ctx = va_arg(ap, struct spu_context *);
+ ctx = va_arg(*args, struct spu_context *);
sputrace_log_item(p->name, ctx, NULL);
- va_end(ap);
}
struct spu_probe spu_probes[] = {
@@ -219,10 +213,6 @@
if (error)
printk(KERN_INFO "Unable to register probe %s\n",
p->name);
-
- error = marker_arm(p->name);
- if (error)
- printk(KERN_INFO "Unable to arm probe %s\n", p->name);
}
return 0;
@@ -238,7 +228,8 @@
int i;
for (i = 0; i < ARRAY_SIZE(spu_probes); i++)
- marker_probe_unregister(spu_probes[i].name);
+ marker_probe_unregister(spu_probes[i].name,
+ spu_probes[i].probe_func, _probes[i]);
remove_proc_entry("sputrace", NULL);
kfree(sputrace_log);
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
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/
[PATCH] x86: fixup machine_ops reboot_{32|64}.c unification fallout
Please cc on any replies, thanks.
---
When reboot_32.c and reboot_64.c were unified (commit 4d022e35fd...),
the machine_ops code was broken, leading to xen pvops kernels failing
to properly halt/poweroff/reboot etc. This fixes that up.
Signed-off-by: Jody Belka <[EMAIL PROTECTED]>
---
arch/x86/kernel/reboot.c | 46 --
1 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 5818dc2..7fd6ac4 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -326,7 +326,7 @@ static inline void kb_wait(void)
}
}
-void machine_emergency_restart(void)
+static void native_machine_emergency_restart(void)
{
int i;
@@ -376,7 +376,7 @@ void machine_emergency_restart(void)
}
}
-void machine_shutdown(void)
+static void native_machine_shutdown(void)
{
/* Stop the cpus and apics */
#ifdef CONFIG_SMP
@@ -420,7 +420,7 @@ void machine_shutdown(void)
#endif
}
-void machine_restart(char *__unused)
+static void native_machine_restart(char *__unused)
{
printk("machine restart\n");
@@ -429,11 +429,11 @@ void machine_restart(char *__unused)
machine_emergency_restart();
}
-void machine_halt(void)
+static void native_machine_halt(void)
{
}
-void machine_power_off(void)
+static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
@@ -443,9 +443,35 @@ void machine_power_off(void)
}
struct machine_ops machine_ops = {
- .power_off = machine_power_off,
- .shutdown = machine_shutdown,
- .emergency_restart = machine_emergency_restart,
- .restart = machine_restart,
- .halt = machine_halt
+ .power_off = native_machine_power_off,
+ .shutdown = native_machine_shutdown,
+ .emergency_restart = native_machine_emergency_restart,
+ .restart = native_machine_restart,
+ .halt = native_machine_halt
};
+
+void machine_power_off(void)
+{
+ machine_ops.power_off();
+}
+
+void machine_shutdown(void)
+{
+ machine_ops.shutdown();
+}
+
+void machine_emergency_restart(void)
+{
+ machine_ops.emergency_restart();
+}
+
+void machine_restart(char *cmd)
+{
+ machine_ops.restart(cmd);
+}
+
+void machine_halt(void)
+{
+ machine_ops.halt();
+}
+
--
1.5.2.5
--
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: [ofa-general] Re: Demand paging for memory regions
On Tue, 12 Feb 2008, Christoph Lameter wrote: > On Tue, 12 Feb 2008, Jason Gunthorpe wrote: > > > Well, certainly today the memfree IB devices store the page tables in > > host memory so they are already designed to hang onto packets during > > the page lookup over PCIE, adding in faulting makes this time > > larger. > > You really do not need a page table to use it. What needs to be maintained > is knowledge on both side about what pages are currently shared across > RDMA. If the VM decides to reclaim a page then the notification is used to > remove the remote entry. If the remote side then tries to access the page > again then the page fault on the remote side will stall until the local > page has been brought back. RDMA can proceed after both sides again agree > on that page now being sharable. HPC environments won't be amenable to a pessimistic approach of synchronizing before every data transfer. RDMA is assumed to be a low-level data movement mechanism that has no implied synchronization. In some parallel programming models, it's not uncommon to use RDMA to send 8-byte messages. It can be difficult to make and hold guarantees about in-memory pages when many concurrent RDMA operations are in flight (not uncommon in reasonably large machines). Some of the in-memory page information could be shared with some form of remote caching strategy but then it's a different problem with its own scalability challenges. I think there are very potential clients of the interface when an optimistic approach is used. Part of the trick, however, has to do with being able to re-start transfers instead of buffering the data or making guarantees about delivery that could cause deadlock (as was alluded to earlier in this thread). InfiniBand is constrained in this regard since it requires message-ordering between endpoints (or queue pairs). One could argue that this is still possible with IB, at the cost of throwing more packets away when a referenced page is not in memory. With this approach, the worse case demand paging scenario is met when the active working set of referenced pages is larger than the amount physical memory -- but HPC applications are already bound by this anyway. You'll find that Quadrics has the most experience in this area and that their entire architecture is adapted to being optimistic about demand paging in RDMA transfers -- they've been maintaining a patchset to do this for years. . . christian -- 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 resend] qla3xxx: convert byte order of constant instead ofvariable
> -Original Message-
> From: Marcin Slusarz [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 10, 2008 2:06 AM
> To: [EMAIL PROTECTED]; Linux Driver
> Cc: LKML
> Subject: [PATCH resend] qla3xxx: convert byte order of
> constant instead ofvariable
>
> convert byte order of constant instead of variable
> which can be done at compile time (vs run time)
>
> Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
> ---
> drivers/net/qla3xxx.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
> index a6aeb9d..b7f7b22 100644
> --- a/drivers/net/qla3xxx.c
> +++ b/drivers/net/qla3xxx.c
> @@ -2472,8 +2472,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
>
> if (seg_cnt == 1) {
> /* Terminate the last segment. */
> - oal_entry->len =
> - cpu_to_le32(le32_to_cpu(oal_entry->len) |
> OAL_LAST_ENTRY);
> + oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
> } else {
> oal = tx_cb->oal;
> for (completed_segs=0; completed_segs completed_segs++,seg++) {
> @@ -2530,8 +2529,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
> frag->size);
> }
> /* Terminate the last segment. */
> - oal_entry->len =
> - cpu_to_le32(le32_to_cpu(oal_entry->len) |
> OAL_LAST_ENTRY);
> + oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
> }
>
> return NETDEV_TX_OK;
> --
> 1.5.3.7
>
>
Thanks
Acked-by: Ron Mercer <[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: BTRFS partition usage...
From: Chris Mason <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 09:35:20 -0500 > From my point of view, 0 is a bad idea because it is very likely to > conflict with other things. Starting at 0 is a bad idea because otherwise you'll waste significant chunks of your disk on Sparc because of reasons I've outlined in other replies. What XFS does is really unfortunate, let's learn from it's mistake. -- 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: [REGRESSION]fan turns at highspeed after suspend2ram
On Wednesday, 13 of February 2008, Mirco Tischler wrote:
>
> Am Dienstag, den 12.02.2008, 23:18 +0100 schrieb Rafael J. Wysocki:
> > Ouch. I think I know what the problem is.
> >
> > On top of this patch, please apply the appended one and retest.
> >
> > Thanks,
> > Rafael
> >
> > ---
> > drivers/acpi/hardware/hwsleep.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> > ===
> > --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> > +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> > @@ -566,6 +566,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
> > return_ACPI_STATUS(status);
> > }
> >
> > + arg.integer.value = sleep_state;
> > status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
> > if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> > ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
> Good news. That works perfectly.
Ah, ok. Thanks for testing. :-)
Can you please check if the current mainline with the following patch applied
works on your box?
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -616,6 +616,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
--
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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 11:01:32PM +, Alan Cox wrote: > > Hrm... How badly is pl2303 broken? I actually use that sucker, so if > > it needs help - count me in. > > 2303 is pretty good (in fact by usb serial standards outstanding). It has > all the internal locking needed for now and right down to killing > lock_kernel entirely outside of open/close (which is going to hit > everything). > > Only fixme I have tagged for it is > > - if you set an unsupported baud rate it reports it set rather than the > one you got > > Which is a trivial mend for someone who has suitable docs (its marked > FIXME: at the right spot) I'll see what I can do about fixing this. thanks, greg k-h -- 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: [-mm PATCH] register_memory/unregister_memory clean ups
On Tue, 2008-02-12 at 15:03 -0800, Badari Pulavarty wrote: > Here is the version with your suggestion. Do you like this better ? I do like how it looks, better, thanks. -- 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: [REGRESSION]fan turns at highspeed after suspend2ram
Am Dienstag, den 12.02.2008, 23:18 +0100 schrieb Rafael J. Wysocki:
> Ouch. I think I know what the problem is.
>
> On top of this patch, please apply the appended one and retest.
>
> Thanks,
> Rafael
>
> ---
> drivers/acpi/hardware/hwsleep.c |1 +
> 1 file changed, 1 insertion(+)
>
> Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> ===
> --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> @@ -566,6 +566,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
> return_ACPI_STATUS(status);
> }
>
> + arg.integer.value = sleep_state;
> status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
Good news. That works perfectly.
Thanks
Mirco
--
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: [ofa-general] Re: Demand paging for memory regions
> -Original Message- > From: [EMAIL PROTECTED] [mailto:general- > [EMAIL PROTECTED] On Behalf Of Roland Dreier > Sent: Tuesday, February 12, 2008 2:42 PM > To: Christoph Lameter > Cc: Rik van Riel; [EMAIL PROTECTED]; Andrea Arcangeli; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux- > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Robin Holt; [EMAIL PROTECTED]; > Andrew Morton; [EMAIL PROTECTED] > Subject: Re: [ofa-general] Re: Demand paging for memory regions > > > > Chelsio's T3 HW doesn't support this. > > > Not so far I guess but it could be equipped with these features > right? > > I don't know anything about the T3 internals, but it's not clear that > you could do this without a new chip design in general. Lot's of RDMA > devices were designed expecting that when a packet arrives, the HW can > look up the bus address for a given memory region/offset and place the > packet immediately. It seems like a major change to be able to > generate a "page fault" interrupt when a page isn't present, or even > just wait to scatter some data until the host finishes updating page > tables when the HW needs the translation. That is correct, not a change we can make for T3. We could, in theory, deal with changing mappings though. The change would need to be synchronized though: the VM would need to tell us which mapping were about to change and the driver would then need to disable DMA to/from it, do the change and resume DMA. > > - R. > > ___ > general mailing list > [EMAIL PROTECTED] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general -- 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: BTRFS partition usage...
From: Jan Engelhardt <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET) > Something looks wrong here. Why would btrfs need to zero at all? So that existing superblocks on the partition won't be interpreted as correct by other filesystems. It's a safety measure many mkfs programs use. > Superblock at 0, and done. Just like xfs. No, we won't do stupid things like that and make an entire cylinder of our disks unusable. See my other reply. -- 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] pata_cs5536 Fix secondary port configuration
Am Dienstag, den 12.02.2008, 09:37 -0500 schrieb Martin K. Petersen: > Brown paper bag time. My devel board has a 16MB 1st generation > compact flash on the secondary so I never noticed this was hosed. > Please try the following patch... boots! For some reason, i had to apply it by hand (to 2.6.24.2), and i was too stupid to examine how to produce a new patch. Looks like i have to read the documentation at kernelnewbies.org... Anyway, the patch fits perfectly and now UDMA/33 (due to 40wire-cable, vendor says UDMA/100 should work either) on a HDD using pata_cs5536 just works =) -- Jabber: [EMAIL PROTECTED]PGP: 0x63FC728D Tel: 0170/238 30 53http://www.g-radtke.name signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Announce: Linux-next (Or Andrew's dream :-))
> Hrm... How badly is pl2303 broken? I actually use that sucker, so if > it needs help - count me in. 2303 is pretty good (in fact by usb serial standards outstanding). It has all the internal locking needed for now and right down to killing lock_kernel entirely outside of open/close (which is going to hit everything). Only fixme I have tagged for it is - if you set an unsupported baud rate it reports it set rather than the one you got Which is a trivial mend for someone who has suitable docs (its marked FIXME: at the right spot) -- 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/
[PATCH] quota: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Jan Kara <[EMAIL PROTECTED]>
---
fs/quota_v2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota_v2.c b/fs/quota_v2.c
index c519a58..a9f9eef 100644
--- a/fs/quota_v2.c
+++ b/fs/quota_v2.c
@@ -303,7 +303,7 @@ static uint find_free_dqentry(struct dquot *dquot, int *err)
printk(KERN_ERR "VFS: find_free_dqentry(): Can't remove
block (%u) from entry free list.\n", blk);
goto out_buf;
}
- dh->dqdh_entries = cpu_to_le16(le16_to_cpu(dh->dqdh_entries)+1);
+ le16_add_cpu(>dqdh_entries, 1);
memset(, 0, sizeof(struct v2_disk_dqblk));
/* Find free structure in block */
for (i = 0; i < V2_DQSTRINBLK && memcmp(, ddquot+i,
sizeof(struct v2_disk_dqblk)); i++);
@@ -445,7 +445,7 @@ static int free_dqentry(struct dquot *dquot, uint blk)
goto out_buf;
}
dh = (struct v2_disk_dqdbheader *)buf;
- dh->dqdh_entries = cpu_to_le16(le16_to_cpu(dh->dqdh_entries)-1);
+ le16_add_cpu(>dqdh_entries, -1);
if (!le16_to_cpu(dh->dqdh_entries)) { /* Block got free? */
if ((ret = remove_free_dqentry(sb, type, buf, blk)) < 0 ||
(ret = put_free_dqblk(sb, type, buf, blk)) < 0) {
--
1.5.3.7
--
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/
[PATCH] ext4: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: "Theodore Ts'o" <[EMAIL PROTECTED]>
Cc: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/balloc.c |7 ++-
fs/ext4/extents.c | 20 +---
fs/ext4/ialloc.c | 12
fs/ext4/mballoc.c |7 ++-
fs/ext4/resize.c |6 ++
fs/ext4/super.c |2 +-
fs/ext4/xattr.c |6 ++
7 files changed, 22 insertions(+), 38 deletions(-)
diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index 0737e05..5d34899 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -752,9 +752,7 @@ do_more:
jbd_unlock_bh_state(bitmap_bh);
spin_lock(sb_bgl_lock(sbi, block_group));
- desc->bg_free_blocks_count =
- cpu_to_le16(le16_to_cpu(desc->bg_free_blocks_count) +
- group_freed);
+ le16_add_cpu(>bg_free_blocks_count, group_freed);
desc->bg_checksum = ext4_group_desc_csum(sbi, block_group, desc);
spin_unlock(sb_bgl_lock(sbi, block_group));
percpu_counter_add(>s_freeblocks_counter, count);
@@ -1823,8 +1821,7 @@ allocated:
spin_lock(sb_bgl_lock(sbi, group_no));
if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))
gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
- gdp->bg_free_blocks_count =
- cpu_to_le16(le16_to_cpu(gdp->bg_free_blocks_count)-num);
+ le16_add_cpu(>bg_free_blocks_count, -num);
gdp->bg_checksum = ext4_group_desc_csum(sbi, group_no, gdp);
spin_unlock(sb_bgl_lock(sbi, group_no));
percpu_counter_sub(>s_freeblocks_counter, num);
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index bc7081f..ad628ff 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -608,7 +608,7 @@ static int ext4_ext_insert_index(handle_t *handle, struct
inode *inode,
ix->ei_block = cpu_to_le32(logical);
ext4_idx_store_pblock(ix, ptr);
- curp->p_hdr->eh_entries =
cpu_to_le16(le16_to_cpu(curp->p_hdr->eh_entries)+1);
+ le16_add_cpu(>p_hdr->eh_entries, 1);
BUG_ON(le16_to_cpu(curp->p_hdr->eh_entries)
> le16_to_cpu(curp->p_hdr->eh_max));
@@ -730,7 +730,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
}
if (m) {
memmove(ex, path[depth].p_ext-m, sizeof(struct ext4_extent)*m);
- neh->eh_entries = cpu_to_le16(le16_to_cpu(neh->eh_entries)+m);
+ le16_add_cpu(>eh_entries, m);
}
set_buffer_uptodate(bh);
@@ -747,8 +747,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
err = ext4_ext_get_access(handle, inode, path + depth);
if (err)
goto cleanup;
- path[depth].p_hdr->eh_entries =
-cpu_to_le16(le16_to_cpu(path[depth].p_hdr->eh_entries)-m);
+ le16_add_cpu([depth].p_hdr->eh_entries, -m);
err = ext4_ext_dirty(handle, inode, path + depth);
if (err)
goto cleanup;
@@ -811,8 +810,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
if (m) {
memmove(++fidx, path[i].p_idx - m,
sizeof(struct ext4_extent_idx) * m);
- neh->eh_entries =
- cpu_to_le16(le16_to_cpu(neh->eh_entries) + m);
+ le16_add_cpu(>eh_entries, m);
}
set_buffer_uptodate(bh);
unlock_buffer(bh);
@@ -828,7 +826,7 @@ static int ext4_ext_split(handle_t *handle, struct inode
*inode,
err = ext4_ext_get_access(handle, inode, path + i);
if (err)
goto cleanup;
- path[i].p_hdr->eh_entries =
cpu_to_le16(le16_to_cpu(path[i].p_hdr->eh_entries)-m);
+ le16_add_cpu([i].p_hdr->eh_entries, -m);
err = ext4_ext_dirty(handle, inode, path + i);
if (err)
goto cleanup;
@@ -1363,7 +1361,7 @@ int ext4_ext_try_to_merge(struct inode *inode,
* sizeof(struct ext4_extent);
memmove(ex + 1, ex + 2, len);
}
- eh->eh_entries = cpu_to_le16(le16_to_cpu(eh->eh_entries) - 1);
+ le16_add_cpu(>eh_entries, -1);
merge_done = 1;
WARN_ON(eh->eh_entries == 0);
if
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 14:55:31 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote: > > > I think the best way to get the serial drivers maintained would be to cat > > > them all onto the end of synclink.c and hope that Paul thinks he did it. > > > > Well I've already broken the buffering so he'd fix it ;) > > > > We have a pile of old ISA drivers that are going to break soon with the > > locking changes and a pile of USB drivers that when I looked at the > > locking were so terminally broken I couldn't be bothered to fix them. > > Let me know which USB ones are broken, I'll work to fix them. That I noticed doing an audit for unlocking the mctrl functions: ir-usb: global variables without locking used in per port operations iuu_phoenix: no locking on internal data structures mos7840: ditto option: ditto kobil_sct: ditto These drivers do interesting things (where interesting is probably not too evil on a PC - except ir-usb) involving playing with data structures without locks. It seems there was some kind of evolution along the way as some drivers do have a carefully used port private data structure lock (or two) but many do not. -- 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/
[PATCH] scsi: le*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
little_endian_variable = cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
leX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
drivers/scsi/aacraid/commsup.c |2 +-
drivers/scsi/ips.c |8 ++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 81b3692..3ac8c82 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -594,7 +594,7 @@ void aac_consumer_free(struct aac_dev * dev, struct
aac_queue *q, u32 qid)
if (le32_to_cpu(*q->headers.consumer) >= q->entries)
*q->headers.consumer = cpu_to_le32(1);
else
- *q->headers.consumer =
cpu_to_le32(le32_to_cpu(*q->headers.consumer)+1);
+ le32_add_cpu(q->headers.consumer, 1);
if (wasfull) {
switch (qid) {
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index bb152fb..f45770a 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -3696,9 +3696,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
scb->cmd.basic_io.sg_count = scb->sg_len;
if (scb->cmd.basic_io.lba)
- scb->cmd.basic_io.lba =
- cpu_to_le32(le32_to_cpu
- (scb->cmd.basic_io.lba) +
+ le32_add_cpu(>cmd.basic_io.lba,
le16_to_cpu(scb->cmd.basic_io.
sector_count));
else
@@ -3744,9 +3742,7 @@ ips_send_cmd(ips_ha_t * ha, ips_scb_t * scb)
scb->cmd.basic_io.sg_count = scb->sg_len;
if (scb->cmd.basic_io.lba)
- scb->cmd.basic_io.lba =
- cpu_to_le32(le32_to_cpu
- (scb->cmd.basic_io.lba) +
+ le32_add_cpu(>cmd.basic_io.lba,
le16_to_cpu(scb->cmd.basic_io.
sector_count));
else
--
1.5.3.7
--
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/
[PATCH] affs: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Roman Zippel <[EMAIL PROTECTED]> --- fs/affs/file.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/affs/file.c b/fs/affs/file.c index 6e0c939..95b48af 100644 --- a/fs/affs/file.c +++ b/fs/affs/file.c @@ -543,7 +543,7 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize) if (boff + tmp > bsize || tmp > bsize) BUG(); memset(AFFS_DATA(bh) + boff, 0, tmp); - AFFS_DATA_HEAD(bh)->size = cpu_to_be32(be32_to_cpu(AFFS_DATA_HEAD(bh)->size) + tmp); + be32_add_cpu(_DATA_HEAD(bh)->size, tmp); affs_fix_checksum(sb, bh); mark_buffer_dirty_inode(bh, inode); size += tmp; @@ -686,7 +686,7 @@ static int affs_write_end_ofs(struct file *file, struct address_space *mapping, if (boff + tmp > bsize || tmp > bsize) BUG(); memcpy(AFFS_DATA(bh) + boff, data + from, tmp); - AFFS_DATA_HEAD(bh)->size = cpu_to_be32(be32_to_cpu(AFFS_DATA_HEAD(bh)->size) + tmp); + be32_add_cpu(_DATA_HEAD(bh)->size, tmp); affs_fix_checksum(sb, bh); mark_buffer_dirty_inode(bh, inode); written += tmp; -- 1.5.3.7 -- 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/
[PATCH] infiniband: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Roland Dreier <[EMAIL PROTECTED]> Cc: Sean Hefty <[EMAIL PROTECTED]> Cc: Hal Rosenstock <[EMAIL PROTECTED]> --- drivers/infiniband/hw/mthca/mthca_cq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/mthca/mthca_cq.c b/drivers/infiniband/hw/mthca/mthca_cq.c index 6bd9f13..1e1e336 100644 --- a/drivers/infiniband/hw/mthca/mthca_cq.c +++ b/drivers/infiniband/hw/mthca/mthca_cq.c @@ -473,7 +473,7 @@ static void handle_error_cqe(struct mthca_dev *dev, struct mthca_cq *cq, if (!(new_wqe & cpu_to_be32(0x3f)) || (!cqe->db_cnt && dbd)) return; - cqe->db_cnt = cpu_to_be16(be16_to_cpu(cqe->db_cnt) - dbd); + be16_add_cpu(>db_cnt, -dbd); cqe->wqe = new_wqe; cqe->syndrome = SYNDROME_WR_FLUSH_ERR; -- 1.5.3.7 -- 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/
[PATCH] ieee 1394: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]> replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(_endian_variable, expression_in_cpu_byteorder); generated with semantic patch Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> Cc: Ben Collins <[EMAIL PROTECTED]> Cc: Stefan Richter <[EMAIL PROTECTED]> --- drivers/ieee1394/csr.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/ieee1394/csr.c b/drivers/ieee1394/csr.c index 52ac83e..c90be40 100644 --- a/drivers/ieee1394/csr.c +++ b/drivers/ieee1394/csr.c @@ -133,8 +133,7 @@ static void host_reset(struct hpsb_host *host) host->csr.state &= ~0x100; } -host->csr.topology_map[1] = -cpu_to_be32(be32_to_cpu(host->csr.topology_map[1]) + 1); + be32_add_cpu(>csr.topology_map[1], 1); host->csr.topology_map[2] = cpu_to_be32(host->node_count << 16 | host->selfid_count); host->csr.topology_map[0] = @@ -142,8 +141,7 @@ static void host_reset(struct hpsb_host *host) | csr_crc16(host->csr.topology_map + 1, host->selfid_count + 2)); -host->csr.speed_map[1] = -cpu_to_be32(be32_to_cpu(host->csr.speed_map[1]) + 1); + be32_add_cpu(>csr.speed_map[1], 1); host->csr.speed_map[0] = cpu_to_be32(0x3f1 << 16 | csr_crc16(host->csr.speed_map+1, 0x3f1)); -- 1.5.3.7 -- 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/
[PATCH] crypto: be*_add_cpu conversion
From: Marcin Slusarz <[EMAIL PROTECTED]>
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(_endian_variable, expression_in_cpu_byteorder);
generated with semantic patch
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PROTECTED]>
Cc: David S. Miller <[EMAIL PROTECTED]>
---
crypto/lrw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 9d52e58..4d93928 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -92,7 +92,7 @@ struct sinfo {
static inline void inc(be128 *iv)
{
if (!(iv->b = cpu_to_be64(be64_to_cpu(iv->b) + 1)))
- iv->a = cpu_to_be64(be64_to_cpu(iv->a) + 1);
+ be64_add_cpu(>a, 1);
}
static inline void lrw_round(struct sinfo *s, void *dst, const void *src)
--
1.5.3.7
--
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/
[PATCHSET] [bl]e*_add_cpu conversions
From: Marcin Slusarz <[EMAIL PROTECTED]> Hi This patchset converts big/little_endian_variable = cpu_to_[bl]eX([bl]eX_to_cpu(big/little_endian_variable) + expression_in_cpu_byteorder); to: [bl]eX_add_cpu(/little_endian_variable, expression_in_cpu_byteorder); All patches were generated by spatch, then reviewed and fixed to follow coding style. Semantic patch: @@ expression *X; expression Y; @@ ( - *X = cpu_to_le64(le64_to_cpu(*X) + Y); + le64_add_cpu(X, Y); | - *X = cpu_to_le32(le32_to_cpu(*X) + Y); + le32_add_cpu(X, Y); | - *X = cpu_to_le16(le16_to_cpu(*X) + Y); + le16_add_cpu(X, Y); | - *X = cpu_to_be64(be64_to_cpu(*X) + Y); + be64_add_cpu(X, Y); | - *X = cpu_to_be32(be32_to_cpu(*X) + Y); + be32_add_cpu(X, Y); | - *X = cpu_to_be16(be16_to_cpu(*X) + Y); + be16_add_cpu(X, Y); | - *X = cpu_to_le64(le64_to_cpu(*X) - Y); + le64_add_cpu(X, -Y); | - *X = cpu_to_le32(le32_to_cpu(*X) - Y); + le32_add_cpu(X, -Y); | - *X = cpu_to_le16(le16_to_cpu(*X) - Y); + le16_add_cpu(X, -Y); | - *X = cpu_to_be64(be64_to_cpu(*X) - Y); + be64_add_cpu(X, -Y); | - *X = cpu_to_be32(be32_to_cpu(*X) - Y); + be32_add_cpu(X, -Y); | - *X = cpu_to_be16(be16_to_cpu(*X) - Y); + be16_add_cpu(X, -Y); ) @@ expression X, Y; @@ ( - X = cpu_to_le64(le64_to_cpu(X) + Y); + le64_add_cpu(, Y); | - X = cpu_to_le32(le32_to_cpu(X) + Y); + le32_add_cpu(, Y); | - X = cpu_to_le16(le16_to_cpu(X) + Y); + le16_add_cpu(, Y); | - X = cpu_to_be64(be64_to_cpu(X) + Y); + be64_add_cpu(, Y); | - X = cpu_to_be32(be32_to_cpu(X) + Y); + be32_add_cpu(, Y); | - X = cpu_to_be16(be16_to_cpu(X) + Y); + be16_add_cpu(, Y); | - X = cpu_to_le64(le64_to_cpu(X) - Y); + le64_add_cpu(, -Y); | - X = cpu_to_le32(le32_to_cpu(X) - Y); + le32_add_cpu(, -Y); | - X = cpu_to_le16(le16_to_cpu(X) - Y); + le16_add_cpu(, -Y); | - X = cpu_to_be64(be64_to_cpu(X) - Y); + be64_add_cpu(, -Y); | - X = cpu_to_be32(be32_to_cpu(X) - Y); + be32_add_cpu(, -Y); | - X = cpu_to_be16(be16_to_cpu(X) - Y); + be16_add_cpu(, -Y); ) diffstat: crypto/lrw.c |2 +- drivers/ieee1394/csr.c |6 ++ drivers/infiniband/hw/mthca/mthca_cq.c |2 +- drivers/net/wireless/ipw2200.c |4 +--- drivers/scsi/aacraid/commsup.c |2 +- drivers/scsi/ips.c |8 ++-- fs/affs/file.c |4 ++-- fs/ext2/ialloc.c | 12 fs/ext2/super.c|2 +- fs/ext2/xattr.c|9 +++-- fs/ext4/balloc.c |7 ++- fs/ext4/extents.c | 20 +--- fs/ext4/ialloc.c | 12 fs/ext4/mballoc.c |7 ++- fs/ext4/resize.c |6 ++ fs/ext4/super.c|2 +- fs/ext4/xattr.c|6 ++ fs/gfs2/dir.c |6 +++--- fs/hfs/mdb.c |2 +- fs/hfsplus/super.c |2 +- fs/jfs/jfs_dmap.c | 11 +-- fs/jfs/jfs_imap.c | 15 ++- fs/jfs/jfs_xtree.c | 26 -- fs/ntfs/upcase.c |5 ++--- fs/ocfs2/dir.c |5 ++--- fs/ocfs2/localalloc.c |3 +-- fs/quota_v2.c |4 ++-- fs/reiserfs/objectid.c |5 ++--- fs/reiserfs/stree.c|3 +-- fs/sysv/sysv.h |8 fs/ufs/swab.h | 16 31 files changed, 86 insertions(+), 136 deletions(-) Marcin -- 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/
Cast cmpxchg64 and cmpxchg64_local result for 386 and 486 - Fix missing parenthesis
Two pairs of parenthesis were missing around the result cast of cmpxchg64 and
cmpxchg64_local. This is a rather stupid mistake in
"Cast cmpxchg and cmpxchg_local result for 386 and 486". My bad. This fix
should be folded with the previous.
Sorry for this trivial bug which should have never appeared in the first place.
The aim was to fix cmpxchg and cmpxchg_local, which were used in slub. cmpxchg64
and cmpxchg64_local happen to be only used in LTTng currently.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Vegard Nossum <[EMAIL PROTECTED]>
Cc: Pekka Enberg <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
include/asm-x86/cmpxchg_32.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6-lttng/include/asm-x86/cmpxchg_32.h
===
--- linux-2.6-lttng.orig/include/asm-x86/cmpxchg_32.h 2008-02-12
17:49:32.0 -0500
+++ linux-2.6-lttng/include/asm-x86/cmpxchg_32.h2008-02-12
17:50:18.0 -0500
@@ -305,11 +305,11 @@ extern unsigned long long cmpxchg_486_u6
({ \
__typeof__(*(ptr)) __ret; \
if (likely(boot_cpu_data.x86 > 4)) \
- __ret = __typeof__(*(ptr))__cmpxchg64((ptr),\
+ __ret = (__typeof__(*(ptr)))__cmpxchg64((ptr), \
(unsigned long long)(o),\
(unsigned long long)(n)); \
else\
- __ret = __typeof__(*(ptr))cmpxchg_486_u64((ptr),\
+ __ret = (__typeof__(*(ptr)))cmpxchg_486_u64((ptr), \
(unsigned long long)(o),\
(unsigned long long)(n)); \
__ret; \
@@ -318,11 +318,11 @@ extern unsigned long long cmpxchg_486_u6
({ \
__typeof__(*(ptr)) __ret; \
if (likely(boot_cpu_data.x86 > 4)) \
- __ret = __typeof__(*(ptr))__cmpxchg64_local((ptr), \
+ __ret = (__typeof__(*(ptr)))__cmpxchg64_local((ptr),\
(unsigned long long)(o),\
(unsigned long long)(n)); \
else\
- __ret = __typeof__(*(ptr))cmpxchg_486_u64((ptr),\
+ __ret = (__typeof__(*(ptr)))cmpxchg_486_u64((ptr), \
(unsigned long long)(o),\
(unsigned long long)(n)); \
__ret; \
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
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 4/8][for -mm] mem_notify v6: memory_pressure_notify() caller
On Sun, 10 Feb 2008 00:24:28 +0900 "KOSAKI Motohiro" <[EMAIL PROTECTED]> wrote: > the notification point to happen whenever the VM moves an > anonymous page to the inactive list - this is a pretty good indication > that there are unused anonymous pages present which will be very likely > swapped out soon. > > and, It is judged out of trouble at the fllowing situations. > o memory pressure decrease and stop moves an anonymous page to the > inactive list. > o free pages increase than (pages_high+lowmem_reserve)*2. This seems rather arbitrary. Why choose this stage in the page reclaimation process rather than some other stage? If this feature is useful then I'd expect that some applications would want notification at different times, or at different levels of VM distress. So this semi-randomly-chosen notification point just won't be strong enough in real-world use. Does this change work correctly and appropriately for processes which are running in a cgroup memory controller? Given the amount of code which these patches add, and the subsequent maintenance burden, and the unlikelihood of getting many applications to actually _use_ the interface, it is not obvious to me that inclusion in the kernel is justifiable, sorry. memory_pressure_notify() is far too large to be inlined. Some of the patches were wordwrapped. -- 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 1/6] Core driver for WM97xx touchscreens
Hi, Mark Brown wrote: > This patch series adds support for the touchscreen controllers provided > by Wolfson Microelectronics WM97xx series chips in both polled and > streaming modes. You used platform_device_register, but should be using platform_device_add, otherwise you get barfs with 2.6.25-rc1 (device is initialized twice). Also as got deprecated there is no point including it. Patch below -- With best wishes Dmitry >From 81b96191eb50837bdf1f437a6f4f05786cc0b49e Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 01:55:10 +0300 Subject: [PATCH] wm97xx-core fixes Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]> --- drivers/input/touchscreen/wm97xx-core.c |8 include/linux/wm97xx.h |1 - 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c index 840d9ff..4cbb9e5 100644 --- a/drivers/input/touchscreen/wm97xx-core.c +++ b/drivers/input/touchscreen/wm97xx-core.c @@ -596,7 +596,7 @@ static int wm97xx_probe(struct device *dev) } platform_set_drvdata(wm->battery_dev, wm); wm->battery_dev->dev.parent = dev; - ret = platform_device_register(wm->battery_dev); + ret = platform_device_add(wm->battery_dev); if (ret < 0) goto batt_reg_err; @@ -609,7 +609,7 @@ static int wm97xx_probe(struct device *dev) } platform_set_drvdata(wm->touch_dev, wm); wm->touch_dev->dev.parent = dev; - ret = platform_device_register(wm->touch_dev); + ret = platform_device_add(wm->touch_dev); if (ret < 0) goto touch_reg_err; @@ -619,12 +619,12 @@ static int wm97xx_probe(struct device *dev) platform_device_put(wm->touch_dev); touch_err: platform_device_unregister(wm->battery_dev); - wm->battery_dev = 0; + wm->battery_dev = NULL; batt_reg_err: platform_device_put(wm->battery_dev); batt_err: input_unregister_device(wm->input_dev); - wm->input_dev = 0; + wm->input_dev = NULL; dev_alloc_err: input_free_device(wm->input_dev); alloc_err: diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h index fc6e0b3..f0d9fc0 100644 --- a/include/linux/wm97xx.h +++ b/include/linux/wm97xx.h @@ -6,7 +6,6 @@ #ifndef _LINUX_WM97XX_H #define _LINUX_WM97XX_H -#include #include #include #include -- 1.5.3.8 -- 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: [Bug 9944] suspend to ram doesn't work anymore on Thinkpad T61 with Intel X3100
On Tuesday, 12 of February 2008, [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9944 > > > > Distribution: Debian Sid > > Hardware Environment: Thinkpad T61 > > Software Environment: > > Problem Description: > > > > Suspend to ram doesn't work anymore on my thinkpad t61 with 2.6.25-rc1. On > > 2.6.24 I had to pass acpi_sleep=s3bios at boot time and suspend with s2ram > > -f > > -a 3. > > > > On 2.6.25-rc1 doing (on console, with X not running) that leads to a blank > > screen and the ___sleep___ led (the moon) on the thinkpad blinks (like when > > it > > is currently suspending), but nothing happens then. > > > > If I can make some more tests, or if you need more info, please ask. I hope > > this is no duplicate. > > > > I have a t61p and suspend/hibernate is bad and deteriorating. So > many things go wrong that I'm afraid to test it any more. There are at least two known suspend regressions, one of which affects the T61 for sure. There's a fix for it, available at: http://lkml.org/lkml/2008/2/11/472 The fix for the second issue is in the works. -- 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: [RFC v3 5/7] dmaengine: Make DMA Engine menu visible for AVR32 users
On Feb 12, 2008 3:13 PM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > On Tue, 12 Feb 2008 14:43:30 -0600 > Olof Johansson <[EMAIL PROTECTED]> wrote: > > > > - depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX > > > + depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX > > > || AVR32 > > > > This is a slippery slope. Things should be the other way around instead, > > create a HAVE_DMA_DEVICE, select it in the relevant platform code and > > make DMADEVICES depend on that. > > Agree. I'll cook up a patch tomorrow to make it use the new HAVE_* > scheme. > I suggested something similar here: http://marc.info/?l=linux-kernel=118670671806100=2 > > Or just let the subsystem always be available. > > It used to be always available, but then it was changed. Assuming there > was a reason for this change, I guess we don't want to change it back. > Adrian had concerns about users enabling NET_DMA when the hardware capability is relatively rare. So, +1 for HAVE_DMA_DEVICE > Haavard -- Dan -- 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.24-sha1: RIP [] iov_iter_advance+0x38/0x70
On Tue, Feb 12, 2008 at 02:04:30PM -0800, Andrew Morton wrote: > On Sun, 10 Feb 2008 17:00:31 +0300 > Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > > > This happened during LTP. FWIW, modprobe/rmmod trivial empty module > > together with cat /proc/*/wchan and cat /proc/modules were also running. > > > > Box is E6400, much debugging is on, config below. > > > > > > [ 4057.31] BUG: unable to handle kernel paging request at > > 810101dbc008 > > [ 4057.31] IP: [] iov_iter_advance+0x38/0x70 > > [ 4057.31] PGD 8063 PUD c063 PMD 153baa163 PTE 800101dbc160 > > [ 4057.31] Oops: [1] SMP DEBUG_PAGEALLOC > > [ 4057.31] CPU 0 > > [ 4057.31] Modules linked in: [last unloaded: foo] > > what is this foo.ko of which you speak, and did it wreck your kernel? It's a trivial dumb module which does nothing but loads and unloads. I redid ftest03 later without any suspicious activity and it oopsed the same way. Don't worry about it. > > [ 4057.31] Pid: 7035, comm: ftest03 Not tainted > > 2.6.24-25f666300625d894ebe04bac2b4b3aadb907c861 #2 > > [ 4057.31] RIP: 0010:[] [] > > iov_iter_advance+0x38/0x70 > > [ 4057.31] RSP: 0018:810110329b20 EFLAGS: 00010246 > > [ 4057.31] RAX: RBX: 0800 RCX: > > > > [ 4057.31] RDX: RSI: 0800 RDI: > > 810110329ba8 > > [ 4057.31] RBP: 0800 R08: R09: > > 810101dbc000 > > [ 4057.31] R10: 0004 R11: R12: > > 00026000 > > [ 4057.31] R13: 81010d765c98 R14: 1000 R15: > > > > [ 4057.31] FS: 7fee589146d0() GS:80501000() > > knlGS: > > [ 4057.31] CS: 0010 DS: ES: CR0: 8005003b > > [ 4057.31] CR2: 810101dbc008 CR3: 0001103da000 CR4: > > 06e0 > > [ 4057.31] DR0: DR1: DR2: > > > > [ 4057.31] DR3: DR6: 0ff0 DR7: > > 0400 > > [ 4057.31] Process ftest03 (pid: 7035, threadinfo 810110328000, > > task 810160b0) > > [ 4057.31] Stack: 8025b413 81010d765ab0 804e6fd8 > > 001201d2 > > [ 4057.31] 810110329db8 00026000 810110329d38 > > 81017b9fb500 > > [ 4057.31] 81010d765c98 804175e0 81010d765ab0 > > > > [ 4057.31] Call Trace: > > [ 4057.31] [] ? > > generic_file_buffered_write+0x1e3/0x6f0 > > [ 4057.31] [] ? current_fs_time+0x1e/0x30 > > [ 4057.31] [] ? > > __generic_file_aio_write_nolock+0x28f/0x440 > > [ 4057.31] [] ? generic_file_aio_write+0x63/0xd0 > > [ 4057.31] [] ? ext3_file_write+0x23/0xc0 > > [ 4057.31] [] ? ext3_file_write+0x0/0xc0 > > [ 4057.31] [] ? do_sync_readv_writev+0xcb/0x110 > > [ 4057.31] [] ? autoremove_wake_function+0x0/0x30 > > [ 4057.31] [] ? debug_check_no_locks_freed+0x7d/0x130 > > [ 4057.31] [] ? trace_hardirqs_on+0xcf/0x150 > > [ 4057.31] [] ? __kmalloc+0x15/0xc0 > > [ 4057.31] [] ? rw_copy_check_uvector+0x9d/0x130 > > [ 4057.31] [] ? do_readv_writev+0xe0/0x170 > > [ 4057.31] [] ? mutex_lock_nested+0x1a7/0x280 > > [ 4057.31] [] ? trace_hardirqs_on+0xcf/0x150 > > [ 4057.31] [] ? __mutex_unlock_slowpath+0xc9/0x170 > > [ 4057.31] [] ? trace_hardirqs_on+0xcf/0x150 > > [ 4057.31] [] ? trace_hardirqs_on_thunk+0x35/0x3a > > [ 4057.31] [] ? sys_writev+0x53/0x90 > > [ 4057.31] [] ? system_call_after_swapgs+0x7b/0x80 > > [ 4057.31] > > [ 4057.31] > > [ 4057.31] Code: 48 01 77 10 48 29 77 18 c3 0f 0b eb fe 66 66 90 66 66 > > 90 4c 8b 0f 48 8b 4f 10 49 89 f0 eb 07 66 66 66 90 49 29 c0 4d 85 c0 75 07 > > <49> 83 79 08 00 75 23 49 8b 51 08 48 89 d0 48 29 c8 49 39 c0 49 > > [ 4057.31] RIP [] iov_iter_advance+0x38/0x70 > > [ 4057.31] RSP > > [ 4057.31] CR2: 810101dbc008 > > [ 4057.31] Kernel panic - not syncing: Fatal exception > > because this has me stumped. It might need bisecting, please. OK. > Nick, can you think of anything around there which we changed? -- 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: IO queueing and complete affinity w/ threads: Some results
Alan D. Brunelle wrote: > > Hopefully, the first column is self-explanatory - these are the settings > applied to the queue_affinity, completion_affinity and rq_affinity tunables. > Due to the fact that the standard deviations are so large coupled with the > very close average results, I'm not seeing anything in this set of tests to > favor any of the combinations... > Note quite: Q or C = 0 really means Q or C set to -1 (default), Q or C = 1 means placing that thread on the CPU managing the IRQ. Sorry... Alan -- 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: [RFC PATCH] RTTIME watchdog timer proc interface
Peter Zijlstra wrote: > On Mon, 2008-02-11 at 13:44 -0800, Hiroshi Shimamoto wrote: >> Hi Ingo, >> >> I think an interface to access RLIMIT_RTTIME from outside is useful. >> It makes administrator able to set RLIMIT_RTTIME watchdog to existing >> real-time applications without impact. >> >> I implemented that interface with /proc filesystem. > > /proc//tasks//rttime might also make sense. > thanks, I'll add. -- 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] timeconst.pl: correct reversal of USEC_TO_HZ and HZ_TO_USEC
H. Peter Anvin wrote:
> The USEC_TO_HZ and HZ_TO_USEC constant sets were mislabelled, with
> seriously incorrect results. This among other things manifested
> itself as cpufreq not working when a tickless kernel was configured.
>
> Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Tested-by: Carlos R. Mafra <[EMAIL PROTECTED]>
> ---
> kernel/timeconst.pl |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
> index 62b1287..4146803 100644
> --- a/kernel/timeconst.pl
> +++ b/kernel/timeconst.pl
> @@ -339,7 +339,7 @@ sub output($@)
> print "\n";
>
> foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ',
> - 'USEC_TO_HZ','HZ_TO_USEC') {
> + 'HZ_TO_USEC','USEC_TO_HZ') {
> foreach $bit (32, 64) {
> foreach $suf ('MUL', 'ADJ', 'SHR') {
> printf "#define %-23s %s\n",
--
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: [REGRESSION]fan turns at highspeed after suspend2ram
On Tuesday, 12 of February 2008, Mirco Tischler wrote:
>
> Am Dienstag, den 12.02.2008, 01:13 +0100 schrieb Rafael J. Wysocki:
> > Since _GTS and _BFS don't seem to be defined in your box's BIOS, please
> > try to apply the appended patch on top of the revert and see if that breaks
> > things again.
> >
> > Thanks,
> > Rafael
> >
> > ---
> > drivers/acpi/hardware/hwsleep.c | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> > ===
> > --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> > +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> > @@ -199,11 +199,6 @@ acpi_status acpi_enter_sleep_state_prep(
> > return_ACPI_STATUS(status);
> > }
> >
> > - status = acpi_evaluate_object(NULL, METHOD_NAME__GTS, _list, NULL);
> > - if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> > - return_ACPI_STATUS(status);
> > - }
> > -
> > /* Setup the argument to _SST */
> >
> > switch (sleep_state) {
> > @@ -554,12 +549,6 @@ acpi_status acpi_leave_sleep_state(u8 sl
> > ACPI_EXCEPTION((AE_INFO, status, "During Method _SST"));
> > }
> >
> > - arg.integer.value = sleep_state;
> > - status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, _list, NULL);
> > - if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> > - ACPI_EXCEPTION((AE_INFO, status, "During Method _BFS"));
> > - }
> > -
> > /*
> > * GPEs must be enabled before _WAK is called as GPEs
> > * might get fired there
> Yes, that's it. This patch breaks things again.
Ouch. I think I know what the problem is.
On top of this patch, please apply the appended one and retest.
Thanks,
Rafael
---
drivers/acpi/hardware/hwsleep.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -566,6 +566,7 @@ acpi_status acpi_leave_sleep_state(u8 sl
return_ACPI_STATUS(status);
}
+ arg.integer.value = sleep_state;
status = acpi_evaluate_object(NULL, METHOD_NAME__WAK, _list, NULL);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
ACPI_EXCEPTION((AE_INFO, status, "During Method _WAK"));
--
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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 21:51:52 + Alan Cox <[EMAIL PROTECTED]> wrote: > > We could simply decide that API changes affecting more than one subsystem > > Must Be Serialized(tm). Explicitly. As in "any such change is posted > > Welcome to dreamland. The only way I can get serial changes done is to > wait months and eventually simply persuade Andrew to ignore the > "maintainers" who are basically not responding. "maintainers"? I think the best way to get the serial drivers maintained would be to cat them all onto the end of synclink.c and hope that Paul thinks he did it. -- 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: [-mm PATCH] register_memory/unregister_memory clean ups
On Tue, 2008-02-12 at 14:07 -0800, Badari Pulavarty wrote:
> On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> > On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > >
> > > +static void __remove_section(struct zone *zone, unsigned long
> > > section_nr)
> > > +{
> > > + if (!valid_section_nr(section_nr))
> > > + return;
> > > +
> > > + unregister_memory_section(__nr_to_section(section_nr));
> > > + sparse_remove_one_section(zone, section_nr);
> > > +}
> >
> > I do think passing in a mem_section* here is highly superior. It makes
> > it impossible to pass a pfn in and not get a warning.
> >
>
> Only problem is, I need to hold pgdat_resize_lock() if pass *ms.
> If I don't hold the resize_lock, I have to re-evaluate.
What's wrong with holding the resize lock? What races, precisely, are
you trying to avoid?
> And also,
> I need to pass section_nr for decoding the mem_map anyway :(
See sparse.c::__section_nr(). It takes a mem_section* and returns a
section_nr.
-- Dave
--
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: [RFC v3 5/7] dmaengine: Make DMA Engine menu visible for AVR32 users
On Tue, 12 Feb 2008 14:43:30 -0600 Olof Johansson <[EMAIL PROTECTED]> wrote: > > - depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX > > + depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX > > || AVR32 > > This is a slippery slope. Things should be the other way around instead, > create a HAVE_DMA_DEVICE, select it in the relevant platform code and > make DMADEVICES depend on that. Agree. I'll cook up a patch tomorrow to make it use the new HAVE_* scheme. > Or just let the subsystem always be available. It used to be always available, but then it was changed. Assuming there was a reason for this change, I guess we don't want to change it back. Haavard -- 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: currently active Linux kernel versions
When Willy go in 2.6.22.y, then I help it, so far as I 'm possible. On 2/12/08, Mike Snitzer <[EMAIL PROTECTED]> wrote: > On Feb 12, 2008 4:18 PM, Ferenc Wagner <[EMAIL PROTECTED]> wrote: > > Xavier Bestel <[EMAIL PROTECTED]> writes: > > > > > On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > > > > > >> which are the "currently active Linux kernel versions" at any point in > > >> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > > >> Or more precisely: which are the "stable" versions I can depend on for > > >> a more or less critical server, those that have active security > > >> support or receive at least critical bugfixes? I know about the > > >> 2.6.2[34].y stable git trees, but I wonder how long will those receive > > >> attention (that is, security fixes). Can I find a written policy > > >> somewhere? > > > > > > The answer is at http://kernel.org/ > > > > Not quite, at least I can't find 2.6.23.y there, even though that > > branch seems to be maintained... > > 2.6.16.x is still maintained (2.6.16.60 was recently released). > > 2.6.22.x is still maintained but Greg KH is apparently going to be > ending his duties on it after the next release or so. There is some > confusion as to whether Willy Tarreau will be taking on the 2.6.22.x > tree once Greg is done, Willy?: > http://lwn.net/Articles/268003/ > http://kerneltrap.org/Linux/Stable_2.6_Branches > > 2.6.23.x and 2.6.24.x are obviously quite active for [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/ > -- Thanks, Oliver -- 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: Demand paging for memory regions (was Re: MMU Notifiers V6)
On Tue, 12 Feb 2008, Steve Wise wrote: > Chelsio's T3 HW doesn't support this. Not so far I guess but it could be equipped with these features right? Having the VM manage the memory area for Infiniband allows more reliable system operations and enables the sharing of large memory areas via Infiniband without the risk of livelocks or OOMs. -- 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/
[PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.
RDMA/cxgb3: Fail loopback connections.
The cxgb3 HW and driver don't support loopback RDMA connections. So fail
any connection attempt where the destination address is local.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index e9a08fa..5d82723 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1784,6 +1784,17 @@ err:
return err;
}
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+ struct net_device *dev;
+
+ dev = ip_dev_find(_net, cm_id->remote_addr.sin_addr.s_addr);
+ if (!dev)
+ return 0;
+ dev_put(dev);
+ return 1;
+}
+
int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
{
int err = 0;
@@ -1791,6 +1802,11 @@ int iwch_connect(struct iw_cm_id *cm_id, struct
iw_cm_conn_param *conn_param)
struct iwch_ep *ep;
struct rtable *rt;
+ if (is_loopback_dst(cm_id)) {
+ err = -ENOSYS;
+ goto out;
+ }
+
ep = alloc_ep(sizeof(*ep), GFP_KERNEL);
if (!ep) {
printk(KERN_ERR MOD "%s - cannot alloc ep.\n", __FUNCTION__);
--
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: IO queueing and complete affinity w/ threads: Some results
Back on the 32-way, in this set of tests we're running 12 disks spread out through the 8 cells of the 32-way. Each disk will have an Ext2 FS placed on it, a clean Linux kernel source untar()ed onto it, then a full make (-j4) and then a make clean performed. The 12 series are done in parallel - so each disk will have: mkfs tar x make make clean performed. This was performed ten times, and the overall averages are presented below - note this is Jens' original patch sequence NOT the kthread one (those results available tomorrow, hopefully). mkfsMin Avg Max Std Dev - --- --- --- --- q0.c0.rq0 17.814 30.322 33.263 4.551 q0.c0.rq1 17.540 30.058 32.885 4.321 q0.c1.rq0 17.770 31.328 32.958 3.121 q1.c0.rq0 17.907 31.032 32.767 3.515 q1.c1.rq0 16.891 30.319 33.097 4.624 untar Min Avg Max Std Dev - --- --- --- --- q0.c0.rq0 19.747 21.971 26.292 1.215 q0.c0.rq1 19.680 22.365 36.395 2.010 q0.c1.rq0 18.823 21.390 24.455 0.976 q1.c0.rq0 18.433 21.500 23.371 1.009 q1.c1.rq0 19.414 21.761 34.115 1.378 makeMin Avg Max Std Dev - --- --- --- --- q0.c0.rq0 527.418 543.296 552.030 5.384 q0.c0.rq1 526.265 542.312 549.477 5.467 q0.c1.rq0 528.935 544.940 553.823 4.746 q1.c0.rq0 529.432 544.399 553.212 5.166 q1.c1.rq0 527.638 543.577 551.323 5.478 clean Min Avg Max Std Dev - --- --- --- --- q0.c0.rq0 16.962 20.308 33.775 3.179 q0.c0.rq1 17.436 20.156 29.370 3.097 q0.c1.rq0 17.061 20.111 31.504 2.791 q1.c0.rq0 16.745 20.247 29.327 2.953 q1.c1.rq0 17.346 20.316 31.178 3.283 Hopefully, the first column is self-explanatory - these are the settings applied to the queue_affinity, completion_affinity and rq_affinity tunables. Due to the fact that the standard deviations are so large coupled with the very close average results, I'm not seeing anything in this set of tests to favor any of the combinations... As noted, I will be having the machine run the kthreads-variant of the patch stream tonight, and then I have to go back and run a non-patched kernel to see if there are any /regressions/. Alan -- 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: [-mm PATCH] register_memory/unregister_memory clean ups
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > + /*
> > > +* Its ugly, but this is the best I can do - HELP !!
> > > +* We don't know where the allocations for section memmap and usemap
> > > +* came from. If they are allocated at the boot time, they would come
> > > +* from bootmem. If they are added through hot-memory-add they could
> > > be
> > > +* from sla or vmalloc. If they are allocated as part of hot-mem-add
> > > +* free them up properly. If they are allocated at boot, no easy way
> > > +* to correctly free them :(
> > > +*/
> > > + if (usemap) {
> > > + if (PageSlab(virt_to_page(usemap))) {
> > > + kfree(usemap);
> > > + if (memmap)
> > > + __kfree_section_memmap(memmap, nr_pages);
> > > + }
> > > + }
> > > +}
> >
> > Do what we did with the memmap and store some of its origination
> > information in the low bits.
>
> Hmm. my understand of memmap is limited. Can you help me out here ?
Never mind. That was a bad suggestion. I do think it would be a good
idea to mark the 'struct page' of ever page we use as bootmem in some
way. Perhaps page->private? Otherwise, you can simply try all of the
possibilities and consider the remainder bootmem. Did you ever find out
if we properly initialize the bootmem 'struct page's?
Please have mercy and put this in a helper, first of all.
static void free_usemap(unsigned long *usemap)
{
if (!usemap_
return;
if (PageSlab(virt_to_page(usemap))) {
kfree(usemap)
} else if (is_vmalloc_addr(usemap)) {
vfree(usemap);
} else {
int nid = page_to_nid(virt_to_page(usemap));
bootmem_fun_here(NODE_DATA(nid), usemap);
}
}
right?
> I was trying to use free_bootmem_node() to free up the allocations,
> but I need nodeid from which allocation came from :(
How is this any different from pfn_to_nid() on the thing? Or, can you
not use that because we never init'd the bootmem 'struct page's?
If so, I think the *CORRECT* fix is to give the bootmem areas real
struct pages, probably at boot-time.
-- Dave
--
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: [REGRESSION]fan turns at highspeed after suspend2ram
Am Dienstag, den 12.02.2008, 01:13 +0100 schrieb Rafael J. Wysocki:
> Since _GTS and _BFS don't seem to be defined in your box's BIOS, please
> try to apply the appended patch on top of the revert and see if that breaks
> things again.
>
> Thanks,
> Rafael
>
> ---
> drivers/acpi/hardware/hwsleep.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
> ===
> --- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
> +++ linux-2.6/drivers/acpi/hardware/hwsleep.c
> @@ -199,11 +199,6 @@ acpi_status acpi_enter_sleep_state_prep(
> return_ACPI_STATUS(status);
> }
>
> - status = acpi_evaluate_object(NULL, METHOD_NAME__GTS, _list, NULL);
> - if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> - return_ACPI_STATUS(status);
> - }
> -
> /* Setup the argument to _SST */
>
> switch (sleep_state) {
> @@ -554,12 +549,6 @@ acpi_status acpi_leave_sleep_state(u8 sl
> ACPI_EXCEPTION((AE_INFO, status, "During Method _SST"));
> }
>
> - arg.integer.value = sleep_state;
> - status = acpi_evaluate_object(NULL, METHOD_NAME__BFS, _list, NULL);
> - if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> - ACPI_EXCEPTION((AE_INFO, status, "During Method _BFS"));
> - }
> -
> /*
>* GPEs must be enabled before _WAK is called as GPEs
>* might get fired there
Yes, that's it. This patch breaks things again.
Thanks
Mirco
--
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: BTRFS only works with PAGE_SIZE <= 4K
On Tuesday 12 February 2008, David Miller wrote: > From: Chris Mason <[EMAIL PROTECTED]> > Date: Wed, 6 Feb 2008 12:00:13 -0500 > > > So, here's v0.12. > > Any page size larger than 4K will not work with btrfs. All of the > extent stuff assumes that PAGE_SIZE <= sectorsize. Yeah, there is definitely clean up to do in that area. > > I confirmed this by forcing mkfs.btrfs to use an 8K sectorsize on > sparc64 and I was finally able to successfully mount a partition. Nice > > With 4K there are zero's in the root tree node header, because it's > extent's location on disk is at a sub-PAGE_SIZE multiple and the > extent code doesn't handle that. > > You really need to start validating this stuff on other platforms. > Something that isn't little endian and something that doesn't use 4K > pages. I'm sure you have some powerpc parts around somewhere. :) Grin, I think around v0.4 I grabbed a ppc box for a day and got things working. There has been some churn since then... My first prio is the newest set of disk format changes, and then I'll sit down and work on stability on a bunch of arches. > > Anyways, here is a patch for the kernel bits which fixes most of the > unaligned accesses on sparc64. Many thanks, I'll try these out here and push them into the tree. -chris -- 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: [-mm PATCH] register_memory/unregister_memory clean ups
On Tue, 2008-02-12 at 13:57 -0800, Dave Hansen wrote:
> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> >
> > +static void __remove_section(struct zone *zone, unsigned long
> > section_nr)
> > +{
> > + if (!valid_section_nr(section_nr))
> > + return;
> > +
> > + unregister_memory_section(__nr_to_section(section_nr));
> > + sparse_remove_one_section(zone, section_nr);
> > +}
>
> I do think passing in a mem_section* here is highly superior. It makes
> it impossible to pass a pfn in and not get a warning.
>
Only problem is, I need to hold pgdat_resize_lock() if pass *ms.
If I don't hold the resize_lock, I have to re-evaluate. And also,
I need to pass section_nr for decoding the mem_map anyway :(
Thanks,
Badari
--
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/
[PATCH] timeconst.pl: correct reversal of USEC_TO_HZ and HZ_TO_USEC
The USEC_TO_HZ and HZ_TO_USEC constant sets were mislabelled, with
seriously incorrect results. This among other things manifested
itself as cpufreq not working when a tickless kernel was configured.
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
---
kernel/timeconst.pl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
index 62b1287..4146803 100644
--- a/kernel/timeconst.pl
+++ b/kernel/timeconst.pl
@@ -339,7 +339,7 @@ sub output($@)
print "\n";
foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ',
- 'USEC_TO_HZ','HZ_TO_USEC') {
+ 'HZ_TO_USEC','USEC_TO_HZ') {
foreach $bit (32, 64) {
foreach $suf ('MUL', 'ADJ', 'SHR') {
printf "#define %-23s %s\n",
--
1.5.3.8
--
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: Demand paging for memory regions (was Re: MMU Notifiers V6)
Roland Dreier wrote: [Adding [EMAIL PROTECTED] to get the IB/RDMA people involved] This thread has patches that add support for notifying drivers when a process's memory map changes. The hope is that this is useful for letting RDMA devices handle registered memory without pinning the underlying pages, by updating the RDMA device's translation tables whenever the host kernel's tables change. Is anyone interested in working on using this for drivers/infiniband? I am interested in participating, but I don't think I have enough time to do this by myself. I don't have time, although it would be interesting work! Also, at least naively it seems that this is only useful for hardware that has support for this type of demand paging, and can handle not-present pages, generating interrupts for page faults, etc. I know that Mellanox HCAs should have this support; are there any other devices that can do this? Chelsio's T3 HW doesn't support this. Steve. -- 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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, J. Bruce Fields wrote: > > So as a result, some *random* commit that was actually fine on its own has > > now become a bug, just because it was re-written. > > If there was a "fundamental thing that didn't cause a conflict", then > the two trees in question probably didn't touch the same code, so would > probably merge cleanly, for the same reason that one rebased onto the > other cleanly. But depending on what the "fundamental thing" was, the > merge might still introduce the same bug, right? Absolutely. But if you do a true merge, the bug is clearly in the merge (automatedly clean or not), and the blame is there too. IOW, you can blame me for screwing up. Now, I will say "oh, me bad, I didn't realize how subtle the interaction was", so it's not like I'll be all that contrite, but at least it's obvious where the blame lies. In contrast, when you rebase, the same problem happens, but now a totally innocent commit is blamed just because it happened to no longer work in the location it was not tested in. The person who wrote that commit, the people who tested it and said it works, all that work is now basically worthless: the testing was done with another version, the original patch is bad, and the history and _reason_ for it being bad has been lost. And there's literally nothing left to indicate the fact that the patch and the testing _used_ to be perfectly valid. That may not sound like such a big deal, but what does that make of code review and tested-by, and the like? It just makes a mockery of trying to do a good job testing any sub-trees, when you know that eventually it will all quite possibly be pointless, and the fact that maybe the networking tree was tested exhaustively is all totally moot, because in the end the stuff that hit the main tree is something else altogether? I don't know about you, but I'd personally be really disappointed if it happened to me, and I felt that I did a really good job as a submaintainer. I'd also feel that the source control management sucked. Contrast that to the case where somebody simply does a merge error. The original work doesn't lose it's validity - so the original maintainer hasn't lost anything. And quite frankly, even the person who "screwed up" with the merge hasn't really done anything bad: these things _do_ happen. So bugs happen; not big deal. But the fact that the bugs are correctly attributed - or rather, not mis-attributed to somebody blameless - that _is_ a big deal. It's not like I will guarantee that all my manual merges are always 100% correct, much less try to guarantee that no subtle merge issue can make things not work even if it all merged totally cleanly. That isn't my point. And others will make merge mistakes too. But the people they merged from will not be blamed. So just the fact that the right commit gets blamed when somebody does a "git bisect" is I think a big issue. It's just fundamentally more fair to everybody. And it means that the people who push their work to me can really choose to stand behind it, knowing that whatever happens, their work won't get diluted by bad luck or others' incompetence. And no, maybe most people don't feel things like that matters. But I do think it's important. Linus -- 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: Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: On Tue, Feb 12, 2008 at 01:14:04PM -0800, H. Peter Anvin wrote: Are you sure that build matches the bug report? urrgs right sorry, the posted vmlinux is a newer 2.6.24-git22 and not Version: 2.6.24-3 The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa will rebuild aboves. Okay, the faulting instruction is the following: c0383360: 0f 1f 40 00 nopl 0x0(%eax) The Crusoe code morphing software apparently doesn't recognize these "long noops", and (presumably) the rest of the hinting NOOP group. gcc didn't use to generate them, and Crusoe/Efficeon generally do not benefit from code alignment anyway. I suspect the best thing to do is to use either a 586 kernel or build a dedicated Crusoe kernel without code alignment. -hpa -- 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 00/18] ide: warm-plug support for IDE devices and other goodies
On Tuesday 12 February 2008, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > >
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead
> > > of
> > > [un]registering IDE interface) [ it is the main reason for spamming PPC
> > > ML ]
> >
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
> >
> > I'll have a look & test next week hopefully.
>
> Also, the above would have the advantage of not relying on drivers/ide
> infrastructure, and thus working with libata (once somebody has ported
> pmac ide to libata).
Neither of these things exist at the moment so lets stick to the existing
code which is scheduled for 2.6.26 and which finally allows removal of ppc
specific ide hacks from arch/{powerpc,ppc} (500 LOC gone, patches to be
posted this week), not to mention other nice changes in the future...
Thanks,
Bart
--
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: multiple drivers, single device (was Re: Announce: Linux-next (Or Andrew's dream :-)))
On Tue, Feb 12, 2008 at 10:30:04AM -0800, Linus Torvalds wrote: > > > On Tue, 12 Feb 2008, Jeff Garzik wrote: > > > Greg KH wrote: > > > The work I'm doing here is for stupid PCI firmware engineers, who have > > > created devices that are different things, all bound up under the same > > > PCI device. I'm thinking of watchdog timers and random number > > > generator and i2c controller on the same PCI device, or even the more > > > basic, frame buffer and DRM access to the same PCI video device. > > > > Yes, that has a known solution: have your driver register i2c, rng, > > watchdog, > > etc. functions. > > > > Works just fine inside today's infrastructure, no changes needed. > > Indeed. If you have a multi-function device that shows up as a single PCI > function, just make it have its own "private bus", and make it show up as > a "devices within a device". That's how I first tried to do this (old pci-piggy patches in -mm were a result of this...). But, we have the issue of the foolish-in-retrospect sysdev devices. They are an example of "multiple drivers per device" type thing. To clean them up properly, they need to move to the general 'struct device' and if that is going to already support the one-to-many model, well, then any PCI implementation of such an internal bus can also use the same code. This is a lot of handwaving right now, let me go work on some code and see how it turns out. Don't worry, I'll expect a lot of review cycles :) thanks, greg k-h -- 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: currently active Linux kernel versions
On Feb 12, 2008 4:18 PM, Ferenc Wagner <[EMAIL PROTECTED]> wrote: > Xavier Bestel <[EMAIL PROTECTED]> writes: > > > On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > > > >> which are the "currently active Linux kernel versions" at any point in > >> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. > >> Or more precisely: which are the "stable" versions I can depend on for > >> a more or less critical server, those that have active security > >> support or receive at least critical bugfixes? I know about the > >> 2.6.2[34].y stable git trees, but I wonder how long will those receive > >> attention (that is, security fixes). Can I find a written policy > >> somewhere? > > > > The answer is at http://kernel.org/ > > Not quite, at least I can't find 2.6.23.y there, even though that > branch seems to be maintained... 2.6.16.x is still maintained (2.6.16.60 was recently released). 2.6.22.x is still maintained but Greg KH is apparently going to be ending his duties on it after the next release or so. There is some confusion as to whether Willy Tarreau will be taking on the 2.6.22.x tree once Greg is done, Willy?: http://lwn.net/Articles/268003/ http://kerneltrap.org/Linux/Stable_2.6_Branches 2.6.23.x and 2.6.24.x are obviously quite active for [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: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Greg KH wrote: > > Yes, I agree, there are lots of examples of this, but the overall > majority are reviewed by 2 people at least (or sure as hell should be, > maybe we need to bring into existance the "reviewed-by" marking to > ensure this.) Well, I don't really "review" any patches that come through Andrew. What I do is: - global search-and-replace Andrew's "acked-by:" with one that is both him and me (that way I make sure that I _only_ sign off on patches that he has signed off on!) - look through all the commit *messages* (but not patches). This sometimes involves also editing up grammar etc - some of those messages just make me wince - but it also tends to include things like adding commit one-liner information if only a git commit ID is mentioned etc. - and only for areas that I feel competent in, I look at the patches too. So, to take an example, when Andrew passes on uml patches that only touch arch/um and include/asm-um, my sign-off does not mean *any* kind of review at all. It's purely a sign that it's passed the sign-off requirements properly. When it comes to VM issues or other things, things are different, and I actually review the patch (and occasionally send it back with "nope, I'm not applying this"). But for stuff that comes through Andrew, that's probably less than a quarter of the patches. And I don't mark the ones I've reviewed specially in any way. And I suspect I'm not at all alone in this. People simply have maintainers they trust (and _need_ to trust in order to not become a bottleneck). Linus -- 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 0/8] Create and populate toplevel tests/ for kernel tests
Andrew Morton wrote: On Tue, 12 Feb 2008 11:44:52 -0500 Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Mon, Feb 11, 2008 at 04:14:52PM +0530, Ananth N Mavinakayanahalli wrote: The following series of patches create and populate the toplevel tests/ directory. This will henceforth be the place where all in-kernel tests live. All patches against 2.6.25-rc1 and are just code movement without any change in functionality. ACK to patches 1-7, and I agree with Ingo that the x86-specific test should stay under arch/x86. OK. But now is basically the worst time for me (or anyone else) to merge large code-motion changes like this, because they need to be carried for two months or more. alternatively, since it's just code motion and nothing more, it could just be done in 2.6.25-rc; in fact doing motion patches in the -rc2 window makes sense to me, that's the point where all external trees are the smallest, and it should be provably the same result.. so safe. -- 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: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written: > Hi, > > Is it a known problem? > Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1 > E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in > e1000e). > > Don't work by default. "pci=nomsi" fixes the problem. Probably the patch to enable msi bit on the host bridge(?) is still missing in mainline. I needed that patch to make msi work on my MCP51 system. -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V signature.asc Description: This is a digitally signed message part.
Re: xfs [_fsr] probs in 2.6.24.0
Linda Walsh wrote: > > David Chinner wrote: >> Filesystem bugs rarely hang systems hard like that - more likely is >> a hardware or driver problem. And neither of the lockdep reports >> below are likely to be responsible for a system wide, no-response >> hang. > --- > "Ish", the 32-bitter, has been the only hard-hanger. 4k stacks? -Eric -- 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/
E1000 (PCI-E) doesn't work on nforce430, MSI issue.
Hi, Is it a known problem? Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1 E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in e1000e). Don't work by default. "pci=nomsi" fixes the problem. 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: PRO/1000 PT Desktop Adapter (8086:10b9 subsystem 8086:1083) grep eth0 /proc/interrupts 20: 1945 1 IO-APIC-fasteoi eth0 (without "pci=nomsi": 221: 0 0 PCI-MSI-edge eth0) other devices of possible interest: 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) Additional details on request. -- Krzysztof Halasa -- 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] ide-scsi: do non-atomic pc->flags testing
On Tuesday 12 February 2008, Borislav Petkov wrote:
> commit 272976f0f5754707f9e41da315717a6eb8d9d536
> Author: Borislav Petkov <[EMAIL PROTECTED]>
> Date: Tue Feb 12 16:22:44 2008 +0100
>
> ide-scsi: do non-atomic pc->flags testing
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
>
> diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
> index 5ec421c..eb84cdc 100644
> --- a/drivers/scsi/ide-scsi.c
> +++ b/drivers/scsi/ide-scsi.c
> @@ -319,8 +319,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
> uptodate, int nrsecs)
> pc = opc;
> rq = pc->rq;
> pc->scsi_cmd->result = (CHECK_CONDITION << 1) |
> - ((test_bit(PC_TIMEDOUT,
> >flags)?DID_TIME_OUT:DID_OK) << 16);
> - } else if (test_bit(PC_TIMEDOUT, >flags)) {
> + (((pc->flags & PC_TIMEDOUT) ?
> + DID_TIME_OUT :
> + DID_OK) << 16);
> + } else if (pc->flags & PC_TIMEDOUT) {
How's about renaming flag defines to PC_FLAG_* at the same time
(like it was done for other ATAPI drivers)?
Otherwise looks good.
--
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] ide-floppy: rename end_request handler properly
On Tuesday 12 February 2008, Borislav Petkov wrote: > commit 48f9b88d491aa478ffcf21e2f523e3665db0770b > Author: Borislav Petkov <[EMAIL PROTECTED]> > Date: Tue Feb 12 09:42:19 2008 +0100 > > ide-floppy: rename end_request handler properly > > mv idefloppy_do_end_request -> idefloppy_end_request as is the case with > ide-cd > > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> applied -- 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: Bug#464962: immediate crash on boot on TM5800
On Tue, Feb 12, 2008 at 01:14:04PM -0800, H. Peter Anvin wrote: > > Are you sure that build matches the bug report? urrgs right sorry, the posted vmlinux is a newer 2.6.24-git22 and not Version: 2.6.24-3 > The EIP given falls inside the .data segment of that kernel, > specifically inside the symbol init_task. > > -hpa will rebuild aboves. -- 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 00/18] ide: warm-plug support for IDE devices and other goodies
On Tue, 2008-02-12 at 21:41 +, Alan Cox wrote: > On Wed, 13 Feb 2008 08:04:07 +1100 > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote: > > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > - couple of fixes and preparatory patches > > > > > > > > - rework of PowerMac media-bay support ([un]register IDE devices > > > > instead of > > > > [un]registering IDE interface) [ it is the main reason for spamming > > > > PPC ML ] > > > > > > Interesting... I was thinking about doing a full remove of the device at > > > a higher level instead but I suppose what you propose is easier. > > > > > > I'll have a look & test next week hopefully. > > > > Also, the above would have the advantage of not relying on drivers/ide > > infrastructure, and thus working with libata (once somebody has ported > > pmac ide to libata). > > Unfortunately you need a degree in dentistry to open a Macintosh up and > fix it otherwise we would have support by now. Heh :-) Recent powermacs are trivial to open ! But yeah, I do need to produce a driver for libata one of these days. On my todo list ... Cheers, Ben. -- 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: xfs [_fsr] probs in 2.6.24.0
On Tue, Feb 12, 2008 at 01:02:05PM -0800, Linda Walsh wrote:
> David Chinner wrote:
> >Perhaps by running xfs_fsr manually you could reproduce the
> >problem while you are sitting in front of the machine...
>
> Um...yeah, AND with multiple "cp's of multi-gig files
> going on at same time, both local, by a sister machine via NFS,
> and and a 3rd machine tapping (not banging) away via CIFS.
> These were on top of normal server duties. Whenever I stress
> it on *purpose* and watch it, works fine. GRRRI HATE
> THAT!!!
I feel your pain.
> The file system(s) going "offline" due
> to xfs-detected filesystem errors has only happened *once* on
> asa, the 64-bit machine. It's a fairly new machine w/o added
> hardware -- but this only happened in 2.24.0 when I added the
> tickless clock option, which sure seems like a remote possibility for
> causing an xfs error, but could be.
Well, tickless is new and shiny and I doubt anyone has done
much testing with XFS on tickless kernels. Still, if that's a new
config option you set, change it back to what you had for .23 on
that hardware and try again.
> >Looking at it in terms of i_mutex, other filesystems hold
> >i_mutex over dio_get_page() (all those that use DIO_LOCKING)
> >so question is whether we are allowed to take the i_mutex
> >in ->release. I note that both reiserfs and hfsplus take
> >i_mutex in ->release as well as use DIO_LOCKING, so this
> >problem is not isolated to XFS.
> >
> >However, it would appear that mmap_sem -> i_mutex is illegal
> >according to the comment at the head of mm/filemap.c. While we are
> >not using i_mutex in this case, the inversion would seem to be
> >equivalent in nature.
> >
> >There's not going to be a quick fix for this.
>
> What could be the consequences of this locking anomaly?
If you have a multithreaded application that mixes mmap and
direct I/O, and you have a simultaneous munmap() call and
read() to the same file, you might be able to deadlock access
to that file. However, you'd have to be certifiably insane
to write an application that did this (mix mmap and direct I/O
to the same file at the same time), so I think exposure is
pretty limited.
> I.e., for example, in NFS, I have enabled "allow direct I/O on NFS
> files".
That's client side direct I/O, which is not what the server
does. Client side direct I/O results in synchronous buffered
I/O on the server, which will thrash your disks pretty hard.
The config option help does warn you about this. ;)
> >And the other one:
> >
> >>Feb 7 02:01:50 kern:
> >>---
> >>Feb 7 02:01:50 kern: xfs_fsr/6313 is trying to acquire lock:
> >>Feb 7 02:01:50 kern: (&(>i_lock)->mr_lock/2){}, at:
> >>[] xfs_ilock+0x82/0xc0
> >>Feb 7 02:01:50 kern:
> >>Feb 7 02:01:50 kern: but task is already holding lock:
> >>Feb 7 02:01:50 kern: (&(>i_iolock)->mr_lock/3){--..}, at:
> >>[] xfs_ilock+0xa5/0xc0
> >>Feb 7 02:01:50 kern:
> >>Feb 7 02:01:50 kern: which lock already depends on the new lock.
> >
> >Looks like yet another false positive. Basically we do this
> >in xfs_swap_extents:
> >
> > inode A: i_iolock class 2
> > inode A: i_ilock class 2
> > inode B: i_iolock class 3
> > inode B: i_ilock class 3
> > .
> > inode A: unlock ilock
> > inode B: unlock ilock
> > .
> >>inode A: ilock class 2
> > inode B: ilock class 3
> >
> >And lockdep appears to be complaining about the relocking of inode A
> >as class 2 because we've got a class 3 iolock still held, hence
> >violating the order it saw initially. There's no possible deadlock
> >here so we'll just have to add more hacks to the annotation code to make
> >lockdep happy.
>
> Is there a reason to unlock and relock the same inode while
> the level 3 lock is held -- i.e. does 'unlocking ilock' allow some
> increased 'throughput' for some other potential process to access
> the same inode?
It prevents a single thread deadlock when doing transaction reservation.
i.e. the process of setting up a transaction can require the ilock
to be taken, and hence we have to drop it before and pick it back up
after the transaction reservation.
We hold on to the iolock to prevent the inode from having new I/O
started while we do the transaction reservation, so it's in the
same state after the reservation as it was before
We have to hold both locks to guarantee exclusive access to the
inode, so once we have the reservation we need to pick the ilocks
back up. The way we do it here does not violate lock ordering at all
(iolock before ilock on a single inode, and ascending inode number
order for multiple inodes), but lockdep is not smart enough to know
that. Hence we need more complex annotations to shut it up.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: [-mm PATCH] register_memory/unregister_memory clean ups
On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
>
> +static void __remove_section(struct zone *zone, unsigned long
> section_nr)
> +{
> + if (!valid_section_nr(section_nr))
> + return;
> +
> + unregister_memory_section(__nr_to_section(section_nr));
> + sparse_remove_one_section(zone, section_nr);
> +}
I do think passing in a mem_section* here is highly superior. It makes
it impossible to pass a pfn in and not get a warning.
-- Dave
--
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] Execute tasklets in the same order they were queued
On Mon, 11 Feb 2008 16:28:13 -0600 Olof Johansson <[EMAIL PROTECTED]> wrote: > I noticed this when looking at an openswan issue. Openswan (ab?)uses > the tasklet API to defer processing of packets in some situations, > with one packet per tasklet_action(). I started noticing sequences of > reverse-ordered sequence numbers coming over the wire, since new tasklets > are always queued at the head of the list but processed sequentially. > > Convert it to instead append new entries to the tail of the list. As an > extra bonus, the splicing code in takeover_tasklets() no longer has to > iterate over the list. kernel/softirq.c: In function 'takeover_tasklets': kernel/softirq.c:597: error: 'struct tasklet_head' has no member named 'next' kernel/softirq.c:603: error: 'struct tasklet_head' has no member named 'next' kernel/softirq.c:588: warning: unused variable 'i' -- 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/
[PATCH] Add MS_BIND_FLAGS mount flag
From: Paul Menage <[EMAIL PROTECTED]>
Add a new mount() flag, MS_BIND_FLAGS.
MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags
from the arguments passed to mount() rather than from the source
mountpoint.
This flag allows you to create a bind mount with the desired per-mount
flags in a single operation, rather than having to do a bind mount
followed by a remount, which is fiddly and can block for non-trivial
periods of time (on sb->s_umount?).
For recursive bind mounts, only the root of the tree being bound
inherits the per-mount flags from the mount() arguments; sub-mounts
inherit their per-mount flags from the source tree as usual.
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
fs/namespace.c | 36 +---
include/linux/fs.h |2 ++
2 files changed, 27 insertions(+), 11 deletions(-)
Index: 2.6.24-mm1-bindflags/fs/namespace.c
===
--- 2.6.24-mm1-bindflags.orig/fs/namespace.c
+++ 2.6.24-mm1-bindflags/fs/namespace.c
@@ -512,13 +512,13 @@ static struct vfsmount *skip_mnt_tree(st
}
static struct vfsmount *clone_mnt(struct vfsmount *old, struct dentry *root,
- int flag)
+ int flag, int mnt_flags)
{
struct super_block *sb = old->mnt_sb;
struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
if (mnt) {
- mnt->mnt_flags = old->mnt_flags;
+ mnt->mnt_flags = mnt_flags;
atomic_inc(>s_active);
mnt->mnt_sb = sb;
mnt->mnt_root = dget(root);
@@ -1095,8 +1095,9 @@ static int lives_below_in_same_fs(struct
}
}
-struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
- int flag)
+static struct vfsmount *
+__copy_tree(struct vfsmount *mnt, struct dentry *dentry,
+ int flag, int mnt_flags)
{
struct vfsmount *res, *p, *q, *r, *s;
struct nameidata nd;
@@ -1104,7 +1105,7 @@ struct vfsmount *copy_tree(struct vfsmou
if (!(flag & CL_COPY_ALL) && IS_MNT_UNBINDABLE(mnt))
return NULL;
- res = q = clone_mnt(mnt, dentry, flag);
+ res = q = clone_mnt(mnt, dentry, flag, mnt_flags);
if (!q)
goto Enomem;
q->mnt_mountpoint = mnt->mnt_mountpoint;
@@ -1126,7 +1127,7 @@ struct vfsmount *copy_tree(struct vfsmou
p = s;
nd.path.mnt = q;
nd.path.dentry = p->mnt_mountpoint;
- q = clone_mnt(p, p->mnt_root, flag);
+ q = clone_mnt(p, p->mnt_root, flag, p->mnt_flags);
if (!q)
goto Enomem;
spin_lock(_lock);
@@ -1146,6 +1147,11 @@ Enomem:
}
return NULL;
}
+struct vfsmount *copy_tree(struct vfsmount *mnt, struct dentry *dentry,
+ int flag)
+{
+ return __copy_tree(mnt, dentry, flag, mnt->mnt_flags);
+}
struct vfsmount *collect_mounts(struct vfsmount *mnt, struct dentry *dentry)
{
@@ -1320,7 +1326,8 @@ static int do_change_type(struct nameida
/*
* do loopback mount.
*/
-static int do_loopback(struct nameidata *nd, char *old_name, int recurse)
+static int do_loopback(struct nameidata *nd, char *old_name, int flags,
+ int mnt_flags)
{
struct nameidata old_nd;
struct vfsmount *mnt = NULL;
@@ -1342,10 +1349,15 @@ static int do_loopback(struct nameidata
goto out;
err = -ENOMEM;
- if (recurse)
- mnt = copy_tree(old_nd.path.mnt, old_nd.path.dentry, 0);
+ /* Use the source mount flags unless the user passed MS_BIND_FLAGS */
+ if (!(flags & MS_BIND_FLAGS))
+ mnt_flags = old_nd.path.mnt->mnt_flags;
+ if (flags & MS_REC)
+ mnt = __copy_tree(old_nd.path.mnt, old_nd.path.dentry, 0,
+ mnt_flags);
else
- mnt = clone_mnt(old_nd.path.mnt, old_nd.path.dentry, 0);
+ mnt = clone_mnt(old_nd.path.mnt, old_nd.path.dentry, 0,
+ mnt_flags);
if (!mnt)
goto out;
@@ -1874,7 +1886,9 @@ long do_mount(char *dev_name, char *dir_
retval = do_remount(, flags & ~MS_REMOUNT, mnt_flags,
data_page);
else if (flags & MS_BIND)
- retval = do_loopback(, dev_name, flags & MS_REC);
+ retval = do_loopback(, dev_name,
+flags & (MS_REC | MS_BIND_FLAGS),
+mnt_flags);
else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
retval = do_change_type(, flags);
else if (flags & MS_MOVE)
Index: 2.6.24-mm1-bindflags/include/linux/fs.h
Re: currently active Linux kernel versions
Xavier Bestel <[EMAIL PROTECTED]> writes: > On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote: > >> which are the "currently active Linux kernel versions" at any point in >> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29. >> Or more precisely: which are the "stable" versions I can depend on for >> a more or less critical server, those that have active security >> support or receive at least critical bugfixes? I know about the >> 2.6.2[34].y stable git trees, but I wonder how long will those receive >> attention (that is, security fixes). Can I find a written policy >> somewhere? > > The answer is at http://kernel.org/ Not quite, at least I can't find 2.6.23.y there, even though that branch seems to be maintained... -- Thanks, Feri. -- 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: Bug#464962: immediate crash on boot on TM5800
maximilian attems wrote: On Tue, Feb 12, 2008 at 12:32:27PM -0800, H. Peter Anvin wrote: INT 6 is #UD, undefined instruction. If you could send me a copy of your vmlinux file (not bzImage), it would speed things up. cp -l src/linux-2.6-2.6.24/debian/build/build_i386_none_686/vmlinux ~/public_html/ http://charm.itp.tuwien.ac.at/~mattems/ Are you sure that build matches the bug report? The EIP given falls inside the .data segment of that kernel, specifically inside the symbol init_task. -hpa -- 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: Documentation about sysfs/procfs entries
On 2/13/08, Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote: > > > Hi all... > > > > Here's my idea: what if we collaborate to extend and make the kernel > > documentation better? I have done (slow) start by editing profile= > > kernel param. It's not accepted by Adrian Bunk, but at least I did it. > > Feedback? > > Adrian is no longer the trivial patch maintainer. > Did you send the patch to [EMAIL PROTECTED] ? > > Any doc additions or improvements would be appreciated. > I'll be glad to help get them merged... > > --- > ~Randy > Ok, I will do something.thanks for the info. -- 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: [git pull for -mm] CPU isolation extensions (updated2)
Steven Rostedt wrote: > On Tue, 12 Feb 2008, Peter Zijlstra wrote: >>> Rusty - Stop machine. >>>After doing a bunch of testing last three days I actually downgraded >>> stop machine >>>changes from [highly experimental] to simply [experimental]. Pleas see >>> this thread >>>for more info: http://marc.info/?l=linux-kernel=120243837206248=2 >>>Short story is that I ran several insmod/rmmod workloads on live >>> multi-core boxes >>>with stop machine _completely_ disabled and did no see any issues. Rusty >>> did not get >>>a chance to reply yet, I hopping that we'll be able to make "stop >>> machine" completely >>>optional for some configurations. > > This part really scares me. The comment that you say you have run several > insmod/rmmod workloads without kstop_machine doesn't mean that it is still > safe. A lot of races that things like this protect may only happen under > load once a month. But the fact that it happens at all is reason to have > the protection. > > Before taking out any protection, please analyze it in detail and report > your findings why something is not needed. Not just some general hand > waving and "it doesn't crash on my box". Sure. I did not say lets disable it. I was hopping we could and I wanted to see what Rusty Russell has to say about this. > Besides that, kstop_machine may be used by other features that can have an > impact. Yes it is. I missed a few. Nick and Dave already pointed out CPU hotplug. I looked around and found more users. So disabling stop machine completely is definitely out. > Again, if you have a system that cant handle things like kstop_machine, > than don't do things that require a kstop_machine run. All modules should > be loaded, and no new modules should be added when the system is > performing critical work. I see no reason for disabling kstop_machine. I'm considering that option. So far it does not seem practical. At least the way we use those machines at this point. If we can prove that at least not halting isolation CPUs is safe that'd be better. Max -- 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/
