On Thu, 30 Aug 2007 04:07:11 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> 1. Several people recommended it
> 2. Herbert mentioned that they've moved to that interface and it
>was working fine for them.
>
I have no strong opinion. But how about Mega bytes ? (too big ?)
There will be no
My current view of the IO stack is the following:
-- -- --
-- -
|NET_PCI_BACK| |BLK_PCI_BACK| |9P_PCI_BACK| |NET_FRONT|
|BLK_FRONT| |9P_FRONT|
-- -- --
On Wed, 29 Aug 2007, Matthew Wilcox wrote:
>
> I've long hated the non-killability of tasks accessing a dead
> NFS server. Linus had an idea for fixing this way back in 2002:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0167.html which
> I've prototyped in this patch.
Hey, I
Adrian Bunk wrote
> Tracking feature or implementation suggestions wouldn't make sense.
> Consider e.g. that there are several people on linux-kernel who often
> write what they think the kernel should do but who never write a single
> line of code themselves. There's no value in tracking such
Alan Cox wrote:
> Daniel Exner <[EMAIL PROTECTED]> wrote:
>> Attached patch will add above mentioned Laptop Model to whitelist for both
>> pata_ali and alim15x3, as it is correctly detected as 40-wire connected
>> but this cable is short enough to still do transfers higher than UDMA33.
>
> Looks
On 8/29/07, Andres Salomon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here are a bunch of fixes for the cs5535audio driver. None of these are
> OLPC specific; generic chip and power management fixes, and one cleanup
> patch. All have been tested on an OLPC (5536), so even though the 5535
> data sheet
We really only care about the first two bus masters (playback and capture).
There's no need to have unused BM code lying around, so let's get rid of it.
If for some reason we trigger an IRQ for some BM that we're not using.. well,
that warrants spitting out an error message (imo).
In the suspend path, we currently save the PRD registers and then disable DMA.
This is racy; the sound hardware might update the PRD register as it finishes
processing some DMA pages between when we've saved the PRD registers and
when DMA actually gets disabled. Furthermore, we actively check
Save the PCI state before disabling the device, and add some error checking.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
sound/pci/cs5535audio/cs5535audio_pm.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/sound/pci/cs5535audio/cs5535audio_pm.c
ACcording to 6.3.2.7 of the cs5535/cs5536 data sheets, the ACC_BM[x]_CMD
registers are only 8 bits wide. This driver treats them as 32 bits wide,
and also has bits in the wrong place. Simple fix to the definitions.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
On Wed, 2007-08-29 at 20:09 -0700, Hua Zhong wrote:
> I am in the process of bisecting now. It takes a while but the bad commit is
> between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll
> continue tomorrow.
>
> My system is FC4.
>
> autofs-4.1.4-26
>
We're never actually setting dma->substream to the current substream; that
means the dma->substream checks that we do in the suspend/resume path
are never satisfied, and the PRD registers are never correctly managed. This
changes it so that we set the substream when constructing the specific
bus
Hi,
Here are a bunch of fixes for the cs5535audio driver. None of these are
OLPC specific; generic chip and power management fixes, and one cleanup
patch. All have been tested on an OLPC (5536), so even though the 5535
data sheet claims to be the same, it would be nice to hear success/failure
Eduard-Gabriel Munteanu wrote:
> *This message was transferred with a trial version of CommuniGate(r) Pro*
> This might have been discussed a few years ago, but things have changed.
> I'm talking about patches like this one (I'm not the author):
> http://developer.osdl.org/dev/fumount/#kernel1
>
I am in the process of bisecting now. It takes a while but the bad commit is
between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll
continue tomorrow.
My system is FC4.
autofs-4.1.4-26
nfs-utils-1.0.7-13.FC4
By the way, the particular autofs commit Andrian sent is
Hi,
On Wed, 29 Aug 2007, Sam Ravnborg wrote:
> > > > I've noticed an oddity with CONFIG_HOTPLUG_CPU in 2.6.23-rc:
> > > > make oldconfig seems to turn it on even when nothing wants it,
> > > > increasing kernel size by about 10k; but if you then edit the
> > > > line out of .config and make
On Thu, 2007-08-30 at 00:47 +0200, Adrian Bunk wrote:
> On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote:
>
> > Hi,
>
> Hi Hua,
>
> > I am wondering if this is a known issue, but I just built the current git
> > and several autofs mounts mysteriously disappeared. Restarting autofs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morton wrote:
> So it's an interaction between the x86_64 vdso patches in Andi's tree and
> newer glibc, and we don't know which one is getting it wrong yet?
glibc does nothing but call the code in the vdso. We have a function
pointer
From: Divy Le Ray <[EMAIL PROTECTED]>
Load the engine microcode when an interface
is brought up, instead of of doing it when the module
is loaded.
Loosen up tight binding between the driver and the
engine microcode version.
There is no need for microcode update with T3A boards.
Fix the file
From: Divy Le Ray <[EMAIL PROTECTED]>
cxgb3 used netdev_priv() and dev->priv for different purposes.
In 2.6.23, netdev_priv() == dev->priv, cxgb3 needs a fix.
This patch is a partial backport of Dave Miller's changes in the
net-2.6.24 git branch.
Without this fix, cxgb3 crashes on 2.6.23.
Jeff,
I'm resubmitting the cxgb3 dev->priv issue.
I'm also submitting a patch fixing the engine microcode loading.
The first patch changes in both cxgb3 and iw_cxgb3 related to
the dev->priv issue.
The second patch allows the driver to load the engine microcode
at the right time - when a port
Pete/Piet Delaney wrote:
We are getting a problem with VMware where kernel text is the schedler
is getting wacked with four null bytes into the code. Thought I'd use
the current linux-2.6-kgdb.git tree and possible the CONFIG_DEBUG_RODATA
patch to make kernel text readonly:
On Wed, 29 Aug 2007 19:33:48 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote:
> >
> >> http://bugzilla.kernel.org/show_bug.cgi?id=8957
> >>
> >>Summary: Exported functions and variables should
Pete/Piet Delaney wrote:
Why am I getting this when I do:
git clone
http://master.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
I have only ever used:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git
Jason.
-
To unsubscribe from this
*This message was transferred with a trial version of CommuniGate(r) Pro*
This might have been discussed a few years ago, but things have changed.
I'm talking about patches like this one (I'm not the author):
http://developer.osdl.org/dev/fumount/#kernel1
The current situation requires a way
On Wed, 29 Aug 2007 18:19:29 -0700 Pete/Piet Delaney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Pete/Piet Delaney wrote:
> > Jason Wessel wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 22 Aug 2007 17:44:12 -0500
> >>> Jason Wessel <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
>
2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>:
> On Tue, Aug 28, 2007 at 12:01:30PM -0400, Jiri Slaby wrote:
> > +config ATH5K_AR5210
> > + bool "Support AR5210"
> > + depends on ATH5K
> > + default y
> > +
> > +config ATH5K_AR5211
> > + bool "Support AR5211"
> > + depends
Daniel Drake wrote:
On Wed, 2007-08-29 at 07:30 -0700, Arjan van de Ven wrote:
My experiments show that when there is not much free physical memory,
swapoff moves pages out of swap at a rate of approximately 5mb/sec.
sounds like about disk speed (at random-seek IO pattern)
We are only using
Andrew Morton wrote:
On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8957
Summary: Exported functions and variables should not be reachable
by the outside of the module until module_init finishes
Hi,
>On 8/23/07, Takashi Iwai <[EMAIL PROTECTED]> wrote:
> At Wed, 22 Aug 2007 22:23:03 +0200,
> Mariusz Kozlowski wrote:
> >
> > Hello,
> >
> > This is from x86_32 with gcc 3.4.6:
> >
> > CC [M] sound/pci/hda/hda_codec.o
> > sound/pci/hda/hda_codec.c: In function `snd_hda_codec_free':
>
On Wed, 2007-08-29 at 14:24 -0700, Stephane Eranian wrote:
> Now on Core Duo, there is no PEBS anyway, so it is okay to use counter 0
> for NMI. The problem is that the detection code in perfctr-watchdog.c
> treats a Core Duo and a Core 2 Duo the same way as they both have the
>
On Wed, Aug 29, 2007 at 05:39:18PM -0400, Jeff Moyer wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Tue, Aug 21, 2007 at 03:48:42PM -0400, Jeff Moyer wrote:
> >> Hi,
> >>
> >> A while back, Nick Piggin introduced a patch to reduce the node memory
> >> usage for small files (commit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete/Piet Delaney wrote:
> Jason Wessel wrote:
>> Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 17:44:12 -0500
>>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>>
>>>
+while (!atomic_read(_active));
>>> eek. We're in the process of
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
> local_t Documentation update 2
>
> Grant Grundler was asking for more detail about correct usage of local atomic
> operations and suggested adding the resulting summary to local_ops.txt.
>
> "Please add a bit more detail. If
On Wed, 29 Aug 2007, Mingming Cao wrote:
> It's quite simple to support large block size in ext2/3/4, mostly just
> enlarge the block size limit. But it is NOT possible to have 64kB
> blocksize on ext2/3/4 without some changes to the directory handling
> code. The reason is that an empty 64kB
On Fri, 2007-08-10 at 08:14 -0600, Gregory Haskins wrote:
> ---
>
> include/linux/sched.h |7 +--
> kernel/latency_trace.c | 18 +++---
> 2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> To summarize more clearly, I think that so long as we support
> process trees with a sort of !SECURE_NOROOT support, that
> support should include the ability to use prctl(KEEP_CAPS) the
> way one uses it now.
> When a
[3/4] ext3: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext3/dir.c | 13 ---
fs/ext3/namei.c | 88
[4/4] ext4: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/dir.c | 11 --
fs/ext4/namei.c | 88
[2/4] ext2: fix rec_len overflow
- prevent rec_len from overflow with 64KB blocksize
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext2/dir.c | 46 --
The next 4 patches support large block size (up to PAGESIZE, max 64KB)
for ext2/3/4, originally from Takashi Sato.
http://marc.info/?l=linux-ext4=115768873518400=2
It's quite simple to support large block size in ext2/3/4, mostly just
enlarge the block size limit. But it is NOT possible to have
On 2007.08.29 10:49:12 -0700, Christoph Lameter wrote:
> On Wed, 29 Aug 2007, Peter Lund wrote:
>
> >
> > - if (tmp >= RADIX_TREE_INDEX_BITS)
> > - index = ~0UL;
> > - return index;
> > + if (shift < 0)
> > + return ~0UL;
> > + if (shift >= 8 * sizeof(unsigned long))
On Thu, 30 Aug 2007, Adrian Bunk wrote:
> Christoph, is your fix in -mm suitable for 2.6.23, or how else should
> this regression be fixed for 2.6.23?
Looks like this is just alpha and a certain particular compiler version?
You may get away with adding
void __kmalloc_size_too_large(void)
{
On 8/29/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Aug 2007, Yan Burman wrote:
> HDAPS with input device support is quite new. hdapsd was patched to talk to
> it, too. I suppose we should port the input device support to the driver
> in-tree just so that we get it
I've updated to 2.6.23-rc4 .. This is an "Ingo appears to be busy.."
release .. I've been waiting for a -rt update , but there hasn't been
one for a while. So my tree is the best everyone will get for now.
ftp://source.mvista.com/pub/dwalker/rt/patch-2.6.23-rc4-dw1
On Wed, 29 Aug 2007, Mingming Cao wrote:
> > Known internal limitations:
> >
> > Ext264k
> > XFS 64k
> > Reiserfs8k
> > Ext34k (rumor has it that changing a constant can remove the
> > limit)
> > Ext44k
> >
>
> There are patches original
On Thu, 30 Aug 2007, Adrian Bunk wrote:
> > CC init/version.o
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/alpha/kernel/built-in.o(.text+0xaaa8): In function
> > `pdev_save_srm_config':
> > include/linux/slub_def.h:154: undefined reference to
> >
On Tue, 2007-08-28 at 12:06 -0700, [EMAIL PROTECTED] wrote:
> plain text document attachment (0031-Large-Blocksize-Core-piece.patch)
> Provide an alternate definition for the page_cache_xxx(mapping, ...)
> functions that can determine the current page size from the mapping
> and generate the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete/Piet Delaney wrote:
> Jason Wessel wrote:
>> Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 17:44:12 -0500
>>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>>
>>>
+while (!atomic_read(_active));
>>> eek. We're in the process of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Wessel wrote:
> Andrew Morton wrote:
>> On Wed, 22 Aug 2007 17:44:12 -0500
>> Jason Wessel <[EMAIL PROTECTED]> wrote:
>>
>>
>>> +while (!atomic_read(_active));
>>>
>>
>> eek. We're in the process of hunting down and eliminating
> Bugzilla is for tracking bugs, not for discussing possible
> kernel features.
True, but some of them are categorized as bugs from the reporter's
prospective, when they say "man page says" or "according to POSIX it's
wrong". I am going to push ones that are feature suggestions,
re-design
On Aug 29, 2007, at 19:01:57, Eric Sandeen wrote:
Jesper Juhl wrote:
A first step could be to allocate those two char arrays with
kmalloc() instead of on the stack, but then I guess that dump_stack
() gets called from places where we may not really want to be
calling kmalloc(). I guess we
On Wed, Aug 29, 2007 at 08:04:52PM +0200, Jan Dittmer wrote:
> Michal Piotrowski wrote:
> > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa)
> > References : http://lkml.org/lkml/2007/8/6/43
> > Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6
> > Submitter
On 08/24/2007 02:04 PM, Greg KH wrote:
>> I don't understand. The history for stable/linux-2.6.22.y.git at
>> http://git.kernel.org shows that the commit for my patch, labelled
>>
>> 6b30a4e1c357410a78d7bcb831743b0e99bab4ad,
>>
>> includes both hunks. And patch-2.6.22.5.bz2 includes both as
On Wed, 29 Aug 2007, Yan Burman wrote:
> I don't mind doing it this way, it's just that from what I saw all
> current applications use the sys interface, so I figured that people
> would like to be able to use those.
Well, they will have to fix their applications to use the input device, if
the
On Wed, Aug 29, 2007 at 08:04:52PM +0200, Jan Dittmer wrote:
> Michal Piotrowski wrote:
> > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa)
> > References : http://lkml.org/lkml/2007/8/6/43
> > Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6
> > Submitter
Some shipped files were wrongly ignored by git.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
.gitignore |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
45a1318453ecc5fa346d323e8d806a5630a7191c
diff --git a/.gitignore b/.gitignore
index 27c3e83..80d891b 100644
---
On Mon, Aug 20, 2007 at 02:16:46AM +0200, Andi Kleen wrote:
> On Mon, Aug 20, 2007 at 01:01:36AM +0200, Adrian Bunk wrote:
> > On Wed, Aug 01, 2007 at 09:10:37PM +0200, Adrian Bunk wrote:
> > > On Wed, Aug 01, 2007 at 11:07:53PM +0400, Alexey Dobriyan wrote:
> > > > On Wed, Aug 01, 2007 at
On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8957
>
>Summary: Exported functions and variables should not be reachable
> by the outside of the module until module_init finishes
>Product:
Il Wed, Aug 29, 2007 at 01:29:56AM +0200, Daniel Ritz ha scritto:
> tried that one on my old toshiba tecra 8000 laptop, almost killing it.
> the fan doesn't work any more...type 'make' and see the box dying.
> luckily my CPU doesn't commit suicide...bisected it to that one:
>
>
On Wed, 29 Aug 2007 13:37:38 -0400 [EMAIL PROTECTED] wrote:
> On Wed, 29 Aug 2007 10:04:33 EDT, [EMAIL PROTECTED] said:
>
> (Fixing the Subject: and updating the info)
>
> > On Wed, 22 Aug 2007 02:06:48 PDT, Andrew Morton said:
> > >
On Aug 28, 2007, at 6:20 AM, Jochen Friedrich wrote:
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
This has been posted to linuxppc-embedded by Marcelo Tosatti
<[EMAIL
Jesper Juhl wrote:
>> Any suggestions for ways around this? The warning is somewhat helpful,
>> and I guess the obvious option is to lighten up the dump_stack path, but
>> it's still effectively reducing precious available stack space by some
>> amount.
>>
> A first step could be to allocate
On Wed, 29 Aug 2007 05:55:16 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On a serious note, James, I think you mis-spoke when you said that
> Andrew Morton's term was up this year.
In that case I hereby quit ;) My contribution to the TAB has been practically
zero and I don't expect that
On 30/08/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW
> config options is a bit deadly.
>
> DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the
> end of useable stack space, or 512 bytes on a 4k stack.
>
Currently, if the refresh rate is not specified, fb_find_mode() returns
the first known video mode with the requested resolution, which provides
no guarantees wrt the refresh rate. Change this so that the mode with
the highest refresh rate is returned when the driver provides a custom
video mode
On Wed, 29 Aug 2007 11:46:04 +0100 Alan Cox <[EMAIL PROTECTED]> wrote:
> > >> adequate job of warning our users. A printk when we run a program
> > >> that uses the binary interface and an long enough interval the warning
> > >> makes it to the Enterprise kernels before we remove the interface
>
On Wed, Aug 29, 2007 at 01:58:58PM -0700, Hua Zhong wrote:
> Hi,
Hi Hua,
> I am wondering if this is a known issue, but I just built the current git
> and several autofs mounts mysteriously disappeared. Restarting autofs could
> fix some, but then lose others. 2.6.22 was fine.
>
> Is there
Dave Hansen wrote:
> On Thu, 2007-08-30 at 03:57 +0530, Balbir Singh wrote:
>> True, mmap() is a good example of such an interface for developers, I
>> am not sure about system admins though.
>>
>> To quote Andrew
>>
>> Reporting tools could run getpagesize() and do the arithmetic, but we
>>
Dave Hansen wrote:
> On Wed, 2007-08-29 at 15:20 -0700, Paul Menage wrote:
>> I'd argue that having the user's specified limit be truncated to the
>> page size is less confusing than giving an EINVAL if it's not page
>> aligned.
>
> Do we truncate mmap() values to the nearest page so to not
On Thu, 2007-08-30 at 03:57 +0530, Balbir Singh wrote:
> True, mmap() is a good example of such an interface for developers, I
> am not sure about system admins though.
>
> To quote Andrew
>
> Reporting tools could run getpagesize() and do the arithmetic, but we
> generally try to avoid exposing
Takashi Iwai wrote:
At Wed, 29 Aug 2007 18:42:56 +0300,
Ivan N. Zlatev wrote:
On 8/29/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
ALSA
Subject : Master volume control broken
References : http://lkml.org/lkml/2007/8/18/46
Last known good : ?
Submitter : Thomas Meyer
Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW
config options is a bit deadly.
DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the
end of useable stack space, or 512 bytes on a 4k stack.
If we are, then it goes down the dump_stack path, which uses
Sorry for the delay, I am out of town for a few weeks, and am away from network
connectivit at the moment. I'll get this out in a few days when I return to
civilization.
Thanks,
Greg k-h
Sent via BlackBerry by AT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Dave Hansen wrote:
> On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote:
>> I've thought about this before. The problem is that a user could
>> set his limit to 1 bytes, but would then see the usage and
>> limit round to the closest page boundary. This can be confusing
>> to a user.
>
>
On Wed, 2007-08-29 at 15:20 -0700, Paul Menage wrote:
>
> I'd argue that having the user's specified limit be truncated to the
> page size is less confusing than giving an EINVAL if it's not page
> aligned.
Do we truncate mmap() values to the nearest page so to not confuse the
user? ;)
Imagine
On Wed, Aug 29, 2007 at 12:42:02AM -0700, Natalie Protasevich wrote:
>...
> Then I think bugzilla needs:
> adding more categories such as security,
"security" would be a flag like "regression", not a category.
> system calls (lots of
> implementation suggestions for posix and non-posix
On 8/29/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote:
> > I've thought about this before. The problem is that a user could
> > set his limit to 1 bytes, but would then see the usage and
> > limit round to the closest page boundary. This can
On Monday, 27 August 2007 23:47, Rafael J. Wysocki wrote:
> Hi,
>
> The patches in this series are intended to improve the handling of the ACPI
> platform during suspend and hibernation.
>
> They do the following things:
> * make hibernation_platform_enter() consistent with the sleep state
On Thu, 2007-08-30 at 03:34 +0530, Balbir Singh wrote:
> I've thought about this before. The problem is that a user could
> set his limit to 1 bytes, but would then see the usage and
> limit round to the closest page boundary. This can be confusing
> to a user.
True, but we're lying if we
Dave Hansen wrote:
> On Wed, 2007-08-29 at 16:40 +0530, Balbir Singh wrote:
>>
>> @@ -352,7 +353,7 @@ int mem_container_charge(struct page *pa
>> kfree(pc);
>> pc = race_pc;
>> atomic_inc(>ref_cnt);
>> - res_counter_uncharge(>res, 1);
On Wed, Aug 29, 2007 at 05:27:39PM +0200, Michal Piotrowski wrote:
> FS
>
> Subject : [NFSD OOPS] 2.6.23-rc1-git10
> References : http://lkml.org/lkml/2007/8/2/462
> Last known good : ?
> Submitter : Andrew Clayton <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
Hi!
I'm a newbie here on the list and also as a "kernel hacker". There's a
bug reported in bugzilla (Bug 7927), cite:
> In the function __down
>
> fastcall void __sched __down(struct semaphore * sem)
> {
> struct task_struct *tsk = current;
> DECLARE_WAITQUEUE(wait, tsk);
> unsigned long
Pavel Emelianov [EMAIL PROTECTED] wrote:
| The sync_master_pid and sync_backup_pid are set in set_sync_pid()
| and are used later for set/not-set checks and in printk. So it
| is safe to use the global pid value in this case.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Acked-by:
On Wed, 29 Aug 2007 23:41:13 +0200
Daniel Exner <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Please CC me, as I'm currently not subscribed to this list, thx.
>
> Attached patch will add above mentioned Laptop Model to whitelist for both
> pata_ali and alim15x3, as it is correctly detected as 40-wire
--- Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 08/28/2007 11:53 AM, Martin Knoblauch wrote:
> >
> > The basic setup is a dual x86_64 box with 8 GB of memory. The
> DL380
> > has a HW RAID5, made from 4x72GB disks and about 100 MB write
> cache.
> > The performance of the block device with
Hi!
Please CC me, as I'm currently not subscribed to this list, thx.
Attached patch will add above mentioned Laptop Model to whitelist for both
pata_ali and alim15x3, as it is correctly detected as 40-wire connected but
this cable is short enough to still do transfers higher than UDMA33.
Don't
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Tue, Aug 21, 2007 at 03:48:42PM -0400, Jeff Moyer wrote:
>> Hi,
>>
>> A while back, Nick Piggin introduced a patch to reduce the node memory
>> usage for small files (commit cfd9b7df4abd3257c9e381b0e445817b26a51c0c):
>>
>> -#define
Pavel Emelianov [EMAIL PROTECTED] wrote:
| The pktgen_thread.pid is set to current->pid and is never used
| after this. So remove this at all.
|
| Found during isolating the explicit pid/tgid usage.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Good observation that its not being used
Daniel,
On Tue, Aug 28, 2007 at 01:13:44PM -0700, Daniel Walker wrote:
> On Tue, 2007-08-28 at 12:46 -0700, Stephane Eranian wrote:
>
> > I think I found the problem. As I suspected, it seems there is an assymetry
> > between the 1st end 2nd counter (just like what they have on P6 core). Yet
> >
On Wed, 29 Aug 2007 15:06:43 MDT, Eric W. Biederman said:
> So we have to figure out how to do the hard thing which is look at
> who opened our netlink broadcast see if they are in the same user
> namespace as current->user. Which is a pain and we don't currently
> have the infrastructure for.
Pavel Emelianov [EMAIL PROTECTED] wrote:
| This is a lost hunk of previous patch that isolated the
| explicit usage of task->tgid in some places. The signalfd
| code uses the tsk->tgid comparison.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Acked-by: Sukadev Bhattiprolu <[EMAIL
Jan Kara <[EMAIL PROTECTED]> writes:
>
>> However I'm still confused about the use of current->user. If that
>> is what we really want and not the user who's quota will be charged
>> it gets to be a really trick business, because potentially the uid
>> we want to deliver varies depending on who
Xu Yang wrote:
does anyone know from which address does the kernel load the initrd? I
mean the default value?
I want to boot the filesystem using a ramdisk. but the I don't know
where to put it in my ram? as I don't have flash , I can only load the
ramdisk into the ram.
and which boot option
Hi,
I am wondering if this is a known issue, but I just built the current git
and several autofs mounts mysteriously disappeared. Restarting autofs could
fix some, but then lose others. 2.6.22 was fine.
Is there anything I could check other than bisect? (It may take some time
for me to get to
On Wednesday 29 August 2007 21:45:01 Alexey Starikovskiy wrote:
> If you could open a bugreport at bugzilla.kernel.org in ACPI category
> and attach
> dmesg and acpidump output, that would help a lot. (I hope :( )
>
done. http://bugzilla.kernel.org/show_bug.cgi?id=8958
> Thanks,
> Alex.
>
>
does anyone know from which address does the kernel load the initrd? I
mean the default value?
I want to boot the filesystem using a ramdisk. but the I don't know
where to put it in my ram? as I don't have flash , I can only load the
ramdisk into the ram.
and which boot option should I use?
I've long hated the non-killability of tasks accessing a dead
NFS server. Linus had an idea for fixing this way back in 2002:
http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0167.html which
I've prototyped in this patch.
Splitting up TASK_* into separate bits is going to need a lot more
If the stack pointer is 0xc057a000, then the first stack page is at
0xc0579000 (the stack pointer is decremented before use). Not
calculating this correctly caused guests with CONFIG_DEBUG_PAGEALLOC=y
to be killed with a "bad stack page" message: the initial kernel stack
was just proceeding the
On Wed, Aug 29, 2007 at 10:43:53PM +0300, Thomas Backlund wrote:
> Greg KH skrev:
> >This is the start of the stable review cycle for the 2.6.22.6 release.
> >There are 28 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied,
1 - 100 of 568 matches
Mail list logo
