I'm deliberatly breaking the threading on this so that people who have
tuned out the hibernation thread can take a look at this.
below is the proposal that I made at the bottom of one of the posts on the
hibernation thread.
the idea is that instead of approaching power management from the poi
From: Al Viro <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 07:35:11 +0100
> > Crude and simple way would be to add
> >
> > config JS_RTC
> > tristate "JavaStation RTC"
> > depends on SPARC32 && PCI
> >
> >
> > in drivers/char/Kconfig, slap plain and simple !SPARC in RTC dependencies
>
On 7/22/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> [...]
> These are the patches in this series :
Ok, I've reviewed all patches in this series except:
> [PATCH][12/37] Clean up duplicate includes in drivers/net/
> [PATCH][28/37] Clean up
On Sun, Jul 22, 2007 at 07:31:49AM +0100, Al Viro wrote:
> On Sat, Jul 21, 2007 at 11:22:07PM -0700, David Miller wrote:
> > From: Al Viro <[EMAIL PROTECTED]>
> > Date: Sun, 22 Jul 2007 07:19:24 +0100
> >
> > > We probably ought to make drivers/sbus/char/rtc.c sparc32-only,
> > > then - AFAICS it
On Sat, Jul 21, 2007 at 11:22:07PM -0700, David Miller wrote:
> From: Al Viro <[EMAIL PROTECTED]>
> Date: Sun, 22 Jul 2007 07:19:24 +0100
>
> > We probably ought to make drivers/sbus/char/rtc.c sparc32-only,
> > then - AFAICS it simply won't be able to register misc device and that
> > will be it.
From: Al Viro <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 07:19:24 +0100
> We probably ought to make drivers/sbus/char/rtc.c sparc32-only,
> then - AFAICS it simply won't be able to register misc device and that
> will be it. ACK?
ACK.
> > 2) all the __sparc_v9__ crap is removed from drivers/cha
On Sat, Jul 21, 2007 at 10:54:13PM -0700, David Miller wrote:
> From: Al Viro <[EMAIL PROTECTED]>
> Date: Sun, 22 Jul 2007 06:43:56 +0100
>
> > seems to imply that CONFIG_RTC has no business whatsoever on sparc64 builds,
> > let alone in defconfig - JavaStation had never gone sparc64. OTOH, we
>
On Sun, Jul 22, 2007 at 01:50:09AM +0200, Andi Kleen wrote:
> Lars Ellenberg <[EMAIL PROTECTED]> writes:
> >
> > Jens, Andrew, anyone: please review,
> > and give me advice how to proceed from here.
>
> The standard procedure would be to post all the source code in logical
> pieces on the list fo
On Sat, 21 Jul 2007 20:26:47 +0200 Charlie Shepherd <[EMAIL PROTECTED]> wrote:
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3cee76a..5e7daea 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -72,7 +72,6 @@ void unmap_kernel_range(unsigned long addr, unsigned long
> size)
> {
> pg
From: Al Viro <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 06:43:56 +0100
> seems to imply that CONFIG_RTC has no business whatsoever on sparc64 builds,
> let alone in defconfig - JavaStation had never gone sparc64. OTOH, we
> have explicit scanning ISA bus in addition to EBUS in drivers/char/rtc.c
On Sun, Jul 22 2007, Andi Kleen wrote:
> Lars Ellenberg <[EMAIL PROTECTED]> writes:
> >
> > Jens, Andrew, anyone: please review,
> > and give me advice how to proceed from here.
>
> The standard procedure would be to post all the source code in logical
> pieces on the list for review. Then iterat
Jesper Juhl napsal(a):
> drivers/hid/usbhid/hid-core.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index b2baeae..3ff7468 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid
We have a problem - there are two rtc drivers for sparc; sbus and
ebus+isa respectively (drivers/sbus/char/rtc.c and drivers/char/rtc.c). They
can be built into the kernel at the same time just fine; one that doesn't
find the hardware will STFU and bugger off, leaving the other free to reg
On Mon, Jul 16, 2007 at 08:45:47AM +0400, Alexey Dobriyan wrote:
> On Sun, Jul 15, 2007 at 09:36:59PM -0300, Diego Woitasen wrote:
> > ---
> > include/asm-generic/bug.h | 25 +
> > 1 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/include/asm-generi
Alexey Dobriyan wrote:
> On Fri, Jul 20, 2007 at 12:37:45PM +0900, Tetsuo Handa wrote:
> > --- linux-2.6.22-orig/kernel/sysctl.c
> > +++ linux-2.6.22/kernel/sysctl.c
> > @@ -1190,9 +1190,9 @@
> > return -ENOTDIR;
> > if (get_user(n, name))
> > return -EFAULT;
> > + if
On Sunday 22 July 2007 04:30:41 Satyam Sharma wrote:
> On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > [...]
> > These are the patches in this series :
>
> Ok, I've reviewed all patches in this series except:
>
> > [PATCH][12/37] Clean up duplicate includes in drivers/net/
> > [PATCH][28
On Sunday 22 July 2007 04:30:41 Satyam Sharma wrote:
> On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > [...]
> > These are the patches in this series :
>
> Ok, I've reviewed all patches in this series except:
>
> > [PATCH][12/37] Clean up duplicate includes in drivers/net/
> > [PATCH][28
On Sunday 22 July 2007 04:30:41 you wrote:
> On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > [...]
> > These are the patches in this series :
>
> Ok, I've reviewed all patches in this series except:
>
> > [PATCH][12/37] Clean up duplicate includes in drivers/net/
> > [PATCH][28/37] Clean
On 22/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch cleans up duplicate includes in
> kernel/
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
[ Jesper, I hope yo
On Tuesday 03 July 2007 01:44, Dave Jones wrote:
> On Tue, Jul 03, 2007 at 01:22:47AM -0400, Len Brown wrote:
>
> > whelp, it seems that the reason for this patch is this:
> >
> > #define DBG()
> >
> > if(...)
> >DBG();
> > next_c_statement
> >
> > which turns into
> > if(...) ;
>
Please check the updated version to current tree.
[PATCH 2/3] x86_64: use core id bits for apicid_to_node initialization
We shoud use core id bits instead of max cores, in case later with AMD
downcores Quad core Opteron.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/mm/
Can you please try the following command line options in any
combination:
hpet=disable
nohz=off
highres=off
nolapic_timer
I've now tried running the kernel with all combinations of
hpet=disable, nolapic_timer, and clocksource=pm_timer|acpi_pm. I feel
like hpet=disable was probably unnecessary,
Hi Geert,
On Saturday 21 July 2007 04:27, Geert Uytterhoeven wrote:
> On Fri, 20 Jul 2007, Dmitry Torokhov wrote:
> >
> > I am OK with adding a new header file. I was just saying that placing
> > that declaration in linux/hid.h makes about the same sense as putting
> > it into linux/scsi.h
>
> A
On Sat, Jul 21, 2007 at 03:09:41PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > Ok, let's try again:
> >
> > You're changing this (pageattr.c)
> >
> > asm volatile("clflush (%0)" :: "r" (adr + i));
> >
> > into this:
> >
> > asm volatile("clflush %0
Theodore Tso wrote:
> On Sat, Jul 21, 2007 at 07:54:14PM +0200, Rene Herman wrote:
> > sfdisk -d already works most of the time. Not as a verbatim tool (I
> > actually semi-frequently use a "sfdisk -d /dev/hda | sfdisk" invocation
> > as a way to _rewrite_ the CHS fields to other values after chang
Please check the updated version regarding to pci_sysdata ...
hope we can add .node and iommu to pci_bus struct instead later.
Thanks
Yinghai Lu
[PATCH] x86_64: get mp_bus_to_node as early v2
In struct device, we already have numa_node member. and we can use dev_to_node()
/set_dev_node() to
Benjamin Herrenschmidt wrote:
Thus, we have two choices here:
- The simple one: sysfs_create_blah() displays a warning when it fails
and has no must_check
- The one that adds code everywhere (the current one):
sysfs_create_blah() returns an error, has much_check, and thus all
callers like I d
On Sat, 21 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
How would you prevent tasks from being scheduled? How would you
prevent drivers from deadlocking because in order to put their device
in a low-power state they need to acquire a lock which is held by a
user ta
This keeps an unstripped copy of the vDSO images built before they are
stripped and embedded in the kernel. The unstripped copies get installed
in $(MODLIB)/vdso/ by "make install". These files can be useful when they
contain source-level debugging information.
Signed-off-by: Roland McGrath <[EM
On Sun, Jul 22, 2007 at 10:39:23AM +0800, Fengguang Wu wrote:
> It makes sense to raise it beyond 128K. 1M default readahead
> absolutely makes sense for sequential workloads. For the desktop,
> this increases boot speed and readahead misses, both due to more
> aggressive mmap read-around.
On Sat, Jul 21, 2007 at 11:00:05PM +0200, Peter Zijlstra wrote:
> The various readahead bits I have lying about.
>
> Wu, would you agree with asking Andrew to stick these behind your latest
> readahead series?
They are generally good feature to have. Thank you!
- default readahead size
It makes
On Sun, 22 Jul 2007, Huang, Ying wrote:
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
Backuping target memory before kexec and restoring it after kexec is
planed feature for kexec jump. But I will work on image writing/reading
first.
if we can get a list of what memory is safe t
From: David Howells <[EMAIL PROTECTED]>
Date: Fri, 20 Jul 2007 10:53:25 +0100
> Add missing entries to af_family_clock_key_strings[].
>
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
Applied, thanks David.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
[...]
These are the patches in this series :
Ok, I've reviewed all patches in this series except:
[PATCH][12/37] Clean up duplicate includes in drivers/net/
[PATCH][28/37] Clean up duplicate includes in net/ipv4/
[PATCH][32/37] Clean up du
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 20 Jul 2007 17:41:48 +0200
> Generic LRO patch
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
I have no general objections to this patch.
However I'd like to see at least one or two uses of these APIs before
we put it in, and it s
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Fri, 20 Jul 2007 17:11:54 +0100
> On Fri, Jul 20, 2007 at 09:24:42AM -0400, Horst H. von Brand wrote:
> > When building v2.6.22-3478-g275afca on sparc64 (.config attached) I get:
> >
> > MODPOST vmlinux
> > Building modules, stage 2.
> > MOD
From: Al Viro <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 00:12:41 +0100
> same scheme as for sparc64, same rationale
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
From: Al Viro <[EMAIL PROTECTED]>
Date: Sat, 21 Jul 2007 23:29:02 +0100
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Applied, thanks Al.
-
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.k
From: Al Viro <[EMAIL PROTECTED]>
Date: Sat, 21 Jul 2007 23:28:52 +0100
>
> Move stuff used only by arch/sparc/kernel/* into arch/sparc/kernel/irq.h
> and into individual files in there (e.g. macros internal to sun4m_irq.c,
> etc.)
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Applied, thanks
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
> > Backuping target memory before kexec and restoring it after kexec is
> > planed feature for kexec jump. But I will work on image writing/reading
> > first.
>
> if we can get a list of what memory is safe to backup/restore then the
>
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Sat, 21 Jul 2007 18:27:38 +0200 (CEST)
> Enabling drivers from "Devices > Networking" (in menuconfig), for
> example SLIP and/or PLIP, throws link time errors when CONFIG_NET itself
> is =n. Have CONFIG_NETDEVICES depend on CONFIG_NET.
>
> Signed-o
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 00:23:03 +1000
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
> drivers/pcmcia/m8xx_pcmcia.c |2 +-
> include/linux/of_platform.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Built for Pow
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Sun, 22 Jul 2007 00:27:01 +1000
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
> include/linux/of_platform.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Built for PowerPC allmodconfig and ppc64_defconfig and S
On 7/21/07, Dave Jones <[EMAIL PROTECTED]> wrote:
pmu_battery fails to compile as a module on ppc64.
ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_battery_count" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undef
sorry for the long delay in testing.
On Wed, 27 Jun 2007, Randy Dunlap wrote:
[adding [EMAIL PROTECTED]
On Wed, 27 Jun 2007 00:38:17 -0700 (PDT) [EMAIL PROTECTED] wrote:
On Tue, 26 Jun 2007, Randy Dunlap wrote:
On Mon, 25 Jun 2007 15:56:17 -0700 (PDT) [EMAIL PROTECTED] wrote:
due to the
On Sun, 22 Jul 2007 10:46:54 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> As reported by Stephen Rothwell, an allmodconfig build on 64-bit
> PowerPC reports these errors:
>
> ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
> ERROR: "pmu_battery_count" [drivers/power/pmu_bat
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
Hi,
This patch cleans up duplicate includes in
kernel/
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
[ Jesper, I hope you re-built with all these changes? Some
of these duplicate #incl
On 7/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Saturday 21 July 2007 13:21:34 Yinghai Lu wrote:
> On 7/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > On Saturday 21 July 2007 09:56:15 Yinghai Lu wrote:
> > > please check my version, we should use core id bits instead.
> > >
> > > it shoul
[PATCH 3/3] x86_64: offset apicid_to_node before use it before init_cpu_to_node
When acpi=off or there is no SRAT defined, apicid_to_node is got from K8
Northbridge PCI configuration space in k8_scan_nodes() in
arch/x86_64/mm/k8toplogy.c.
The problem is that it assumes bsp apic id is 0 at that po
[PATCH 2/3] x86_64: use core id bits for apicid_to_node initialization
We shoud use core id bits instead of max cores, in case later with AMD
downcores Quad core Opteron.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
k8topology.c | 14 +-
1 files changed, 9 insertions(+), 5 deletio
Andi,
Please check the three patches about the apicid_to_node initialization
when acpi=off or srat is not defined with BIOS.
Thanks
YH
-
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.kern
[PATCH 1/3] x86_64: store core id bits in cpuinfo_x86
We need to store core id bits to cpuinfo_x86 in early_identify_cpu. So we
use it to create acpiid_to_node array in k8topolgy.c
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
arch/x86_64/kernel/setup.c | 72 +++---
As reported by Stephen Rothwell, an allmodconfig build on 64-bit
PowerPC reports these errors:
ERROR: "pmu_batteries" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_battery_count" [drivers/power/pmu_battery.ko] undefined!
ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undefined!
T
Ingo Molnar writes:
>
> * Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > static inline void ccids_read_lock(void)
> > {
> > atomic_inc(&ccids_lockct);
> > spin_unlock_wait(&ccids_lock);
> > }
> >
> > This looks racy, in theory atomic_inc() and spin_unlock_wai
On Sunday 22 July 2007 00:16, Oleg Verych wrote:
> * From: Andi Kleen <[EMAIL PROTECTED]>
> * Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
> >
> > Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> > it should generate better code than the old macro. Let's try it.
>
> Unfortu
Hi,
sorry for the late reply.
On 18.07.2007 20:22 Jan Engelhardt wrote:
> here are two more changes I propose for the isdn submenu(s).
> They go on top of Tilman's patch; each of the two following patches is
> independent of another.
> Opinions please :)
These are fine by me.
Thanks
Tilman
--
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> Can we see some stats on:
>
> How many files were auto-merged?
> How many files got 32.c and 64.c extensions?
> How many existed only in one arch?
It's mostly about file movement first.
Kbuild |8 +-
Mak
On Sat, Jul 21, 2007 at 04:28:52PM -0500, Matt Mackall wrote:
> On Fri, Jul 20, 2007 at 10:28:46AM +0900, Paul Mundt wrote:
> > Slab destructors were no longer supported after Christoph's
> > c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
> > BUGs for both slab and slub, and slob nev
On Sunday 22 July 2007 01:16:42 Oleg Verych wrote:
> * From: Andi Kleen <[EMAIL PROTECTED]>
> * Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
> >
> > Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> > it should generate better code than the old macro. Let's try it.
>
> Unfor
same scheme as for sparc64, same rationale
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/sparc/mm/init.c|3 +++
arch/sparc/mm/srmmu.c |2 +-
arch/sparc/mm/sun4c.c |2 +-
include/asm-sparc/pgtable.h |3 +--
4 files changed, 6 insertions(+), 4 deletions(-)
On Sat, 21 Jul 2007 03:31:33 -0700 Andrew Morton wrote:
> On Sat, 21 Jul 2007 00:58:01 +0200 Sebastian Siewior <[EMAIL PROTECTED]>
> wrote:
>
> > Got with randconfig
>
> randconfig apparently generates impossible configs. Please always
> run `make oldconfig' after the randconfig, then do the t
* From: Andi Kleen <[EMAIL PROTECTED]>
* Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
>
> Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> it should generate better code than the old macro. Let's try it.
Unfortunately such info is hard to find. The [EMAIL PROTECTED] list is
Lars Ellenberg <[EMAIL PROTECTED]> writes:
>
> Jens, Andrew, anyone: please review,
> and give me advice how to proceed from here.
The standard procedure would be to post all the source code in logical
pieces on the list for review. Then iterate until all comments are addressed.
-Andi
-
To unsu
On Sat, Jul 21, 2007 at 05:03:29PM +0200, Jesper Juhl wrote:
> Hi,
>
> This patch cleans up duplicate includes in
> kernel/
Changes to kernel/rcupdate.c and kernel/rcutorture.c:
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
> diff
On Sat, Jul 21, 2007 at 11:17:43PM +0200, Jan Engelhardt wrote:
>
> On Jul 21 2007 22:38, Lars Ellenberg wrote:
> >
> >We implement shared-disk semantics in a shared-nothing cluster.
>
> If nothing is shared, the disk is not shared, but got shared-disk
> semantics? A little confusing.
Think of i
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.
As for the 9p code it doesn't seem to need or wan
Hi ,
I noticed this warnings on current git:
...
drivers/hwmon/pc87360.c:1082: warning: 'pc87360_remove' defined but not used
drivers/hwmon/sis5595.c:580: warning: 'sis5595_remove' defined but not used
drivers/hwmon/smsc47m1.c:608: warning: 'smsc47m1_remove' defined but not used
drivers/hwmon/vi
Now that the last inlined instances are gone, all that is left to do
is turning disable_irq_nosync on arm26 and m68k from defines to aliases
and we are all set - we can make these externs in linux/interrupt.h
uncoditional and kill remaining instances in asm/irq.h
Signed-off-by: Al Viro <[EMAIL PR
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/sparc/kernel/irq.c | 25 ++---
arch/sparc/kernel/irq.h | 20
arch/sparc/kernel/sparc_ksyms.c |2 --
arch/sparc/kernel/sun4d_irq.c |4 ++--
arch/sparc/kernel/tick14.c |
Move stuff used only by arch/sparc/kernel/* into arch/sparc/kernel/irq.h
and into individual files in there (e.g. macros internal to sun4m_irq.c,
etc.)
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/sparc/kernel/irq.c |2 +
arch/sparc/kernel/irq.h | 48 ++
arch
commit 36d139ccebba6a1082b743fbedb53c5a5097987c
Author: Mark Hindley <[EMAIL PROTECTED]>
Date: Sat Jul 21 22:56:08 2007 +0100
Check return of pci_enable_device in vortex_up().
Signed-off-by: Mark Hindley <[EMAIL PROTECTED]>
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
ind
On Sun, Jul 22, 2007 at 12:13:26AM +0200, Sam Ravnborg wrote:
> On Sun, Jul 22, 2007 at 12:16:27AM +0200, Oleg Verych wrote:
> >
> > What do you think about this one? I want to propose to remove
> > scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
> > sections in header file
On Sat, Jul 21, 2007 at 12:32:59AM +0200, Thomas Gleixner wrote:
> How is the new arch/x86 and include/asm-x86 namespace layed out? Our
> foremost concern was to enable a 100% smooth transition to the new,
> shared architecture, while still enabling much more fine-grained future
> unification of
H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
>> Ok, let's try again:
>>
>> You're changing this (pageattr.c)
>>
>> asm volatile("clflush (%0)" :: "r" (adr + i));
>>
>> into this:
>>
>> asm volatile("clflush %0" : "+m" (*(char __force*)(adr + i)));
>>
>> The original o
Hi,
If, in usb_hid_configure(), we fail to allocate storage for 'usbhid',
"if (!(usbhid = kzalloc(sizeof(struct usbhid_device), GFP_KERNEL)))",
then we'll jump to the 'fail:' label where we have this code:
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbout);
usb_fr
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> It seems that you could still potentially get a failure to freeze if one
> FUSE process depends on another, and the one that is frozen second just
> happens to be waiting on the one that is frozen first when it is frozen.
> I admit
Hi.
On Sunday 22 July 2007 04:12:22 Miklos Szeredi wrote:
> > It seems that you could still potentially get a failure to freeze if one
> > FUSE process depends on another, and the one that is frozen second just
> > happens to be waiting on the one that is frozen first when it is frozen.
> > I admi
On Sat, 21 Jul 2007, Mike Frysinger wrote:
> On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote:
> > > On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > > >I would much more prefer this functionality to be integrated into
>
On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
On Sat, Jul 21, 2007 at 10:39:16PM +0200, Sam Ravnborg wrote:
> On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
[]
> > while you could try and make a claim against memory/cpu effeciency, i
> > fail to see how the first or last cla
On Sat, 21 Jul 2007, Pavel Machek wrote:
So it will be break at least battery status and "AC plugged in"
status, because those are handled by ACPI and we do not know how to
control them by hand.
It seems that it should be possible to initialize ACPI as if the system
just booted up normally. T
* From: Alan Cox
* Date: Sat, 21 Jul 2007 00:55:12 +0100
* Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
Lloegr o'r rhif cofrestru 3798903
>
> On Fri, 20 Jul 2007 18:38:39 -0400
> Jeff Garzik <[EMAI
On Sun, Jul 22, 2007 at 12:16:27AM +0200, Oleg Verych wrote:
>
> What do you think about this one? I want to propose to remove
> scripts/unifdef.c but to make clear policy about how to mark __KERNEL__
> sections in header files. We know how obfuscated C can be, and this also
> applies to preproces
On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote:
> On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >I would much more prefer this functionality to be integrated into unifdef.
> >There is no good reason to have two different
Hi,
I noticed this warnings on current git:
...
arch/i386/mach-voyager/voyager_thread.c: In function 'thread':
arch/i386/mach-voyager/voyager_thread.c:113: warning: no return statement in
function returning non-void
...
I think return 0; is missing on line 112 here.
...
arch/i386/mach-voy
Hi,
As with -rt3, I was able to capture one more crash trace, via serial
console, with nmi_watchdog=1.
Yes, current 2.6.22.1-rt4 is still locking-up on my ix86 SMT/SMP boxes.
I'll have to wait for some hours of uptime and normal desktop use and
then it just locks-up without warning.
Last couple
On Sat, 2007-07-21 at 17:02 +0200, Jesper Juhl wrote:
> Hi,
>
> This patch cleans up duplicate includes in
> drivers/macintosh/
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/macintosh/rack-meter.c
Muli Ben-Yehuda wrote:
>
> Ok, let's try again:
>
> You're changing this (pageattr.c)
>
> asm volatile("clflush (%0)" :: "r" (adr + i));
>
> into this:
>
> asm volatile("clflush %0" : "+m" (*(char __force*)(adr + i)));
>
> The original one calls clflush with (adr
On Sat, Jul 21, 2007 at 06:03:00PM -0400, Mike Frysinger wrote:
> On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
> >> On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> >> >On Sat, Jul 21, 2007 at 04:27:31AM -0400, Mike Frysi
On Sat, 2007-07-21 at 14:27 -0700, David Schwartz wrote:
> > On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > > v & 0x0F <=> v % 16
> > Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
>
> Actually, it's the compiler's bad. That's a pretty fundamental equivalence
> tha
On Sat, Jul 21, 2007 at 10:39:16PM +0200, Sam Ravnborg wrote:
> On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
[]
> > while you could try and make a claim against memory/cpu effeciency, i
> > fail to see how the first or last claims could possibly be backed up
Less \{\(\\n\t\+\)\}
On 7/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
On Sat, Jul 21, 2007 at 03:21:43PM -0400, Mike Frysinger wrote:
> On 7/21/07, Oleg Verych <[EMAIL PROTECTED]> wrote:
> >On Sat, Jul 21, 2007 at 04:27:31AM -0400, Mike Frysinger wrote:
> >[]
> >> if you want to make some micro optimization in the
Krzysztof Halasa wrote:
> Stefan Richter <[EMAIL PROTECTED]> writes:
>
>> The latter is sometimes hard or impossible to satisfy. Therefore the
>> select statement should be used with care, i.e. only for library-type
>> helper code which itself shouldn't depend on further options.
>
> How about d
On Sun, 22 Jul 2007 00:57:09 +0400 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 21, 2007 at 12:53:19PM -0600, Eric W. Biederman wrote:
> > The recent 9p commit: bd238fb431f31989898423c8b6496bc8c4204a86
> > that supposedly only moved files also introduced a new 9p sysctl
> > interface t
On Saturday 21 July 2007, Rodolfo Giometti wrote:
> I reworked the driver according to latest suggestions from you.
... except for the most important one, which is to remove the
requirement to change every part of the gadget driver stack to
work around quirks in that particular hardware!!
I hope
On 21/07/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
DRBD wants to go mainline.
please have a look at the "for-linus" branch of
git://git.drbd.org/home/git/linux-drbd.git.
I just fetched yourt branch and had a (very) quick look.
Some comments.
Try running your patc
At least on my hardware, the cfs in 2.6.22-git13 runs as smoothly as the
perfect smoothness of cfs-v13, with two tuning changes:
sched_stat_granularity_ns = 100
sched_features = 14
The change in "features" made a major improvement.
Having identified the cause of the better smoothness in t
On Fri, Jul 20, 2007 at 10:28:46AM +0900, Paul Mundt wrote:
> Slab destructors were no longer supported after Christoph's
> c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
> BUGs for both slab and slub, and slob never supported them
> either.
SLOB of course did support destructors, o
On Sat, 2007-21-07 at 23:00 +0200, Peter Zijlstra wrote:
> plain text document attachment (readahead-useonce.patch)
> Use the read-ahead code to provide hints to page reclaim.
>
> This patch has the potential to solve the streaming-IO trashes my
> desktop problem.
>
> It tries to aggressively rec
> On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > v & 0x0F <=> v % 16
> Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Actually, it's the compiler's bad. That's a pretty fundamental equivalence that
the compiler should recognize for native integral types.
DS
-
T
Stefan Richter <[EMAIL PROTECTED]> writes:
> The latter is sometimes hard or impossible to satisfy. Therefore the
> select statement should be used with care, i.e. only for library-type
> helper code which itself shouldn't depend on further options.
How about depending on common dependency?
Som
1 - 100 of 313 matches
Mail list logo
