Power Management framework proposal

[david]

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 point of 
view of the current desktop standard (ACPI), instead this approaches it 
from the point of view of 'what does a tool need to know to do the job' no 
matter what mechanism is actually used to implement the different modes.


one thing that I didn't put in the original post is that the framework 
that I mention below should work with other types of devices besides ACPI 
ones.


CPU clock settings could fit the same API for example (with modeID=0 being 
to hot-unplug the cpu and modeID=1 to initialize the cpu)


here's the original post:

in fact, a better abstraction would be something like

report_power_modes
   which would return a series of modes (sorted only by modeID)
   modeID, %power_used_in_this_mode, %capability_in_this_mode
   (I would make mode 0 always be complete power off, and mode 1 always be 
full capacity)


report_power_mode_speed
  which would return a matrix giving how long it takes to transition from any 
mode to any other mode. this should be a relative number, not an absolute 
number since it will be different at different clock speeds.


set_operational_mode(modeID)
  which would take you from whatever mode you are in now to the requested mode.

most devices would report the simple list of modes

0,0,0
1,100,100

with a mode_speed matrix of
   0 1
   ---
0|0 1
1|1 0

it may be that there is more info needed for the powr management engine to 
decide what modes it wants to put things into, if so identify what type of info 
you need and add another column to the modes list.

for example:
  you may want to add a flag for 'does this mode allow downstream devices to 
operate?'
  you may want to make a mode for 'this mode doesn't allow any new requests, 
but continues to process pending requests' and have a flag that indicates this


currently it looks like there's no way to find out what modes are available, 
and you have to know what mode something is in currently before you can request 
it change to a different mode. both of these prevent effective power management 
without encoding intimate knowledge of the capability of the particular 
hardware in your management tool.


some of this may be discoverable via the ACPI interface (it's not talked about 
much in the devices.txt file), but the mode setting is still wrong.


note that in the example above it's accpetable for a driver to cache what mode 
it thinks the device is in, but it needs to properly set the new mode even if 
it's cached data is incorrect.


this approach would allow the transition of ALL drivers to the new mode of 
operation in one fell swoop, and then adding additional power management 
features is just adding to the existing list rather then implementing new 
functions.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[David Miller]

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
> > and put
> > js-rtc-y = rtc.o
> > obj-$(JS_RTC) += js-rtc.o
> > in drivers/char/Makefile
> > 
> > Objections?
> 
> Oh, and s/CONFIG_RTC/CONFIG_JS_RTC/ in arch/sparc/defconfig, of course.

No objections.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [00/37] Clean up duplicate includes

[Satyam Sharma]

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 duplicate includes in net/ipv4/
>  [PATCH][32/37] Clean up duplicate includes in net/sunrpc/


And I also looked over these three after your resends.


Anyway, the entire series was OK, just removing a #include
line when that exact same header was already #include'd in
the same file. [ I also wonder if this patchset ends up exposing
some header-include-ordering problems that were previously
hidden, actually. ]


Like you said you built an allmodconfig, everything should be OK.
[ Except for modules that didn't get included in allmodconfig because
your arch might not have supported it -- but even then, your patches
are obviously correct and will only expose issues elsewhere if we do
see any build breakage, but which isn't likely in any case. ]

So the entire series is reviewed and looks good to me :-)

Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[Al Viro]

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 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/char/rtc.c
> > > > 3) all the __sparc__ crap is changed to CONFIG_SPARC32 in same
> > > > 4) CONFIG_RTC is not longer allows on sparc64, only sparc32 with PCI
> > > 
> > > Umm...  OK, that takes care of sparc64 side of things, which is probably
> > > all we realistically care about.  Except that it still leaves broken 
> > > sparc32
> > > defconfig - we have RTC=m, SUN_MOSTEK_RTC=m and kbuild won't deal with 
> > > it...
> > 
> > That definitely needs to be fixed and I'm willing to entertain
> > any suggestion on how to deal with it.
> 
> 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
> and put
> js-rtc-y = rtc.o
> obj-$(JS_RTC) += js-rtc.o
> in drivers/char/Makefile
> 
> Objections?

Oh, and s/CONFIG_RTC/CONFIG_JS_RTC/ in arch/sparc/defconfig, of course.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[Al Viro]

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.  ACK?
> 
> ACK.
> 
> > > 2) all the __sparc_v9__ crap is removed from drivers/char/rtc.c
> > > 3) all the __sparc__ crap is changed to CONFIG_SPARC32 in same
> > > 4) CONFIG_RTC is not longer allows on sparc64, only sparc32 with PCI
> > 
> > Umm...  OK, that takes care of sparc64 side of things, which is probably
> > all we realistically care about.  Except that it still leaves broken sparc32
> > defconfig - we have RTC=m, SUN_MOSTEK_RTC=m and kbuild won't deal with it...
> 
> That definitely needs to be fixed and I'm willing to entertain
> any suggestion on how to deal with it.

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
and put
js-rtc-y = rtc.o
obj-$(JS_RTC) += js-rtc.o
in drivers/char/Makefile

Objections?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[David Miller]

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/char/rtc.c
> > 3) all the __sparc__ crap is changed to CONFIG_SPARC32 in same
> > 4) CONFIG_RTC is not longer allows on sparc64, only sparc32 with PCI
> 
> Umm...  OK, that takes care of sparc64 side of things, which is probably
> all we realistically care about.  Except that it still leaves broken sparc32
> defconfig - we have RTC=m, SUN_MOSTEK_RTC=m and kbuild won't deal with it...

That definitely needs to be fixed and I'm willing to entertain
any suggestion on how to deal with it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[Al Viro]

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
> > have explicit scanning ISA bus in addition to EBUS in drivers/char/rtc.c
> > in case of __sparc_v9__, so it looks like help above ought to be changed.
> > OTTH, the isa-scanning code looks odd - for comparison, FreeBSD has
> > the same logics for ebus (looks for node called "rtc"), but the isa probe
> > in the same driver (sys/sparc64/sparc64/rtc.c) is
> 
> It doesn't get built on sparc64 any more.
> 
> If you look at the current tree:
> 1) we handle all of the sparc64 RTC stuff in arch/sparc64/kernel/time

I see...  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?

> 2) all the __sparc_v9__ crap is removed from drivers/char/rtc.c
> 3) all the __sparc__ crap is changed to CONFIG_SPARC32 in same
> 4) CONFIG_RTC is not longer allows on sparc64, only sparc32 with PCI

Umm...  OK, that takes care of sparc64 side of things, which is probably
all we realistically care about.  Except that it still leaves broken sparc32
defconfig - we have RTC=m, SUN_MOSTEK_RTC=m and kbuild won't deal with it...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DRIVER SUBMISSION] DRBD wants to go mainline

[Lars Ellenberg]

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 for review. Then iterate until all comments are addressed.
> 
> -Andi

well.
there is just one logical piece, the drbd module...
it is all in its own subdirectory.
it does not really touch anything else.
I don't think it is feasible to split it further.

Lars
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove unused variable 'start'.

[Andrew Morton]

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)
>  {
>   pgd_t *pgd;
>   unsigned long next;
> - unsigned long start = addr;
>   unsigned long end = addr + size;
>  
>   BUG_ON(addr >= end);
> @@ -84,7 +83,7 @@ void unmap_kernel_range(unsigned long addr, unsigned long 
> size)
>   continue;
>   vunmap_pud_range(pgd, addr, next);
>   } while (pgd++, addr = next, addr != end);
> - flush_tlb_kernel_range(start, end);
> + flush_tlb_kernel_range(addr, end);
>  }
>  
>  static void unmap_vm_area(struct vm_struct *area)

err, no.  addr has a different value here.

There's a patch in Andi's tree which fixes the compile warning.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[David Miller]

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
> in case of __sparc_v9__, so it looks like help above ought to be changed.
> OTTH, the isa-scanning code looks odd - for comparison, FreeBSD has
> the same logics for ebus (looks for node called "rtc"), but the isa probe
> in the same driver (sys/sparc64/sparc64/rtc.c) is

It doesn't get built on sparc64 any more.

If you look at the current tree:

1) we handle all of the sparc64 RTC stuff in arch/sparc64/kernel/time
2) all the __sparc_v9__ crap is removed from drivers/char/rtc.c
3) all the __sparc__ crap is changed to CONFIG_SPARC32 in same
4) CONFIG_RTC is not longer allows on sparc64, only sparc32 with PCI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DRIVER SUBMISSION] DRBD wants to go mainline

[Jens Axboe]

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 iterate until all comments are
> addressed.

Yep, cleanup the style issues (that make sense) from checkpatch and then
psot as a series of patches that can be reviewed. Linking to a git tree
wont get you very far.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][hid] Fix a NULL pointer dereference when we fail to allocate memory

[Jiri Slaby]

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-core.c
> @@ -743,7 +743,7 @@ static struct hid_device *usb_hid_configure(struct 
> usb_interface *intf)
>   hid->quirks = quirks;
>  
>   if (!(usbhid = kzalloc(sizeof(struct usbhid_device), GFP_KERNEL)))

Out of curiosity, where is this freed?

-- 
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Kconfig fun with sparc32/sparc64 rtc drivers

[Al Viro]

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 register
misc device, etc.   As the matter of fact, that's what sparc64 defconfig
has.

However, building both as modules runs into fun problems with
kbuild - we get
drivers/char/rtc.o
drivers/sbus/char/rtc.o
drivers/sbus/char/rtc.mod.c
but no
drivers/char/rtc.mod.c
and anything that depends on exports from the latter will get buggered.
E.g. we get
WARNING: "rtc_control" [sound/core/snd-rtctimer.ko] undefined!
WARNING: "rtc_unregister" [sound/core/snd-rtctimer.ko] undefined!
WARNING: "rtc_register" [sound/core/snd-rtctimer.ko] undefined!
on sparc64 allmodconfig build because of that.

Aside of kbuild problems, how is userland supposed to deal with
two modules with the same name, anyway?

There's another interesting question -
config SUN_MOSTEK_RTC
tristate "Mostek real time clock support"
help
  The Mostek RTC chip is used on all known Sun computers except
  some JavaStations. For a JavaStation you need to say Y both here
  and to "Enhanced Real Time Clock Support".
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
in case of __sparc_v9__, so it looks like help above ought to be changed.
OTTH, the isa-scanning code looks odd - for comparison, FreeBSD has
the same logics for ebus (looks for node called "rtc"), but the isa probe
in the same driver (sys/sparc64/sparc64/rtc.c) is

static struct isa_pnp_id rtc_isa_ids[] = {
{ 0x000bd041, "AT realtime clock" }, /* PNP0B00 */
{ 0 }
};

static int
rtc_isa_probe(device_t dev)
{

if (ISA_PNP_PROBE(device_get_parent(dev), dev, rtc_isa_ids) == 0) {
device_set_desc(dev, "Real Time Clock");
return (0);
}

return (ENXIO);
}

and they claim to find that one on Netra X1, where we seemed to get rtc_init:
no PC rtc found, if the boot logs I've been able to google are to be trusted.

Comments?  Sparc64 box I've got is sbus-only, so I've never touched the
drivers/char/rtc.c stuff - it doesn't find anything ebus anyway, since the
damn thing is simply note there...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add KERN_* prefix to printks in bug.h

[Diego Woitasen]

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-generic/bug.h b/include/asm-generic/bug.h
> > index 7f30cce..6e49266 100644
> > --- a/include/asm-generic/bug.h
> > +++ b/include/asm-generic/bug.h
> > @@ -8,22 +8,23 @@
> >  #ifdef CONFIG_GENERIC_BUG
> >  #ifndef __ASSEMBLY__
> >  struct bug_entry {
> > -   unsigned long   bug_addr;
> > +   unsigned long bug_addr;
> 
> Never include unrelated changes.
> 
> >  #ifdef CONFIG_DEBUG_BUGVERBOSE
> > -   const char  *file;
> > -   unsigned short  line;
> > +   const char *file;
> > +   unsigned short line;
> >  #endif
> > -   unsigned short  flags;
> > +   unsigned short flags;
> >  };
> > -#endif /* __ASSEMBLY__ */
> > +#endif /* __ASSEMBLY__ */
> >  
> >  #define BUGFLAG_WARNING(1<<0)
> > -#endif /* CONFIG_GENERIC_BUG */
> > +#endif /* CONFIG_GENERIC_BUG */
> >  
> >  #ifndef HAVE_ARCH_BUG
> > -#define BUG() do { \
> > -   printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, 
> > __FUNCTION__); \
> > -   panic("BUG!"); \
> > +#define BUG() do { 
> > \
> > +   printk(KERN_EMERG "BUG: failure at %s:%d/%s()!\n",  \
> > +   __FILE__, __LINE__, __FUNCTION__);  \
> > +   panic("BUG!");  \
> >  } while (0)
> >  #endif
> >  
> > @@ -35,15 +36,15 @@ struct bug_entry {
> >  #define WARN_ON(condition) ({  
> > \
> > typeof(condition) __ret_warn_on = (condition);  \
> > if (unlikely(__ret_warn_on)) {  \
> > -   printk("WARNING: at %s:%d %s()\n", __FILE__,\
> > -   __LINE__, __FUNCTION__);\
> > +   printk(KERN_WARNING "WARNING: at %s:%d %s()\n", \
> > +   __FILE__, __LINE__, __FUNCTION__);  \
> > dump_stack();   \
> > }   \
> > unlikely(__ret_warn_on);\
> >  })
> >  #endif
> >  
> > -#else /* !CONFIG_BUG */
> > +#else  /* !CONFIG_BUG */
> >  #ifndef HAVE_ARCH_BUG
> >  #define BUG()
> >  #endif

yes, sorry... the "unrelated" changes are result of Lindent. May be I
should include that in the git log.



-- 

--
Diego Woitasen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] parse_table() earlier check.

