(resending this one to the list).
Arjan van de Ven wrote:
On Tue, 20 Nov 2007 10:47:24 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
..
After reading some of the replies, I installed it on my
malfunctioning 64-bit system, but discovered it does not perform
nearly as well as the kernel solution
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
> On Nov 20, 2007 7:52 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> > >
> > > This one is definitely messy. There is absolutely no way to know what
> > > gcc has
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Phil Dibowitz <[EMAIL PROTECTED]>
patch 16eb345f4d9189b59bae576ae63cba7ca77817b2 in mainline.
Upgrade the unusual_devs.h file to support the Nikon D200
Signed-off-by: Mike Pagano <[EMAIL
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Ingo Molnar <[EMAIL PROTECTED]>
patch a3b13c23f186ecb57204580cc1f2dbe9c284953a in mainline.
sched_clock() is not a reliable time-source, use cpu_clock() instead.
Signed-off-by: Ingo Molnar
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: David P. Reed <[EMAIL PROTECTED]>
patch fa6a1a554b50cbb7763f6907e6fef927ead480d9 in mainline.
ntp: fix typo that makes sync_cmos_clock erratic
Fix a typo in ntp.c that has caused updating of
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Andrey Mirkin <[EMAIL PROTECTED]>
patch 1c5b5cfd290b6cb7c67020ef420e275f746a7236 in mainline.
x86: return correct error code from child_rip in x86_64 entry.S
Right now register edi is just
From: Joe Perches <[EMAIL PROTECTED]>
Add missing space between merged string constants.
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/drivers/vde_user.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
Simplify the page fault stub by not masking signals while it is
running. This allows it to signal that it is done by executing an
instruction which will generate a SIGTRAP (int3 on x86) rather than
running sigreturn by hand after queueing a blocked SIGUSR1.
userspace_tramp now no longer puts
Some register accessor cleanups -
userspace() was calling restore_registers and save_registers for no
reason, since userspace() is on the libc side of the house, and these
add no value over calling ptrace directly
init_thread_registers and get_safe_registers were the same thing,
so
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Chuck Ebbert <[EMAIL PROTECTED]>
No patch in mainline as this logic has been removed from 2.6.24 so it is
not necessary.
https://bugzilla.redhat.com/show_bug.cgi?id=340161
The problem code
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Sebastian Siewior <[EMAIL PROTECTED]>
patch 2e21630ddc3fb717dc645356b75771c6a52dc627 in mainline.
Currently the Geode AES module fails to encrypt or decrypt if
the coherent bits are not set
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Herbert Xu <[EMAIL PROTECTED]>
It's upstream changeset ef19454bd437b2ba14c9cda1de85debd9f383484.
[LIB] crc32c: Keep intermediate crc state in cpu order
crypto/crc32.c:chksum_final() is
These four patches are cleanups and should hold off until 2.6.25.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
UML was panicing in the case of failures of libc calls which shouldn't
happen. This is an overreaction since a failure from libc doesn't
normally mean that kernel data structures are in an unknown state.
Instead, the current process should just be killed if there is no
way to recover.
The case
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Jan Beulich <[EMAIL PROTECTED]>
patch aa506dc7b12d03fbf8fd11aab752aed1aadd9c07 in mainline.
i386: avoid temporarily inconsistent pte-s
One more of these issues (which were considered fixed a
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Andrew Hastings <[EMAIL PROTECTED]>
patch 801916c1b369b637ce799e6c71a94963ff63df79 in mainline.
x86: fix off-by-one in find_next_zero_string
Fix an off-by-one error in find_next_zero_string
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Kirill Korotaev <[EMAIL PROTECTED]>
patch c1217a75ea102d4e69321f210fab60bc47b9a48e in mainline.
x86: mark read_crX() asm code as volatile
Some gcc versions (I checked at least 4.1.1 from
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Huang, Ying <[EMAIL PROTECTED]>
patch 84e0fdb1754d066dd0a8b257de7299f392d1e727 in mainline.
x86: NX bit handling in change_page_attr()
This patch fixes a bug of
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: David P. Reed <[EMAIL PROTECTED]>
patch c399da0d97e06803e51085ec076b63a3168aad1b in mainline.
x86: fix freeze in x86_64 RTC update code in time_64.c
Fix hard freeze on x86_64 when the ntpd
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Ingo Molnar <[EMAIL PROTECTED]>
This is a merge of commits a5f2ce3c6024a5bb895647b6bd88ecae5001020a and
43581a10075492445f65234384210492ff333eba in mainline to fix a warning in
the 2.6.23.3
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Ortwin Gl??ck <[EMAIL PROTECTED]>
patch d466a9190ff1ceddfee50686e61d63590fc820d9 in mainline.
Not surprisingly the Nikon D40X DSC needs the same quirks as the D40,
but it has a separate ID.
2.6.23-stable review patch. If anyone has any objections, please let us
know.
--
From: Dan Williams <[EMAIL PROTECTED]>
patch 0b5316769774d1dc2fdd702e095f9e6992af269a in mainline.
ipw2200 makes extensive use of background scanning when unassociated or
down. Unfortunately, the
On Tue, Nov 20, 2007 at 10:22:48AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 2.6.23.9 release.
> There are 29 patches in this series, all will be posted as a response to
> this one. If anyone has any issues with these being applied, please let
> us
Simplify the hot-path (gpio value get/set) locking by taking advantage
of the fact that gpio_request() effectively locks that GPIO in memory.
This also helps avoid the belated complaints about whether this locking
is one of the places raw spinlocks are OK to use; it's now back to
using regular
On Mon, 19 Nov 2007 15:22:11 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
This looks good, but have a couple of comments. Maybe I can fix it up.
> * we do not know how to support. We ignore them for the moment.
> * XXX Rate-limit the error
--- Casey Schaufler <[EMAIL PROTECTED]> wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> ...
I have verified this version against broken-out-2007-11-20-01-45
as well. Compiles, boots, and passes tests.
Thank you.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
I just had a strange freeze that killed networking and made software
RAID fail two of my harddisks.
There are a bunch of messages from the kernel which I extracted from
the system log after reboot at the end of this mail. I hit power off
in pure paranoia after the box froze, and then started to
On Wed, 21 Nov 2007 02:43:46 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
> > On Tue, 20 Nov 2007 18:37:39 +1100
> >
> > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > actually no. IRQ balancing is not a "fast" decision; every
> >
Hi all,
Please ignore the previous patch with the same subject.
It has a bug that can manifest itself in the very exotic case
when each do {} while() iteration executes on different cpu
leading to potentially infinite loop.
This is a patch based on the Ingo's idea/patch to track
delay_tsc()
On Tue, 2007-11-20 at 14:14 +1100, Benjamin Herrenschmidt wrote:
> FYI, Here's what I have for the SCSI change. I haven't updated drivers
> to care for the new return code though, help appreciated with that as I
> don't know much about these drivers.
It looks to me like the return problem could
On Tue, 20 Nov 2007, Takashi Iwai wrote:
> At Mon, 19 Nov 2007 19:35:09 +0100 (CET),
> Jaroslav Kysela wrote:
> >
> >
> > Linus, please pull from [the linus branch at]:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus
> > gitweb interface:
> >
Nick Piggin <[EMAIL PROTECTED]> writes:
>
> For that matter, I'd like to know why it has been decided that the
> best place for IRQ balancing is in userspace.
There is a lot of possible policy in it
> It should be in kernel
> IMO, and it would probably allow better power saving, performance,
>
I think it may be time to move away from that by now misleading
"msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland" thread.
And I've cut most out of the Cc list, but by all means add any back.
On Saturday I said:
> I'm glad to report that this unionfs, not the one in 2.6.24-rc2-mm1
>
Hi,
I get the following build error when compiling 2.6.24-rc3-git1 for ia64
with gcc 3.4.5.
/opt/crosstool/gcc-3.4.5-glibc-2.3.6/ia64-unknown-linux-gnu/bin/ia64-unknown-linux-gnu-gcc
-nostdlib -shared -s -Wl,-soname=linux-gate.so.1
-Wl,-T,arch/ia64/kernel/gate.lds arch/ia64/kernel/gate.o -o
Zach Brown wrote:
That's only because you're being, deliberately or accidentally, vague
about what your actual (as opposed to imagined) requirements are.
Maybe I can help by summarizing how syslets fit in to this.
Currently the syslet patches add a single submission call which includes
an
On Tue, 20 Nov 2007 17:09:35 +0100
Mikael Ståldal <[EMAIL PROTECTED]> wrote:
> Hello.
>
> > The proper way to enable port <= 1024 binding support is adding
> > CAP_NET_BIND_SERVICE
> > to the process capability set, e.g. by using file-system capabilities.
>
> Is file-system capabilites part
On 20-11-07 19:00, Alan Cox wrote:
On Tue, 20 Nov 2007 18:52:04 +0100
Thomas Renninger <[EMAIL PROTECTED]> wrote:
Pass struct pnp_dev to pnp_clean_resource_table for cleanup reasons
Again I don't see the point of this change. A routine for cleaning up
resource tables expects logically to be
> I like the idea, but I would prefer to have three checkboxes for this option:
Nice addition, thanks for the input.
--- linux-2.6.23.8/fs/Kconfig 2007-11-16 19:14:27.0 +0100
+++ linux-2.6.23.8-dhr/fs/Kconfig 2007-11-20 19:54:54.0 +0100
@@ -918,6 +918,36 @@
help
Hi Joe,
On Mon, 19 Nov 2007 17:48:08 -0800, Joe Perches wrote:
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-davinci.c |4 ++--
> drivers/i2c/busses/i2c-omap.c|6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
> (...)
Good catch. Patch
On Tue, Nov 20, 2007 at 02:04:02AM +, Matthew Garrett wrote:
> On Mon, Nov 19, 2007 at 03:32:25PM -0800, Gary Hade wrote:
>
> > Alex, What I was trying to suggest is a boot-time kernel option,
> > not a kernel configuration option. The basic idea is to give
> > the user (with a single
On Mon, 2007-11-19 at 16:17 +0100, Ingo Molnar wrote:
> By popular demand, here is release -v24 of the CFS scheduler patch.
>
> It is a full backport of the latest & greatest scheduler code to
> v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be
> downloaded from the usual place:
On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> Jonathan McDowell sez:
> > On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote:
> > > The hearburn I have with these patches is that you are changing
> > > driver-specific attributes, not common ones as enforced/requested
> >
Arjan van de Ven wrote:
On Wed, 21 Nov 2007 02:43:46 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
On Tue, 20 Nov 2007 18:37:39 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
actually no. IRQ balancing is not a "fast" decision;
> unknown-linux-gnu/bin/ld: section .data.patch [a500 ->
> a507] overlaps section .dynamic [a3c8 ->
> a507]
Andrew Morton saw a similar thing and proposed
- . = GATE_ADDR + 0x500;
+ . = GATE_ADDR + 0x600;
in gate.lds.S ... which does
> Actually, we already established on IRC that the lasi700 driver doesn't
> need this, principally because the parisc architecture doesn't do an
> invalidate for DMA_FROM_DEVICE but a flush and invalidate
> (architecturally, if you read our manuals, even pdc is entitled to write
> back dirty
On Tue, 20 Nov 2007 13:32:06 +0100
Richard MUSIL <[EMAIL PROTECTED]> wrote:
> >> + if (chip->vendor.release)
> >> + chip->vendor.release(dev);
> >> +
> >> + /* it *should* be: chip->release != NULL */
> >
> > And that one's actually wrong in the context of kernel coding practices.
>
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> > Convert one loop to NR_CPUS to use the cpu_possible map instead.
> >
>
> I'm just wondering how broken this is. Is there any assumption that
> there is no holes in the online cpu map in this code ?
Yeah, I saw only one loop in there and so I
On Tue, 20 Nov 2007, Mel Gorman wrote:
> Went back and revisited this. Allocating them at boot-time is below but
> essentially it is a silly and it makes sense to just have two zonelists
> where one of them is for __GFP_THISNODE. Implementation wise, this involves
> dropping the last patch in the
On Tue, 20 Nov 2007, Andi Kleen wrote:
> I would suggest to separate that one and fast-track it, possibly even for
> 2.6.24
I already did. Andrew has the patch in his tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Tue, 20 Nov 2007, Mel Gorman wrote:
> Hold off testing for the moment. Getting all the corner cases right for
> __GFP_THISNODE has turned too complicated to be considered as part of a larger
> patchset. I believe it makes sense to drop the final patch and settle with
> having two zonelists.
On Tue, 2007-11-20 at 12:14 +0800, Coly Li wrote:
> Thanks for the feedback :-)
>
> Mingming Cao wrote:
> > On Tue, 2007-11-13 at 22:12 +0800, Coly Li wrote:
> >> Basic idea of my dir inode reservation patch can be found here,
> >> http://lists.openwall.net/linux-ext4/2007/11/05/3
> >>
> >> 1,
On Dienstag, 20. November 2007, Michael E Brown wrote:
> On Fri, Nov 16, 2007 at 11:53:53AM +0100, Frank Seidel wrote:
> > On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote:
> > > Hi,
> > >
> > > this is a small trivial rework of the dcdbas driver so
> > > HAL can get uevents when
On Tue, 20 Nov 2007 10:17:15 -0800
Joe Perches <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-11-20 at 21:56 +0800, Herbert Xu wrote:
> > [KERNEL]: Avoid divide in IS_ALIGN
> > I was happy to discover the brand new IS_ALIGN macro and quickly
> > used it in my code. To my dismay I found that the
Abhishek> It took me some time to get compilebench working due to the
Abhishek> known issue with drop_caches due to circular lock dependency
Abhishek> between j_list_lock and inode_lock (compilebench triggers
Abhishek> drop_caches quite frequently). Here are the results for
Abhishek> compilebench
On Tue, 20 Nov 2007 19:52:25 +0530
Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The kernel build fails, on one of the machine
>
> CC arch/x86/mach-generic/summit.o
> In file included from arch/x86/mach-generic/summit.c:16:
> include/asm/mach-summit/mach_apic.h: In
Hi Andrew,
The kernel build fails, in selinux with following error
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
security/built-in.o(.toc1+0x928): undefined reference to `selinux_xfrm_refcount'
make:
On Tue, 20 Nov 2007, Andi Kleen wrote:
> > So I think we have a 2GB area right?
>
> For everything that needs the -31bit offsets; that is everything linked
Of course.
> > 1GB kernel
> > 1GB - 1x per cpu area (128M?) modules?
> > cpu aree 0
> > 2GB limit
> > cpu area 1
> > cpu area 2
> >
Sense buffer ptr data type in the ioctl path is reverted back to u32 *
for x86 and x86_64 as in previous versions of driver. For IA64 it will
be unsigned long *. Compile time flag added for ia64 for this.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
Documentation/scsi/ChangeLog.megaraid_sas |
This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following patch preserves the test for other file
systems and makes the
On Mon, 19 Nov 2007, Mathieu Desnoyers wrote:
> > But (x) is returned to the "caller" of the macro so it should be specially
> > marged.
> >
>
> I don't think that it really matters.. the preprocessor already wraps
> all the ({ }) in a single statement, doesn't it ?
No it does not matter for
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
>
> > fixing the top 20:
>
> There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the
> BKL which I would guess can't be converted. The others I've looked at
> appear to be trivial
On Tue, 20 Nov 2007, Christoph Hellwig wrote:
> On Mon, Nov 19, 2007 at 05:11:50PM -0800, [EMAIL PROTECTED] wrote:
> > Also remove the useless zeroing after allocation. Allocpercpu already
> > zeroed the objects.
>
> You still haven't answered my comment to the last iteration.
And you have not
Hi.
First, thanks for this patch. I don't have numbers but working with my
laptop feels much better.
Just a question: does the patch include the fix (divide by zero)
you just posted in the stable review for 2.6.23.9?
Thanks and regards,
Fabio
On Nov 19, 2007 4:17 PM, Ingo Molnar <[EMAIL
* Greg KH <[EMAIL PROTECTED]> wrote:
> > but we only have cpu_clock() from v2.6.23 onwards - so we should not
> > apply the original patch to v2.6.22. (we should not have applied
> > your patch that started the mess to begin with - but that's another
> > matter.)
>
> Well, I can easily back
* Fabio Comolli <[EMAIL PROTECTED]> wrote:
> Hi.
> First, thanks for this patch. I don't have numbers but working with my
> laptop feels much better.
curious: what scheduler/kernel version have you used before?
> Just a question: does the patch include the fix (divide by zero)
> you just
On Wed, Nov 21, 2007 at 08:40:56AM +, bo yang wrote:
> Sense buffer ptr data type in the ioctl path is reverted back to u32 *
> for x86 and x86_64 as in previous versions of driver. For IA64 it will
> be unsigned long *. Compile time flag added for ia64 for this.
This changelog tells us what
On Tue, 20 Nov 2007 14:46:59 +
Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> I have one powerpc machine which managed to compile this snapshot! It
> paniced on boot as below, might be nfs so copied them. General results
> are popping out on TKO.
>
> -apw
>
> Freeing initrd memory: 1224k
Andi Kleen wrote:
On Tuesday 20 November 2007 04:50, Christoph Lameter wrote:
On Tue, 20 Nov 2007, Andi Kleen wrote:
I might be pointing out the obvious, but on x86-64 there is definitely
not 256TB of VM available for this.
Well maybe in the future.
That would either require more than 4
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> > {
> > -#ifdef CONFIG_SMP
> > on_each_cpu(flush_cpu_slab, s, 1, 1);
> > -#else
> > - unsigned long flags;
> > -
> > - local_irq_save(flags);
> > - flush_cpu_slab(s);
> > - local_irq_restore(flags);
> > -#endif
> > }
> >
>
>
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 11/19, Eric W. Biederman wrote:
>>
>> So to fix the problem this patch modifies next_tgid() to return
>> both a tgid and the task struct in question.
>>
>> A structure is introduced to return these values because it is
>> slightly cleaner and
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> > @@ -488,11 +487,8 @@ dma_async_memcpy_buf_to_buf(struct dma_c
> > tx->tx_set_dest(addr, tx, 0);
> > cookie = tx->tx_submit(tx);
> >
> > - cpu = get_cpu();
> > - per_cpu_ptr(chan->local, cpu)->bytes_transferred += len;
> > -
Hi
On Nov 20, 2007 9:41 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Fabio Comolli <[EMAIL PROTECTED]> wrote:
>
> > Hi.
> > First, thanks for this patch. I don't have numbers but working with my
> > laptop feels much better.
>
> curious: what scheduler/kernel version have you used before?
I
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> The question that arises is : are there some architectures that do not
> provide fast PER_CPU ops but provides fast local atomic ops ?
There were only a few no critical users of local_t before this patch. So I
doubt that it matters.
-
To
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This patch adds the core support code for three TMIO based MFDs.
There are no complete datasheets for these chips so their drivers are not
100% complete, however they do work.
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> > Index: linux-2.6/fs/nfs/iostat.h
> > ===
> > --- linux-2.6.orig/fs/nfs/iostat.h 2007-11-15 21:17:24.391404458 -0800
> > +++ linux-2.6/fs/nfs/iostat.h 2007-11-15
On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
> > - buf = (u32*)per_cpu_ptr(crash_notes, cpu);
> > + buf = (u32*)CPU_PTR(crash_notes, cpu);
>
> Nitpick : (u32 *)
Yeah. I tend to leave the things as they were...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This adds necessary IRQ and GPIO definitions for use by the e-series
platform support code.
0003-add-IRQ-and-GPIO-definitions-for-eseries.patch
Description: application/mbox
On Tue, 20 Nov 2007 20:48:39 +0530
Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The kernel build fails, on the AMD machine with following message
>
> arch/x86/ia32/ia32_aout.c: In function ___load_aout_binary___:
> arch/x86/ia32/ia32_aout.c:283: error: implicit declaration of
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This patch adds platform support for the TMIO devices used by the various
e-series platforms.
It depends on the previous patch in this series.
0004-add-eseries-platform-support-for-the-TMIO-multifunct.patch
From: Julia Lawall <[EMAIL PROTECTED]>
kfree_skb rather than kfree should be used for values of type struct
sk_buff *.
This was fixed using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/).
//
@@
struct sk_buff *skb;
@@
- kfree(skb)
+ kfree_skb(skb)
//
Signed-off-by:
Jonathan McDowell [mailto:[EMAIL PROTECTED] sez:
> On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote:
> > The aacraid cards, which uses hba_monitor_version,
> > hba_kernel_version and hba_bios_version for each piece
> > does not fit into the single 'firmware revision' common ideal
>
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > and send us the output? (Enabling CONFIG_TIMER_STATS,
> > CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount
> > of information.)
>
> This was w/o hpet=disable . Do you want me to test with hpet=disable?
no, this is fine. You've
On Tue, 2007-11-20 at 12:49 -0800, Christoph Lameter wrote:
> On Tue, 20 Nov 2007, Mathieu Desnoyers wrote:
>
> > > Index: linux-2.6/fs/nfs/iostat.h
> > > ===
> > > --- linux-2.6.orig/fs/nfs/iostat.h2007-11-15
> This limitation shouldn't apply to the percpu area, since gs_base can be
> pointed anywhere in the address space -- in effect we're always indirect.
The initial reference copy of the percpu area has to be addressed by
the linker.
Hmm, in theory since it is not actually used by itself I
On Tuesday 20 November 2007 3:34:24 pm Kamalesh Babulal wrote:
> Hi Andrew,
>
> The kernel build fails, in selinux with following error
>
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
>
> > rename arch/x86/{kernel/vsyscall-int80_32.S => vdso/vdso32/int80.S} (97%)
> > rename arch/x86/{kernel/vsyscall-note_32.S => vdso/vdso32/note.S} (95%)
> > rename arch/x86/{kernel/vsyscall-sigreturn_32.S =>
> > vdso/vdso32/sigreturn.S} (100%)
> > rename
On Tue, 20 Nov 2007, Andi Kleen wrote:
>
> > This limitation shouldn't apply to the percpu area, since gs_base can be
> > pointed anywhere in the address space -- in effect we're always indirect.
>
> The initial reference copy of the percpu area has to be addressed by
> the linker.
Right that
On Tue, 2007-11-20 at 21:37 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
> >
> > > fixing the top 20:
> >
> > There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the
> > BKL which I would guess
>
> Right so I could move the kernel to
>
> #define __PAGE_OFFSET _AC(0x8100, UL)
> #define __START_KERNEL_map_AC(0xfff8, UL)
That is -31GB unless I'm miscounting. But it needs to be >= -2GB
(31bits)
Right now it is at -2GB + 2MB, because it is loaded at physical
Andi Kleen wrote:
This limitation shouldn't apply to the percpu area, since gs_base can be
pointed anywhere in the address space -- in effect we're always indirect.
The initial reference copy of the percpu area has to be addressed by
the linker.
Hmm, in theory since it is not actually used by
On Tue, 2007-11-20 at 12:05 -0800, Roland Dreier wrote:
> > Actually, we already established on IRC that the lasi700 driver doesn't
> > need this, principally because the parisc architecture doesn't do an
> > invalidate for DMA_FROM_DEVICE but a flush and invalidate
> > (architecturally, if
On Tue, Nov 20, 2007 at 02:16:17PM +0100, Damien Wyart wrote:
> Hello,
>
> > > > Ok, so it's not synchronous writes that we are doing - we're just
> > > > submitting bio's tagged as WRITE_SYNC to get the I/O issued quickly.
> > > > The "synchronous" nature appears to be coming from higher level
>
This looks ok to me.
Thanks,
Roland
-
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/
On 20 Nov 2007, H. Peter Anvin outgrape:
> This one is definitely messy. There is absolutely no way to know what
> gcc has miscompiled.
Actually, since this only affects abs() calls containing multiplications
or divisions by negative constants, you can at least make a pretty good
guess as to its
On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote:
>
> * Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > but we only have cpu_clock() from v2.6.23 onwards - so we should not
> > > apply the original patch to v2.6.22. (we should not have applied
> > > your patch that started the mess to
thanks, applied.
-
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/
On 11/20, Roland McGrath wrote:
>
> Subject should be "kill PT_ATTACHED".
>
> > - (!(child->ptrace & PT_ATTACHED) || child->real_parent != current)
> > - && child->signal != NULL) {
> > +child->sighand != NULL) {
>
> This does s/signal/sighand/ without comment.
Ah yes,
Hi Andrew,
The kernel build fails, with randconfig
CC arch/x86/kernel/asm-offsets.s
In file included from include/asm/thread_info.h:4,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
On Tue, 20 Nov 2007 13:26:33 -0500
Jeff Dike <[EMAIL PROTECTED]> wrote:
> +extern void os_dump_core(void) __attribute__ ((noreturn));
We have a __noreturn helper for this.
I'd have expected checkpatch to have a little whine about the space-before-(,
but it didn't.
-
To unsubscribe from this
On (20/11/07 12:18), Christoph Lameter didst pronounce:
> On Tue, 20 Nov 2007, Mel Gorman wrote:
>
> > Went back and revisited this. Allocating them at boot-time is below but
> > essentially it is a silly and it makes sense to just have two zonelists
> > where one of them is for __GFP_THISNODE.
801 - 900 of 1146 matches
Mail list logo
