Re: Linux 2.6.22-rc1

2007-05-16 Thread Len Brown
On Sunday 13 May 2007 05:20, Jan Engelhardt wrote:
> On May 12 2007 20:20, Linus Torvalds wrote:
> >
> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
> 
> I have hit a randconfig compile failure. .config attached.
> 
>   LD  .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_bus_generate_event':
> (.text+0x233f7): undefined reference to `event_is_open'
> drivers/built-in.o: In function `acpi_bus_get_power':
> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x237c3): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x23835): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> make: *** [.tmp_vmlinux1] Error 1

CONFIG_PM=n
CONFIG_ACPI=y

not possible.
"select" in Kconfig is broken.

http://lkml.org/lkml/2007/4/28/28

-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/


CONFIG_BREAK_MY_MACHINE was Re: Linux 2.6.22-rc1

2007-05-16 Thread Pavel Machek
Hi!

> > Hardware Monitoring support  --->
> >   <*> Hardware Monitoring support
> >   <*> Abit uGuru
> >VIA686A
> >   <*> IBM Hard Drive Active Protection System (hdaps)
> > 
> > But I'm quite sure that the only module used is VIA686A (I'm
> > rebuilding to confirm).
> 
> This is a rather bad idea to build the abituguru and hdaps drivers into
> your kernel if you don't have these devices. Especially abituguru, as
> it does arbitrary port probing.

hdaps should be safe (DMI based whitelist, no?)

If abitguru breaks random machines, we probably should DMI whitelist,
too.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: Linux 2.6.22-rc1

2007-05-16 Thread Satyam Sharma

On 5/16/07, Stefan Richter <[EMAIL PROTECTED]> wrote:

Satyam Sharma wrote:
> * Also, some "[MENU]" kind of prefix/tag in the text of configmenu
> options would also be nice.

This belongs into the UIs, not into Kconfigs.
And it'd not just be nice, it's a requirement.


Indeed. "make menuconfig" interprets them specially (suffixes "--->")
and so does "xconfig". Just that the non-curses/graphics-based
scripts/kconfig/conf.c also needs to be taught to treat them specially
and tag something to them. Gaah. What was I smoking ...
-
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 2.6.22-rc1

2007-05-16 Thread Satyam Sharma

On 5/16/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:

Am 16.05.2007 03:39 schrieb Satyam Sharma:
["default n" for menuconfig]
> these problems would occur only the _first_ time someone
> transitions from the old .config's to the new scheme. But those
> "default y"s for all the various "configmenu"s (let's please call
> them that) that got introduced in the Kconfig files would cause
> unnecessary annoyance to users of make oldconfig _for ever_.

I'm not sure I'm following you. Where would that annoyance occur?
On subsequent uses of "make oldconfig" the default shouldn't even
matter, as the previous choice would just silently be kept.


Aargh, you're right. The prompt'll come only if it's a "(NEW)"
configmenu addition and hence not come after the first time either.
-
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 2.6.22-rc1

2007-05-16 Thread Tilman Schmidt
Am 16.05.2007 03:39 schrieb Satyam Sharma:
["default n" for menuconfig]
> these problems would occur only the _first_ time someone
> transitions from the old .config's to the new scheme. But those
> "default y"s for all the various "configmenu"s (let's please call
> them that) that got introduced in the Kconfig files would cause
> unnecessary annoyance to users of make oldconfig _for ever_.

I'm not sure I'm following you. Where would that annoyance occur?
On subsequent uses of "make oldconfig" the default shouldn't even
matter, as the previous choice would just silently be kept.

-- 
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: Linux 2.6.22-rc1

2007-05-15 Thread Stefan Richter
Satyam Sharma wrote:
> * Also, some "[MENU]" kind of prefix/tag in the text of configmenu
> options would also be nice.

This belongs into the UIs, not into Kconfigs.
And it'd not just be nice, it's a requirement.
-- 
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: Fwd: Re: Linux 2.6.22-rc1

2007-05-15 Thread Mattia Dongili
On Tue, May 15, 2007 at 10:46:21AM -0700, Randy Dunlap wrote:
> On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote:
...
> > Given the drivers/acpi/Kconfig portion
> > 
> >   if ACPI
> >   ...
> >   config ACPI_EC
> >   bool
> >   default y
> >   help
> > ...
> >   
> >   config ACPI_POWER
> >   bool
> >   default y
> >   
> >   config ACPI_SYSTEM
> >   bool
> >   default y
> >   help
> >   ...
> >   ...
> >   endif
> > 
> > I'd expect the 3 symbols to be all set when CONFIG_ACPI=y.
> > What am I overseeing?
> 
> I think that this is just 'make randconfig' throwing a curve ball.
> ACPI depends on PM, but PM=n.  In my experience, randconfig is a
> good tool for testing oddball configs, but the results are not
> always something that is fixable or needs to be fixed.

It looks like Kconfig does the right thing on i386 though. Not the same
on x84_64.

-- 
mattia
:wq!
-
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 2.6.22-rc1

2007-05-15 Thread Satyam Sharma

On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:

[...]
If you transform a menu with hidden options (which do NOT "depend on"
the menu - they can't even) into a menuconfig (continuing not to
depend on the menuconfig), the presentation fucks up (especially in
ncurses-menuconfig). That is a good hint something should be taken
more seriously.


Sorry, I didn't follow this "hidden options" thing at all ...


So, for menus with hidden options I had a number of options how to
go about them:

 - move the hidden options before the menuconfig or after, so
   the presentation does not bork;

 - leave the menu as-is because there's just so many hidden
   options and a menuconfig entry is detrimental


... but the second method seems sane and safe, still :-)


So what do we need?

 * 'configmenu' option (with 'endconfigmenu') that works the same as
   'menu' and 'endmenu' (so we can have hidden options), but at the
   same time make the ---> and options inside it disappear when it is
   not selected. Currently, no other type seems to satisfy this.


(Yes, and with that implicit if-endif block to make "depends on" the
configmenu for those config options that are inside it automatic)

* Also, some "[MENU]" kind of prefix/tag in the text of configmenu
options would also be nice.

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: Linux 2.6.22-rc1

2007-05-15 Thread Satyam Sharma

On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:

[...]
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.

It's tricky for "make oldconfig" when introducing a new "menuconfig"
around some previously existing "config"s, because just accepting
the default for the new option then causes previously selected
ones to be silently dropped. But I don't know a perfect solution
for that. Perhaps we'll just have to live with it. Or perhaps a
warning message along the line of "deselecting option xxx" would
be in order.
[...]
It's actually the other way around, all those options now tucked
underneath the menuconfig were previously directly visible, so
selecting "y" (either explicitly or by default) makes everything
work as before while "n" very conveniently skips them all.


Jan did mention this in the previous thread, but as Jens said,
these problems would occur only the _first_ time someone
transitions from the old .config's to the new scheme. But those
"default y"s for all the various "configmenu"s (let's please call
them that) that got introduced in the Kconfig files would cause
unnecessary annoyance to users of make oldconfig _for ever_.
-
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 2.6.22-rc1

2007-05-15 Thread andrew hendry

Yes, putting the extern highstart_pfn back compiles clean for that rand config.

Sorry for the attachment, no access to a patch friendly mailer at work.

Andrew.

On 5/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:



On Tue, 15 May 2007, andrew hendry wrote:
>
> almost, highstart_pfn is used in a few printks
>
> arch/i386/mm/discontig.c: In function 'setup_memory':
> arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
> use in this function)
> arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
> reported only once
> arch/i386/mm/discontig.c:314: error: for each function it appears in.)

Gaah. highstart_pfn is declared in , but that one is
protected by a

#ifdef CONFIG_HIGHMEM
#include 

in , so even though we include highmem.h, we never see
the declaration.

Your config is insane, but anyway, does it compile if you just add back
the extra "unnecessary" declaration of highstart_pfn?

Linus

