Hello,
On Thu, 08 Mar 2007 18:15:12 +0100, Patrick McHardy wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+ /* Equivalent to:
+* -A chaos -m statistic --mode random --probability \
+* $reject_percentage -j REJECT --reject-with host-unreach;
+* -A
On Wednesday, 7 March 2007 22:07, Pavel Machek wrote:
> Hi!
>
> > Prevent the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> > from triggering by disabling nonboot CPUs before we finally enter the
> > platform
> > suspend.
> >
> > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTE
On Fri, Mar 09, 2007 at 09:50:56AM +0300, Andrey Panin wrote:
> On 068, 03 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> > __builtin_types_compatible_p() has been around since gcc 2.95,
>
> but it's not available in Intel C compiler IIRC :(
So what?
-
To unsubscribe from this list: send t
On Fri, Mar 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
> diff -r f0ff8138f993 include/linux/kernel.h
> --
On Fri, Mar 09, 2007 at 02:05:24PM +1100, Rusty Russell wrote:
> diff -r fdc8cbc1fd61 drivers/block/lguest_blk.c
> --- a/drivers/block/lguest_blk.c Thu Mar 08 13:35:39 2007 +1100
> +++ b/drivers/block/lguest_blk.c Thu Mar 08 15:51:55 2007 +1100
> @@ -45,6 +45,16 @@ struct blockdev
>
Hi!
> Prevent the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> from triggering by disabling nonboot CPUs before we finally enter the platform
> suspend.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> kernel/power/disk.c |1 +
> kernel/power/user.c |
I understand the NOMMU situation, and you are already screwed by
PTRACE_ATTACH. What I meant to suggest is that I would start from a
safety point of view with get_user_pages/access_process_vm refusing to
do force&&write to MAP_PRIVATE pages that are in fact being shared
(ETXTBSY or something). (W
Hi!
> Port (and memory) addresses can be dynamically generated by the AML code
> and thus, there is no way that the ACPI subsystem can statically predict
> any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
It would be nice if next version of acpi specs support
Description: Check the return value of kmalloc() in function
se401_start_stream(), in file drivers/media/video/se401.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/se401.c b/drivers/media/video/se401.c
index 7aeec57..006c818 100644
--- a/drivers/media/video
From: Amit Choudhary <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 23:26:54 -0800
> Description: Check the return value of kmalloc() in function dbg_kmalloc(),
> in file net/wanrouter/wanmain.c.
>
> Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
There is no reason for any subsystem to implement
On Thu, 8 Mar 2007 22:21:37 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Fix avr32 TIF atomicity in do_debug_priv
>
> avr32 updates the thread flags 1 - non atomically and 2 - with the wrong value
> (for TIF_SINGLE_STEP) in this function.
>
> It applies to 2.6.20.
Thanks, but this has a
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 +2640,
Description: Fix error-path leak in function jffs2_scan_medium(), in file
fs/jffs2/scan.c
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index e241346..cd9ed6e 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -130,6 +130,8 @@ #endif
Description: Check the return value of kmalloc() in function agp_sgi_init(), in
file drivers/char/agp/sgi-agp.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/char/agp/sgi-agp.c b/drivers/char/agp/sgi-agp.c
index d73be4c..5897e6c 100644
--- a/drivers/char/agp/sgi-agp.c
+
From: Amit Choudhary <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 23:22:15 -0800
> Description: Check the return value of kmalloc() in function
> wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c.
>
> Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
This kind of patch has been submitted
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
+++ b/net/wanr
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 23:16:58 -0800
> It seems expensive to change all the skb's if this type of
> event occurs,
The reset functions have to walk all the SKBs anyways.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Description: Change in error message in function fore200e_kmalloc(), in file
drivers/atm/fore200e.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 3a7b21f..1c7ea02 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200
Description: Check the return value of kmalloc() in function
mgsl_alloc_intermediate_txbuffer_memory(), in file drivers/char/synclink.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
index 06784ad..24f99bc 100644
--- a/drivers/ch
Description: Check the return value of kmalloc() in function i810_open(), in
file sound/oss/i810_audio.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/sound/oss/i810_audio.c b/sound/oss/i810_audio.c
index 240cc79..a415967 100644
--- a/sound/oss/i810_audio.c
+++ b/sound/oss/i810
On 07-03-2007 23:42, David Miller wrote:
> I didn't say to use skb->priority, I said to shrink skb->priority down
> to a u16 and then make another u16 which will store your queue mapping
> value.
Peter is right: this is fully used by schedulers (prio,
CBQ, HTB, HFSC...) and would break users' scri
Description: Check the return value of kmalloc() in function
wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/net/ipv4/multipath_wrandom.c b/net/ipv4/multipath_wrandom.c
index 92b0482..bcdb1f1 100644
--- a/net/ipv4/multipa
Description: Check the return value of kmalloc() in function
stv680_start_stream(), in file drivers/media/video/stv680.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/stv680.c b/drivers/media/video/stv680.c
index 6d1ef1e..f35c664 100644
--- a/drivers/media/v
Description: Check the return value of kmalloc() in function setup_cpu_cache(),
in file mm/slab.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/mm/slab.c b/mm/slab.c
index 84c631f..613ae61 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2021,6 +2021,7 @@ static int setup_cpu_cache(s
Description: Check the return value of kmalloc() in function cifs_readdir(), in
file fs/cifs/readdir.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index b5b0a2a..2d43b2a 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -1063,6 +1
Description: Check the return value of kmalloc() in function mos7840_get_reg(),
in file drivers/usb/serial/mos7840.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 021be39..91d474b 100644
--- a/drivers/usb/serial/
Description: Check the return value of kmalloc() in function
stv680_start_stream(), in file drivers/media/video/stv680.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/stv680.c b/drivers/media/video/stv680.c
index 6d1ef1e..a1ec3ac 100644
--- a/drivers/media/v
Description: Check the return value of kmalloc() in function ch_readconfig(),
in file drivers/scsi/ch.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index f6caa43..fcd635b 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -324,7 +3
> This is not a problem.
>
> Since the ->enqueue function stores references to the SKBs,
> any change of the dev->qdisc has to flush those references
> somehow, and it is at that point that you can fixup the skb
> queue mappings.
>
> This happens via invoking the qdisc->ops->reset() method.
>
Description: Check the return value of kmalloc() in function
videocodec_build_table(), in file drivers/media/video/videocodec.c.
Signed-off-by: Amit Choudhary <[EMAIL PROTECTED]>
diff --git a/drivers/media/video/videocodec.c b/drivers/media/video/videocodec.c
index 2ae3fb2..16fc1dd 100644
--- a/
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 22:42:19 -0800
> This was taken into consideration, and I did reply that my concern for
> doing that could cause stale data in the skb if the queue mapping
> changed.
This is not a problem.
Since the ->enqueue function stor
On Friday, 9 March 2007 02:11, Len Brown wrote:
> On Wednesday 07 March 2007 18:13, Rafael J. Wysocki wrote:
> > On Wednesday, 7 March 2007 23:49, Andrew Morton wrote:
> > > On Wed, 7 Mar 2007 23:14:29 +0100
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Wednesday, 7 March 2
hello,
The manpage of "swapon" function since Linux 2.6.17 has some error.
The MAX_SWAPFILES should be 30 in the latest version. Swap migration uses
the two higest numbers of swap types (30 and 31).
Regards
Zhang Xiliang
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> On Thu, 8 Mar 2007, Bill Davidsen wrote:
> > Please, could you now rethink plugable scheduler as well? Even if one had to
> > be chosen at boot time and couldn't be change thereafter, it would still
> > allow
> > a few new thoughts
> That sounds like a rather fragile approach to avoiding a minimal amount of
> work. Debug exceptions don't occur very often, and when they do it won't
> matter too much if we go through some extra notifier-chain callouts.
When single-stepping occurs it happens repeatedly many times, and that
d
On 068, 03 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95,
but it's not available in Intel C compiler IIRC :(
> and we don't use it anywhere. This patch quietly fixes that.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
David Miller wrote:
You didn't address my correction the other day wherein I clarified
for you that my idea was not to store the queue mapping in
skb->priority but rather to shrink skb->priority to a u16 and
add a new u16 skb->queue_mapping or whatever field to store the
necessary information.
Y
Hi!
> Pavel, I tried with your .config, and indeed the system came back to life
> after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test that
On Wednesday 07 March 2007 3:48 pm, Chris Lesiak wrote:
> From: Chris Lesiak <[EMAIL PROTECTED]>
>
> This patch fixes a bug in the cleanup of an spi_bitbang bus.
It's nearly right, but see below.
> @@ -505,28 +499,10 @@ EXPORT_SYMBOL_GPL(spi_bitbang_start);
> */
> int spi_bitbang_stop(struc
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 10:22 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Leech, Christopher
> Subject: Re: [PATCH 0/2] NET: Multiple queue network device
> supp
On Fri, 9 Mar 2007, Rusty Russell wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
Whee.
Rusty, that's a work of art.
However, I would suggest that you never show it to anybody ever again. I'm
sure that i
On Thu, Mar 08, 2007 at 09:37:46PM -0500, Bill Davidsen wrote:
> Andy Isaacson wrote:
> >% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
> >% for i in 2 3 4; do dd if=/dev/zero of=d$i bs=1k count=$(($i+150)); done
[snip]
> >-for (j=i; i >+for (j=i; j >
On Thu, 8 Mar 2007, Bill Davidsen wrote:
>
> Please, could you now rethink plugable scheduler as well? Even if one had to
> be chosen at boot time and couldn't be change thereafter, it would still allow
> a few new thoughts to be included.
No. Really.
I absolutely *detest* pluggable schedulers.
On Friday 09 March 2007 16:39, Matt Mackall wrote:
> First off, let me say that I think your approach has great promise,
> but I'm afraid it doesn't work so well here yet.
>
> Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
> test load.
>
> With 2.6.21-rc2-mm2, I get slightly s
On Fri, 09 Mar 2007 16:56:32 +1100 Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
After staring at this for about 2 minutes, how about a commit message like:
Make ARRAY_SIZ
You didn't address my correction the other day wherein I clarified
for you that my idea was not to store the queue mapping in
skb->priority but rather to shrink skb->priority to a u16 and
add a new u16 skb->queue_mapping or whatever field to store the
necessary information.
You're just posting a
Mockern a écrit :
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
Welcome Andy
Since your messages always make me wonder if you are some kind of robot, able
to post one "one line" message to lkml everyday, I have one suggestion :
Try next times to
Hi,
What is the simpliest implementation of block_til_ready for tty driver?
Thanks,
Andy
-
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
__builtin_types_compatible_p() has been around since gcc 2.95, and we
don't use it anywhere. This patch quietly fixes that.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r f0ff8138f993 include/linux/kernel.h
--- a/include/linux/kernel.hFri Mar 09 16:40:25 2007 +1100
+++ b/include/li
Michael K. Edwards a écrit :
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool
might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unles
First off, let me say that I think your approach has great promise,
but I'm afraid it doesn't work so well here yet.
Box is an R51 Thinkpad, 1.7GHz Pentium M. I'm using a make -j 5 as a
test load.
With 2.6.21-rc2-mm2, I get slightly sluggish response for opening new
terminals, scrolling in Galeon
On Wed, Feb 21, 2007 at 02:36:40PM +0100, Stefan Richter wrote:
> Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.19.5 release.
> >
> > This will probably be the last release of the 2.6.19-stable series, so
> > if there are patches that you feel should be applied to tha
From: Mathieu Desnoyers <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 22:12:27 -0500
> Fix sparc TIF_USEDFPU flag atomicity
>
> Non atomic update of TIF can be very dangerous, except at thread structure
> creation time. Here I standardize the TIF_USEDFPU usage of the sparc arch.
>
> Applies on 2.6.2
From: Mathieu Desnoyers <[EMAIL PROTECTED]>
Date: Thu, 8 Mar 2007 21:38:14 -0500
> Fix atomicity of TIF update in flush_thread() for x86_64
^^
You mean sparc64 of course, I fixed this up while committing your
patch, thanks a lot.
-
To unsubsc
On Fri, Mar 09, 2007 at 12:02:31AM +0100, Thomas Gleixner wrote:
> On Thu, 2007-03-08 at 18:29 +0100, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Ingo,
> > >
> > > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > > it tests whether the SA_
On Thursday 08 March 2007 13:54, Andrew Morton wrote:
> On Wed, 7 Mar 2007 17:43:45 -0800 Andrew Morton <[EMAIL PROTECTED]>
wrote:
> > On Wed, 7 Mar 2007 12:26:42 +1100
> >
> > Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > What follows is the same patch series that constitutes the RDSL
> > > "Rotat
On Thu, Mar 08, 2007 at 06:29:02PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
> > it tests whether the SA_RESTART flag works for the sem_wait operation.
> >
> > I see sem_wai
Daniel Drake wrote:
> Andrew Johnson wrote:
> > When the console is in VT_AUTO/KD_GRAPHICS mode, switching to the
> > SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting
indefinately
> > or until the task is interrupted. The following patch tests if a
> > console switch can occur in set_co
albcamus wrote:
your kthread IS preemptible unless you call preempt_disable or some
locking functions explicitly .
I think he's trying to go the other way, make his thread the highest
priority to blow anything else in the system out of the water. See his
previous post "how to make kernel threa
Matt wrote:
> It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:31:05 -0800
> The advantage would be that it wouldn't require a v3 for platforms for
> which MIN_PAGE_SIZE == PAGE_SIZE, which accounts for a very large
> percentage of systems.
>
> You still have to look for the darn magic in
Hello Andrew,
I found a little "hickup" in the mm kernel series since 2.6.21-rc2-mm1/mm2.
1.) appeared while boot (no VFS mounted at time)
BUG: at arch/i386/mm/highmem.c:61 kmap_atomic()
[] [] [] [] []
[] [] [] [] []
[] [] [] [] []
[] [] [] []
===
BUG: at arch/
David Miller wrote:
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
Anton Blanchard wrote:
The other option is to create a v3 swap format that doesnt use any
PAGE_SIZE parameters.
The best thing to do would be to look for the magic both at PAGE_SIZE
(for compa
> The real trick is that I believe these groupings are designed to be something
> you can setup on login and then not be able to switch out of. Which means
> we can't use sessions and process groups as the grouping entities as those
> have different semantics.
Not always on login. For big admin
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2007 20:18:28 -0800
> Anton Blanchard wrote:
> > The other option is to create a v3 swap format that doesnt use any
> > PAGE_SIZE parameters.
>
> The best thing to do would be to look for the magic both at PAGE_SIZE
> (for compatibilit
In attempting to fix some issues with my system, I was pulling patches from
the kernel git tree, and I discovered that this patch (
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fe69933652562f093ccde600cecf234930c01932
)
is malformed on i386, specifically the lin
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local * to global objects. This
> accurately describes things liek resource controllers, cpusets, resource
> monitoring, etc.
No!
Cpusets don't rename or change the mapping of objects.
I suspect
Anton Blanchard wrote:
Hi,
I might be missing something but doesn't this break every
SWAP partition that was created with something other than
MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the p
Con Kolivas wrote:
On Wednesday 07 March 2007 04:50, Bill Davidsen wrote:
With luck I'll get to shake out that patch in combination with kvm later
today.
Great thanks!. I've appreciated all the feedback so far.
I did try, the 2.6.21-rc3-git3 doesn't want to kvm for me, and your
patch may n
On 3/8/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
Hi Brian,
Thanks for the quick update.
> +
> + rc = (iface->result >= 0) ? 0 : -1;
> +
> + /* Release mutex */
> + mutex_unlock(&iface->twi_lock);
> +
> + return rc;
> +}
i2c-core can emulate SMBus transactions using master
Linus Torvalds wrote:
On Mon, 5 Mar 2007, Ed Tomlinson wrote:
The patch _does_ make a difference. For instance reading mail with freenet working
hard (threaded java application) and gentoo's emerge triggering compiles to update the
box is much smoother.
Think this scheduler needs serious l
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luong Ngo
Sent: Friday, March 09, 2007 8:54 AM
To: Robert Hancock
Cc: linux-kernel; [EMAIL PROTECTED]
Subject: Re: Sleeping thread not receive signal until it wakes up
On 3/8/07, Robert Hancock <[EMAIL PROTEC
Robert P. J. Day wrote:
> i asked about this a while back, but i still haven't heard a
> definitive response as to whether it's acceptable.
Maybe you get response if you post a complete patch.
--
Stefan Richter
-=-=-=== --== -=--=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send
Hi , all .
Add an RTC driver for Ricoh RS5C313 RTC chip.
Please apply.
regards,
Nobuhiro
Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 95826b9..cc3c0b2 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -354,4 +35
Hi,
> Most system calls seem to get added to i386 first. This patch
> automatically generates a warning for any new system call which is
> implemented on i386 but not the architecture currently being compiled.
> On PowerPC at the moment, for example, it results in these warnings:
Love it!
...
"handle" NMI by ignoring it. Can't have been important, right? As the
lguest64 hackers explained, handling NMI is a PITA. Now oprofile does
not crash machine.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 5beeb29ed3a3 arch/i386/lguest/hypervisor.S
--- a/arch/i386/lguest/hypervisor.S
Rather than copy in IDT, GDT and TSS every time, we only need do it
when something has changed (ie. guest IDT/GDT/TSS has changed, or
guest has changed CPU, or CPU has just run another guest).
For the registers, we simply allocate them an entire page and map that
over the stack page in the guest.
On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said:
> This is a request for comments for a new Integrity Based Access
> Control(IBAC) LSM module which bases access control decisions
> on the new integrity framework services.
>
> (Hopefully this will help clarify the interaction between an LSM
> m
On 3/8/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
Luong Ngo wrote:
> Hi Thomas and Dick,
> I appreciate all the responses. They are very good information to me.
> Actually, it wasn't me working on the driver but it's been there long
> time. I thought I just need to add the signal and signal ha
The current lguest uses segment limits to ensure that the guest cannot
reach the switcher code at the top of virtual memory. This is bad for
two reasons:
1) It introduces complexity when the guest wants to use 4G segments
(ie. glibc's __thread support).
2) It doesn't work on x86-64 boxes.
The al
> > Try running your guest with -no-kvm (and even with the kvm module not
> > loaded, just to be sure). In my case I still saw the messages.
> > However, removing the "-net tap" line from my command line did get rid
> > of the messages.
>
> Hmmm I'm getting the same thing on 2.6.20.1 as wel
> Holding a lock too long should be easy to debug with the -rt patch -
> set the preemption related options to match mainline, and enable the
> latency tracer.
Good idea, I'll give it a shot when I get a chance.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
We make sure that the stack is always mapped in pin_stack_pages by
simply calling demand_page, but that calls get_user_pages() to find
the pfn, which is way overkill since the page is almost certainly
already mapped. So don't call pin_stack_pages every context switch
(unless genuinely a completely
Fix avr32 TIF atomicity in do_debug_priv
avr32 updates the thread flags 1 - non atomically and 2 - with the wrong value
(for TIF_SINGLE_STEP) in this function.
It applies to 2.6.20.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/arch/avr32/kernel/ptrace.c
+++ b/arch/avr32/kernel/ptr
1: It helps if you connect the bridge to a link.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
2: You can theoretically run lguest with no boot parameters.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 90134cf1fe0a Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c
We previously put "cr3" in the guest regs restored and saved: the
guest cannot change cr3, so saving it it silly. Hand it across to the
host<->guest switcher in ebx.
While we're there, only save the host registers we need to; tell GCC
we clobber everything we can.
Finally, and trap 2 (NMI) doesn
We don't need physically-contiguous pages for the hypervisor, since we
use map_vm_area anyway.
Two other related cleanups: pass the number of pages to
init_pagetables() so we can remove the constant from the header, and
call populate_hypervisor_pte_page() on each page as we allocate it,
rather tha
Fix sparc TIF_USEDFPU flag atomicity
Non atomic update of TIF can be very dangerous, except at thread structure
creation time. Here I standardize the TIF_USEDFPU usage of the sparc arch.
Applies on 2.6.20.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/arch/sparc/kernel/process.c
++
On Thu, 2007-03-08 at 16:55 -0800, [EMAIL PROTECTED] wrote:
> Hi,
>
> Is there a faster way to access "/proc/*" other than open it as a file and
> reading/parsing contents? e.g. fopen("/proc/stat", "r");
>
> In BSD, there is the kvm method of access, which is relatively fast (light
> weight)
>
Expand the --tunnet option to take a bridge name as an argument, so that
the tap interface is added to the specified bridge. This makes it
convenient to use bridging for connecting the guest to external networks.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[E
Jens Axboe pointed out that end_request() does not end the entire
request. Go figure. On the upside, he wrote the replacement for me!
Now we do far less block traffic, and our performance sucks less.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r fdc8cbc1fd61 drivers/block/lguest_blk.
Hi,
> Well, PowerPC "dcbt" does prefetch() correctly, it doesn't ever raise
> exceptions, doesn't have any side effects, takes only enough CPU to
> decode the address, and is ignored if it would have to do anything
> other than load the cacheline from RAM. Prefetch streams are halted
> w
> OK, 200 cycles...
>
> But what is the cost of the conditional branch you added in prefetch(x) ?
Much less than the tablewalk. On ppc64 a tablewalk of an address that is
not populated in the hashtable will incur 2 cacheline lookups (primary
and secondary buckets). This plus the MMU state machin
Fix atomicity of TIF update in flush_thread() for powerpc
Race :
parent process executing :
sys_ptrace()
(lock_kernel())
(ptrace_get_task_struct(pid))
arch_ptrace()
ptrace_detach()
ptrace_disable(child);
clear_singlestep(child);
clear_tsk_thread_flag(child, TIF_SINGLEST
> Yeah, I'm not at all surprised. Any implementation of "prefetch" that
> doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
> them weaker for *actual* prefetching) will generally have a hard time with
> a NULL pointer. Exactly because it will try to do a totally unneces
Hi,
> I might be missing something but doesn't this break every
> SWAP partition that was created with something other than
> MIN_PAGE_SIZE?
It does. I was thinking we could work around it in ppc64 (64kB is quite
new), but I forgot there are options on sparc64 to change the page size :)
The oth
Fix atomicity of TIF update in flush_thread() for x86_64
Race :
parent process executing :
sys_ptrace()
(lock_kernel())
(ptrace_get_task_struct(pid))
arch_ptrace()
ptrace_detach()
ptrace_disable(child);
clear_singlestep(child);
clear_tsk_thread_flag(child, TIF_SINGLESTE
Herbert wrote:
> why is the filesystem approach so favored for this
> kind of manipulations?
I don't have any clear sense of whether the additional uses of file
systems being considered here are a good idea or not, but the use of a
file system for cpusets has turned out quite well, in my (vain and
Andy Isaacson wrote:
When iterating through an array, one must be careful to test one's index
variable rather than another similarly-named variable.
The loop will read off the end of conf->disks[] in the following
(pathological) case:
% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
% for
On Thu, 8 Mar 2007, Davide Libenzi wrote:
> +static ssize_t signalfd_read(struct file *file, char *buf, size_t count,
> + loff_t *ppos)
> +{
> + struct signalfd_ctx *ctx = file->private_data;
> + struct sighand_struct *sighand = ctx->sighand;
> + ssize_t res =
1 - 100 of 539 matches
Mail list logo