Jeff Garzik wrote:
> This also opens a chicken-and-egg problem... What kind of config is
> generated by allmodconfig when ARCH==x86? There is no good answer.
With a unified x86 architecture, the decision to compile with 32 or
64-bit mode isn't really different from SMP vs UP, PAE vs non-PAE and
Hi,
On Wednesday 08 August 2007 15:32, Bill Nottingham wrote:
> Kay Sievers ([EMAIL PROTECTED]) said:
> > It doesn't have any aliases, so seems it was never autoloaded.
>
> It was - prior kernels loaded it via the uevent generated from
> /devices/platform/pcspkr. Newer kernels seem to never
There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
entries) using a simple ls -l.
On 2.6.23 client and server running userland rpc.nfs.V2:
first try: time -p ls -l <2k+ entry dir> in ~2.5sec
more tries: time -p ls -l <2k+ entry dir> in ~8sec
first try: time -p ls -l
The permissions of i2c module parameters were set to zero making the
parameters invisible and unsettable from the kernel command line. This
patch changes the permissions to the standard 0644 read/write.
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
diff --git a/include/linux/i2c.h
Building with the attached .config on x86-64, it does this:
CC arch/um/kernel/smp.o
In file included from include/asm/arch/tlb.h:11,
from include/asm/tlb.h:4,
from arch/um/kernel/smp.c:8:
include/asm-generic/tlb.h: In function ‘tlb_flush_mmu’:
Tejun Heo wrote:
> Daniel Drake wrote:
>
>>Tejun Heo wrote:
>>
<4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
<4> res
(cc'ing linuxppc-dev, see
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg221770.html
for original post and .config)
Elimar Riesebieter wrote:
> On Wed, 24 Oct 2007 the mental interface of
> Elimar Riesebieter told:
>
> [...]
> > The kernel is loaded from firmware but freezes at the
Hi,
On Thursday 01 November 2007, Ralf Baechle wrote:
> kernel/time/ntp.c contains the following piece of code:
>
> #define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
> #define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC)
> / \ (s64)CLOCK_TICK_RATE)
>
> static
On Sat, Nov 03, 2007 at 10:02:19PM -0400, Jeff Garzik wrote:
> Sam Ravnborg wrote:
>> This patchset unify the i386 and x86_64 Kconfig
>> files for x86.
>> In addition it replaces the use of ARCH=i386 and
>> ARCH=x86_64 with the more intuitive ARCH=x86.
>> The primary purpose of this patch serie is
Hi
Strange, that noone notice issue with popular for wireless board, WRAP2C.
Probably most of developers was fixing silently in their codebase and was not
supplying patch to mainline kernel.
The symptoms is easy, it just doesn't reboot in any case, till i apply patch.
Works for me.
Can anyone
Sam Ravnborg wrote:
This patchset unify the i386 and x86_64 Kconfig
files for x86.
In addition it replaces the use of ARCH=i386 and
ARCH=x86_64 with the more intuitive ARCH=x86.
The primary purpose of this patch serie is to
enable make ARCH=x86 and let the config decide
if we are building for
On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote:
> On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote:
> > Thomas Bächler schrieb:
> > >
> > > I just remembered, a friend of mine got it to compile with the exact
> > > same toolchain, but with a different configuration
On Sun, Nov 04, 2007 at 12:51:12AM +0100, Sam Ravnborg wrote:
>...
> --- a/arch/x86/Kconfig.x86_64
> +++ b/arch/x86/Kconfig.x86_64
>...
> # x86-64 doesn't support PCI BIOS access from long mode so always go direct.
> config PCI_DIRECT
> @@ -737,36 +723,11 @@ config PCI_DIRECT
> depends on
Zurk Tech wrote:
dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
A few unrelated observations about Barcelona support...
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the
On Sun, Nov 04, 2007 at 12:51:11AM +0100, Sam Ravnborg wrote:
>...
> config X86_SPEEDSTEP_CENTRINO
> - tristate "Intel Enhanced SpeedStep"
> + tristate "Intel Enhanced SpeedStep (deprecated)"
> select CPU_FREQ_TABLE
> - select X86_SPEEDSTEP_CENTRINO_TABLE
> + select
On 11/1/07, David Newall <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> > On Nov 1 2007 12:51, Peter Dolding wrote:
> >
> >> This is above me doing code. No matter how many fixes I do to the
> >> core that will not fix dysfunction in the LSM section. Strict
> >> policies on fixing the
On Sat, Nov 03, 2007 at 04:52:47PM -0700, Arjan van de Ven wrote:
> On Sun, 4 Nov 2007 00:48:26 +0100
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > This patchset unify the i386 and x86_64 Kconfig
> > files for x86.
> > In addition it replaces the use of ARCH=i386 and
> > ARCH=x86_64 with the
Alan Cox wrote:
On my NV3 board with a Samsung SP1634N Harddisk I wrongly got
"drive side 80-wire cable detection failed" with the current kernel.
Does the drive cable detect correctly on a non Nvidia chipset ?
I have no box here to test this - my laptop won't help.
But I did another test:
On Sat, 3 Nov 2007, Arjan van de Ven wrote:
On Sat, 3 Nov 2007 15:40:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
I don't understand how you can call this a "PID namespace design
bug", when it clearly has nothing what-so-ever to do with pid
namespaces, and everything to do with
Daniel Drake wrote:
> Tejun Heo wrote:
>>> <4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
>>> <3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
>>> <3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
>>> 10 in
>>> <4> res
Hi,
Maybe some of you have been hearing lately about a problem with laptop's hard
disk drives being killed by *insert Linux distro here* [1]
The problem comes from a very high rate of load/unload cycles of the heads
that reaches the 300.000-600.000 limit in 2-3 years (with smartmontools it
On Sat, 3 Nov 2007 15:40:48 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I don't understand how you can call this a "PID namespace design
> bug", when it clearly has nothing what-so-ever to do with pid
> namespaces, and everything to do with the *futexes* that blithely
> assume that
On Sun, 4 Nov 2007 00:48:26 +0100
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> This patchset unify the i386 and x86_64 Kconfig
> files for x86.
> In addition it replaces the use of ARCH=i386 and
> ARCH=x86_64 with the more intuitive ARCH=x86.
>
> The primary purpose of this patch serie is to
>
No functional changes.
A prepatory step towards full unification.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.i386 | 124 +
1 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig.i386
Like powerpc and other we now select the actual
architecture during configuration.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/x86/Kconfig | 26 +-
arch/x86/Kconfig.i386| 17 +++--
arch/x86/Kconfig.x86_64 | 16 +++-
Merge the two Kconfig files to a single file.
Checked by comparing menuconfig before and after.
Except some slight reordering in the x86_&4 case
the result is equal.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.i386 |2 +-
A few symbols remained in Kconfig.x86_64 where the
dependencies were different or the help text was
different from the i386 one.
Modify all relevant Kconfig.i386 symbols such that
they have X86_64 dependencies for x86_64 specific items
and update the help text as appropriate.
Signed-off-by: Sam
This step introduces the file arch/x86/Kconfig
which contains all the menu's from "Power Management"
and below.
The main parts of the new Kconfig file are shared
and the remaining i386/x86_64 specific parts
are covered by dependencies.
All config options without prompt are kept in the
Move all CPU definitions to Kconfig.cpu
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.cpu| 83 ++
arch/x86/Kconfig.x86_64 | 61 +--
2 files changed, 69 insertions(+), 75 deletions(-)
diff
But this will break all the scripts that uses
make ARCH=i386 / make ARCH=x86_64
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
Makefile |5 ++---
arch/x86/Makefile |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index
To ease unification of Kconfig.i386 and Kconfig.x86_64
add X86_32 dependencies to all i386 specific symbols.
This patch introduce no functional changes but is one step
towards unification. This smaller step is used to ease
review of the patch set.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
To ease unification of Kconfig.i386 and Kconfig.x86_64
add X86_64 dependencies to all x86_64 specific symbols.
This patch introduce no functional changes but is one step
towards unification. This smaller step is used to ease
review of the patch set.
Signed-off-by: Sam Ravnborg <[EMAIL
This patchset unify the i386 and x86_64 Kconfig
files for x86.
In addition it replaces the use of ARCH=i386 and
ARCH=x86_64 with the more intuitive ARCH=x86.
The primary purpose of this patch serie is to
enable make ARCH=x86 and let the config decide
if we are building for 32 or 64 bit.
But we
When tmpfs is mounted with a size less than one page the number of blocks
is set to 0 which makes the tmpfs mount unlimited. This can lead to a quick
and surprising death is someone typos a tmpfs mount command and writes to much.
tmpfs can still be mounted as unlimited if size or nr_blocks is
Hi. My computer is constipated. The load average when idle never goes
below 100%. Top shows this:
top - 11:01:27 up 5 min, 2 users, load average: 2.63, 1.73, 0.76
Tasks: 91 total, 2 running, 89 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.5%us, 4.4%sy, 1.6%ni, 9.9%id, 70.2%wa,
Bo Brantén wrote:
On Sat, 3 Nov 2007, Matt Mackall wrote:
This is typically due to a problem with the setup of your MTRRs. Try
booting with mem=nnnM where nnn is some number smaller than your
actual amount of memory.
Thank you for that advice, the system has 4GB and if I boot with
mem=3072M
On Sat, Nov 03, 2007 at 12:48:23PM -0700, Stephen Hemminger wrote:
> The sizeof(struct device) is way too big, especially in the network device
> case.
> We want to support 1000's of device's and the change from class_device to
> net_device has caused needless bloat.
>
> sizeof(struct device) =
sys_pciconfig_{read,write}() are protected against PCI removal with the
reference count in struct pci_dev. The concurrency of
pci_user_{read,write}_config_* functions are already protected by pci_lock in
drivers/pci/access.c.
Signed-off-by: Diego Woitasen <[EMAIL PROTECTED]>
---
On Sun, 04 Nov 2007 00:09:49 +0100
Tobias Hoffmann <[EMAIL PROTECTED]> wrote:
> Hi!
>
> On my NV3 board with a Samsung SP1634N Harddisk I wrongly got
> "drive side 80-wire cable detection failed" with the current kernel.
Does the drive cable detect correctly on a non Nvidia chipset ?
-
To
Hi!
On my NV3 board with a Samsung SP1634N Harddisk I wrongly got
"drive side 80-wire cable detection failed" with the current kernel.
A possible fix is attached.
Please CC any replies as I'm not on the list.
Tobias
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index
Split the LRU lists in two, one set for pages that are backed by
real file systems ("file") and one for pages that are backed by
memory and swap ("anon"). The latter includes tmpfs.
Eventually mlocked pages will be taken off the LRUs alltogether.
A patch for that already exists and just needs to
Security fixes since 2.6.16.56:
- CVE-2007-3740: CIFS should honour umask
- CVE-2007-4308: aacraid: fix security hole
- CVE-2007-4997: [IEEE80211]: avoid integer underflow for runt rx frames
- CVE-2007-5093: USB: fix DoS in pwc USB video driver
Location:
Rik van Riel's patch to free swap space on swap-in/activiation,
forward ported by Lee Schermerhorn.
Against: 2.6.23-rc2-mm2 atop:
+ lts' convert anon_vma list lock to reader/write lock patch
+ Nick Piggin's move and rework isolate_lru_page() patch
Patch Description: quick attempt by lts
Free
The memory controller code is still quite simple, so don't do
anything fancy for now trying to make it work better with the
split VM code.
Will be merged into 6/10 soon.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.23-mm1/mm/memcontrol.c
move isolate_lru_page() to vmscan.c
Against 2.6.23-rc4-mm1
V1 -> V2 [lts]:
+ fix botched merge -- add back "get_page_unless_zero()"
From: Nick Piggin <[EMAIL PROTECTED]>
To: Linux Memory Management <[EMAIL PROTECTED]>
Subject: [patch 1/4] mm: move and rework isolate_lru_page
Date: Mon, 12
Make lumpy reclaim and the split VM code work together better, by
allowing both file and anonymous pages to be relaimed together.
Will be merged into patch 6/10 soon, split out for the benefit of
people who have looked at the older code in the past.
Signed-off-by: Rik van Riel <[EMAIL
Use an indexed array for LRU variables. This makes the rest
of the split VM code a lot cleaner.
V1 -> V2 [lts]:
+ Remove extraneous __dec_zone_state(zone, NR_ACTIVE) pointed
out by Mel G.
>From [EMAIL PROTECTED] Wed Aug 29 11:39:51 2007
Currently we are defining explicit variables for the
Make the LRU arithmetic more explicit. Hopefully this will make
the code a little easier to read and less prone to future errors.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.23-mm1/include/linux/mm_inline.h
===
Debug whether we end up classifying the wrong pages as
filesystem backed. This has not triggered in stress
tests on my system, but who knows...
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
Index: linux-2.6.23-mm1/include/linux/mm_inline.h
Swapin_readahead can read in a lot of data that the processes in
memory never need. Adding swap cache pages to the inactive list
prevents them from putting too much pressure on the working set.
This has the potential to help the programs that are already in
memory, but it could also be a
The current page replacement scheme in Linux has a number of problems,
which can be boiled down to:
- Sometimes the kernel evicts the wrong pages, which can result in
bad performance.
- The kernel scans over pages that should not be evicted. On systems
with a few GB of RAM, this can result in
Define page_file_cache() function to answer the question:
is page backed by a file?
Originally part of Rik van Riel's split-lru patch. Extracted
to make available for other, independent reclaim patches.
Moved inline function to linux/mm_inline.h where it will
be needed by subsequent
On Sat, Nov 03, 2007 at 11:38:24PM +0100, Bo Brant?n wrote:
> On Sat, 3 Nov 2007, Matt Mackall wrote:
>
> >This is typically due to a problem with the setup of your MTRRs. Try
> >booting with mem=nnnM where nnn is some number smaller than your
> >actual amount of memory.
>
> Thank you for that
On Sat, 3 Nov 2007, Ingo Molnar wrote:
>
> - one problem is that this condition is 'invisible'. If two namespaces
> happen to access the same robust futex (say a yum update from two
> PID namespaces sharing the same read-mostly filesystem) there's silent
> breakage and data corruption
On Sat, 3 Nov 2007, Matt Mackall wrote:
This is typically due to a problem with the setup of your MTRRs. Try
booting with mem=nnnM where nnn is some number smaller than your
actual amount of memory.
Thank you for that advice, the system has 4GB and if I boot with mem=3072M
it will run as
Nick Piggin wrote:
> Just for fun I also had a shot at merging the headers, as they become a
> lot more similar after this with the removal of the paravirt crud.
Glommer posted a set of patches the other day to implement x86-64
paravirt, which unifies lots of things including spinlocks. But if
On 11/3/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Nov 03, 2007, at 12:43:06, Ahmed S. Darwish wrote:
> > Bashv3 builtin "echo" behaves very strangely to -EINVAL. It sends
> > all the buffers that causes -EINVAL again in subsequent echo
> > invocations.
> >
> > i.e.
> > echo "Invalid Rule" >
When tmpfs is mounted with a size less than one page the number of blocks
is set to 0 which makes the tmpfs mount unlimited. This can lead to a quick
and surprising death is someone typos a tmpfs mount command and writes to much.
tmpfs can still be mounted as unlimited if size or nr_blocks is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([EMAIL PROTECTED]):
>> On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote:
[..]
>>> Also don't do file-capabilities signaling checks when uids for
>>> the processes don't match, since the
If fs_enet is build as module, mii-fec/mii-bitbang should be build as
module, as well. Otherwise some symbols remain undefined.
Building modules, stage 2.
MODPOST 5 modules
ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules]
On Saturday, 3 November 2007 21:08, Frans Pop wrote:
> Rafael J. Wysocki wrote:
> > +core run in a test mode. There are 5 test modes available:
> > +
> > +freezer - test the freezing of processes
> > +devices - test the freezing of processes and suspending of devices
> > +platform - test the
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Neither of us has yet posted a correct patch which applies to 2.6.23
> and 2.6.22. I'm testing your 2.6.24-rc patch overnight, and if that's
> fine then one of us will post the version for -stable. I thought I'd
> better leave that to you, after I've
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Fri, 2 Nov 2007, Dave Hansen wrote:
> >
> > There are certainly more of these, but here is one In the futex
> > userspace address, we install the current pid's vnr into a userspace
> > address.
>
> Now, realistically, why not just say "you
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > >
> > > > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > > > So stable should
On Saturday 03 November 2007 20:58:09 Luis R. Rodriguez wrote:
> I was using SLAB and ran into other strange oops, as the one below,
> but after switching to SLUB, after Michael Buesch's suggestion that
> one went away... The lockdep segfault is still present, however.
Who is responsible for slab
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > I was afraid you might say something like that.
> > Perhaps it'll be a patch I need to use in my own builds.
> > Though I'd have thought others would want that accuracy too.
> > Didn't SLAB give it? (The
Pavel Emelianov [EMAIL PROTECTED] wrote:
| Ulrich Drepper wrote:
| > -BEGIN PGP SIGNED MESSAGE-
| > Hash: SHA1
| >
| > Pavel Emelyanov wrote:
| >>> Isn't it this?
| >>>
| >>> http://lkml.org/lkml/2007/11/1/141
| >> That was the initial problem, and I already answered to Ingo about
| >> it
Tejun Heo wrote:
<4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
<4> res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violation)
On 11/2/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-01 at 19:26 -0400, Michael Wu wrote:
> > On Thursday 01 November 2007 15:17:16 Luis R. Rodriguez wrote:
> > > [EMAIL PROTECTED]:~/devel/wireless-2.6$ git-describe
> > > v2.6.24-rc1-146-g2280253
> > >
> > > So I hit segfault
Looks like word-wrapping by your mail client has corrupted the patch.
Suggest you resend it.
Cheers,
FJP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> >
> > > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > > So stable should ignore my patch, and he will come up with another.
> >
> >
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > Later Christoph noticed that I'm not handling the SlabDebug case right.
> > So stable should ignore my patch, and he will come up with another.
>
> Hmmm? I thought you wanted to test the patch provided?
The sizeof(struct device) is way too big, especially in the network device case.
We want to support 1000's of device's and the change from class_device to
net_device has caused needless bloat.
sizeof(struct device) = 272
sizeof(struct class_device) = 92
* not the class_id in class_device could
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Later Christoph noticed that I'm not handling the SlabDebug case right.
> So stable should ignore my patch, and he will come up with another.
Hmmm? I thought you wanted to test the patch provided?
-
To unsubscribe from this list: send the line
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Update the suspend/hibernation debugging and testing documentation to describe
the newly introduced testing facilities.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
Documentation/power/basic-pm-debugging.txt | 203
Hi,
This is the second iteration of the patches that add a new testing facility for
suspend and hibernation.
The first patch adds the possibility to test the suspend (STD) core code
without actually suspending, which is useful for tracking problems with drivers
etc.
The second one modifies the
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make it possible to test the hibernation core code with the help of the
/sys/power/pm_test attribute introduced for suspend testing in the previous
patch.
Writing an appropriate string to this file causes the hibernation code to work
in one of the test
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Olivér Pintér wrote:
> > > Q: It's needed auch to 2.6.22-stable?
>
> Okay, here's a version for 2.6.23 and 2.6.22...
> Christoph, you've now Acked the 2.6.24 one, thanks:
> do you agree this
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> > >
> > > > Which fixes the leakage: Objects and Partials then remain stable.
> > >
> > > Well this code is just
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> I was afraid you might say something like that.
> Perhaps it'll be a patch I need to use in my own builds.
> Though I'd have thought others would want that accuracy too.
> Didn't SLAB give it? (The "r*gr*ss**n" word!)
Slab also only counts objects that
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Christoph Lameter wrote:
> > On Sat, 3 Nov 2007, Hugh Dickins wrote:
> >
> > > Which fixes the leakage: Objects and Partials then remain stable.
> >
> > Well this code is just an optimization for a rare case.
> > Your patch may not
fpi->cp_command should be overwritten only if CONFIG_PPC_CPM_NEW_BINDING
is NOT set. Otherwise it is already set from the device tree.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
This can be pulled from git://git.bocc.de/dbox2.git for-2.6.24
drivers/net/fs_enet/mac-scc.c |2 +-
Krzysztof Halasa wrote:
> The difference is of course at 0x0E, not 0x1E. Maybe the byte at 0x0A
> is 0x92 for 4 IR contents and 0xA2 for 8 contents. That would also
> make sense wrt the broken 6306 as it has 0x00 there.
Somebody pointed me to this thread in a support forum of Asustek:
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > The count of active Objects shown by Slub's slabinfo is too approximate,
> > because each cpu slab is counted as all in use, even when lots are free.
> > That makes tracing leaks harder than it need be.
>
Signed-off-by: Paulius Zaleckas <[EMAIL PROTECTED]>
---
diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
index 2ce3806..58fccc9 100644
--- a/arch/parisc/kernel/signal.c
+++ b/arch/parisc/kernel/signal.c
@@ -333,7 +333,7 @@ setup_rt_frame(int sig, struct k_sigaction *ka,
On Sat, 3 Nov 2007, Christoph Lameter wrote:
> On Sat, 3 Nov 2007, Hugh Dickins wrote:
>
> > Which fixes the leakage: Objects and Partials then remain stable.
>
> Well this code is just an optimization for a rare case.
> Your patch may not handle the debug situation the right way.
Oh? How?
>
Add a select PHYLIB to config FS_ENET as the driver uses functions of
libphy.
LD .tmp_vmlinux1
drivers/built-in.o: In function `fs_ioctl':
drivers/net/fs_enet/fs_enet-main.c:952: undefined reference to `phy_mii_ioctl'
[...]
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Jochen Friedrich
Here is a series fixing some bugs for 8xx powerpc CPUs.
1. [POWERPC] Kill non-existant symbols from ksyms and commproc.h
2. [POWERPC] fs_enet: select PHYLIB as the driver needs it
This series can be pulled from git://git.bocc.de/dbox2.git for-2.6.24
Thanks,
Jochen
-
To unsubscribe from this
Remove exports of __res and cpm_install_handler/cpm_free_handler.
Remove cpm_install_handler/cpm_free_handler from the commproc.h as well.
Both were used for ARCH=ppc and aren't defined for ARCH=powerpc.
CC arch/powerpc/kernel/ppc_ksyms.o
arch/powerpc/kernel/ppc_ksyms.c:180: error: '__res'
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> On Sat, 3 Nov 2007, Olivér Pintér wrote:
> > Q: It's needed auch to 2.6.22-stable?
>
> I guess so: though SLUB wasn't on by default in 2.6.22; and it being
> only a slow leak rather than a corruption, I was less inclined to
> agitate about it for releases
The fix against mm:
SLUB: Fix memory leak by not reusing cpu_slab
Fix the memory leak that may occur when we attempt to reuse a cpu_slab
that was allocated while we reenabled interrupts in order to be able to
grow a slab cache. The per cpu freelist may contain objects and in that
situation we
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> Which fixes the leakage: Objects and Partials then remain stable.
Well this code is just an optimization for a rare case. Your patch may not
handle the debug situation the right way. We could just remove it.
SLUB: Fix memory leak by not reusing
Rafael J. Wysocki schrieb:
> On Saturday, 3 November 2007 12:31, Thomas Bächler wrote:
>> I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree.
>> During boot, I get a kernel oops when udevtrigger is running, thus most
>> devices are not created and the boot stalls.
>>
>>
Hi,
On Saturday, 3 November 2007 19:23, Pavel Machek wrote:
> Hi!
>
> > Introduce /sys/power/pm_test_level attribute allowing one to test the
> > suspend
> > core code. Namely, writing a number (1-5) to this file causes the suspend
> > code
> > to work in one of the test modes defined as
Hi!
> > iwl3945: 00 0x007b 403761122
> > iwl3945: 02 0x007d 403761129
> > iwl3945: I iwl_irq_handle_error Restarting adapter due to uCode error.
> > iwl3945: Error Reply type 0x0005 cmd REPLY_TX (0x1C) seq 0x0203
> > ser 0x004B
> > iwl3945: Can't
Hi,
The below is my bugreport as suggested in REPORTING-BUGS:
1. noauto option prevents codepages from being processed properly by smbfs
2. I had the following line in my /etc/fstab :
//host/share /path smbfs
noauto,iocharset=koi8-r,codepage=cp866 0 0
Mounting such a share
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> The culprit turns out to be __slab_alloc(), where it copes with the race
> that another task has assigned the cpu slab while we were allocating one.
> Don't rush off to load_freelist there: that assumes c->freelist is empty,
> and will lose all of its
On Nov 03, 2007, at 12:43:06, Ahmed S. Darwish wrote:
Bashv3 builtin "echo" behaves very strangely to -EINVAL. It sends
all the buffers that causes -EINVAL again in subsequent echo
invocations.
i.e.
echo "Invalid Rule" > /smack/load # -EINVAL returned
echo "Valid Rule" > /smack/load
In
On Sat, 3 Nov 2007, Hugh Dickins wrote:
> The count of active Objects shown by Slub's slabinfo is too approximate,
> because each cpu slab is counted as all in use, even when lots are free.
> That makes tracing leaks harder than it need be.
True but that is the way it is for performance reasons.
1 - 100 of 342 matches
Mail list logo
