On Sat, 2007-12-22 at 06:36 +0800, Andrei Gaponenko wrote:
>
> Hi,
>
> With 2.6.23 or newer (including 2.6.24-rc6) kernels, writing to the
> /sys/devices/platform/asus-laptop/display file does not do anything:
>
> Cold boot to single user, then connect an external monitor
>
> # cat /sys/devic
Andrew Morton wrote:
> On Fri, 21 Dec 2007 00:23:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> Based on the discussion at http://lkml.org/lkml/2007/12/20/383, it was
>> felt that control_type might not be a good thing to implement right away.
>> We can add this flexibility at a later point
> > Which is why my suggestion was to have them both move up a level, with
> > host and peripheral side menus nested normally:
> >
> > Device Drivers:
> > ...
> > [ ] HID devices
> > < > Host side USB
> > < > Peripheral side USB
> > <
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
lib/inflate.c | 1265 -
1 files changed, 0 insertions(+), 1265 deletions(-)
delete mode 100644 lib/inflate.c
diff --git a/lib/inflate.c b/lib/inflate.c
deleted file mode 100644
index 845f9
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
arch/arm/boot/compressed/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 5fde99f..563cfc2 100644
--- a/arch/arm/boot/compressed/Makefi
Uncompiled/Untested (no cross-compiler for alpha)
--
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
Please read the FAQ at http://www.tux.org/lkml/
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
arch/alpha/boot/Makefile |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/boot/Makefile b/arch/alpha/boot/Makefile
index cd14388..c53169c 100644
--- a/arch/alpha/boot/Makefile
+++ b/arch/alpha/boot/Makefile
@@
On Fri, 21 Dec 2007 00:23:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> Based on the discussion at http://lkml.org/lkml/2007/12/20/383, it was
> felt that control_type might not be a good thing to implement right away.
> We can add this flexibility at a later point when required.
Gee the mem
David Brownell wrote:
> > > The driver stacks are independent of each other, except for common
> > > data structures like what's in the header file. I
> > > think there's no real point, other than history, to having both sides
> > > share the same menu.
> >
> > They aren't.
>
> How can you say th
On Thu, 20 Dec 2007 16:39:21 -0500 "Cory T. Tusar" <[EMAIL PROTECTED]> wrote:
> tty: Fix logic change introduced by wait_event_interruptible_timeout()
>
> Commit 5a52bd4a2dcb570333ce6fe2e16cd311650dbdc8 introduced a subtle logic
> change in tty_wait_until_sent(). The original version would only
On Fri, 21 Dec 2007 22:24:28 -0800 Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > I converted the usu_init_notify semaphore to normal mutex usage, and it
> > should still prevent the request_module before the init rout
On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:
> I converted the usu_init_notify semaphore to normal mutex usage, and it
> should still prevent the request_module before the init routine is
> complete. Before it acted more like a complete, now the mutex protects
> tw
> > Notice that this whole menu is for "Host-side USB", except for that
> > gadget stuff. That might usefully be labeled as "Peripheral-side USB".
> >
> > For that matter, it could be moved up a level in the menu, so the top
> > level driver menu has two USB entries: Host side, and Peripheral sid
On Thu, 20 Dec 2007 17:16:01 -0500 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
> Subject: [PATCH 13/13] update copyright date
Please put an identfier for the subsytem in patch titles. In this case,
Subject: [PATCH 13/13] aoe: update copyright date
would suit.
I dropped aoe-remove-race-b
On Thu, 20 Dec 2007 17:15:57 -0500 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
> Alexey Dobriyan noticed a race in the initialization of the dynamic
> locks in ...
>
> Message-ID: <[EMAIL PROTECTED]>
>
> Andrew Morton commented that these locks should be initialized at
> compile time, so this pa
Some corrections to the preamble.
The large amount of text is due to the nature of the
problem and the discussion it engendered on the lkml.
Should say:
The large amount of text in the explanation below is due to
the nature of the problem and the discussion engendered on
lkml by my first subm
On Fri, 21 Dec 2007 22:51:45 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> > Here's a test patch:
>
> Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug.
>
> Thanks a lot to both of you.
Thank you for testing -mm (especially on sparc64) and for reporting
the bug and for testing
On Thu, 20 Dec 2007 23:18:49 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Jeff Moyer pointed out that a mount; umount loop of ecryptfs,
> with the same cipher & other mount options, created a new
> ecryptfs_key_tfm_cache item each time, and the cache could
> grow quite large this way.
>
> Loo
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 22 Dec 2007 02:53:11 +0100
> > And to handle potentially ambiguous cases we, for a long time, have
> > the force_successful_syscall_return() arch hook.
>
> Ah I see what you mean now.
>
> Thanks for the clarification.
Thanks for continuing to ins
On Fri, 21 Dec 2007 00:00:04 -0800 Daniel Walker <[EMAIL PROTECTED]> wrote:
> I converted the usu_init_notify semaphore to normal mutex usage, and it
> should still prevent the request_module before the init routine is
> complete. Before it acted more like a complete, now the mutex protects
> two
Most likely your device nodes are missing in /dev.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Siva Prasad
Sent: Thursday, December 20, 2007 4:03 AM
To: Clemens Koller; David Newall
Cc: linux-kernel@vger.kernel.org
Subject: RE: printf internals
Thank
On Fri, Dec 21, 2007 at 08:19:42PM -0600, Matt Mackall wrote:
>
> On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote:
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> > > relies on it, people use it every day to monit
On Fri, Dec 21, 2007 at 06:22:41PM -0800, H. Peter Anvin wrote:
> >Ok, that's a different argument than before. Ok. Although it's
> >only a few bytes.
> >
> >I would lobby for any message at least contain the suggestion to try
> >edd=off. That could save users a lot of time.
>
> The important thi
Andi Kleen wrote:
Those don't live in an area of memory which is hard-limited to 32K.
Why not 64k?
Because the bootloader needs some memory in the same segment that it
controls. Furthermore, since there were some residual uses of the
0x9000 segment (now removed, but not all bootloaders co
On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> > relies on it, people use it every day to monitor memory consumption.
>
> It's definitely not a stable ABI. slabtop tend
* Greg KH <[EMAIL PROTECTED]> wrote:
> How about you drop this one patch, and I'll keep it, as it goes along
> with the other 2 patches in his series, and I'll make sure to check if
> I have future pci quirk patches that affect the x86/ directory.
>
> Sound reasonable?
sure enough - dropped.
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> This patch moves _set_gate and its users to desc.h. We can now use
> common code for x86_64 and i386.
a few days ago i started seeing weird crashes on 64-bit x86 in the
random-kernel-bootup tests. Nothing truly reproducable to be bisecta
eCryptfs: Change the type of cipher_code from u16 to u8.
Only the lower byte of cipher_code is ever used, so it makes sense
for its type to be u8.
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |8
fs/ecryptfs/ecryptfs_kernel.h |4 ++--
fs/e
eCryptfs: Load each file decryption key only once
There is no need to keep re-setting the same key for any given
eCryptfs inode. This patch optimizes the use of the crypto API and
helps performance a bit.
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |9 +---
> Those don't live in an area of memory which is hard-limited to 32K.
Why not 64k?
Ok, that's a different argument than before. Ok. Although it's
only a few bytes.
I would lobby for any message at least contain the suggestion to try
edd=off. That could save users a lot of time.
-Andi
--
To uns
> And to handle potentially ambiguous cases we, for a long time, have
> the force_successful_syscall_return() arch hook.
Ah I see what you mean now.
Thanks for the clarification.
Ok that could be in theory made to work yes. The migration would
probably be ugly though (how would glibc figure out
Andi Kleen wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
/* Query EDD information */
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
- query_edd();
+printf("Probing EDD (query Bios for boot-device information)\n");
+printf("If
> I'm suggesting that you set the condition codes based upon whether
> there is an error or not.
And the only way the syscall code could find out if there is an error is by
checking err < 0 && err >= -4096 like glibc (except for the compat
syscall on 64bit kernel case)
Or rewrite all code that
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 17:41:24 -0800 (PST)
> I'm suggesting that you set the condition codes based upon whether
> there is an error or not. That is the critical thing x86 doesn't do
> that all the other platforms do.
And if you still don't get it, I'm sayi
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 22 Dec 2007 01:42:02 +0100
> David Miller <[EMAIL PROTECTED]> writes:
>
> > Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
> > case right.
>
> Do they for 32bit kernels or for 64bit userland?
Both. This is not a compat iss
Change mmap read-around to share the same code style and data structure
with readahead code.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/filemap.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/m
From: Linus Torvalds <[EMAIL PROTECTED]>
This shouldn't really change behavior all that much, but the single
rather complex function with read-ahead inside a loop etc is broken up
into more manageable pieces.
The behaviour is also less subtle, with the read-ahead being done up-front
rather than
Auto-detect sequential mmap reads and do sync/async readahead for them.
The sequential mmap readahead will be triggered when
- sync readahead: it's a major fault and (prev_offset==offset-1);
- async readahead: minor fault on PG_readahead page with valid readahead state.
It's a bit conservative to
Andrew,
Here are the mmap read-around related patches initiated by Linus.
They are for linux-2.6.24-rc5-mm1. They're mainly about code cleanups.
The only major new feature - auto detection and early readahead for mmap
sequential reads - shows about 2% speedup on single stream case, and should
pe
It is insane and error-prone to insist on the call sites to check for async
readahead after doing any sync one. I.e. whenever someone do a sync readahead:
if (!page)
page_cache_sync_readahead(...);
He must try async readahead
When the user explicitly sets MADV_SEQUENTIAL, we should really avoid the slow
readahead size ramp-up phase and start full-size readahead immediately.
This patch won't change behavior for the auto-detected sequential mmap reads.
Its previous read-around size is ra_pages/2, so it will be doubled to
Simplify code by moving max_sane_readahead() calls into
force_page_cache_readahead().
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/fadvise.c |2 +-
mm/filemap.c |3 +--
mm/madvise.c |3 +--
mm/readahead.c |1 +
4 files changed, 4 insertions(+), 5 deletions(-)
---
Remove do_page_cache_readahead().
Its last user, mmap read-around, has been changed to call ra_submit().
Also, the no-readahead-if-congested logic is not appropriate here.
Raw 1-page reads can only makes things painfully slower, and
users are pretty sensitive about the slow loading of executables
Apply the max_sane_readahead() limit in ondemand_readahead().
Just in case someone aggressively set a huge readahead size.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/readahead.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
Make ra_submit() non-static and callable from other files.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
---
include/linux/mm.h |3 +++
mm/readahead.c |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.24-rc5-mm1.orig/include/linux/mm.h
+++ linux-2.6.24-rc5-mm
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> /* Query EDD information */
>> #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
>> - query_edd();
>> +printf("Probing EDD (query Bios for boot-device information)\n");
>> +printf("If boot
On Fri, Dec 21, 2007 at 11:10:36AM -0500, Andrew Lutomirski wrote:
> > > Step 1: Boot a system without a usable entropy source.
> > > Step 2: add some (predictable) "entropy" from userspace which isn't a
> > > multiple of 4, so up to three extra bytes get added.
> > > Step 3: Read a few bytes of /d
The tx_set_src and tx_set_dest methods were originally implemented to allow
an array of addresses to be passed down from async_xor to the dmaengine
driver while minimizing stack overhead. Removing these methods allows
drivers to have all transaction parameters available at 'prep' time, saves
two f
Prompted by Yuri's RAID6 acceleration implementation [1], and Haavard's
DMA-slave interface [2], this series cleans up the async_tx api and prepares
it for these new features. The most invasive change is the removal of
the tx_set_src and tx_set_dest methods in patch 2/4, drivers now receive
all ne
Remove the unused ASYNC_TX_ASSUME_COHERENT flag. Async_tx is
meant to hide the difference between asynchronous hardware and synchronous
software operations, this flag requires clients to understand cache
coherency consequences of the async path.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
The source and destination addresses are included to allow channel
selection based on address alignment.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c |3 ++-
crypto/async_tx/async_memset.c |3 ++-
crypto/async_tx/async_tx.c |6 +++---
crypto/
Pass a full set of flags to drivers' per-operation 'prep' routines.
Currently the only flag passed is DMA_PREP_INTERRUPT. The expectation is
that arch-specific async_tx_find_channel() implementations can exploit this
capability to find the best channel for an operation.
Signed-off-by: Dan William
David Miller <[EMAIL PROTECTED]> writes:
> Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this
> case right.
Do they for 32bit kernels or for 64bit userland?
> Yes it's another unfortunate side effect of how error status is
> indicated for x86 system calls.
Maybe I'm dense, b
On 12/21/2007 07:28 PM, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
>> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
>> relies on it, people use it every day to monitor memory consumption.
>
> It's definitely not a stable ABI. slabtop tends to exit with
Ingo Molnar <[EMAIL PROTECTED]> writes:
> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> relies on it, people use it every day to monitor memory consumption.
It's definitely not a stable ABI. slabtop tends to exit without any
error message on any slabinfo version number
On Sat, 8 Dec 2007, Richard Knutsson wrote:
> Fixing:
> CHECK mm/mmap.c
> mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer
> mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer
> mm/mmap.c:1944:29: warning: Using plain integer as NULL pointer
>
> Signed-off-by: Rich
Hi!
I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am
observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as
of today, ea67db4cdbbf7f4e74150e71da0984e25121f500).
The last working version is 2.6.24-rc1.
The system is running debian unstable (current) usi
On Fri, 21 Dec 2007 16:55:03 +0100
Marcin Slusarz <[EMAIL PROTECTED]> wrote:
> sparse generated:
> fs/udf/dir.c:78:5: warning: symbol 'udf_readdir' was not declared. Should it
> be static?
> there are 2 different prototypes of udf_readdir - remove them and move
> code around to make it still comp
On 12/21/2007 06:54 PM, Christoph Lameter wrote:
>
> SLUB: Improve hackbench speed
>
> Increase the mininum number of partial slabs to keep around and put
> partial slabs to the end of the partial queue so that they can add
> more objects.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> >Propose new layout as follows:
>
> Yes, this has been done before in a lot of places, and attempts to
> clean up more menus is always welcome.
>
> Try to use 'menuconfig' objects so people can disable a whole menu
> at once without having to enter it, e.g. that USB Gadget thing down
> there.
No
On Sat, 22 Dec 2007, Ingo Molnar wrote:
> and the regression seems to be largely fixed! Not only is the hackbench
> one fixed, but mmap shows an above-noise improvement as well.
>
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Well lets use the version attached to this patch. It turns out that it
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> I'm really getting worried that you are apparently incapable of grasping
> such _SIMPLE_ concepts. Who the heck cares whether you put in zeros or
> whatever else in some of the fields? People use it to know how many
> objects are allocated and sure SLUB
Hi,
On Dec 22, 2007 1:17 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yep, and i ran a quick comparison test on a 2-core box with 3 kernels:
>
> [ best of 5 runs in a row which had a relative jitter of less than 10% ]
>
> MIN v2.6.24.slab v2.6.24.slub v2.6.24.slub.fix
> -
"Jan Beulich" <[EMAIL PROTECTED]> writes:
> This is the base patch, adding notification for task creation and
> deletion.
I like the basic concept. At some point I suspect we'll even need
a per task dynamic data allocator, that would remove even
more cruft.
Could you change the block notifier ca
On Fri, 21 Dec 2007 23:54:13 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 21 Dec 2007, Peter Zijlstra wrote:
> >
> > > BTW, does /proc/slabinfo exist again? I thought we set that as a
> > > requirement for SLUB to be the default and
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> And now, can the people who made the problem reports and complained
> about SLUB please test the patch - the ball is now in your court!
yep, and i ran a quick comparison test on a 2-core box with 3 kernels:
[ best of 5 runs in a row which had a r
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 23:54:13 +0100
> Really, if your behavior is representative of how our SLAB allocator
> will be maintained in the future then i'm very, very worried :-(
Actually, to the contrary, I actually think Christoph responds to
every problem I'
On Fri, 14 Dec 2007 16:17:44 -0600
Mike Miller <[EMAIL PROTECTED]> wrote:
> Patch 1 of 3
>
> Sorry to take so long to repost.
>
> This patch exports more attributes to /sys so we can work work better with
> udev. Some distros use unique_id among other attributes. This patch attempts
> to provide
On Fri, 2007-12-21 at 16:52 -0500, David Dillow wrote:
> I'm getting the following oops when doing the following commands:
>
> modprobe ib_srp
>
> rmmod ib_srp
> modprobe ib_srp
>
>
> I'm going to try and track down how the list is getting corrupted; it
> looks like attribute_container_list in
On Fri, Dec 21, 2007 at 11:40:53PM +0100, Ingo Molnar wrote:
>
> * Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > > arch/x86/kernel/quirks.c | 42
> > > > ++
> > > > arch/x86/pci/fixup.c | 22 +++---
> > >
> > > That made it hard. Argua
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> if (unlikely(!prior))
> - add_partial(get_node(s, page_to_nid(page)), page);
> + add_partial_tail(get_node(s, page_to_nid(page)), page);
FYI, this gives me:
mm/slub.c: In function 'kfree':
mm/slub.c:2604: warning:
On Dec 21 2007 14:35, Greg KH wrote:
>> >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
>> >> >base 10 as well
>> >>
>> >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing.
>> >
>> >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007, Peter Zijlstra wrote:
>
> > BTW, does /proc/slabinfo exist again? I thought we set that as a
> > requirement for SLUB to be the default and a full replacement for
> > SLAB.
>
> Well the information that would be exposed in
On Fri, 21 Dec 2007, Christoph Lameter wrote:
> Actually thanks for pointing that out Pekka Here is a patch that takes
> the regression almost completely away (Too much jetlag combined with flu
> seems to have impaired my thinking I should have seen this earlier). I
> still need to run my sla
On Fri, 21 Dec 2007, Christoph Lameter wrote:
>
> Actually thanks for pointing that out Pekka Here is a patch that takes
> the regression almost completely away
Now *this* is what I wanted to see - rather than argue against other
peoples performance regression reports, an actual patch that
On Fri, 21 Dec 2007, Christoph Lameter wrote:
>
> It obviously can replace it and has replaced it for awhile now.
No. If there are 6% performance regressions on TPC-C, then it CAN NOT
replace it!
> Well still SLUB is really superior to SLAB in many ways
>
> - SLUB is performance wise muc
On Fri, 2007-12-21 at 17:43 -0500, Chuck Ebbert wrote:
> On 12/21/2007 04:03 PM, James Bottomley wrote:
> > On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote:
> >> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
> >>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
>
Hi,
With 2.6.23 or newer (including 2.6.24-rc6) kernels, writing to the
/sys/devices/platform/asus-laptop/display file does not do anything:
Cold boot to single user, then connect an external monitor
# cat /sys/devices/platform/asus-laptop/display
1
OK, only the built in LCD is enabled. Try t
On 12/21/2007 04:03 PM, James Bottomley wrote:
> On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote:
>> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
>>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote:
I have found one problem. Please try patch [2] below and report.
* Greg KH <[EMAIL PROTECTED]> wrote:
> > > arch/x86/kernel/quirks.c | 42 ++
> > > arch/x86/pci/fixup.c | 22 +++---
> >
> > That made it hard. Arguably one file is PCI tree and the other is
> > x86 tree.
>
> Hm, as traditionally w
Actually thanks for pointing that out Pekka Here is a patch that takes
the regression almost completely away (Too much jetlag combined with flu
seems to have impaired my thinking I should have seen this earlier). I
still need to run my slab performance tests on this. But hackbench
improves.
On Fri, Dec 21, 2007 at 11:04:19PM +0100, Jan Engelhardt wrote:
>
> On Dec 21 2007 22:16, Willy Tarreau wrote:
> >Hi Jan,
> >
> >> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR
> >> >> >+int "Low address space to protect from user allocation"
> >> >>
> >> >> Hm, should not this be 'hex'?
> >
On Fri, Dec 21, 2007 at 10:10:24PM +0100, Jan Engelhardt wrote:
>
> On Dec 21 2007 15:31, Eric Paris wrote:
> >On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote:
> >> On Dec 19 2007 16:59, Eric Paris wrote:
> >> >
> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR
> >> >+int "Low address s
[EMAIL PROTECTED]
Bcc:
Subject: Re: Regarding request for IBM camera patch to be applied to the
main tree
Reply-To:
In-Reply-To: <[EMAIL PROTECTED]>
On Fri, Dec 21, 2007 at 03:21:30PM -0600, David Hilvert wrote:
> > > http://www.linux-usb.org/ibmcam/
>
> > > http://auricle.dyndns.org/xv
On Fri, Dec 21, 2007 at 01:47:35PM -0800, Andrew Morton wrote:
> On Tue, 18 Dec 2007 14:58:01 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > Convert quirk printks to dev_printk().
> >
> > thanks, applied the x86 bits.
> >
>
>
On Fri, 21 Dec 2007, Peter Zijlstra wrote:
> BTW, does /proc/slabinfo exist again? I thought we set that as a
> requirement for SLUB to be the default and a full replacement for SLAB.
Well the information that would be exposed in /proc/slabinfo would only be
faked up stuff from SLUB. The queues
On Fri, 21 Dec 2007, Pekka Enberg wrote:
> Christoph, did you see Steven's oprofile results for the hackbench
> runs (http://lkml.org/lkml/2007/12/8/198)? Any ideas why we're hitting
> add_partial like crazy?
Hmmm... SLUB is cycling through partial slabs. If it gets fed objects with
a single fre
> I'm getting the following oops when doing the following commands:
>
> modprobe ib_srp
>
> rmmod ib_srp
> modprobe ib_srp
>
>
> I'm going to try and track down how the list is getting corrupted; it
> looks like attribute_container_list in
> drivers/base/attribute_container.c is the
Hi All,
I have now free IBM H70 with old SSA Array (1 TB discs) and would like use it
as a samba share.
Everythink is working except the SSA card accessing the array:
0001:40:0b.0 SSA: IBM SSA Adapter [Advanced SerialRAID/X] (rev 06)
Is there driver available for this card?
Thanks a lot for r
On Fri, 2007-12-21 at 23:16 +0100, Peter Zijlstra wrote:
> On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote:
> > On Fri, 21 Dec 2007, Linus Torvalds wrote:
> >
> > > If you aren't even motivated to fix the problems that have been reported,
> > > then SLUB isn't even a _potential_ solut
On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote:
> On Fri, 21 Dec 2007, Linus Torvalds wrote:
>
> > If you aren't even motivated to fix the problems that have been reported,
> > then SLUB isn't even a _potential_ solution, it's purely a problem, and
> > since I am not IN THE LEAST in
On Fri, 21 Dec 2007, Linus Torvalds wrote:
> If you aren't even motivated to fix the problems that have been reported,
> then SLUB isn't even a _potential_ solution, it's purely a problem, and
> since I am not IN THE LEAST interested in having three different
> allocators around, SLUB is going
On Friday, 21 of December 2007, Johannes Weiner wrote:
> Hi,
>
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > This message contains a list of some regressions from 2.6.23 reported since
> > 2.6.24-rc1 was released, for which there are no fixes in the mainline I know
> > of. If any of th
On Dec 21 2007 22:16, Willy Tarreau wrote:
>Hi Jan,
>
>> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR
>> >> >+int "Low address space to protect from user allocation"
>> >>
>> >> Hm, should not this be 'hex'?
>> >
>> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
>> >b
On Fri, 2007-12-21 at 16:52 -0500, David Dillow wrote:
> Before I get too far into this, has anyone seen this one before? I
> looked at 'git diff v2.6.24-rc4..' and didn't see any changes that would
> stand out as fixing it.
This should read v2.6.24-rc5...
--
To unsubscribe from this list: send
I'm getting the following oops when doing the following commands:
modprobe ib_srp
rmmod ib_srp
modprobe ib_srp
I'm going to try and track down how the list is getting corrupted; it
looks like attribute_container_list in
drivers/base/attribute_container.c is the one getting corrupted.
Before I
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> > There are patches pending to address these issues. AFAICT Intel is
> > testing if the regression is still there. There is no way for me to
> > verify what is going on there and there is the constant difficulty of
> > getting detailed information about
On Tue, 18 Dec 2007 14:58:01 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Convert quirk printks to dev_printk().
>
> thanks, applied the x86 bits.
>
Greg applied it too. Could you guys please sort out some sort of
who-owns-what protoco
Hello,
> > > [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
> > > 005119b0 Y: Not tainted
> > > [ 145.128940] TPC:
> >
> > My suspicion at this point is that with certain RAM layouts, simply
> > iterating over PFN's is simply not working out.
>
> That
For those interested, an updated PS3 Linux Distributor's Starter Kit (v1.5.1)
was released.
This is a bug-fix release that only updates kboot and the linux kernel
with the fix for the PS3 system update 2.10 frame buffer bug.
The CD-ROM iso image is here (171 MiB):
ftp://ftp.infradead.org/pub/S
1 - 100 of 294 matches
Mail list logo