[Tetsuo Handa]

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 (!n)
> > +   return -ENOTDIR;
> > for ( ; table->ctl_name || table->procname; table++) {
> > -   if (!table->ctl_name)
> > -   continue;
> > if (n == table->ctl_name) {
> > int error;
> > if (table->child) {
> 
> I don't like this. For one, it destroy some symmetry in sysctl table
> walking code, where sysctl(2) code checks for valid ->ctl_name, and proc
> code checks for valid ->procname and both have same for loop. For two,
> nobody uses sysctl(2), sysctl aren't big, so this optimization is
> unneeded.

Excuse me, but I didn't understand what you are worrying.
I'm saying that:
  If n == 0, the condition "if (n == table->ctl_name)" is always false
  because of previous "if (!table->ctl_name) continue;" statement
  regardless of the result whether ->ctl_name and/or ->procname are valid or 
not.
  Thus, they always return -ENOTDIR if n == 0.
Why this optimization destroys something?
Should "if (!table->ctl_name)" be
for ( ; table->ctl_name || table->procname; table++) {
-   if (!table->ctl_name)
+   if (!table->procname)
continue;
if (n == table->ctl_name) {
int error;
if (table->child) {
or something?

Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [00/37] Clean up duplicate includes (resend patch 32)

[Jesper Juhl]

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/37] Clean up duplicate includes in net/ipv4/
> >  [PATCH][32/37] Clean up duplicate includes in net/sunrpc/
> 

Here's 32 : 

diff --git a/net/sunrpc/auth_gss/svcauth_gss.c 
b/net/sunrpc/auth_gss/svcauth_gss.c
index 4906975..794ce55 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -42,7 +42,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [00/37] Clean up duplicate includes (resend patch 12)

[Jesper Juhl]

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/37] Clean up duplicate includes in net/ipv4/
> >  [PATCH][32/37] Clean up duplicate includes in net/sunrpc/
> 

Here's a resend of patch 12.

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index fd1e156..4a18b88 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -75,7 +75,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 9a08d65..01281ee 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -47,15 +47,10 @@
 #include 
 #include 
 #include 
-
 #include 
 #include 
 #include 
-
 #include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 60cccf2..9afd172 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index a4a2a0e..27de3d8 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -39,8 +39,6 @@
 
 #include 
 #include 
-
-#include 
 #include 
 #include 
 
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..43c8668 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "gianfar_mii.h"
 
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 7b411c1..2470903 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/irda/kingsun-sir.c b/drivers/net/irda/kingsun-sir.c
index bdd5c97..4c0d379 100644
--- a/drivers/net/irda/kingsun-sir.c
+++ b/drivers/net/irda/kingsun-sir.c
@@ -66,7 +66,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
index 0de8672..bfc5752 100644
--- a/drivers/net/irda/mcs7780.c
+++ b/drivers/net/irda/mcs7780.c
@@ -50,7 +50,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c
index 9853c74..c0f5ad3 100644
--- a/drivers/net/mipsnet.c
+++ b/drivers/net/mipsnet.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/netxen/netxen_nic_main.c 
b/drivers/net/netxen/netxen_nic_main.c
index b703ccf..6ba8e07 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -39,7 +39,6 @@
 #include "netxen_nic_phan_reg.h"
 
 #include 
-#include 
 #include 
 
 MODULE_DESCRIPTION("NetXen Multi port (1/10) Gigabit Network Driver");
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 8be8be4..c2fc2f7 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
index 1aabc91..a059f3d 100644
--- a/drivers/net/tsi108_eth.c
+++ b/drivers/net/tsi108_eth.c
@@ -47,7 +47,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/drivers/net/wireless/ipw2200.h b/drivers/net/wireless/ipw2200.h
index 626a240..9c973b9 100644
--- a/drivers/net/wireless/ipw2200.h
+++ b/drivers/net/wireless/ipw2200.h
@@ -45,7 +45,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/net/wireless/zd1211rw/zd_def.h 
b/drivers/net/wireless/zd1211rw/zd_def.h
index deb99d1..505b4d7 100644
--- a/drivers/net/wireless/zd1211rw/zd_def.h
+++ b/drivers/net/wireless/zd1211rw/zd_def.h
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 
 typedef u16 __nocast zd_addr_t;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [00/37] Clean up duplicate includes (resend patch 28)

[Jesper Juhl]

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 up duplicate includes in net/ipv4/
> >  [PATCH][32/37] Clean up duplicate includes in net/sunrpc/
> 
Here's patch 28 again.

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index c9e2b5e..0f1d7be 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -75,7 +75,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
index e1052bc..c32781d 100644
--- a/net/ipv4/ipvs/ip_vs_ctl.c
+++ b/net/ipv4/ipvs/ip_vs_ctl.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c 
b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index dcc12b1..69bd362 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][24/37] Clean up duplicate includes in kernel/

[Jesper Juhl]

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 you re-built with all these changes? Some
of these duplicate #include's could have been hiding deeper
header-include-ordering problems, and we'd want to know
about that too. Otherwise looks fairly obvious, thanks. ]


I build an allmodconfig kernel, an allnoconfig one as well as one with
my regular config for my home machine.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fix empty macros in acpi.

[Len Brown]

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(...) ;
>  > next_c_statement
>  > 
>  > But since there is an intervening ';', this code is still functionally 
> correct
>  > and a decent compiler will delete the test altogether, yes?
> 
> Right, gcc does generate the correct code.
> 
>  > So is there some real problem here that I missed,
>  > or is this to make some code-checking tool that I don't have happy?
> 
> Out of curiousity, I thought I'd see what was lurking in a -Wextra
> build a while back. It's 99.9% noise, but a lot of it is trivial stuff
> like this.

okay, i'll apply it to reduce the noise.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] x86_64: use core id bits for apicid_to_node initialization v2

[Yinghai Lu]

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/k8topology.c b/arch/x86_64/mm/k8topology.c
index a96006f..7cbd58a 100644
--- a/arch/x86_64/mm/k8topology.c
+++ b/arch/x86_64/mm/k8topology.c
@@ -44,12 +44,14 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 { 
 	unsigned long prevbase;
 	struct bootnode nodes[8];
-	int nodeid, i, j, nb;
+	int nodeid, i, nb;
 	unsigned char nodeids[8];
 	int found = 0;
 	u32 reg;
 	unsigned numnodes;
-	unsigned num_cores;
+	unsigned cores;
+	unsigned bits;
+	int j;
 
 	if (!early_pci_allowed())
 		return -1;
@@ -60,9 +62,6 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 
 	printk(KERN_INFO "Scanning NUMA topology in Northbridge %d\n", nb); 
 
-	num_cores = (cpuid_ecx(0x8008) & 0xff) + 1;
-	printk(KERN_INFO "CPU has %d num_cores\n", num_cores);
-
 	reg = read_pci_config(0, nb, 0, 0x60); 
 	numnodes = ((reg >> 4) & 0xF) + 1;
 	if (numnodes <= 1)
@@ -168,11 +167,15 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 	} 
 	printk(KERN_INFO "Using node hash shift of %d\n", memnode_shift); 
 
+	/* use the coreid bits from early_identify_cpu */
+	bits = boot_cpu_data.x86_coreid_bits;
+	cores = (1<

Re: PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+

[Mark Tiefenbruck]

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, since I have HPET disabled
in my BIOS. I didn't bother with nohz and highres=off, since I don't
believe those options are present in the version of the kernel I'm
testing. None of these made any difference, but I can try the rest of
the combinations, if you think I should. Just to make sure, I should
be placing these after the kernel path in grub.conf, right?

I noticed during these tests that the cursor still blinks when it
reaches the point where it stops printing things. This seems like good
evidence that, indeed, the kernel is still active but is waiting for a
response. Or maybe the hardware does that itself.

I checked on what happens when I enable HPET in my BIOS. In the
working kernel, it gets to the boot scripts and stops doing anything
useful when letting udev process events. With the newer kernels, it
halts in the same place as before.

So, what next? I am of course willing to give out reasonable
information about my system and try out patches.

 Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/3] m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible

[Dmitry Torokhov]

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
> 
> At first I just wanted to move it. Then I thought about the angry
> comments I would get about not moving it to a header file ;-)
> 
>  looked like the best candidate.  is
> another option.
> 

linux/kbd_kern.h sounds much better.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Create clflush() inline, remove hardcoded wbinvd

[Muli Ben-Yehuda]

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" : "+m" (*(char __force*)(adr + i)));
> > 
> > The original one calls clflush with (adr + i), the new one with (*(adr
> > + i)). Are these calls equivalent?
> 
> Yes, they are.  The parentheses which are part of the old assembly
> string has the same effect as the asterisk operator in C.

Ah, I see. Thanks for the explanation!

Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFH] Partition table recovery

[Al Boldi]

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 changing
> > machines around on a disk) but something you'd backup on the FS level
> > should, in my opinion, need to be less fragile than would be possible
> > with just 512 bytes available.
>
> *IF* you remember to store the sfdisk -d somewhere useful.  In my "How
> To Recover From Hard Drive Catastrophies" classes, I tell them to
> print out a copy of "sfdisk -l /dev/hda ; sfdisk -d /dev/hda" and tape
> it to the side of the computer.  I also tell them do regular backups.
> What to make a guess how many them actually follow this good advice?
> Far fewer than I would like, I suspect...
>
> What I'm suggesting is the equivalent of sfdisk -d, except we'd be
> doing it automatically without requiring the user to take any kind of
> explicit action.  Is it perfect?  No, although the edge conditions are
> quite rare these days and generally involve users using legacy systems
> and/or doing Weird Shit such that They Really Should Know To Do Their
> Own Explicit Backups.  But for the novice users, it should work Just
> Fine.

Sounds great, but it may be advisable to hook this into the partition 
modification routines instead of mkfs/fsck.  Which would mean that the 
partition manager could ask the kernel to instruct its fs subsystem to 
update the backup partition table for each known fs-type that supports such 
a feature.


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.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86_64: get mp_bus_to_node as early v2

[Yinghai Lu]

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 get and set numa_node in the device.
set_dev_node is called in pci_device_add() with pcibus_to_node(bus). and
pci_bus_to_node use bus->sysdata for nodeid.
the problem is when pci_add_device is called, bus->sysdata is not assigned
correct nodeid yet. the result will be numa_node always is 0.
pcibios_scan_root and pci_scan_root could take sysdata. So we need to get
mp_bus_to_node mapping before these two are called. and get_mp_bus_to_node
could get correct node for sysdata in root bus.
in scanning of root bus, all child bus will take parent bus sysdata. So all
pci_device->dev.numa_node will be assigned correctly automatically.
later we could use dev_to_node(&pci_dev->dev) to numa_node, and we could also
could make other bus specific device get the correct numa_node too.
and in different driver we could use kmalloc_node instead of kmalloc for
skbuff/net or urb/usb etc. That could help improve performance with
usb or net or
sata for AMD K8 two sockets beyond system.

For example:
two way opteron system and only one HT chain on node 0. USB controller on SB
will be on node0. some dma accessing is used with kmalloc/dma_map_single. and
these address will be on node1 instead of node0. and even worse, when node1 ram
is above 4G, we may need to iommu mapping for usb operation.
two way system with one HT chain on different node, we will need to
kmalloc/dma_map_single to use ram on corresonding node too.  esp for nvidia
mcp55/io55 system. the second io55 could have nic/sata/pcie devices.

this is one update version to pci_sysdata ...
also reverse pci_acpi_scan_root to use pcibios_scan_root again.

without this patch: /sys/pci:80/*/numa_node for second HT chain always 0.

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

arch/i386/pci/Makefile |1
arch/i386/pci/acpi.c   |   40 +--
arch/i386/pci/common.c |7 ++-
arch/i386/pci/irq.c|   18 
arch/i386/pci/legacy.c |   22 ++
arch/i386/pci/mp_bus_to_node.c |   24 +++
arch/x86_64/pci/k8-bus.c   |   83 -
include/asm-i386/topology.h|   10 
include/asm-x86_64/topology.h  |   13 ++
9 files changed, 159 insertions(+), 59 deletions(-)

diff --git a/arch/i386/pci/Makefile b/arch/i386/pci/Makefile
index 44650e0..600d0e7 100644
--- a/arch/i386/pci/Makefile
+++ b/arch/i386/pci/Makefile
@@ -10,5 +10,6 @@ pci-y+= legacy.o irq.o
 
 pci-$(CONFIG_X86_VISWS)		:= visws.o fixup.o
 pci-$(CONFIG_X86_NUMAQ)		:= numa.o irq.o
+pci-$(CONFIG_NUMA)		+= mp_bus_to_node.o
 
 obj-y+= $(pci-y) common.o early.o
diff --git a/arch/i386/pci/acpi.c b/arch/i386/pci/acpi.c
index bc8a44b..dfa24a1 100644
--- a/arch/i386/pci/acpi.c
+++ b/arch/i386/pci/acpi.c
@@ -8,46 +8,28 @@
 struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_device *device, int domain, int busnum)
 {
 	struct pci_bus *bus;
-	struct pci_sysdata *sd;
+#ifdef CONFIG_ACPI_NUMA
 	int pxm;
-
-	/* Allocate per-root-bus (not per bus) arch-specific data.
-	 * TODO: leak; this memory is never freed.
-	 * It's arguable whether it's worth the trouble to care.
-	 */
-	sd = kzalloc(sizeof(*sd), GFP_KERNEL);
-	if (!sd) {
-		printk(KERN_ERR "PCI: OOM, not probing PCI bus %02x\n", busnum);
-		return NULL;
-	}
+	int node;
+#endif
 
 	if (domain != 0) {
 		printk(KERN_WARNING "PCI: Multiple domains not supported\n");
-		kfree(sd);
 		return NULL;
 	}
 
-	sd->node = -1;
-
-	pxm = acpi_get_pxm(device->handle);
 #ifdef CONFIG_ACPI_NUMA
-	if (pxm >= 0)
-		sd->node = pxm_to_node(pxm);
+	pxm = acpi_get_pxm(device->handle);
+	if (pxm >= 0) {
+		node = pxm_to_node(pxm);
+		printk(KERN_INFO "bus %02x -> pxm %d -> node %02x\n",
+			busnum, pxm, node);
+		set_mp_bus_to_node(busnum, node);
+	}
 #endif
 
-	bus = pci_scan_bus_parented(NULL, busnum, &pci_root_ops, sd);
-	if (!bus)
-		kfree(sd);
+	bus = pcibios_scan_root(busnum);
 
-#ifdef CONFIG_ACPI_NUMA
-	if (bus != NULL) {
-		if (pxm >= 0) {
-			printk("bus %d -> pxm %d -> node %d\n",
-busnum, pxm, sd->node);
-		}
-	}
-#endif
-	
 	return bus;
 }
 
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 85503de..d188e10 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -314,9 +314,14 @@ struct pci_bus * __devinit pcibios_scan_root(int busnum)
 		return NULL;
 	}
 
+	sd->node = get_mp_bus_to_node(busnum);
+
 	printk(KERN_DEBUG "PCI: Probing PCI hardware (bus %02x)\n", busnum);
+	bus = pci_scan_bus_parented(NULL, busnum, &pci_root_ops, sd);
+	if (!bus)
+		kfree(sd);
 
-	return pci_scan_bus_parented(NULL, busnum, &pci_root_ops, sd);
+	return bus;
 }
 
 extern u8 pci_cache_line_size;