diff -uprN -X dontdiff a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
--- a/arch/i386/mm/discontig.c	2007-05-15 15:19:49.0 +1000
+++ b/arch/i386/mm/discontig.c	2007-05-15 15:35:26.0 +1000
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -97,14 +98,9 @@ unsigned long node_memmap_size_bytes(int
 #endif
 
 extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
 extern void add_one_highpage_init(struct page *, int, int);
 
-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
+extern unsigned long highstart_pfn;
 
 #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
 
@@ -360,7 +356,9 @@ void __init zone_sizes_init(void)
 	max_zone_pfns[ZONE_DMA] =
 		virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
 	max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
 	max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif
 	/* If SRAT has not registered memory, register it now */
 	if (find_max_pfn_with_active_regions() == 0) {
 		for_each_online_node(nid) {


Re: Fwd: Re: Linux 2.6.22-rc1

2007-05-15 Thread Randy Dunlap
On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote:

> On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote:
> > On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote:
> > 
> > > 
> > > On May 14 2007 10:55, Mattia Dongili wrote:
> > > >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote:
> > > >> On May 12 2007 20:20, Linus Torvalds wrote:
> > > >> >
> > > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
> > > >> 
> > > >> I have hit a randconfig compile failure. .config attached.
> > > >> 
> > > >>   LD  .tmp_vmlinux1
> > > >> drivers/built-in.o: In function `acpi_bus_generate_event':
> > > >> (.text+0x233f7): undefined reference to `event_is_open'
> > > >> drivers/built-in.o: In function `acpi_bus_get_power':
> > > >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> > > >> drivers/built-in.o: In function `acpi_bus_set_power':
> > > >> (.text+0x237c3): undefined reference to `acpi_power_transition'
> > > >> drivers/built-in.o: In function `acpi_bus_set_power':
> > > >> (.text+0x23835): undefined reference to `acpi_power_transition'
> > > >> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> > > >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> > > >> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> > > >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> > > >> make: *** [.tmp_vmlinux1] Error 1
> > > >
> > > >I actually can't reproduce it with your .config.
> > > 
> > > But I can. Did you try it on x86_64? From 2.6.22-rc1 [
> > > commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ?
> > > 
> > >   bzip2 -cd randconfig-1.bz2 >.config
> > >   make -j8
> > 
> > Yes, build easily fails for me also.
> 
> ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices
> to fix the link failure, but I guess that would just hide the real
> issue.
> IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the
> ACPI symbol is?
> 
> Given the drivers/acpi/Kconfig portion
> 
>   if ACPI
>   ...
>   config ACPI_EC
>   bool
>   default y
>   help
> ...
>   
>   config ACPI_POWER
>   bool
>   default y
>   
>   config ACPI_SYSTEM
>   bool
>   default y
>   help
> ...
>   ...
>   endif
> 
> I'd expect the 3 symbols to be all set when CONFIG_ACPI=y.
> What am I overseeing?

I think that this is just 'make randconfig' throwing a curve ball.
ACPI depends on PM, but PM=n.  In my experience, randconfig is a
good tool for testing oddball configs, but the results are not
always something that is fixable or needs to be fixed.

---
~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: Linux 2.6.22-rc1

2007-05-15 Thread Linus Torvalds


On Tue, 15 May 2007, andrew hendry wrote:
>
> almost, highstart_pfn is used in a few printks
> 
> arch/i386/mm/discontig.c: In function 'setup_memory':
> arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
> use in this function)
> arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
> reported only once
> arch/i386/mm/discontig.c:314: error: for each function it appears in.)

Gaah. highstart_pfn is declared in , but that one is 
protected by a

#ifdef CONFIG_HIGHMEM
#include 

in , so even though we include highmem.h, we never see 
the declaration.

Your config is insane, but anyway, does it compile if you just add back 
the extra "unnecessary" declaration of highstart_pfn?

Linus
-
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: Fwd: Re: Linux 2.6.22-rc1

2007-05-15 Thread Mattia Dongili
On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote:
> On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote:
> 
> > 
> > On May 14 2007 10:55, Mattia Dongili wrote:
> > >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote:
> > >> On May 12 2007 20:20, Linus Torvalds wrote:
> > >> >
> > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
> > >> 
> > >> I have hit a randconfig compile failure. .config attached.
> > >> 
> > >>   LD  .tmp_vmlinux1
> > >> drivers/built-in.o: In function `acpi_bus_generate_event':
> > >> (.text+0x233f7): undefined reference to `event_is_open'
> > >> drivers/built-in.o: In function `acpi_bus_get_power':
> > >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> > >> drivers/built-in.o: In function `acpi_bus_set_power':
> > >> (.text+0x237c3): undefined reference to `acpi_power_transition'
> > >> drivers/built-in.o: In function `acpi_bus_set_power':
> > >> (.text+0x23835): undefined reference to `acpi_power_transition'
> > >> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> > >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> > >> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> > >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> > >> make: *** [.tmp_vmlinux1] Error 1
> > >
> > >I actually can't reproduce it with your .config.
> > 
> > But I can. Did you try it on x86_64? From 2.6.22-rc1 [
> > commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ?
> > 
> > bzip2 -cd randconfig-1.bz2 >.config
> > make -j8
> 
> Yes, build easily fails for me also.

ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices
to fix the link failure, but I guess that would just hide the real
issue.
IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the
ACPI symbol is?

Given the drivers/acpi/Kconfig portion

  if ACPI
  ...
  config ACPI_EC
  bool
  default y
  help
...
  
  config ACPI_POWER
  bool
  default y
  
  config ACPI_SYSTEM
  bool
  default y
  help
  ...
  ...
  endif

I'd expect the 3 symbols to be all set when CONFIG_ACPI=y.
What am I overseeing?

-- 
mattia
:wq!
-
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 2.6.22-rc1

2007-05-15 Thread Tilman Schmidt
Hi,

Satyam Sharma schrieb:

>>   * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
> 
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.

It's tricky for "make oldconfig" when introducing a new "menuconfig"
around some previously existing "config"s, because just accepting
the default for the new option then causes previously selected
ones to be silently dropped. But I don't know a perfect solution
for that. Perhaps we'll just have to live with it. Or perhaps a
warning message along the line of "deselecting option xxx" would
be in order.

> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.

It's actually the other way around, all those options now tucked
underneath the menuconfig were previously directly visible, so
selecting "y" (either explicitly or by default) makes everything
work as before while "n" very conveniently skips them all.
It's really quite nice if you know how it works. The only thing
that's missing is instructions for those seeing it for the first
time.

> IMHO, those using "oldconfig" are often looking towards doing
> things quickly ... doesn't help them if they have default y menu's
> that they need to "?" upon then to see what they're really about.

Well, yes and no. I am of course trying to get through the new
options as quickly as possible. But if I hit an option I don't
understand then typing "?" is the quickest way to sort it out,
so it's doubly annoying if that yields nothing.

Thanks,
Tilman

-- 
Tilman SchmidtE-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: Linux 2.6.22-rc1, 'nother randconfig

2007-05-15 Thread Jan Engelhardt

On May 15 2007 10:26, David Howells wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>> Are you going to fix it?
>
>You should've got a copy of the patch.

Yes, right. So much for asynchronous mail transferral :)


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: Linux 2.6.22-rc1, 'nother randconfig

2007-05-15 Thread David Howells
Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> Are you going to fix it?

You should've got a copy of the patch.

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: Linux 2.6.22-rc1

2007-05-15 Thread Jan Engelhardt

On May 15 2007 08:04, Satyam Sharma wrote:
> On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> that can be switched on or off.
>> It is for those people that start with an arbitrary .config and
>> work their way through menuconfig to disable all the parts they
>> do not want. So, point no. 1:
>> 
>> * Disabling this menu disables all the fluff inside it,
>> without needing to enter the menu and disable each
>> option one by one (as was the case previously)
>
> This kind of promise was really nice, and why I liked Jan's
> menuconfig patches a lot.
>
> But if:
>
> On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>> Another essential piece of information. I seem to remember other
>> menus which, when disabled, kept the selection status of the
>> options inside and just hid them from view.
>
> is true, then are we really gaining much from these configmenu's?

If you transform a menu with hidden options (which do NOT "depend on"
the menu - they can't even) into a menuconfig (continuing not to
depend on the menuconfig), the presentation fucks up (especially in
ncurses-menuconfig). That is a good hint something should be taken
more seriously.

So, for menus with hidden options I had a number of options how to
go about them:

 - move the hidden options before the menuconfig or after, so
   the presentation does not bork;

 - leave the menu as-is because there's just so many hidden
   options and a menuconfig entry is detrimental

> [unrelated]
> I wish these new constructs were called "configmenu" and
> _not_ "menuconfig". It causes confusion with the "menuconfig"
> master Makefile rule which has nothing to do with these new
> "configmenu"s.
> [/unrelated]

Indeed.

>> Then of course, one can also turn these menuconfig on (apparently!)
>> to be able to descend into them and select some drivers they like.
>> Point no. 2:
>> 
>> * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
>
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.
>
>> (I would have wanted them to be always 'y' - it does not affect
>> the build, just opens all menus by default)
>
> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.
>


> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...

I can't tell, since I'd just say yes if it asks "Ethernet (10 GbE)?" -
either I have such an adapter or I don't.



So what do we need?

 * 'configmenu' option (with 'endconfigmenu') that works the same as
   'menu' and 'endmenu' (so we can have hidden options), but at the
   same time make the ---> and options inside it disappear when it is
   not selected. Currently, no other type seems to satisfy this.


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: Linux 2.6.22-rc1

2007-05-15 Thread Jan Engelhardt

On May 15 2007 08:32, Satyam Sharma wrote:
> On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Tilman Schmidt wrote:
>> > Am 14.05.2007 22:33 schrieb Jan Engelhardt:
>> > > * Disabling this menu disables all the fluff inside it,
>> 
>> except when it doesn't.

Blame CONFIG_EMBEDDED!

>> If menuconfig isn't used with strict discipline, we end up with
>> inconsistent and misleading presentation of the kernel configuration.
>
> Yes, this really requires discipline on the part of those who add new
> config options, to also "depends on" the menuconfig they're inside,
> otherwise we end up with inconsistencies. We can't really make this
> automatic, or can we?

Well more or less yes. Instead of adding 'depends on' on every subconfig
object, just wrap the whole thing into an if block:

menuconfig FOOBAR

if FOOBAR

config FOO

config BAR

endif # FOOBAR

Since this is still edgy, an implicit if-endif block could be added as
part of the menuconfig. Sort of like the old menu:

menuconfig FOOBAR

config FOO

config BAR

endmenu

Robert P.J. Day had some solid ideas about this.


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: Linux 2.6.22-rc1

2007-05-14 Thread Stefan Richter
Satyam Sharma wrote:
> Or perhaps we could change the text associated with these
> "menu-only" dummy constructs instead ...
> 
>> we really screw the text-based "make oldconfig" folks who think
>> that they're taking a build-related (and not presentation-related)
>> decision when confronted with a:
> 
> So:
> 
>> Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
> 
> becomes:
> 
> [MENU] Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)

Make menuconfig and xconfig already have hints that these are menus.
Make oldconfig and gconfig and maybe others lack such hints.
-- 
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: Linux 2.6.22-rc1

2007-05-14 Thread Stefan Richter
Satyam Sharma wrote:
> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...

That's one of the things I thought of...

> On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
>> PS:  I still believe that Kconfigs shouldn't by overly burdened with
>> presentation.

...when I wrote this.
-- 
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: Linux 2.6.22-rc1

2007-05-14 Thread Michael Gerdau
> >Seriously, it might be a tad more efficient if the help texts were
> >written by those who invented the options in the first place.
> 
> menuconfig NETDEV_1
>   bool "Ethernet (10GbE)"
>   ---help--
>   Say Y here to actually be able to go into this menu
>   and select some drivers that we think belong to the
>   "10 Gigabit Ethernet" family.
> 
>   If unsure, it is unwise to say N!
> 
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.

I remember very well the time when I first issued make menuconfig.
Ever since then I've been grateful for all those "fundamentally basic"
explanations. And I've learned quite alot about kernelconfig just
by reading them.

Best,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau   email: [EMAIL PROTECTED]
 GPG-keys available on request or at public keyserver


pgpR0U6biGdbj.pgp
Description: PGP signature


Re: Linux 2.6.22-rc1

2007-05-14 Thread andrew hendry

almost, highstart_pfn is used in a few printks

arch/i386/mm/discontig.c: In function 'setup_memory':
arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
use in this function)
arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:314: error: for each function it appears in.)

On 5/15/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:



On Tue, 15 May 2007, andrew hendry wrote:
>
> from a randconfig, attached.
>
> arch/i386/mm/discontig.c:107: error: expected identifier or '(' before 
numeric constant

Gaah. That file is horrible. It redeclares a lot of stuff that it has no
business declaring.

Does this patch help?

Linus
---
 arch/i386/mm/discontig.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
index aa58720..baac2a4 100644
--- a/arch/i386/mm/discontig.c
+++ b/arch/i386/mm/discontig.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long 
start_pfn,
 #endif

 extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
 extern void add_one_highpage_init(struct page *, int, int);

-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
-
 #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)

 unsigned long node_remap_start_pfn[MAX_NUMNODES];
@@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif

/* If SRAT has not registered memory, register it now */
if (find_max_pfn_with_active_regions() == 0) {


-
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 2.6.22-rc1

2007-05-14 Thread Linus Torvalds


On Tue, 15 May 2007, andrew hendry wrote:
>
> from a randconfig, attached.
> 
> arch/i386/mm/discontig.c:107: error: expected identifier or '(' before 
> numeric constant

Gaah. That file is horrible. It redeclares a lot of stuff that it has no 
business declaring.

Does this patch help?

Linus
---
 arch/i386/mm/discontig.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
index aa58720..baac2a4 100644
--- a/arch/i386/mm/discontig.c
+++ b/arch/i386/mm/discontig.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long 
start_pfn,
 #endif
 
 extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
 extern void add_one_highpage_init(struct page *, int, int);
 
-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
-
 #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
 
 unsigned long node_remap_start_pfn[MAX_NUMNODES];
@@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif
 
/* If SRAT has not registered memory, register it now */
if (find_max_pfn_with_active_regions() == 0) {
-
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 2.6.22-rc1

2007-05-14 Thread andrew hendry

from a randconfig, attached.

arch/i386/mm/discontig.c:107: error: expected identifier or '(' before
numeric constant
arch/i386/mm/discontig.c: In function 'zone_sizes_init':
arch/i386/mm/discontig.c:363: error: 'ZONE_HIGHMEM' undeclared (first
use in this function)
arch/i386/mm/discontig.c:363: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:363: error: for each function it appears in.)
make[1]: *** [arch/i386/mm/discontig.o] Error 1
make: *** [arch/i386/mm] Error 2


config.gz
Description: GNU Zip compressed data


Re: Linux 2.6.22-rc1

2007-05-14 Thread Satyam Sharma

On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:

Tilman Schmidt wrote:
> Am 14.05.2007 22:33 schrieb Jan Engelhardt:
>>   * Disabling this menu disables all the fluff inside it,

except when it doesn't.

> Another essential piece of information. I seem to remember other
> menus which, when disabled, kept the selection status of the
> options inside and just hid them from view.

It's a matter of /dependence/ on a menuconfig option whether options
inside the menu will be disabled.  Not a matter of being located in the
menu.


Yeah, this is a good solution -- making options inside a menuconfig
also dependent on it makes sense.


If menuconfig isn't used with strict discipline, we end up with
inconsistent and misleading presentation of the kernel configuration.


Yes, this really requires discipline on the part of those who add new
config options, to also "depends on" the menuconfig they're inside,
otherwise we end up with inconsistencies. We can't really make this
automatic, or can we?
-
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 2.6.22-rc1

2007-05-14 Thread Satyam Sharma

On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> [...]
> They are just a menu

Ok, so they don't really affect Makefiles / sources (and thus builds).
In that case I'd suggest that let's please change the names of such
menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise


Or perhaps we could change the text associated with these
"menu-only" dummy constructs instead ...


we really screw the text-based "make oldconfig" folks who think
that they're taking a build-related (and not presentation-related)
decision when confronted with a:


So:


Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)


