On Thu, 2007-11-29 at 22:07 +0100, Jan Engelhardt wrote:
I'd add GFP_ATOMIC here. Who knows whether tomorrow, the oops dumper
or warn_on will use print_hex_dump.
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 70e23fb..be94934 100644
---
On Thu, 2007-11-29 at 15:56 -0500, [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007 14:45:51 EST, Jon Masters said:
Ah, but I could write a sequence of pages that on their own looked
garbage, but in reality, when executed would print out a copy of the
Jargon File in all its glory. And if you
On 11/29/07, Tejun Heo [EMAIL PROTECTED] wrote:
I now have affected drives on my desk and am gonna try reproduce it. My
gut feeling says it's timing related problem on controller / driver
side. Please wait a bit.
by the way, and OT, did the Plextor DVD-RW drive reach you, Tejun?
No,
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
On Thu, 29 Nov 2007 08:14:10 -
Metzger, Markus T [EMAIL PROTECTED] wrote:
Support for Intel's last branch recording to ptrace. This gives
debuggers
access to this hardware feature and allows them to show an execution
trace
of the debugged application.
Last branch recording (see
Hi -
This regular Linux user and lkml lurker just noticed data corruption in
ftp'ed files and narrowed it down to vsftpd using sendfile(). So far this
has never caused problems in the past; I have not noticed this with
2.6.22.x but may have missed it. I do remember reading about some changes
to
On Sun, 25 Nov 2007, Christoph Hellwig wrote:
This patch does exactly that and reverts xfs_file_readdir to what's
basically the 2.6.23 version minus the uio and vnops junk.
Thanks, works here too (without nordirplus as a mountoption).
Am I supposed to close the bug[0] or do you guys want to
On Monday 26 November 2007 11:05:38 pm Andrew Morton wrote:
On Thu, 22 Nov 2007 22:41:16 +0100 Jiri Slaby [EMAIL PROTECTED] wrote:
Ok, I hit the bug, suspend of 00:06 device complains about it:
WARNING: at .../kernel/resource.c:185 __release_resource()
Call Trace:
[8023f7b5]
On Thu, 2007-11-29 at 21:45 +, Alan Cox wrote:
Jargon File in all its glory. And if you still think you could look for
patterns, how about executable code that self-modifies in random ways
but when executed as a whole actually has the functionality of fetchmail
embedded within it? How
When the conversion factor between jiffies and milli- or microseconds
is not a single multiply or divide, as for the case of HZ == 300, we
currently do a multiply followed by a divide. The intervening
result, however, is subject to overflows, especially since the
fraction is not simplified (for
On Thu, 29 Nov 2007 16:25:33 -0500
Lee Schermerhorn [EMAIL PROTECTED] wrote:
- pn = kmalloc_node(sizeof(*pn), GFP_KERNEL, node);
+ /*
+* This routine is called against possible nodes.
+* But it's BUG to call kmalloc() against offline node.
+*
+* TODO: this routine
* Eric W. Biederman [EMAIL PROTECTED] wrote:
You'll never run out of this sort of problem. Keeping Linux lean and
simple would be far better.
Nah. The control group stuff has all kinds of corner cases because it
is a new and untested API. The namespace work after we get the code
On Thu, Nov 29, 2007 at 01:50:55PM -0800, Roland McGrath wrote:
UML is also a good test, though I have never been set up to verify
anything beyond UML seems to boot far enough to complain I don't
have a userland filesystem for it.
BTW, this doesn't exercise ptrace at all. Interesting ptrace
On Thursday November 29, [EMAIL PROTECTED] wrote:
http://programming.kicks-ass.net/kernel-patches/foo/
bdi-task-dirty.patch
bdi-sysfs.patch
bdi-min.patch
bdi-max.patch
Is my current rather experimental stack, I just wrote the max part after
having slept on it. I'm not fond
Hi,
I am running older kernel (CentOS 2.6.9-34 SMP) on 32 bit arch. Some
of my systems got hung, while trying to write some data to disk. All
those systems exhibit similar pattern where during this time,
/proc/meminfo suggesting 'Inactive' 'Dirty'. All of machines have 2G
of physical memory and
On Fri, Nov 30, 2007 at 12:11:28AM +0530, K. Prasad wrote:
Hi,
Please review the ensuing set of patches which convert the
existing RCU tracing mechanism for Preempt RCU and RCU Boost into
markers.
These patches are based upon the 2.6.24-rc2-rt1 kernel tree.
Along with marker
On Thu, Nov 29, 2007 at 12:16:36PM -0800, Michael Rubin wrote:
Due to my faux pas of top posting (see
http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt) I am
resending this email.
On Nov 28, 2007 4:34 PM, Fengguang Wu [EMAIL PROTECTED] wrote:
Could you demonstrate the
Hi Gary,
First, thanks for all the help and testing -- I really appreciate
it.
* Gary Hade [EMAIL PROTECTED]:
I'm getting back to you but unfortunately with not so good
news. Sorry Alex.
:-/
On the x3950 (configured single node) I encountered the below
problem when attempting to hotplug
On Nov 30, 2007 4:43 AM, Jiri Kosina [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007, Marcel Holtmann wrote:
Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784
[ ... ]
Does bluetooth input devices have something to do with usbhid? I don't
know, perhaps this is another
On Thu, 29 Nov 2007, Al Viro wrote:
Incidentally, I would really love to see the threat profile we are talking
about.
Exactly.
Please come up with a set of requirements that can be reviewed by the core
kernel folk, and perhaps then focus on how to meet those requirements once
they have
On Thu, 29 Nov 2007 16:40:37 -0700
Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Monday 26 November 2007 11:05:38 pm Andrew Morton wrote:
On Thu, 22 Nov 2007 22:41:16 +0100 Jiri Slaby [EMAIL PROTECTED] wrote:
Ok, I hit the bug, suspend of 00:06 device complains about it:
WARNING: at
-/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, the we can
+/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, then we can
divide
Yes, I missed it.
- * which, buy the way, it can do, but it take more code and at least 2
+ * which, buy the way, it can do,
Hi Linus,
It appears that unconditionally resetting the stack, which fixes old
LILO, breaks LOADLIN after all. This patch should work with either,
as well as work around the command-line truncation bug in old versions
of SYSLINUX.
Please pull:
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
On Thu, Nov 29, 2007 at 02:38:03PM -0800, Roland McGrath wrote:
Can you make sure that UML still runs when you're done with ptrace?
I'd be glad to, especially if you give me some advice on testing (.config
for um-i386 and um-x86_64, what do try that constitutes UML still runs).
Use
Paul Rolland wrote:
Total of 2 processors activated (6919.15 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 - CPU#1]:
Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due
Andrew Morton wrote:
On Thu, 29 Nov 2007 11:20:18 +0100 Frans Pop [EMAIL PROTECTED] wrote:
Well, for one it needlessly increases the size of log files.
It also IMO just looks weird to have a trailing period only for some
messages and it certainly is completely inappropriate for messages
On Nov 29, 2007 7:13 PM, Herbert Xu [EMAIL PROTECTED] wrote:
...
uninlining this function shrinks crypto/tcrypt.o's .text from 20,009 bytes
down to 19,701.
inlining is almost always wrong.
I agree. Please do as Andrew suggests and resubmit.
inline disabled.
Cc: Randy Dunlap [EMAIL
Larry Finger wrote:
If a particular routine needs to lock a mutex, but it may be entered with that
mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
The common way to deal with this is first to restructure your function
into two. One always acquires
On Fri, 2007-11-30 at 09:12 +0800, Li Zefan wrote:
Just a roughly grep:
# grep -r -P --include=*.[ch] 'printk.*\.\\n' * | wc -l
6025
# grep -r -P --include=*.[ch] '\.\\n' * | wc -l
12723
Inequivalent.
Try:
grep -rP --include=*.[ch] 'printk.*\.\\n' * | wc -l
and
grep -rp
On Thu, 29 Nov 2007 12:05:13 -0700 Matthew Wilcox [EMAIL PROTECTED] wrote:
The database performance group have found that half the cycles spent
in kmem_cache_free are spent in this one call to BUG_ON. Moving it
into the CONFIG_SLAB_DEBUG-only function cache_free_debugcheck() is a
performance
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
On Tue, 27 Nov 2007 17:33:05 +0800
Zhang, Yanmin [EMAIL PROTECTED] wrote:
If echo 1/proc/sys/kernel/sched_compat_yield before starting
volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
my 16-core tigerton.
On Thu, 29 Nov 2007, Linus Torvalds wrote:
Heh. It definitely hasn't gotten lost by the git software.
No, it sure hasn't. In fact it was staring me right in the face and I
didn't realize it.
In fact, with
the kinds of hints you already gave, git makes it really _trivial_ to find
it.
Ben Woodard [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
Ok. Got it. So in this case we route the interrupts directly through LAPIC
and put LVT0 in ExtInt mode and IOAPIC is bypassed.
I am looking at Intel Multiprocessor specification v1.4 and as
On Fri, 30 Nov 2007 13:46:22 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Todays kernel has a different behavior somewhat (and before people
scream regression; sched_yield() behavior isn't really specified
and doesn't make any sense at all, whatever you get is what you
get it's pretty
On Fri, 2007-11-30 at 09:54 +0800, Li Zefan wrote:
So it doesn't deserve the effort to eliminate these periods, isn't it?
I hope these will eventually disappear.
Or we can add a check to checkpatch.pl to prevent new ones.
Perhaps that's a good idea.
diff --git a/scripts/checkpatch.pl
On 29-11-07 18:09, Vitaliy Ivanov wrote:
Can anyone advice whether there is something similar to inotify in 2.4
kernel?
inotify is 2.6 (dnotify 2.4).
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Thursday 29 November 2007 10:36:06 Christoph Lameter wrote:
The code becomes much simpler if gs would point to the beginning of the
per cpu area and if the __per_cpu_offset[i] would do the same. No weird
__per_cpu_start offsetting anymore.
It is a little weird, but it gave flexibility for
Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
Ok. Got it. So in this case we route the interrupts directly through LAPIC
and put LVT0 in ExtInt mode and IOAPIC is bypassed.
I am looking at Intel Multiprocessor specification v1.4 and as per figure
3-3 on page 3-9, 8259 is
2.6.25 material.
kernel.h has become a bit disorganized over a long time.
Here's an attempt to clean it up a bit.
Something for everyone to like or dislike...
Groups externs and functions by module/function
Creates a logging.h for printk, KERN_level
Changes some macros to statement expressions
Change Documentation/Changes to Documentation/Requirements, and at
least begin to separate the runtime requirements from the kernel
compilation requirements.
There are definitely kernel compilation requirements that are not
listed in this file. It would be good to get them uncovered.
This
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
sounds like a bad idea; volanomark (well, technically the jvm behind
it) is abusing sched_yield() by assuming it does
On Friday 30 November 2007 13:51, Arjan van de Ven wrote:
On Fri, 30 Nov 2007 13:46:22 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Todays kernel has a different behavior somewhat (and before people
scream regression; sched_yield() behavior isn't really specified
and doesn't make any
Change Documentation/Changes to Documentation/Requirements, and at
least begin to separate the runtime requirements from the kernel
compilation requirements.
There are definitely kernel compilation requirements that are not
listed in this file. It would be good to get them uncovered.
This
Arjan van de Ven wrote:
Anyway, I don't think compiling bc is hard on anything which has a C
compiler.
alternative is to just also ship the precomputed values ;-)
Oh, come on... it's not like bc is some obscure thing. It's a POSIX
utility.
-hpa
-
To unsubscribe from this list:
Andrew Morton wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Does this add the first dependency upon the availability of bc?
I believe it does. I used bc because doing it C would have required
arbitrary-precision code or have added a dependency on
On Fri, 2007-11-30 at 14:29 +1100, Nick Piggin wrote:
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
sounds like a bad idea; volanomark (well, technically the jvm
Chris Snook wrote:
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
Perhaps it would, but I think there is more variability between dc
implementations -- consider if the
On Fri, Nov 30, 2007 at 09:20:34AM +0800, rae l wrote:
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
Patch applied. Thanks a lot Denis!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page:
On Mon, Nov 26, 2007 at 02:18:52PM -0800, Andrew Morton wrote:
On Sun, 18 Nov 2007 14:11:30 +0100
Borislav Petkov [EMAIL PROTECTED] wrote:
On Thu, Nov 15, 2007 at 01:10:16PM -0800, Lucy McCoy wrote:
...
yes, after testing this i can confirm that this one fixes the NULL ptr
problem here
Andrew Morton wrote:
On Wed, 28 Nov 2007 20:03:22 +0530
Kamalesh Babulal [EMAIL PROTECTED] wrote:
Hi Andrew,
while running tbench on the powerpc with 2.6.24-rc3-mm2 softlock up occurs
BUG: soft lockup - CPU#0 stuck for 11s! [tbench:12183]
NIP: c00ac978 LR: c00acff0 CTR:
On Nov 30, 2007 6:11 AM, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007, Greg KH wrote:
kobject_put(foo) is needed since it gets you through kobject_cleanup()
where the name can be freed.
No, kobject_register() should have handled that for us, right?
On Fri, 2007-11-30 at 03:18 +0100, Rene Herman wrote:
On 29-11-07 10:11, Dave Young wrote:
The pnpacpi rsparser.c report warnings of:
exceeded the max number of IO resources: 24
dmesg|grep exceeded|wc
66 5943564
Heavens... (added CCs of people who just upped it from 8
Vivek Goyal wrote:
On Wed, Nov 28, 2007 at 11:02:06AM -0500, Neil Horman wrote:
On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
Andi Kleen wrote:
Are we putting the system back in PIC mode or virtual wire mode? I have
On Thu, 29 Nov 2007 13:47:34 -0800
Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
-Original Message-
From: Jiri Slaby [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 29, 2007 1:43 PM
To: Pallipadi, Venkatesh; Nakajima, Jun
Cc: Linux kernel mailing list
Subject: kondemand:
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, Nov 29, 2007 at 03:12:38PM -0700, Justin Banks wrote:
It's not perfect, but as was recently pointed out, if you can only get
98% of the way there rather than 100% is that a reason for not trying to
make it possible?
BTW, that's a fine example of a common fallacy: $FOO is 98% of the
Hi Kenji-san,
* Kenji Kaneshige [EMAIL PROTECTED]:
Hi Gary, Kenji-san, et. al,
* Gary Hade [EMAIL PROTECTED]:
Alex, What I was trying to suggest is a boot-time kernel
option, not a kernel configuration option. The basic idea is
to give the user (with a single binary kernel) the
On Thu, 29 Nov 2007 16:19:51 -0800 H. Peter Anvin [EMAIL PROTECTED] wrote:
When the conversion factor between jiffies and milli- or microseconds
is not a single multiply or divide, as for the case of HZ == 300, we
currently do a multiply followed by a divide. The intervening
result, however,
Joe Perches wrote:
On Fri, 2007-11-30 at 09:12 +0800, Li Zefan wrote:
Just a roughly grep:
# grep -r -P --include=*.[ch] 'printk.*\.\\n' * | wc -l
6025
# grep -r -P --include=*.[ch] '\.\\n' * | wc -l
12723
Inequivalent.
Try:
grep -rP --include=*.[ch] 'printk.*\.\\n' * | wc -l
On Friday 30 November 2007 01:43, Balbir Singh wrote:
They say better strike when the iron is hot.
Since we have so many people discussing the memory controller, I would
like to access the readiness of the memory controller for mainline
merge. Given that we have some time until the merge
On Friday 30 November 2007 03:53:34 Arjan van de Ven wrote:
On Mon, 26 Nov 2007 10:25:33 -0800
Agreed. On first glance, I was intrigued but:
1) Why is everyone so concerned that export symbol space is large?
- does it cost cpu or running memory?
yes. about 120 bytes per symbol
But
On 29-11-07 10:11, Dave Young wrote:
The pnpacpi rsparser.c report warnings of:
exceeded the max number of IO resources: 24
dmesg|grep exceeded|wc
66 5943564
Heavens... (added CCs of people who just upped it from 8 -- I suppose the
problem is not new then?)
Rene.
-
To
Nick Piggin wrote:
On Friday 30 November 2007 01:43, Balbir Singh wrote:
They say better strike when the iron is hot.
Since we have so many people discussing the memory controller, I would
like to access the readiness of the memory controller for mainline
merge. Given that we have some time
On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
On Tue, 27 Nov 2007 17:33:05 +0800
Zhang, Yanmin [EMAIL PROTECTED] wrote:
If echo 1/proc/sys/kernel/sched_compat_yield before starting
volanoMark testing, the result is
On Thu, 29 Nov 2007 19:04:36 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Chris Snook wrote:
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
Perhaps it would, but
On 11/29/07, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
The feature does work as long as the device remains plugged in and
that is what I have said in my previous postings too. What I'm saying
that should work and worked under 2.6.21 and is not
On Fri, Nov 30, 2007 at 01:07:37PM +0800, Dave Young wrote:
On Nov 30, 2007 6:11 AM, Alan Stern [EMAIL PROTECTED] wrote:
On Thu, 29 Nov 2007, Greg KH wrote:
kobject_put(foo) is needed since it gets you through
kobject_cleanup()
where the name can be freed.
No,
On Thu, 29 Nov 2007 18:34:33 EST, Jon Masters said:
On Thu, 2007-11-29 at 21:45 +, Alan Cox wrote:
Jargon File in all its glory. And if you still think you could look for
patterns, how about executable code that self-modifies in random ways
but when executed as a whole actually has
On Fri, 30 Nov 2007 10:21:28 +0800, Zhao Yakui said:
Thanks for the acpidump dmesg.
In the acpidump there are so many IO resource definitions in the device
of mem2 and the number exceeds the predefined number(24).
On a semi-related note, I'm seeing 7 of these at each boot on a Dell
On Thu, Nov 29, 2007 at 05:11:35PM -0500, Alan Stern wrote:
On Thu, 29 Nov 2007, Greg KH wrote:
kobject_put(foo) is needed since it gets you through kobject_cleanup()
where the name can be freed.
No, kobject_register() should have handled that for us, right?
On Thu, 29 Nov 2007 23:00:47 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 30 Nov 2007 01:39:29 -0500 Kyle McMartin [EMAIL PROTECTED] wrote:
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume that we broke the
Relocate the x86_64 percpu variables to begin at zero. Then
we can directly use the x86_32 percpu operations. x86_32
offsets %fs by __per_cpu_start. x86_64 has %gs pointing
directly to the pda and the per cpu area if they start at zero.
Access to the pda with the x86_64 pda operations is still
Declare the pda as a per cpu variable. This will have the effect of moving
the pda data into the cpu area managed by cpu alloc.
The boot_pdas are only needed in head64.c so move the declaration
over there and make it static.
Remove the code that allocates special pda data structures.
The pda is
Support an option
CONFIG_PERCPU_ZERO_BASED
that makes offsets for per cpu variables start at zero.
If a percpu area starts at zero then
1. We do not need RELOC_HIDE anymore
2. Indexes off the per cpu area for each processor are small
3. The percpu area addresses are offsets and we
This patchset allows the use of x86_32 percpu ops on x86_64 while maintaining
%gs pointing to the pda. It does that by moving the x86_64 pda into
the percpu area (thereby pointing %gs at the per cpu area) and then
relocating the x86_64 per cpu variables to start at 0.
Patch applies on top of the
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume that we broke the
driver and that's never going to terminate.
how about this? doesn't break things on my pa8800:
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
Hello,
On Thu, 29 Nov 2007 15:29:49 -0800
Pallipadi, Venkatesh [EMAIL PROTECTED] wrote:
TSCs on Core 2 Duo are supposed to be in sync unless CPU supports deep idle
states like C2, C3. Can you send the full /proc/cpuinfo and full dmesg.
Sure I can...
[EMAIL PROTECTED] log]# cat
Hello,
On Fri, 30 Nov 2007 00:26:47 +0300
Michael Tokarev [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Paul Rolland (ポール・ロラン) wrote:
[]
Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to: check_tsc_sync_source failed.
[]
but I was
On Fri, 30 Nov 2007 01:39:29 -0500 Kyle McMartin [EMAIL PROTECTED] wrote:
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume that we broke the
driver and that's never going to terminate.
how about this? doesn't break
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc3 #6
---
bash/2294 is trying to acquire lock:
(journal-j_list_lock){--..}, at: [c01eee2f]
Andrew Morton wrote:
On Thu, 29 Nov 2007 23:00:47 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 30 Nov 2007 01:39:29 -0500 Kyle McMartin [EMAIL PROTECTED] wrote:
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
ten million is close enough to infinity for me to assume
Paul Rolland (ポール・ロラン) wrote:
Note that once TSC is disabled (it's using jiffies as far
as I can see), ntpd constantly speeds up and slows down the
clock, it jumps +/- 0.5sec every several minutes or hours -
I guess that's when ntpd process gets moved from one core
to another for whatever
On Nov 29, 2007 5:15 PM, Daniel Drake [EMAIL PROTECTED] wrote:
[...]
To avoid the unaligned memory access, you would rewrite it as follows:
void myfunc(u8 *data, u32 value)
{
[...]
value = cpu_to_le32(value);
put_unaligned(value,
On Fri, Nov 30, 2007 at 12:45:05AM +0100, Christian Kujau wrote:
On Sun, 25 Nov 2007, Christoph Hellwig wrote:
This patch does exactly that and reverts xfs_file_readdir to what's
basically the 2.6.23 version minus the uio and vnops junk.
Thanks, works here too (without nordirplus as a
On 30-11-2007 04:32, H. Peter Anvin wrote:
...
As far as I can tell, Documentation/Changes is the only thing we have
that even attempts to document the basic requirements. This attempts
to formalize that fact.
Documentation/Changes | 396
On Nov 29, 2007 4:40 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Albert Cahalan [EMAIL PROTECTED] writes:
On Nov 28, 2007 6:31 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Albert Cahalan [EMAIL PROTECTED] wrote:
On Nov 27, 2007 7:49 PM,
Christoph Hellwig wrote:
The current readdir implementation deadlocks on a btree buffers locks
because nfsd calls back into -lookup from the filldir callback. The
only short-term fix for this is to revert to the old inefficient
double-buffering scheme.
Probably why Steve did this: :)
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
3. Make sure usbcore doesn't probe the devices in the wrong mode with the
option driver
This fixes duplication. And to take it further, why don't we turn this
idea around and let usb-storage fail to attach with some
On Thu, Nov 29, 2007 at 00:26:47 +0100, Pavel Machek wrote:
[...]
Also, is there some documentation for wakealarm?
git show 3925a5ce44330767f7f0de5c58c6a797009f0f75 has some.
Thanks. Will put it into Doc*/rtc.txt.
It would be nice if you mention the differences to the old
Hi Vegard,
On Nov 27, 2007 5:16 PM, Vegard Nossum [EMAIL PROTECTED] wrote:
+config KMEMCHECK
+ bool Trap use of uninitialized memory
+ depends on X86_32 !CC_OPTIMIZE_FOR_SIZE
+ help
+ This option enables tracing of dynamically allocated kernel memory
+ to
Am Donnerstag, 29. November 2007 08:52:37 schrieb Pete Zaitcev:
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
The problem stems from the fact that both option and usb-storage can
bind to the modem
On Nov 29, 2007 11:03 AM, Brad Smith [EMAIL PROTECTED] wrote:
Thank you for the reply Marvel. I use the gnome bluetooth client which
Marcel
apparently does manage bluetooth devices using bluetooth-input-service.
I still have the problem of the devices disappearing if idle for too
long
Changes to previous version(s):
- moved task arrives/departs notifications to __switch_to_xtra()
- added _TIF_BTS_TRACE and _TIF_BTS_TRACE_TS to _TIF_WORK_CTXSW_*
- split _TIF_WORK_CTXSW into ~_PREV and ~_NEXT for x86_64
- ptrace_bts_init_intel() function called from init_intel()
- removed
901 - 994 of 994 matches
Mail list logo
