This patch fixes an off-by-one in a snd_assert() spotted by the
Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.22-rc6-mm1/sound/pci/cs46xx/dsp_spos_scb_lib.c.old
2007-07-23 15:33:17.0 +0200
+++
Tilman Schmidt wrote:
Attached are .config and dmesg (as captured in SuSE's /var/log/boot.msg)
of a CONFIG_XEN=n git-current build.
That's dmesg from a successful boot? What does it look like when its
unsuccessful? Where do they start to differ?
J
-
To unsubscribe from this list: send
On Mon, 2007-07-23 at 16:36 +0200, Frederik Deweerdt wrote:
- struct request_queue *rq = sdev-request_queue;
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -736,7 +735,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
*
On Monday 23 July 2007 16:46:03 Mathieu Desnoyers wrote:
I would recommend to prefix with __init every function that is assumed
safe because executed at boot time. It would minimize the risks of
buggy usage of these text-modification primitives. That includes
text_poke() and a big chunk of
On Jul 23 2007 15:18, Yoann Padioleau wrote:
Here is an excerpt of the semantic patch that performs the transformation
@@
- (T*) dev-priv
+ netdev_priv(dev)
Note that dev-priv is a void*, and hence does not need casting.
So dev-priv may also appear without one.
{
- struct xl_private
On Mon, Jul 23, 2007 at 04:36:38PM +0200, Frederik Deweerdt wrote:
Hi James,
A compile of the latest git on arm triggers the following warning:
CC [M] drivers/scsi/scsi_sysfs.o
drivers/scsi/scsi_sysfs.c: In function `scsi_sysfs_add_sdev':
drivers/scsi/scsi_sysfs.c:718: warning:
On Tuesday, July 3, 2007 4:00:07 am Justin Piszcz wrote:
Incase anyone is interested:
p34:/usr/src/linux-2.6.22-rc7# patch -p1 ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
Hunk #1 succeeded at 548 (offset -5 lines).
patching file arch/i386/kernel/cpu/mtrr/generic.c
On Sun, 22 Jul 2007 [EMAIL PROTECTED] wrote:
You are confusing userspace with user tasks. And not only that,
you often use the term userspace when you should say user mode.
If you want I can explain the differences.
please do, I have been treating all three as the same catagory.
Very
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Take a step back for a second.
The problem we're facing now is that we're getting some userspace threads,
used in processing I/O, that are functioning as exceptions to the freeze
userspace, then freezeable kernel threads rule. They are only
Resolves,
BUG: sleeping function called from invalid context cc1(29651) at
kernel/rtmutex.c:636
in_atomic():1 [0001], irqs_disabled():0
[c0119f50] __might_sleep+0xf3/0xf9
[c031600e] __rt_spin_lock+0x21/0x3c
[c014102c] get_zone_pcp+0x20/0x29
[c0141a40] free_hot_cold_page+0xdc/0x167
* Andi Kleen ([EMAIL PROTECTED]) wrote:
On Monday 23 July 2007 16:46:03 Mathieu Desnoyers wrote:
I would recommend to prefix with __init every function that is assumed
safe because executed at boot time. It would minimize the risks of
buggy usage of these text-modification primitives.
On Mon, 23 Jul 2007 09:40:04 -0300 (GFT)
werner [EMAIL PROTECTED] wrote:
The kernel need to stay compatible to old versions of the file system and
other fundamental programs.
This sounds new to me...
Documentation/stable_api_nonsense.txt
--
Paolo Ornati
Linux
* Date: Mon, 23 Jul 2007 14:53:10 +0100
http://permalink.gmane.org/gmane.linux.kernel/559360
-
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
Jan Engelhardt [EMAIL PROTECTED] writes:
On Jul 23 2007 15:18, Yoann Padioleau wrote:
Here is an excerpt of the semantic patch that performs the transformation
@@
- (T*) dev-priv
+ netdev_priv(dev)
Note that dev-priv is a void*, and hence does not need casting.
So dev-priv may also appear
Ken Moffat wrote:
On Sat, Jul 21, 2007 at 09:54:37AM -0400, Bill Davidsen wrote:
So is setting it to a random number considered correct behavior? Any of
the first three values I mentioned would make sense, but the value I see
is neither time since resume, time since power-on to do the
I'm attempting to get kexec to pass a command line longer than 256 bytes to the
new kernel, using kexec-tools-testing-20070330 and kernel 2.6.22.1. The new
kernel is a bzImage, and I'm using kexec to tack on a command line and an
initrd.
I made the following change to kexec:
---
Gabriel C wrote:[Sun Jul 22 2007, 10:00:39PM EDT]
Linus Torvalds wrote:
Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there.
...
drivers/char/hpet.c:76: warning: integer constant is too large for 'long' type
...
Introduced by
Subject: xen: fix process_msg() use-after-kfree
From: Ingo Molnar [EMAIL PROTECTED]
fix an obvious use-after-kfree bug in Xen.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
drivers/xen/xenbus/xenbus_xs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
Sorry about that. I thought my review had caught all of these.
I missed it too (my old gcc version 3.4.6 doesn't pop a warning
for this).
Presumably the same change is needed for clocksource_itc in
arch/ia64/kernel/time.c
-Tony
-
To unsubscribe from this list: send the line unsubscribe
Mikael Pettersson wrote:
On this machine (Gigabyte mobo with i815EP chipset and a PIII),
APM worked fine up to 2.6.22. With 2.6.23-rc1 however the APM
driver fails to locate the APM bios:
--- dmesg-2.6.22 2007-07-23 14:07:46.0 +0200
+++ dmesg-2.6.23-rc1 2007-07-23
Am Montag, 23. Juli 2007 schrieb Agarwal, Lomesh:
For future how do I trace a system call to a function in a kernel?
strace. i.e:
$ strace ls
-
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 Mon, Jul 23, 2007 at 02:35:16PM +0100, David Woodhouse wrote:
s/Documentaion/Documentation/ in the last line of Documentation/pps/pps.txt
Fixed.
Please feed it to scripts/checkpatch.pl -- you can ignore all the
warnings about lines greater than 80 characters, and the complete crap
about
On Mon, Jul 23, 2007 at 01:53:30PM +0200, Adrian Bunk wrote:
On Mon, Jul 23, 2007 at 08:56:04AM +0200, Borislav Petkov wrote:
Hi there,
I don't know whether this is the proper Kconfig-way to fix this but it
works ok here.
When entered, the menu point USB DSL modem support in
Hi,
There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
that was unnecessary and not required for the correctness of those APIs.
All that superfluous stuff was also unnecessarily disallowing compiler
optimization possibilities, and making gcc generate code that wasn't as
From: Satyam Sharma [EMAIL PROTECTED]
[1/8] i386: bitops: Update/correct comments
Just trying to standardize the look of comments for various functions of the
bitops API, removed some trailing whitespace here and there, give different
kernel-doc description to the atomic functions and their
From: Satyam Sharma [EMAIL PROTECTED]
[2/8] i386: bitops: Rectify bogus Ir constraints
The I constraint (on the i386 platform) is used to restrict constants to
the 0..31 range, for use with instructions that must deal with bit numbers.
However:
* The I constraint modifier is applicable only to
From: Satyam Sharma [EMAIL PROTECTED]
[3/8] i386: bitops: Rectify bogus +m constraints
From the gcc manual:
Extended asm supports input-output or read-write operands. Use the
constraint character `+' to indicate such an operand and list it with
the output operands. You should only use
From: Satyam Sharma [EMAIL PROTECTED]
[4/8] i386: bitops: Kill volatile-casting of memory addresses
All the occurrences of volatile that are used to qualify access to the
passed bit-string pointer/address must be removed, because volatile is
crazy, doesn't really work anyway, has nothing to do
From: Satyam Sharma [EMAIL PROTECTED]
[5/8] i386: bitops: Contain warnings fallout from the death of volatiles
The wrappers below included from all over tree re-used volatile just
because the bitops used them. With them killed, almost every file ends
up crying about:
warning: passing argument 2
From: Satyam Sharma [EMAIL PROTECTED]
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
But test_and_set_bit, test_and_clear_bit, __test_and_change_bit,
and test_and_change_bit unnecessarily mark all of memory as
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) intersperse, our inline
From: Satyam Sharma [EMAIL PROTECTED]
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386, clear_bit() is a strict,
* John Sigler [EMAIL PROTECTED] wrote:
./trace-it 1 trace.txt
does it produce lots of trace entries? If not then
CONFIG_FUNCTION_TRACING is not enabled. Once you see lots of output
in the file, the tracer is up and running and you can start tracing
the latency in your app.
#
Gabriel C [mailto:[EMAIL PROTECTED]
Hi,
I got this warning on current git using gcc 4.2.1 :
...
drivers/dma/ioatdma.c: In function 'ioat_init_module':
drivers/dma/ioatdma.c:816: warning: the address of
'__this_module' will always evaluate as 'true'
Can you forward a copy of your .config?
ACK.
Al Viro wrote:
Obviously broken on little-endian; fortunately, the option is
not frequently used...
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index b34b7a7..b2a851c 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -732,7 +732,7 @@
On Mon, Jul 23, 2007 at 04:02:39PM +0300, Dan Aloni wrote:
On Mon, Jul 23, 2007 at 08:47:23PM +0900, Ken'ichi Ohmichi wrote:
Hi,
2007/07/23 10:31:47 +0530, Vivek Goyal [EMAIL PROTECTED] wrote:
[..]
I am also in favour of a complete kernel based solution. Export required
info
Hi!
Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P)
[N/m/y/?] (NEW) ?
If you say Y here, you will get experimental support for
Plan 9 resource sharing via the 9P2000 protocol.
See http://v9fs.sf.net for more information.
If unsure, say N.
What is plan 9 resource sharing?
On Fri 2007-07-13 21:11:28, Kok, Auke wrote:
[adding netdev]
David Fries wrote:
When I did a software suspend to disk then resumed the Intel network
card using eepro100 driver would be unable to transmit packets. I
tracked this down and found a register write after the print message
On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[2/8] i386: bitops: Rectify bogus Ir constraints
The I constraint (on the i386 platform) is used to restrict constants to
the 0..31 range, for use with instructions that must deal with bit numbers.
On Mon, Jul 23, 2007 at 09:54:34AM +0200, Pavel Machek wrote:
Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P)
[N/m/y/?] (NEW) ?
If you say Y here, you will get experimental support for
Plan 9 resource sharing via the 9P2000 protocol.
See http://v9fs.sf.net for more
On Monday 23 July 2007 18:05:58 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
The first goal is correct code.
The reason for the memory barrier
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
On Sat, 2007-07-21 at 23:07 +0100, Rui Nuno Capela wrote:
Call Trace:
[c010622a] show_trace_log_lvl+0x1a/0x30
[c01062f6] show_stack_log_lvl+0xb6/0xe0
[c0106521] show_registers+0x201/0x330
[c0106768] die+0x118/0x260
[c0304233] do_page_fault+0x193/0x600
[c030294a] error_code+0x72/0x78
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[2/8] i386: bitops: Rectify bogus Ir constraints
The I constraint (on the i386 platform) is used to restrict constants to
the 0..31 range,
BTW if you want to optimize inline asm code a bit -- find_first_bit /
find_first_zero_bit / for_each_cpu could really benefit from a optimized
version
for cpumask_t sized bitmaps. That would save a lot of cycles in some of the
hotter paths of the kernel like the scheduler.
-Andi
-
To
Checking for section mismatches across all of vmlinux is kicking
out a bunch of new warnings. Many of them real, but I have a
few from routines like this:
foo(...)
{
static int first_time = 1;
if (first_time) {
all_i_need = alloc_bootmem(NR_CPUS * xxx);
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or,
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:05:58 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
The
On Monday 23 July 2007 11:40, Arkadiusz Miskiewicz wrote:
After booting fresh 2.6.23rc1 taken from git I noticed oops in dmesg:
[ 46.274038] BUG: unable to handle kernel NULL pointer dereference at
virtual address
[ 46.274042] printing eip:
[ 46.274044] f8b5b2dc
[
BuraphaLinux Server wrote:
Hello,
I have had a hard time determining if /dev/sda is SCSI or SATA
from my boot scripts. It matters for smartd which needs an added
parameter -d sat in the configuration file for SATA drives. Finally I
came up with this, but I wonder if there is a better way?
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
just written a test program that used Ir with an automatic variable
defined in the inline function (as is the case with these bitops) and
observed that even when I gave 32 values, it would still work -- hence
my
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to
On Mon, 23 Jul 2007 18:01:32 +0200 Karsten Wiese wrote:
Am Montag, 23. Juli 2007 schrieb Agarwal, Lomesh:
For future how do I trace a system call to a function in a kernel?
strace. i.e:
$ strace ls
I thought (maybe I misunderstood) that Lomesh wanted to know
which kernel function
On Mon, 2007-07-23 at 08:21 -0700, Daniel Walker wrote:
Resolves,
BUG: sleeping function called from invalid context cc1(29651) at
kernel/rtmutex.c:636
in_atomic():1 [0001], irqs_disabled():0
[c0119f50] __might_sleep+0xf3/0xf9
[c031600e] __rt_spin_lock+0x21/0x3c
[c014102c]
Yes, but _that_ address (of the bit-string) is protected already -- by the
implicit memory barrier due to the LOCK prefix.
Compiler barrier != CPU barrier.
The memory clobber is a compiler barrier that prevents its global optimizer
from moving memory references. The CPU memory ordering
When comparing a pointer, it's clearer to compare it to NULL than to 0.
Here is the semantic patch:
@@
expression *E;
@@
E ==
- 0
+ NULL
@@
expression *E;
@@
- 0
+ NULL
== E
@@
expression *E;
@@
E !=
- 0
+ NULL
@@
expression *E;
@@
- 0
+ NULL
!= E
PS: I have performed the same
On Mon, 2007-07-23 at 18:32 +0200, Peter Zijlstra wrote:
On Mon, 2007-07-23 at 08:21 -0700, Daniel Walker wrote:
Resolves,
BUG: sleeping function called from invalid context cc1(29651) at
kernel/rtmutex.c:636
in_atomic():1 [0001], irqs_disabled():0
[c0119f50]
On Monday 23 July 2007 18:05:43 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[3/8] i386: bitops: Rectify bogus +m constraints
From the gcc manual:
Extended asm supports input-output or read-write operands. Use the
constraint character `+' to indicate such an operand
On 7/23/07, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
What is plan 9 resource sharing? Some kind of mosix-like process
migration? Could you explain it in two lines in Kconfig?
http://v9fs.sf.net
is redirect to
http://v9fs.sourceforge.net/
which tells me
Moved to SWiK
after clicking on
Nelson, Shannon wrote:
Gabriel C [mailto:[EMAIL PROTECTED]
Hi,
I got this warning on current git using gcc 4.2.1 :
...
drivers/dma/ioatdma.c: In function 'ioat_init_module':
drivers/dma/ioatdma.c:816: warning: the address of
'__this_module' will always evaluate as 'true'
Can you
Hello, please CC me as I'm not registered in these lists.
I'd like to announce DynAMOS, a dynamic kernel updating system that
supports Linux and could be of help in kernel development and high
availability.
This system has been a research project at Arizona State University
for the past 3 years
Plan 9 Resource Sharing Support (9P2000) (Experimental) (NET_9P)
[N/m/y/?] (NEW) ?
If you say Y here, you will get experimental support for
Plan 9 resource sharing via the 9P2000 protocol.
See http://v9fs.sf.net for more information.
If unsure, say N.
What is plan 9
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline
On Mon, Jul 23, 2007 at 09:22:14AM -0700, Luck, Tony wrote:
Checking for section mismatches across all of vmlinux is kicking
out a bunch of new warnings. Many of them real, but I have a
few from routines like this:
foo(...)
{
static int first_time = 1;
if (first_time) {
Ingo Molnar wrote:
add 'notrace' to the definition of read_tsc in arch/i386/kernel/tsc.c
OK.
(or do echo 1 /proc/sys/kernel/trace_use_raw_cycles
if you are using recent enough -rt)
Is patch-2.6.20-rt8 recent enough?
# ./trace-it 1 trace
# cat trace
preemption latency trace v1.1.5 on
I get some ACPI Exception.
...
[ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
Evaluating _PTC [20070126]
[ 33.075437] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND,
Evaluating _TSS [20070126]
[ 33.075490] ACPI Exception (processor_throttling-0084):
Hey there Michael, all,
On 7/22/07, Michael Kerrisk [EMAIL PROTECTED] wrote:
Problem 1
-
The value returned by read(2)ing from a timerfd file descriptor is the
number of timer overruns. In 2.6.22, this value is 4 bytes, limiting the
overrun count to 2^32. Consider an application
On Sun, 22 Jul 2007, H. Peter Anvin wrote:
Wouldn't be hard to make a git tree with all the patches all the way
back to 0.01 even...
I actually tried to get something like this together back in the BK days
and early in the SCO saga. It was pretty painful to try to find all the
historic
On Monday 23 July 2007 19:43:56 Gabriel C wrote:
I get some ACPI Exception.
...
[ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND,
Evaluating _PTC [20070126] [ 33.075437] ACPI Exception
(processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
just written a test program that used Ir with an automatic variable
defined in the inline function (as is the case with these bitops) and
observed that even when I gave 32 values, it would still work -- hence
my
(I tried to send this patch to linux-input@, but it seems to be currently having
some problems, so I'm going directly to LKML).
Certain (broken) pieces of South Bridge hardware will respond to
i8042_read_status() on boot with 0x0, despite there not being a real i8042
controller hooked up in the
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
Yes, but _that_ address (of the bit-string) is protected already -- by the
implicit memory barrier due to the LOCK prefix.
Compiler barrier != CPU barrier.
Exactly, but the actual _synchronization_ in all users of the bitops API
should
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:05:43 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[3/8] i386: bitops: Rectify bogus +m constraints
From the gcc manual:
Extended asm supports input-output or read-write operands. Use the
On 7/21/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Alexey Dobriyan [EMAIL PROTECTED] writes:
That's separate patch but CTL_UNNUMBERED must die, because it's totally
unneeded. If you don't want sysctl(2) interface just SKIP -ctl_name
initialization and save one line for something useful.
On Monday 23 July 2007 05:50, Mel Gorman wrote:
This was seen on a machine on test.kernel.org;
Unable to handle kernel NULL pointer dereference at
RIP:
[8037379b] acpi_processor_throttling_seq_show+0xa7/0xd6
PGD 3bd9e067 PUD 3bc6a067 PMD 0
Oops: [1] SMP
On Fri 20 Jul 2007 16:28, Mathieu Desnoyers pondered:
I also don't like the comment in asm-blackfin/atomic.h :
* Generally we do not concern about SMP BFIN systems, so we don't have
* to deal with that.
I have seen on the blackfin website that you actually sell a board with
SMP. Why
ext[234]_check_descriptors sanity checks block group descriptor geometry
at mount time, testing whether the block bitmap, inode bitmap, and
inode table reside wholly within the blockgroup. However, the inode
table test is off by one so that if the last block in the inode table
resides on the last
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The fallocate syscall returns ENOSYS in case the filesystem does not
support the operation and expects the userlevel code to fill in. This
is good in concept.
The problem is that the libc code for old kernels should be able to
distinguish the case
Add documentation for AGP boot options.
Signed-off-by: Chuck Ebbert [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |7 +++
1 file changed, 7 insertions(+)
--- 2.6.22-git11-d390.orig/Documentation/kernel-parameters.txt
+++ 2.6.22-git11-d390/Documentation/kernel-parameters.txt
On Mon, 23 Jul 2007, Ondrej Zajicek wrote:
On Sun, Jul 22, 2007 at 09:19:17PM -0700, Arjan van de Ven wrote:
let me give you a real world example then, and the numbers I'm using are
ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I
just rounded them a little so that the
Satyam Sharma wrote:
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
This patch adds the following files to the container filesystem:
notify_on_release - configures/reports whether the container subsystem should
attempt to run a release script when this container becomes unused
release_agent -
Eric Dumazet wrote:
The problem is in established_get_next() and established_get_first() not
allowing softirq processing, while scanning a possibly huge hash table,
even if few sockets are hashed in.
As cond_resched_softirq() was added in linux-2.6.11, you probably *need*
to check the diffs
On Mon, 23 Jul 2007, Satyam Sharma wrote:
[3/8] i386: bitops: Rectify bogus +m constraints
From the gcc manual:
Extended asm supports input-output or read-write operands. Use the
constraint character `+' to indicate such an operand and list it with
the output operands. You
On Mon, 23 Jul 2007, Linus Torvalds wrote:
So I've been thinking about trying to re-create some really old history
into git, but it's still a lot of work.. And obviously not very useful,
just interesting from an archeological standpoint.
I started this once.
I have (sort of) a GIT tree
Satyam Sharma wrote:
Exactly, but the actual _synchronization_ in all users of the bitops API
should (should, at least, otherwise the bugs lie in the callers) depend
upon the _bit-string_ whose address is passed to us. That could be some
flags/lock/etc in some caller, whatever, but all the
ext[234]_get_group_desc never tests the bh argument, and only sets
it if it is passed in; it is perfectly happy with a NULL bh argument.
But, many callers send one in and never use it. May as well call with
NULL like other callers who don't use the bh.
Signed-off-by: Eric Sandeen [EMAIL
On Mon, 23 Jul 2007, Satyam Sharma wrote:
[4/8] i386: bitops: Kill volatile-casting of memory addresses
This is wrong.
The const volatile is so that you can pass an arbitrary pointer. The
only kind of abritraty pointer is const volatile.
In other words, the volatile has nothing at all to
On Mon, 23 Jul 2007, Satyam Sharma wrote:
The goal is to let gcc generate good, beautiful, optimized code.
No. The point is to let gcc generate *correct* code.
It's either =m together with memory, or it's +m.
You just introduced a bug.
Linus
-
To unsubscribe from this
On Mon, 23 Jul 2007, Satyam Sharma wrote:
* The I constraint modifier is applicable only to immediate-value operands,
and combining it with r is bogus.
This is wrong too.
The whole point of a Ir modifier is to say that the instruction takes
*either* an I or an r.
Andrew - the ones I've
On Mon, Jul 23, 2007 at 12:49:36PM +0100, Al Viro wrote:
On Mon, Jul 23, 2007 at 06:55:59PM +0930, Alan Modra wrote:
On Mon, Jul 23, 2007 at 10:14:35AM +0200, Sam Ravnborg wrote:
But I would still like to hear from Alan what the benefits are.
See
Hey Andi,
I've not been able to review the new vdso code very carefully yet, but
I noticed one thing right off: the offset calculation is not masked, so
its possible w/ counters less then 64bits wide to have wrapping issues.
It seems something like the following would be needed.
diff
On Mon, Jul 23, 2007 at 09:05:54AM -0700, Nelson, Shannon wrote:
Gabriel C [mailto:[EMAIL PROTECTED]
Hi,
I got this warning on current git using gcc 4.2.1 :
...
drivers/dma/ioatdma.c: In function 'ioat_init_module':
drivers/dma/ioatdma.c:816: warning: the address of
Amit Choudhary [EMAIL PROTECTED] wrote:
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 07, 2007 at 12:46:50AM -0800, Amit Choudhary wrote:
Any strong reason why not? x has some value that does not make sense and can
create only problems. And as I explained, it can result in
Hi Linus,
It seems I just missed the closure of the -rc1 merge window.
Could you still add following 3 new watchdog drivers + some clean-ups
from the watchdog git tree for the -rc2 version?
If yes, please pull from 'master' branch of
On Mon, 23 Jul 2007, Nicolas Pitre wrote:
I started this once.
I have (sort of) a GIT tree with all Linux revisions that I could find
from v0.01 up to v1.0.9. But the most interesting information and also
what is the most time consuming is the retrieval of announcement
messages for
On Mon, 2007-07-23 at 10:59 -0700, john stultz wrote:
Hey Andi,
I've not been able to review the new vdso code very carefully yet, but
I noticed one thing right off: the offset calculation is not masked, so
its possible w/ counters less then 64bits wide to have wrapping issues.
Here's
It doesn't really matter (for me) whether it is sysctl or sysfs
interface. The sysctl approach seemed easier to implement. If the
consensus is to use sysfs, I'll send a patch (for 2.6.24).
Sorry for the incorrect implementation, I guess I stole the code from
unappropriate place :)
Thanks,
Andi Kleen wrote:
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
just written a test program that used Ir with an automatic variable
defined in the inline function (as is the case with these bitops) and
observed that even when I gave 32 values, it would still work
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
I'm not quite sure what your point is.
Could be a case of terminology confusion ...
The paragraph you quoted is
pretty explicit in saying that volatile doesn't prevent an asm
volatile from being interspersed with other code, and the example
801 - 900 of 1182 matches
Mail list logo
