New serial driver for SC2681/SC2691 uarts. Older SNI RM400 machines are
using these chips for onboard serial ports.
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
Please apply for 2.6.25.
drivers/serial/Kconfig | 15 +
drivers/serial/Makefile |1 +
drivers/serial/sc26xx.c |
Hello,
Since I_SYNC was split out from I_LOCK, the concern in commit
4b89eed93e0fa40a63e3d7b1796ec1337ea7a3aa is not longer valid.
We should revert to the original behavior: in __writeback_single_inode(),
when we find an I_SYNC-ed inode and we're not doing a data-integrity sync,
skip writing
On Sun, 2 Dec 2007 21:33:23 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> On Saturday, 1 of December 2007, Pavel Machek wrote:
> > Hi!
> >
> > > 2.6.24-rc3-mm2 (which will be released if it boots on two more machines
> > > and
> > > if I stay awake) will say this during suspend-to-RAM
Andrew Morgan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
I think it is a good idea.
However, this module already have a feature to modify inheritable
capability set.
How
On 12/2/07, Thomas Tuttle <[EMAIL PROTECTED]> wrote:
> On Sun, 2 Dec 2007 19:43:16 +0300, "Cyrill Gorcunov"
> <[EMAIL PROTECTED]> said:
> > [Thomas Tuttle - Tue, Nov 27, 2007 at 03:43:57PM -0500]
> > | Hey.
> > |
> > | I'm using a git snapshot that gentoo distributed mere hours ago (so I'm
> > |
Bartlomiej Zolnierkiewicz wrote:
> On Saturday 01 December 2007, Rafael J. Wysocki wrote:
>
>> Subject : 2.6.24-rc1: pata_amd fails to detect 80-pin wire
>> Submitter: "Thomas Lindroth" <[EMAIL PROTECTED]>
>> References : http://lkml.org/lkml/2007/11/7/152
>>
Andi Kleen wrote:
Avi Kivity <[EMAIL PROTECTED]> writes:
[I really doubt there are that many of these; syscall
entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is
Not all the return value of __copy_from_user and
__put_user is checked.This patch fixed it.
Signed-off-by: Shi Weihua <[EMAIL PROTECTED]>
---
diff -x '*.o*' -urp linux-2.6.24-rc3-git6.orig/arch/ia64/kernel/signal.c
linux-2.6.24-rc3-git6/arch/ia64/kernel/signal.c
---
On Thu, Nov 29, 2007 at 03:53:23PM +0300, Evgeniy Polyakov wrote:
>
> Distributed storage documentation.
>
> Algorithms used in the system, userspace interfaces
> (sysfs dirs and files), design and implementation details
> are described here.
Can you give us a summary of how this differs from
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Haven't we been asking JVMs to use futexes or posix locking for years
> > and years now? [...]
>
> i'm curious, with what JVM was it tested and where's the source so i can
> fix their locking for
How about this issue now ?
--
View this message in context:
http://www.nabble.com/PROBLEM%3A--OOPSes-in-PREEMPT-SMP-for-AMD-Opteron-Dual-Core-with-Memhole-Mapping-tf55018.html#a14123663
Sent from the linux-kernel mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the
Hi.
I'm finding that recently kexec'ed kernels on PS3 will
panic on startup. It seems the trouble was introduced
with the ppc64 SPARSEMEM_VMEMMAP support. The problem
is the same when starting either new or old kernels:
2.6.24 -> 2.6.23 ok
2.6.24 -> 2.6.23 panic
2.6.24 -> 2.6.24 panic
These
Hi Alex-san,
On my system, hotplug slots themselves can be added, removed
and replaced with the ohter type of I/O box. The ACPI firmware
tells OS the presence of those slots using _STA method (That
is, it doesn't use 'LoadTable()' AML operator). On the other
hand, current pci_slot driver
Kenneth Howlett wrote:
The loadlin boot loader fails to boot 2.6.23 kernels.
I used msdos 6.22 in real mode, without himem.sys or any other memory
manager, without any tsrs; loadlin 1.6c; and kernel 2.6.23.1-42.fc8, which
is the install kernel for the fedora core 8 distribution. The normal
> Date: Sat, 1 Dec 2007 22:27:20 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: linux-kernel@vger.kernel.org
> Subject: Re: 2.6.23.9, make install doesn't work with grub anymore??
>
> On Sat, 1 Dec 2007 20:51:14 -0500
> Scott Noone wrote:
>
>>
>> Hello,
>>
>> I downloaded the
"Kay Sievers" <[EMAIL PROTECTED]> writes:
> That cruft is going away with the block patch in your tree.
And it doesn't matter because it is a separate mount anyway.
Although I have to admit I hadn't taken that mount into
account earlier.
Eric
--
To unsubscribe from this list: send the line
On Saturday 01 December 2007, Andrew Morton wrote:
> I have all these:
>
> spi-at25-driver-is-for-eeprom-not-flash.patch
I'd be tempted to merge that since it's documentation-only,
and I like to see such stuff merged ASAP. But otherwise
it's non-essential.
> spi-use-mutex-not-semaphore.patch
Michael Cree wrote:
> On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
> > On Sat, 01 Dec 2007 11:30:01 +1300
> > Michael Cree <[EMAIL PROTECTED]> wrote:
> >
> >> Bob Tracy wrote:
> >>> Here's
> >>> hoping someone else is seeing this or can replicate it in the
> >>> meantime.
> >>
> >> Snap.
>
On Sun, Dec 02, 2007 at 10:59:46PM +0100, Patrick McHardy wrote:
> Adrian Bunk wrote:
>> On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
>...
>> your statement has an interesting implication:
>>
>> Stuff like e.g. the EXPORT_SYMBOL(sk_alloc) predates the EXPORT_SYMBOL_GPL
>>
Alan Cox wrote:
Well, original C allowed you to do what you wanted with pointers (I used
to teach that back when K was "the" C manual). Now people which about
having pointers outside the array, which is a crock in practice, as long
as you don't actually /use/ an out of range value.
On Sun, 2 December 2007 22:19:00 +0100, Ingo Molnar wrote:
> * Jörn Engel <[EMAIL PROTECTED]> wrote:
>
> > Maybe one more thing: can you send me the config you used for the
> > setup above? I'd like to know whether qemu or my config is to blame.
>
> sure - attached.
After an eternity of
On Mon, 3 Dec 2007 01:07:41 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > We really need to get better diagnostics for the
> > bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to
> > get to the scenario where we have a more or less robust measure of
> > kernel quality (and we're
On Dec 2, 2007 11:53 PM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Sun, Dec 02, 2007 at 03:22:46PM -0700, Eric W. Biederman wrote:
> > Greg KH <[EMAIL PROTECTED]> writes:
> >
> > > On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
> > >> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]>
On Sun, Dec 02, 2007 at 03:22:46PM -0700, Eric W. Biederman wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
> >> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> >> ...
> >> > > and where is a detailed explaination on
> You license yours under the GPL, so they should respect the GPL.
>
> It sounds like we're back to where we were years ago. Didn't we already
> agree that EXPORT_SYMBOL_GPL was *NOT* a GPL-enforcement mechanism and had
> nothing to do with respecting the GPL? After all, if it s a GPL-enforcement
> We really need to get better diagnostics for the
> bad-kernel-behavior-that-is-seen-as-bug cases. If we ever want to get
> to the scenario where we have a more or less robust measure of kernel
> quality (and we're not all that far off for several cases), one thing
One measure to kernel quality
> > Then init_net needs to be not GPL limited. Sorry, we need to allow
> > non GPL network drivers. There is a fine line between keeping the
> Why - they aren't exactly likely to be permissible by law
Really? What law and/or what clause in the GPL says that derivative works
have to be licensed
On Sun, Dec 02, 2007 at 09:06:19AM -0800, Avuton Olrich wrote:
> Adding xfs to CC
>
> On Dec 2, 2007 9:02 AM, Avuton Olrich <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > 2.6.23.8 just crashed here, it had been up 8 days and suspended to
> > disk many times in those 8 days. The process that
> Delay accounting (or the /proc//sched fields that i added recently)
> only get updated once a task has finished its unreasonably long delay
> and has scheduled.
If it is stuck forever then you can just use sysrq-t
If it recovers delay accounting will catch it.
> detected_ this way. This is
The loadlin boot loader fails to boot 2.6.23 kernels.
I used msdos 6.22 in real mode, without himem.sys or any other memory
manager, without any tsrs; loadlin 1.6c; and kernel 2.6.23.1-42.fc8, which
is the install kernel for the fedora core 8 distribution. The normal loadlin
messages are
Hi!
> >Well... I'd really like to know what A/V people are trying to do.
> >
> >Indexing services are really different, and doable with recursive
> >m-time Jan is preparing...
> >
> m-time <=> modification time?
Yep.
> What am I preparing?
Not you, Jan Kara. Sorry.
On Dec 2 2007 22:56, Pavel Machek wrote:
>>
>> We probably want to hear related usages as well - what *besides*
>> A/V would be interested? Indexing services?
>
Indexing services would probably benefit much more from a
recursive-aware inotify, though that has its own sort of problems to
solve
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
Jiri Kosina wrote:
[ linux-usb-devel added to CC ]
On Sun, 2 Dec 2007, Mark Lord wrote:
Okay. I've got to leave the computer for a while now, so I'll post
again whenever I have something new here.
Thanks. To sum up this longish thread:
- 2.6.24-rcX exposes the problem with sometimes
On Sun, 2 Dec 2007 21:47:25 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Out of direct experience, 95% of the "too long delay" cases are
> > plain old bugs. The rest we can (and must!) convert to
> > TASK_KILLABLE or could
>
> I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs).
Bartlomiej Zolnierkiewicz wrote:
[PATCH] pata_amd/pata_via: de-couple programming of PIO/MWDMA and UDMA timings
* Don't program UDMA timings when programming PIO or MWDMA modes.
This has also a nice side-effect of fixing regression added by commit
681c80b5d96076f447e8101ac4325c82d8dce508
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > do you realize that more than 120 seconds TASK_UNINTERRUPTIBLE _is_
> > something that most humans consider as "buggy" in the overwhelming
> > majority of cases, regardless of the reason? Yes, there are and will
> > be some exceptions, but not
Greg KH <[EMAIL PROTECTED]> writes:
> On Sun, Dec 02, 2007 at 02:52:17PM +0800, rae l wrote:
>> On Dec 2, 2007 12:48 PM, Greg KH <[EMAIL PROTECTED]> wrote:
>> ...
>> > > and where is a detailed explaination on kern_mount? could someone give
>> > > some comments or documentation pointers on this?
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Until now users had little direct recourse to get such problems
> > fixed. (we had sysrq-t, but that included no real metric of how long
> > a task was
>
> Actually task delay accounting can measure this now. iirc someone had
> a latencytop based
On Sun, 2 Dec 2007 22:19:25 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > Until now users had little direct recourse to get such problems
> > fixed. (we had sysrq-t, but that included no real metric of how
> > long a task was
>
> Actually task delay accounting can measure this now. iirc
Hans Verkuil wrote:
On Sunday 02 December 2007 18:46, Richard Knutsson wrote:
Fix "warning: Using plain integer as NULL pointer".
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Remove a gcc-2.95 requirement.
NACK! The main v4l-dvb repository that contains this driver can
On Sun, 2 Dec 2007 23:00:04 +0100 (CET)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> [ nobody seems to have picked this up, resending. This is a fix for
> commit 8853c202b4 in Linus' tree ]
>
> From: Jiri Kosina <[EMAIL PROTECTED]>
>
> RTC: assure proper memory ordering with respect to
[ linux-usb-devel added to CC ]
On Sun, 2 Dec 2007, Mark Lord wrote:
> Okay. I've got to leave the computer for a while now, so I'll post
> again whenever I have something new here.
Thanks. To sum up this longish thread:
- 2.6.24-rcX exposes the problem with sometimes multiple clicks being
[ nobody seems to have picked this up, resending. This is a fix for
commit 8853c202b4 in Linus' tree ]
From: Jiri Kosina <[EMAIL PROTECTED]>
RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag
We must make sure that the RTC_DEV_BUSY flag has proper lock semantics,
i.e. that
Adrian Bunk wrote:
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
For all I care binary modules can break, but frankly I don't see
how encapsulating a couple of structures and pointers in a new
structure and adding a new argument to existing functions shifts
the decision
On Sun 2007-12-02 16:09:55, [EMAIL PROTECTED] wrote:
> On Sun, 02 Dec 2007 21:22:40 +0100, Pavel Machek said:
> > Well, if you only want to detect viruses _sometimes_, you can just
> > LD_PRELOAD your scanner.
>
> And for some use cases, that probably *is* the best answer..
I'd say so.
> > I
Em Mon, Dec 03, 2007 at 06:34:20AM +0900, Tetsuo Handa escreveu:
> Hello.
>
> Adrian Bunk wrote:
> > > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't
> > > know why.
> > That's due to the fact that my patch to remove this unused export from
> > slub was not yet applied...
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> do you realize that more than 120 seconds TASK_UNINTERRUPTIBLE _is_
> something that most humans consider as "buggy" in the overwhelming
> majority of cases, regardless of the reason? Yes, there are and will be
> some exceptions, but not nearly as
Hello.
Adrian Bunk wrote:
> > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know
> > why.
> That's due to the fact that my patch to remove this unused export from
> slub was not yet applied...
So, removing exports is intended thing?
> Where is the modular in-kernel
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 02, 2007 at 10:10:27PM +0100, Ingo Molnar wrote:
> > what if you considered - just for a minute - the possibility of this
> > debug tool being the thing that actually animates developers to fix such
> > long delay bugs that have bothered
On Sun, Dec 02, 2007 at 10:10:27PM +0100, Ingo Molnar wrote:
> what if you considered - just for a minute - the possibility of this
> debug tool being the thing that actually animates developers to fix such
> long delay bugs that have bothered users for almost a decade meanwhile?
Throwing
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote:
>
> to capture that trace i did not use -rt, i just patched latest -git
> with:
>
>
> http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch
>
> (this has your fixes included already)
>
>
On Sun, 2 December 2007 21:45:59 +0100, Ingo Molnar wrote:
>
> to capture a 1 second trace of what the system is doing. I think your
> troubles are due to running it within a qemu guest - that is not a
> typical utilization so you are on unchartered waters.
Looks like it. Guess I'll switch to
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Out of direct experience, 95% of the "too long delay" cases are plain
> > old bugs. The rest we can (and must!) convert to TASK_KILLABLE or could
>
> I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs). It
> would be pretty bad to
On Sun, 02 Dec 2007 21:22:40 +0100, Pavel Machek said:
> Well, if you only want to detect viruses _sometimes_, you can just
> LD_PRELOAD your scanner.
And for some use cases, that probably *is* the best answer..
> I guess the A/V people should describe what they are trying to do, as
> in
>
>
On Wed, 2007-11-28 at 10:54 -0800, Christoph Lameter wrote:
> > As far as I can see, after applying your series of patches, I end up
> > with an unbalanced #ifdef in include/asm-powerpc/percpu.h. I see 3
> > #ifdef/#ifndef, but only two #endifs. It needs another #endif after
> > the #endif /*
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree <[EMAIL PROTECTED]> wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get
On Sun, 02 Dec 2007 17:00:03 +0100, Holger Hoffstaette wrote:
> On Fri, 30 Nov 2007 10:26:54 -0800, Rick Jones wrote:
>
>> Could the corruption be seen in a tcpdump trace prior to transmission
>> (ie taken on the sender) or was it only seen after the data passed out
>> the NIC?
>
> I did the
Summary: I couldn't find any further responses confirming the patch
worked, so I thought I'd report that it does work for my case which
was very similar. See Below for details.
NOTE: I am not subscribed, so make sure I'm copied on any replies.
David CHANIAL wrote:
> Le Tuesday 04 September
> Out of direct experience, 95% of the "too long delay" cases are plain
> old bugs. The rest we can (and must!) convert to TASK_KILLABLE or could
I already pointed out a few cases (nfs, cifs, smbfs, ncpfs, afs).
It would be pretty bad to merge this patch without converting them to
* Jörn Engel <[EMAIL PROTECTED]> wrote:
> > oprofile helps if you can reliably reproduce the slowdown in a loop
> > or for a long amount of time, with lots of CPU utilization - and
> > then it's also lower overhead. The tracer can be used to capture
> > rare or complex events, and gives the
On Sun, Dec 02, 2007 at 09:03:56PM +0100, Patrick McHardy wrote:
> Ben Greear wrote:
>> Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any issues
here,
since they can just patch their kernels around any issues.
But it looks like
On Sun, 2 December 2007 21:07:22 +0100, Ingo Molnar wrote:
> * Jörn Engel <[EMAIL PROTECTED]> wrote:
>
> > Result looked like a livelock and finally convinced me to abandon the
> > latency tracer. Sorry, but it appears to be the right tool for the
> > wrong job.
>
> hm, we routinely use it in
On Sun, 2 Dec 2007, Oleg Nesterov wrote:
>
> exec() from the signal handler doesn't do sys_sigreturn(), so we don't unblock
> the signal, and it remains blocked after exec().
>
> Hmm. Is this linux bug, or application bug?
I think that's an application bug.
The kernel does the obvious (and
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > .. and it's even a tool to show where we missed making something
> > TASK_KILLABLE... anything that triggers from NFS and the like really
> > ought to be TASK_KILLABLE after all. This patch will point any
> > omissions out quite nicely without
Hi!
> > So what you are trying to do is 'application may never read bad
> > sequence of bits from disk', right?
>
> No, in many of the use cases, we're trying to do "if application reads certain
> specified sequences of bits from disk we know about it", which is subtly
> different. Often,
On Sunday, 2 of December 2007, Mark M. Hoffman wrote:
> Hi:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> [2007-12-01 00:51:40 +0100]:
> > On Saturday, 1 of December 2007, Rafael J. Wysocki wrote:
> > > On Friday, 30 of November 2007, Jiri Slaby wrote:
> > > > On 11/30/2007 11:15 PM, Jean Delvare
On Saturday, 1 of December 2007, Pavel Machek wrote:
> Hi!
>
> > 2.6.24-rc3-mm2 (which will be released if it boots on two more machines and
> > if I stay awake) will say this during suspend-to-RAM on the Vaio:
> >
> > [ 91.876445] Syncing filesystems ... done.
> > [ 92.382595] Freezing user
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > TASK_KILLABLE should be the right solution i think.
>
> .. and it's even a tool to show where we missed making something
> TASK_KILLABLE... anything that triggers from NFS and the like really
> ought to be TASK_KILLABLE after all. This patch
> .. and it's even a tool to show where we missed making something
> TASK_KILLABLE... anything that triggers from NFS and the like really
> ought to be TASK_KILLABLE after all. This patch will point any
> omissions out quite nicely without having to do any kind of destructive
> testing.
It would
* Jörn Engel <[EMAIL PROTECTED]> wrote:
> On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote:
> >
> > well what does the trace say, where do the delays come from? To get a
> > quick overview you can make tracing lighter weight by doing:
> >
> > echo 0 > /proc/sys/kernel/mcount_enabled
On Sun, 2 Dec 2007, Arjan van de Ven wrote:
> > This creates a lockdep violation; each rwsem in turn is locked while
> > the other is being held. However the only way this could lead to
> > deadlock would be if there was already a bug in the system Power
> > Management code (overlapping
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_compatible_node.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
On Sun, 2 Dec 2007 14:45:32 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> Ingo:
>
> I ran into a lockdep reporting issue just now with some new code
> under development. I think it's a false positive; the question is
> how best to deal with it.
>
> Here's the situation. The new code
> and I don't think you can mmap() a socket anyhow,
> right?
You can mmap packet sockets.
-Andi
--
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
Ben Greear wrote:
Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any
issues here,
since they can just patch their kernels around any issues.
But it looks like Eric has this one thought out well enough.
So you are saying all this is not a
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_node_by_type.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
iterator
From: Julia Lawall <[EMAIL PROTECTED]>
There should be an of_node_put when breaking out of a loop that iterates
using for_each_node_by_type.
This was detected and fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
identifier d;
type T;
expression e;
iterator
On Sun, 02 Dec 2007 14:44:48 -0500
[EMAIL PROTECTED] wrote:
> On Sat, 01 Dec 2007 08:43:32 GMT, Pavel Machek said:
>
> > So what you are trying to do is 'application may never read bad
> > sequence of bits from disk', right?
>
> No, in many of the use cases, we're trying to do "if application
>
From: Julia Lawall <[EMAIL PROTECTED]>
After using for_each_node_by_name, there is no need for of_node_put unless
there was a break in the loop body, as for_each_node_by_name does a
of_node_put on each of the elements it returns.
This was detected and fixed using the following semantic patch.
On Sun, 2 December 2007 16:47:46 +0100, Ingo Molnar wrote:
>
> well what does the trace say, where do the delays come from? To get a
> quick overview you can make tracing lighter weight by doing:
>
> echo 0 > /proc/sys/kernel/mcount_enabled
> echo 1 > /proc/sys/kernel/trace_syscalls
I
On Sun, 02 Dec 2007 13:51:04 GMT, Alan Cox said:
> On Sat, 1 Dec 2007 16:30:35 -0800
> > I spoke too soon earlier, ndiswrapper builds and loads against current
> > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again
> > I don't
> > give a damn, but the enterprise distro
Hi Linus,
Before rc4, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
This fixes the Thinkpad T61 OOPS regression due to the -rc3 thermal changes.
It also fixes a boot crash in the AML interpreter that has been with us forever,
but has recently
On Sat, 1 December 2007 21:59:31 +0200, Avi Kivity wrote:
>
> Object orientation in C leaves much to be desired; see the huge number
> of void pointers and container_of()s in the kernel.
While true, this isn't such a bad problem. A language really sucks when
it tries to disallow something
On Sunday 02 December 2007 18:46, Richard Knutsson wrote:
> Fix "warning: Using plain integer as NULL pointer".
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
> Remove a gcc-2.95 requirement.
NACK! The main v4l-dvb repository that contains this driver can also be
compiled on older systems.
On Sun, 02 Dec 2007 13:03:35 +0100, Christer Weinigel said:
> WARNING: no space between function name and open parenthesis '('
> #520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
> + list_for_each_entry (transfer, >transfers, transfer_list) {
>
> which I think is a bit bogus since it actually
Ingo:
I ran into a lockdep reporting issue just now with some new code under
development. I think it's a false positive; the question is how best
to deal with it.
Here's the situation. The new code runs during a system sleep (i.e.,
suspend or hibernation). Certain activities have to be
On Sat, 01 Dec 2007 08:43:32 GMT, Pavel Machek said:
> So what you are trying to do is 'application may never read bad
> sequence of bits from disk', right?
No, in many of the use cases, we're trying to do "if application reads certain
specified sequences of bits from disk we know about it",
Jiri Kosina wrote:
On Sun, 2 Dec 2007, Mark Lord wrote:
Right now it's double-clicking just about everything. If I unplug/replug
it, things behave for a while. Still want the HID_DEBUG output?
(rebooting shortly)
Yes, definitely. I currently don't have an idea what might be causing it,
On Sunday 02 December 2007 18:47, Richard Knutsson wrote:
> Remove the shadowing 'struct v4l2_chip_ident *chip', since it already
> exists and makes the if-statement useless.
>
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
Signed-off-by: Hans Verkuil <[EMAIL PROTECTED]>
Thanks,
On Sun, 2 Dec 2007 19:59:45 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > > this patch extends the soft-lockup detector to automatically
> > > detect hung TASK_UNINTERRUPTIBLE tasks. Such hung
Stephen Hemminger wrote:
Naw, enterprise (or any other) distro vendors shouldn't have any issues here,
since they can just patch their kernels around any issues.
But it looks like Eric has this one thought out well enough.
So you are saying all this is not a problem, fine.
Any affected
On Sun, 2 Dec 2007, Mark Lord wrote:
> Right now it's double-clicking just about everything. If I unplug/replug
> it, things behave for a while. Still want the HID_DEBUG output?
> (rebooting shortly)
Yes, definitely. I currently don't have an idea what might be causing it,
and I am unable to
Jiri Kosina wrote:
On Sun, 2 Dec 2007, Mark Lord wrote:
Here's a *single* button click (press/release quickly):
Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
Event: time 1196621063.620504, type 1
Linus, please pull the latest scheduler git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched.git
this includes a single commit: a revert of a revert :-/ It turns out
revert cfb5285660 went in by mistake (outside of sched.git). This commit
has been tested quite
Linus, please pull the latest x86 git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-x86.git
two kexec related hpet fixes from Ogawa Hirofumi. (the #ifdefs will be
eliminated later on, these are the tested patches for -rc4)
Thanks!
Ingo
On Sun, 2 Dec 2007, Mark Lord wrote:
> > Here's a *single* button click (press/release quickly):
> > Event: time 1196621063.612542, type 1 (Key), code 272 (LeftBtn), value 1
> > Event: time 1196621063.612553, type 0 (Reset), code 0 (Reset), value 0
> > Event: time 1196621063.620504, type 1 (Key),
On Sun, Dec 02, 2007 at 01:18:37PM +0200, Avi Kivity wrote:
> The following patchset fixes some bugs in KVM for the next 2.6.23.y stable
> release. Please apply.
I'm guessing that all of these are already upstream in Linus's tree?
If so, can you give me the git commit ids for them all if you
Avi Kivity <[EMAIL PROTECTED]> writes:
>
> [I really doubt there are that many of these; syscall
> entry/dispatch/exit, interrupt dispatch, context switch, what else?]
Networking, block IO, page fault, ... But only the fast paths in these
cases. A lot of the kernel is slow path code and could
Hi!
> I've got an old 2xP-II @ 400MHz Compaq AP400 system, which I'm still
> using. It has many peculiarities, so, I wouldn't be surprised if the
> answer to my questions would be "sorry, the patient is rather dead than
> alive".
>
> Some of the problems lie in ACPI area, I tried some time
1 - 100 of 440 matches
Mail list logo