diff --git a/arch/i386/pci/irq.c b/arch/i386/pci/irq.c
index f2cb9

Re: [git patches] two warning fixes

[Jeff Garzik]

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 described abvoe need to add code to test it and print a
warning. Lots of added .text and .data for little benefit.



Not necessarily as simple as that -- you need to make sure you don't 
pass something bogus to a sysfs_remove_blah() function at 
unregister/unload time, if sysfs_create_blah() failed.


Certainly sysfs_foo() failure is often ignorable in the sense that you 
want the driver to keep loading... but that does not imply that it is 
strictly ignorable, if you also consider the associated cleanup code.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Hibernation considerations

[david]

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 task?


you give up on the suspend becouse you have no way of getting the user
task to give up the lock.


Once the deadlock has occurred it's too late.  You can't give up; in
fact you can't do anything at all.  The system has hung.


however, kernel locks should not be held by user tasks, user tasks are not
expected to behave in rational ways, allowing them to compete with kernel
tasks for locks is a sure way to get a deadlock or indefinate stall.


What on Earth are you talking about?  "Kernel locks should not be held
by user tasks"?  Then who _should_ hold them?  You are aware, I hope,
that down() and mutex_lock() can be called only in process context?


what locks are accessed this way?


Lots of them.  For example, most drivers won't want a suspend to occur
right in the middle of an I/O transfer.  To prevent this, the driver
might use a mutex.  The task doing the I/O (which will be a user task)
acquires the mutex during a transfer and the suspend routine acquires
the mutex while quiescing the device.


wait a min her, it's possible we are misunderstanding each other.

as I see it.

if userspace can aquire locks that prevent the kernel from shutting off 
(or doing anything else in particular) then it's possible for misbehaving 
userspace code to stop the kernel by simply choosing to never release the 
lock.


this would be a trivial DOS from userspace.

now, if you are talking instead about the fact that when userspace makes a 
system call, the execution of that system call involves aquiring locks 
that are released before the system call completes you have a very 
different situation.


if you have locks that are held across system calls then you should 
already have problems. becouse you can't count on userspace ever taking 
whatever action is appropriate to release the lock.


what am I missing that concerns you so much?


Does it really (fundamentally) require scheduling tasks, particularly in
the case that the devices have already been put in the "quiesced" state?


I can't say for sure.  That's the way we have been doing it.  It
wouldn't be easy to change, because the driver would have to busy-wait
during delays -- which would mean it would need to use different code
for system-wide suspend and runtime suspend.


please define terms so that we are all on the same page


Please read Documentation/power/devices.txt.


I have done so.


what do you mean by
system-wide suspend


That's what you would call standby, suspend-to-RAM, or hibernate.  The
entire system goes to sleep.


runtime suspend


That's when an individual device is placed in a low-power state to
save energy while it isn't being used.  The system as a whole remains
awake and the device will be resumed the next time it is needed for
anything.


thanks for the defintitions.

having read through Documentation/power/devices.txt I remain convinced 
that you are making a fundamental mistake.


you are designing a system that will only work if everything (every 
driver, every state transition) participates fully in the process at all 
times. You started with the facts 'this is the info that ACPI provides and 
this is how it is designed to be used' and worked from there instead of 
looking to see what the kernel really needed and figuring how to provide a 
good interface for that that happens to be implemented (today) with ACPI. 
(a proper power management framework shouldn't care if you have ACPI, APM, 
or some other method of controlling the devices)


this leads to resume functions that can only work if the proper suspend 
function was called rather then makeing 'resume' just mean 'go to full 
operation', which is the same thing that gets called when the device is 
first initialized. internally it can examine the hardware and follow 
different paths depending on what it finds the current state of the 
hardware is, but the outside world (including the rest of the kernel) 
should not care. the fact that the rest of the kernel needs to know if it 
should call 'resume' or 'initialize' is a failure in the abstraction.


in fact, a better abstraction would be something like

report_power_modes
  which would return a series of modes (sorted only by modeID)
  modeID, %power_used_in_this_mode, %capability_in_this_mode
  (I would make mode 0 always be complete power off, and mode 1 always be 
full capacity)


report_power_mode_speed
  which would return a matrix giving how long it takes to transition from 
any mode to any other mode. this should be a relative number, not an 
absolute number since it will be different at different clock speeds.


set_operational_mode(modeID)
  which would take you from whatever mode you are in now to the requested 
mode.


mo

[PATCH] x86_64 vDSO: install unstripped copies on disk

[Roland McGrath]

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 <[EMAIL PROTECTED]>
---
 arch/x86_64/Makefile  |1 +
 arch/x86_64/vdso/Makefile |   20 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 93fc1f2..c0905ae 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -107,6 +107,7 @@ fdimage fdimage144 fdimage288 isoimage: vmlinux
 
 install:
$(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(BOOTIMAGE) $@ 
+   $(Q)$(MAKE) $(build)=arch/x86_64/vdso $@
 ifeq ($(CONFIG_IA32_EMULATION),y)
$(Q)$(MAKE) $(build)=arch/x86_64/ia32 $@
 endif
diff --git a/arch/x86_64/vdso/Makefile b/arch/x86_64/vdso/Makefile
index faaa72f..20ecf05 100644
--- a/arch/x86_64/vdso/Makefile
+++ b/arch/x86_64/vdso/Makefile
@@ -13,7 +13,7 @@ vobjs := $(foreach F,$(vobjs-y),$(obj)/$F)
 
 $(obj)/vdso.o: $(obj)/vdso.so
 
-targets += vdso.so vdso.lds $(vobjs-y) vdso-syms.o
+targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y) vdso-syms.o
 
 # The DSO images are built using a special linker script.
 quiet_cmd_syscall = SYSCALL $@
@@ -25,14 +25,18 @@ export CPPFLAGS_vdso.lds += -P -C -U$(ARCH)
 vdso-flags = -fPIC -shared -Wl,-soname=linux-vdso.so.1 \
 $(call ld-option, -Wl$(comma)--hash-style=sysv) \
-Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
-SYSCFLAGS_vdso.so = $(vdso-flags)
+SYSCFLAGS_vdso.so.dbg = $(vdso-flags)
 
 $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
 
-$(obj)/vdso.so: $(src)/vdso.lds $(vobjs) FORCE
+$(obj)/vdso.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
$(call if_changed,syscall)
 
-CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables 
-m64
+$(obj)/%.so: OBJCOPYFLAGS := -S
+$(obj)/%.so: $(obj)/%.so.dbg FORCE
+   $(call if_changed,objcopy)
+
+CF := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64
 
 $(obj)/vclock_gettime.o: CFLAGS = $(CF)
 $(obj)/vgetcpu.o: CFLAGS = $(CF)
@@ -47,3 +51,11 @@ $(obj)/built-in.o: ld_flags += -R $(obj)/vdso-syms.o
 SYSCFLAGS_vdso-syms.o = -r -d
 $(obj)/vdso-syms.o: $(src)/vdso.lds $(vobjs) FORCE
$(call if_changed,syscall)
+
+quiet_cmd_vdso_install = INSTALL $@
+  cmd_vdso_install = cp [EMAIL PROTECTED] $(MODLIB)/vdso/$@
+vdso.so:
+   @mkdir -p $(MODLIB)/vdso
+   $(call cmd,vdso_install)
+
+install: vdso.so
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] readahead drop behind and size adjustment

[Dave Jones]

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. Most users will be glad to feel the
 > speedup, and happily ignore the readahead misses, which may be
 > "invisible" in case of large memory.
 > 
 > In theory, the distributions can do the same tuning.  So we have an
 > interesting question for Dave:
 > Does fedora desktop raise the default readahead size? Why or
 > why not?  It goes so far to do userland readahead ;)
 
Fedora takes whatever defaults for readahead the kernel.org kernel has.
The only reasoning being if anyone reported VM bugs, we'd be able
to say to interested upstream developers "we're running the stock VM".
without having to get the user to try and reproduce on unpatched
kernels.
 
 > - drop behind
 > 
 > Sorry, I still doubt it will benefit all/most workloads. Leave it off
 > by default, and leave the enabling decision to Dave? I do hope that
 > it help general desktops.

It's not a subject that I'm intimatly familiar with, and when it
comes to decisions like this, I tend to just take whatever the
upstream defaults are.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] readahead drop behind and size adjustment

[Fengguang Wu]

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 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. Most users will be glad to feel the
speedup, and happily ignore the readahead misses, which may be
"invisible" in case of large memory.

In theory, the distributions can do the same tuning.  So we have an
interesting question for Dave:
Does fedora desktop raise the default readahead size? Why or
why not?  It goes so far to do userland readahead ;)


- drop behind

Sorry, I still doubt it will benefit all/most workloads. Leave it off
by default, and leave the enabling decision to Dave? I do hope that
it help general desktops.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Hibernation considerations

[david]

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 to backup/restore then the
reading/writing of the image should be able to be done in userspace.


The backup/restore here has nothing to do with the read/write of the
image. It means instead of preserving memory for a new kernel like that
of crash-dump, the memory for a new kernel is backupped before kexec and
restored after kexec by the kexec kernel.


Ok, I see the miscommunication here. you are talking about freeing up 
memory for the second kernel instead of reserving it from boot time.


I'm talking about getting the second kernel a list of what memory pages it 
should write to the image


if we can get the info for the list I'm looking for we should be able to 
demonstrate the kexec based hibernate.


the change you are talking about in an enhancment that is useful after 
that point to save some memory.



If the "scatter copy" is replaced by "scatter swap", we need not the
inverse list, and the state of kexeced kernel can be backuped too. There
are "scatter copy" support in normal kexec implementation in
"relocate_kernel".


what do you mean by "scatter swap"


copy:   dest=src
swap:   tmp=dest; dest=src; src=tmp

If memory is swapped, no information is lost, both that of kexec kernel
and kexeced kernel.


I'm missing why you need to preserve this memory

if you are talking about memory that will be used by the second kernel 
when you kexec to it then you don't need to preserve it (since it will be 
overwritten by the second kernel). if you aren't talking about memory that 
will be used by the second kernel why do you need to move it?


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NET: Add missing entries to family name tables

[David Miller]

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 of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [00/37] Clean up duplicate includes

[Satyam Sharma]

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 duplicate includes in net/sunrpc/


which I did not find anywhere ... not even on netdev@

Anyway, the entire series was OK, just removing a #include
line when that exact same header was already #include'd in
the same file. [ I also wonder if this patchset ends up exposing
some header-include-ordering problems that were previously
hidden, actually. ]


Please consider applying these patches.


I think these are trivial and obvious enough -- can probably be
merged together into single patch by Andrew and just slammed
into the kernel tree :-)

Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/1] lro: Generic Large Receive Offload for TCP traffic

[David Miller]

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 sounds as if we have at least two pending and
in the works if not ready already, so that shouldn't be an issue.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sparc64: ERROR: "sys_ioctl" [arch/sparc64/solaris/solaris.ko] undefined!

[David Miller]

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.
> >   MODPOST 463 modules
> > ERROR: "sys_ioctl" [arch/sparc64/solaris/solaris.ko] undefined!
> 
> Sorry, my fault.
> 
> It looked to me like sparc64 exports sys_ioctl on it's own, but it only
> exports compat_sys_ioctl on it's own.
> 
> Here's the fix:

Applied, thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] make sparc32 PAGE_SHARED a read-mostly variable

[David Miller]

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 PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] take sparc32 enable_irq/disable_irq out of line

[David Miller]

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.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] clean include/asm-sparc/irq.h

[David Miller]

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 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.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Hibernation considerations

[Huang, Ying]

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 
> reading/writing of the image should be able to be done in userspace.

The backup/restore here has nothing to do with the read/write of the
image. It means instead of preserving memory for a new kernel like that
of crash-dump, the memory for a new kernel is backupped before kexec and
restored after kexec by the kexec kernel.

> > If the "scatter copy" is replaced by "scatter swap", we need not the
> > inverse list, and the state of kexeced kernel can be backuped too. There
> > are "scatter copy" support in normal kexec implementation in
> > "relocate_kernel".
> 
> what do you mean by "scatter swap"

copy:   dest=src
swap:   tmp=dest; dest=src; src=tmp

If memory is swapped, no information is lost, both that of kexec kernel
and kexeced kernel.

Best Regards,
Huang, Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] CONFIG_NET=n - lots of link time errors

[David Miller]

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-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

This is the second time I've seen this change in the past few
days, and people seem to hit it quite readily with randconfig.

It seems reasonable and I'll apply it, thanks Jan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] constify of_platform_driver name

[David Miller]

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 PowerPC allmodconfig and ppc64_defconfig, and for Sparc and
> Sparc64 defconfig.

Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] constify of_platform_driver match_table

[David Miller]

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 Sparc and Sparc64
> defconfig.

Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fix modular compilation of pmu_battery

[Josh Boyer]

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] undefined!

Signed-off-by: Dave Jones <[EMAIL PROTECTED]>

--- linux-2.6.22.noarch/drivers/macintosh/via-pmu.c~2007-07-20 
20:45:27.0 -0400
+++ linux-2.6.22.noarch/drivers/macintosh/via-pmu.c 2007-07-20 
20:45:52.0 -0400
@@ -2842,10 +2842,10 @@ EXPORT_SYMBOL(pmu_wait_complete);
 EXPORT_SYMBOL(pmu_suspend);
 EXPORT_SYMBOL(pmu_resume);
 EXPORT_SYMBOL(pmu_unlock);
-#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
+#if defined(CONFIG_PM)
 EXPORT_SYMBOL(pmu_enable_irled);
 EXPORT_SYMBOL(pmu_battery_count);
 EXPORT_SYMBOL(pmu_batteries);
 EXPORT_SYMBOL(pmu_power_flags);
-#endif /* CONFIG_PM && CONFIG_PPC32 */
+#endif


Paul has a different fix for this pending on the linuxppc-dev list.

josh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: long-term regression

[david]

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 size the files are posted at http://linux.lang.hm/linux

let me know what else I can send to help.

David Lang



I suggest that you test 2.6.22-rcN using one or both of these
boot options:

noisapnp
pnpacpi=off

Somewhere between 2.6.18 and 2.6.22-development, the ACPI config
symbol also starting enabling (selecting) PNP.  That's one of many
differences


with the 2.6.22-rc4 kernel that I was useing earlier, adding these two
options clears up the problem. Thanks.

should I test the two individually? or just plan on useing both from now
on?


Yes, please test them individually.  I expect that just one of them
will suffice, but I don't know which one.


pnpacpi=off works
noisapnp doesn't work


I normally disable PnP (both ISA and PCI), should I leave it enabled with
the newer kernels and this motherboard?


ACPI recently began enabling (selecting) PNP for you...