becomes:

[MENU] Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)

?

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: Linux 2.6.22-rc1

2007-05-14 Thread Satyam Sharma

Hello,

On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:

[...]
They are just a menu


Ok, so they don't really affect Makefiles / sources (and thus builds).
In that case I'd suggest that let's please change the names of such
menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise
we really screw the text-based "make oldconfig" folks who think
that they're taking a build-related (and not presentation-related)
decision when confronted with a:

Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)

kind of option. OTOH:

Ethernet (1000 Mbit) (MENU_NETDEV_1000) [Y/n] (NEW)

taxes a make-oldconfig-using-person's intuition a little less, IMHO.
So this'll hopefully take care of Tilman's and Stefan's gripes:

On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:

(Except for the "this
menu" part which might appear rather cryptic to users of the
curses based interface who don't see any menu.)
[...]
Point is, without grepping through the Kconfig the user has no
way of knowing that the question comes from a menuconfig in the
first place ...
... s/he cannot be sure the option doesn't directly affect
code generation.


and

On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:

One problem is, nobody can see easily whether saying Y is merely the
ticket to get into the menu, or whether it on its own will cause
something to be built.


?

On 5/15/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:

that can be switched on or off.
It is for those people that start with an arbitrary .config and
work their way through menuconfig to disable all the parts they
do not want. So, point no. 1:

  * Disabling this menu disables all the fluff inside it,
without needing to enter the menu and disable each
option one by one (as was the case previously)


This kind of promise was really nice, and why I liked Jan's
menuconfig patches a lot.

But if:

On 5/15/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:

Another essential piece of information. I seem to remember other
menus which, when disabled, kept the selection status of the
options inside and just hid them from view.


is true, then are we really gaining much from these configmenu's?

[unrelated]
I wish these new constructs were called "configmenu" and
_not_ "menuconfig". It causes confusion with the "menuconfig"
master Makefile rule which has nothing to do with these new
"configmenu"s.
[/unrelated]


Then of course, one can also turn these menuconfig on (apparently!)
to be able to descend into them and select some drivers they like.
Point no. 2:

  * Since Jens Axboe's stance ["default y idiocy"] is to have
these menus disabled by default, people should most likely
enable them first before they will be able to enter them.


I do agree that anything non-essential (even if it's just a presentation
menu that doesn't affect builds) must be default n.


(I would have wanted them to be always 'y' - it does not affect
the build, just opens all menus by default)


IMHO, the real problem with "default y" menuconfig's, is that they
cause unpleasant surprises to those folks that use the text-based
"make oldconfig". They get confronted with choices that they never
bothered about (or even knew existed) previously, and have no
idea how to answer them -- same problem faced by Tilman, when
he used oldconfig.


>Seriously, it might be a tad more efficient if the help texts were
>written by those who invented the options in the first place.

menuconfig NETDEV_1
bool "Ethernet (10GbE)"
---help--
Say Y here to actually be able to go into this menu
and select some drivers that we think belong to the
"10 Gigabit Ethernet" family.

If unsure, it is unwise to say N!

See, this looks so fundamentally basic to me that I find it
almost funny. YMMV, hence I asked for suggestions from
other people.


IMHO, those using "oldconfig" are often looking towards doing
things quickly ... doesn't help them if they have default y menu's
that they need to "?" upon then to see what they're really about.


>For a start, it shouldn't require users to grep through Kconfigs
>and Makefiles in order to find out what effects an option has.

menuconfigs are some special kind in that they combine an option
with a menu. Perhaps now that some ->menuconfig patches have gone
in, more people will get to know these constructs.


I think what happened here is that Jan really only considered the
"make menuconfig" users with these new constructs (which makes life
really simple for them), but "oldconfig" users were unfortunately in for
unpleasant surprises ...

On 5/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:

PS:  I still believe that Kconfigs shouldn't by overly burdened with
presentation.  Presentation should mostly be left to the UIs.  And the
UIs shouldn't be created by kernel hackers...  ;-)


Kernel dev's can still try, can't they ;-) I do agree that Kconfig is
primarily a build dependency language, but also, note that linking
Kconfig dependency rules with 

Re: Linux 2.6.22-rc1

2007-05-14 Thread Stefan Richter
Tilman Schmidt wrote:
> Am 14.05.2007 22:33 schrieb Jan Engelhardt:
>>   * Disabling this menu disables all the fluff inside it,

except when it doesn't.

> Another essential piece of information. I seem to remember other
> menus which, when disabled, kept the selection status of the
> options inside and just hid them from view.

It's a matter of /dependence/ on a menuconfig option whether options
inside the menu will be disabled.  Not a matter of being located in the
menu.

If menuconfig isn't used with strict discipline, we end up with
inconsistent and misleading presentation of the kernel configuration.
-- 
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: Linux 2.6.22-rc1

2007-05-14 Thread Stefan Richter
Jan Engelhardt wrote:
> menuconfig NETDEV_1
>   bool "Ethernet (10GbE)"
>   ---help--
>   Say Y here to actually be able to go into this menu
>   and select some drivers that we think belong to the
>   "10 Gigabit Ethernet" family.
> 
>   If unsure, it is unwise to say N!
> 
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.

One problem is, nobody can see easily whether saying Y is merely the
ticket to get into the menu, or whether it on its own will cause
something to be built.

PS:  I still believe that Kconfigs shouldn't by overly burdened with
presentation.  Presentation should mostly be left to the UIs.  And the
UIs shouldn't be created by kernel hackers...  ;-)
-- 
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: Linux 2.6.22-rc1

2007-05-14 Thread Tilman Schmidt
Am 14.05.2007 22:33 schrieb Jan Engelhardt:
> On May 14 2007 20:01, Tilman Schmidt wrote:
>>> "Patches welcome" ;-)
>> Sure. Just tell me exactly what those options are intended to do
>> and I'll happily write up a patch adding help texts trying to
>> express that in bad English. :-)
> 
> They are just a menu that can be switched on or off.

Ok, that's the first essential piece of information which is *not*
evident from the prompt "make oldconfig" presents me with:

  Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)

contains *no* indication that this is the start of a menu.

>   * Disabling this menu disables all the fluff inside it,

Another essential piece of information. I seem to remember other
menus which, when disabled, kept the selection status of the
options inside and just hid them from view.

> menuconfig NETDEV_1
>   bool "Ethernet (10GbE)"
>   ---help--
>   Say Y here to actually be able to go into this menu
>   and select some drivers that we think belong to the
>   "10 Gigabit Ethernet" family.
> 
>   If unsure, it is unwise to say N!
> 
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.

That's because it's so incomplete and mentions only the facts
which where obvious in the first place. (Except for the "this
menu" part which might appear rather cryptic to users of the
curses based interface who don't see any menu.)

Have a look at the entry "config NET_ETHERNET" for an impression
of what others felt worth mentioning in similar circumstances.
And no, that is not funny, even though much of it is of course
fundamentally basic for most of us. It does actually help people
confronted with the question.

>> For a start, it shouldn't require users to grep through Kconfigs
>> and Makefiles in order to find out what effects an option has.
> 
> menuconfigs are some special kind in that they combine an option
> with a menu. Perhaps now that some ->menuconfig patches have gone
> in, more people will get to know these constructs.

Point is, without grepping through the Kconfig the user has no
way of knowing that the question comes from a menuconfig in the
first place, at least with "make menuconfig" and friends, and
without grepping through the Makefile (and, à la limite, source
files) s/he cannot be sure the option doesn't directly affect
code generation.

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: Linux 2.6.22-rc1

2007-05-14 Thread Jan Engelhardt

On May 14 2007 20:01, Tilman Schmidt wrote:
>> 
>> "Patches welcome" ;-)
>
>Sure. Just tell me exactly what those options are intended to do
>and I'll happily write up a patch adding help texts trying to
>express that in bad English. :-)

They are just a menu that can be switched on or off.
It is for those people that start with an arbitrary .config and
work their way through menuconfig to disable all the parts they
do not want. So, point no. 1:

  * Disabling this menu disables all the fluff inside it,
without needing to enter the menu and disable each
option one by one (as was the case previously)

Then of course, one can also turn these menuconfig on (apparently!)
to be able to descend into them and select some drivers they like.
Point no. 2:

  * Since Jens Axboe's stance ["default y idiocy"] is to have
these menus disabled by default, people should most likely
enable them first before they will be able to enter them.

(I would have wanted them to be always 'y' - it does not affect
the build, just opens all menus by default)

>Seriously, it might be a tad more efficient if the help texts were
>written by those who invented the options in the first place.

menuconfig NETDEV_1
bool "Ethernet (10GbE)"
---help--
Say Y here to actually be able to go into this menu
and select some drivers that we think belong to the
"10 Gigabit Ethernet" family.

If unsure, it is unwise to say N!

See, this looks so fundamentally basic to me that I find it
almost funny. YMMV, hence I asked for suggestions from
other people.

>> As for NETDEV_1000 and _1, I really wonder if we need anymore
>> help text than the option. I do not know what the minimum level
>> of user knowledge is that kconfig help texts need to support,
>> but maybe you can tell?
>
>For a start, it shouldn't require users to grep through Kconfigs
>and Makefiles in order to find out what effects an option has.

menuconfigs are some special kind in that they combine an option
with a menu. Perhaps now that some ->menuconfig patches have gone
in, more people will get to know these constructs.


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: Linux 2.6.22-rc1

2007-05-14 Thread Jan Engelhardt

On May 14 2007 19:32, Stefan Richter wrote:
>> 
>> As for NETDEV_1000 and _1, I really wonder if we need anymore
>> help text than the option. I do not know what the minimum level
>> of user knowledge is that kconfig help texts need to support,
>> but maybe you can tell?
>
>The text "Ethernet (1 Mbit)" _doesn't_ tell me that this option
>"does not affect the kernel build, it only lets [me] choose drivers".
>
>The "patches welcome" is quite appropriate.  On the other hand, visible
>Kconfig options without help text should almost never be allowed to go
>in in the first place, IMO.

Well, it was a conversion from "menu" to "menuconfig". Since
menus cannot(?) have a kconfig text, I did not transform one.

For the "config" to "menuconfig" conversions, the help text
was preserved, since there was something to preserve.


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: Linux 2.6.22-rc1

2007-05-14 Thread Christoph Hellwig
On Mon, May 14, 2007 at 03:53:21PM -0400, Jeff Garzik wrote:
> Jean Delvare wrote:
> >On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:
> >>On Mon, 14 May 2007, Jean Delvare wrote:
> >>>Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> >>>2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
> >>And we really complained about it! The oprofile thing should be fixed, 
> >>btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
> >>from Greg. That thing has been a disaster, and everybody involved should 
> >>be ashamed and now hopefully *very* aware of the fact that we don't break 
> >>user-level interfaces.
> >>
> >>(Right now, I suspect we may have a loop setup regression. Not sure)
> >
> >While I'm all for keeping things relatively stable and not asking the
> >user to constantly upgrade user-space, I believe that we just can't
> >promise to never break user-level interfaces while keeping the
> >development pace we have right now. We can promise to grant people
> >significant delay before we drop compatibility options, but "forever"
> >doesn't scale.
> >
> >If you really want to enforce the "never" rule, be prepared to either
> >see development slow down and finally come to a stop, or see the code
> >become unmaintainable and insecure and nobody is longer willing to work
> >on it.
> 
> Why do you think we -stopped- enforcing such a rule?   :)
> 
> It's been the rule throughout Linux's history.  syscalls from early 
> Linux binaries should still work, for example.

