Christoph Hellwig wrote:
On Wed, Nov 21, 2007 at 02:02:43PM +, Phillip Lougher wrote:
Unfortunately the move to fixed little endian filesystem will involve
another filesystem layout change. The current filesystem layout still
uses packed bitfield structures, and it is impossible to swap
On Wed, 21 Nov 2007 15:52:37 +0100, "Markus Rechberger"
<[EMAIL PROTECTED]> wrote:
> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>> > On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> > > Am Mittwoch 21 November
On Wed, 21 Nov 2007 15:42:43 +0100, "Markus Rechberger"
<[EMAIL PROTECTED]> wrote:
> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>> On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
>> > > On 11/21/07, Markus
Hi,
On Wed, 21 Nov 2007 15:37:20 +0100, "Markus Rechberger"
<[EMAIL PROTECTED]> wrote:
> On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
>> > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>> > > On 11/21/07, Mark Lord
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]>
On Wed, Nov 21, 2007 at 02:02:43PM +, Phillip Lougher wrote:
> Unfortunately the move to fixed little endian filesystem will involve
> another filesystem layout change. The current filesystem layout still
> uses packed bitfield structures, and it is impossible to swap these
> using the
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > > > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote:
>
On 11/21/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote:
> > > > Markus Rechberger wrote:
> > > > > Hi,
> > > > >
> > > > >
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Sun, 2007-11-18 at 21:58 +, Roger Leigh wrote:
>> Hi folks,
>>
>> I'm using an Apple Cinema Display connected via DVI to an Apple Mac
>> Mini with Radeon 9200 graphics. This used to work fine, but with
>> kernels >= 2.6.19, the monitor
Vincent Fortier wrote:
Le mardi 20 novembre 2007 à 18:56 -0600, Robert Hancock a écrit :
This fixes some problems with ATAPI devices on nForce4 controllers in ADMA
mode on systems with memory located above 4GB. We need to delay setting the
64-bit DMA mask until the PRD table and padding buffer
On Wed, Nov 21, 2007 at 09:01:36AM -0500, Stephen Smalley wrote:
> Do not clear f_op when removing entries since it isn't safe to do.
If this is still safe for selinux I'm fine with it. It also gets rid
of one of them few remaining s_files users which is always good.
Btw, after this patch we
On Tue, 2007-11-20 at 15:17 +, Christoph Hellwig wrote:
> On Tue, Nov 20, 2007 at 10:05:05AM -0500, Stephen Smalley wrote:
> > > Nice, getting rid of this is a very good step formwards. Unfortunately
> > > we have another copy of this junk in
> > >
Dave Jones wrote:
The biggest problem we've seen with it (asides from having to rediff
it every time we rebase when there isn't a newer upstream)
Yes, this is mainly my fault. There was a gap of 10 months between the
3.2 release in January this year, and the latest in November. With the
The error path in sys_mq_getsetattr() after the call to
audit_mq_getsetattr() is wrong - the info->lock is not
unlocked and the struct file *filp is not put.
Fix them both.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 0ce1ba6..7d1b8aa
On Wed, Nov 21, 2007 at 01:20:51PM +, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff
> Garzik <[EMAIL PROTECTED]> says:
>
> >
> > SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> > based on a reading of
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> Another issue that I encountered with the cpu_alloc stuff.
>
>
>
> The module subsystem cannot handle symbols that are zero. If symbols are
> present that have a zero value then the module resolver prints out
> a message that these symbols are
"linux-os (Dick Johnson)" <[EMAIL PROTECTED]> writes:
> Executing this script.
>
> cat #include
>
> #define IS_ALIGNED(x,a) (((x) % ((typeof(x))(a))) == 0)
> #define _IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
>
> int main()
> {
> int i;
Hi Pierre,
Thanks for explaining.
I guess then I have a crappy SDIO card that needs the "voodoo" bit set
for correct operation. There are other registers close to the START
ADDRESS so it is a FIFO, but the Incrementing Address flag is needed to
read from and write to the FIFO correctly.
In article <[EMAIL PROTECTED]> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff
Garzik <[EMAIL PROTECTED]> says:
>
> SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
> based on a reading of net/ipv4/udp.c.
Disagree. UDP checksum is mandatory in IPv6.
--yoshfuji
-
To
Nix wrote:
I've grepped all the source on my system (1148 expanded upstream source
tarballs or git/cvs/svn trees including the Linux kernel, most of GNOME,
and all of KDE and X.org) and found that hits are extremely rare: not as
rare as calls to seekdir() and telldir() :) but rare. (Quite a lot
Pavel Krauz <[EMAIL PROTECTED]> writes:
> 256 65792 131328 196864 262400 327936 393472 459008 524544 590080 655616
> 721152 786688
> Node: 0, start_pfn: 1048576, end_pfn: 1245183
> Setting physnode_map array to node 0 for pfns:
> 1048576 1114112 1179648
> get_memcfg_from_srat: assigning
> > All you need is a 2MB area (16MB is too large if you really
> > want 16k CPUs someday) somewhere in the -2GB or probably better
> > in +2GB. Then the linker puts stuff in there and you use
> > the offsets for referencing relative to %gs.
>
> 2MB * 16k = 32GB. Even with 4k cpus we will have
On Wed, 21 Nov 2007 11:57:01 +
Dean Jenkins <[EMAIL PROTECTED]> wrote:
> Hi Pierre,
>
> I've looked at the SD Card Association's SDIO Part E1 V2.00
> specification concerning the Incrementing Address OP Code field for
> CMD53.
>
> The specification indicates that the START ADDRESS is
On Tue, 20 Nov 2007, Richard B. Johnson wrote:
> On Tue, 20 Nov 2007, Herbert Xu wrote:
>
>> Hi:
>>
>> [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 generated code
>> used division
ipc_lock_check_down(), ipc_lock_check() and ipcget() seem
too large to be inline. Besides, they give no optimization
being inline as they perform calls inside in any case.
Moving them into ipc/util.c saves 500 bytes of vmlinux and
shortens IPC internal API.
$ ./scripts/bloat-o-meter vmlinux-orig
On 21-11-07 07:08, Andrew Morton wrote:
fix (for my config ?) is attached.
=
This was necessary to build.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
arch/ia64/lib/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
On Sat 2007-11-17 20:42:40, Sam Ravnborg wrote:
> On Sat, Nov 17, 2007 at 11:35:01AM -0800, Arjan van de Ven wrote:
> > On Sat, 17 Nov 2007 10:46:52 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > by ... not too much at least, gcc ought to be quite good at merging
> > > >
Andrew Morton <[EMAIL PROTECTED]> wrote:
> So... what went wrong with broken-out-2007-11-20-01-45.tar.gz?
It differs too much from Linus's base.
> But sometimes it doesn't work out very well. There's lot of stuff
> outstanding again. Immediate problems are from an x86 exec randomisation
>
Hi!
> > > > It works. Subjectively I have relatively long pause after first
> > > > Suspending console
> > > > message (where it hangs otherwise), according to dmesg timestamp it is
> > > > about
> > > > 1 second before next messages appear. Also last two times I tried it
> > > > writeout
> >
SO_NO_CHECK support for IPv6 appeared to be missing. This is presented,
based on a reading of net/ipv4/udp.c.
I wonder if IPv4's CHECKSUM_PARTIAL check from udp_push_pending_frames()
also needs to be copied to IPv6?
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
net/ipv6/udp.c | 10
Daniel Lezcano wrote:
Pavel Emelyanov wrote:
+2. Intentionnaly, two equal user ids in different user namespaces
Intentionaly
Intentionally
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, November 21, 2007 00:01, [EMAIL PROTECTED] wrote:
>>There is.. it's called "root privileges".
> yes, true.
>
> but - regardless of being a windows app or not - what if you want to take a
> look on your system as a whole,
> especially when using some tool which graphically shows how and
Manpage 'man 2 fork' says:
'File locks ... are not inherited.'
This is true for POSIX locks, but not for flock-type locks.
This phrase comes directly from posix fork manpage,
which is not aware of flock-style locks.
Maybe fork manpage should rather say:
... POSIX file
On Wed, 21 Nov 2007, Roland McGrath wrote:
>
> This consolidates the four different places that implemented the same
> encoding magic for the GDT-slot 32-bit TLS support. The old tls32.c is
> renamed and only slightly modified to be the shared implementation guts.
Cool patchset.
One minor
Hi Pierre,
I've looked at the SD Card Association's SDIO Part E1 V2.00
specification concerning the Incrementing Address OP Code field for
CMD53.
The specification indicates that the START ADDRESS is inserted into the
Register Address register field. When the OP Code field has a value of 1
then
Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > > I'm looking at the linux uvc driver, and noticed after resuming my
>
On Wednesday 21 November 2007 12:02:38 Metzger, Markus T wrote:
Your patch seems to be still word wrapped.
>
> It seems we're avoiding to declare a structured data type and instead
> prefer to describe the type indirectly.
> We gain the flexibility to work with different data layouts.
> We
Hi,
> >and it seems like this patch and perfmon2 are going to have to
> >live with
> >each other... since they both require the use of the DS save area...
>
> Hmmm, this might require some synchronization between those two.
>
> Do you know how (accesses to) MSR's are managed by the kernel?
I think, the status paramter should be unsigned. Is this correct?
This also fixes a sparse warning about different signedness.
Only compile tested, because i do not have the hardware.
From: Andre Haupt <[EMAIL PROTECTED]>
Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
---
On Tue, Nov 20 2007, FUJITA Tomonori wrote:
> pci-noop.c doesn't use DMA mappings.
you should send that one to the alpha maintainers, it needs to go in
that way.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, Nov 20 2007, FUJITA Tomonori wrote:
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
applied
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
>From time to time people begin discussions about how the
namespaces are working/going-to-work together.
Ted T'so proposed to create some document that describes what
problems user may have when he/she creates some new namespace,
but keeps others shared. I liked this idea, so here's the
initial
From: Julia Lawall <[EMAIL PROTECTED]>
When values of type struct sk_buff * are freed from within an interrupt
handler, dev_kfree_skb_irq should be used rather than kfree or kfree_skb.
In most of the cases below, the function containing the free ends up as a
URB completion callback. Such
Pavel Emelyanov wrote:
> The commit
>
> commit 7d69a1f4a72b18876c99c697692b78339d491568
> Author: Cedric Le Goater <[EMAIL PROTECTED]>
> Date: Sun Jul 15 23:40:58 2007 -0700
>
> remove CONFIG_UTS_NS and CONFIG_IPC_NS
>
> accidentally removed the code, that prevented the uts->hostname
>
Hi
On Nov 21, 2007 11:39 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Fabio Comolli <[EMAIL PROTECTED]> wrote:
>
> > To answer your latest mail, again I don't have numbers but from my
> > point ov view:
> >
> > 23.1 < 23.1+ck < 23.8+cfs.24
> >
> > where 23.1+ck is slightly better than vanilla
The commit
commit 7d69a1f4a72b18876c99c697692b78339d491568
Author: Cedric Le Goater <[EMAIL PROTECTED]>
Date: Sun Jul 15 23:40:58 2007 -0700
remove CONFIG_UTS_NS and CONFIG_IPC_NS
accidentally removed the code, that prevented the uts->hostname
and uts->domainname values from being
>> - the internal buffer interpretation as well as the corresponding
>> operations are selected at run-time by hardware detection
>> - different processors use different branch record formats
>
>I still think it would be far better if you would switch this
>over to be table
>driven. e.g.
On 11/21/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 11/21/07, Mark Lord <[EMAIL PROTECTED]> wrote:
> > Markus Rechberger wrote:
> > > Hi,
> > >
> > > I'm looking at the linux uvc driver, and noticed after resuming my
> > ..
> >
> > Pardon me.. what is the "uvc" driver? Which
On 11/21/07, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch does fix missed increment on counter
>
> Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
> ---
> Sorry for that nonstandart patch submission - I've only access
> to gmail with Internet Explorer on my work. If that is not OK -
Hi,
sorry, I messed up the #ifdef directives (confused them with C++...). Here's
the really working patch:
--- 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
There are already 4 error paths in alloc_uid() that do incremental
rollbacks. I think it's time to merge them. This costs us 8 lines
of code :)
Maybe it would be better to merge this patch with the previous
one, but I remember that some time ago I sent a similar patch
(fixing the error path and
The commit
commit 5cb350baf580017da38199625b7365b1763d7180
Author: Dhaval Giani <[EMAIL PROTECTED]>
Date: Mon Oct 15 17:00:14 2007 +0200
sched: group scheduling, sysfs tunables
introduced the uids_mutex and the helpers to lock/unlock it.
Unfortunately, the error paths of alloc_uid() were
On Tue, 20 Nov 2007 09:34:38 -0800
"Nelson, Shannon" <[EMAIL PROTECTED]> wrote:
> >-Original Message-
> >From: Haavard Skinnemoen [mailto:[EMAIL PROTECTED]
> >+#define TEST_BUF_SIZE (16384)
>
> You might make this a module parameter so we can test with various
> sizes.
* Fabio Comolli <[EMAIL PROTECTED]> wrote:
> To answer your latest mail, again I don't have numbers but from my
> point ov view:
>
> 23.1 < 23.1+ck < 23.8+cfs.24
>
> where 23.1+ck is slightly better than vanilla 23.1 and 23.8+cfs.24 is
> much better than 23.1+ck.
>
> My workload is pretty
On Wed, 21 Nov 2007, Avi Kivity wrote:
> headers_check continues to complain. Is the only recourse to add
> asm/kvm.h for all archs?
that's what's happened with other header files. see asm-*/auxvec.h,
for example.
rday
--
At Tue, 20 Nov 2007 15:31:26 +0100,
Rene Herman wrote:
>
> On 20-11-07 15:19, Thomas Renninger wrote:
>
> > At the end is some example code how things could get even more cleaned
> > up. It shows how I think pnp layer and one example driver would get
> > adjusted. There are not that much drivers
This consolidates the four different places that implemented the same
encoding magic for the GDT-slot 32-bit TLS support. The old tls32.c is
renamed and only slightly modified to be the shared implementation guts.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
diff --git
The fs_base and gs_base fields are available in user_regs_struct.
But reading these via ptrace (PTRACE_GETREGS or PTRACE_PEEKUSR) does
not give a reliably useful value. The thread_struct fields are 0
when do_arch_prctl decided to use a GDT slot instead of MSR_FS_BASE,
which it does for a value
This replaces the desc_empty macro with an inline. It now handles
easily any of the four different types used between 32/64 code to
refer to these 8 bytes. It's identical in both asm-x86/processor_64.h
and asm-x86/processor_32.h, so if these files ever get merged this
function can be in the
On 11/21/07, Jim Keniston <[EMAIL PROTECTED]> wrote:
> I have one minor suggestion on the code -- see below -- but I'm willing
> to ack that with or without the suggested change. Please also see
> suggestions on kprobes.txt and the demo program.
Thanks...I've made the necessary changes. More
This changes a couple of places to use the get_desc_base function.
They were duplicating the same calculation with different equivalent code.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
diff --git a/arch/x86/ia32/tls32.c b/arch/x86/ia32/tls32.c
index 1cc4340..5291596 100644
---
This defines the get_desc_base function in asm-x86/desc_64.h to match the
one in desc_32.h. If these two files ever get merged together, this
function could be the same in both.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
diff --git a/include/asm-x86/desc_64.h b/include/asm-x86/desc_64.h
On Wednesday 21 November 2007 11:02:01 [EMAIL PROTECTED] wrote:
>
> v2:
> - fix some compile errors when NR_CPUS > default for ia386 (128 & 4096)
> - remove unneccessary includes
>
> Convert cpumask_of_cpu to use a static percpu data array and
> set_cpus_allowed to pass the cpumask_t arg
Please ignore this patch. In the case of btsdio.c, the enclosing function
is used as an interrupt handler, so it should not use kfree_skb either.
julia
On Tue, 20 Nov 2007, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> kfree_skb rather than kfree should be used for values
Avi Kivity wrote:
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK include/linux/usb/audio.h
CHECK include/linux/kvm.h
/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
asm/kvm.h,
Avoid pushing cpumask variables onto stack when calling set_cpus_allowed
when NR_CPUS > BITS_PER_LONG by passing cpumast_t arg as a pointer.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/sched.h | 11 +--
kernel/sched.c| 22 --
2 files
v2:
- fix some compile errors when NR_CPUS > default for ia386 (128 & 4096)
- remove unneccessary includes
Convert cpumask_of_cpu to use a static percpu data array and
set_cpus_allowed to pass the cpumask_t arg as a pointer.
Conditioned on NR_CPUS > BITS_PER_LONG.
Compiled and tested
v2: fix some compile errors when NR_CPUS > default for i386 arch's.
Here is a simple patch to use a per cpu cpumask instead of constructing
one on the stack. I have been running awhile with this one:
Do not use stack to allocate cpumask for cpumask_of_cpu
Signed-off-by: Christoph Lameter
Sam Ravnborg wrote:
On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
Kamalesh Babulal wrote:
Andrew Morton wrote:
On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
<[EMAIL PROTECTED]> wrote:
The make headers_check fails,
CHECK
On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
> Kamalesh Babulal wrote:
> >Andrew Morton wrote:
> >
> >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> >><[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>The make headers_check fails,
> >>>
> >>> CHECK
On Wed, Nov 21, 2007 at 10:03:46AM +0100, Jesper Nilsson wrote:
> Improve including of architecture dependent Kconfig files.
>
> - Always include the architecture dependent Kconfig files.
> - Wrap architecture dependent Kconfig files inside an appropriate
> "if ETRAX_ARCH_Vxx" block.
>
> This
Andrew Morton wrote:
> On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi Andrew,
Kernel panic's across different architectures like
On Wed, 2007-11-21 at 09:37 +0100, Rene Herman wrote:
> On 20-11-07 23:18, Alan Cox wrote:
>
> >>> Again I don't see the point of this change. A routine for cleaning up
> >>> resource tables expects logically to be passed a resource table to clean
> >>> up not some device it may be attached to.
>
On Wed, 21 Nov 2007, Max wrote:
> Is it the same to comment out a variable in .config than assigning
> 'N' to it?
>
> Also could somebody explain the big picture of how does the kernel
> configuration/build process treats the commented out variables in
> .config?
>
> Or even more general:
>
>
Eric W. Biederman wrote:
> Below is a preliminary patch. It solves the directory issue but it doesn't
> play well with proc_mnt and proc_flush_task. It works by simply caching the
> network namespace when we mount proc so we don't have to be fancy and dynamic.
Nice... Where should we apply this
On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi Andrew,
> >>
> >> Kernel panic's across different architectures like powerpc, x86_64,
> >
>
Am Montag, 12. November 2007 schrieb Alasdair G Kergon:
> On Mon, Nov 12, 2007 at 01:33:21PM +0100, Toralf Förster wrote:
> > the build with the attached .config failed, make ends with:
> > drivers/built-in.o: In function `hp_sw_end_io':
> > dm-mpath-hp-sw.c:(.text+0xb0596): undefined reference to
Is it the same to comment out a variable in .config than assigning 'N' to it?
Also could somebody explain the big picture of how does the kernel
configuration/build process treats the commented out variables in
.config?
Or even more general:
Could anybody please help me in understanding the
Andrew Morton wrote:
> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Hi Andrew,
>>
>> Kernel panic's across different architectures like powerpc, x86_64,
>
> powerpc complains about IO-APICs??
>
>> Dentry cache hash table entries: 8388608 (order: 14,
On Wed, 21 Nov 2007, Andrew Morton wrote:
> On Wed, 21 Nov 2007 03:52:08 -0500 (EST) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
... snip ...
> > i'm sure i'm going to humiliate myself for asking this, but shouldn't
> > i be able to reproduce the above by just running:
> >
> > $ make
On Wed, 21 Nov 2007 03:52:08 -0500 (EST) "Robert P. J. Day" <[EMAIL PROTECTED]>
wrote:
> On Wed, 21 Nov 2007, Avi Kivity wrote:
>
> > Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > >
> > > > On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > > > <[EMAIL PROTECTED]> wrote:
> > > >
>
Improve including of architecture dependent Kconfig files.
- Always include the architecture dependent Kconfig files.
- Wrap architecture dependent Kconfig files inside an appropriate
"if ETRAX_ARCH_Vxx" block.
This makes it possible to run the configuration even without the arch links,
which
This patch does fix missed increment on counter
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
Sorry for that nonstandart patch submission - I've only access
to gmail with Internet Explorer on my work. If that is not OK - will resend
the patch today evening with mutt.
---
Hi Andrew,
The kernel build fails on powerpc while linking,
AS .tmp_kallsyms3.o
LD vmlinux.o
ld: TOC section size exceeds 64k
make: *** [vmlinux.o] Error 1
The patch posted at http://lkml.org/lkml/2007/11/13/414, solves this
failure.
--
Thanks & Regards,
Kamalesh Babulal,
Linux
On Wed, 21 Nov 2007, Avi Kivity wrote:
> Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> >
> > > On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > > The make headers_check fails,
> > > >
> > > > CHECK include/linux/usb/gadgetfs.h
> > > >
>>> Greg KH <[EMAIL PROTECTED]> 21.11.07 00:14 >>>
>On Tue, Nov 20, 2007 at 03:49:43AM -0700, Jan Beulich wrote:
>> This patch (in its incarnation in our SLE10SP2 tree) is causing resource
>> allocation failures on one of my machines.
>
>Does the latest 2.6.23 kernel also cause these same
Hi
On Nov 20, 2007 10:53 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > >
> > > curious: what scheduler/kernel version have you used before?
> >
> > I was using 2.6.23.1 with ck patches.
>
> are you sure? The last -ck patch i can find is for .22:
>
>
On Wed, 21 Nov 2007 17:42:15 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Hi, Andrew
>
> I got following result in 'sync' command.
> It was too slow. (memory controller config is off ;)
> I attaches my .config.
> ==
> [2.6.24-rc3-mm1]
> [EMAIL PROTECTED] ~]$ dd if=/dev/zero of=./tmpfile
On Wed, 21 Nov 2007 17:42:15 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Hi, Andrew
>
> I got following result in 'sync' command.
> It was too slow. (memory controller config is off ;)
> I attaches my .config.
> ==
> [2.6.24-rc3-mm1]
> [EMAIL PROTECTED] ~]$ dd if=/dev/zero of=./tmpfile
Kamalesh Babulal wrote:
Andrew Morton wrote:
On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK
On 20-11-07 23:18, Alan Cox wrote:
Again I don't see the point of this change. A routine for cleaning up
resource tables expects logically to be passed a resource table to clean
up not some device it may be attached to.
He needs to pass the pnp_dev to later be able to replace the:
Andrew Morton wrote:
> On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> The make headers_check fails,
>>
>> CHECK include/linux/usb/gadgetfs.h
>> CHECK include/linux/usb/ch9.h
>> CHECK include/linux/usb/cdc.h
>> CHECK include/linux/usb/audio.h
>>
On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> The make headers_check fails,
>
> CHECK include/linux/usb/gadgetfs.h
> CHECK include/linux/usb/ch9.h
> CHECK include/linux/usb/cdc.h
> CHECK include/linux/usb/audio.h
> CHECK include/linux/kvm.h
Hi,
>> tpm_tis 00:0a: 1.2 TPM (device-id 0x, rev-id 255)
>> But correct is:
>> tpm_tis 00:0c: 1.2 TPM (device-id 0x3203, rev-id 9)
>> This short patch fixes this issue.
> Is this bug sufficiently serious to warrant inclusion of the fix in
> 2.6.24? 2.6.23.x?
I think including the patch for
Hi Andrew,
The make headers_check fails,
CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK include/linux/usb/audio.h
CHECK include/linux/kvm.h
/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires asm/kvm.h,
which
`do_safe' parameter is not in generic_set_mtrr but explained.
Maybe someone forgot removing.
Signed-off-by: Masatake YAMATO <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 992f08d..e0c0676 100644
---
Here is a simple patch to use a per cpu cpumask instead of constructing
one on the stack. I have been running awhile with this one:
Do not use stack to allocate cpumask for cpumask_of_cpu
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Modified to be used only if NR_CPUS is greater than
On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
...
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /pub/scm /
Convert cpumask_of_cpu to use a static percpu data array and
set_cpus_allowed to pass the cpumask_t arg as a pointer.
Conditioned on NR_CPUS > BITS_PER_LONG.
Compiled and tested for i386 and x86_64. I'd appreciate
feedback on other architectures.
(Note: there are still compile/test errors
Avoid pushing cpumask variables onto stack when calling set_cpus_allowed
when NR_CPUS > BITS_PER_LONG by passing cpumast_t arg as a pointer.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/sched.h | 11 +--
kernel/sched.c| 22 --
2 files
201 - 300 of 602 matches
Mail list logo