I didn't realize this had changed.


How do you normally disable PCI PNP?

What kind of hardware is this?  Please show us lspci output.


00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0

00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: 66MHz, fast devsel, IRQ 3
I/O ports at fc00 [size=32]
I/O ports at 1c00 [size=64]
I/O ports at 1c40 [size=64]
Capabilities: [44] Power Management version 2

00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 
(prog-if 10 [OHCI])
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
Memory at fe02f000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 
(prog-if 20 [EHCI])
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at fe02e000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2

00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio 
Controller (rev a2)
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 3
I/O ports at f000 [size=256]
I/O ports at ec00 [size=256]
Memory at fe02d000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2) (prog-if 8a 
[Master SecP PriP])
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] 
[size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] 
[size=1]
[virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] 
[size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] 
[size=1]
I/O ports at e000 [size=16]
Capabilities: [44] Power Management version 2

00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 
[Subtractive decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: fde0-fdef
Prefetchable memory behind bridge: fdf0-fdff

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
Subsystem: Elitegroup Computer Systems Unknown device 1b51
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
Memory at fe02b000 (32-bit, non-prefetchable) [size=4K]
I/O ports at dc00 [size=8]
Capabilities: [44] Power Management version 2

00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: b000-bfff
Memory behind bridge: fdd0-fd

Re: [PATCH] Don't compile the PMU power driver on 64-bit PowerPC

[Stephen Rothwell]

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_battery.ko] undefined!
> ERROR: "pmu_power_flags" [drivers/power/pmu_battery.ko] undefined!
> 
> This fixes the problem by not building pmu_battery.ko on ppc64.  There
> are no battery-powered ppc64 machines with an Apple PMU, and we can be
> reasonably confident there never will be.
> 
> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>

That fixes it.
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
for what its worth :-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgp19IwDdYD3x.pgp
Description: PGP signature

Re: [PATCH][24/37] Clean up duplicate includes in kernel/

[Satyam Sharma]

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 #include's could have been hiding deeper
header-include-ordering problems, and we'd want to know
about that too. Otherwise looks fairly obvious, thanks. ]


diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 145cbb7..5f7dba2 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


Ack


diff --git a/kernel/exit.c b/kernel/exit.c
index 464c2b1..9eef513 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 

 #include 
 #include 


Ack


diff --git a/kernel/kexec.c b/kernel/kexec.c
index 25db14b..d8de12e 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


Ack


diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
index 2c2dd84..5d9e07e 100644
--- a/kernel/rcupdate.c
+++ b/kernel/rcupdate.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 


Ack


diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
index ddff332..dd413bf 100644
--- a/kernel/rcutorture.c
+++ b/kernel/rcutorture.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


Ack


diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 998..e0b2456 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


Ack


diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index 059431e..7d4d7f9 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 


Ack


diff --git a/kernel/time.c b/kernel/time.c
index 5b81da0..6304942 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 

 #include 
 #include 


Ack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64: use apic core id bits for core nums

[Yinghai Lu]

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 should replace
> > > [PATCH for review] [37/48] x86_64: make k8topology multi-core aware
> >
> > Yes, you're right the patch is not good. It should probably use
> > information from the regular CPU setup code, not touch cpuid
> > directly
>
> need move some code into early_identify_cpu from identify_cpu in
> arch/x86_64/kernel/setup.c
> then could use that bits in bsp cpu info.

Yes something like this

> BTW:
> it seems for BSP only early_identify_cpu is called, and identify_cpu
> is only use in smp_callin for AP. Do i miss sth.

identify_cpu calls early_identify_cpu as first thing.


the calling to identify_cpu in BSP is in check_bugs(). It is easy to
ignore it...
maybe we could move that to setup_arch directly.

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.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] x86_64: offset apicid_to_node before use it before init_cpu_to_node

[Yinghai Lu]

[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 point.
For four socket system with Quad core cpus installed, all cpus apic id
is offset by 4, and bsp apic id is 4.
For eight socket system with dual core cpus installed, all cpus apic id
is offset by 2, and bsp apic id is 2.
We need offset apicid_to_node array according to boot_cpu_id.--- bsp apic id.
before we use apicid_to_node array.
boot_cpu_id is only valid init_apic_mappings.

So do update_apicid_to_node and init_cpu_to_node after init_apic_mappings

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>

arch/x86_64/kernel/setup.c |   10 --
arch/x86_64/mm/numa.c  |   24 
include/asm-x86_64/numa.h  |2 ++
3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index 33ef718..1862a91 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -385,8 +385,6 @@ void __init setup_arch(char **cmdline_p)
 	acpi_boot_init();
 #endif
 
-	init_cpu_to_node();
-
 	/*
 	 * get boot-time SMP configuration:
 	 */
@@ -395,6 +393,14 @@ void __init setup_arch(char **cmdline_p)
 	init_apic_mappings();
 
 	/*
+	 * need to put init_cpu_to_node after init_apic_mappings
+	 * we need to get boot_cpu_id (the BSP apic id) to modify
+	 * apicid_to_node array, before init_cpu_node
+	 */
+	update_apicid_to_node();
+	init_cpu_to_node();
+
+	/*
 	 * We trust e820 completely. No explicit ROM probing in memory.
  	 */
 	e820_reserve_resources(); 
diff --git a/arch/x86_64/mm/numa.c b/arch/x86_64/mm/numa.c
index 5154894..91605aa 100644
--- a/arch/x86_64/mm/numa.c
+++ b/arch/x86_64/mm/numa.c
@@ -607,6 +607,30 @@ early_param("numa", numa_setup);
  * prior to this call, and this initialization is good enough
  * for the fake NUMA cases.
  */
+void __init update_apicid_to_node(void)
+{
+	/*
+	 * let modify apicid_to_node array when boot_cpu_id !=0
+	 * apicid_to_node[0] != NUMA_NODE
+	 */
+
+	int i;
+
+	/* there is no apic id offset */
+	if (!boot_cpu_id)
+		return;
+
+	/* check if it is already updated */
+	if (apicid_to_node[0] == NUMA_NO_NODE)
+		return;
+
+	for (i = NR_CPUS -1; i >= boot_cpu_id; i--)
+		apicid_to_node[i] = apicid_to_node[i - boot_cpu_id];
+
+	for (i = boot_cpu_id - 1; i >= 0; i--)
+		apicid_to_node[i] = NUMA_NO_NODE;
+
+}
 void __init init_cpu_to_node(void)
 {
 	int i;
diff --git a/include/asm-x86_64/numa.h b/include/asm-x86_64/numa.h
index 933ff11..282b7a7 100644
--- a/include/asm-x86_64/numa.h
+++ b/include/asm-x86_64/numa.h
@@ -21,6 +21,7 @@ extern int hotadd_percent;
 
 extern unsigned char apicid_to_node[256];
 #ifdef CONFIG_NUMA
+extern void __init update_apicid_to_node(void);
 extern void __init init_cpu_to_node(void);
 
 static inline void clear_node_cpumask(int cpu)
@@ -29,6 +30,7 @@ static inline void clear_node_cpumask(int cpu)
 }
 
 #else
+#define update_apicid_to_node() do {} while (0)
 #define init_cpu_to_node() do {} while (0)
 #define clear_node_cpumask(cpu) do {} while (0)
 #endif

[PATCH 2/3] x86_64: use core id bits for apicid_to_node initialization

[Yinghai Lu]

[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 deletions(-)

diff --git a/arch/x86_64/mm/k8topology.c b/arch/x86_64/mm/k8topology.c
index f983c75..d108f96 100644
--- a/arch/x86_64/mm/k8topology.c
+++ b/arch/x86_64/mm/k8topology.c
@@ -49,7 +49,9 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 	int found = 0;
 	u32 reg;
 	unsigned numnodes;
-	unsigned dualcore = 0;
+	unsigned cores;
+	unsigned bits;
+	int j;
 
 	if (!early_pci_allowed())
 		return -1;
@@ -73,8 +75,6 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 		unsigned long base,limit; 
 		u32 nodeid;
 		
-		/* Undefined before E stepping, but hopefully 0 */
-		dualcore |= ((read_pci_config(0, nb, 3, 0xe8) >> 12) & 3) == 1;
 		base = read_pci_config(0, nb, 1, 0x40 + i*8);
 		limit = read_pci_config(0, nb, 1, 0x44 + i*8);
 
@@ -167,11 +167,15 @@ int __init k8_scan_nodes(unsigned long start, unsigned long end)
 	} 
 	printk(KERN_INFO "Using node hash shift of %d\n", memnode_shift); 
 
+	/* use the coreid bits from early_identify_cpu */
+bits = boot_cpu_data.x86_coreid_bits;
+	cores = (1<

[PATCH 0/3] x86_64: apicid_to_node when acpi=off or no srat

[Yinghai Lu]

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.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] x86_64: store core id bits in cpuinfo_x86

[Yinghai Lu]

[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 +++--
include/asm-x86_64/processor.h |1
2 files changed, 49 insertions(+), 24 deletions(-)

diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index 33ef718..24e6a52 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -499,18 +505,7 @@ static void __init amd_detect_cmp(struct cpuinfo_x86 *c)
 	int node = 0;
 	unsigned apicid = hard_smp_processor_id();
 #endif
-	unsigned ecx = cpuid_ecx(0x8008);
-
-	c->x86_max_cores = (ecx & 0xff) + 1;
-
-	/* CPU telling us the core id bits shift? */
-	bits = (ecx >> 12) & 0xF;
-
-	/* Otherwise recompute */
-	if (bits == 0) {
-		while ((1 << bits) < c->x86_max_cores)
-			bits++;
-	}
+	bits = c->x86_coreid_bits;
 
 	/* Low order bits define the core id (index of core in socket) */
 	c->cpu_core_id = c->phys_proc_id & ((1 << bits)-1);
@@ -546,6 +541,34 @@ static void __init amd_detect_cmp(struct cpuinfo_x86 *c)
 #endif
 }
 
+static void __cpuinit early_init_amd(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_SMP
+	unsigned bits;
+	unsigned ecx;
+
+	/* Multi core CPU? */
+	if (c->extended_cpuid_level < 0x8008)
+		return;
+
+	ecx = cpuid_ecx(0x8008);
+
+	c->x86_max_cores = (ecx & 0xff) + 1;
+
+	/* CPU telling us the core id bits shift? */
+	bits = (ecx >> 12) & 0xF;
+
+	/* Otherwise recompute */
+	if (bits == 0) {
+		while ((1 << bits) < c->x86_max_cores)
+			bits++;
+	}
+
+	c->x86_coreid_bits = bits;
+
+#endif
+}
+
 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 {
 	unsigned level;
@@ -768,6 +791,7 @@ struct cpu_model_info {
 void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
 	u32 tfms;
+	u32 xlvl;
 
 	c->loops_per_jiffy = loops_per_jiffy;
 	c->x86_cache_size = -1;
@@ -778,6 +802,7 @@ void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 	c->x86_clflush_size = 64;
 	c->x86_cache_alignment = c->x86_clflush_size;
 	c->x86_max_cores = 1;
+	c->x86_coreid_bits = 0;
 	c->extended_cpuid_level = 0;
 	memset(&c->x86_capability, 0, sizeof c->x86_capability);
 
@@ -814,18 +839,6 @@ void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 #ifdef CONFIG_SMP
 	c->phys_proc_id = (cpuid_ebx(1) >> 24) & 0xff;
 #endif
-}
-
-/*
- * This does the hard work of actually picking apart the CPU stuff...
- */
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
-{
-	int i;
-	u32 xlvl;
-
-	early_identify_cpu(c);
-
 	/* AMD-defined flags: level 0x8001 */
 	xlvl = cpuid_eax(0x8000);
 	c->extended_cpuid_level = xlvl;
@@ -846,6 +859,23 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
 			c->x86_capability[2] = cpuid_edx(0x80860001);
 	}
 
+	switch (c->x86_vendor) {
+	case X86_VENDOR_AMD:
+		early_init_amd(c);
+		break;
+	}
+
+}
+
+/*
+ * This does the hard work of actually picking apart the CPU stuff...
+ */
+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+	int i;
+
+	early_identify_cpu(c);
+
 	init_scattered_cpuid_features(c);
 
 	c->apicid = phys_pkg_id(0);
diff --git a/include/asm-x86_64/processor.h b/include/asm-x86_64/processor.h
index efc87a5..a5ac309 100644
--- a/include/asm-x86_64/processor.h
+++ b/include/asm-x86_64/processor.h
@@ -63,6 +63,7 @@ struct cpuinfo_x86 {
 	int	x86_tlbsize;	/* number of 4K pages in DTLB/ITLB combined(in pages)*/
 __u8x86_virt_bits, x86_phys_bits;
 	__u8	x86_max_cores;	/* cpuid returned max cores value */
+	__u8	x86_coreid_bits; /* cpuid returned core id bits */
 __u32   x86_power; 	
 	__u32   extended_cpuid_level;	/* Max extended CPUID function supported */
 	unsigned long loops_per_jiffy;

[PATCH] Don't compile the PMU power driver on 64-bit PowerPC

[Paul Mackerras]

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!

This fixes the problem by not building pmu_battery.ko on ppc64.  There
are no battery-powered ppc64 machines with an Apple PMU, and we can be
reasonably confident there never will be.

Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 3f6e176..58c806e 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -38,7 +38,7 @@ config BATTERY_DS2760
 
 config BATTERY_PMU
tristate "Apple PMU battery"
-   depends on ADB_PMU
+   depends on PPC32 && ADB_PMU
help
  Say Y here to expose battery information on Apple machines
  through the generic battery class.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pi-futex: set PF_EXITING without taking ->pi_lock

[Paul Mackerras]

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_wait() could 
> > be re-ordered. However, in this particular case we have an "optimized" 
> > smp_mb_after_atomic_inc(), perhaps it is good that the caller can 
> > choose the "right" barrier by hand.
> 
> _all_ default locking and atomic APIs should be barrier-safe i believe. 
> (and that includes atomic_inc() too) Most people dont have barriers on 
> their mind when their code. _If_ someone is barrier-conscious then we 
> should have barrier-less APIs too for that purpose of squeezing the last 
> half cycle out of the code, but it should be a non-default choice. The 
> reason: nobody notices an unnecessary barrier, but a missing barrier can 
> be nasty.

The approach we have taken on powerpc is that the atomic_*_test and
atomic_*_return functions have a barrier, but the straight atomic_inc
etc. don't.

As for putting barriers in, it's not a half cycle, it's more like 50
to 100 on some processors.  Added to that, what I think you are
actually advocating is *two* full barriers - one before the increment
and one after.  That seems like an enormous penalty to pay just
because some people want to roll their own lock primitives instead of
using the standard ones.

Why is ccids_read_lock trying to implement a rwlock without using an
rwlock?  Could it be converted to an ordinary rwlock?  Or an rwsem?

Paul.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [9/58] x86_64: Always use builtin memcpy on gcc 4.3

[Denis Vlasenko]

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.
> 
> Unfortunately such info is hard to find. The [EMAIL PROTECTED] list is
> empty. So, let me ask how this memcpy relates to recently submitted
> for glibc one [0]?
> 
> [0] 

Am I stupid or the files attached to that post demonstrate than "new"
code isn't much better and sometimes worse (aligned 4096 byte memcpy
went from 558 to 648 for Core 2)?

Beware that text files in test-memcpy.tar.bz2 seem to have
simple_memcpy / builtin_memcpy / memcpy columns swapped
(-old and -new files have them in different order).
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [more PATCHes] Use menuconfig objects - CONFIG_ISDN_I4L

[Tilman Schmidt]

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

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: [RFC, Announce] Unified x86 architecture, arch/x86

[Chris Wright]

* 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 +-
 Makefile   |   23 +-
 arch/i386/Kconfig  | 1275 +-
 arch/i386/Makefile |  208 +--
 arch/i386/kernel/early_printk.c|2 -
 arch/i386/kernel/tsc_sync.c|1 -
 arch/x86/Kconfig   | 1919 
 arch/{i386 => x86}/Kconfig.cpu |0 
 arch/{i386 => x86}/Kconfig.debug   |   50 +-
 arch/x86/Kconfig_32| 1283 +
 arch/{i386/Kconfig.debug => x86/Kconfig_32.debug}  |0 
 arch/x86/Kconfig_64|  792 
 .../{x86_64/Kconfig.debug => x86/Kconfig_64.debug} |0 
 arch/x86/Makefile  |5 +
 arch/{i386 => x86}/Makefile.cpu|0 
 arch/x86/Makefile_32   |  163 ++
 arch/x86/Makefile_64   |  128 ++
 arch/{i386 => x86}/boot/.gitignore |0 
 arch/{i386 => x86}/boot/Makefile   |6 +-
 arch/{i386 => x86}/boot/a20.c  |0 
 arch/{i386 => x86}/boot/apm.c  |0 
 arch/{i386 => x86}/boot/bitops.h   |0 
 arch/{i386 => x86}/boot/boot.h |0 
 arch/{i386 => x86}/boot/cmdline.c  |0 
 arch/{i386 => x86}/boot/code16gcc.h|0 
 arch/{i386 => x86}/boot/compressed/.gitignore  |0 
 arch/x86/boot/compressed/Makefile  |5 +
 .../Makefile => x86/boot/compressed/Makefile_32}   |8 +-
 .../Makefile => x86/boot/compressed/Makefile_64}   |8 +-
 .../head.S => x86/boot/compressed/head_32.S}   |0 
 .../head.S => x86/boot/compressed/head_64.S}   |0 
 .../misc.c => x86/boot/compressed/misc_32.c}   |0 
 .../misc.c => x86/boot/compressed/misc_64.c}   |0 
 arch/{i386 => x86}/boot/compressed/relocs.c|0 
 .../boot/compressed/vmlinux_32.lds}|0 
 .../boot/compressed/vmlinux_32.scr}|0 
 .../boot/compressed/vmlinux_64.lds}|0 
 .../boot/compressed/vmlinux_64.scr}|0 
 arch/{i386 => x86}/boot/copy.S |0 
 arch/{i386 => x86}/boot/cpu.c  |0 
 arch/{i386 => x86}/boot/cpucheck.c |0 
 arch/{i386 => x86}/boot/edd.c  |0 
 arch/{i386 => x86}/boot/header.S   |0 
 arch/{i386 => x86}/boot/install.sh |0 
 arch/{i386 => x86}/boot/main.c |0 
 arch/{i386 => x86}/boot/mca.c  |0 
 arch/{i386 => x86}/boot/memory.c   |0 
 arch/{i386 => x86}/boot/mtools.conf.in |0 
 arch/{i386 => x86}/boot/pm.c   |0 
 arch/{i386 => x86}/boot/pmjump.S   |0 
 arch/{i386 => x86}/boot/printf.c   |0 
 arch/x86/boot/setup.S  |7 +
 arch/{i386 => x86}/boot/setup.ld   |0 
 arch/{i386 => x86}/boot/string.c   |0 
 arch/{i386 => x86}/boot/tools/.gitignore   |0 
 arch/{i386 => x86}/boot/tools/build.c  |0 
 arch/{i386 => x86}/boot/tty.c  |0 
 arch/{i386 => x86}/boot/version.c  |0 
 arch/{i386 => x86}/boot/vesa.h |0 
 arch/{i386 => x86}/boot/video-bios.c   |0 
 arch/{i386 => x86}/boot/video-vesa.c   |0 
 arch/{i386 => x86}/boot/video-vga.c|0 
 arch/{i386 => x86}/boot/video.c|0 
 arch/{i386 => x86}/boot/video.h|0 
 arch/{i386 => x86}/boot/voyager.c  |0 
 arch/x86/crypto/Makefile   |5 +
 .../crypto/Makefile => x86/crypto/Makefile_32} |4 +-
 .../crypto/Makefile => x86/crypto/Makefile_64} |4 +-
 arch/{i386 => x86}/crypto/aes-i586-asm.S   |0 
 arch/{x86_64 => x86}/crypto/aes-x86_64-asm.S   |0 
 arch/{i386/crypto/aes.c => x86/crypto/aes_32.c}|0 
 arch/{x86_64/crypto/aes.c => x86/crypto/aes_64.c}  |0 
 arch/{i386 => x86}/crypto/twofish-i586-asm.S   |0 
 arch/{x86_64 => x86}/crypto/twofish-x86_64-asm.S   |0 
 .../crypto/twofish.c => x86/crypto/twofish_32.c}   |0 
 .../crypto/twofish.c => x86/crypto/twofish_64.c}   |0 
 arch/{i386/defconfig => x86/defconfig_32}  |0 
 arch/{x86_64/defconfig => x86/defconfig_64}|0 
 a