Except for very rare case (modules support comes to mine) syscall
compatiblity works perfectly.  But that's because syscalls are a very
visible ABI and people don't break them by accident.  They also don't
decide they have a cool new scheme all syscalls need to follow now.

Now compare that to sysfs..
-
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 2.6.22-rc1

2007-05-14 Thread Christoph Hellwig
On Mon, May 14, 2007 at 09:28:07PM +0200, Jean Delvare wrote:
> > And we really complained about it! The oprofile thing should be fixed, 
> > btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
> > from Greg. That thing has been a disaster, and everybody involved should 
> > be ashamed and now hopefully *very* aware of the fact that we don't break 
> > user-level interfaces.
> > 
> > (Right now, I suspect we may have a loop setup regression. Not sure)
> 
> While I'm all for keeping things relatively stable and not asking the
> user to constantly upgrade user-space, I believe that we just can't
> promise to never break user-level interfaces while keeping the
> development pace we have right now. We can promise to grant people
> significant delay before we drop compatibility options, but "forever"
> doesn't scale.

never with a loong deprecations period.  At least for APIs that are not
private to a single obscure driver.  But this would require people actually
beeing aware of creating ABIs, and maybe someone with half a clue reviewing
them. Which of course is not the case today, thanks to ioctls, procfs, sysfs,
debugfs and co people can create userspace ABIs without a single though
easily, and they happily do 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: Linux 2.6.22-rc1

2007-05-14 Thread Christoph Hellwig
On Mon, May 14, 2007 at 11:43:45AM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 14 May 2007, Jean Delvare wrote:
> > 
> > Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> > 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
> 
> And we really complained about it! The oprofile thing should be fixed, 
> btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
> from Greg. That thing has been a disaster, and everybody involved should 
> be ashamed and now hopefully *very* aware of the fact that we don't break 
> user-level interfaces.

sysfs is an even bigger desaster.  Even if people know they can't break
userspace apis sysfs can force it on them.  As long as we tightly couple
kernel data structures and a userspace ABI that's unavoidable.  Unfortunately
sorting that mess out properly would be such a massive amount of work
that it'd alsmost require a 2.7 series.

-
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 2.6.22-rc1

2007-05-14 Thread Jeff Garzik

Jean Delvare wrote:

On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:

On Mon, 14 May 2007, Jean Delvare wrote:

Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
And we really complained about it! The oprofile thing should be fixed, 
btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
from Greg. That thing has been a disaster, and everybody involved should 
be ashamed and now hopefully *very* aware of the fact that we don't break 
user-level interfaces.


(Right now, I suspect we may have a loop setup regression. Not sure)


While I'm all for keeping things relatively stable and not asking the
user to constantly upgrade user-space, I believe that we just can't
promise to never break user-level interfaces while keeping the
development pace we have right now. We can promise to grant people
significant delay before we drop compatibility options, but "forever"
doesn't scale.

If you really want to enforce the "never" rule, be prepared to either
see development slow down and finally come to a stop, or see the code
become unmaintainable and insecure and nobody is longer willing to work
on it.


Why do you think we -stopped- enforcing such a rule?   :)

It's been the rule throughout Linux's history.  syscalls from early 
Linux binaries should still work, for example.


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 2.6.22-rc1

2007-05-14 Thread Jean Delvare
On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:
> 
> On Mon, 14 May 2007, Jean Delvare wrote:
> > 
> > Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> > 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
> 
> And we really complained about it! The oprofile thing should be fixed, 
> btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
> from Greg. That thing has been a disaster, and everybody involved should 
> be ashamed and now hopefully *very* aware of the fact that we don't break 
> user-level interfaces.
> 
> (Right now, I suspect we may have a loop setup regression. Not sure)

While I'm all for keeping things relatively stable and not asking the
user to constantly upgrade user-space, I believe that we just can't
promise to never break user-level interfaces while keeping the
development pace we have right now. We can promise to grant people
significant delay before we drop compatibility options, but "forever"
doesn't scale.

If you really want to enforce the "never" rule, be prepared to either
see development slow down and finally come to a stop, or see the code
become unmaintainable and insecure and nobody is longer willing to work
on it.

> > We already have CONFIG_SYSFS_DEPRECATED for that.
> 
> ..and that should have been made more clear. I certainly didn't react to 
> it immediately.

You seem to assume that I remembered myself about this option when I
first replied. I wish it were true :(

-- 
Jean Delvare
-
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 2.6.22-rc1

2007-05-14 Thread Linus Torvalds


On Mon, 14 May 2007, Jean Delvare wrote:
> 
> Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.

And we really complained about it! The oprofile thing should be fixed, 
btw, and yeah,if udev breaks any more, I'll have to stop taking patches 
from Greg. That thing has been a disaster, and everybody involved should 
be ashamed and now hopefully *very* aware of the fact that we don't break 
user-level interfaces.

(Right now, I suspect we may have a loop setup regression. Not sure)

> We already have CONFIG_SYSFS_DEPRECATED for that.

..and that should have been made more clear. I certainly didn't react to 
it immediately.

Linus
-
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 2.6.22-rc1

2007-05-14 Thread Antonino Ingargiola

Hi Jean,

2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]

> I've not found an obvious way to set it in sensors.conf. Could you
> point me to some doumentation, thanks.

sensors.conf supposedly _is_ the the documentation ;)

Search for the following line in /etc/sensors.conf:

chip "via686a-*"

After this line, add:

set fan1_div 4
set fan2_div 4

Save, quit, run "sensors -s" (as root), that should do it.


Thanks for the explanation (it's not too evident form sensors.conf ;)).


> Is this new version required only for the via686 chip or should be a
> general advise for Debian Etch users to upgrade to lm-sensors >=
> 2.10.3 for kernels >= 2.6.22?

The problem affects almost all hardware monitoring chips, so this is a
general advice. I've added a note about it on the lm-sensors website.

Alternatively though, you could have recompiled your kernel with
CONFIG_SYSFS_DEPRECATED=y, then lm_sensors 2.10.1 would have worked
fine again. Sorry for not mentioning this before, this might have been
easier than upgrading lm_sensors.


No problem. I took no more than 5 min to do the backport instead of
~25 min of a full kernel built ;-). BTW it's always good to know the
various solutions.

Thanks,

   ~  Antonio
-
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 2.6.22-rc1

2007-05-14 Thread Jean Delvare
Hello Linus,

On Mon, 14 May 2007 09:30:19 -0700 (PDT), Linus Torvalds wrote:
> On Mon, 14 May 2007, Jean Delvare wrote:
> > 
> > This is a side effect of an i2c-core cleanup. This is already fixed in
> > lm_sensors 2.10.3 (libsensors.so.3.1.3).
> 
> So apparently that fixed it, but in general we do not allow these kinds of 
> "need to have new xyz with new kernel".

Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.

> Kernels are supposed to be backwards compatible. Jean, what was it that 
> changed, and why can't we just make them appear the same?
> 
> It may be that something like a sensors package isn't important enough to 
> worry about (the machine still *works*, and everything else won't notice), 
> but if it's a simple matter of adding some random file to /sysfs, we 
> should just do it.

We already have CONFIG_SYSFS_DEPRECATED for that.

-- 
Jean Delvare
-
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 2.6.22-rc1

2007-05-14 Thread Jean Delvare
Hi Antonino,

On Mon, 14 May 2007 18:04:00 +0200, Antonino Ingargiola wrote:
> Hi Jean!
> 
> 2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
> 
> > > Sure. On 2.6.21.1:
> > >
> > > via686a-isa-6000
> > > Adapter: ISA adapter
> > > CPU core:  +1.63 V  (min =  +0.06 V, max =  +3.10 V)
> > > +2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
> > > I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
> > > +5V:   +5.05 V  (min =  +4.73 V, max =  +5.20 V)
> > > +12V: +12.30 V  (min = +11.35 V, max = +12.48 V)
> > > CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
> > > P/S Fan:  2657 RPM  (min = 42187 RPM, div = 2)  ALARM
> >
> > Hint: increase the fan clock dividers to 4.
> 
> I've not found an obvious way to set it in sensors.conf. Could you
> point me to some doumentation, thanks.

sensors.conf supposedly _is_ the the documentation ;)

Search for the following line in /etc/sensors.conf:

chip "via686a-*"

After this line, add:

set fan1_div 4
set fan2_div 4

Save, quit, run "sensors -s" (as root), that should do it.

> > > while on 2.6.22-rc1:
> > >
> > > via686a-i2c-9191-6000
> > >  ERROR: Can't get adapter or algorithm?!?
> >
> > Ah, interesting. Could it be that the gnome applet quits because it
> > fails to get the adapter name? That wouldn't be very smart, but that's
> > possible.
> 
> Just for the record. Does not quit. It displays on the panel "Chip not 
> found.".
> 
> > This is a side effect of an i2c-core cleanup. This is already fixed in
> > lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
> > confirm it fixes the problem? Note that it might be a bit tricky to get
> > the gnome applet to use your own libsensors rather than the system one.
> > You might need to set the LD_LIBRARY_PATH environment variable before
> > the applet starts, or something similar.
> 
> Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
> Debian Etch was straightforward. Now the applet works again! And the
> P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
> case) works too. Many thanks ;-).

Great, this is good news.

The 0 RPM reading isn't related to the problem you had, this is a
coincidence. 2657 RPM (which your other example shows) is the lowest fan
speed this chip can measure with a fan clock divider of 2, anything
slower is reported as 0 RPM. That's the reason why I suggested
switching the divider to 4.

> Is this new version required only for the via686 chip or should be a
> general advise for Debian Etch users to upgrade to lm-sensors >=
> 2.10.3 for kernels >= 2.6.22?

The problem affects almost all hardware monitoring chips, so this is a
general advice. I've added a note about it on the lm-sensors website.

Alternatively though, you could have recompiled your kernel with
CONFIG_SYSFS_DEPRECATED=y, then lm_sensors 2.10.1 would have worked
fine again. Sorry for not mentioning this before, this might have been
easier than upgrading lm_sensors.

-- 
Jean Delvare
-
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 2.6.22-rc1

2007-05-14 Thread Tilman Schmidt
Jan Engelhardt schrieb:
> On May 13 2007 20:19, Tilman Schmidt wrote:
>>
>>Would it be asking too much to have help texts on the following
>>new (wrt 2.6.21) configuration options?
>>
>>ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>>Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
>>Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>>Ethernet (1 Mbit) (NETDEV_1) [Y/n] (NEW)
>>
>>Those for the latter three could/should say something like the
>>one for the WLAN_80211 option.
> 
> "Patches welcome" ;-)

Sure. Just tell me exactly what those options are intended to do
and I'll happily write up a patch adding help texts trying to
express that in bad English. :-)

Seriously, it might be a tad more efficient if the help texts were
written by those who invented the options in the first place.

> As for NETDEV_1000 and _1, I really wonder if we need anymore
> help text than the option. I do not know what the minimum level
> of user knowledge is that kconfig help texts need to support,
> but maybe you can tell?

For a start, it shouldn't require users to grep through Kconfigs
and Makefiles in order to find out what effects an option has.

-- 
Tilman SchmidtE-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: Fwd: Re: Linux 2.6.22-rc1

2007-05-14 Thread Randy Dunlap
On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote:

