On Thursday 17 January 2008, David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
>
> > We spent Wednesday trying to reproduce (without the patch) these issues
> > without much luck, and have applied the patch cleanly and will continue
> > testing it. Given the simplicity of the cha
From: Zhang Rui <[EMAIL PROTECTED]>
Register ACPI Fan as thermal cooling device.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/acpi/fan.c | 90 -
1 file changed, 83 insertions(+), 7
From: Zhang Rui <[EMAIL PROTECTED]>
Change the ACPI thermal action upon notification 0x81 and 0x82.
According to the ACPI spec, we should:
re-evaluate _PSV and _ACx methods upon notification 0x81
re-evaluate _PSL and _ALx and _TZD upon notificaiton 0x82.
But the current code re-evaluates all the
From: Zhang Rui <[EMAIL PROTECTED]>
Register ACPI video device as thermal cooling devices as they may be listed
in _TZD method and the backlight control can be used for throttling.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/acpi/vide
From: Zhang Rui <[EMAIL PROTECTED]>
Register ACPI processor as thermal cooling devices.
A combination of processor T-state and P-state are used for thermal throttling.
the processor will reduce the frequency first and then set the T-state.
we use cpufreq_thermal_reduction_pctg to calculate the cp
From: Zhang Rui <[EMAIL PROTECTED]>
Fix an imprecision in CELSIUS_TO_KELVIN and move these
two macroes to a proper place.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/acpi/thermal.c |3 ---
include/linux/thermal.h |4
2 f
From: Zhang Rui <[EMAIL PROTECTED]>
Intel menlow driver needs to get the pointer of themal_zone_device
structure of an ACPI thermal zone.
Attach this to each ACPI thermal zone device object.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers
From: Thomas Sujith <[EMAIL PROTECTED]>
Intel menlow platform specific driver for thermal management.
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
---
drivers/misc/Kconfig| 10
drivers/misc/Makefile |1
drivers/misc/intel_men
From: Zhang Rui <[EMAIL PROTECTED]>
The alias name may be used in _PSL, _ALx and _TZD,
so we bind the cooling device only if the acpi_device node matches.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
drivers/acpi/thermal.c | 42 +
From: Zhang Rui <[EMAIL PROTECTED]>
Register ACPI thermal zone as thermal zone device.
the new sys I/F for ACPI thermal zone will be like this:
/sys/class/thermal:
|thermal_zone1:
|-type: "ACPI thermal zone". RO
|-temp: the current
From: Zhang Rui <[EMAIL PROTECTED]>
The Generic Thermal sysfs driver for thermal management.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
Signed-off-by: Thomas Sujith <[EMAIL PROTECTED]>
---
Documentation/thermal/sysfs-api.txt | 247
drivers/Kconfig |2
dri
Hi, all,
This patch series introduces a new generic thermal sysfs driver
which provides a set of interfaces for thermal zone devices (sensors)
and thermal cooling devices (fan, processor...) to register with the
thermal management solution and to be a part of it.
And it also includes the implemen
On Jan 15, 2008 22:05 -0500, Rik van Riel wrote:
> With a filesystem that is compartmentalized and checksums metadata,
> I believe that an online fsck is absolutely worth having.
>
> Instead of the filesystem resorting to mounting the whole volume
> read-only on certain errors, part of the filesy
From: Márton Németh <[EMAIL PROTECTED]>
Add leading zeros to pr_debug() calls. For example if x=0x0a, the format
"0x%2x" will result the string "0x a", the format "0x%2.2x" will result "0x0a".
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
--- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 200
From: Márton Németh <[EMAIL PROTECTED]>
The "DEBUG" symbol needs to be defined before #including to
get the pr_debug() working.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
---
--- linux-2.6.24-rc8/drivers/acpi/ec.c.orig 2008-01-16 07:25:33.0
+0100
+++ linux-2.6.24-rc8/drivers/a
On Jan 17, 2008 7:06 AM, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, Jan 16, 2008 at 09:02:05AM +0800, Dave Young wrote:
>
> > The rfcomm tty device will possibly retain even when conn is down,
> > and sysfs doesn't support zombie device moving, so this patch
> > move the tty device b
From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 23:09:47 -0800
> We spent Wednesday trying to reproduce (without the patch) these issues
> without much luck, and have applied the patch cleanly and will continue
> testing it. Given the simplicity of the changes, and the commun
David Miller wrote:
> From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or interrupt
>> rescheduling based on the return value fr
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
kernel/irq/manage.c |7 +++
1 file changed, 3
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> I refactored the paravirt.h mmu_ops patch into a number of smaller
> ones.
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been
Hi
> If that is indeed the source of your change_bit function then there is
> a problem. However in my kernel tree there is a LOCK_PREFIX in the
> definition of the atomic version. I don't have your exact source tree
> handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
>
> stat
> Then, I think there is a problem with the function written below which is
> meant to be atomic.
>
> static __inline__ void change_bit(int nr, volatile void * addr)
> {
> __asm__ __volatile__(
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir"
On Wed, Jan 16, 2008 at 11:57:54PM +0100, Jan Engelhardt wrote:
>
> On Jan 16 2008 17:20, Kyle McMartin wrote:
> >On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote:
> >> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760
> >> commit
> >
> >^- did
Thanks for the reply John.
Then, I think there is a problem with the function written below which is meant
to be atomic.
static __inline__ void change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
"btcl %1,%0"
:"=m" (ADDR)
:"Ir
Not sure where to begin so here goes anway. Today I did an rsync backup
of a server with 2million+ files. Before doing so the used memory on the
server this was initiated from was under 200meg (excluding buffers and
cache). During the rsync the memory used grew to just shy of 1.6gig and
now, about
On Thursday 17 January 2008 06:58, Dave Kleikamp wrote:
> On Wed, 2007-12-12 at 16:40 +1100, Nick Piggin wrote:
> > On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
> > > On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
> > > > Anyway, I am hoping that someone will one day and test if
Alan Cox wrote:
>> If the hardware required an intermediate junk I/O, that would be a
>> reason to do one, but it doesn't, does it? It requires a delay. It's
>> written thus in all of the application notes.
>>
>
> And the only instruction that is synchronized to the bus in question is
> an I
So I take everyone's latest and greatest product and injudiciously type the
above command. The result five minutes later is at
http://userweb.kernel.org/~akpm/borkage.jpg. See if you can count all the bugs.
Sorry, but I've had it with this stuff and I'm tired of fixing everyone else's
stuff. I
In message <[EMAIL PROTECTED]>, Al Viro writes:
> After grep for locking-related things:
[...]
Thanks. I'll start looking at these issues asap.
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
After grep for locking-related things:
* lock_parent(): who said that you won't get dentry moved
before managing to grab i_mutex on parent? While we are at it,
who said that you won't get dentry moved between fetching d_parent
and doing dget()? In that case parent could've been _freed_ b
Pravin Nanaware wrote:
Hi,
I was just going through the include file in the /usr/include/asm/bitops.h
The function description describes it as non-atomic but it seems it is not.
static __inline__ void __change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
Hi,
I was just going through the include file in the /usr/include/asm/bitops.h
The function description describes it as non-atomic but it seems it is not.
static __inline__ void __change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
"btcl %1,%0"
On Jan 16, 2008 8:27 PM, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
>
Up and running fine here:
[EMAIL PROTECTED] ~ $ uname -a
Linux lightning 2.6.24-rc8-rt1 #
On Thu, Jan 17, 2008 at 11:16:00AM +0800, Fengguang Wu wrote:
> On Thu, Jan 17, 2008 at 09:35:10AM +1100, David Chinner wrote:
> > On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote:
> > > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> > > > > Then to do better ordering
Serge:
> Right, but one will be preferred by the community - and while I have my
> own preference, I wouldn't put too much faith on that, rather talk with
> the apparmor folks, look over the lkml logs for previous submissions,
> and then decide.
Thanks for your advice.
We got the same advice from [
On Wed, Jan 16, 2008 at 03:27:41PM +0100, markus reichelt wrote:
> * Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote:
>
> > It contains a single fix for a problem that could cause a local
> > user to cause file system corruption on some types of filesystems.
>
> Some types of filesystems? Which ones
We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
Changes since 2.6.24-rc7-rt3
- ported to 2.6.24-rc8
- PPC bootup
On Wed, Jan 16, 2008 at 07:13:07PM +1100, David Chinner wrote:
> On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote:
> > Redirtied inodes could be seen in really fast writes.
> > They should really be synced as soon as possible.
> >
> > redirty_tail() could delay the inode for up to 30s.
On Wed, Jan 16, 2008 at 04:23:13PM +0900, Tejun Heo wrote:
> The two posted patches are bug fixes for apparent bugs which can be
> triggered by the current two users of the interface. AFAICS, locking
> there is weird but correct for the current two users. If you can find
> any problem there, ple
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers writes:
>
> > Sorry for self-reply, but I thought, in the past, of a way to make this
> > possible.
> >
> > It would imply the creation of a new vsyscall : vgetschedperiod
> >
> > It would read a counter that would increment each ti
On Wed, Jan 16, 2008 at 07:23:40AM -0700, Jonathan Corbet wrote:
> Hi, Pavel,
>
> [Adding Ulrich]
>
> > I use the last bit in the clone_flags for CLONE_LONGARG. When set it
> > will denote that the child_tidptr is not a pointer to a tid storage,
> > but the pointer to the struct long_clone_struct
On Thu, 17 Jan 2008, Paul Mackerras wrote:
>
> It's very hard to do a per-thread counter in the VDSO, since threads
> in the same process see the same memory, by definition. You'd have to
> have an array of counters and have some way for each thread to know
> which entry to read. Also you'd have
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt <[EMAIL PROTECTED]>
> wrote:
>
> >
> > On Jan 17 2008 00:43, Karel Zak wrote:
> > >>
> > >> Seems like a plain bad idea to me. There will be any number of home-made
> > >> /
On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote:
> The alternative (and completely safe) solution is to add another file
> to proc. Me no likey.
Since we need saner layout, I would strongly suggest exactly that.
> major:minor -- is the major minor number of the device hosting the
On Wed, Jan 16, 2008 at 10:55:28AM -0800, Michael Rubin wrote:
> On Jan 15, 2008 7:01 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > Basically I think rbtree is an overkill to do time based ordering.
> > Sorry, Michael. But s_dirty would be enough for that. Plus, s_more_io
> > provides fair queuin
Harvey Harrison wrote:
Casting to (void *) and using %p is probably your best bet. That's what
it really is anyway.
Note: in the kernel right now, %p doesn't have the leading 0x prefix,
which it probably should...
Well, that won't exactly be the nicest looking solution in places, maybe
a
On Wed, 16 Jan 2008, Luotao Fu wrote:
>
> I found out that the tracer got stuck on ppc32 platforms because some early
> functions call _mcount before mcount_enabled is initialized at all. I made a
> patch, which marks these functions as notrace to solve this problem. With this
> patch I can succe
Hi Daniel
> > Thank you for good point out!
> > Could you please post your test program and reproduced method?
>
> Sure:
>
> 1. Fill almost all available memory with page cache in a system without swap.
> 2. Run attached alloc-test program.
> 3. Notification fires when page cache is reclaimed.
Hi
> > One thing you could also try is to pass MAP_POPULATE to mmap so that the
> > page tables are filled in at the time of the mmap, avoiding a lot of
> > page faults later.
> >
>
> OK, I will test your idea and report about tomorrow.
> but I don't think page fault is major performance impac
On Wed, 2008-01-16 at 22:11 -0500, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > On Wed, 2008-01-16 at 23:27 +0100, Andi Kleen wrote:
> >> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> >>
> >> ---
> >> arch/x86/mm/fault_32.c |2 +-
> >
> > Could use exactly the same in fault_64.c
> >
>
Mathieu Desnoyers writes:
> Sorry for self-reply, but I thought, in the past, of a way to make this
> possible.
>
> It would imply the creation of a new vsyscall : vgetschedperiod
>
> It would read a counter that would increment each time the thread is
> scheduled out (or in). It would be a per
Harvey Harrison wrote:
On Wed, 2008-01-16 at 23:27 +0100, Andi Kleen wrote:
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/fault_32.c |2 +-
Could use exactly the same in fault_64.c
#ifdef CONFIG_X86_32
- "%s%s[%d]: segfault at %08lx ip %08lx sp %08
On Thu, Jan 17, 2008 at 09:35:10AM +1100, David Chinner wrote:
> On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote:
> > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> > > > Then to do better ordering by adopting radix tree(or rbtree
> > > > if radix tree is not enough),
On Saturday 12 January 2008 15:35:27 rmingming wrote:
> Hi,
> I have a problem about the try_module_get function, I don't know if
> someone removed the module just AFTER line 372, then what happens? Because
> in this situation, the variable module will be incorrect, and
> module_is_live function w
Hi
> > I'd read mem_notify as "tell me when new memory is unplugged" or
> > something. /dev/oom_notify? Plus, /dev/ names usually do not have "_"
> > in them.
>
> I don't think we should use oom in the name, since the notification is
> sent long before oom.
OK, I don't change name.
Of cource, I
Andrew Morton wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
There is a lot of precedent for adding fields at the end. Since the
last fields in current /proc/*/mounts are dummy fields anyway, it
doesn't
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> It would imply the creation of a new vsyscall : vgetschedperiod
>
> It would read a counter that would increment each time the thread is
> scheduled out (or in). It would be a per thread counter (not a per cpu
> counter) so we can deal appropriately
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * john stultz ([EMAIL PROTECTED]) wrote:
> >
> > On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> > > Thanks John for doing this!
> > >
> > > (comments imbedded)
> > >
> > > On Wed, 16 Jan 2008, john stultz wrote:
> > > > + int num
On Wed, 2008-01-16 at 23:27 +0100, Andi Kleen wrote:
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
> arch/x86/mm/fault_32.c |2 +-
Could use exactly the same in fault_64.c
> #ifdef CONFIG_X86_32
> - "%s%s[%d]: segfault at %08lx ip %08lx sp %08lx error
> %lx\n"
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > Yep. clocksource_get_cycles() ended up not being as useful as an helper
> > function (I was hoping the arch vsyscall implementations could use it,
> > but they've done too much optimization - although that may reflect a
> > need up the chain to
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> > Thanks John for doing this!
> >
> > (comments imbedded)
> >
> > On Wed, 16 Jan 2008, john stultz wrote:
> > > + int num = !cs->base_num;
> > > + cycle_t offset = (now - cs->base[!num].cycle_
* john stultz ([EMAIL PROTECTED]) wrote:
> On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> > I would disable preemption in clocksource_get_basecycles. We would not
> > want to be scheduled out while we hold a pointer to the old array
> > element.
> >
> > > + int num = cs->base_num;
>
Remove duplicate __pmd/pmd_val functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/in
Rearrange the various pagetable mmu_ops to remove duplication.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/
Remove duplicate set_pte* operations. PAE still needs to have special
variants of some of these because it can't atomically update a 64-bit
pte, so there's still some duplication.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 116 ++-
Remove duplicate __pgd/pgd_val functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 50
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravir
Hi Ingo,
I refactored the paravirt.h mmu_ops patch into a number of smaller ones.
Thanks,
J
--
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
Remove duplicate set_pmd()s.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/incl
Remove duplicate __pte/pte_val functions.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 48
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravir
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/page.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h
--- a/include/asm-x86/page.h
+++ b/include/asm-x86/page.h
@@ -91,6 +91,11 @@ static inline pudval_t na
Remove duplicate set_pud()s.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.
On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> Thanks John for doing this!
>
> (comments imbedded)
>
> On Wed, 16 Jan 2008, john stultz wrote:
> > + int num = !cs->base_num;
> > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
> > + offset &= cs->mask;
> > + cs->bas
Thomas, can you look at this. He's getting APIC errors on bootup. I'm
wondering if this isn't another strange anomaly of this controller.
He also states that he doesn't get this with the non-rt kernel.
>
> -rt3 on top of 2.6.24-rc8 works fine without that sysfs problem (acpi warnings
> still the
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> > * john stultz ([EMAIL PROTECTED]) wrote:
> > >
> > > On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
> > > > On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> I would disable preemption in clocksource_get_basecycles. We would not
> want to be scheduled out while we hold a pointer to the old array
> element.
>
> > + int num = cs->base_num;
>
> Since you deal with base_num in a shared manner
On Wednesday 16 January 2008 22:06:46 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > truly stuck, or just an annoying message?
> >
> > Just annoying message; system works after that for simple login etc.
> > (haven't run anything complicated)
>
> ok, if you see no other
On Wed, 2008-01-16 at 20:29 -0500, Steven Rostedt wrote:
> On Wed, 16 Jan 2008, Frank Rowand wrote:
>
> >
> > time/Kconfig added by preempt-realtime-mips.patch duplicates other entry,
> > resulting in kernel make error:
> >
> > Signed-off-by: Frank Rowand <[EMAIL PROTECTED]>
> > ---
> > arch/mip
On Tue, 15 Jan 2008, Mariusz Kozlowski wrote:
> Ok. It works.
>
> I found this in dmesg:
>
> BUG: swapper:0 task might have lost a preemption check!
> Pid: 0, comm: swapper Not tainted 2.6.24-rc7-rt2 #3
> [] show_trace_log_lvl+0x1d/0x3b
> [] show_trace+0x12/0x14
> [] dump_stack+0x6a/0x70
> []
On Jan 16, 2008 2:06 PM, Bryan Henderson <[EMAIL PROTECTED]> wrote:
> >The "disk motor as a generator" tale may not be purely folklore. When
> >an IDE drive is not in writeback mode, something special needs to done
> >to ensure the last write to media is not a scribble.
>
> No it doesn't. The las
Mathieu Desnoyers wrote:
> * Li Zefan ([EMAIL PROTECTED]) wrote:
>> This reverts commit e1265205c0ee3919c3f2c750662630154c8faab2.
>>
>> It's a duplicate commit of commit 74beb9db77930be476b267ec8518a642f39a04bf,
>> resulting in a duplicate section.
>>
>> Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
* Li Zefan ([EMAIL PROTECTED]) wrote:
> This reverts commit e1265205c0ee3919c3f2c750662630154c8faab2.
>
> It's a duplicate commit of commit 74beb9db77930be476b267ec8518a642f39a04bf,
> resulting in a duplicate section.
>
> Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
>
Thanks, I guess it's been m
This reverts commit e1265205c0ee3919c3f2c750662630154c8faab2.
It's a duplicate commit of commit 74beb9db77930be476b267ec8518a642f39a04bf,
resulting in a duplicate section.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
Documentation/local_ops.txt | 23 ---
1 files changed
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
>
> On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > > + int num = !cs->base_num;
> > > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
> >
> > !0 is not necessarily 1.
>
> Incorrect.
>
Hrm, *digging in my mailbox*, ah, here it is
On Wed, 16 Jan 2008, Frank Rowand wrote:
>
> time/Kconfig added by preempt-realtime-mips.patch duplicates other entry,
> resulting in kernel make error:
>
> Signed-off-by: Frank Rowand <[EMAIL PROTECTED]>
> ---
> arch/mips/Kconfig |2 0 + 2 - 0 !
> 1 files changed, 2 deletions(-)
On Wed, Jan 16, 2008 at 11:57:57PM +, Adrian McMenamin wrote:
>
> On Mon, 2008-01-14 at 23:17 +, Adrian McMenamin wrote:
> > On Mon, 2008-01-14 at 23:00 +, Adrian McMenamin wrote:
> > > From: Adrian McMenamin <[EMAIL PROTECTED]>
> > >
> > > This patch adds support for the GD-Rom driv
On Jan 16, 2008 11:27 PM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jan 2008, Dave Young wrote:
>
> > The lockdep warining was posted in the below thread, actually, I have
> > built and run this patced kernel for several days, there's no more
> > warnings.
> > http://lkml.org/lkml/2008/1/3
On Jan 16, 2008 4:34 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 16, 2008 at 09:03:03AM +0800, Dave Young wrote:
> ...
> > The lockdep warining was posted in the below thread, actually, I have
> > built and run this patced kernel for several days, there's no more
> > warnings.
> >
On Wed, 16 Jan 2008 19:10:00 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:
> Powerpc uses the generic report_bug() from lib/bug.c to report
> warnings, and I'm guessing other arches do as well.
>
> Add the module list as well as the end-of-trace marker to the output.
> This required making prin
On Jan 17 2008 11:33, Neil Brown wrote:
>On Thursday January 17, [EMAIL PROTECTED] wrote:
>>
>> On Jan 17 2008 00:43, Karel Zak wrote:
>> >>
>> >> Seems like a plain bad idea to me. There will be any number of home-made
>> >> /proc/mounts parsers and we don't know what they do.
>> >
>> > So, le
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
>
> > + int num = !cs->base_num;
> > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
>
> !0 is not necessarily 1.
Incorrect.
!0 _is_ necessarily 1. It's how all C logical operators work. If you find
a compiler that turns !x into any
Jeff Garzik wrote:
..
Thus, the "SX4 challenge" is a challenge to developers to figure out the
most optimal configuration for this hardware, given the existing MD and
DM work going on.
..
This sort of RAID optimization hardware is not unique to the SX4,
so hopefully we can work out a way to ta
Thomas,
If you send me a checkpatch.pl clean version, I'll apply it for 2.6.25.
Also, how is the dynamic allocation of pnp resources coming along?
We'll be wanting to do that on day1 of 2.6.25 integration window.
thanks,
-Len
> I don't know how many externally built drivers, which are making use
Powerpc uses the generic report_bug() from lib/bug.c to report warnings,
and I'm guessing other arches do as well.
Add the module list as well as the end-of-trace marker to the output. This
required making print_oops_end_marker() nonstatic.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
dif
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than just
doing a compare and branch.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
http://bugzilla.kernel.org/show_bug.cgi?id=2645
Changes for updating the ctime and mtime fields for memory-mapped files:
1) a new flag triggering update of the inode data;
2) a new field in the address_space structure for saving modification time;
3) a new helper function to update ctime and mtim
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
---
include/asm-alpha/bug.h |1 -
include/asm-arm/bug.h |1 -
in
Substantial code cleanup of the sys_msync() function:
1) using the PAGE_ALIGN() macro instead of "manual" alignment;
2) improved readability of the loop traversing the process memory regions.
Signed-off-by: Anton Salikhmetov <[EMAIL PROTECTED]>
---
mm/msync.c | 74 +
This is the fifth version of my solution for the bug #2645:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
New since the previous version:
1) the case of retouching an already-dirty page pointed out
by Miklos Szeredi has been correctly addressed;
2) a few cosmetic changes according to the l
Promise just gave permission to post the docs for their PDC20621 (i.e.
SX4) hardware:
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-1.2.pdf.bz2
joining the existing PDC20621 DIMM and PLL docs:
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-dimm-1.6.pdf.bz2
http://g
1 - 100 of 497 matches
Mail list logo
