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