> 
> On May 14 2007 10:55, Mattia Dongili wrote:
> >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote:
> >> On May 12 2007 20:20, Linus Torvalds wrote:
> >> >
> >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
> >> 
> >> I have hit a randconfig compile failure. .config attached.
> >> 
> >>   LD  .tmp_vmlinux1
> >> drivers/built-in.o: In function `acpi_bus_generate_event':
> >> (.text+0x233f7): undefined reference to `event_is_open'
> >> drivers/built-in.o: In function `acpi_bus_get_power':
> >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> >> drivers/built-in.o: In function `acpi_bus_set_power':
> >> (.text+0x237c3): undefined reference to `acpi_power_transition'
> >> drivers/built-in.o: In function `acpi_bus_set_power':
> >> (.text+0x23835): undefined reference to `acpi_power_transition'
> >> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> >> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> >> make: *** [.tmp_vmlinux1] Error 1
> >
> >I actually can't reproduce it with your .config.
> 
> But I can. Did you try it on x86_64? From 2.6.22-rc1 [
> commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ?
> 
>   bzip2 -cd randconfig-1.bz2 >.config
>   make -j8

Yes, build easily fails for me also.

>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf -s arch/x86_64/Kconfig
> drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol '
> drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_G
> drivers/input/keyboard/Kconfig:170:warning: 'select' used by config sym
> drivers/input/mouse/Kconfig:181:warning: 'select' used by config symbol
>   CHK include/linux/version.h
>   UPD include/linux/version.h
>   CHK include/linux/utsrelease.h
>   UPD include/linux/utsrelease.h
>   SYMLINK include/asm -> include/asm-x86_64
> 
> 
> >>From a clean tree, running make fires up the oldconfig which fixes the
> >many missing/garbled dependencies. In any case SONY_LAPTOP depends on
> >ACPI which always build EC statically if selected.
> 
> I really presume it is something on x86_64, because doing
> 
>   gzip -cd /proc/config.gz
>   make
> 
> on i386 seemed to compile fine - including the sony modules.


---
~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: Linux 2.6.22-rc1

2007-05-14 Thread Stefan Richter
Jan Engelhardt wrote:
> On May 13 2007 20:19, Tilman Schmidt wrote:
...
>> Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>> Ethernet (1 Mbit) (NETDEV_1) [Y/n] (NEW)
>>
>> Those for the latter three could/should say something like the
>> one for the WLAN_80211 option.
> 
> "Patches welcome" ;-)
> 
> As for NETDEV_1000 and _1, I really wonder if we need anymore
> help text than the option. I do not know what the minimum level
> of user knowledge is that kconfig help texts need to support,
> but maybe you can tell?

The text "Ethernet (1 Mbit)" _doesn't_ tell me that this option
"does not affect the kernel build, it only lets [me] choose drivers".

The "patches welcome" is quite appropriate.  On the other hand, visible
Kconfig options without help text should almost never be allowed to go
in in the first place, IMO.
-- 
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: Linux 2.6.22-rc1, 'nother randconfig

2007-05-14 Thread Jan Engelhardt

On May 14 2007 12:44, David Howells wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>> net/built-in.o: In function `rxrpc_destroy_all_calls':
>> (.exit.text+0x71d): undefined reference to `rxrpc_call_states'
>> make: *** [.tmp_vmlinux1] Error 1
>
>This is the problem:
>
>   # CONFIG_PROC_FS is not set
>   CONFIG_AF_RXRPC=y

Are you going to fix it?



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: Linux 2.6.22-rc1

2007-05-14 Thread Jan Engelhardt

On May 13 2007 20:19, Tilman Schmidt wrote:
>Am 13.05.2007 05:20 schrieb Linus Torvalds:
>> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>[...]
>> So give it a good testing.
>
>Would it be asking too much to have help texts on the following
>new (wrt 2.6.21) configuration options?
>
>ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
>Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>Ethernet (1 Mbit) (NETDEV_1) [Y/n] (NEW)
>
>Those for the latter three could/should say something like the
>one for the WLAN_80211 option.

"Patches welcome" ;-)

As for NETDEV_1000 and _1, I really wonder if we need anymore
help text than the option. I do not know what the minimum level
of user knowledge is that kconfig help texts need to support,
but maybe you can tell?


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: Linux 2.6.22-rc1

2007-05-14 Thread Linus Torvalds


On Mon, 14 May 2007, Jean Delvare wrote:
> 
> This is a side effect of an i2c-core cleanup. This is already fixed in
> lm_sensors 2.10.3 (libsensors.so.3.1.3).

So apparently that fixed it, but in general we do not allow these kinds of 
"need to have new xyz with new kernel". 

Kernels are supposed to be backwards compatible. Jean, what was it that 
changed, and why can't we just make them appear the same?

It may be that something like a sensors package isn't important enough to 
worry about (the machine still *works*, and everything else won't notice), 
but if it's a simple matter of adding some random file to /sysfs, we 
should just do it.

Linus
-
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 2.6.22-rc1

2007-05-14 Thread Michal Piotrowski

Hi,

On 14/05/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:

Hi Jean!

2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:

> > Sure. On 2.6.21.1:
> >
> > via686a-isa-6000
> > Adapter: ISA adapter
> > CPU core:  +1.63 V  (min =  +0.06 V, max =  +3.10 V)
> > +2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
> > I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
> > +5V:   +5.05 V  (min =  +4.73 V, max =  +5.20 V)
> > +12V: +12.30 V  (min = +11.35 V, max = +12.48 V)
> > CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
> > P/S Fan:  2657 RPM  (min = 42187 RPM, div = 2)  ALARM
>
> Hint: increase the fan clock dividers to 4.
>

I've not found an obvious way to set it in sensors.conf. Could you
point me to some doumentation, thanks.

> > while on 2.6.22-rc1:
> >
> > via686a-i2c-9191-6000
> >  ERROR: Can't get adapter or algorithm?!?
>
> Ah, interesting. Could it be that the gnome applet quits because it
> fails to get the adapter name? That wouldn't be very smart, but that's
> possible.

Just for the record. Does not quit. It displays on the panel "Chip not found.".

> This is a side effect of an i2c-core cleanup.


I call it "breaking userspace".


> This is already fixed in
> lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
> confirm it fixes the problem? Note that it might be a bit tricky to get
> the gnome applet to use your own libsensors rather than the system one.
> You might need to set the LD_LIBRARY_PATH environment variable before
> the applet starts, or something similar.

Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
Debian Etch was straightforward. Now the applet works again! And the
P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
case) works too. Many thanks ;-).

Is this new version required only for the via686 chip or should be a
general advise for Debian Etch users to upgrade to lm-sensors >=
2.10.3 for kernels >= 2.6.22?


Ok, I removed this issue from the list of known regressions.




~ Antonio
-


Regards,
Michal

--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)
-
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 2.6.22-rc1

2007-05-14 Thread Antonino Ingargiola

Hi Jean!

2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:


> Sure. On 2.6.21.1:
>
> via686a-isa-6000
> Adapter: ISA adapter
> CPU core:  +1.63 V  (min =  +0.06 V, max =  +3.10 V)
> +2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
> I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
> +5V:   +5.05 V  (min =  +4.73 V, max =  +5.20 V)
> +12V: +12.30 V  (min = +11.35 V, max = +12.48 V)
> CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
> P/S Fan:  2657 RPM  (min = 42187 RPM, div = 2)  ALARM

Hint: increase the fan clock dividers to 4.



I've not found an obvious way to set it in sensors.conf. Could you
point me to some doumentation, thanks.


> while on 2.6.22-rc1:
>
> via686a-i2c-9191-6000
>  ERROR: Can't get adapter or algorithm?!?

Ah, interesting. Could it be that the gnome applet quits because it
fails to get the adapter name? That wouldn't be very smart, but that's
possible.


Just for the record. Does not quit. It displays on the panel "Chip not found.".


This is a side effect of an i2c-core cleanup. This is already fixed in
lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
confirm it fixes the problem? Note that it might be a bit tricky to get
the gnome applet to use your own libsensors rather than the system one.
You might need to set the LD_LIBRARY_PATH environment variable before
the applet starts, or something similar.


Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
Debian Etch was straightforward. Now the applet works again! And the
P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
case) works too. Many thanks ;-).

Is this new version required only for the via686 chip or should be a
general advise for Debian Etch users to upgrade to lm-sensors >=
2.10.3 for kernels >= 2.6.22?


   ~ Antonio
-
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 2.6.22-rc1

2007-05-14 Thread Jean Delvare
On Mon, 14 May 2007 15:28:00 +0200, Antonino Ingargiola wrote:
> Hi Jean,
> 
> 2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
> [cut]
> > This is a rather bad idea to build the abituguru and hdaps drivers into
> > your kernel if you don't have these devices. Especially abituguru, as
> > it does arbitrary port probing.
> 
> My bad. I have an abit motherboard and in doubt I selected the driver
> (and then leaved selected since all worked on previous kernels). I've
> disabled them and the problem persist.

Sure, I didn't expect it to solve the problem. But as a general advice,
hardware monitoring drivers are better selected as modules than
built-in.

> > > I'm not using any of the listed drivers.
> >
> > How strange, why are they loaded then?
> 
> My reply refers to your list of drivers that require a certain version
> of lm-sensors.

Ah, OK. Sorry, I got confused.

> > > However the lm-sensors package is version 2.10.1-3 and
> > > libsensors.so.3.1.1 is on my system too (package libsensors3).
> >
> > Can you please share the output of "sensors" under both kernels 2.6.21.1
> > and 2.6.22-rc1.
> 
> Sure. On 2.6.21.1:
> 
> via686a-isa-6000
> Adapter: ISA adapter
> CPU core:  +1.63 V  (min =  +0.06 V, max =  +3.10 V)
> +2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
> I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
> +5V:   +5.05 V  (min =  +4.73 V, max =  +5.20 V)
> +12V: +12.30 V  (min = +11.35 V, max = +12.48 V)
> CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
> P/S Fan:  2657 RPM  (min = 42187 RPM, div = 2)  ALARM

Hint: increase the fan clock dividers to 4.

> SYS Temp:  +40.9°C  (high =  +146°C, hyst =   -71°C)
> CPU Temp:  +43.3°C  (high =  +146°C, hyst =   -71°C)
> SBr Temp:  +24.9°C  (high =   -63°C, hyst =   -71°C)   ALARM
> 
> while on 2.6.22-rc1:
> 
> via686a-i2c-9191-6000
>  ERROR: Can't get adapter or algorithm?!?

Ah, interesting. Could it be that the gnome applet quits because it
fails to get the adapter name? That wouldn't be very smart, but that's
possible.

This is a side effect of an i2c-core cleanup. This is already fixed in
lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
confirm it fixes the problem? Note that it might be a bit tricky to get
the gnome applet to use your own libsensors rather than the system one.
You might need to set the LD_LIBRARY_PATH environment variable before
the applet starts, or something similar.

> CPU core:  +1.65 V  (min =  +0.06 V, max =  +3.10 V)
> +2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
> I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
> +5V:   +5.08 V  (min =  +4.73 V, max =  +5.20 V)
> +12V: +12.24 V  (min = +11.35 V, max = +12.48 V)
> CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
> P/S Fan: 0 RPM  (min = 42187 RPM, div = 2)  ALARM
> SYS Temp:  +41.3°C  (high =  +146°C, hyst =   -71°C)
> CPU Temp:  +41.8°C  (high =  +146°C, hyst =   -71°C)
> SBr Temp:  +24.9°C  (high =   -63°C, hyst =   -71°C)   ALARM
> 
> In both kernels I have set:
> 
>  I2C Algorithms  --->
>I2C PCF 8584 interfaces
>I2C PCA 9564 interfaces

Irrelevant to your problem, but you most certainly need neither - else
they would have been selected automatically.

-- 
Jean Delvare
-
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 2.6.22-rc1

2007-05-14 Thread Antonino Ingargiola

Hi Jean,

2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]

This is a rather bad idea to build the abituguru and hdaps drivers into
your kernel if you don't have these devices. Especially abituguru, as
it does arbitrary port probing.


My bad. I have an abit motherboard and in doubt I selected the driver
(and then leaved selected since all worked on previous kernels). I've
disabled them and the problem persist.


> > > The first column of lsmod list the same modules in both kernels. The
> > > diff-ed dmesg is attached.
> >
> > Please provide the output of lsmod.
> >
> > If you are using one of the following drivers: lm78, smsc47b397,
> > smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
> > (libsensors.so.3.1.1 or later).
>
> I've attached the lsmod for 2.6.22-rc.

You didn't.



:) Right, sorry. Now it is.


> I'm not using any of the listed drivers.

How strange, why are they loaded then?


My reply refers to your list of drivers that require a certain version
of lm-sensors.


> However the lm-sensors package is version 2.10.1-3 and
> libsensors.so.3.1.1 is on my system too (package libsensors3).

Can you please share the output of "sensors" under both kernels 2.6.21.1
and 2.6.22-rc1.


Sure. On 2.6.21.1:

via686a-isa-6000
Adapter: ISA adapter
CPU core:  +1.63 V  (min =  +0.06 V, max =  +3.10 V)
+2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
+5V:   +5.05 V  (min =  +4.73 V, max =  +5.20 V)
+12V: +12.30 V  (min = +11.35 V, max = +12.48 V)
CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
P/S Fan:  2657 RPM  (min = 42187 RPM, div = 2)  ALARM
SYS Temp:  +40.9°C  (high =  +146°C, hyst =   -71°C)
CPU Temp:  +43.3°C  (high =  +146°C, hyst =   -71°C)
SBr Temp:  +24.9°C  (high =   -63°C, hyst =   -71°C)   ALARM

while on 2.6.22-rc1:

via686a-i2c-9191-6000
ERROR: Can't get adapter or algorithm?!?
CPU core:  +1.65 V  (min =  +0.06 V, max =  +3.10 V)
+2.5V: +2.45 V  (min =  +0.06 V, max =  +3.10 V)
I/O:   +3.52 V  (min =  +3.12 V, max =  +3.45 V)   ALARM
+5V:   +5.08 V  (min =  +4.73 V, max =  +5.20 V)
+12V: +12.24 V  (min = +11.35 V, max = +12.48 V)
CPU Fan: 0 RPM  (min = 42187 RPM, div = 2)
P/S Fan: 0 RPM  (min = 42187 RPM, div = 2)  ALARM
SYS Temp:  +41.3°C  (high =  +146°C, hyst =   -71°C)
CPU Temp:  +41.8°C  (high =  +146°C, hyst =   -71°C)
SBr Temp:  +24.9°C  (high =   -63°C, hyst =   -71°C)   ALARM

In both kernels I have set:

I2C Algorithms  --->
  I2C PCF 8584 interfaces
  I2C PCA 9564 interfaces


I would also be interested in a diff of /proc/ioports between 2.6.21.1
and 2.6.22-rc1.



The diff is empty.


--
Jean Delvare



   ~ Antonio


lsmod.2.6.22-rc1.gz
Description: GNU Zip compressed data


Re: Linux 2.6.22-rc1

2007-05-14 Thread Jean Delvare
Hi Antonino,

On Mon, 14 May 2007 10:34:08 +0200, Antonino Ingargiola wrote:
> 2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
> [cut]
> > I am not familiar with the gnome sensors applet. Does it say where it
> > is getting the data (driver name, device name...)?
> 
> The applet settings show a list of sensors under the libsensors name.
> Those are the sensors that work on 2.6.21.1.
> 
> However the acpi and i2c section of the two config are
> > > identical. I report the only selected options:
> > >
> > > Power management options (ACPI, APM)  --->
> > >   [*] Power Management support
> > >   [*]   Software Suspend (Hibernation)
> > >   ACPI (Advanced Configuration and Power Interface) Support  --->
> > > [*] ACPI Support
> > > [*]   Sleep States
> > >Button
> > >Video
> > >Fan
> > >Processor
> > >  Thermal Zone
> > > (0)   Disable ACPI for systems before Jan 1st this year
> > >
> > > Device Drivers  --->
> > >   I2C support  --->
> > >I2C device interface
> > > I2C Hardware Bus support  --->
> > >VIA VT82C596/82C686/82xx and CX700
> >
> > You forgot to list the Hardware Monitoring support options.
> 
> Sorry. Here it is (they are identical in the two config):
> 
> Hardware Monitoring support  --->
>   <*> Hardware Monitoring support
>   <*> Abit uGuru
>VIA686A
>   <*> IBM Hard Drive Active Protection System (hdaps)
> 
> But I'm quite sure that the only module used is VIA686A (I'm
> rebuilding to confirm).

This is a rather bad idea to build the abituguru and hdaps drivers into
your kernel if you don't have these devices. Especially abituguru, as
it does arbitrary port probing.

> > > The first column of lsmod list the same modules in both kernels. The
> > > diff-ed dmesg is attached.
> >
> > Please provide the output of lsmod.
> >
> > If you are using one of the following drivers: lm78, smsc47b397,
> > smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
> > (libsensors.so.3.1.1 or later).
> 
> I've attached the lsmod for 2.6.22-rc.

You didn't.

> I'm not using any of the listed drivers.

How strange, why are they loaded then?

> However the lm-sensors package is version 2.10.1-3 and
> libsensors.so.3.1.1 is on my system too (package libsensors3).

Can you please share the output of "sensors" under both kernels 2.6.21.1
and 2.6.22-rc1.

I would also be interested in a diff of /proc/ioports between 2.6.21.1
and 2.6.22-rc1.

-- 
Jean Delvare
-
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 2.6.22-rc1, 'nother randconfig

2007-05-14 Thread David Howells
Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> net/built-in.o: In function `rxrpc_destroy_all_calls':
> (.exit.text+0x71d): undefined reference to `rxrpc_call_states'
> make: *** [.tmp_vmlinux1] Error 1

This is the problem:

# CONFIG_PROC_FS is not set
CONFIG_AF_RXRPC=y

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: Linux 2.6.22-rc1

2007-05-14 Thread Antonino Ingargiola

2007/5/14, Jean Delvare <[EMAIL PROTECTED]>:
[cut]

I am not familiar with the gnome sensors applet. Does it say where it
is getting the data (driver name, device name...)?


The applet settings show a list of sensors under the libsensors name.
Those are the sensors that work on 2.6.21.1.

However the acpi and i2c section of the two config are

> identical. I report the only selected options:
>
> Power management options (ACPI, APM)  --->
>   [*] Power Management support
>   [*]   Software Suspend (Hibernation)
>   ACPI (Advanced Configuration and Power Interface) Support  --->
> [*] ACPI Support
> [*]   Sleep States
>Button
>Video
>Fan
>Processor
>  Thermal Zone
> (0)   Disable ACPI for systems before Jan 1st this year
>
> Device Drivers  --->
>   I2C support  --->
>I2C device interface
> I2C Hardware Bus support  --->
>VIA VT82C596/82C686/82xx and CX700

You forgot to list the Hardware Monitoring support options.


Sorry. Here it is (they are identical in the two config):

Hardware Monitoring support  --->
 <*> Hardware Monitoring support
 <*> Abit uGuru
  VIA686A
 <*> IBM Hard Drive Active Protection System (hdaps)

But I'm quite sure that the only module used is VIA686A (I'm
rebuilding to confirm).


> The first column of lsmod list the same modules in both kernels. The
> diff-ed dmesg is attached.

Please provide the output of lsmod.

If you are using one of the following drivers: lm78, smsc47b397,
smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
(libsensors.so.3.1.1 or later).



I've attached the lsmod for 2.6.22-rc. I'm not using any of the listed
drivers. However the lm-sensors package is version 2.10.1-3 and
libsensors.so.3.1.1 is on my system too (package libsensors3).

Thanks.


--
Jean Delvare


   ~ Antonio
-
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] driver core: fix warning of temporarily unused multithreaded probing function (was: Re: Linux 2.6.22-rc1)

2007-05-14 Thread Cornelia Huck
On Sun, 13 May 2007 11:47:53 +0200,
Borislav Petkov <[EMAIL PROTECTED]> wrote:

> if I'm not mistaken, despite the PCI_MULTITHREAD_PROBE removal,
> Cornelia Huck wanted to keep 
> driver-core-per-subsystem-multithreaded-probing.patch:
> 
> 
> > Wouldn't per-subsystem multithreaded probing just expose bugs that
> > could also be exposed on SMP systems?
> 
> Yes, it would be the same.
> 

Hm, I don't think I'll follow up with this - we need a different
approach, I guess.

> However, device_probe_drivers() remains temporarily unused, so we either
> suppress the compiler warning or remove the whole function altogether. The
> following patch does the first.

I'd prefer to kill device_probe_drivers(). If we really need something
like this sometime in the future, we can easily resurrect it.

Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>

---
 drivers/base/dd.c |   13 -
 1 file changed, 13 deletions(-)

--- linux-2.6.orig/drivers/base/dd.c
+++ linux-2.6/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device
return driver_probe_device(drv, dev);
 }
 
-static int device_probe_drivers(void *data)
-{
-   struct device *dev = data;
-   int ret = 0;
-
-   if (dev->bus) {
-   down(&dev->sem);
-   ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
-   up(&dev->sem);
-   }
-   return ret;
-}
-
 /**
  * device_attach - try to attach device to a driver.
  * @dev:   device.
-
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 2.6.22-rc1

2007-05-13 Thread Satyam Sharma

Hi David,

On 5/14/07, David Miller <[EMAIL PROTECTED]> wrote:

From: Tilman Schmidt <[EMAIL PROTECTED]>
Date: Sun, 13 May 2007 20:19:09 +0200

> Would it be asking too much to have help texts on the following
> new (wrt 2.6.21) configuration options?
>
> ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)

This one is a case where the option makes no sense by itself,
it provides the core common code for other front-end drivers.

The documentation exists in those front end drivers, which
in turn auto-matically select and enable this config option.

It would be nice if there was a Kconfig way to not provide
this thing at all unless one of the front-ends got selected


Yeah, so the Kconfig-blessed way that you're looking for is:

config SCSI_ESP_CORE
tristate
depends on SCSI && SCSI_SPI_ATTRS
default y if SCSI_SUNESP=y
default m if SCSI_SUNESP=m

Add other front-ends (other than SCSI_SUNESP) to the last
two lines, as applicable.

Important: And then *remove* the "select SCSI_ESP_CORE"
from the Kconfig options of the front-ends themselves.

[ You could do something similar with SCSI_SPI_ATTRS
also, it looks like to be something that probably never makes
sense alone either, and needs only to be automatically pulled
in by other options (?) ]

[ Note that "select"ing stuff that is not library-like and itself
depends on other stuff is a Bad Thing. ]


but on the otherhand I like how anyone can select it and thus
test the build of it :-)


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: Linux 2.6.22-rc1

2007-05-13 Thread Jean Delvare
Hi Antonino, hi Linus,

On Sun, 13 May 2007 20:50:54 +0200, Antonino Ingargiola wrote:
> 2007/5/13, Linus Torvalds <[EMAIL PROTECTED]>:
> > On Sun, 13 May 2007, Antonino Ingargiola wrote:
> > >
> > > On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> > > applet "Sensors Applet" give an error message "No chip detected".
> > > Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> > > (I've only only done  make oldconfig).

I am not familiar with the gnome sensors applet. Does it say where it
is getting the data (driver name, device name...)?

> > One thing to check is that "make oldconfig" can actually change the
> > configuration if things were moved behind a new top-level configuration
> > parameter or such. I'm not saying that's the case here, but it's possible
> > that things like the i2c changes might have made you inadvertedly changed
> > some config option.
> 
> I suspected so. However the acpi and i2c section of the two config are
> identical. I report the only selected options:
> 
> Power management options (ACPI, APM)  --->
>   [*] Power Management support
>   [*]   Software Suspend (Hibernation)
>   ACPI (Advanced Configuration and Power Interface) Support  --->
> [*] ACPI Support
> [*]   Sleep States
>Button
>Video
>Fan
>Processor
>  Thermal Zone
> (0)   Disable ACPI for systems before Jan 1st this year
> 
> Device Drivers  --->
>   I2C support  --->
>I2C device interface
> I2C Hardware Bus support  --->
>VIA VT82C596/82C686/82xx and CX700

You forgot to list the Hardware Monitoring support options.

> > > Is this considered a regression or can be due to userland 
> > > incompatibilities?
> >
> > It's a regression, although I'd like to know more about your cases. It's
> > just hard to tell what happened: was it a i2c/hwmon driver that got
> > broken, or is it some sysfs file that got buggered, or what..
> >
> > For example, "dmesg" output before and after (preferably as a diff between
> > the two), and what modules you had loaded in the working/nonworking case.
> 
> The first column of lsmod list the same modules in both kernels. The
> diff-ed dmesg is attached.

Please provide the output of lsmod.

If you are using one of the following drivers: lm78, smsc47b397,
smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
(libsensors.so.3.1.1 or later).

-- 
Jean Delvare
-
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: Fwd: Re: Linux 2.6.22-rc1

2007-05-13 Thread Jan Engelhardt

On May 14 2007 10:55, Mattia Dongili wrote:
>On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote:
>> On May 12 2007 20:20, Linus Torvalds wrote:
>> >
>> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>> 
>> I have hit a randconfig compile failure. .config attached.
>> 
>>   LD  .tmp_vmlinux1
>> drivers/built-in.o: In function `acpi_bus_generate_event':
>> (.text+0x233f7): undefined reference to `event_is_open'
>> drivers/built-in.o: In function `acpi_bus_get_power':
>> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
>> drivers/built-in.o: In function `acpi_bus_set_power':
>> (.text+0x237c3): undefined reference to `acpi_power_transition'
>> drivers/built-in.o: In function `acpi_bus_set_power':
>> (.text+0x23835): undefined reference to `acpi_power_transition'
>> drivers/built-in.o: In function `sony_pic_fanspeed_store':
>> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
>> drivers/built-in.o: In function `sony_pic_fanspeed_show':
>> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
>> make: *** [.tmp_vmlinux1] Error 1
>
>I actually can't reproduce it with your .config.

