Trond Myklebust <[EMAIL PROTECTED]> writes:
> I was mainly interested in feedback from Peter, Florin and Ogawa-san to
> find out if this series fixes their problems. You were unfortunate
> enough to have been on earlier Ccs, so I didn't dare trim you off. :-)
Sorry. I'm trying to reproduce that,
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > 535.43user 30.62system 2:23.72elapsed 393%CPU
> >
> > Thanks for testing this! Could you please try this also with:
> >
> >echo 1 > /proc/sys/kernel/sched_granularity
>
> 507.68user 31.87system 2:18.05elapsed 390%CPU
> 507.99user
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >which thread would be the most interesting to you - 9324?
>
> The thread which should wake the main thread - but hmm ... 9303 seems
> to be rather dead-locked than doing pthread_cond_timedwait() ?
On Wed, 18 Apr 2007 11:33:29 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> John Anthony Kazos Jr. wrote:
> > Convert the subdirectory "crypto" to UTF-8. The files changed are
> > and .
>
> Aren't we using ASCII for C sources?
We haven't done that for many years - it makes it hard to spell
On 4/17/2007 7:53 PM, John Anthony Kazos Jr. wrote:
> From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
>
> Convert the "include" subdirectory to UTF-8. The following files are
> changed.
>
> include/net/irda/{iriap.h,irttp.h,iriap_event.h,parameters.h}
>
> Yet another hard drive which doesn't seem to get NCQ right.
I have a Samsung 400LJ that appears to work fine with NCQ on an Intel
965 chipset motherboard (Asus P5B) and Linux kernel 2.6.20.7.
Dmesg Output :
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7,
Hi,
The patch looks good to me.
On Mon, Apr 16, 2007 at 11:27:58PM +0200, Rafael J. Wysocki wrote:
>
> ---
> Documentation/cpu-hotplug.txt |9 +++--
> arch/i386/kernel/cpu/intel_cacheinfo.c|2 ++
> arch/i386/kernel/cpu/mcheck/therm_throt.c |2 ++
>
On Wednesday 18 April 2007 18:55, Nick Piggin wrote:
> On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > 2.6.21-rc7-cfs-v2
> > > 534.80user 30.92system 2:23.64elapsed 393%CPU
> > > 534.75user 31.01system 2:23.70elapsed 393%CPU
> > >
John Anthony Kazos Jr. wrote:
> Convert the subdirectory "crypto" to UTF-8. The files changed are
> and .
Aren't we using ASCII for C sources?
--
Stefan Richter
-=-=-=== -=-- =--=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It's debatable but I think things will be safer this way. If we wait by
> default, we are forced to check that all references are dropped and will
> have a stack dump indicating which object is causing problem when
>
On Wed, Apr 18, 2007 at 11:16:50AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> > That is what I referred to as error path. Btw, with positive return
> > value we end up in subsequent call to input which will free callback
> > under lock as expected.
>
>
> No, nothing is going to call
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >which thread would be the most interesting to you - 9324?
>
> The thread which should wake the main thread - but hmm ... 9303 seems
> to be rather dead-locked than doing pthread_cond_timedwait() ?
ok, here it is, 9303 with better symbol names:
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >are the updated backtraces in the followup mail i just sent more
> >useful? (I still have that stuck session running so i can whatever
> >debugging you'd like to see done.)
>
>
> > Allowing this and other flags to NOT be propagated just makes it
> > possible to have a set of shared mounts with asymmetric properties,
> > which may actually be desirable.
>
> The shared mount feature was designed to ensure that the mount remained
> identical at all the locations.
OK, so
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 10:50:42AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
>
>>>I thought that with releasing a socket, which will have a callback
>>>attached only results in a leak of the callback? In that case we can
>>>just free it in dump() just like it
> The basic reason for all this is to eventually allow the low-level
> serial drivers to function without a uart_info structure being
> allocated. This will allow the serial console, debuggers like kgdb,
> and the IPMI serial driver to use one interface to the uart code and
Its cheaper to
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >are the updated backtraces in the followup mail i just sent more
> >useful? (I still have that stuck session running so i can whatever
> >debugging you'd like to see done.)
>
> QWidget::setUpdatesEnabled() is (wrongly) present in every thread
On Wed, Apr 18, 2007 at 01:03:56PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
> > Yes, you are right, that it will not be freed in netlink_release(),
> > but it will be freed in netlink_dump() after it is processed (in no-error
> > path only though).
> >
>
> But error path will leak
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >backtrace:
> >
> > #0 0xe410 in __kernel_vsyscall ()
> > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib/libpthread.so.0
> > #2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from
> > I've tried to make this unprivileged mount thing as simple as
> > possible, and no simpler. If we can make it even simpler, all the
> > better.
>
> We are certainly much more complex then the code in plan9 (just
> read through it) so I think we have room for improvement.
>
> Just for
On Wed, 2007-04-18 at 11:01 +0200, Ingo Molnar wrote:
> * Christoph Pfister <[EMAIL PROTECTED]> wrote:
>
> > >backtrace:
> > >
> > > #0 0xe410 in __kernel_vsyscall ()
> > > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > > /lib/libpthread.so.0
> > > #2 0xb79fd1a8 in
On Wed, Apr 18, 2007 at 10:50:42AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> >>It already does (netlink_destroy_callback), but that doesn't help
> >>with this race though since without this patch we don't enter the
> >>error path.
> >
> > I thought that with releasing a socket, which
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> these were only the threads that showed up in htop. Here's a full
> analysis about what all threads are doing:
>
> Process 9303: stuck in xine_play()/pthread_mutex_lock()
> Process 9319: stuck in pthread_cond_timedwait()
> Process 9320: stuck in
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >backtrace:
> >
> > #0 0xe410 in __kernel_vsyscall ()
> > #1 0x4a2510c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > /lib/libpthread.so.0
> > #2 0xb79fd1a8 in QWidget::setUpdatesEnabled () from /usr/lib/libxine.so.1
> > #3 0xb7a030ab in
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 12:32:40PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
> wrote:
>> Evgeniy Polyakov wrote:
>>> On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
>>> PROTECTED]) wrote:
Sorry, I forgot to put netdev and David in Cc when I first
Hi,
2007/4/18, Ingo Molnar <[EMAIL PROTECTED]>:
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
>
> Could you
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> update: i've reproduced one kind of a hang but i'm not sure it's the
> same hang Ismail is seeing. It was quite hard to trigger it under CFS,
> i had to do wild forward/backward button seeks on a real DVD and i
> mixed it with CPU-intense workloads
On Tue, Apr 17, 2007 at 11:59:00AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > 2.6.21-rc7-cfs-v2
> > 534.80user 30.92system 2:23.64elapsed 393%CPU
> > 534.75user 31.01system 2:23.70elapsed 393%CPU
> > 534.66user 31.07system 2:23.76elapsed 393%CPU
> > 534.56user
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
>
>>>Out of curiosity, why not to fix a netlink_dump_start() to remove
>>>callback in error path, since in 'no-error' path it removes it in
>>>netlink_dump().
>>
>>
>>It already does
On Fri, 2007-03-30 at 16:05 -0700, Dan Williams wrote:
> Allows architectures to advertise that they support MSI rather than listing
> each architecture as a PCI_MSI dependency.
>
> rev2:
> * update i386 and x86_64 as well
>
> Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
> Acked-by: "Eric W.
Madhusudhan c wrote:
> Hi Pierre/philip,
>
Hi Madhusudhan,
Feel free to add me as cc in the future if you want me to notice your mail ;)
> This is regarding the MMCv4 support that came in as part of the MMC
> core of 2.6.20 linux kernel version.
>
> The high speed MMC cards can support
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:49:01 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Oh, one more thing, with proper code audit, we can just make
>> device_unregister() do the waiting instead of adding separate
>> device_unregister_wait(). I think that will be a good step
On Wed, Apr 18, 2007 at 12:32:40PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
> > PROTECTED]) wrote:
> >> Sorry, I forgot to put netdev and David in Cc when I first sent it.
> >>
> >> There is
On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL
> > PROTECTED]) wrote:
> >
> >>Sorry, I forgot to put netdev and David in Cc when I first sent it.
> >>
> >>There
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:41:10 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Hello, all.
>>
>> Agreed with the problem but I'm not very enthusiastic for adding
>> kobj->owner. How about the following? exit() routines will have to
>> do device_unregister_wait() instead
[ i've Cc:-ed Ulrich Drepper, this CFS-triggered hang seems to have some
futex and pthread_cond_wait() relevance. ]
* Christoph Pfister <[EMAIL PROTECTED]> wrote:
> >> > [1] http://cekirdek.pardus.org.tr/~caglar/strace.kaffeine
>
> Could you try xine-ui or gxine? Because I suspect rather
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
> wrote:
>
>>Sorry, I forgot to put netdev and David in Cc when I first sent it.
>>
>>There is a race between netlink_dump_start() and netlink_release()
>>that can lead to the situation when a
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
> wrote:
>> Sorry, I forgot to put netdev and David in Cc when I first sent it.
>>
>> There is a race between netlink_dump_start() and netlink_release()
>> that can lead to the situation when a
> I'd imagine that other serial drivers might get upset having their
> ->get_mcrtl() called prior to being opened. Perhaps we should be fixing
> this in uart_read_proc()?
>
I looked at other serial drivers and I could not find any other
drivers which accesses port->info in their ->get_mctrl().
18.04.2007 06:25, Dmitry Torokhov wrote/a écrit:
On Saturday 14 April 2007 12:09, Éric Piel wrote:
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Was there 1/2 file?
On Tue, 2007-04-17 at 21:19 -0400, Trond Myklebust wrote:
> I've split the issues introduced by the 2.6.21-rcX write code up into 4
> subproblems.
>
> The first patch is just a cleanup in order to ease review.
>
> Patch number 2 ensures that we never release the PG_writeback flag until
> _after_
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
> Sorry, I forgot to put netdev and David in Cc when I first sent it.
>
> There is a race between netlink_dump_start() and netlink_release()
> that can lead to the situation when a netlink socket with non-zero
>
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink socket with non-zero
callback is freed.
Here it is:
CPU1: CPU2
netlink_release():
John Sigler wrote:
# : >/var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 519083XT-PIC-XTtimer
2: 0XT-PIC-XTcascade
9: 0XT-PIC-XTacpi
10: 9786
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Oh, one more thing, with proper code audit, we can just make
> device_unregister() do the waiting instead of adding separate
> device_unregister_wait(). I think that will be a good step toward
> immediate-detach driver
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, all.
>
> Agreed with the problem but I'm not very enthusiastic for adding
> kobj->owner. How about the following? exit() routines will have to
> do device_unregister_wait() instead of device_unregister(). On
Max Kellermann wrote:
> On 2007/04/18 08:26, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Can you try it on another controller? Say, a ahci or sil24?
>
> Seems to work ok on a Via VT8251 controller (AHCI) on kernel
> 2.6.21-rc6-git4 without my NCQ disabling patch.
Unfortunately, NCQ is not supported
On 2007/04/18 08:26, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
By the way, on this machine, I had a lot of SATA timeouts during
remember that the windows NT permission model is theoreticly superior to the
Unix permission model.
however there are far more insecure windows boxes out there then Unix boxes
(even if taken as a percentage of the installed base)
I don't think that anyone is claiming that AA is superior to
Matt Mackall wrote:
On Tue, Apr 17, 2007 at 03:59:02PM -0700, William Lee Irwin III wrote:
On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
I'm working with the following suggestion:
On Tue, Apr 17, 2007 at 09:07:49AM -0400, James Bruce wrote:
Nonlinear is a must IMO. I
It seems that this might introduce serious denial of service
possibilities due to the fact that many of the file systems are not
robust to invalid on-block-device data.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, Apr 18, 2007 at 01:55:34AM -0500, Matt Mackall wrote:
> On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
> > I don't know how that supports your argument for unfairness,
>
> I never had such an argument. I like fairness.
>
> My argument is that -you- don't have an argument
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>> > Label-based security (exemplified by SELinux, and its predecessors in
>> > MLS systems) attaches security policy to the data. As the
On Tue, Apr 17, 2007 at 12:56:24PM -0400, Shaya Potter wrote:
> Bharata B Rao wrote:
>
> >No. foo is not visible. While looking for a file in a union mounted
> >directory, the lookup starts from the topmost directory and proceeds
> >downwards if the file isn't present the top layers. If a
On Tue, 17 Apr 2007, Dave Jones wrote:
> git-bisect just fingered it as responsible for my "backlight doesn't turn on"
> suspend/resume regression on the Thinkpad X60. I think it's lying.
Actually I've seeing git bisect lying on me, too. I retried a few times
(fortunately it didn't require
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
> I don't know how that supports your argument for unfairness,
I never had such an argument. I like fairness.
My argument is that -you- don't have an argument for making fairness a
-requirement-.
> processes are special only because
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
On Tue, 17 Apr 2007, John Anthony Kazos Jr. wrote:
> --- linux-2.6.21-rc7.orig/Documentation/fb/framebuffer.txt2007-02-04
> 13:44:54.0 -0500
> +++ linux-2.6.21-rc7.mod/Documentation/fb/framebuffer.txt 2007-04-17
> 12:44:09.0 -0400
> @@ -217,7 +217,7 @@ vsync length.
>
Pekka Enberg wrote:
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>> The out_of_memory() function and SysRq-M handler call
>> show_mem() to show the current memory usage state.
>
> I am still somewhat unhappy about the spinlock, but I don't really
What's wrong with the spinlock? It
There are many places in the kernel where the construction like
foo = list_entry(head->next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)->next, type, member)
On Wed, Apr 18, 2007 at 12:55:25AM -0500, Matt Mackall wrote:
> On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
> > > It's also not yet clear that a scheduler can't be taught to do the
> > > right thing with X without fiddling with nice levels.
> >
> > Being fair doesn't prevent
Dave Hansen wrote:
> On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
>> +#define SHOW_TOP_SLABS 10
>
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHOW 10
>
> or
>
Max Kellermann wrote:
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
On Tue, 17 Apr 2007, Eric Dumazet wrote:
> This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
> or else you defeat NUMA optimizations if touching a field in kmem_cache
> at kmem_getpages()/kmem_freepages() time.
We already touch ->flags, ->gfpflags, and ->gfporder in
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA LEGACY, stat=0x400
* Michael Ellerman <[EMAIL PROTECTED]> wrote:
> Apparently it's not cool anymore to use SPIN/RW_LOCK_UNLOCKED. There's
> some mention of this in Documentation/spinlocks.txt, but that only
> talks about dynamic initialisation.
>
> A comment in the code mentioning the preferred usage would be
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> > +#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define
On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
> > It's also not yet clear that a scheduler can't be taught to do the
> > right thing with X without fiddling with nice levels.
>
> Being fair doesn't prevent that. Implicit unfairness is wrong though,
> because it will bite people.
>
On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
It's also not yet clear that a scheduler can't be taught to do the
right thing with X without fiddling with nice levels.
Being fair doesn't prevent that. Implicit unfairness is wrong though,
because it will bite people.
What's
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
* Michael Ellerman [EMAIL PROTECTED] wrote:
Apparently it's not cool anymore to use SPIN/RW_LOCK_UNLOCKED. There's
some mention of this in Documentation/spinlocks.txt, but that only
talks about dynamic initialisation.
A comment in the code mentioning the preferred usage would be good
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA LEGACY, stat=0x400
On Tue, 17 Apr 2007, Eric Dumazet wrote:
This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
or else you defeat NUMA optimizations if touching a field in kmem_cache
at kmem_getpages()/kmem_freepages() time.
We already touch -flags, -gfpflags, and -gfporder in
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
Max Kellermann wrote:
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA
Dave Hansen wrote:
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define
On Wed, Apr 18, 2007 at 12:55:25AM -0500, Matt Mackall wrote:
On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
It's also not yet clear that a scheduler can't be taught to do the
right thing with X without fiddling with nice levels.
Being fair doesn't prevent that. Implicit
There are many places in the kernel where the construction like
foo = list_entry(head-next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)-next, type, member)
Here
Pekka Enberg wrote:
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
What's wrong with the spinlock? It exists
On Tue, 17 Apr 2007, John Anthony Kazos Jr. wrote:
--- linux-2.6.21-rc7.orig/Documentation/fb/framebuffer.txt2007-02-04
13:44:54.0 -0500
+++ linux-2.6.21-rc7.mod/Documentation/fb/framebuffer.txt 2007-04-17
12:44:09.0 -0400
@@ -217,7 +217,7 @@ vsync length.
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
I don't know how that supports your argument for unfairness,
I never had such an argument. I like fairness.
My argument is that -you- don't have an argument for making fairness a
-requirement-.
processes are special only because
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
On Tue, 17 Apr 2007, Dave Jones wrote:
git-bisect just fingered it as responsible for my backlight doesn't turn on
suspend/resume regression on the Thinkpad X60. I think it's lying.
Actually I've seeing git bisect lying on me, too. I retried a few times
(fortunately it didn't require
On Tue, Apr 17, 2007 at 12:56:24PM -0400, Shaya Potter wrote:
Bharata B Rao wrote:
No. foo is not visible. While looking for a file in a union mounted
directory, the lookup starts from the topmost directory and proceeds
downwards if the file isn't present the top layers. If a whiteout is
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to the data. As the data flows
It seems that this might introduce serious denial of service
possibilities due to the fact that many of the file systems are not
robust to invalid on-block-device data.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Wed, Apr 18, 2007 at 01:55:34AM -0500, Matt Mackall wrote:
On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
I don't know how that supports your argument for unfairness,
I never had such an argument. I like fairness.
My argument is that -you- don't have an argument for
Matt Mackall wrote:
On Tue, Apr 17, 2007 at 03:59:02PM -0700, William Lee Irwin III wrote:
On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
I'm working with the following suggestion:
On Tue, Apr 17, 2007 at 09:07:49AM -0400, James Bruce wrote:
Nonlinear is a must IMO. I
remember that the windows NT permission model is theoreticly superior to the
Unix permission model.
however there are far more insecure windows boxes out there then Unix boxes
(even if taken as a percentage of the installed base)
I don't think that anyone is claiming that AA is superior to
On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote:
Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
By the way, on this machine, I had a lot of SATA timeouts during
Max Kellermann wrote:
On 2007/04/18 08:26, Tejun Heo [EMAIL PROTECTED] wrote:
Can you try it on another controller? Say, a ahci or sil24?
Seems to work ok on a Via VT8251 controller (AHCI) on kernel
2.6.21-rc6-git4 without my NCQ disabling patch.
Unfortunately, NCQ is not supported on
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Oh, one more thing, with proper code audit, we can just make
device_unregister() do the waiting instead of adding separate
device_unregister_wait(). I think that will be a good step toward
immediate-detach driver model.
John Sigler wrote:
# : /var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 519083XT-PIC-XTtimer
2: 0XT-PIC-XTcascade
9: 0XT-PIC-XTacpi
10: 9786
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink socket with non-zero
callback is freed.
Here it is:
CPU1: CPU2
netlink_release():
On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
wrote:
Sorry, I forgot to put netdev and David in Cc when I first sent it.
There is a race between netlink_dump_start() and netlink_release()
that can lead to the situation when a netlink socket with non-zero
On Tue, 2007-04-17 at 21:19 -0400, Trond Myklebust wrote:
I've split the issues introduced by the 2.6.21-rcX write code up into 4
subproblems.
The first patch is just a cleanup in order to ease review.
Patch number 2 ensures that we never release the PG_writeback flag until
_after_ we've
18.04.2007 06:25, Dmitry Torokhov wrote/a écrit:
On Saturday 14 April 2007 12:09, Éric Piel wrote:
This patch adds support for mail and wifi leds. It modifies the Kconfig
file to automatically pull led_class with wistron_btns, hopefully
everyone is fine with this.
Was there 1/2 file?
I'd imagine that other serial drivers might get upset having their
-get_mcrtl() called prior to being opened. Perhaps we should be fixing
this in uart_read_proc()?
I looked at other serial drivers and I could not find any other
drivers which accesses port-info in their -get_mctrl(). This
301 - 400 of 738 matches
Mail list logo