Re: [GIT PULL] mm: Remove slab destructors from kmem_cache_create().

[Paul Mundt]

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 never supported them
> > either.
> 
> SLOB of course did support destructors, otherwise it wouldn't have
> worked.
> 
Ah, I just noticed that there was no reference to the dtor in SLOB at all
apart from the kmem_cache_create() op. It looks like they were called
back in to and removed by an earlier patch, so the 'never' statement is
disinformation on my part. Sorry for the confusion!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [9/58] x86_64: Always use builtin memcpy on gcc 4.3

[Andi Kleen]

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.
> 
> Unfortunately such info is hard to find. The [EMAIL PROTECTED] list is
> empty. So, let me ask how this memcpy relates to recently submitted
> for glibc one [0]?

It doesn't relate at all. The kernel still uses its own memcpy.

Note that a lot of the traditional memcpy optimizations (like WC copies) 
are pointless in kernel space because the kernel rarely deals with continuous 
memory areas larger than a 4K page.

The only difference from the patch is that instead of using an own
heuristic when to use an out of line memcpy trust gcc's heuristic.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] make sparc32 PAGE_SHARED a read-mostly variable

[Al Viro]

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(-)

diff --git a/arch/sparc/mm/init.c b/arch/sparc/mm/init.c
index a532922..a1bef07 100644
--- a/arch/sparc/mm/init.c
+++ b/arch/sparc/mm/init.c
@@ -308,6 +308,9 @@ extern void sun4c_paging_init(void);
 extern void srmmu_paging_init(void);
 extern void device_scan(void);
 
+pgprot_t PAGE_SHARED __read_mostly;
+EXPORT_SYMBOL(PAGE_SHARED);
+
 void __init paging_init(void)
 {
switch(sparc_cpu_model) {
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index ca26232..17b485f 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -2154,7 +2154,7 @@ void __init ld_mmu_srmmu(void)
BTFIXUPSET_SIMM13(ptrs_per_pgd, SRMMU_PTRS_PER_PGD);
 
BTFIXUPSET_INT(page_none, pgprot_val(SRMMU_PAGE_NONE));
-   BTFIXUPSET_INT(page_shared, pgprot_val(SRMMU_PAGE_SHARED));
+   PAGE_SHARED = pgprot_val(SRMMU_PAGE_SHARED);
BTFIXUPSET_INT(page_copy, pgprot_val(SRMMU_PAGE_COPY));
BTFIXUPSET_INT(page_readonly, pgprot_val(SRMMU_PAGE_RDONLY));
BTFIXUPSET_INT(page_kernel, pgprot_val(SRMMU_PAGE_KERNEL));
diff --git a/arch/sparc/mm/sun4c.c b/arch/sparc/mm/sun4c.c
index bdd835f..a57a366 100644
--- a/arch/sparc/mm/sun4c.c
+++ b/arch/sparc/mm/sun4c.c
@@ -2155,7 +2155,7 @@ void __init ld_mmu_sun4c(void)
BTFIXUPSET_SIMM13(user_ptrs_per_pgd, KERNBASE / SUN4C_PGDIR_SIZE);
 
BTFIXUPSET_INT(page_none, pgprot_val(SUN4C_PAGE_NONE));
-   BTFIXUPSET_INT(page_shared, pgprot_val(SUN4C_PAGE_SHARED));
+   PAGE_SHARED = pgprot_val(SUN4C_PAGE_SHARED);
BTFIXUPSET_INT(page_copy, pgprot_val(SUN4C_PAGE_COPY));
BTFIXUPSET_INT(page_readonly, pgprot_val(SUN4C_PAGE_READONLY));
BTFIXUPSET_INT(page_kernel, pgprot_val(SUN4C_PAGE_KERNEL));
diff --git a/include/asm-sparc/pgtable.h b/include/asm-sparc/pgtable.h
index a55f4c3..2cc235b 100644
--- a/include/asm-sparc/pgtable.h
+++ b/include/asm-sparc/pgtable.h
@@ -46,7 +46,6 @@ BTFIXUPDEF_SIMM13(user_ptrs_per_pgd)
 #define pgd_ERROR(e)   __builtin_trap()
 
 BTFIXUPDEF_INT(page_none)
-BTFIXUPDEF_INT(page_shared)
 BTFIXUPDEF_INT(page_copy)
 BTFIXUPDEF_INT(page_readonly)
 BTFIXUPDEF_INT(page_kernel)
@@ -66,7 +65,7 @@ BTFIXUPDEF_INT(page_kernel)
 #define PTE_SIZE   (PTRS_PER_PTE*4)
 
 #define PAGE_NONE  __pgprot(BTFIXUP_INT(page_none))
-#define PAGE_SHARED__pgprot(BTFIXUP_INT(page_shared))
+extern pgprot_t PAGE_SHARED;
 #define PAGE_COPY  __pgprot(BTFIXUP_INT(page_copy))
 #define PAGE_READONLY  __pgprot(BTFIXUP_INT(page_readonly))
 
-- 
1.5.3.GIT

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2o: defined but not used.

[Randy Dunlap]

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 test build.

This one is not impossible.  Patch looks good.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [9/58] x86_64: Always use builtin memcpy on gcc 4.3

[Oleg Verych]

* 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
empty. So, let me ask how this memcpy relates to recently submitted
for glibc one [0]?

[0] 

Also you are enabling rep. string operations for 10h family. Yet manual
says, that while they were improved, there are still various other
preferred optimization cases

Thanks.

> Cc: [EMAIL PROTECTED]
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
>  include/asm-x86_64/string.h |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DRIVER SUBMISSION] DRBD wants to go mainline

[Andi Kleen]

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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][24/37] Clean up duplicate includes in kernel/

[Paul E. McKenney]

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 --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 145cbb7..5f7dba2 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -45,7 +45,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 464c2b1..9eef513 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -45,7 +45,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  #include 
>  #include 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 25db14b..d8de12e 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> index 2c2dd84..5d9e07e 100644
> --- a/kernel/rcupdate.c
> +++ b/kernel/rcupdate.c
> @@ -45,7 +45,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> 
> diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
> index ddff332..dd413bf 100644
> --- a/kernel/rcutorture.c
> +++ b/kernel/rcutorture.c
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 998..e0b2456 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -27,7 +27,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> index 059431e..7d4d7f9 100644
> --- a/kernel/taskstats.c
> +++ b/kernel/taskstats.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/kernel/time.c b/kernel/time.c
> index 5b81da0..6304942 100644
> --- a/kernel/time.c
> +++ b/kernel/time.c
> @@ -34,7 +34,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  #include 
>  #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DRIVER SUBMISSION] DRBD wants to go mainline

[Lars Ellenberg]

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 it as RAID1 over TCP.
Typically you have one Node in Primary, the other as Secondary,
replication target only.
But you can also have both Active, for use with a cluster file system.

So the semantics are like you have
two (to come: N) nodes and a shared disk.
only that there is not one shared disk,
but two (N) replicated ones.

btw, regarding linux kernel CodingStyle issues.
scripts/checkpatch.pl reports 2000+ lines of complaints.
I'm working on it now, it is mostly whitespace (lame excuse: phil grew
up with emacs and gnu coding style, sorry for that).

-- 
: Lars EllenbergTel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH  Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europehttp://www.linbit.com :
__
please use the "List-Reply" function of your email client.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CTL_UNNUMBERED (Re: [PATCH] 9p: Don't use binary sysctl numbers.)

[Eric W. Biederman]

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 want a real binary
interface.  The 9p debug code picking of a semi-random number and not
patching it into sysctl.h like it should for a binary interface is
an implementation bug, and a maintenance problem.

Further it is a classic example of the silliness that goes on
when people actually try and add to the binary interface.

So not assigning a binary number very much looks like the right thing
to do for 9p.

I expect if the change had not happened in a mega patch to 9p that
seems to have changed everything the addition of a new user space
interface would more likely have been caught in a code review.



Now to the issue of using CTL_UNNUMBERED versus knowing that the magic
value is zero and we can just leave it uninitialized.  I don't much
care but given how often people who are not actively watching this
mess up I tend to prefer the explicit value.  It is a practical
question of how do we get the word out that we should not expand the
binary interface anymore. 

The only really practical way I can see us doing better then we are
today is to have a separate tree that maps binary numbers into ascii
strings and so we remove the ctl_name field entirely from ctl_table. 

That way people attempting to assign binary numbers using old
conventions will have code that doesn't even compile, and the
developers themselves are more likely to spot the problem.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

drivers/hwmon - 'defined but not used' warnings

[Gabriel C]

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/via686a.c:648: warning: 'via686a_remove' defined but not used
drivers/hwmon/vt8231.c:755: warning: 'vt8231_remove' defined but not used

...


Regards,

Gabriel C
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] take declarations of enable_irq() et.al. to linux/interrupt.h