But I can. Did you try it on x86_64? From 2.6.22-rc1 [
commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ?

bzip2 -cd randconfig-1.bz2 >.config
make -j8

  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86_64/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol '
drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_G
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config sym
drivers/input/mouse/Kconfig:181:warning: 'select' used by config symbol
  CHK include/linux/version.h
  UPD include/linux/version.h
  CHK include/linux/utsrelease.h
  UPD include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86_64


>>From a clean tree, running make fires up the oldconfig which fixes the
>many missing/garbled dependencies. In any case SONY_LAPTOP depends on
>ACPI which always build EC statically if selected.

I really presume it is something on x86_64, because doing

gzip -cd /proc/config.gz
make

on i386 seemed to compile fine - including the sony modules.




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: Linux 2.6.22-rc1

2007-05-13 Thread David Miller
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Mon, 14 May 2007 06:37:14 +0200

> The above is almost the help entry seeked for this option.
> For some this is maybe given from the option name,
> but for other the above info is a help.
> 
> So either provide help or do not have the option visible.
> I would prefer the first.

Agreed, I'll cook something up.
-
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 2.6.22-rc1

2007-05-13 Thread Sam Ravnborg
On Sun, May 13, 2007 at 04:20:59PM -0700, David Miller wrote:
> From: Tilman Schmidt <[EMAIL PROTECTED]>
> Date: Sun, 13 May 2007 20:19:09 +0200
> 
> > Would it be asking too much to have help texts on the following
> > new (wrt 2.6.21) configuration options?
> > 
> > ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
> 
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
> 
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.
> 
> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)
The above is almost the help entry seeked for this option.
For some this is maybe given from the option name,
but for other the above info is a help.

