Oliver Neukum wrote:
Am Montag, 12. März 2007 15:56 schrieb Mark Lord:
Still no improvement on the b0rken usb-serial resume support in -rc*.
Have you applied the fixes in Greg's current tree?
I don't know anything about any "current tree"
other than the 2.6.21-rc3-git* on kernel.org.
Greg
Wouldn't it be better for all of us that select() doesn't block on
write(), unless there is a socket writting buffer fulfilled? It will
be consistent with the select() specification.
2007/3/12, Alistair John Strachan <[EMAIL PROTECTED]>:
On Monday 12 March 2007 15:02, Lluís Batlle wrote:
> Oh,
On Monday 12 March 2007 15:02, Lluís Batlle wrote:
> Oh, of course you're right. I was inside too much layers to think of
> the tcp protocol, and I did not pay attention to it.
>
> Maybe something could be added to the manpage anyway.
>
> The bad thing is that there's no way I can use a socket for
On Mon, 12 Mar 2007, Jiri Slaby wrote:
> Bisecting figured out the culprit:
> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
> Author: Alan Stern <[EMAIL PROTECTED]> Mon, 19 Feb 2007 15:52:45 -0500
>
> UHCI: Eliminate asynchronous skeleton Queue Headers
>
> This patch (as856)
On Mon, Mar 12, 2007 at 07:31:48PM +0530, Srivatsa Vaddagiri wrote:
> not so. This in-fact lets vservers and containers to work with each
> other. So:
s/containers/cpusets
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Am Montag, 12. März 2007 15:56 schrieb Mark Lord:
> Still no improvement on the b0rken usb-serial resume support in -rc*.
Have you applied the fixes in Greg's current tree?
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon 12-03-07 15:39:00, Nick Piggin wrote:
> On Mon, Mar 12, 2007 at 03:20:12PM +0100, Jan Kara wrote:
> > Hi,
> >
> > > Hi, I am encountering a performance problem, which I have tracked into
> > > the
> > > Linux kernel. The problem occurs with my experimental web server that
> > > uses
On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
If I can manage to focus on this, it looks like the information I need to
start fixing this.
I had a look at the second leak reported it seems to be caused by the
same proc_set_tty() call but, in this case, there is no
Oh, of course you're right. I was inside too much layers to think of
the tcp protocol, and I did not pay attention to it.
Maybe something could be added to the manpage anyway.
The bad thing is that there's no way I can use a socket for writing
using select() if that connection has been
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> > 3. This next leads me to think that 'tasks' file in each directory doesnt
> > make
> >sense for containers. In fact it can lend itself to error situations (by
> >administrator/script mistake) when some tasks of a container
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > Why? What's wrong with simply calling kref_get/put?
> >
> > It's the same old problem: the race between unbind and sysfs I/O. What
> > good does holding a reference to the private data structure do if the
> > show/store method gets called after
On Mon, 12 Mar 2007 15:34:57 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> > > + bit_data->udelay= 5,/* 100 kHz */
> > > + bit_data->timeout = HZ / 10, /* 100 ms */
> >
> > Can we add these udelay/timeout to struct i2c_gpio_platform_data?
Andi Kleen wrote:
in Linux. Apparently in some cases sata_nv does DMA on an already freed and then
reused mapping.
Any data or additional info on that? Did you discover this by tracking
the DMA API software routines, or something lower level (like a bus
analyzer)?
libata handles all the
Op Monday 12 March 2007, schreef Al Boldi:
> Con Kolivas wrote:
> > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > > Basically exactly as I'd expect. The higher priority task gets
> > > >
Still no improvement on the b0rken usb-serial resume support in -rc*.
Today I got this ooops on resume from RAM.
Slightly tainted kernel this time (vmware), but not previously
on similar crashes. I cannot yet get it to "crash on demaind",
so you'll just have to live with it this time.
All USB
Hi,
I'm running a slackware 10.2 on a HP/Compaq nx5000.
With kernels <= 2.6.17.3 I didn't have problems.
Starting from 2.6.19 if I close the notebook's video,
or if I press the lid switch,
after a couple of time, or after a few seconds, the o.s. hangs
completely. The only thing to do is a brute
On 3/12/07, David Schwartz <[EMAIL PROTECTED]> wrote:
In no case is much of anything guaranteed, of course. (What can you do if
there's no other process to yield to?)
Perhaps if sched_yield()'s effects were cumulative inside a timeslice,
then eventually the calling task would get pushed far
Hello,
I've found a problem in the select() call. The manpage states:
"those in writefds will be watched to see if a write will not block"
I've tried a select() for write against a closed tcp socket (closed by
the other side), and the select call _blocks_.
Any write() call to that socket will
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > this patch has been tested in -rt. Must-have for v2.6.21.
>
> Does that fix this:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224262
yeah, could very much be related.
Ingo
-
To unsubscribe from this list: send the line
Vitaliyi wrote:
Good Day
Say i want to implement extended set of ATA commands available to
userspace for building diagnostic tools.
I need 0x40 -- read verify and 0x32 -- write long with error handling,
for example. I was trying ide driver through ioctl's, but seems it
lack of functionality and
Andi Kleen wrote:
>> Rusty's pda->per_cpu patch will deal with this once and for all; have
>>
>
> Not on x86-64.
>
Have you considered dropping pda in x86-64? Segment based percpu
doesn't really have any disadvantages.
>> you picked it up yet?
>>
>
> Not yet.
>
There will be
Ingo Molnar wrote:
> Subject: [patch] futex: PI state locking fix
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
> state needs to be locked before we access it.
>
> this patch has been tested in -rt. Must-have for v2.6.21.
>
At Mon, 12 Mar 2007 13:53:51 +,
Ralf Baechle wrote:
>
> On Mon, Mar 12, 2007 at 12:04:30PM +0100, Takashi Iwai wrote:
>
> > It's no big problem to remove const in these cases, but allowing const
> > with __devinitdata seems the right fix to me...
>
> Gccs derives the readability of a
On Mon, 12 Mar 2007 18:07:59 +0800
"Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> > static struct i2c_gpio_platform_data i2c_gpio_data = {
> > .sda_pin= GPIO_PIN_FOO,
> > .scl_pin= GPIO_PIN_BAR,
> > };
>
> Is this usage right, because 3 flags are added to this structure as
>
On Mon, Mar 12, 2007 at 03:20:12PM +0100, Jan Kara wrote:
> Hi,
>
> > Hi, I am encountering a performance problem, which I have tracked into the
> > Linux kernel. The problem occurs with my experimental web server that uses
> > sendfile to repeatedly transmit files. The files are based on
On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> Mike the cpu is being proportioned out perfectly according to fairness as I
> mentioned in the prior email, yet X is getting the lower latency scheduling.
> I'm not sure within the bounds of fairness what more would you have happen to
>
* Theodore Tso <[EMAIL PROTECTED]> wrote:
> What we probably need in the long-term, and not just for high
> precision wakeups, is we need a way for waiters (either in the kernel
> or in userspace) to specify a desired precision in their timers. Is
> it, "wake me up in a second, exactly", or
On Mon, Mar 12, 2007 at 10:12:14AM -0400, Theodore Tso wrote:
> On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
> > On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > > Ingo Molnar <[EMAIL PROTECTED]>
> This becomes especially important if we want the tickless code to
> really shine as far as power management is concerned. Unfortunately,
> the POSIX timer abstraction doesn't give this kind of flexibility
> easily, so it's going to be a while before we see significant
> userspace adoption of
Con Kolivas wrote:
> > > The higher priority one always get 6-7ms whereas the lower priority
> > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > Basically exactly as I'd expect. The higher priority task gets
> > > precisely RR_INTERVAL maximum latency whereas the
Hi,
> Hi, I am encountering a performance problem, which I have tracked into the
> Linux kernel. The problem occurs with my experimental web server that uses
> sendfile to repeatedly transmit files. The files are based on the static
> portion of the SPECweb99 fileset and range in size to
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup
> detected on CPU#0!)
>
>
> * Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
>
> > > could you turn on CONFIG_SLAB_DEBUG as well?
> > >
> > > that should catch certain
Robert P. J. Day wrote:
> On Mon, 12 Mar 2007, Stefan Richter wrote:
>> Rusty Russell wrote:
>> > OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
>> > it's zero.
>>
>> What about ZERO_UNLESS_BUILD_BUG_ON(e)? It's long though...
>
> how often is this going to be used? it's
On Sun, Mar 11, 2007 at 12:38:43PM -0700, Paul Jackson wrote:
> The primary reason for the cpuset double locking, as I recall, was because
> cpusets needs to access cpusets inside the memory allocator.
"needs to access cpusets" - can you be more specific?
Being able to safely walk
On Sat, 10 Mar 2007 21:15:50 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> I like the idea very much. Would this let us get rid of i2c-ixp2000?
> i2c-ixp4xx? scx200_i2c? Other drivers?
Any platform that implements the generic gpio api should be able to use
this driver. So yes, I hope we might
On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
> On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > > >
> > > > the only correct approach is the use of hrtimers,
On Sun, 11 Mar 2007, Andrew Morton wrote:
> > On Sat, 10 Mar 2007 02:31:35 -0200 Mauro Carvalho Chehab <[EMAIL
> > PROTECTED]> wrote:
> > From: Trent Piepho <[EMAIL PROTECTED]>
> >
> > When a module uses symbol_get() to increase the ref count of another
> > module, there is no record what module
Pekka Enberg wrote:
Hi,
On 3/12/07, Valerie Henson <[EMAIL PROTECTED]> wrote:
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -17,11 +17,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
> > containers patches uses just a single pointer in the task_struct, and
> > all tasks in the same set of containers (across all hierarchies) will
> > share a single container_group object, which holds the actual pointers
> > to
> On Monday 12 March 2007 22:21, Michael Gerdau wrote:
> > > > And here are the backported RSDL 0.30 patches in case any of you
> > > > would still be running an older 2.6.18.8 kernel ...
> >
> > The original mail doesn't seem to have made it to the ck-list.
> >
> > Where would I find the
On Mon, Mar 12, 2007 at 12:04:30PM +0100, Takashi Iwai wrote:
> It's no big problem to remove const in these cases, but allowing const
> with __devinitdata seems the right fix to me...
Gccs derives the readability of a section used with __attribute(section())
from the first use, which in case of
2007/3/12, David Schwartz <[EMAIL PROTECTED]>:
> NULL has the same bit pattern as the number zero. (I'm not saying the bit
> pattern is all zeroes. And I am not even sure if NULL ought to
> have the same
> pattern as zero.) So C++ could use (void *)0, if it would let itself :p
They don't have
Please pull from 'for-linus' branch of
git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus
to receive the following updates:
arch/s390/kernel/compat_wrapper.S | 17 +
arch/s390/kernel/debug.c |2 +-
arch/s390/kernel/early.c | 10
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote:
[snip]
> So, are /dev/hd* going to disappear in a few years? iow, does it make
> sense to _slowly_ start to migrate to /dev/sd*?
How would you propose doing this? I'm sure modern distros with an
initrd/initramfs probably already do some
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
> > if you create a 'resource container' to limit the
> > usage of a set of resources for the processes
> > belonging to this container, it would be kind of
> > defeating the purpose, if you'd allow the processes
> > to manipulate
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > could you turn on CONFIG_SLAB_DEBUG as well?
> >
> > that should catch certain types of use-after-free accesses, and
> > lockdep will also warn if a still locked object is freed.
>
> Hmm, no, this does not look like use-after-free. I enabled
From: Heiko Carstens <[EMAIL PROTECTED]>
[S390] memory detection: fix off by one bug.
diag 260 returns the address of the last addressable byte and not the
size of memory. Since we want the size we have to add 1 to the return
value.
Disable diag 260 for non z/Arch mode since it doesn't work
From: Heiko Carstens <[EMAIL PROTECTED]>
[S390] Wire up compat_sys_epoll_pwait.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
arch/s390/kernel/compat_wrapper.S | 11 +++
arch/s390/kernel/syscalls.S |2 +-
2 files
From: Michael Holzheu <[EMAIL PROTECTED]>
[S390] reboot from and dump to SCSI under z/VM fails.
We used wrong length values for ipl and dump hardware structures.
Since z/VM checks the ipl parameters more accurately than LPAR,
the operations fail there.
Signed-off-by: Michael Holzheu <[EMAIL
From: Heiko Carstens <[EMAIL PROTECTED]>
[S390] Wire up sys_utimes.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
arch/s390/kernel/compat_wrapper.S |6 ++
arch/s390/kernel/syscalls.S |1 +
include/asm-s390/unistd.h
On Mon, Mar 12, 2007 at 10:23:06PM +1100, Con Kolivas wrote:
> > > > We are getting good interactive response with a fair scheduler yet
> > > > you seem intent on overloading it to find fault with it.
> > >
> > > I'm not trying to find fault, I'm TESTING AND REPORTING. Was.
> >
> > Con, could you
From: Ursula Braun <[EMAIL PROTECTED]>
[S390] cio: qdio slsb setup
Make sure set_slsb problems are handled correctly in
qdio_do_qdio_fill_input() and qdio_do_qdio_fill_output.
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
On Mon, Mar 12, 2007 at 02:29:43PM +0100, Michael Matz wrote:
> Hi Joerg,
>
> On Mon, 12 Mar 2007, Joerg Roedel wrote:
>
> > > >+#define RDTSCP ".byte 0x0f, 0x01, 0xf9"
> > > >+alternative_io_two("cpuid\nrdtsc",
> > > >+ "rdtsc", X86_FEATURE_SYNC_RDTSC,
> > > >+
Hello List,
running the following command
/sbin/grub-install --root-directory=/mnt --no-floppy /dev/sda
from a nfsroot system with kernel 2.6.20.2 (x86_64) results in:
[ cut here ]
kernel BUG at fs/nfs/write.c:505!
invalid opcode: [1] SMP
CPU 0
Modules linked in:
On Mon, Mar 12, 2007 at 02:36:46PM +0200, Pekka Enberg wrote:
> On 3/12/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >So, maybe it's less evil to check those NULLs where possible and add
> >some WARN_ONs here and there...
>
> No, it's much better to oops rather than paper over a bug.
>
I'm
Hi Joerg,
On Mon, 12 Mar 2007, Joerg Roedel wrote:
> > >+#define RDTSCP ".byte 0x0f, 0x01, 0xf9"
> > >+ alternative_io_two("cpuid\nrdtsc",
> > >+ "rdtsc", X86_FEATURE_SYNC_RDTSC,
> > >+ ".byte 0x0f, 0x01, 0xf9", X86_FEATURE_RDTSCP,
> > >
> >
> > why
Hi Honza,
On Mon, 12 Mar 2007, Jan Kara wrote:
> > +#define VM_REVOKED 0x0400 /* Mapping has been revoked */
> > +
> Is it intended to conflict with VM_ALWAYSDUMP? I'd guess not and if
> yes, it definitely deserves a comment...
Peter Zijlstra spotted this also and it has been fixed in
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: lockdep question (was Re: IPoIB caused a kernel: BUG: softlockup
> detected on CPU#0!)
>
>
> * Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
>
> > > So either there are other sites that instanciate those objects and
> > > forget about
Oleg Nesterov wrote:
> On 03/12, Rafael J. Wysocki wrote:
>> On Monday, 12 March 2007 09:14, Pavel Machek wrote:
>>> Can we get better name for this function?
>> Well, I took the name from the Oleg's message. Can you please suggest
>> something?
>
> Well, kthread_should_stop_check_freeze() is
try acpi=off please.
On 3/12/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
I went from 2.6.18-rc5-mm1 to 2.6.21-rc3-mm2
The computer now hangs solid during boot, at this point:
usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0
On Mon, Mar 12, 2007 at 12:07:18PM +, Alistair John Strachan wrote:
> On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
> > On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> > > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > > -d 1
Hi,
> This adds special handling for revoked memory mappings. We want to
> raise SIGBUS when accessing revoked mappings and return ENODEV when
> trying to remap with mmap(2).
>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
> include/linux/mm.h |2 ++
> mm/memory.c|3
> > There's a substantial performance hit for not yield, so we probably
> > want to investigate alternate semantics for it. It seems reasonable
> > for apps to say "let me not hog the CPU" without completely expiring
> > them. Imagine you're in the front of the line (aka queue) and you
> > spend
On Mon, Mar 12, 2007 at 02:09:18PM +0100, Andi Kleen wrote:
> On Monday 12 March 2007 14:02, Joerg Roedel wrote:
> > On Fri, Mar 09, 2007 at 08:10:03PM +0200, Avi Kivity wrote:
> > > Joerg Roedel wrote:
> > > >From: Joerg Roedel <[EMAIL PROTECTED]>
> > > >
> > > >This patch simplifies the
Gene Heskett <[EMAIL PROTECTED]> writes:
> If, and I have previously, I revert to a 2.6.20-ck1 patching, this does
> not occur. So my contention is that someplace in this recent progression
> from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how
> c-time is being reported to
On Monday 12 March 2007 14:02, Joerg Roedel wrote:
> On Fri, Mar 09, 2007 at 08:10:03PM +0200, Avi Kivity wrote:
> > Joerg Roedel wrote:
> > >From: Joerg Roedel <[EMAIL PROTECTED]>
> > >
> > >This patch simplifies the get_cycles_sync() function by removing
> > >the #ifdefs from it. Further it
>
> Hello Vincent,
>
> As it seems the 5s net gain is during the early phase of the
> boot process, could you please post longer dmesgs, to let us
> know where the gain occurs ?
Hi Paul,
Here is an sdiff between the two dmesg:
[0.00] Linux version 2.6.18.8-amd64-envcan-003 (root@ | [
> Andi, have you had a look at this? I'm a bit surprised at the lack of
> reaction to this find..
FYI the problem is still being analysed behind the scenes. Chip's patch didn't
fix
it in all cases unfortunately -- it just changed the timing enough to make it
happen
less often. The latest
On Fri, Mar 09, 2007 at 08:10:03PM +0200, Avi Kivity wrote:
> Joerg Roedel wrote:
> >From: Joerg Roedel <[EMAIL PROTECTED]>
> >
> >This patch simplifies the get_cycles_sync() function by removing
> >the #ifdefs from it. Further it introduces an optimization for AMD
> >processors. There the RDTSCP
I went from 2.6.18-rc5-mm1 to 2.6.21-rc3-mm2
The computer now hangs solid during boot, at this point:
usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0
alt 0 proto 2 vid 0x04B8 pid 0x0007
usb 1-3: new high speed USB device
"Tosoni" <[EMAIL PROTECTED]> writes:
> It has always been the standard for all modems.
Look, I've been using various modems for many years, starting with
self-made 300 bps one and there were basically 3 options:
- no flow control at all (no buffering etc), RTS/CTS disabled/missing,
- XON/XOFF
On Monday 12 March 2007 22:26, Al Boldi wrote:
> Con Kolivas wrote:
> > On Monday 12 March 2007 15:42, Al Boldi wrote:
> > > Con Kolivas wrote:
> > > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > > And thank you! I think I know what's going on now. I think each
> > > > > rotation is
Your message dated Mon, 12 Mar 2007 07:37:15 -0500 with subject "Message
could not be delivered" has been submitted to the moderator of the SPORTS
list: John Hartrick <[EMAIL PROTECTED]>.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> Could you check if this is the same problem as this one:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8169
Looks like it except that I don't see "lost interrupt" messages here. So,
it might be something
On Mon, Mar 12, 2007 at 01:21:03PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > > > the issue is this: your fix reduces the effects of the bug but
> > > > > it is still fundamentally incomplete because of the use of
> > > > > timer_list. So
> > > >
> > > >
On 3/12/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
So, maybe it's less evil to check those NULLs where possible and add
some WARN_ONs here and there...
No, it's much better to oops rather than paper over a bug.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
I happened to read the entire thread (@ http://lkml.org/lkml/2007/3/1/159)
all over again and felt it may be usefull to summarize the discussions so far.
If I have missed any imp. points or falsely represented someone's view
(unintentionally of course!), then I would be glad to be corrected.
1.
On 03/12, Rafael J. Wysocki wrote:
>
> On Monday, 12 March 2007 09:14, Pavel Machek wrote:
> >
> > Can we get better name for this function?
>
> Well, I took the name from the Oleg's message. Can you please suggest
> something?
Well, kthread_should_stop_check_freeze() is really awful, I agree
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > the issue is this: your fix reduces the effects of the bug but
> > > > it is still fundamentally incomplete because of the use of
> > > > timer_list. So
> > >
> > > But using schedule_timeout is not a bug. Userspace timeouts are
> > > always
Cong WANG wrote:
Use NULL to indicate we are returning a pointer rather than an integer
and to eliminate some sparse warnings.
Signed-off-by: Cong WANG <[EMAIL PROTECTED]>
These are already fixed in my repo.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe
On 3/9/07, David Miller <[EMAIL PROTECTED]> wrote:
> The whole cahce-multipath subsystem has to have it's guts revamped for
> proper error handling.
(Untested patch follows.)
From: Amit Choudhary <[EMAIL PROTECTED]>
Check the return value of kmalloc() in function wrandom_set_nhinfo(),
in file
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Thanks,
Bart
On Monday 12 March 2007, Frank van Maarseveen wrote:
> On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> >
> > 2.6.19 is ok, 2.6.20.[12] hangs from
On Mon, Mar 12, 2007 at 12:23:00PM +0300, Dmitriy Monakhov wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
> >> Nick Piggin <[EMAIL PROTECTED]> writes:
> >>
> >> > On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
> On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > -d 1 /dev/hda):
> >
> > hda: dma_timer_expiry: dma status == 0x20
> > hda: DMA
On 12/03/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
On Monday 12 March 2007, Gene Heskett wrote:
>To Con, I knew 2.6.20 worked with your earlier patches, so rather than
>revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going
>to fire off another backup. I suspect it will work,
On Mon, 12 Mar 2007, Stefan Richter wrote:
> Rusty Russell wrote:
> > On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
> >> I have to admit that I don't see the point here - I can't seem to make
> >> any sense of the OR... Jan
> >
> > At least one other person thought that:
> >
> >
On Mon, Mar 12, 2007 at 12:38:29PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > the issue is this: your fix reduces the effects of the bug but it is
> > > still fundamentally incomplete because of the use of timer_list. So
> >
> > But using schedule_timeout is
On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>>On 3/11/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>>
>>> Just to comment, I've been running one of the patches between 20-ck1
>>> and this
On 09-03-2007 08:29, David Miller wrote:
> From: Amit Choudhary <[EMAIL PROTECTED]>
> Date: Thu, 8 Mar 2007 23:22:15 -0800
>
>> Description: Check the return value of kmalloc() in function
>> wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c.
>>
>> Signed-off-by: Amit Choudhary <[EMAIL
> > I have no idea how serious the scalability problems with this are. If
> > they are serious, different solutions can probably be found for the
> > above, but this is certainly the simplest.
>
> Atomic operations to a single per-backing device from all CPUs at once?
> That's a pretty serious
Rusty Russell wrote:
> On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
>> I have to admit that I don't see the point here - I can't seem to make
>> any sense of the OR... Jan
>
> At least one other person thought that:
>
> #define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
>
>
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > the issue is this: your fix reduces the effects of the bug but it is
> > still fundamentally incomplete because of the use of timer_list. So
>
> But using schedule_timeout is not a bug. Userspace timeouts are always
> defined to be "at least".
but
Mathieu Bérard wrote:
> Jeff Garzik a écrit :
>> Adrian Bunk wrote:
>>> Subject: NCQ problem with ahci and Hitachi drive
>>> References : http://lkml.org/lkml/2007/3/4/178
>>> Submitter : Mathieu Bérard <[EMAIL PROTECTED]>
>>> Status : unknown
>> according to the last message in that
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > if HIGH_RES_TIMERS is disabled then that is what happens. But
> > frankly,
>
> disabled? I would expect it (= more wakeups) when hrtimers are
> enabled.
i mean the groupping of timer expiries happens automatically when
high-res is disabled. When
On Mon, Mar 12, 2007 at 12:19:58PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > even if this means more work for you (i'm sorry about that!) i'm
> > > quite sure we should take Sebastien's hrtimers based implementation
> > > of futex_wait(), and use the
On Mon, 2007-03-12 at 12:08 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > The test scenario was one any desktop user might do with every
> > expectation responsiveness of the interactive application remain
> > intact. I understand the concepts here Con, and I'm
Con Kolivas wrote:
> On Monday 12 March 2007 15:42, Al Boldi wrote:
> > Con Kolivas wrote:
> > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > And thank you! I think I know what's going on now. I think each
> > > > rotation is followed by another rotation before the higher priority
> >
On Monday 12 March 2007 22:08, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > The test scenario was one any desktop user might do with every
> > expectation responsiveness of the interactive application remain
> > intact. I understand the concepts here Con, and I'm not
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
>
> 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> -d 1 /dev/hda):
>
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
>
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Mon, 12 Mar 2007 04:12:32 -0700 (PDT)
> On Sun, 11 Mar 2007, David Miller wrote:
>
> > I'm going to make the radical declaration that it be perhaps often
> > better to always initialize page table chunks to all zeros on
> > allocation.
>
> That
301 - 400 of 980 matches
Mail list logo
