On Wed, 6 Dec 2006 22:42:07 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> But I wouldn't want to think about an implementation as long as we have
> that WORK_STRUCT_NOAUTOREL horror in there. Can we just nuke that? Only
> three drivers need it and I bet they can be modified to use the usual
Description: Check the return value of kmalloc() in function con_init(), in
file drivers/char/vt.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 87587b4..6aa08cb 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2640,6
Hi Venki,
On Wed, Dec 06, 2006 at 10:27:01AM -0800, Pallipadi, Venkatesh wrote:
> But, if we make cpufreq more affected_cpus aware and have a per_cpu
> target()
> call by moving set_cpus_allowed() from driver into cpufreq core and
> define
> the target function to be atomic/non-sleeping type,
Hi Alan,
Sorry for late followup on this.
I did found the problem. It was 32 bit binary running on 64 bit arch.
Actually main kernel had fixed this problem in 2.6.14
(http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2fd4ef85e0db9ed75c98e13953257a967ea55e03)
But
From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 22:20:22 -0800
> Ok, good to know, since that's what we're doing with ARM drivers
> presently. What's the preferred method going forward?
There are multiple ways provided to solve the problem so that
platforms can use whichever
Hi,
Another piece of information...
If i do on shell.
# while 1
# ./grow_dentry
# end
(grow_dentry is C code I've posted in previous msg.)
Then dentry_cache grows really fast.
But if within 'C' code if I write while(1), then everything is okay.
(No substantial growth ).
Thanks
-Kunal
On
On Wed, 2006-12-06 at 17:56 -0600, Stephen Torri wrote:
> I am trying to create a custom ELF and Windows PE loader for the purpose
> of security research. I am having a difficult time finding how to
> allocate memory for a binary at the desired address in memory
> (especially if its
Description: Check the return value of kmalloc() in function dbg_kmalloc(), in
file net/wanrouter/wanmain.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/net/wanrouter/wanmain.c b/net/wanrouter/wanmain.c
index 316211d..263450c 100644
--- a/net/wanrouter/wanmain.c
+++
On Thu, Dec 07, 2006 at 11:47:01AM +0530, Srivatsa Vaddagiri wrote:
> - Make it rw-sem
I think rw-sems also were shown to hit deadlocks (recursive read-lock
attempt deadlocks when a writer comes between the two read attempts by the same
thread). So below suggestion only seems to makes sense
On Wed, 6 Dec 2006 17:21:50 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 6 Dec 2006, Linus Torvalds wrote:
> >
> > How about something like this?
>
> I didn't get any answers on this. I'd like to get this issue resolved, but
> since I don't even use libphy on my main
On Wed, Dec 06, 2006 at 05:26:14PM -0700, Bjorn Helgaas wrote:
> loadkeys is holding the cpu_hotplug lock (acquired in flush_workqueue())
> and waiting in flush_cpu_workqueue() until the cpu_workqueue drains.
>
> But events/4 is responsible for draining it, and it is blocked waiting
> to acquire
On 12/6/06, David Miller <[EMAIL PROTECTED]> wrote:
From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 13:19:41 -0800
> On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Matt Reimer" <[EMAIL PROTECTED]>
> > Date: Tue, 5 Dec 2006 16:57:12 -0800
> >
> > > Right, but isn't
On Thu, 07 Dec 2006 11:56:32 +0800 Albert Lee <[EMAIL PROTECTED]> wrote:
>
> It seems the opps occurred in the ata_exec_internal(). Could you please
> try the attached patch and see if the older ata_exec_internal() works?
> This can help to narrow it down.
This worked much better:
Waiting for
so first hunk of the patch doesn't have nothing in common with second ,
and it is different disable acpi_irqs than disable all acpi,
callacpi_disable_pci () is acpi=off.
pci=noacpi mean it will not use acpi for pci bus scan and irq routing setting.
acpi=noirq mean it will only not use irq
On Wed, 6 Dec 2006 17:12:37 -0600
Michael Halcrow <[EMAIL PROTECTED]> wrote:
> Public key support code. This reads and writes packets in the header
> that contain public key encrypted file keys. It calls the messaging
> code in the previous patch to send and receive encryption and
> decryption
On Wed, 6 Dec 2006 17:06:38 -0600
Michael Halcrow <[EMAIL PROTECTED]> wrote:
> This is a re-submission of the same public key patches (updated for
> 2.6.19-rc6-mm2) that were submitted for review a while back.
I made a number of comments last time around, some temperate, some not.
I trust the
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
The first boot will need to hold a copy of the in memory fs for the
second boot. This image can be large (much larger than the kernel),
hence we can save time when the memory
> > -#ifdef CONFIG_KEXEC
> > unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> > unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
> I'm still not seeing how using crashk_res is valid here when
> CONFIG_KEXEC=n. Can you explain that, please?
> You
Hi I have a dual PIII Motherboard based on a ServerWorks LE chipset,
the motherboard is from an HP Netserver E 800 which is a customised
ASUS CUR-DLS.
in UP config everything is OK in SMP the system slows right down,
I've been searching and recompiling my kernel for days looking for
the
The changes in 365970a1ea76d81cb1ad2f652acb605f06dae256 result in
cmpxchg() being invoked with bogus sizes with gcc-4.1 on SH, particularly
when kernel/workqueue.c:set_wq_data() is left inlined:
LD .tmp_vmlinux1
kernel/built-in.o: In function `__cmpxchg':
Michael Neuling wrote:
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
The first boot will need to hold a copy of the in memory fs for the
second boot. This image can be large (much larger than the kernel),
hence we can
Hi,
On Wed, Dec 06, 2006 at 09:22:29AM +0100, Jesper Juhl wrote:
> The following messages just showed up in dmesg on one of my servers.
> The server seems to be running fine but I would like to know if
> there's a real problem here or if the message is just noise.
>
> The server is running 2.4.25
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
The first boot will need to hold a copy of the in memory fs for the
second boot. This image can be large (much larger than the kernel),
hence we can save time when the memory
Jiri Kosina wrote:
> Do you think that you could wait a little bit more, after the split has
> been done? (it's currently planned approximately after 2.6.20-rc1). It
> seems to me that your patches will apply almost cleanly on top of the
> split patches (you will have to change the pathnames,
On Sun, 2006-11-26 at 15:23 -0800, Yinghai Lu wrote:
[PATCH 2/3] x86: remove duplicated parser for "pci=noacpi"
Remove "pci=noacpi" parse in acpi/boot.c, because it is duplicated
with that in pci/common.c.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/acpi/boot.c
Hi Linus,
This tree has mainly driver updates for the i915 vblank + DRM drawable
changes, along with some minor bugfixes.
Please pull from the 'drm-patches' branch:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
(or from master if the mirroring is still
On Wed, Dec 06, 2006 at 04:18:37PM +0100, Marcel Holtmann wrote:
> Hi Dmitry,
>
> > > > > I still have the same objection - the "simple'" code will have to be
> > > > > compiled into the driver instead of being a separate module and
> > > > > eventyally will lead to a monster-size HID module. We
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char *
Description: Free previously allocated memory (in array elements) if kmalloc()
returns NULL, in function submit_urbs(), in file
drivers/media/video/cpia2/cpia2_usb.c. If the system is low on memory, then
previously allocated memory in the same array should be freed up to help the
system
On Thu, 07 Dec 2006 14:42:57 +1100 Michael Neuling wrote:
> Add retain_initrd option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Updated based on comments from akpm.
> Added
Am Donnerstag, 7. Dezember 2006 03:28 schrieb Sergio Monteiro Basto:
> On Wed, 2006-12-06 at 23:30 +0100, Ingo Molnar wrote:
> > Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> Hi Ingo,
> Just curiosity ,have we this patch on
Stephen Rothwell wrote:
> Hi all,
>
> I get an oops during initialisation of the pata_pdc2027x module on a
> POWER 285 machine. This is on a very recent Linus kernel tree
> (ff51a98799931256b555446b2f5675db08de6229) with Paulus' powerpc tree
> (that has now been merged). The oops looks like
Michael Neuling wrote:
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
This
On Tue, Dec 05, 2006 at 11:26:51PM -0800, Greg KH wrote:
> > If this looks good, I'll post a diff for gregkh.
>
> This looks very good, thanks for doing this work.
welcome - feels like the most significant contribution I've made
to kernel in a long time.
> I do have a few minor comments:
I'll
Add retain_initrd option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Updated based on comments from akpm.
Added documentation and changed option name to "retain_initrd"
Tested on POWERPC
> I would have to agree with this; it also seems a bit odd to me to have
> this at all (kexec provides a new kernel image, surely it also
> provides a new initrd image???)
The first boot will need to hold a copy of the in memory fs for the
second boot. This image can be large (much larger than
Greg,
I wonder why the netconsole could print all boot log from beginning with
buffer. But your usb serial console can not.
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Dear Sir,
This is Kevin Wang from Areca Technology, Tech-Support Team.
regarding your problem, please trying to disable ACPI in kernel loader.
if the problem happen as soon as driver loaded, it should be the IRQ
releated issue.
the motherboard bios didn't assigned a correct IRQ to controller, it
On Wed, 2006-12-06 at 23:30 +0100, Ingo Molnar wrote:
> Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> From: Ingo Molnar <[EMAIL PROTECTED]>
Hi Ingo,
Just curiosity ,have we this patch on 2.6.19-1.rt6 ?
Thanks,
--
Sérgio M.B.
smime.p7s
Description: S/MIME
On Wed, 6 Dec 2006, Trond Myklebust wrote:
>
> Hmm... Have the workqueue updates been pushed out yet? I can't seem to
> pull them from git.kernel.org.
The kernel.org mirroring has been really flaky lately.
If you have an account, you can use master.kernel.org to get things
without mirroring
Matthew Wilcox <[EMAIL PROTECTED]> writes:
> On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
>> Or are you saying that gcc aligns normal 32-bit entities at
>> 16-bit alignment? Neither of those sound very likely.
>
> alignof(u32) is 2 on m68k. Crazy, huh?
The original 68000 had
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > m68060 produces a trap for unaligned atomic access, unfortunately standard
> > alignment is smaller than this.
>
> Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you
> saying that you can't do a 32-bit atomic access at
On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
> > - Host, to which that console connects (through the debug device);
> > runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user
> space only on top of libusb.
I suppose it
> > First, for reference, I refer to hotplugging using the trivial ASH scripts
> > from [1], updated by removing no-longer-needed special cases for
> > platform_bus
> > (that original logic didn't work sometimes) and pcmcia. ...
>
> Ah, so for the platform devices, doing a
> modprobe
This reorders the RTC driver menu into separate sections, splitting out
the SOC, I2C, and SPI support to help make the menu easier to navigate.
(We got some feedback a while ago that it was "a mess" and hard to make
sense of...)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Assumes the
On Wed, Dec 06, 2006 at 05:36:29PM -0800, Linus Torvalds wrote:
> Or are you saying that gcc aligns normal 32-bit entities at
> 16-bit alignment? Neither of those sound very likely.
alignof(u32) is 2 on m68k. Crazy, huh?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, 2006-12-06 at 20:34 -0500, Trond Myklebust wrote:
> On Wed, 2006-12-06 at 17:16 -0800, Linus Torvalds wrote:
> >
> > On Wed, 6 Dec 2006, Trond Myklebust wrote:
> > >
> > >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> > >
> > > This will update the following files through
Remi Colinet wrote:
Frank Sorenson <[EMAIL PROTECTED]> wrote:
The latest -git tree panics at boot for me. git-bisect traced the
offending commit to:
368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Author: Alan Cox <[EMAIL
Jeremy Fitzhardinge wrote:
> I'm wondering if activate_mm() is the right thing to be using in
> use_mm(); shouldn't this be switch_mm()?
>
> On normal x86, they're synonymous, but for the Xen patches I'm adding a
> hook which assumes that activate_mm is only used the first time a new mm
> is used
On Tuesday December 5, [EMAIL PROTECTED] wrote:
>
> strace on exportfs shows this:nfsservctl(0x3, 0xbf875824, 0) =
> - -1 ENOMEM
What version of nfs-utils are you running? We haven't been using
nfsservctl(3, ...) on 2.6 kernels for ages - which probably explains
why exp_export() has
On Thu, 7 Dec 2006, Roman Zippel wrote:
>
> m68060 produces a trap for unaligned atomic access, unfortunately standard
> alignment is smaller than this.
Umm. on 68060, since it's 32-bit, you'd only have the 32-bit case. Are you
saying that you can't do a 32-bit atomic access at any 32-bit
On Wed, 2006-12-06 at 17:16 -0800, Linus Torvalds wrote:
>
> On Wed, 6 Dec 2006, Trond Myklebust wrote:
> >
> >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> >
> > This will update the following files through the appended changesets.
>
> Well, right now it conflicts with the
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > Any _real_ CPU will simply never care about _anything_ else than just the
> > > size of the datum in question.
> >
> > ..or alignment which a dedicated atomic type would allow to be attached.
>
> Can you give any example of a real CPU where
I'm wondering if activate_mm() is the right thing to be using in
use_mm(); shouldn't this be switch_mm()?
On normal x86, they're synonymous, but for the Xen patches I'm adding a
hook which assumes that activate_mm is only used the first time a new mm
is used after creation (I have another hook
Eric Fox wrote:
> Patch works if I disable SMP in kernel.
Aha, and it didn't work without the patch with SMP disabled?
> strace setserial -g /dev/ttyM0
> execve("/bin/setserial", ["setserial", "-g", "/dev/ttyM0"], [/* 17 vars
> */]) = 0
> uname({sys="Linux", node="dialin-0.vab.com", ...}) = 0
>
On Wed, 6 Dec 2006, Linus Torvalds wrote:
>
> How about something like this?
I didn't get any answers on this. I'd like to get this issue resolved, but
since I don't even use libphy on my main machine, I need somebody else to
test it for me.
Just to remind you all, here's the patch again.
On Thu, 7 Dec 2006, Roman Zippel wrote:
> >
> > Any _real_ CPU will simply never care about _anything_ else than just the
> > size of the datum in question.
>
> ..or alignment which a dedicated atomic type would allow to be attached.
Can you give any example of a real CPU where alignment
On Wed, 6 Dec 2006, Trond Myklebust wrote:
>
>git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
>
> This will update the following files through the appended changesets.
Well, right now it conflicts with the workqueue cleanups. Can you fix up
the conflicts and push again? Quite
On Wed, Nov 22, 2006 at 11:09:01AM -0700, Grant Grundler wrote:
> On Wed, Nov 22, 2006 at 05:06:07PM +0900, Hidetoshi Seto wrote:
> > --- linux-2.6.19-rc6.orig/drivers/pci/pci.c
> > +++ linux-2.6.19-rc6/drivers/pci/pci.c
> > @@ -558,12 +558,18 @@
> > {
> > int err;
> >
> > + if
On Wed, Dec 06, 2006 at 04:03:42PM -0800, Randy Dunlap wrote:
> On Thu, 30 Nov 2006 12:20:42 + Steven Whitehouse wrote:
>
> > >From b98c95af01c10827e3443157651eb469071391a3 Mon Sep 17 00:00:00 2001
> > From: Patrick Caulfield <[EMAIL PROTECTED]>
> > Date: Wed, 15 Nov 2006 12:29:24 -0500
> >
Matthias Schniedermeyer wrote:
Hi
I'm using a Bunch auf HDDs in USB-Enclosures for storing files.
(currently 38 HDD, with a total capacity of 9,5 TB of which 8,5 TB is used)
All the same enclosure type?
This time i kept the defective files and used "vbindiff" to show me the
difference.
From: Al Viro <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 19:08:28 +
> On Wed, Dec 06, 2006 at 11:05:22AM -0800, Linus Torvalds wrote:
> >
> >
> > On Wed, 6 Dec 2006, Christoph Lameter wrote:
> > >
> > > I'd really appreciate a cmpxchg that is generically available for
> > > all arches. It
Hi,
On Wed, 6 Dec 2006, Linus Torvalds wrote:
> > > To be honest, it'd be much easier if we only defined these operations on
> > > atomic_t's. We have all the infrastructure in place for them, and
> > > they're fairly well understood. If you need different sizes, I'm OK
> > > with an
Hi
> On Thu, 2006-12-07 at 10:58 +1030, Jonathan Woithe wrote:
> > Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
> > error:
>
> This was fix in -rt5 or 6 I think . The !PREEMPT_RT case. Current
> version is -rt7
Ah right, good. I did grab rt6 yesterday but forgot to
On Thu, 7 Dec 2006, Roman Zippel wrote:
> On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>
> > To be honest, it'd be much easier if we only defined these operations on
> > atomic_t's. We have all the infrastructure in place for them, and
> > they're fairly well understood. If you need different
On Wed, Dec 06, 2006 at 11:16:55AM -0800, Christoph Lameter wrote:
> But then its also just requires disable/enable interrupts on UP which may
> be cheaper than an atomic operation.
>
> > For CPUs with load locked + store conditional, it is expensive.
>
> Because it locks the bus? I am not
From: "Matt Reimer" <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 13:19:41 -0800
> On 12/5/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Matt Reimer" <[EMAIL PROTECTED]>
> > Date: Tue, 5 Dec 2006 16:57:12 -0800
> >
> > > Right, but isn't he declaring that each architecture needs to take
> >
Arjan van de Ven wrote:
>> It'd be nice if we could just teach the userspace balancer to not try to
>> move perpcu IRQs?
>>
>> otoh, the patch is super-cheap. Arjan?
>
> I can fix irqbalance no problem, however I like the kernel approach as
> well, since it's not just irqbalance that moves
On Thu, 2006-12-07 at 10:58 +1030, Jonathan Woithe wrote:
> Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
> error:
>
This was fix in -rt5 or 6 I think . The !PREEMPT_RT case. Current
version is -rt7
http://people.redhat.com/~mingo/realtime-preempt/patch-2.6.19-rt7
Ben Collins wrote:
...
I would like to see new development efforts take cleanliness WRT host
byte order and 64bit architectures into account from the ground up. (I
understand though why Kristian made the announcement in this early
phase, and I agree with him that this kind of development has to
Andrew Morton wrote:
I'd have thought that an option `retain_initrd' would make more sense.
Please always update Documentation/kernel-parameters.txt when adding boot
options.
I would have to agree with this; it also seems a bit odd to me to have
this at all (kexec provides a new kernel
Hi,
On Wed, 6 Dec 2006, Matthew Wilcox wrote:
> To be honest, it'd be much easier if we only defined these operations on
> atomic_t's. We have all the infrastructure in place for them, and
> they're fairly well understood. If you need different sizes, I'm OK
> with an atomic_pointer_t, or
Upon an attempt to compile 2.6.19-rt3 I encountered the following compile
error:
> make -j 2
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CC arch/i386/kernel/asm-offsets.s
In file included from include/linux/time.h:7,
from
On Thu, 07 Dec 2006 11:18:43 +1100
Michael Neuling <[EMAIL PROTECTED]> wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
> ---
> Useful for kexec when you want to
I'm seeing a workqueue-related deadlock. This is on an ia64
box running SLES10, but it looks like the same problem should
be possible in current upstream on any architecture.
Here are the two tasks involved:
events/4:
schedule
__down
__lock_cpu_hotplug
lock_cpu_hotplug
On Thu, 07 Dec 2006 11:18:43 +1100 Michael Neuling wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
Please add doc. for this in Documentation/kernel-parameters.txt.
> Signed-off-by: Michael Neuling <[EMAIL
On Dec 06, David Brownell <[EMAIL PROTECTED]> wrote:
> > Please explain in more details how hotplugging would be broken, possibly
> > with examples.
> First, for reference, I refer to hotplugging using the trivial ASH scripts
> from [1], updated by removing no-longer-needed special cases for
Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
init/initramfs.c | 18
On Thursday 07 December 2006 01:07, Ben Nizette wrote:
> Jesper Juhl wrote:
[...]
> > @@ -22,15 +22,17 @@ ON WHAT HARDWARE DOES IT RUN?
> >
> >Although originally developed first for 32-bit x86-based PCs (386 or
> > higher),
> >today Linux also runs on (at least) the Compaq Alpha AXP,
Jesper Juhl wrote:
Hi,
here's a small patch which
- adds a few archs to the current list of supported platforms.
- adds a few missing slashes at the end of URLs.
- adds a few references to additional documentation.
- adds "make config" to the list of possible configuration targets.
-
Selon Stephen Torri <[EMAIL PROTECTED]>:
> I am trying to create a custom ELF and Windows PE loader for the purpose
> of security research. I am having a difficult time finding how to
> allocate memory for a binary at the desired address in memory
> (especially if its non-relocatable).
Use mmap
On Thu, 30 Nov 2006 12:20:42 + Steven Whitehouse wrote:
> >From b98c95af01c10827e3443157651eb469071391a3 Mon Sep 17 00:00:00 2001
> From: Patrick Caulfield <[EMAIL PROTECTED]>
> Date: Wed, 15 Nov 2006 12:29:24 -0500
> Subject: [PATCH] [DLM] Fix DLM config
>
> The attached patch fixes the DLM
I am trying to create a custom ELF and Windows PE loader for the purpose
of security research. I am having a difficult time finding how to
allocate memory for a binary at the desired address in memory
(especially if its non-relocatable). I would like to see why I cannot
get memory allocated at the
On Wednesday 06 December 2006 17:30, Ingo Molnar wrote:
> Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> during kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about
> 10%-20% of the time in acpi_init():
>
>
Kristian Høgsberg wrote:
> Stefan Richter wrote:
>> You have to look at the matter not only from the POV of API design but
>> also of deployment and support.
>
> My POV here *is* about deployment and support, but from the kernel side
> of things. If you commit yourself to long time support for
Frank Sorenson <[EMAIL PROTECTED]> wrote:
> The latest -git tree panics at boot for me. git-bisect traced the
offending commit to:
>
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
> Author: Alan Cox <[EMAIL PROTECTED]>
> Date:
Hi,
here's a small patch which
- adds a few archs to the current list of supported platforms.
- adds a few missing slashes at the end of URLs.
- adds a few references to additional documentation.
- adds "make config" to the list of possible configuration targets.
- makes a few other minor
On Tue, 5 Dec 2006 21:34:16 + (GMT)
James Simmons <[EMAIL PROTECTED]> wrote:
> Here you go. This patch places the backlight before the framebuffers. You
> will now be able to select using the backlight with various framebuffer
> drivers.
This doesn't work right for me. x86_64 allmodconfig
> Will try your patch tomorrow.
...which does not change anything. (As expected.)
Olaf
-
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
This patch implements block device specific .direct_IO method instead
of going through generic direct_io_worker for block device.
direct_io_worker is fairly complex because it needs to handle O_DIRECT
on file system, where it needs to perform block allocation, hole detection,
extents file on
On Wed, 06 Dec 2006 13:50:35 -0600
Frank Sorenson <[EMAIL PROTECTED]> wrote:
> The latest -git tree panics at boot for me. git-bisect traced the offending
> commit to:
>
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit
> commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
> Author:
Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
From: Ingo Molnar <[EMAIL PROTECTED]>
during kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about
10%-20% of the time in acpi_init():
Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
Calling initcall
Here's a patch that cleans up the "make help" output a bit for the
documentation targets.
Currently the documentation targets are listed completely different than
all the other targets :
Documentation targets:
Linux kernel internal documentation in different formats:
xmldocs (XML
Public key support code. This reads and writes packets in the header
that contain public key encrypted file keys. It calls the messaging
code in the previous patch to send and receive encryption and
decryption request packets from the userspace daemon.
Signed-off-by: Michael Halcrow <[EMAIL
On Wed, Dec 06, 2006 at 05:51:32PM +0100, [EMAIL PROTECTED] wrote:
> OS distro used:
> CentOS 4.4 x86_64
> Kernel 2.6.19 with hand-crafted config, that we are
> able to use successfully with kernel 2.6.16.20.
What patches were you applying to 2.6.16.20, since that didn't
have an Areca driver in
This is a re-submission of the same public key patches (updated for
2.6.19-rc6-mm2) that were submitted for review a while back.
This is the transport code for public key functionality in
eCryptfs. It manages encryption/decryption request queues with a
transport mechanism. Currently, netlink is
This patch converts sata_promise to use new-style libata error
handling on Promise SATA chips, for both SATA and PATA ports.
* ATA_FLAG_SRST is no longer set
* ->phy_reset is no longer set as it is unused when ->error_handler
is present, and pdc_sata_phy_reset() has been removed
* pdc_freeze()
Hi,
I am running 2.6.18 kernel on 64 bit AMD machine. (procinfo attached
at the end of the mail). One of the things I have noticed that
dentry_cache grows really fast under certain code path.
So, far I have not seen any problems, but I would like to get some
more input on this subject. Is it okay
there are a plethora of headers that cannot be included straight due
to the usage of __ types (like __u32) without first including
linux/types.h ... so the question is, should all of these headers be
fixed to properly pull in linux/types.h first or are users expected to
"just know" the correct
Hi,
* Jean Delvare <[EMAIL PROTECTED]> [061204 09:49]:
> Hi Tony, all,
>
> On Thu, 10 Aug 2006 16:19:26 +0300, Tony Lindgren wrote:
> > * Jean Delvare <[EMAIL PROTECTED]> [060810 11:30]:
> > > I've now taken Komal's patch (#4). Here is a proposed patch which brings
> > > the prescaler
1 - 100 of 784 matches
Mail list logo