So either provide help or do not have the option visible.
I would prefer the first.

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: Fwd: Re: Linux 2.6.22-rc1

2007-05-13 Thread Mattia Dongili
On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote:
> On May 12 2007 20:20, Linus Torvalds wrote:
> >
> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
> 
> I have hit a randconfig compile failure. .config attached.
> 
>   LD  .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_bus_generate_event':
> (.text+0x233f7): undefined reference to `event_is_open'
> drivers/built-in.o: In function `acpi_bus_get_power':
> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x237c3): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x23835): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> make: *** [.tmp_vmlinux1] Error 1

I actually can't reproduce it with your .config.
>From a clean tree, running make fires up the oldconfig which fixes the
many missing/garbled dependencies. In any case SONY_LAPTOP depends on
ACPI which always build EC statically if selected.

clues?

-- 
mattia
:wq!
-
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 2.6.22-rc1

2007-05-13 Thread andrew hendry

sorry, forgot to CC mailing list last time.

build errors from make randconfig

# CONFIG_SMP is not set
CONFIG_X86_VOYAGER=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

arch/i386/kernel/built-in.o: In function `vic_sys_interrupt':
(.text+0x2770): undefined reference to `smp_vic_sys_interrupt'
arch/i386/kernel/built-in.o: In function `vic_cmn_interrupt':
(.text+0x27a8): undefined reference to `smp_vic_cmn_interrupt'
arch/i386/kernel/built-in.o: In function `vic_cpi_interrupt':
(.text+0x27e0): undefined reference to `smp_vic_cpi_interrupt'
arch/i386/kernel/built-in.o: In function `qic_timer_interrupt':
(.text+0x2818): undefined reference to `smp_qic_timer_interrupt'
arch/i386/kernel/built-in.o: In function `qic_invalidate_interrupt':
(.text+0x2850): undefined reference to `smp_qic_invalidate_interrupt'
arch/i386/kernel/built-in.o: In function `qic_reschedule_interrupt':
(.text+0x2888): undefined reference to `smp_qic_reschedule_interrupt'
arch/i386/kernel/built-in.o: In function `qic_enable_irq_interrupt':
(.text+0x28c0): undefined reference to `smp_qic_enable_irq_interrupt'
arch/i386/kernel/built-in.o: In function `qic_call_function_interrupt':
(.text+0x28f8): undefined reference to `smp_qic_call_function_interrupt'
arch/i386/kernel/built-in.o: In function `setup_bootmem_allocator':
(.init.text+0x58a): undefined reference to `find_smp_config'
arch/i386/mach-voyager/built-in.o: In function `voyager_power_off':
(.text+0x18f): undefined reference to `voyager_cat_power_off'
arch/i386/mach-voyager/built-in.o: In function `thread':
voyager_thread.c:(.text+0x3b8): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x405): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x418): undefined reference to `voyager_cat_psi'
voyager_thread.c:(.text+0x452): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x46c): undefined reference to `voyager_status'

CONFIG_SMP=y
CONFIG_X86_VOYAGER=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

arch/i386/kernel/built-in.o: In function `msr_read':
msr.c:(.text+0xa614): undefined reference to `smp_call_function_single'
arch/i386/kernel/built-in.o: In function `msr_write':
msr.c:(.text+0xa710): undefined reference to `smp_call_function_single'
arch/i386/kernel/built-in.o: In function `cpuid_read':
cpuid.c:(.text+0xa8d0): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `wrmsr_on_cpu':
(.text+0x63): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `rdmsr_on_cpu':
(.text+0xb6): undefined reference to `smp_call_function_single'
make: *** [.tmp_vmlinux1] Error 1

CONFIG_SMP=y
CONFIG_X86_VOYAGER=y
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

arch/i386/lib/built-in.o: In function `wrmsr_on_cpu':
(.text+0x63): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `rdmsr_on_cpu':
(.text+0xb6): undefined reference to `smp_call_function_single'


On 5/13/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:


Ok, the merge window has closed, and 2.6.22-rc1 is out there.

The diffstat and shortlogs are way too big to fit under the kernel mailing
list limits, and the changes are all over the place. Almost seven thousand
files changed, and that's not double-counting the files that got moved
around.

Architecture updates, drivers, filesystems, networking, security, build
scripts, reorganizations, cleanups.. You name it, it's there.

You want a new firewire stack? We've got it. New wireless networking
infrastructure? Check. New infiniband drivers? Digital video drivers? A
totally new CPU architecture (blackfin)? Check, check, check.

That said, I think (and certainly hope) that this will not be nearly as
painful as the big fundamental timer changes for 2.6.21, and while there
are some pretty core changes there (like the new SLUB allocator, which
hopefully will end up replacing both SLAB and SLOB), it feels pretty
solid, and not as scary as ripping the carpet from under the timer
infrastructure.

So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good reports!

Linus
-
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: Linux 2.6.22-rc1

2007-05-13 Thread Tilman Schmidt
Am 14.05.2007 01:20 schrieb David Miller:
>>
>> ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
> 
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
> 
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.

Thanks for the explanation. I never saw those other front-end
drivers, perhaps because for lack of information I just chose
the default of "N" on this one.

> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)

Well, as it stands, I am presented with that option but I don't
have the faintest idea what "ESP" is and whether it would even
be worth attempting to compile it. I would have preferred to
see at least a short explanation of the term in order to decide
whether it would be worth trying.

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: Linux 2.6.22-rc1

2007-05-13 Thread Roland Dreier
 > > Would it be asking too much to have help texts on the following
 > > new (wrt 2.6.21) configuration options?
 > > 
 > > ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
 > 
 > This one is a case where the option makes no sense by itself,
 > it provides the core common code for other front-end drivers.
 > 
 > The documentation exists in those front end drivers, which
 > in turn auto-matically select and enable this config option.
 > 
 > It would be nice if there was a Kconfig way to not provide
 > this thing at all unless one of the front-ends got selected
 > but on the otherhand I like how anyone can select it and thus
 > test the build of it :-)

If this is just an internal option that people shouldn't have to deal
with, why have a prompt at all?  AFAIK the following (untested) patch
should do exactly what you want.

FWIW:
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index e62d23f..5366913 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1754,7 +1754,7 @@ config SUN3X_ESP
  machines.  Say Y here to compile in support for it.
 
 config SCSI_ESP_CORE
-   tristate "ESP Scsi Driver Core"
+   tristate
depends on SCSI
select SCSI_SPI_ATTRS
 
-
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 2.6.22-rc1

2007-05-13 Thread David Miller
From: Tilman Schmidt <[EMAIL PROTECTED]>
Date: Sun, 13 May 2007 20:19:09 +0200

> Would it be asking too much to have help texts on the following
> new (wrt 2.6.21) configuration options?
> 
> ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)

This one is a case where the option makes no sense by itself,
it provides the core common code for other front-end drivers.

The documentation exists in those front end drivers, which
in turn auto-matically select and enable this config option.

It would be nice if there was a Kconfig way to not provide
this thing at all unless one of the front-ends got selected
but on the otherhand I like how anyone can select it and thus
test the build of 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: Linux 2.6.22-rc1

2007-05-13 Thread Jeff Chua

On 5/13/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:


Ok, the merge window has closed, and 2.6.22-rc1 is out there.


Got this ...

Thanks,
Jeff.

# make config
scripts/kconfig/conf arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol
'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning: 'select' used by config symbol
'UCC_GETH' refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:181:warning: 'select' used by config
symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
-
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 2.6.22-rc1

2007-05-13 Thread Antonino Ingargiola

Hi,

2007/5/13, Linus Torvalds <[EMAIL PROTECTED]>:



