Ulrich Drepper wrote:
wing patches provide an alternative implementation of the
sys_indirect system call which has been discussed a few times.
This no system call allows us to extend existing system call
interfaces with adding more system calls.
Davide's previous implementation is IMO far more
Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
are seen on console as far as disks found and partitions on each. However,
once /dev is populated and the boottime scripts attempt to check filesystem
status, no partitions on either of the two disks attached to the SCSI
Thank you all for your consideration and insightful responses to my
posting. I apologize for not responding sooner---I have been under a
deadline.
It seems clear that further investigation will be needed to understand
these performance numbers better.
To summarize, I understand that the
hi,
I'm trying to add some code to netif_receive_skb function in
dev.c file . The cycles consumed by that code was around 16 cycles on
Dual Core Opetron machine.I'm working on that code for last 6 months
now and the consumed cycles have always been around 16 cycles .I don't
touch any other
Tobias wrote:
If you are accessing a scratched Video DVD and the device cannot read it, the
process ends.
What about a more tolerant way to handle unreadable blocks.
Especially on Video DVDs single blocks are not that important than on data
dvds.
If the DVD player process ends from this,
On Sun, Nov 18, 2007 at 12:04:01PM +0800, Herbert Xu wrote:
> On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote:
> >
> > On a related issue, I think the rng interface is not very suitable
> > for chips like HIFN that have a constant random bandwidth, it would
> > make a lot more
On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote:
>
> On a related issue, I think the rng interface is not very suitable
> for chips like HIFN that have a constant random bandwidth, it would
> make a lot more sense to return the time to wait to the core, instead
> of waiting 10us in
Hello.
Paul Moore wrote:
> Okay, well if that is the case I think you are going to have another problem
> in that you could end up throwing away skbs that haven't been through your
> security_post_recv_datagram() hook because you _always_ throw away the result
> of the second skb_peek(). Once
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> However, I got around the problem by making the code change manually -
> and my network connection is now working. Looking at the code being
> bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat
Matt Mackall <[EMAIL PROTECTED]> writes:
> What is the proper encoding for a patch that contains hunks in
> multiple character sets?
8-bit binary encoding, the same for single charset patch - we don't
want mail systems to change the encoding.
Unfortunately you can't display anything like that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> Looking at the code being bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat weird as it is testing the same condition twice. Should
> it have been:
>
> if (pE.cap[i] || pP.cap[i] ||
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Should be done for all architectures, methinks.
>
> If so, an appropriate way to do that would be to do
> s/dump_stack/arch_dump_stack/ and do a single all-arch implementation
> of dump_stack(). (Where we might add new goodies in the future).
i
On Sun, 18 Nov 2007 01:42:18 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > ok so how about putting the same into dump_stack() instead? (see
> > below) added bonus is that it's now present for all dumps that use
> > dump_stack(), not just
* Greg KH <[EMAIL PROTECTED]> wrote:
> Great, thanks for tracking this down.
>
> Ingo, this corrisponds to changeset
> a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. Is that patch
> incorrect? Should this patch in the -stable tree be reverted?
hm, there are no such problems in .24
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
>
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> ok so how about putting the same into dump_stack() instead? (see
> below) added bonus is that it's now present for all dumps that use
> dump_stack(), not just WARN_ON() (the format I copied from the exact
> line used by oopses)
nice! I did
From: "Patrick DEMICHEL" <[EMAIL PROTECTED]>
Date: Sat, 17 Nov 2007 18:19:25 +0100
> Yet another noisy linux HPC user
Nobody on this list is interested in discussing this.
Really, the on-topic discussion here is the code and
the technical issues. And we will work on those to
get perfmon2 into
Greg KH wrote:
> Great, thanks for tracking this down.
>
> Ingo, this corrisponds to changeset
> a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. Is that patch
> incorrect? Should this patch in the -stable tree be reverted?
>
Hm, I've never observed a problem with this in mainline.
pciehp_fix_double_init_bug.patch:
Earlier patches to split out the hardware init for PCIe hotplug
resulted in some one-time initializations being redone on every
resume cycle. Eg. irq/polling initialization.
This patch splits the hardware init into two parts,
and separates the one-time
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 17 Nov 2007 13:56:08 +0100
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >> >
> >> > Its not that cheap. The ChangeLog included my own numbers, on a
> >> > Pentium M machine. (i686, 1.6 GHz, 1.5 GB ram)
> >> >
> >> > Without "if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin,
Can you try this quick hack?
diff --git a/kernel/capability.c b/kernel/capability.c
index e57d1aa..4088610 100644
- --- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -109,7 +109,7 @@ out:
kdata[i].permitted =
On Friday 16 November 2007 10:45:32 pm Tetsuo Handa wrote:
> Paul Moore wrote:
> > I might be missing something here, but why do you need to do a skb_peek()
> > again? You already have the skb and the sock, just do the unlink.
>
> The skb might be already dequeued by other thread while I slept
On Nov 18, 2007 12:05 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 17, 2007 at 08:40:22PM +0100, Torsten Kaiser wrote:
>
> > Lockdep triggers immedetly before the freeze, but the result is still
> > not helpful:
> >
> > [ 221.565011] INFO: trying to register non-static key.
> > [
Subject: lockdep: annotate do_debug() trap handler
Ensure the hardirq state is consistent before using locks. Use the rare
trace_hardirqs_fixup() because the trap can happen in any context.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
arch/x86/kernel/traps_32.c |2 ++
On Sat, Nov 17, 2007 at 08:40:22PM +0100, Torsten Kaiser wrote:
> Lockdep triggers immedetly before the freeze, but the result is still
> not helpful:
>
> [ 221.565011] INFO: trying to register non-static key.
> [ 221.566999] the code is fine but needs lockdep annotation.
> [ 221.569206]
On Saturday 17 November 2007 10:15, Arjan van de Ven wrote:
> Hi,
>
> #define WARN_ON(condition) ({
> \
> int __ret_warn_on = !!(condition); \
> if (unlikely(__ret_warn_on)) {
On Sat, Nov 17, 2007 at 07:09:46PM +0100, Ingo Molnar wrote:
>
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>
> > Sadly lockdep does not work for me, as it gets turned off early:
> > [ 39.851594] -
> > [ 39.855963] inconsistent {softirq-on-W} ->
> > Sure, you want to split the list?
>
> split the list with you? Feel free to take any of those :-) dev->sem is
> nontrivial and probably not possible right now - and some of the others
> might be problematic too. But there might be fixable ones in the list.
> This shouldnt become like the BKL
Bill Fink wrote, On 11/16/2007 08:26 PM:
...
> Regarding the Target IP, RFC 826 says:
>
> "The target protocol address is necessary in the request form
> of the packet so that a machine can determine whether or not
> to enter the sender information in a table or to send a
On Sat, 17 Nov 2007, Rafael J. Wysocki wrote:
> On Saturday, 17 of November 2007, Jiri Slaby wrote:
> > On 11/16/2007 05:10 PM, Alan Stern wrote:
> > > On Thu, 15 Nov 2007, Greg KH wrote:
> > >
> > >>> The offending -mm patch is
> > >>>
On Tue, 13 Nov 2007, Erez Zadok wrote:
>
> I posted all of these patches just now. You're CC'ed. Hopefully Andrew can
> pull from my unionfs.git branch soon.
>
> You also reported in your previous emails some hangs/oopses while doing make
> -j 20 in unionfs on top of a single tmpfs, using -mm.
Make the patch-kernel shell script sufficiently compatible with POSIX
shells,
i.e., remove bashisms from scripts/patch-kernel.
This means that it now also works on dash 0.5.3-5
and still works on bash 3.1dfsg-8.
Full changelog:
- replaced non-standard "==" by standard "="
- replaced non-standard
On Sat, Nov 17, 2007 at 08:05:33PM +, David wrote:
> Greg KH wrote:
> > On Sat, Nov 17, 2007 at 07:21:35PM +0100, Javier Kohen wrote:
> >
> >> I upgraded today from 2.6.23 to 2.6.23.8 and started seeing a lot of
> >> these in the logs:
> >>
> >
> > Can you see if the problem showed up
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> proc_pid_readdir:
>
> for (...; ...; task = next_tgid(tgid + 1, ns)) {
> tgid = task_pid_nr_ns(task, ns);
> ... use tgid ...
>
> The first problem is that task_pid_nr_ns() can race with RCU and read the
> freed memory.
On Saturday, 17 of November 2007, Jiri Slaby wrote:
> On 11/16/2007 05:10 PM, Alan Stern wrote:
> > On Thu, 15 Nov 2007, Greg KH wrote:
> >
> >>> The offending -mm patch is
> >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> >>>
> >>> 2.6.24-rc2-mm1 minus it works just fine;
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> Without rcu/tasklist/siglock lock task_pid_nr_ns() may read the freed memory,
> move the callsite under ->siglock.
>
> Sadly, we can report pid == 0 if the task was detached.
We only get detached in release_task so it is a pretty small window
where we
On Nov 17, 2007 8:33 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Nov 2007, Andrew Morton wrote:
>
> > That's slub. It appears that list_lock is being taken from process context
> > in one place and from softirq in another.
>
> I kicked out some weird interrupt disable code in mm
Greg KH wrote:
> On Sat, Nov 17, 2007 at 07:21:35PM +0100, Javier Kohen wrote:
>
>> I upgraded today from 2.6.23 to 2.6.23.8 and started seeing a lot of
>> these in the logs:
>>
>
> Can you see if the problem showed up in 2.6.23.2 or .3 to help narrow
> this down?
>
This is the culprit,
On Sat, Nov 17, 2007 at 07:21:35PM +0100, Javier Kohen wrote:
> I upgraded today from 2.6.23 to 2.6.23.8 and started seeing a lot of
> these in the logs:
Can you see if the problem showed up in 2.6.23.2 or .3 to help narrow
this down?
thanks,
greg k-h
-
To unsubscribe from this list: send the
Javier Kohen wrote:
> I upgraded today from 2.6.23 to 2.6.23.8 and started seeing a lot of
> these in the logs:
>
> BUG: soft lockup detected on CPU#0!
> [] update_process_times+0x32/0x54
> [] tick_sched_timer+0x5e/0x99
> [] hrtimer_interrupt+0x112/0x197
> [] tick_sched_timer+0x0/0x99
> []
On Nov 17, 2007 7:19 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> >
> > > Sadly lockdep does not work for me, as it gets turned off early:
> > > [ 39.851594]
On Sat, Nov 17, 2007 at 11:35:01AM -0800, Arjan van de Ven wrote:
> On Sat, 17 Nov 2007 10:46:52 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > by ... not too much at least, gcc ought to be quite good at merging
> > > same-strings into one, so it's just one extra pointer argument
> > >
I've just released Linux 2.4.36-pre2.
Basically, it gets in sync with 2.4.35.4, and adds DMA support for
2 PCI IDE chipsets (ICH7 and JMicron 20363).
There's just the adutux driver pending before 2.4.36. I plan to issue
2.4.36-rc1 in about 2-3 weeks (first week of december), and -final the
On Sat, 17 Nov 2007 10:46:52 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > by ... not too much at least, gcc ought to be quite good at merging
> > same-strings into one, so it's just one extra pointer argument
> >
>
> I think I knew that. At 1000 callsites.
ok so how about putting the
On Sat, 17 Nov 2007, Andrew Morton wrote:
> > Don't know who to bug about that.
>
> That's slub. It appears that list_lock is being taken from process context
> in one place and from softirq in another.
I kicked out some weird interrupt disable code in mm that was only run during
NUMA
On Sat, Nov 17, 2007 at 10:15:52AM -0800, Arjan van de Ven wrote:
> Hi,
>
> today, all oopses contain a version number of the kernel, which is nice
> because the people who actually do bother to read the oops get this
> vital bit of information always without having to ask the reporter in
>
I've just released Linux 2.4.35.4.
It fixes very minor issues, but some patches have been resting here
for a long time, and there was no reason to hold them. Two minor
old vulnerabilities were fixed :
- CVE-2006-5823 would cause the kernel to oops on specially crafted
CRAMFS filesystems,
--- Peter Dolding <[EMAIL PROTECTED]> wrote:
> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> > Peter Dolding wrote:
> > >>> What is left unspecified here is 'how' a child 'with its own profile'
> is
> > >>> confined here. Are it is confined to just its own profile, it may
On Nov 17, 2007 7:58 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-11-17 at 18:53 +0100, Torsten Kaiser wrote:
> > On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > > Hi Andrew,
> > >
> > > The kernel enters the xmon state while running the file system
> >
Micah,
ok, would it be possible to get "cat /proc/schedstat" output at the
moment when you observe the 'problem'? So we could try to analyze
behavior of the load balancer (yeah, we should have probably started
with this step)
something like this:
(the problem appears)
# cat /proc/schedstat
...
On Sat, 2007-11-17 at 18:53 +0100, Torsten Kaiser wrote:
> On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > Hi Andrew,
> >
> > The kernel enters the xmon state while running the file system
> > stress on nfs v4 mounted partition.
> [snip]
> > 0:mon> t
> >
On Sat, 17 Nov 2007, Gregory Haskins wrote:
> >>> On Sat, Nov 17, 2007 at 1:33 AM, in message
> > This patch changes the searching for a run queue by a waking RT task
> > to try to pick another runqueue if the currently running task
> > is an RT task.
> >
> > The reason is that RT tasks behave
On Fri, Nov 16, 2007 at 04:00:22PM -0600, Rob Landley wrote:
> I wasn't cc'd, and missed it. I'd like to test this, do you have a
> link? (Or a bit more specificity than "a few weeks ago"?)
Here are the three patches:
http://marc.info/?l=linux-arch=119342916329510=2
On Sat, 17 Nov 2007, Gregory Haskins wrote:
> >>> On Sat, Nov 17, 2007 at 1:21 AM, in message
> <[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> > Gregory Haskins RT balancing broke sched domains.
>
> Doh! (though you mean s/domains/stats ;)
Heh, indeed.
>
> > This is a fix
On Sat, 17 Nov 2007, Gregory Haskins wrote:
> >>> On Sat, Nov 17, 2007 at 1:21 AM, in message
> <[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
>
> > +*/
> > + if (idle_cpu(cpu) || cpu_rq(cpu)->nr_running > 1)
> > + return cpu;
> > +
> > + for_each_domain(cpu,
On Sat, Nov 17, 2007 at 11:50:07AM +0100, Roel Kluin wrote:
> > + if (!pte_present(*pte))
> > + pte = NULL;
>
> shouldn't you check again for (pte == NULL)?
No, because if the page isn't mapped, handle_page_fault would have
returned non-zero, and we would have already returned.
This
On Sat, 17 Nov 2007 10:39:47 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Nov 2007 10:27:20 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 17 Nov 2007 10:15:52 -0800 Arjan van de Ven
> > <[EMAIL PROTECTED]> wrote:
> >
> > > @@ -35,8 +36,8 @@ struct bug_entry {
Kai Ruhnau <[EMAIL PROTECTED]> :
[...]
> I have a problem with two of my PCI devices showing the wrong PCI vendor
> ID (0001) in vanilla kernels.
>
> My system currently runs a 32 bit x86 kernel built from ubuntu sources
> 2.6.20.3-ubuntu1. This is the only kernel I have found so far that shows
>
On Sat, 17 Nov 2007 10:27:20 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Nov 2007 10:15:52 -0800 Arjan van de Ven
> <[EMAIL PROTECTED]> wrote:
>
> > @@ -35,8 +36,8 @@ struct bug_entry {
> > #define WARN_ON(condition)
> > ({ \ int
> >
Detect all physical PCI slots as described by ACPI, and create
entries in /sys/bus/pci/slots/.
Not all physical slots are hotpluggable, and the acpiphp module
does not detect them. Now we know the physical PCI geography of
our system, without caring about hotplug.
v2 -> v3:
Add Kconfig
- Make pci_slot the primary sysfs entity. hotplug_slot becomes a
subsidiary structure.
o pci_create_slot() creates and registers a slot with the PCI core
o pci_slot_add_hotplug() gives it hotplug capability
- Change the prototype of pci_hp_register() to take the bus and
slot
Register one slot per slot, rather than one slot per function.
Change the name of the slot to fake%d instead of the pci address.
Signed-off-by: Alex Chiang <[EMAIL PROTECTED]>
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
drivers/pci/hotplug/fakephp.c | 80
Rename the slot to be the contents of the 'path' sysfs attribute, and
delete the attribute. The mapping from pci address to slot name is
supposed to be done through the 'address' file, which will be provided
automatically later in this series of patches.
Signed-off-by: Alex Chiang <[EMAIL
Without rcu/tasklist/siglock lock task_pid_nr_ns() may read the freed memory,
move the callsite under ->siglock.
Sadly, we can report pid == 0 if the task was detached.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 24/fs/proc/array.c~dtst 2007-11-09 12:57:30.0 +0300
+++
I upgraded today from 2.6.23 to 2.6.23.8 and started seeing a lot of
these in the logs:
BUG: soft lockup detected on CPU#0!
[] update_process_times+0x32/0x54
[] tick_sched_timer+0x5e/0x99
[] hrtimer_interrupt+0x112/0x197
[] tick_sched_timer+0x0/0x99
[] smp_apic_timer_interrupt+0x60/0x6f
[]
Hi all,
This is v3 of the pci_slot patch series.
The major change is making the ACPI-PCI slot driver a Kconfig
option, as per the recommendations of others (Gary, Kenji-san).
In the process of doing so, it made sense to collapse the former
3/5 and 4/5 patches into a single 3/4 patch. There
On Sat, 17 Nov 2007 10:15:52 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> @@ -35,8 +36,8 @@ struct bug_entry {
> #define WARN_ON(condition) ({
> \
> int __ret_warn_on = !!(condition); \
> if
On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>
> > Sadly lockdep does not work for me, as it gets turned off early:
> > [ 39.851594] -
> > [ 39.855963] inconsistent {softirq-on-W} ->
Hi,
today, all oopses contain a version number of the kernel, which is nice
because the people who actually do bother to read the oops get this
vital bit of information always without having to ask the reporter in
another round trip.
However, WARN_ON() right now lacks this information; the patch
On Sat, 2007-11-17 at 19:04 +0100, Ingo Molnar wrote:
>
> split the list with you? Feel free to take any of those :-) dev->sem is
> nontrivial and probably not possible right now - and some of the others
> might be problematic too. But there might be fixable ones in the list.
> This shouldnt
On Nov 17, 2007 6:24 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> It'd be helpful to see others (especially kprobes maintainers) chime in
> on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
> kretprobe-hit time is OK, as in Abhishek's approach, then we could also
> use
proc_pid_readdir:
for (...; ...; task = next_tgid(tgid + 1, ns)) {
tgid = task_pid_nr_ns(task, ns);
... use tgid ...
The first problem is that task_pid_nr_ns() can race with RCU and read the
freed memory.
However, rcu_read_lock() can't help. next_tgid()
* Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> Sadly lockdep does not work for me, as it gets turned off early:
> [ 39.851594] -
> [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> [
On Sat, 17 Nov 2007 18:53:45 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > Hi Andrew,
> >
> > The kernel enters the xmon state while running the file system
> > stress on nfs v4 mounted partition.
> [snip]
> > 0:mon> t
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > > Actually, IMO, compat_semaphores behave like semaphores should
> > > > behave, and thus the same as they behave on a non-RT kernel, and
I would like to request a new boot flag/kernel option that would make
the following scenario possible:
1) Working on laptop with a live USB distro on a read-only USB stick.
2) Suspend laptop.
3) Detach USB stick.
4) Do other things, get on a plane, go on a bus, deal with police
officer giving
On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > Actually, IMO, compat_semaphores behave like semaphores should
> > > behave, and thus the same as they behave on a non-RT kernel, and at
> > > the locations where the semaphores are now
On Sat, 2007-11-17 at 16:53 +0100, Diego Calleja wrote:
> El Sat, 17 Nov 2007 09:42:51 -0800, Martin Olsson <[EMAIL PROTECTED]>
> escribió:
>
> > I don't think that setting a max process count by default is a
> > good/viable solution.
>
>
> I don't see why...OS X had a default limit of 100
On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The kernel enters the xmon state while running the file system
> stress on nfs v4 mounted partition.
[snip]
> 0:mon> t
> [c000dbd4fb50] c0069768 .__wake_up+0x54/0x88
> [c000dbd4fc00]
>>> On Sat, Nov 17, 2007 at 1:33 AM, in message
<[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
wrote:
> - if ((p->prio >= rq->rt.highest_prio)
> - && (p->nr_cpus_allowed > 1)) {
> + if (unlikely(rt_task(rq->curr))) {
> int cpu = find_lowest_rq(p);
>
>
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > Actually, IMO, compat_semaphores behave like semaphores should
> > behave, and thus the same as they behave on a non-RT kernel, and at
> > the locations where the semaphores are now misused as mutexes on RT,
> > we should replace them by
>>> On Sat, Nov 17, 2007 at 1:33 AM, in message
<[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
wrote:
> Sorry! I forgot to put in a prologue for this patch.
>
> Here it is.
>
>
>
> This patch changes the searching for a run queue by a waking RT task
> to try to pick another
>>> On Sat, Nov 17, 2007 at 1:21 AM, in message
<[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
wrote:
> Gregory Haskins RT balancing broke sched domains.
Doh! (though you mean s/domains/stats ;)
> This is a fix to allow it to still work.
>
> Signed-off-by: Steven Rostedt <[EMAIL
>>> On Sat, Nov 17, 2007 at 1:21 AM, in message
<[EMAIL PROTECTED]>, Steven Rostedt <[EMAIL PROTECTED]>
wrote:
> -/*
> - * wake_idle() will wake a task on an idle cpu if task->cpu is
> - * not idle and an idle cpu is available. The span of cpus to
> - * search starts with cpus closest then
On Saturday 17 November 2007, Jean Delvare wrote:
> On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
> > On Tuesday 13 November 2007, eric miao wrote:
> > > if (!requested)
> > > - printk(KERN_DEBUG "GPIO-%d autorequested\n",
> > > - chip->base + offset);
On Sat, 2007-11-17 at 18:09 +0100, Remy Bohmer wrote:
> Actually, IMO, compat_semaphores behave like semaphores should behave,
> and thus the same as they behave on a non-RT kernel, and at the
> locations where the semaphores are now misused as mutexes on RT, we
> should replace them by
On Sat, Nov 17, 2007 at 05:33:27PM +0100, Andreas Mohr wrote:
> Hi,
>
> On Wed, Nov 14, 2007 at 02:46:27PM -0800, Randy Dunlap wrote:
> > On Mon, 5 Nov 2007 20:58:27 +0100 Andreas Mohr wrote:
> > > Feel free to go ahead, otherwise I'll try another patch sometime soon.
> > > All I care about is
Hello,
I have found out something new about the cfs problem:
1) on a 2.6.20, working good:
after starting cfs, nothing cattach'd:
zeus:~# cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID
v2 7f01 be9 0:140:0
after cattaching (and at least once listing the directory, if not
On Wed, Oct 31, 2007 at 10:13:21PM +0100, Andreas Mohr wrote:
> Hello,
Hi Andreas,
> I was non-mildly horrified to find that the rather widely used patch-kernel
> script seems to rely on bash despite specifying the interpreter as #!/bin/sh,
> since my dash-using Debian install choked on it.
>
Yet another noisy linux HPC user
I hope to convince you, lkml developers, to pay more attention to our
HPC performance problems.
I will not try to convince you that our problems are also the problems
of many others users, I hope they will do it directly.
Imagine my company bought an expensive
I've done some more testing this morning, and it appears that the "ALSA:
emu10k1 - Fix memory corruption" patch from 2.6.23.6 has broken digital
output on my SB Live Value card. Simply replacing the 2.6.23.7 emumixer.c
with the version included in 2.6.23.1 I was able to get digital output
On Nov 17, 2007 4:39 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> First of all, as promised, here's what would be different if it were
> implemented using the data-pouch approach:
>
> --- abhishek1.c 2007-11-16 13:57:13.0 -0800
> +++ jim1.c 2007-11-16 14:20:39.0 -0800
> @@
Hello Daniel,
Thanks for looking into it also.
Steven already made clear to me that the 'struct semaphore' type on
the RT-kernel should not be used as a counting-semaphore, but as some
sort of legacy-mutex... (The confusion that this will cause is clear
by now...)
I still do not understand the
On Sat, Nov 17, 2007 at 05:33:27PM +0100, Andreas Mohr wrote:
>
> # strip EXTRAVERSION to just a number (drop leading '.' and trailing
> additions)
> EXTRAVER=
> if [ x$EXTRAVERSION != "x" ]
> then
> >>> [l.207] if [ ${EXTRAVERSION:0:1} == "." ]; then
>
On Sat, 17 Nov 2007, Linus Torvalds wrote:
>
> Heh. I applied it just before pulling, so it's there twice.
.. btw, Thomas, you forgot to add your sign-off to your version.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Sat, 17 Nov 2007, Thomas Gleixner wrote:
>
> Just added Sam's latest fix for the x86 build mechanism on top of the
> patches below.
Heh. I applied it just before pulling, so it's there twice. Git obviously
then merged it without problems, so I didn't even notice until you
mentioned it
On 11/16, Roland McGrath wrote:
>
> This is good, but not quite enough. The original intent behind having the
> test was never to return mismatched stale/fresh data. (Not that it ever
> really worked as intended.) That is, it's fine if the task has woken up
> and done other things while WNOWAIT
Hi,
On Wed, Nov 14, 2007 at 02:46:27PM -0800, Randy Dunlap wrote:
> On Mon, 5 Nov 2007 20:58:27 +0100 Andreas Mohr wrote:
> > Feel free to go ahead, otherwise I'll try another patch sometime soon.
> > All I care about is that the result works on (at least)
> > one shell implementation _more_ than
On Sat, 2007-11-17 at 12:44 +0100, Remy Bohmer wrote:
> Hello Steven,
>
> > The taker of a mutex must also be the one that releases it. I don't see
> > how you could use a mutex for this. It really requires some kind of
> > completion, or a compat_semaphore.
>
> I tried several ways of working
1 - 100 of 316 matches
Mail list logo