[Al Viro]

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 PROTECTED]>
---
 arch/arm26/kernel/armksyms.c |2 --
 arch/arm26/kernel/irq.c  |6 ++
 arch/m68k/kernel/ints.c  |4 
 include/asm-alpha/irq.h  |4 
 include/asm-arm26/irq.h  |5 -
 include/asm-h8300/irq.h  |3 ---
 include/asm-ia64/irq.h   |3 ---
 include/asm-m68k/irq.h   |3 ---
 include/asm-sh64/irq.h   |4 
 include/asm-sparc/irq.h  |4 
 include/asm-v850/irq.h   |   10 --
 include/linux/interrupt.h|2 +-
 12 files changed, 11 insertions(+), 39 deletions(-)

diff --git a/arch/arm26/kernel/armksyms.c b/arch/arm26/kernel/armksyms.c
index f735d7e..fe1e3ce 100644
--- a/arch/arm26/kernel/armksyms.c
+++ b/arch/arm26/kernel/armksyms.c
@@ -107,8 +107,6 @@ EXPORT_SYMBOL(__bug);
 #endif
 EXPORT_SYMBOL(__bad_xchg);
 EXPORT_SYMBOL(__readwrite_bug);
-EXPORT_SYMBOL(enable_irq);
-EXPORT_SYMBOL(disable_irq);
 EXPORT_SYMBOL(set_irq_type);
 EXPORT_SYMBOL(pm_idle);
 EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm26/kernel/irq.c b/arch/arm26/kernel/irq.c
index d53382c..2ffe695 100644
--- a/arch/arm26/kernel/irq.c
+++ b/arch/arm26/kernel/irq.c
@@ -95,6 +95,11 @@ void disable_irq(unsigned int irq)
desc->enabled = 0;
spin_unlock_irqrestore(&irq_controller_lock, flags);
 }
+EXPORT_SYMBOL(disable_irq);
+
+void disable_irq_nosync(unsigned int irq) 
__attribute__((alias("disable_irq")));
+
+EXPORT_SYMBOL(disable_irq_nosync);
 
 /**
  * enable_irq - enable interrupt handling on an irq
@@ -131,6 +136,7 @@ void enable_irq(unsigned int irq)
}
spin_unlock_irqrestore(&irq_controller_lock, flags);
 }
+EXPORT_SYMBOL(enable_irq);
 
 int show_interrupts(struct seq_file *p, void *v)
 {
diff --git a/arch/m68k/kernel/ints.c b/arch/m68k/kernel/ints.c
index 60d4d75..2b41245 100644
--- a/arch/m68k/kernel/ints.c
+++ b/arch/m68k/kernel/ints.c
@@ -326,6 +326,10 @@ void disable_irq(unsigned int irq)
 
 EXPORT_SYMBOL(disable_irq);
 
+void disable_irq_nosync(unsigned int irq) 
__attribute__((alias("disable_irq")));
+
+EXPORT_SYMBOL(disable_irq_nosync);
+
 int m68k_irq_startup(unsigned int irq)
 {
if (irq <= IRQ_AUTO_7)
diff --git a/include/asm-alpha/irq.h b/include/asm-alpha/irq.h
index 917b9fe..0637740 100644
--- a/include/asm-alpha/irq.h
+++ b/include/asm-alpha/irq.h
@@ -85,10 +85,6 @@ static __inline__ int irq_canonicalize(int irq)
return ((irq == 2) ? 9 : irq);
 }
 
-extern void disable_irq(unsigned int);
-extern void disable_irq_nosync(unsigned int);
-extern void enable_irq(unsigned int);
-
 struct pt_regs;
 extern void (*perf_irq)(unsigned long, struct pt_regs *);
 
diff --git a/include/asm-arm26/irq.h b/include/asm-arm26/irq.h
index 9aaac87..52971b4 100644
--- a/include/asm-arm26/irq.h
+++ b/include/asm-arm26/irq.h
@@ -24,11 +24,6 @@
 
 struct irqaction;
 
-#define disable_irq_nosync(i) disable_irq(i)
-
-extern void disable_irq(unsigned int);
-extern void enable_irq(unsigned int);
-
 #define __IRQT_FALEDGE (1 << 0)
 #define __IRQT_RISEDGE (1 << 1)
 #define __IRQT_LOWLVL  (1 << 2)
diff --git a/include/asm-h8300/irq.h b/include/asm-h8300/irq.h
index 96600b0..5fb0599 100644
--- a/include/asm-h8300/irq.h
+++ b/include/asm-h8300/irq.h
@@ -59,7 +59,4 @@ static __inline__ int irq_canonicalize(int irq)
return irq;
 }
 
-extern void enable_irq(unsigned int);
-extern void disable_irq(unsigned int);
-
 #endif /* _H8300_IRQ_H_ */
diff --git a/include/asm-ia64/irq.h b/include/asm-ia64/irq.h
index 35b360b..a66d268 100644
--- a/include/asm-ia64/irq.h
+++ b/include/asm-ia64/irq.h
@@ -33,9 +33,6 @@ irq_canonicalize (int irq)
return ((irq == 2) ? 9 : irq);
 }
 
-extern void disable_irq (unsigned int);
-extern void disable_irq_nosync (unsigned int);
-extern void enable_irq (unsigned int);
 extern void set_irq_affinity_info (unsigned int irq, int dest, int redir);
 bool is_affinity_mask_valid(cpumask_t cpumask);
 
diff --git a/include/asm-m68k/irq.h b/include/asm-m68k/irq.h
index 4901cb1..eb29a52 100644
--- a/include/asm-m68k/irq.h
+++ b/include/asm-m68k/irq.h
@@ -59,9 +59,6 @@
 #define IRQ_USER   8
 
 extern unsigned int irq_canonicalize(unsigned int irq);
-extern void enable_irq(unsigned int);
-extern void disable_irq(unsigned int);
-#define disable_irq_nosync disable_irq
 
 struct pt_regs;
 
diff --git a/include/asm-sh64/irq.h b/include/asm-sh64/irq.h
index 1ca49e2..5c9e6a8 100644
--- a/include/asm-sh64/irq.h
+++ b/include/asm-sh64/irq.h
@@ -114,10 +114,6 @@
 #defineIRL0_PRIORITY   13
 #define TOP_PRIORITY   15
 