On Sun, 13 May 2007, Antonino Ingargiola wrote:
>
> On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> applet "Sensors Applet" give an error message "No chip detected".
> Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> (I've only only done  make oldconfig).

One thing to check is that "make oldconfig" can actually change the
configuration if things were moved behind a new top-level configuration
parameter or such. I'm not saying that's the case here, but it's possible
that things like the i2c changes might have made you inadvertedly changed
some config option.


I suspected so. However the acpi and i2c section of the two config are
identical. I report the only selected options:

Power management options (ACPI, APM)  --->
 [*] Power Management support
 [*]   Software Suspend (Hibernation)
 ACPI (Advanced Configuration and Power Interface) Support  --->
   [*] ACPI Support
   [*]   Sleep States
  Button
  Video
  Fan
  Processor
Thermal Zone
   (0)   Disable ACPI for systems before Jan 1st this year

Device Drivers  --->
 I2C support  --->
  I2C device interface
   I2C Hardware Bus support  --->
  VIA VT82C596/82C686/82xx and CX700


> Is this considered a regression or can be due to userland incompatibilities?

It's a regression, although I'd like to know more about your cases. It's
just hard to tell what happened: was it a i2c/hwmon driver that got
broken, or is it some sysfs file that got buggered, or what..

For example, "dmesg" output before and after (preferably as a diff between
the two), and what modules you had loaded in the working/nonworking case.



The first column of lsmod list the same modules in both kernels. The
diff-ed dmesg is attached.


Linus


 ~ Antonio


diff-u-dmesg.2.6.21.1-dmesg.2.6.22-rc1.bz2
Description: BZip2 compressed data


Re: Linux 2.6.22-rc1

2007-05-13 Thread Tilman Schmidt
Am 13.05.2007 05:20 schrieb Linus Torvalds:
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
[...]
> So give it a good testing.

Would it be asking too much to have help texts on the following
new (wrt 2.6.21) configuration options?

ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
Ethernet (1 Mbit) (NETDEV_1) [Y/n] (NEW)

Those for the latter three could/should say something like the
one for the WLAN_80211 option.

-- 
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: Linux 2.6.22-rc1

2007-05-13 Thread Linus Torvalds


On Sun, 13 May 2007, Antonino Ingargiola wrote:
> 
> On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> applet "Sensors Applet" give an error message "No chip detected".
> Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> (I've only only done  make oldconfig).

One thing to check is that "make oldconfig" can actually change the
configuration if things were moved behind a new top-level configuration 
parameter or such. I'm not saying that's the case here, but it's possible 
that things like the i2c changes might have made you inadvertedly changed 
some config option.

> Is this considered a regression or can be due to userland incompatibilities?

It's a regression, although I'd like to know more about your cases. It's 
just hard to tell what happened: was it a i2c/hwmon driver that got 
broken, or is it some sysfs file that got buggered, or what..

For example, "dmesg" output before and after (preferably as a diff between 
the two), and what modules you had loaded in the working/nonworking case.

Linus
-
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 2.6.22-rc1

2007-05-13 Thread Antonino Ingargiola

2007/5/13, Linus Torvalds <[EMAIL PROTECTED]>:


Ok, the merge window has closed, and 2.6.22-rc1 is out there.


[cut]


So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good reports!



On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
applet "Sensors Applet" give an error message "No chip detected".
Works fine on 2.6.21.1 (it show cpu temperature) with the same config
(I've only only done  make oldconfig).

$ lspci
Is this considered a regression or can be due to userland incompatibilities?
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P]
System Controller (rev 13)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
Controller (rev 1a)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
00:0f.1 Input device controller: Creative Labs SB Audigy Game Port (rev 03)
00:0f.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
QY [Radeon 7000/VE]

Config attached.

More info on request (sorry if this is not just a *good* report).


Linus


 ~ Antonio


config-2.6.22-rc1-vanilla.bz2
Description: BZip2 compressed data


Re: Linux 2.6.22-rc1

2007-05-13 Thread Alessandro Suardi

On 5/13/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:


Ok, the merge window has closed, and 2.6.22-rc1 is out there.


[snip]

I took a more careful look than with recent -gitXX, and
for reporting's sake here's a few MODPOST warnings:

 MODPOST vmlinux
WARNING: init/built-in.o - Section mismatch: reference to .init.text:
from .text between 'rest_init' (at offset 0xfd) and 'try_name'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:
from .text between 'kmem_cache_create' (at offset 0x196e4) and
'cache_reap'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:
from .text between 'kmem_cache_create' (at offset 0x19716) and
'cache_reap

Grepping in my recent kernel build logs, the rest_init one
seems to be present since -git7 but wasn't in -git6.

Googling around seems that this has already been looked
into in the 2.6.20-rc series, with patches that may or may
not have made it into mainline.


I still have old .config files, so if there's anything useful I
can do to provide more info, just holler.

ciao,

--alessandro

"Did you get married but forgot to get divorced ?"

(Danny and Dusty, 'The Good Old Days')
-
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 2.6.22-rc1

2007-05-13 Thread Indan Zupancic
Hello,

When compiling 2.6.22-rc1 I get the following (new and interesting) warnings:

GEN /home/indan/src/git/obj/Makefile
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning:
'select' used by config symbol 'PMAC_APM_EMU'
refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning:
'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning:
'select' used by config symbol 'KEYBOARD_ATARI'
refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:181:warning:
'select' used by config symbol 'MOUSE_ATARI'
refers to undefined symbol 'ATARI_KBD_CORE'

And:

/home/indan/src/git/linux-2.6/drivers/base/dd.c:211:
warning: 'device_probe_drivers' defined but not used

No idea how the first warnings can show up at all when I've selected nothing
related to them, nor who to CC for it.

Added Greg to the CC list for the second warning. device_probe_drivers() is
a static function, so it seems safe to remove.

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device_driver * drv, 
void * data)
return driver_probe_device(drv, dev);
 }

-static int device_probe_drivers(void *data)
-{
-   struct device *dev = data;
-   int ret = 0;
-
-   if (dev->bus) {
-   down(&dev->sem);
-   ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
-   up(&dev->sem);
-   }
-   return ret;
-}
-
 /**
  * device_attach - try to attach device to a driver.
  * @dev:   device.


-
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] driver core: fix warning of temporarily unused multithreaded probing function (was: Re: Linux 2.6.22-rc1)

2007-05-13 Thread Borislav Petkov
Hi,

if I'm not mistaken, despite the PCI_MULTITHREAD_PROBE removal,
Cornelia Huck wanted to keep 
driver-core-per-subsystem-multithreaded-probing.patch:


> Wouldn't per-subsystem multithreaded probing just expose bugs that
> could also be exposed on SMP systems?

Yes, it would be the same.


However, device_probe_drivers() remains temporarily unused, so we either
suppress the compiler warning or remove the whole function altogether. The
following patch does the first.

-
From: Borislav Petkov <[EMAIL PROTECTED]>

This patch shuts the following warning:

drivers/base/dd.c:211: warning: 'device_probe_drivers' defined but not used

Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

--

Index: 22-rc1/drivers/base/dd.c
===
--- 22-rc1/drivers/base/dd.c.orig
+++ 22-rc1/drivers/base/dd.c
@@ -207,7 +207,7 @@ static int __device_attach(struct device
return driver_probe_device(drv, dev);
 }

-static int device_probe_drivers(void *data)
+static int __used device_probe_drivers(void *data)
 {
struct device *dev = data;
int ret = 0;


-- 
Regards/Gruß,
Boris.
-
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 2.6.22-rc1, 'nother randconfig

2007-05-13 Thread Jan Engelhardt
On May 12 2007 20:20, Linus Torvalds wrote:
>
>Ok, the merge window has closed, and 2.6.22-rc1 is out there.



net/built-in.o: In function `rxrpc_destroy_all_calls':
(.exit.text+0x71d): undefined reference to `rxrpc_call_states'
make: *** [.tmp_vmlinux1] Error 1

.config atx.

Jan
-- 

randconfig-2.bz2
Description: BZip2 compressed data


Re: Linux 2.6.22-rc1

2007-05-13 Thread Jan Engelhardt
On May 12 2007 20:20, Linus Torvalds wrote:
>
>Ok, the merge window has closed, and 2.6.22-rc1 is out there.

I have hit a randconfig compile failure. .config attached.

  LD  .tmp_vmlinux1
drivers/built-in.o: In function `acpi_bus_generate_event':
(.text+0x233f7): undefined reference to `event_is_open'
drivers/built-in.o: In function `acpi_bus_get_power':
(.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x237c3): undefined reference to `acpi_power_transition'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x23835): undefined reference to `acpi_power_transition'
drivers/built-in.o: In function `sony_pic_fanspeed_store':
sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
drivers/built-in.o: In function `sony_pic_fanspeed_show':
sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
make: *** [.tmp_vmlinux1] Error 1


Jan
-- 

randconfig-1.bz2
Description: BZip2 compressed data


Re: Linux 2.6.22-rc1

2007-05-13 Thread Jan Engelhardt

On May 13 2007 14:00, Jeff Chua wrote:
>> So give it a good testing. We'll see how the regression tracking ends up
>> working, but in order to actually track that, we want people actively
>> testing -rc1 and making good reports!
>
> Here's a little patch to fix filemap.c compilation problem ...

gmail greets with broken spacing :-/

> --- linux/mm/filemap.c.org2007-05-13 13:54:16 +0800
> +++ linux/mm/filemap.c2007-05-13 13:54:25 +0800
> @@ -782,6 +782,7 @@
> read_unlock_irq(&mapping->tree_lock);
> return ret;
> }
> +EXPORT_SYMBOL(find_get_pages);
> EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> @@ -840,8 +841,6 @@
>
>   ra->ra_pages /= 4;
> }
> -EXPORT_SYMBOL(find_get_pages);
> -EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> * do_generic_mapping_read - generic file read routine

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: Linux 2.6.22-rc1

2007-05-12 Thread Jeff Chua

Take that back. It's after patching reiser4-for-2.6.21.patch.gz that
causes duplicated export symbols.

Sorry,
Jeff.


On 5/13/07, Jeff Chua <[EMAIL PROTECTED]> wrote:


Linus,

> So give it a good testing. We'll see how the regression tracking ends up
> working, but in order to actually track that, we want people actively
> testing -rc1 and making good reports!

Here's a little patch to fix filemap.c compilation problem ...


Thanks,
Jeff


--- linux/mm/filemap.c.org  2007-05-13 13:54:16 +0800
+++ linux/mm/filemap.c  2007-05-13 13:54:25 +0800
@@ -782,6 +782,7 @@
read_unlock_irq(&mapping->tree_lock);
return ret;
  }
+EXPORT_SYMBOL(find_get_pages);
  EXPORT_SYMBOL(find_get_pages_tag);

  /**
@@ -840,8 +841,6 @@

ra->ra_pages /= 4;
  }
-EXPORT_SYMBOL(find_get_pages);
-EXPORT_SYMBOL(find_get_pages_tag);

  /**
   * do_generic_mapping_read - generic file read routine



-
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 2.6.22-rc1

2007-05-12 Thread Jeff Chua


Linus,


So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good reports!


Here's a little patch to fix filemap.c compilation problem ...


Thanks,
Jeff


--- linux/mm/filemap.c.org  2007-05-13 13:54:16 +0800
+++ linux/mm/filemap.c  2007-05-13 13:54:25 +0800
@@ -782,6 +782,7 @@
read_unlock_irq(&mapping->tree_lock);
return ret;
 }
+EXPORT_SYMBOL(find_get_pages);
 EXPORT_SYMBOL(find_get_pages_tag);

 /**
@@ -840,8 +841,6 @@

ra->ra_pages /= 4;
 }
-EXPORT_SYMBOL(find_get_pages);
-EXPORT_SYMBOL(find_get_pages_tag);

 /**
  * do_generic_mapping_read - generic file read routine

-
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/