Use ARRAY_SIZE macro in pvrusb2-hdw.c file
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index d200496..f66f7c6 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/v
Use ARRAY_SIZE macro in pvrusb2-std.c file
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/media/video/pvrusb2/pvrusb2-std.c
b/drivers/media/video/pvrusb2/pvrusb2-std.c
index f95c598..677f126 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-std.c
+++ b/drivers/media/v
Use ARRAY_SIZE macro in miscellaneous pvrusb2 files found
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
This patch ofcourse don't include previous patches in the set. I've just
included the remaining modifications in one patch/mail cause every file
touched here has only one or two line
Hi all,
A cleanup series for the pvrusb2 code to use the ARRAY_SIZE macro. Since
The size of the patch is big, I've splitted it to 4 pieces according to
the files they touch.
PATCH 1/4: Use ARRAY_SIZE in pvrusb2-encoder.c
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drive
Hi!
I'm getting "md: bug in file drivers/md/md.c, line 1652" (see below) after
writing data to a md-device using dd.
Is it really a bug or am I just using mdadm in the wrong way? I'm unsure
about the --assume-clean flag when creating the raid5 volume.
My kernel is 2.6.18.
Below are some printou
Hi,
> I think you've convinced me that vmalloc is not a good choice when a
> driver needs a large buffer (many megabytes) for DMA.
Yep. bttv used to do that long time ago, and some people used to run
into trouble because the nvidia driver used lots of vmalloc address
space ...
> In this case,
On Tue, 2007-01-16 at 11:41 +1100, Jens Axboe wrote:
> > AFAICS this is intentional to avoid checks all over the place, but the
> > underflow check is missing. All we need to do is make sure, that in case
> > of ioc->plugged == 0 we return early and bug, if there is either a queue
> > plugged in or
Hi,
Ingo Molnar a écrit :
yeah. As an alternative, it might be a good idea to pthread-ify
hackbench.c - that should replicate the Volano workload pretty
accurately. I've attached hackbench.c. (it's process based right now, so
it wont trigger contended futex ops)
Ok, thanks. I've adapted your
On Mon, Jan 15, 2007 at 11:55:20AM +0100, Michael Noisternig wrote:
> I've posted this before but without getting any replies. Please,
> somebody either give a (short) reply to this or simply explain why they
> think this is OT or not worth answering...
I'm sorry if I missed your previou
Hi,
I unplugged my (second) webcam, forgotting to stop ekiga, and khubd is
now taking 100% CPU.
- lsusb doesn't return
- /etc/init.d/udev restart didn't resolve the problem.
Is that a problem one may want to investigate or should I just forget
about it (problem being cause by a user error)?
Is
Am Dienstag, 16. Januar 2007 10:10 schrieb Jerome Lacoste:
> Hi,
>
> I unplugged my (second) webcam, forgotting to stop ekiga, and khubd is
> now taking 100% CPU.
You might start with mentioning which kind of camera your second webcam is.
Oliver
-
To unsubscribe from this list: send the
Hi all,
Patch uses the ARRAY_SIZE macro defined in kernel.h instead of
reemplementing it.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
bt8xx/dvb-bt8xx.c |2 +-
frontends/cx24110.c |4 ++--
frontends/cx24123.c |6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
dif
Christoph wrote:
> Currently cpusets are not able to do proper writeback since
> dirty ratio calculations and writeback are all done for the system
> as a whole.
Thanks for tackling this - it is sorely needed.
I'm afraid my review will be mostly cosmetic; I'm not competent
to comment on the reall
This patch is inspired by Arjan's "Patch series to mark struct
file_operations and struct inode_operations const".
Compile tested with gcc & sparse.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/9p/vfs_super.c |4 ++--
fs/adfs/super.c |2 +-
fs/af
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
include/asm-x86_64/io.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-x86_64/io.h b/include/asm-x86_64/io.h
index 6ee9fad..7d0b568 100644
--- a/include/asm-x86_64/io.h
+++ b/include/asm-x86_64/io.h
@@
Am Dienstag, 16. Januar 2007 10:10 schrieb Jerome Lacoste:
> Hi,
>
> I unplugged my (second) webcam, forgotting to stop ekiga, and khubd is
> now taking 100% CPU.
>
> - lsusb doesn't return
> - /etc/init.d/udev restart didn't resolve the problem.
>
> Is that a problem one may want to investigate
* Pierre Peiffer <[EMAIL PROTECTED]> wrote:
> The modified hackbench is available here:
>
> http://www.bullopensource.org/posix/pi-futex/hackbench_pth.c
cool!
> I've run this bench 1000 times with pipe and 800 groups.
> Here are the results:
>
> Test1 - with simple list (i.e. without any fute
Hi all,
A trivial patch to use ARRAY_SIZE macro defined in kernel.h instead
of reimplementing it.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
capi.c|4 ++--
capidrv.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/capi/capi.c b/drivers/
Roy Huang wrote:
> Hi Balbir,
>
> Thanks for your comment.
>
> On 1/15/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> wakeup_kswapd and shrink_all_memory use swappiness to determine what to
>> reclaim
>> (mapped pages or page cache). This patch does not ensure that only
>> page cache is
>> r
On 1/16/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Dienstag, 16. Januar 2007 10:10 schrieb Jerome Lacoste:
> Hi,
>
> I unplugged my (second) webcam, forgotting to stop ekiga, and khubd is
> now taking 100% CPU.
>
> - lsusb doesn't return
> - /etc/init.d/udev restart didn't resolve the proble
On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
> Use ARRAY_SIZE macro in pvrusb2-hdw.c file
>
> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
... snip ...
i'm not sure it's worth submitting multiple patches to convert code
expressions to the ARRAY_SIZE() macro since i was going to wait for
t
On Monday 15 January 2007 8:25 pm, Nate Diller wrote:
> I don't think we should be waiting on sync I/O
> at the *top* of the call stack, like with wait_on_sync_kiocb(), I'd
> say the best place to wait is at the *bottom*, down in the I/O
> scheduler.
Erm ... *what* I/O scheduler? These I/O requ
On 1/15/07, David Brownell <[EMAIL PROTECTED]> wrote:
On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
> This removes the aio implementation from the usb gadget file system.
NAK. I see a deep mis-understanding here.
> Aside
> from making very creative (!) use of the aio retry path, it ca
On 1/15/07, David Brownell <[EMAIL PROTECTED]> wrote:
On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
> --- a/drivers/usb/gadget/inode.c 2007-01-12 14:42:29.0 -0800
> +++ b/drivers/usb/gadget/inode.c 2007-01-12 14:25:34.0 -0800
> @@ -559,35 +559,32 @@ static int ep
On Tue, Jan 16 2007, Thomas Gleixner wrote:
> On Tue, 2007-01-16 at 11:41 +1100, Jens Axboe wrote:
> > > AFAICS this is intentional to avoid checks all over the place, but the
> > > underflow check is missing. All we need to do is make sure, that in case
> > > of ioc->plugged == 0 we return early a
...
> -static struct super_operations openprom_sops = {
> +const static struct super_operations openprom_sops = {
About to send a new patch to make that 'static const' instead :)
Jeff.
--
Intellectuals solve problems; geniuses prevent them
- Albert Einstein
-
To unsubscribe
This patch is inspired by Arjan's "Patch series to mark struct
file_operations and struct inode_operations const".
Compile tested with gcc & sparse.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/9p/vfs_super.c |4 ++--
fs/adfs/super.c |2 +-
fs/af
It doesn't look that useful anyway, it just deactivates the unshare
capability for the user namespace.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
include/linux/sched.h |9 -
include/linux/user_namespace.h | 33 -
init/Kconfig
Remove the lone, remaining reference to the long-deceased
rwlock_is_locked() macro.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/asm-arm/spinlock.h b/include/asm-arm/spinlock.h
index 861092f..800ba52 100644
--- a/include/asm-arm/spinlock.h
+++ b/include/asm-arm
Return early from pci_set_power_state() if hardware does not support
power management. This way, we do not generate noise in the logs.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 206c834..6158497 100644
--- a/drivers/pci/pci.c
+++ b/d
On Mo, 2007-01-15 at 10:15 -0800, Stephen Hemminger wrote:
> Are you running over a device that does checksum offload?
Ooh, I'm feeling stupid now. Yes, I was. Turns out the problem
are the md5 checksums after all. Crypto-enabled tcpdump says:
11:05:42.856702 IP (tos 0x0, ttl 64, id 35129, offs
Remove what appear to be a number of dead kernel config variables,
that apparently have no effect on the build process.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
whoops, ignore that last patch. it contained a single line change
to a defconfig file, which is a silly thing to d
Suresh,
on the latest -rt kernel, when the dynticks load-balancer is enabled,
then a dual-core Core2 Duo test-system increases its irq rate from the
normal 15/17 per second to 300-400/sec - on a completely idle system(!).
Any idea what's going on? I'll disable the load balancer for now.
Remove an apparently unused, Appletalk-related kernel config
variable IPDDP_DECAP.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
the kernel config variable IPDDP_DECAP seems superfluous given where
else one finds the string "IPDDP_DECAP" in the kernel source tree
(other than defco
[MTRR] fix 32-bit ioctls on x64_32
Signed-off-by: Giuliano Procida <[EMAIL PROTECTED]>
---
Fixed incomplete support for 32-bit compatibility ioctls in
2.6.19.1. They were unhandled in one of three case-statements.
Testing using X server before and after change.
--- linux-source-2.6.19.1.orig/ar
On Sat, 2007-01-13 at 23:57 +0100, [EMAIL PROTECTED] wrote:
> Hi there,
>
> I've been curious enough to try 2.6.20-rc5 with nfs4/kerberos.
> It was working fine before. I was using 2.6.18.1 on the client and
> 2.6.20-rc3-git4 on server and today i tried 2.6.20-rc5 on both client
> and server. (bot
On Tue, 16 Jan 2007 08:14:30 +, Giuliano Procida wrote:
> [MTRR] fix 32-bit ioctls on x64_32
>
> Signed-off-by: Giuliano Procida <[EMAIL PROTECTED]>
>
> ---
>
> Fixed incomplete support for 32-bit compatibility ioctls in
> 2.6.19.1. They were unhandled in one of three case-statements.
> Test
On Tue, Jan 16, 2007 at 11:53:19AM +0200, Ahmed S. Darwish wrote:
> Hi all,
>
> A trivial patch to use ARRAY_SIZE macro defined in kernel.h instead
> of reimplementing it.
>
> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
Acked-by: Karsten Keil <[EMAIL PROTECTED]>
> ---
>
> capi.c|
On 01/16, Srivatsa Vaddagiri wrote:
>
> On Mon, Jan 15, 2007 at 07:55:16PM +0300, Oleg Nesterov wrote:
> >
> > As I said already __create_workqueue() needs a fix, schedule_on_each_cpu()
> > is already broken, and should be fixed as well.
>
> __create_workqueue() creates worker threads for all onli
A couple of weeks ago my 400Gb SATA disk crashed. I just
got the replacement, but I can't seem to be able to create
a filesystem on it!
This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper
v2.6.15-27.50).
- s n i p -
[EMAIL PROTECTED]:~# cfdisk -P s /dev/sda
Partition Table
Robert Hancock wrote:
>> What is that GART thing exactly? Is this the hardware IOMMU? I've always
>> thought GART was something graphics card related,.. but if so,.. how
>> could this solve our problem (that seems to occur mainly on harddisks)?
>>
> The GART built into the Athlon 64/Opteron CP
>Subject: Re: I broke my port numbers :(
>
>On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
>> I know this may be entirely my fault but I have tried reversing
>> all of my _own_ patches I applied to 2.6.19.2 but can't find what broke this.
>> I did three times "netcat 127.0.0.69 42", not
On Tue, Jan 16, 2007 at 02:27:06PM +0100, Turbo Fredriksson wrote:
> A couple of weeks ago my 400Gb SATA disk crashed. I just
> got the replacement, but I can't seem to be able to create
> a filesystem on it!
>
> This is a PPC (Pegasos), running 2.6.15-27-powerpc (Ubuntu Dapper
> v2.6.15-27.50).
Christoph Anton Mitterer wrote:
Ok,.. that sounds reasonable,.. so the whole thing might (!) actually be
a hardware design error,... but we just don't use that hardware any
longer when accessing devices via sata_nv.
So this doesn't solve our problem with PATA drives or other devices
(although we
CONFIG_UTS_NS has very little value as it only deactivates the unshare
of the uts namespace and does not improve performance.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
include/linux/utsname.h | 19 ---
init/Kconfig|8
kernel/Makefile
CONFIG_IPC_NS has very little value as it only deactivates the unshare
of the ipc namespace and does not improve performance.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
include/linux/ipc.h | 11 ---
init/Kconfig|9 -
ipc/msg.c |4 +---
ipc
Hi all,
Can a buffer allocated by "vmalloc( )" be used to make DMA transmission (the
buffer will be used by BIO structure) on X86_64 platform?
I need a big buffer (cache) maybe 64MB or bigger, so I call vmalloc to
allocate the buffer.
If possible, how to get the pages in the buffer?
Thanks
-
To
And a few graphs here: http://linux.inet.hr/how_fast_is_your_disk.html
Comments welcome!
#define _LARGEFILE64_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BLOCKSIZE 512
#define TIMEOUT 30
int count;
time_t start;
void done()
{
(the following applies equally well to RW_LOCK_UNLOCKED.)
according to Documentation/spinlocks.txt:
==
Macros SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated and will
be removed soon. So for any new code dynamic initialization should be
used:
spin
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> It doesn't look that useful anyway, it just deactivates the unshare
> capability for the user namespace.
>
> Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
Agreed on both this and CONFIG_UTS_NS. (I haven't looked closely enough
at the CONFIG_I
Pierre Peiffer wrote:
> I've run this bench 1000 times with pipe and 800 groups.
> Here are the results:
This is not what I'm mostly concerned about. The patches create a
bottleneck since _all_ processes use the same resource. Plus, this code
has to be run on a machine with multiple processors t
On Mon, 15 Jan 2007, Olivier Galibert wrote:
> On Mon, Jan 15, 2007 at 06:45:40PM +, Alan wrote:
>> On Mon, 15 Jan 2007 18:16:02 +0100
>> Olivier Galibert <[EMAIL PROTECTED]> wrote:
>>
>>> sd 0:0:0:0: SCSI error: return code = 0x0802
>>> sda: Current: sense key: Hardware Error
>>> ASC
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> CONFIG_IPC_NS has very little value as it only deactivates the unshare
> of the ipc namespace and does not improve performance.
>
> Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
Acked-by: Serge Hallyn <[EMAIL PROTECTED]>
> ---
> include/lin
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> CONFIG_UTS_NS has very little value as it only deactivates the unshare
> of the uts namespace and does not improve performance.
>
> Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
It really is worthless complication, with the sole effect being t
> Correctable SCSI errors show that the data in a sector was not properly
> read, but the device was able to fix the data error because of the
> redundancy in the CRC. The error could be permanently fixed is you
> rewrote the sector. You probably don't know where the bad sector is
The drives do th
On Tue, Jan 16, 2007 at 14:57:56 +0100, Jan Engelhardt wrote:
>
> >Subject: Re: I broke my port numbers :(
> >
> >On Mon, Jan 15, 2007 at 23:55:15 +0200, Sami Farin wrote:
> >> I know this may be entirely my fault but I have tried reversing
> >> all of my _own_ patches I applied to 2.6.19.2 but ca
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Pierre Peiffer wrote:
> > I've run this bench 1000 times with pipe and 800 groups.
> > Here are the results:
>
> This is not what I'm mostly concerned about. The patches create a
> bottleneck since _all_ processes use the same resource. [...]
what
I have compiled & built linux 2.4 kernel, then I
created initrd image using mkinitrd.
Then I mounted this initrd, injected /bin/sh & libc
libraries from system into initrd.
I copied newly built vmlinuz & initrd images to pxe
servert tftp directory.
When I pxe boot my bare-metal machine with these
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: fix typo in geode_configre()@cyrix.c
Date: Tue, 9 Jan 2007 12:33:48 -0500
Thank you for comments.
> On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
> > In kernel 2.6, write back wrong register when configure Geode processor.
> > Inst
Hi.
I hope to support "classic" MediaGXm in kernel.
The DIR1 register of MediaGXm( or Geode) shows the following values for
identify CPU.
For exsample, My MediaGXm shows 0x42.
We can read National Semiconductor's datasheet without any NDAs.
http://www.national.com/pf/GX/GXLV.html
from datasheet
I'm sorry if I missed your previous post. I've never ignored a
configfs post on purpose :-)
Well, thanks a lot for the reply! :)
Here's the issue... the configfs system can prevent a user from
_creating_ sub-directories in a certain directory (by not supplying
struct configfs_group_o
On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> You are right. I agree to your comment. These variables are needless.
> I made a patch again.
Of course there are also lots of "magic numbers" around, but I must
admit I don't personally really feel like going through the data sheet
and nam
This patch (as838) makes some trivial whitespace fixes to the i386
ptrace.c file. Along with some stylistic issues, an entire section of
code was indented by two extra spaces -- I blame it on stupid
automatic editor indentation!
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/a
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as839) implements the Kwatch (kernel-space hardware-based
watchpoints) API for the i386 architecture. The API is explained in
the kerneldoc for register_kwatch() in arch/i386/kernel/kwatch.c.
The original version of the patch was written by Vamsi
On Tue, 2006-12-05 at 14:07 +0100, Jan Glauber wrote:
> Yes, if an attacker knows the initial clock value a brute-force attack
> would be feasible to predict the output. But I don't know if the
> hardware completely relies on the clock values or if there is any
> internal state which is not visible
At Sat, 13 Jan 2007 07:37:59 +0100,
Oliver Neukum wrote:
>
> Am Freitag, 12. Januar 2007 18:42 schrieb Takashi Iwai:
> > At Fri, 12 Jan 2007 14:49:57 +0100,
> > Oliver Neukum wrote:
> > >
> > > + } else {
> > > + if (idx < snd_ecards_limit) {
> > > + if (snd_cards_lock &
Quoting Alexey Dobriyan ([EMAIL PROTECTED]):
> /proc/*/mounstats was fixed, all right, but...
>
> To reproduce:
>
> while true; do
> find /proc -type f 2>/dev/null | xargs cat 1>/dev/null
> 2>/dev/null;
> done
>
> BUG: unable to handle kernel NULL pointer dereference a
Subject: [patch] ACPI: fix cpufreq regression
From: Ingo Molnar <[EMAIL PROTECTED]>
recently cpufreq support on my laptop (Lenovo T60) broke completely:
when it's plugged into AC it would never go higher than 1 GHz - neither
1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace,
On Tue, 16 Jan 2007, Paul Jackson wrote:
> > 1. The nodemask expands the inode structure significantly if the
> > architecture allows a high number of nodes. This is only an issue
> > for IA64.
>
> Should that logic be disabled if HOTPLUG is configured on? Or is
> nr_node_ids a valid upper limi
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: fix typo in geode_configre()@cyrix.c
Date: Tue, 16 Jan 2007 11:50:07 -0500
> On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> > You are right. I agree to your comment. These variables are needless.
> > I made a patch again.
>
> Of c
"ping6 -I eth0 ff02::1" worked fine for 2.6.20-rc3, with both Linux
systems on the link responding. Somewhere in either -rc4 or -rc5 this
quit working.
"tcpdump -i eth0 -l -n ip6" on the remote (same link) Linux system shows
the icmp6 echo request going out on the wire, but no one responds.
One
On Tue, Jan 16, 2007 at 03:47:52PM +, Alan wrote:
> The drives do that automatically, and the SCSI verify did it for him too
> if there were any other problems.
The SCSI verify didn't see a thing, I'm gonna do the disk swapping
dance.
OG.
-
To unsubscribe from this list: send the line "uns
Hi Richard,
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> > You've got the same optimizations for x86 by modifying an instruction's
> > immediate operand and thus avoiding a d-cache hit. The only real caveat is
> > the need to avoid the unsynchronised cross modification erratum. Which
> > means
On Tue, Jan 16, 2007 at 12:51:32AM +0530, Dipankar Sarma wrote:
>
>
>
> This patch re-organizes the RCU code to enable multiple implementations
> of RCU. Users of RCU continues to include rcupdate.h and the
> RCU interfaces remain the same. This is in preparation for
> subsequently merging the p
Ingo Molnar wrote:
> what do you mean by that - which is this same resource?
From what has been said here before, all futexes are stored in the same
list or hash table or whatever it was. I want to see how that code
behaves if many separate processes concurrently use futexes.
--
➧ Ulrich Dreppe
On Tue, Jan 16, 2007 at 12:52:48AM +0530, Dipankar Sarma wrote:
>
>
> Finally, RCU gets its own softirq. With it being used extensively,
> the per-cpu tasklet used earlier was just a softirq with overheads.
> This makes things more efficient.
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Sig
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> > what do you mean by that - which is this same resource?
>
> From what has been said here before, all futexes are stored in the
> same list or hash table or whatever it was. I want to see how that
> code behaves if many separate processes concurr
On Tue, Jan 16, 2007 at 12:54:46AM +0530, Dipankar Sarma wrote:
>
>
> Fix rcu_barrier() to work properly in preemptive kernel environment.
> Also, the ordering of callback must be preserved while moving
> callbacks to another CPU during CPU hotplug.
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
On Tue, Jan 16, 2007 at 01:01:03AM +0530, Dipankar Sarma wrote:
>
> Fix a few trivial things based on review comments.
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Dipankar Sarma <[EMAIL PROTECTED]>
>
> ---
>
>
>
> diff -puN kernel/rcupreempt.c~rcu-fix-trivials kernel/rcup
This patch adds a barrier() to lockdep.c lockdep_recursion updates. This
variable behaves like the preemption count and should therefore use similar
memory barriers.
This patch applies on 2.6.20-rc4-git3.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/kernel/lockdep.c
+++ b/kernel/lo
Here is a patch to lockdep.c so it behaves correctly when a kprobe breakpoint is
put on a marker within hardirq tracing functions as long as the marker is within
the lockdep_recursion incremented boundaries. It should apply on
2.6.20-rc4-git3.
Mathieu
Signed-off-by: Mathieu Desnoyers <[EMAIL PRO
On Tue, 2007-01-16 at 00:21 -0500, David Moore wrote:
> On Mon, 2007-01-15 at 16:43 -0500, Kristian Høgsberg wrote:
> > On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > again the best way is for you to provide an mmap method... you can then
> > > fill in the pages and keep that in some
Hi.
On 16/01/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:
On Tue, 16 Jan 2007 08:14:30 +, Giuliano Procida wrote:
These #ifdefs are too ugly.
Agreed that the #ifdefs are rather ugly, but they were the smallest change.
Whoever wrote the original compat changes was relying on the IOC
con
Anyone played with hrtimers?
I setup a hrtimer to expire in 50,000,000 ns (20 hz), but it returns
much faster than specified. Changing sample_ns_interval (say to
80,000,000ns or 1,000,000,000) does not scale delta_time as expected.
So I think I may have found a bug in the clock/hrtimers code.
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> >If one use iommu=soft the sata_nv will continue to use the new code
> >for the ADMA, right?
>
> Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be
On Tue, Jan 16, 2007 at 09:39:19AM -0700, Eric W. Biederman wrote:
> --- a/fs/xfs/linux-2.6/xfs_sysctl.c
> +++ b/fs/xfs/linux-2.6/xfs_sysctl.c
> @@ -55,95 +55,197 @@ xfs_stats_clear_proc_handler(
> + {
> + .ctl_name = XFS_RESTRICT_CHOWN,
> + .procname = "res
Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> On Tue, Jan 16, 2007 at 09:39:19AM -0700, Eric W. Biederman wrote:
>> --- a/fs/xfs/linux-2.6/xfs_sysctl.c
>> +++ b/fs/xfs/linux-2.6/xfs_sysctl.c
>> @@ -55,95 +55,197 @@ xfs_stats_clear_proc_handler(
>
>> +{
>> +.ctl_name = XFS_RES
This kills the extra NULLs and spaces, I missed.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_sysctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/linux-2.6/xfs_sysctl.c b/fs/xfs/linux-2.6/xfs_sysctl.c
index 3ac4dab..0dc
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...]
> It would be nice to push the study of the kprobes debug trap handler so it can
> become possible to use it to put breakpoints in trap handlers. For now,
> kprobes
> refuses to insert breakpoints in __kprobes marked functions. However, as we
Linux Portal wrote:
And a few graphs here: http://linux.inet.hr/how_fast_is_your_disk.html
Comments welcome!
These results:
gaimboi:davidsen> ./da /dev/hdb
Seeker v2.0, 2007-01-15, http://linux.inet.hr/how_fast_is_your_disk.html
Benchmarking /dev/hdb [0MB], wait 30 seconds
On Mon, 2007-01-15 at 15:42 +, Ben Dooks wrote:
> On Mon, Jan 15, 2007 at 01:44:28PM +, Richard Purdie wrote:
> > On Mon, 2007-01-15 at 12:26 +, Ben Dooks wrote:
> > > Generate a name if none is passed to the S3C24XX GPIO LED driver.
> > >
> > > Signed-off-by: Ben Dooks <[EMAIL PROTECT
On Sun, Jan 14, 2007 at 06:27:18AM +0900, OGAWA Hirofumi wrote:
> This rejects a broken MCFG tables on Asus etc.
> Arjan and Andi suggest this.
And I agree completely with the principle. If you don't know the
chipset on a first-name basis, trash the MCFG unless it's squeaky
clean (or you don't ha
On Mon, Jan 08, 2007 at 01:27:15PM -0800, Jesse Barnes wrote:
> On Monday, January 8, 2007 12:45 pm, Olivier Galibert wrote:
> > On Sun, Jan 07, 2007 at 11:44:16AM -0800, Jesse Barnes wrote:
> > > For reference, here's the probe routine I tried for 965, probably
> > > something dumb wrong with it t
Olivier Galibert <[EMAIL PROTECTED]> writes:
> If you're going to do a MCFG validation function, and I don't have a
> problem with that, you should put the e820 test in it too.
Sounds good, thanks. I'll do later.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the lin
On Mon, 15 Jan 2007, Paul Jackson wrote:
> Patch looks good - thanks, Bob.
>
> Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
Looks good to me too.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On 1/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
This solution may be a bit hokey. I tried other approaches but this
one seemed to be the simplest with the least complications. Maybe someone
else can come up with a better solution?
How about a 64-bit field in struct inode that's used a
Chris Wedgwood wrote:
> right now i'm thinking if we can't figure out which cpu/bios
> combinations are safe we might almost be better off doing iommu=soft
> for *all* k8 stuff except for those that are whitelisted; though this
> seems extremely drastic
>
I agree,... it seems drastic, but this i
On Tue, 16 Jan 2007, Paul Menage wrote:
> On 1/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > This solution may be a bit hokey. I tried other approaches but this
> > one seemed to be the simplest with the least complications. Maybe someone
> > else can come up with a better solution?
On 1/16/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Tue, 16 Jan 2007, Paul Menage wrote:
> On 1/15/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > This solution may be a bit hokey. I tried other approaches but this
> > one seemed to be the simplest with the least complications.
On Tue, 16 Jan 2007, Peter Zijlstra wrote:
> > B. We add a new counter NR_UNRECLAIMABLE that is subtracted
> >from the available pages in a node. This allows us to
> >accurately calculate the dirty ratio even if large portions
> >of the node have been allocated for huge pages or for
>
1 - 100 of 322 matches
Mail list logo