-extern void disable_irq(unsigned int);
-extern void disable_irq_nosync(unsigned int);
-extern void enable_irq(unsigned int);
-
 extern int intc_evt_to_irq[(0

[PATCH 2/3] take sparc32 enable_irq/disable_irq out of line

[Al Viro]

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  |4 ++--
 include/asm-sparc/irq.h |   32 +++-
 6 files changed, 49 insertions(+), 38 deletions(-)

diff --git a/arch/sparc/kernel/irq.c b/arch/sparc/kernel/irq.c
index 5e9af30..75b2240 100644
--- a/arch/sparc/kernel/irq.c
+++ b/arch/sparc/kernel/irq.c
@@ -270,7 +270,7 @@ void free_irq(unsigned int irq, void *dev_id)
kfree(action);
 
if (!sparc_irq[cpu_irq].action)
-   disable_irq(irq);
+   __disable_irq(irq);
 
 out_unlock:
spin_unlock_irqrestore(&irq_action_lock, flags);
@@ -466,7 +466,7 @@ int request_fast_irq(unsigned int irq,
 
sparc_irq[cpu_irq].action = action;
 
-   enable_irq(irq);
+   __enable_irq(irq);
 
ret = 0;
 out_unlock:
@@ -546,7 +546,7 @@ int request_irq(unsigned int irq,
 
*actionp = action;
 
-   enable_irq(irq);
+   __enable_irq(irq);
 
ret = 0;
 out_unlock:
@@ -557,6 +557,25 @@ out:
 
 EXPORT_SYMBOL(request_irq);
 
+void disable_irq_nosync(unsigned int irq)
+{
+   return __disable_irq(irq);
+}
+EXPORT_SYMBOL(disable_irq_nosync);
+
+void disable_irq(unsigned int irq)
+{
+   return __disable_irq(irq);
+}
+EXPORT_SYMBOL(disable_irq);
+
+void enable_irq(unsigned int irq)
+{
+   return __enable_irq(irq);
+}
+
+EXPORT_SYMBOL(enable_irq);
+
 /* We really don't need these at all on the Sparc.  We only have
  * stubs here because they are exported to modules.
  */
diff --git a/arch/sparc/kernel/irq.h b/arch/sparc/kernel/irq.h
index 8254a86..32ef3eb 100644
--- a/arch/sparc/kernel/irq.h
+++ b/arch/sparc/kernel/irq.h
@@ -1,11 +1,31 @@
 #include 
 
+/* Dave Redman ([EMAIL PROTECTED])
+ * changed these to function pointers.. it saves cycles and will allow
+ * the irq dependencies to be split into different files at a later date
+ * sun4c_irq.c, sun4m_irq.c etc so we could reduce the kernel size.
+ * Jakub Jelinek ([EMAIL PROTECTED])
+ * Changed these to btfixup entities... It saves cycles :)
+ */
+
+BTFIXUPDEF_CALL(void, disable_irq, unsigned int)
+BTFIXUPDEF_CALL(void, enable_irq, unsigned int)
 BTFIXUPDEF_CALL(void, disable_pil_irq, unsigned int)
 BTFIXUPDEF_CALL(void, enable_pil_irq, unsigned int)
 BTFIXUPDEF_CALL(void, clear_clock_irq, void)
 BTFIXUPDEF_CALL(void, clear_profile_irq, int)
 BTFIXUPDEF_CALL(void, load_profile_irq, int, unsigned int)
 
+static inline void __disable_irq(unsigned int irq)
+{
+   BTFIXUP_CALL(disable_irq)(irq);
+}
+
+static inline void __enable_irq(unsigned int irq)
+{
+   BTFIXUP_CALL(enable_irq)(irq);
+}
+
 static inline void disable_pil_irq(unsigned int irq)
 {
BTFIXUP_CALL(disable_pil_irq)(irq);
diff --git a/arch/sparc/kernel/sparc_ksyms.c b/arch/sparc/kernel/sparc_ksyms.c
index d8e008a..55bac51 100644
--- a/arch/sparc/kernel/sparc_ksyms.c
+++ b/arch/sparc/kernel/sparc_ksyms.c
@@ -154,8 +154,6 @@ EXPORT_SYMBOL(BTFIXUP_CALL(___xchg32));
 #else
 EXPORT_SYMBOL(BTFIXUP_CALL(__hard_smp_processor_id));
 #endif
-EXPORT_SYMBOL(BTFIXUP_CALL(enable_irq));
-EXPORT_SYMBOL(BTFIXUP_CALL(disable_irq));
 EXPORT_SYMBOL(BTFIXUP_CALL(mmu_unlockarea));
 EXPORT_SYMBOL(BTFIXUP_CALL(mmu_lockarea));
 EXPORT_SYMBOL(BTFIXUP_CALL(mmu_get_scsi_sgl));
diff --git a/arch/sparc/kernel/sun4d_irq.c b/arch/sparc/kernel/sun4d_irq.c
index 7a09186..e0efab2 100644
--- a/arch/sparc/kernel/sun4d_irq.c
+++ b/arch/sparc/kernel/sun4d_irq.c
@@ -190,7 +190,7 @@ void sun4d_free_irq(unsigned int irq, void *dev_id)
kfree(action);
 
if (!(*actionp))
-   disable_irq(irq);
+   __disable_irq(irq);
 
 out_unlock:
spin_unlock_irqrestore(&irq_action_lock, flags);
@@ -348,7 +348,7 @@ int sun4d_request_irq(unsigned int irq,
else
*actionp = action;

-   enable_irq(irq);
+   __enable_irq(irq);
 
ret = 0;
 out_unlock:
diff --git a/arch/sparc/kernel/tick14.c b/arch/sparc/kernel/tick14.c
index a55f046..707bfda 100644
--- a/arch/sparc/kernel/tick14.c
+++ b/arch/sparc/kernel/tick14.c
@@ -64,7 +64,7 @@ void claim_ticker14(irq_handler_t handler,
 
/* first we copy the obp handler instructions
 */
-   disable_irq(irq_nr);
+   __disable_irq(irq_nr);
if (!handler)
return;
 
@@ -81,6 +81,6 @@ void claim_ticker14(irq_handler_t handler,
 NULL)) {
install_linux_ticker();
load_profile_irq(cpu, timeout);
-   enable_irq(irq_nr);
+   __enable_irq(irq_nr);
}
 }
diff --git a/include/asm-sparc/irq.h b/include/asm-sparc/irq.h
index 4582793..afb88a5 100644
--- a/include/asm-sparc/irq.h
+++ b/include/asm-sparc/irq.h
@@ -7,41 +7,15 @@
 #ifndef _SPARC_IRQ_H
 #

[PATCH 1/3] clean include/asm-sparc/irq.h

[Al Viro]

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/sparc/kernel/pcic.c  |1 +
 arch/sparc/kernel/smp.c   |2 +
 arch/sparc/kernel/sun4c_irq.c |   15 +
 arch/sparc/kernel/sun4d_irq.c |2 +
 arch/sparc/kernel/sun4d_smp.c |1 +
 arch/sparc/kernel/sun4m_irq.c |   74 ++
 arch/sparc/kernel/sun4m_smp.c |2 +
 arch/sparc/kernel/tick14.c|2 +
 arch/sparc/kernel/time.c  |2 +
 include/asm-sparc/irq.h   |  136 -
 12 files changed, 151 insertions(+), 136 deletions(-)
 create mode 100644 arch/sparc/kernel/irq.h

diff --git a/arch/sparc/kernel/irq.c b/arch/sparc/kernel/irq.c
index f257a67..5e9af30 100644
--- a/arch/sparc/kernel/irq.c
+++ b/arch/sparc/kernel/irq.c
@@ -47,6 +47,8 @@
 #include 
 #include 
 
+#include "irq.h"
+
 #ifdef CONFIG_SMP
 #define SMP_NOP2 "nop; nop;\n\t"
 #define SMP_NOP3 "nop; nop; nop;\n\t"
diff --git a/arch/sparc/kernel/irq.h b/arch/sparc/kernel/irq.h
new file mode 100644
index 000..8254a86
--- /dev/null
+++ b/arch/sparc/kernel/irq.h
@@ -0,0 +1,48 @@
+#include 
+
+BTFIXUPDEF_CALL(void, disable_pil_irq, unsigned int)
+BTFIXUPDEF_CALL(void, enable_pil_irq, unsigned int)
+BTFIXUPDEF_CALL(void, clear_clock_irq, void)
+BTFIXUPDEF_CALL(void, clear_profile_irq, int)
+BTFIXUPDEF_CALL(void, load_profile_irq, int, unsigned int)
+
+static inline void disable_pil_irq(unsigned int irq)
+{
+   BTFIXUP_CALL(disable_pil_irq)(irq);
+}
+
+static inline void enable_pil_irq(unsigned int irq)
+{
+   BTFIXUP_CALL(enable_pil_irq)(irq);
+}
+
+static inline void clear_clock_irq(void)
+{
+   BTFIXUP_CALL(clear_clock_irq)();
+}
+
+static inline void clear_profile_irq(int irq)
+{
+   BTFIXUP_CALL(clear_profile_irq)(irq);
+}
+
+static inline void load_profile_irq(int cpu, int limit)
+{
+   BTFIXUP_CALL(load_profile_irq)(cpu, limit);
+}
+
+extern void (*sparc_init_timers)(irq_handler_t lvl10_irq);
+
+extern void claim_ticker14(irq_handler_t irq_handler,
+  int irq,
+  unsigned int timeout);
+
+#ifdef CONFIG_SMP
+BTFIXUPDEF_CALL(void, set_cpu_int, int, int)
+BTFIXUPDEF_CALL(void, clear_cpu_int, int, int)
+BTFIXUPDEF_CALL(void, set_irq_udt, int)
+
+#define set_cpu_int(cpu,level) BTFIXUP_CALL(set_cpu_int)(cpu,level)
+#define clear_cpu_int(cpu,level) BTFIXUP_CALL(clear_cpu_int)(cpu,level)
+#define set_irq_udt(cpu) BTFIXUP_CALL(set_irq_udt)(cpu)
+#endif
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index 7917711..f2eae45 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 
+#include "irq.h"
 
 /*
  * I studied different documents and many live PROMs both from 2.30
diff --git a/arch/sparc/kernel/smp.c b/arch/sparc/kernel/smp.c
index 4fea3ac..6724ab9 100644
--- a/arch/sparc/kernel/smp.c
+++ b/arch/sparc/kernel/smp.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include "irq.h"
+
 int smp_num_cpus = 1;
 volatile unsigned long cpu_callin_map[NR_CPUS] __initdata = {0,};
 unsigned char boot_cpu_id = 0;
diff --git a/arch/sparc/kernel/sun4c_irq.c b/arch/sparc/kernel/sun4c_irq.c
index 009e891..5734a02 100644
--- a/arch/sparc/kernel/sun4c_irq.c
+++ b/arch/sparc/kernel/sun4c_irq.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include "irq.h"
 
 #include 
 #include 
@@ -40,6 +41,20 @@ static struct resource sun4c_timer_eb = { "sun4c_timer" };
 static struct resource sun4c_intr_eb = { "sun4c_intr" };
 #endif
 
+/* 
+ * Bit field defines for the interrupt registers on various
+ * Sparc machines.
+ */
+
+/* The sun4c interrupt register. */
+#define SUN4C_INT_ENABLE  0x01 /* Allow interrupts. */
+#define SUN4C_INT_E14 0x80 /* Enable level 14 IRQ. */
+#define SUN4C_INT_E10 0x20 /* Enable level 10 IRQ. */
+#define SUN4C_INT_E8  0x10 /* Enable level 8 IRQ. */
+#define SUN4C_INT_E6  0x08 /* Enable level 6 IRQ. */
+#define SUN4C_INT_E4  0x04 /* Enable level 4 IRQ. */
+#define SUN4C_INT_E1  0x02 /* Enable level 1 IRQ. */
+
 /* Pointer to the interrupt enable byte
  *
  * Dave Redman ([EMAIL PROTECTED])
diff --git a/arch/sparc/kernel/sun4d_irq.c b/arch/sparc/kernel/sun4d_irq.c
index 396797e..7a09186 100644
--- a/arch/sparc/kernel/sun4d_irq.c
+++ b/arch/sparc/kernel/sun4d_irq.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 
+#include "irq.h"
+
 /* If you trust current SCSI layer to handle different SCSI IRQs, enable this. 
I don't trust it... -jj */
 /* #define DISTRIBUTE_IRQS */
 
diff --git a/arch/sparc/kernel/sun4d_smp.c b/arch/sparc/kernel/sun4d_smp.c
index 098c94f..89a6de9 100644
--- a/arch/sparc/kernel/sun4d_smp.c
+++ b/arch/sparc/kernel/sun4d_smp.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 
+#include "i

[PATCH] 3c59x, check return of pci_enable_device()

[Mark Hindley]

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
index f26ca33..192e74b 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1490,13 +1490,17 @@ vortex_up(struct net_device *dev)
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp->ioaddr;
unsigned int config;
-   int i, mii_reg1, mii_reg5;
+   int i, mii_reg1, mii_reg5, err;
 
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
if (vp->pm_state_valid)
pci_restore_state(VORTEX_PCI(vp));
-   pci_enable_device(VORTEX_PCI(vp));
+   err = pci_enable_device(VORTEX_PCI(vp));
+   if (err) {
+   printk(KERN_WARNING "%s: Could not enable device \n",
+   dev->name);
+   }
}
 
/* Before initializing select the active media port. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Oleg Verych]

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 files. We know how obfuscated C can be, and this also
> > applies to preprocessing. There's known CodingStyle about some points.
> > The thing is to specify rules, that will be easy for `sed` to do cleaup
> > job.
> > 
> > ./linux/soundcard.h:#if (!defined(__KERNEL__) && !defined(KERNEL) && 
> > !defined(INKERNEL)
> >   && !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
> > ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ 
> > < 2)
> > 
> > Split __KERNEL__ check, make only positive, i.e.
> > 
> > #if defined(__KERNEL__)
> > #ifdef __KERNEL__
> > 
> > ./linux/stat.h:#ifdef __KERNEL__
> > 
> > No `#else` and ending part to contain comment:
> > 
> > ./linux/smb_fs_sb.h:#endif /* __KERNEL__ */
> > 
> > Simple enough:
> > 
> > sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'
> 
> What are you trying to say with the above?
> Sorry but I lost track of part of the discussion but you seems to havea point 
> here?

I want to suggest more easy and tools-friendly way of processing header
files in the headrer_install target. One line above, one paragraph in
CodingStyle, one tree revision from KJ group.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

[Matt Mackall]

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 the source code. To do this we consciously aimed for the 
> strictest possible unification strategy: we only 'unified' those source 
> files that are already bit for bit equal between the two architectures 
> today. For all other files we used the following rule: if a file came 
> from arch/i386/foo/bar.c, it gets moved to arch/x86/foo/bar_32.c, if it 
> came from arch/x86_64/foo/bar.c it gets moved to arch/x86/foo/bar_64.c. 
> We also generated arch/x86/foo/bar.c that simply #include's those two 
> files (depending on whether we do a 32-bit or a 64-bit built). If a file 
> only existed in only one of the architectures, it's moved to 
> arch/x86/foo/bar.c straight away. (take a look at our git repository to 
> see how this works out in practice.)

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?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Create clflush() inline, remove hardcoded wbinvd

[H. Peter Anvin]

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 one calls clflush with (adr + i), the new one with (*(adr
>> + i)). Are these calls equivalent?
> 
> Yes, they are.  The parentheses which are part of the old assembly
> string has the same effect as the asterisk operator in C.
> 
> The difference between the two is that the latter form allows the C
> compiler to select the addressing mode, which allows the full range of
> addressing modes, whereas the former forces it to use a single register
> indirect.
> 

Just to be absolutely obvious about it:

: tazenda 15 ; cat demo.c
#define __force

static inline void clflush1(volatile void *__p)
{
asm volatile("clflush %0" : "+m" (*(char __force *)__p));
}

static inline void clflush2(volatile void *__p)
{
asm volatile("clflush (%0)" :: "r" (__p));
}

void demo(void *q)
{
clflush1(q);
clflush2(q);
}
: tazenda 16 ; gcc -m32 -O3 -S demo.c
: tazenda 17 ; cat demo.s
.file   "demo.c"
.text
.p2align 4,,15
.globl demo
.type   demo, @function
demo:
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
#APP
clflush (%eax)
clflush (%eax)
#NO_APP
popl%ebp
ret
.size   demo, .-demo
.ident  "GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-13)"
.section.note.GNU-stack,"",@progbits
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][hid] Fix a NULL pointer dereference when we fail to allocate memory

[Jesper Juhl]

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_free_urb(usbhid->urbctrl);
Since we got here because we couldn't allocate storage for 'usbhid', 
what we have here is a NULL pointer dereference - ouch...

This patch solves that little problem by adding a new 
'fail_no_usbhid:' label after the problematic calls to 
usb_free_urb() and jumps to that one instead, in the problem case.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 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-core.c
@@ -743,7 +743,7 @@ static struct hid_device *usb_hid_configure(struct 
usb_interface *intf)
hid->quirks = quirks;
 
if (!(usbhid = kzalloc(sizeof(struct usbhid_device), GFP_KERNEL)))
-   goto fail;
+   goto fail_no_usbhid;
 
hid->driver_data = usbhid;
usbhid->hid = hid;
@@ -877,6 +877,7 @@ fail:
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbout);
usb_free_urb(usbhid->urbctrl);
+fail_no_usbhid:
hid_free_buffers(dev, hid);
hid_free_device(hid);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: Hibernation considerations

[Nigel Cunningham]

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 that this situation is unlikely, and perhaps acceptable.
> 
> A larger concern is that it seems that freezing FUSE processes at all
> _will_ generate deadlocks if a non-synchronous or memory-map-supporting
> filesystem is loopback mounted from a FUSE filesystem.  In that case, if
> you attempt to sync or free memory once FUSE is frozen, you are sure to
> get a deadlock.

Ok. So then (in response to Alan too), how about keeping a tree of mounts, 
akin to the device tree, and working from the deepest nodes up? (In 
conjunction with what I already suggested)?

Regards,

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.


pgp1DubIOeAxL.pgp
Description: PGP signature

Re: [linux-pm] Re: Hibernation considerations

[Nigel Cunningham]

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 admit that this situation is unlikely, and perhaps acceptable.
> 
> It isn't all that unlikely.  There's sshfs for example, that depends
> on a separate ssh process for transport.
> 
> Oh, there are also userspace network transports, like tun/tap,
> nfqueue, etc.  They could block any network filesystem (not just fuse)
> if frozen first, making the freezer fail.
> 
> Hmm, wonder why this isn't affecting people with VPNs?  Probably
> network mounts over VPN are rare, and ever rarer to have fs activity
> on them during suspend.
> 
> Anyway, I think it's long overdue to stop thinking about how to "fix"
> fuse, and concentrate on fixing the underlying problem instead ;)

That's what I'm seeking to do :)

> > A larger concern is that it seems that freezing FUSE processes at all
> > _will_ generate deadlocks if a non-synchronous or memory-map-supporting
> > filesystem is loopback mounted from a FUSE filesystem.  In that case, if
> > you attempt to sync or free memory once FUSE is frozen, you are sure to
> > get a deadlock.
> 
> Well, it would deadlock, if
> 
>  a) memory reclaim was synchronous, or
>  b) large part of the memory was used for dirty file data

These are problems in normal operation, aren't they?
 
> I can't remember if (a) was ever true.  And now the dirty ratio is 10%
> by default, so if we go OOM because that 10% can't be reclaimed, there
> is a more serious problem.
> 
> Swap over loop over fuse would be problematic, but that won't work for
> some time yet ;)

Hopefully people will wake up to the problems with Fuse and get rid of it 
before then :|. Of course I don't really expect that to happen.

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.


pgpOpIxpZQh0t.pgp
Description: PGP signature

Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

[Robert P. J. Day]

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 
> > > >unifdef.
> > > >There is no good reason to have two different preprocesisng methonds, one
> > > >being the sed based one and the other the unidef one.
> > > >
> > > >A sinlge dedicated program that contian the sum of the functionality 
> > > >would
> > > >be faster too.
> > >
> > > which functionality ?  normalizing of whitespace or all these
> > > linux-specific hacks ?  unifdef serves one specific function which is
> > > stated in its manpage: remove preprocessor conditionals from code.
> >
> > At present the kernel has a private copy of unidef. So adjusting the
> > private copy for the needs of the kernels seems like a god plan.
>
> didnt realize the kernel had integrated it since it didnt at first ...
> so yeah, extending it however we see fit should be fine
> -mike

just for the entertainment value:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217840

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Mike Frysinger]

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 claims could possibly be backed up

Less \{\(\\n\t\+\)\} [0] stuff make readings regex much easier. My
confusion shows that i didn't used \{ much, because have another ways
so far. And even after my quick testing i didn't realize that there
was unrelated to main task whitespace cleanup.


the e-mail text you were quoting was [[:blank:]] vs [[:space:]], not + vs \{1,\}


./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)


__GLIBC__ cruft should be cleansed rather than looked at for anything else
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hibernation considerations

[david]

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.  Then battery status and such should be
correct, since they are correct after normal initialization.

It should be possible to make hibernate look just like a reboot to all
of the devices, including ACPI stuff.


Patch to make that work with swsusp/shutdown method would be indeed
welcome. It does not work today.


is this a problem in the restore path?

with the kexec approach (and ignoring suspend to ram and disk for the
moment) the system will actually get shutdown completely after the image
is written. on resume it gets cold booted. at this point the ACPI stuff
should have no problem

now if the ACPI drivers are storing something in ram about the battery
status and AC power status, but don't re-check after the resume, it
seems


That seems to be the problem. They store something in ram, and we
don't tell them that we resumed. That's why platform mode is
important, and way to go on ACPI systems.


this sounds like the few drivers that do this sort of thing (and this 
should only be the things that report status, drivers that enable devices 
should be taken care of) need a 'forget what you think you know, check the 
reality of the hardware' function.


even without suspend I've sen these drivers get out of sync with reality, 
and so such a function call would be useful to get them back in sync in 
any case.


if such a 'check reality' function was available it should be 
straightforward to call it after a non-ACPI hibrnate/resume


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC, Announce] Unified x86 architecture, arch/x86

[Oleg Verych]

* 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 <[EMAIL PROTECTED]> wrote:
>
>> I agree with Andi...  it's quite nice to be able to leave some arch/i386 
>> stuff, and not carry it over to arch/x86-64.
>
> Its easy enough to push that stuff into arch/x86/legacy and have one
> subdirectory of stuff to pull in for ancient systems.

