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);
>
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 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:
> >> >>
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc3 #6
---
bash/2294 is trying to acquire lock:
(>j_list_lock){--..}, at: []
journal_try_to_free_buffers+0x76/0x10c
but task
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
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 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
>
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 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
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?
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.
> []
>
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
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 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,
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 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
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
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 ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page:
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
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
> >
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:
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,
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
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,
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:
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.
> >
>
>
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_
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
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 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
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
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 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
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 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
>
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
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
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
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
>
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 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
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
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
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
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
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
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
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
>
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
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]
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,
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
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
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
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
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 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
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
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
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
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
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 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
>>
>> -/* 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,
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:
> > >
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
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
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 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:
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:
* 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
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
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
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
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
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
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:
> > []
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
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?
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
On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
> Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
>
> The test case below, taken from the LTP test code, prints -1 (as
> expected) on 2.6.22 and 0 on 2.6.23. It tries to remap an out-of-range
> page. Proposed patch
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 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.
>
Okay, no problem, I am just curious.
> > by the way, and OT, did the
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Paul
>Rolland (???・???)
>Sent: Thursday, November 29, 2007 8:12 AM
>To: Linux Kernel
>Cc: [EMAIL PROTECTED]
>Subject: constant_tsc and TSC unstable
>
>Hello,
>
>I've a machine with a Core2Duo CPU.
Am Donnerstag, 29. November 2007 19:53:39 schrieb Jaime Velasco Juan:
> Hi,
>
> El jue. 29 de nov. de 2007, a las 15:05:50 +0100, Johann Wilhelm escribió:
> > If everything's working please also add code to also support the other
> > E220 device... so both PID 0x1003 and 0x1004 should be treaded
On Fri, Nov 30, 2007 at 12:02:32AM +0530, Ciju Rajan K wrote:
> I tested your patch. But that is not solving the problem.
> If the code change to user_shm_lock() is not a good solution, could
> you please suggest a method so that the normal user is able to allocate
> the huge pages, if his
On Thu, 29 Nov 2007, Alan Stern wrote:
>
> Yes indeed. I wish I could point you to the exact patch containing the
> fix, but the git software seems to have lost track of it (it's combined
> in with a large number of other patches with no obvious way to separate
> it out). It's also
Hi,
We've developed a driver for an image acquisition card, which maps
kernel alloc'ed buffers into user space vma's. We use alloc_page +
remap_pfn_range in the driver mmap file_operation.
After looking at alloc_page_vma, I thought that it might be more
appropiate than alloc_page in this
On Friday November 30, [EMAIL PROTECTED] wrote:
> On Fri, Nov 30, 2007 at 09:07:06AM +1100, Neil Brown wrote:
> >
> > Hi David,
> >
> > On Friday November 30, [EMAIL PROTECTED] wrote:
> > >
> > >
> > > I came across this because I've been making changes to XFS to avoid the
> > > inode hash,
On 11/29/2007 04:50 PM, Roland McGrath wrote:
> Jan Kratochvil has helped me a great deal with ptrace testing lately.
> We have started to collect a small regression test suite, see
> http://sourceware.org/systemtap/wiki/utrace/tests for pointers. That
> has tests for individual problems that
On 11/29/2007 05:21 PM, Roland McGrath wrote:
>>> case offsetof(struct user32, regs.gs):
>>> *val = child->thread.gsindex;
>>> + if (child == current)
>>> + asm("movl %%gs,%0" : "=r" (*val));
>> Won't this return the kernel's GS instead of the user's?
>
Bjoern Olausson wrote:
> On 11/7/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Thanks. We're currently trying to find out what's actually going on
>> with all these drives. At first, drives which got blacklisted aren't
>> many and made sense (had other problems with NCQ, etc..) but with new
>>
Alan Cox <[EMAIL PROTECTED]> writes:
>
> The simple case is
> open
> write cathedral and bazaar in some order
> close
>process -> label eric_t>
>
> open (eric_t) - SELinux "no"
>
>
> Anyone smart will then write it out of order and keep the file open, or
That would
1 - 100 of 994 matches
Mail list logo