Or if i386 and virualization guys don't want to quietly break/mess with
stuff pulled by x86-64, move it to x86-64 instead. Elegant, easy, honors
Andi.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Sam Ravnborg]

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 preprocessing. There's known CodingStyle about some points.
> The thing is to specify rules, that will be easy for `sed` to do cleaup
> job.
> 
> ./linux/soundcard.h:#if (!defined(__KERNEL__) && !defined(KERNEL) && 
> !defined(INKERNEL)
>   && !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
> ./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 
> 2)
> 
> Split __KERNEL__ check, make only positive, i.e.
> 
> #if defined(__KERNEL__)
> #ifdef __KERNEL__
> 
> ./linux/stat.h:#ifdef __KERNEL__
> 
> No `#else` and ending part to contain comment:
> 
> ./linux/smb_fs_sb.h:#endif /* __KERNEL__ */
> 
> Simple enough:
> 
> sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'

What are you trying to say with the above?
Sorry but I lost track of part of the discussion but you seems to havea point 
here?

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

[Mike Frysinger]

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 preprocesisng methonds, one
> >being the sed based one and the other the unidef one.
> >
> >A sinlge dedicated program that contian the sum of the functionality would
> >be faster too.
>
> which functionality ?  normalizing of whitespace or all these
> linux-specific hacks ?  unifdef serves one specific function which is
> stated in its manpage: remove preprocessor conditionals from code.

At present the kernel has a private copy of unidef. So adjusting the
private copy for the needs of the kernels seems like a god plan.


didnt realize the kernel had integrated it since it didnt at first ...
so yeah, extending it however we see fit should be fine
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

voyager_{thread,cat}.c compile warnings

[Gabriel C]

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-voyager/voyager_cat.c: In function 'voyager_cat_init':
arch/i386/mach-voyager/voyager_cat.c:685: warning: comparison is always false 
due to limited range of data type
arch/i386/mach-voyager/voyager_cat.c:755: warning: comparison is always false 
due to limited range of data type

...


Regards,

Gabriel C

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22.1-rt4 lockups

[Rui Nuno Capela]

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 of occurrences were all while browsing with firefox
(2.0.0.5) or using openoffice.org (2.0.4) but in rare and
non-deterministic fashion I must say.

It looks very similar to the previous ones I've reported before for
-rt3, but I am no expert in these things.

...
Oops:  [#1]
PREEMPT SMP
Modules linked in: tun appletalk ax25 ipx p8023 snd_rtctimer
snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq_midi snd_seq_midi_event
snd_seq w83627hf hwmon_vid hwmon eeprom button battery ac loop dm_mod
wacom usbhid hid ff_memless ohci1394 ieee1394 nvidia(P) snd_cs46xx
gameport firewire_ohci snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda
snd_cs8427 snd_i2c snd_mpu401_uart snd_rawmidi snd_seq_device
firewire_core sk98lin snd_intel8x0 crc_itu_t snd_ac97_codec ac97_bus
ide_cd snd_pcm cdrom snd_timer uhci_hcd ehci_hcd i2c_i801 snd rtc_cmos
shpchp iTCO_wdt i2c_core usbcore rtc_core pci_hotplug soundcore
intel_agp rtc_lib agpgart snd_page_alloc ext3 mbcache jbd edd fan piix
thermal processor ide_disk ide_core
CPU:0
EIP:0060:[<>]Tainted: P   VLI
EFLAGS: 00213006   (2.6.22.1-rt4.0 #1)
EIP is at _stext+0x3feff000/0x20
eax: c1812a80   ebx: c03bb540   ecx: 0001   edx: c038e3c0
esi: c038e3c0   edi: 0001   ebp: f6fe1d6c   esp: f6fe1d50
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068  preempt:0003
Process Xorg (pid: 4101, ti=f6fe1000 task=f754ec30 task.ti=f6fe1000)
Stack: c011a94c 04882eab 0ca9 c1812a80 c1812a80 04882eab 0ca9
f6fe1d90
   c011b4af 04882eab 0ca9 0001 c038e3c0  
c038e3c0
   f6fe1df4 c011e09d f6fe1dfc c011de3b  001f c1812a80
001f
Call Trace:
 [] show_trace_log_lvl+0x1a/0x30
 [] show_stack_log_lvl+0xb6/0xe0
 [] show_registers+0x201/0x330
 [] die+0x118/0x260
 [] do_page_fault+0x193/0x600
 [] error_code+0x72/0x78
 [] activate_task+0x4f/0xb0
 [] try_to_wake_up+0x2bd/0x420
 [] wake_up_process_mutex+0x19/0x20
 [] wakeup_next_waiter+0xec/0x1a0
 [] rt_spin_lock_slowunlock+0x4c/0x70
 [] rt_spin_unlock+0x26/0x30
 [] put_zone_pcp+0x14/0x20
 [] get_page_from_freelist+0x145/0x380
 [] __alloc_pages+0x54/0x2d0
 [] __handle_mm_fault+0x7dd/0x9a0
 [] do_page_fault+0x2f8/0x600
 [] error_code+0x72/0x78
 ===
Code:  Bad EIP value.
EIP: [<>] _stext+0x3feff000/0x20 SS:ESP 0068:f6fe1d50
NMI watchdog detected lockup on CPU#1 (5000/5000)
...


Complete serial console capture:

  http://www.rncbc.org/datahub/console-2.6.22.1-rt4.0-1.log

.config evidence:

  http://www.rncbc.org/datahub/config-2.6.22.1-rt4.0

Cheers.
--
rncbc aka Rui Nuno Capela
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][09/37] Clean up duplicate includes in drivers/macintosh/

[Benjamin Herrenschmidt]

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 b/drivers/macintosh/rack-meter.c
> index 4177ff0..2c21d4f 100644
> --- a/drivers/macintosh/rack-meter.c
> +++ b/drivers/macintosh/rack-meter.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: Create clflush() inline, remove hardcoded wbinvd

[H. Peter Anvin]

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 + i), the new one with (*(adr
> + i)). Are these calls equivalent?

Yes, they are.  The parentheses which are part of the old assembly
string has the same effect as the asterisk operator in C.

The difference between the two is that the latter form allows the C
compiler to select the addressing mode, which allows the full range of
addressing modes, whereas the former forces it to use a single register
indirect.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

[Sam Ravnborg]

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 Frysinger wrote:
> >> >[]
> >> >> if you want to make some micro optimization in the build install step,
> >> >> sure ... but functionally, the difference is irrelevant considering
> >> >> sed operates only on individual lines
> >> >
> >> >That was an attempt to support less sucking userspace in the kernel
> >> >development. More readable, more memory/cpu effective, more portable.
> >>
> >> 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
> >>
> >> but again, if you feel that strongly about it, you're certainly free
> >> to post a patch
> >
> >I would much more prefer this functionality to be integrated into unifdef.
> >There is no good reason to have two different preprocesisng methonds, one
> >being the sed based one and the other the unidef one.
> >
> >A sinlge dedicated program that contian the sum of the functionality would
> >be faster too.
> 
> which functionality ?  normalizing of whitespace or all these
> linux-specific hacks ?  unifdef serves one specific function which is
> stated in its manpage: remove preprocessor conditionals from code.

At present the kernel has a private copy of unidef. So adjusting the
private copy for the needs of the kernels seems like a god plan.
We could even make it an extension so we do not break current
functionality.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: from where comes "__moddi3"?

[Arjan van de Ven]

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 
> that the compiler should recognize for native integral types.

for unsigned ones for sure yes... but the original question was about 15
not 16.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

More effective processing (Re: [PATCH 25/33] kbuild: use POSIX BRE in headers install target)

[Oleg Verych]

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\+\)\} [0] stuff make readings regex much easier. My
confusion shows that i didn't used \{ much, because have another ways
so far. And even after my quick testing i didn't realize that there
was unrelated to main task whitespace cleanup.

[0] http://sed.sf.net/grabbag/tutorials/lookup_tables.txt

> > but again, if you feel that strongly about it, you're certainly free
> > to post a patch
> 
> I would much more prefer this functionality to be integrated into unifdef.
> There is no good reason to have two different preprocesisng methonds, one
> being the sed based one and the other the unidef one.

Clear definition of the task will help to design a solution. I can do
the job, but figuring out all possible corner cases from current
solutions, mixed in Makefiles or everywhere else is not option.

> A sinlge dedicated program that contian the sum of the functionality would
> be faster too.

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 preprocessing. There's known CodingStyle about some points.
The thing is to specify rules, that will be easy for `sed` to do cleaup
job.

./linux/soundcard.h:#if (!defined(__KERNEL__) && !defined(KERNEL) && 
!defined(INKERNEL)
  && !defined(_KERNEL)) || defined(USE_SEQ_MACROS)
./linux/stat.h:#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)

Split __KERNEL__ check, make only positive, i.e.

#if defined(__KERNEL__)
#ifdef __KERNEL__

./linux/stat.h:#ifdef __KERNEL__

No `#else` and ending part to contain comment:

./linux/smb_fs_sb.h:#endif /* __KERNEL__ */

Simple enough:

sed '/^#if[^_]*__KERNEL__/,/^#end[^_]*__KERNEL__/d'

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] [PATCH 25/33] kbuild: use POSIX BRE in headers install target

[Mike Frysinger]

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 build install step,
> >> sure ... but functionally, the difference is irrelevant considering
> >> sed operates only on individual lines
> >
> >That was an attempt to support less sucking userspace in the kernel
> >development. More readable, more memory/cpu effective, more portable.
>
> 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
>
> but again, if you feel that strongly about it, you're certainly free
> to post a patch

I would much more prefer this functionality to be integrated into unifdef.
There is no good reason to have two different preprocesisng methonds, one
being the sed based one and the other the unidef one.

A sinlge dedicated program that contian the sum of the functionality would
be faster too.


which functionality ?  normalizing of whitespace or all these
linux-specific hacks ?  unifdef serves one specific function which is
stated in its manpage: remove preprocessor conditionals from code.
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: what does select statement mean in Kconfig file?

[Stefan Richter]

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 depending on common dependency?
> 
> Something like
> 
> config A
>   bool XXX
>   depends on ARM
> 
> config B
>   depends on ARM
>   select A
> 
> 
> or:
> 
> if ARM
>   config A
>   bool XXX
> endif
> 
> if ARM
>   config B
>   select A
> endif

That's OK.  Or generally, if A depends on X and B wants to select A,
then it has to be guaranteed by whatever means that X is enabled,
because "make XYZconfig" cannot select recursively.  Duplicating A's
dependencies as dependencies for B is one way to ensure that A's
dependencies are satisfied when B selects A.  Another way is to select
not only A but also A's dependencies.

That's why I wrote "/shouldn't/ depend on further options" rather than
"/must not/ depend on further options".

But whatever you do, as soon as you add a "select A", you have to watch
if anybody eventually makes A dependent on something else.  Therefore
think twice before you use select.

Also, while select makes it easy for users to enable options, it makes
it somewhat difficult for users to /disable/ options.  So there are also
tradeoffs in usability.  This essentially means that you should never
select huge subsystems.  As I said, only library-like helpers are
suitable for select.
-- 
Stefan Richter
-=-=-=== -=== =-=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CTL_UNNUMBERED (Re: [PATCH] 9p: Don't use binary sysctl numbers.)

[Andrew Morton]

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 that did not properly register it's sysctl binary numbers,
> > and since it was only for debugging clearly did not need a binary fast
> > path in any case.  So this patch just remove the binary numbers.
> >
> > See Documentation/sysctl/ctl_unnumbered.txt for more details.
> >
> > While I was at it I cleaned up the sysctl initializers a little as
> > well so there is less to read.
> 
> > --- a/net/9p/sysctl.c
> > +++ b/net/9p/sysctl.c
> > @@ -28,15 +28,10 @@
> 
> > -enum {
> > -   P9_SYSCTL_NET = 487,
> > -   P9_SYSCTL_DEBUG = 1,
> > -};
> > -
> > -static ctl_table p9_table[] = {
> > +static struct ctl_table p9_table[] = {
> >  #ifdef CONFIG_NET_9P_DEBUG
> > {
> > -   .ctl_name   = P9_SYSCTL_DEBUG,
> > +   .ctl_name   = CTL_UNNUMBERED,
> 
> 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.
> 
>   {
>   .procname   = "prove_locking",
>   .data   = &prove_locking,
>   .maxlen = sizeof(int),
>   .mode   = 0644,
>   .proc_handler   = &proc_dointvec,
>   },
> 
> Or too late for -rc1?

It might be too late for -rc1 but it isn't too late for 2.6.23.

This affects a userspace interface.  Let's get it right please,
no rush.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] PXA27x UDC driver GIT repository

[David Brownell]

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 patches to resolve that issue get contributed soonish.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [DRIVER SUBMISSION] DRBD wants to go mainline

[Jesper Juhl]

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 patches through scripts/checkpatch.pl - it shows a
lot of style problems. Fixing those up would probably be a good step
towards mainline.  Remember, checkpatch.pl is not the law - in some
situations what it complains about can be totally valid, but usually
what it highlights is stuff that it is prefered to clean up (I'd say
especially now prior to inclusion so we don't have to do it post
inclusion).

A few of your files suffer from trailing whitespace at the end of lines.

It's interresting to build your code with -W. It shows up quite a few
signed vs unsigned comparisons, unused parameters, expressions that
are always false, etc.  Although I doubt anyone is going to complain
too loudly about stuff that only shows up with "-W", cleaning it up
can't hurt.


--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Final glitch1 report WRT cfs

[Bill Davidsen]

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 the older 
version, I'm going to put my efforts into other characterizations. The 
test source will remain on the server, but I'm won't do more with it 
unless someone finds it useful.


--
Bill Davidsen <[EMAIL PROTECTED]>
 "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] mm: Remove slab destructors from kmem_cache_create().

[Matt Mackall]

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, otherwise it wouldn't have
worked.

But good riddance to destructors nonetheless.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] readahead: drop behind

[Eric St-Laurent]

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 reclaim pages that were loaded in a strong
> sequential pattern and have been consumed. Thereby limiting the damage
> to the current resident set.
> 
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>

With the fadvise change, it looks like the right solution to me.

The patches are for which kernel? They doesn't apply cleanly to
2.6.22.1.

It would be useful to have a temporary /proc tunable to enable/disable
the heuristic to help test the effects.


- Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: from where comes "__moddi3"?

[David Schwartz]

> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: what does select statement mean in Kconfig file?

[Krzysztof Halasa]

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?

Something like

config A
bool XXX
depends on ARM

config B
depends on ARM
select A


or:

if ARM
config A
bool XXX
endif

if ARM
config B
select A
endif
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/