Re: Kbuild problem
On Sat, 17 Feb 2007, Tilman Schmidt wrote: > Alright, then so be it. But that raises another question: > asyncdata.o is only needed for M105 and M101, not for the base > driver. How do I express in Kbuild that asyncdata.o is to be added > to gigaset-y only if CONFIG_GIGASET_M105 and CONFIG_GIGASET_M101 > are not both 'n'? The way this is typically done is via Kconfig. Add a config option ASYNCDATA (actually something more descriptive/specific would be better), add a "select ASYNCDATA" to the config options for m101 and m105, and then you can use CONFIG_ASYNCDATA to decide whether to add asyncdata.o in the Makefile. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
On Sat, 17 Feb 2007, Tilman Schmidt wrote: Alright, then so be it. But that raises another question: asyncdata.o is only needed for M105 and M101, not for the base driver. How do I express in Kbuild that asyncdata.o is to be added to gigaset-y only if CONFIG_GIGASET_M105 and CONFIG_GIGASET_M101 are not both 'n'? The way this is typically done is via Kconfig. Add a config option ASYNCDATA (actually something more descriptive/specific would be better), add a select ASYNCDATA to the config options for m101 and m105, and then you can use CONFIG_ASYNCDATA to decide whether to add asyncdata.o in the Makefile. --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
Bill Davidsen wrote:
> Philippe De Muyter wrote:
>> On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
>>> On Tue, Feb 06, 2007 at 09:52:17AM -0800, Joe Perches wrote:
On Tue, 2007-02-06 at 18:04 +0200, Ahmed S. Darwish wrote:
> A patch to use ARRAY_SIZE macro already defined in kernel.h
> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
>>> [...]
> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
> +int nelem = ARRAY_SIZE(procfsentries);
> int i;
>
> for (i=0; i < nelem; i++) {
For these patches, perhaps you can eliminate the temporary
variable and change the loop to the more common form of
for (i = 0; i < ARRAY_SIZE(array); i++) {
>>> Thanks, I think it's better too. Here's the modified patch.
>>>
>>> A patch to use ARRAY_SIZE macro when appropriate.
>>>
>>> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
>>> ---
>>> diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
>>> index d22c022..87fe89c 100644
>>> --- a/drivers/isdn/capi/capi.c
>>> +++ b/drivers/isdn/capi/capi.c
>>> @@ -1456,10 +1456,9 @@ static struct procfsentries {
>>>
>>> static void __init proc_init(void)
>>> {
>>> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
>>> int i;
>>>
>>> -for (i=0; i < nelem; i++) {
>>> +for (i = 0; i < ARRAY_SIZE(procfsentries); i++) {
>>> struct procfsentries *p = procfsentries + i;
>>> p->procent = create_proc_entry(p->name, p->mode, NULL);
>>> if (p->procent) p->procent->read_proc = p->read_proc;
>>> @@ -1468,10 +1467,9 @@ static void __init proc_init(void)
>>>
>>> static void __exit proc_exit(void)
>>> {
>>> -int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
>>> int i;
>>>
>>> -for (i=nelem-1; i >= 0; i--) {
>>> +for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
>>
>> I would write such decrementing loops as :
>>
>>for (i = ARRAY_SIZE(procfsentries); --i >= 0; ) {
>>
>> Long time ago, that produced better code. I did not check recently
>> though.
>
> Why would you write "--i >= 0" instead of just "i--"? The size of an
> array can't be negative.
>
In my opinion, the first way of writing it is the way to go. I've not
seen it put like the 2nd or 3rd way anywhere in the kernel (of course I
haven't read all of the code), and while it's correct, it's less
readable. I don't think gcc would generate different code between
variant 1 and 2, and anyway, this is called once at module init/exit
time, so whether you save 10 cycles there or not is totally insignificant.
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
Bill Davidsen wrote:
Philippe De Muyter wrote:
On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
On Tue, Feb 06, 2007 at 09:52:17AM -0800, Joe Perches wrote:
On Tue, 2007-02-06 at 18:04 +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
[...]
-int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
+int nelem = ARRAY_SIZE(procfsentries);
int i;
for (i=0; i nelem; i++) {
For these patches, perhaps you can eliminate the temporary
variable and change the loop to the more common form of
for (i = 0; i ARRAY_SIZE(array); i++) {
Thanks, I think it's better too. Here's the modified patch.
A patch to use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
---
diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index d22c022..87fe89c 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1456,10 +1456,9 @@ static struct procfsentries {
static void __init proc_init(void)
{
-int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
int i;
-for (i=0; i nelem; i++) {
+for (i = 0; i ARRAY_SIZE(procfsentries); i++) {
struct procfsentries *p = procfsentries + i;
p-procent = create_proc_entry(p-name, p-mode, NULL);
if (p-procent) p-procent-read_proc = p-read_proc;
@@ -1468,10 +1467,9 @@ static void __init proc_init(void)
static void __exit proc_exit(void)
{
-int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
int i;
-for (i=nelem-1; i = 0; i--) {
+for (i = ARRAY_SIZE(procfsentries) - 1; i = 0; i--) {
I would write such decrementing loops as :
for (i = ARRAY_SIZE(procfsentries); --i = 0; ) {
Long time ago, that produced better code. I did not check recently
though.
Why would you write --i = 0 instead of just i--? The size of an
array can't be negative.
In my opinion, the first way of writing it is the way to go. I've not
seen it put like the 2nd or 3rd way anywhere in the kernel (of course I
haven't read all of the code), and while it's correct, it's less
readable. I don't think gcc would generate different code between
variant 1 and 2, and anyway, this is called once at module init/exit
time, so whether you save 10 cycles there or not is totally insignificant.
--Kai
-
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: Undefined symbols in 2.6.11-rc5-mm1
> That's usually solved through #define's (see e.g. lib/extable.c). Well, you can obviously solve pretty much everything with #define's, but it's usually also the ugliest solution. >From my point of view, the preferences for solving issues like the extable.c one are: o Do it automatically. If the architectecture defines its own version, use that one -- otherwise use the default. o Take care of it by configuration options. Let the arch have CONFIG_GENERIC_EXTABLE_SORT (or not), and use that to determine whether to compile / link sort_extable() o Use a #define / #ifdef in the source file to conditionally compile things. Having a config option has the advantage that one can do obj-$(CONFIG_GENERIC_EXTABLE_SORT) += extable_sort.o which leaves the source code free of ugly #ifdef's. Obviously that only works if extable.c is split into extable_sort.o and extable_search.o. If one goes that step (fine IMO), one can however just add these files to lib-y, i.e. use the first solution - everything happens automatically, no need for ARCH_ defines, no need for new CONFIG options. > It's used by many filesystems plus some optional part of the USB code. > > Basically, there are two choices: > - always include a function > - include a function only if required > > The second one is possible, but object files are the wrong granularity - > why should it pull the whole parser.c if only match_strdup was required? Yes, object files are not necessarily the right granularity -- in fact, traditionally libraries are composed of object files which pretty much follow a "one function per file" principle, to get this right. However, two cases should be distinguished: o providing a default implementation. Obviously, this one needs separate files for separately needed units (like the extable.c example above) o providing a library functionality. Grouping multiple functions together isn't necessarily wrong, it just may cause slight inefficencies (pulling in unneeded code). I really don't think we want to go to one function per file but rather leave things grouped as they currently are. If someone needs match_strdup, they'll pull in all of parser.o. > You have all possibilities with #define's. Yes, but also all the ugliness. There's a trade-off where the optimal smallest binary kernel image comes with a bloated, unreadable, full of '#ifdef' kernel source. Noone wants that. If you can optimize the binary kernel image in some automated way with little impact on the source code, that's fine. Otherwise, you'll give up a little space savings for easier maintainability. > If you care about code size, CONFIG_PARSER gives the wrong granularity. Going more fine-grained is out of the question, IMO. If anything, going less fine-grained, i.e. include all of parser.o unconditionally is the way to go here. Currently, the only more fine-grained way would be to have ext2 in KConfig CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN. FAT would define CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN, CONFIG_MATCH_OCTAL, etc. That's insanity. > Everything lib-y does can be done with obj- and #define's. > And this way, it's done explicit. That's true. But more often than not, we don't care about explicitness, we care about cleanliness and readability. The ugliness is hidden somewhere, in includes, in Kconfig, in the build system. "module_init()" is very non-explicit, it does completely different things depending on whether a file is compiled into a module or the kernel. But we sure prefer the cleanliness of module_init() over having #ifdef's in each module which explicitly what happens. As I said it's all a trade-off, and it has much to do with taste. Code looking clean is important. However, hiding too much and jumping through hoops just so that something looks clean while all the magic happens somewhere deep inside unbeknowst to all but few gurus isn't right, either. This discussion doesn't really have much to do with the original issue anymore. Move parser.o to obj-y and be done with it -- in reality everyone needs it, anyway. EXPORT_SYMBOL() sometimes and kinda unpredictably not working in lib-y is tricky. But it produces obvious errors, unresolved symbols, not obscure un-debuggable bugs. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> This warning sounds like a good plan (but it won't let many objects stay
> inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
default implementation for dump_stack(). Most archs provide their own
implementation (and EXPORT_SYMBOL() it), and in this case we definitely
want the default version in lib to be thrown away, including its
EXPORT_SYMBOL. So the appended patch throws false positives and thus can
not be applied.
Still, many files in lib-y "should" be moved to obj-y. Then again, the
clear cases (e.g. ctype, vsnprintf) are getting used in the static kernel
image, so they get linked in anyway, moving them from lib-y to obj-y
doesn't make any difference whatsoever.
The interesting cases are more of the crc32 type -- some people may not
use this at all, so they want the space savings. Moving all of those into
obj-y unconditionally creates unnecessary bloat. Actually, crc32 already
did the right thing -- a config option. That would work for parser.o, too,
just make the filesystems which need it "select CONFIG_PARSER".
I think there are basically three cases of objects in lib-y:
o functions we clearly use anyway, e.g. vsprintf.o.
these should be always available, also for modules (pretty much every
module uses printk, right?)
So these should be in obj-y, however since they always get used in the
kernel, too, independent of the .config, in practice there's no
difference to them being in lib-y.
o "weak" implementations, which may be overwritten by a arch-specific
implementation.
These need to be in lib-y for this mechanism to work.
o Marginal cases like crc32.o, parser.o, bitmap.o
There are real world cases out there where these functions will never be
used, so just compiling them into the kernel because one day there may
be a module which wants to use them does cause some bloat. Making them
config options and have every module which needs them mention them in
Kconfig causes some bloat on the source side.
It's a trade-off. In my tree (current -bk), parser.o symbols are
referenced by procfs, i.e. 99.9% of all builds will pull it in anyway.
So putting it into obj-y is a good solution, IMO. (Do I hear the
embedded people cry?)
I guess in -mm this changed, which may justify going to CONFIG_PARSER
(along the lines of CONFIG_CRC32) way. Then again, .text of
parser.o is 0x373 bytes on my x86_64 system. Not a whole lot to
lose when it's compiled in unconditionally. (And it's used among others
by ext2 and ext3, so chances are, you need it anyway)
--Kai
= include/linux/module.h 1.92 vs edited =
--- 1.92/include/linux/module.h 2005-01-10 14:28:15 -05:00
+++ edited/include/linux/module.h 2005-03-05 10:49:05 -05:00
@@ -200,10 +200,18 @@
= { (unsigned long), __kstrtab_##sym }
#define EXPORT_SYMBOL(sym) \
+__EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, "")
#define EXPORT_SYMBOL_GPL(sym) \
+__EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, "_gpl")
+
+#ifdef KBUILD_LIB
+#define __EXPORT_SYMBOL_WARN DO_NOT_USE_EXPORT_SYMBOL_IN_LIBRARY_FILES;
+#else
+#define __EXPORT_SYMBOL_WARN
+#endif
#endif
= scripts/Makefile.build 1.53 vs edited =
--- 1.53/scripts/Makefile.build 2004-12-28 18:15:17 -05:00
+++ edited/scripts/Makefile.build 2005-03-05 10:34:44 -05:00
@@ -105,6 +105,8 @@
$(real-objs-m:.o=.s) : modkern_cflags := $(CFLAGS_MODULE)
$(real-objs-m:.o=.lst): modkern_cflags := $(CFLAGS_MODULE)
+$(lib-y) : lib_cflags := -DKBUILD_LIB
+
$(real-objs-m): quiet_modtag := [M]
$(real-objs-m:.o=.i) : quiet_modtag := [M]
$(real-objs-m:.o=.s) : quiet_modtag := [M]
= scripts/Makefile.lib 1.27 vs edited =
--- 1.27/scripts/Makefile.lib 2004-10-26 18:06:46 -04:00
+++ edited/scripts/Makefile.lib 2005-03-05 10:33:38 -05:00
@@ -126,7 +126,7 @@
endif
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
-$(__c_flags) $(modkern_cflags) \
+$(__c_flags) $(modkern_cflags) $(lib_cflags) \
$(basename_flags) $(modname_flags)
a_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
-
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: Undefined symbols in 2.6.11-rc5-mm1
On Sat, 5 Mar 2005, Adrian Bunk wrote: > And this can break as soon as the "unused" object files contains > EXPORT_SYMBOL's. > > Is it really worth it doing it in this non-intuitive way? I don't think it non-intuitive, it's how libraries work. However, as you say, it is broken for files containing EXPORT_SYMBOL. The obvious fix for this case is the one that akpm mentioned way earlier in this thread, move parser.o into $(obj-y). It should be rather easy to have the kernel build system warn you when you compile library objects exporting symbols. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Sat, 5 Mar 2005, Adrian Bunk wrote: And this can break as soon as the unused object files contains EXPORT_SYMBOL's. Is it really worth it doing it in this non-intuitive way? I don't think it non-intuitive, it's how libraries work. However, as you say, it is broken for files containing EXPORT_SYMBOL. The obvious fix for this case is the one that akpm mentioned way earlier in this thread, move parser.o into $(obj-y). It should be rather easy to have the kernel build system warn you when you compile library objects exporting symbols. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Sat, 5 Mar 2005, Adrian Bunk wrote:
This warning sounds like a good plan (but it won't let many objects stay
inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
default implementation for dump_stack(). Most archs provide their own
implementation (and EXPORT_SYMBOL() it), and in this case we definitely
want the default version in lib to be thrown away, including its
EXPORT_SYMBOL. So the appended patch throws false positives and thus can
not be applied.
Still, many files in lib-y should be moved to obj-y. Then again, the
clear cases (e.g. ctype, vsnprintf) are getting used in the static kernel
image, so they get linked in anyway, moving them from lib-y to obj-y
doesn't make any difference whatsoever.
The interesting cases are more of the crc32 type -- some people may not
use this at all, so they want the space savings. Moving all of those into
obj-y unconditionally creates unnecessary bloat. Actually, crc32 already
did the right thing -- a config option. That would work for parser.o, too,
just make the filesystems which need it select CONFIG_PARSER.
I think there are basically three cases of objects in lib-y:
o functions we clearly use anyway, e.g. vsprintf.o.
these should be always available, also for modules (pretty much every
module uses printk, right?)
So these should be in obj-y, however since they always get used in the
kernel, too, independent of the .config, in practice there's no
difference to them being in lib-y.
o weak implementations, which may be overwritten by a arch-specific
implementation.
These need to be in lib-y for this mechanism to work.
o Marginal cases like crc32.o, parser.o, bitmap.o
There are real world cases out there where these functions will never be
used, so just compiling them into the kernel because one day there may
be a module which wants to use them does cause some bloat. Making them
config options and have every module which needs them mention them in
Kconfig causes some bloat on the source side.
It's a trade-off. In my tree (current -bk), parser.o symbols are
referenced by procfs, i.e. 99.9% of all builds will pull it in anyway.
So putting it into obj-y is a good solution, IMO. (Do I hear the
embedded people cry?)
I guess in -mm this changed, which may justify going to CONFIG_PARSER
(along the lines of CONFIG_CRC32) way. Then again, .text of
parser.o is 0x373 bytes on my x86_64 system. Not a whole lot to
lose when it's compiled in unconditionally. (And it's used among others
by ext2 and ext3, so chances are, you need it anyway)
--Kai
= include/linux/module.h 1.92 vs edited =
--- 1.92/include/linux/module.h 2005-01-10 14:28:15 -05:00
+++ edited/include/linux/module.h 2005-03-05 10:49:05 -05:00
@@ -200,10 +200,18 @@
= { (unsigned long)sym, __kstrtab_##sym }
#define EXPORT_SYMBOL(sym) \
+__EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, )
#define EXPORT_SYMBOL_GPL(sym) \
+__EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, _gpl)
+
+#ifdef KBUILD_LIB
+#define __EXPORT_SYMBOL_WARN DO_NOT_USE_EXPORT_SYMBOL_IN_LIBRARY_FILES;
+#else
+#define __EXPORT_SYMBOL_WARN
+#endif
#endif
= scripts/Makefile.build 1.53 vs edited =
--- 1.53/scripts/Makefile.build 2004-12-28 18:15:17 -05:00
+++ edited/scripts/Makefile.build 2005-03-05 10:34:44 -05:00
@@ -105,6 +105,8 @@
$(real-objs-m:.o=.s) : modkern_cflags := $(CFLAGS_MODULE)
$(real-objs-m:.o=.lst): modkern_cflags := $(CFLAGS_MODULE)
+$(lib-y) : lib_cflags := -DKBUILD_LIB
+
$(real-objs-m): quiet_modtag := [M]
$(real-objs-m:.o=.i) : quiet_modtag := [M]
$(real-objs-m:.o=.s) : quiet_modtag := [M]
= scripts/Makefile.lib 1.27 vs edited =
--- 1.27/scripts/Makefile.lib 2004-10-26 18:06:46 -04:00
+++ edited/scripts/Makefile.lib 2005-03-05 10:33:38 -05:00
@@ -126,7 +126,7 @@
endif
c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
-$(__c_flags) $(modkern_cflags) \
+$(__c_flags) $(modkern_cflags) $(lib_cflags) \
$(basename_flags) $(modname_flags)
a_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
-
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: Undefined symbols in 2.6.11-rc5-mm1
That's usually solved through #define's (see e.g. lib/extable.c). Well, you can obviously solve pretty much everything with #define's, but it's usually also the ugliest solution. From my point of view, the preferences for solving issues like the extable.c one are: o Do it automatically. If the architectecture defines its own version, use that one -- otherwise use the default. o Take care of it by configuration options. Let the arch have CONFIG_GENERIC_EXTABLE_SORT (or not), and use that to determine whether to compile / link sort_extable() o Use a #define / #ifdef in the source file to conditionally compile things. Having a config option has the advantage that one can do obj-$(CONFIG_GENERIC_EXTABLE_SORT) += extable_sort.o which leaves the source code free of ugly #ifdef's. Obviously that only works if extable.c is split into extable_sort.o and extable_search.o. If one goes that step (fine IMO), one can however just add these files to lib-y, i.e. use the first solution - everything happens automatically, no need for ARCH_ defines, no need for new CONFIG options. It's used by many filesystems plus some optional part of the USB code. Basically, there are two choices: - always include a function - include a function only if required The second one is possible, but object files are the wrong granularity - why should it pull the whole parser.c if only match_strdup was required? Yes, object files are not necessarily the right granularity -- in fact, traditionally libraries are composed of object files which pretty much follow a one function per file principle, to get this right. However, two cases should be distinguished: o providing a default implementation. Obviously, this one needs separate files for separately needed units (like the extable.c example above) o providing a library functionality. Grouping multiple functions together isn't necessarily wrong, it just may cause slight inefficencies (pulling in unneeded code). I really don't think we want to go to one function per file but rather leave things grouped as they currently are. If someone needs match_strdup, they'll pull in all of parser.o. You have all possibilities with #define's. Yes, but also all the ugliness. There's a trade-off where the optimal smallest binary kernel image comes with a bloated, unreadable, full of '#ifdef' kernel source. Noone wants that. If you can optimize the binary kernel image in some automated way with little impact on the source code, that's fine. Otherwise, you'll give up a little space savings for easier maintainability. If you care about code size, CONFIG_PARSER gives the wrong granularity. Going more fine-grained is out of the question, IMO. If anything, going less fine-grained, i.e. include all of parser.o unconditionally is the way to go here. Currently, the only more fine-grained way would be to have ext2 in KConfig CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN. FAT would define CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN, CONFIG_MATCH_OCTAL, etc. That's insanity. Everything lib-y does can be done with obj- and #define's. And this way, it's done explicit. That's true. But more often than not, we don't care about explicitness, we care about cleanliness and readability. The ugliness is hidden somewhere, in includes, in Kconfig, in the build system. module_init() is very non-explicit, it does completely different things depending on whether a file is compiled into a module or the kernel. But we sure prefer the cleanliness of module_init() over having #ifdef's in each module which explicitly what happens. As I said it's all a trade-off, and it has much to do with taste. Code looking clean is important. However, hiding too much and jumping through hoops just so that something looks clean while all the magic happens somewhere deep inside unbeknowst to all but few gurus isn't right, either. This discussion doesn't really have much to do with the original issue anymore. Move parser.o to obj-y and be done with it -- in reality everyone needs it, anyway. EXPORT_SYMBOL() sometimes and kinda unpredictably not working in lib-y is tricky. But it produces obvious errors, unresolved symbols, not obscure un-debuggable bugs. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Fri, 4 Mar 2005, Adrian Bunk wrote: > > [...] So ld looks into the lib .a archive, determines that none of > > the symbols in that object file are needed to resolve a reference and > > drops the entire .o file. > Silly question: > What's the advantage of lib-y compared to obj-y? Basically exactly what I quoted above -- unused object files don't get linked into the kernel image and don't take up (wasted) space. On the other hand, files in obj-y get linked into the kernel unconditionally. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Fri, 4 Mar 2005, Rusty Russell wrote: > On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote: > > Why doesn't an EXPORT_SYMBOL create a reference? > > It does: EXPORT_SYMBOL(x) drops the address of "x", including > __attribute_used__, in the __ksymtab section. Well, the problem is that this is still an internal reference in the same object file. So ld looks into the lib .a archive, determines that none of the symbols in that object file are needed to resolve a reference and drops the entire .o file. Doing so, it drops the __ksymtab section as well, which otherwise would be used by the kernel to look up that symbol. So it drops the reference and the referencee ;), which is normally fine -- no unresolved symbols occur. Unfortunately, the kernel really needs to know the contents of the __ksymtab sections to correctly export those symbols, but it doesn't reference it in any explicit way. I don't think there's an easy fix, except for not putting such objects into an archive/lib, but to link them directly. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Fri, 4 Mar 2005, Rusty Russell wrote: On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote: Why doesn't an EXPORT_SYMBOL create a reference? It does: EXPORT_SYMBOL(x) drops the address of x, including __attribute_used__, in the __ksymtab section. Well, the problem is that this is still an internal reference in the same object file. So ld looks into the lib .a archive, determines that none of the symbols in that object file are needed to resolve a reference and drops the entire .o file. Doing so, it drops the __ksymtab section as well, which otherwise would be used by the kernel to look up that symbol. So it drops the reference and the referencee ;), which is normally fine -- no unresolved symbols occur. Unfortunately, the kernel really needs to know the contents of the __ksymtab sections to correctly export those symbols, but it doesn't reference it in any explicit way. I don't think there's an easy fix, except for not putting such objects into an archive/lib, but to link them directly. --Kai - 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: Undefined symbols in 2.6.11-rc5-mm1
On Fri, 4 Mar 2005, Adrian Bunk wrote: [...] So ld looks into the lib .a archive, determines that none of the symbols in that object file are needed to resolve a reference and drops the entire .o file. Silly question: What's the advantage of lib-y compared to obj-y? Basically exactly what I quoted above -- unused object files don't get linked into the kernel image and don't take up (wasted) space. On the other hand, files in obj-y get linked into the kernel unconditionally. --Kai - 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] Makefiles are not built using a Fortran compiler
On Tue, 8 Feb 2005, Sam Ravnborg wrote: > The SCCS rules is the sole reason why -rR has not been enabled. An easy way to make sure that the SCCS business is not a factor would be to explicitly put the SCCS rules into the Makefile -- it's just two lines. This way one could easily make sure there are no other problems incurred (I wouldn't think so, but...), and tackle the SCCS/bk business later. --Kai - 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] Makefiles are not built using a Fortran compiler
On Tue, 8 Feb 2005, Sam Ravnborg wrote: The SCCS rules is the sole reason why -rR has not been enabled. An easy way to make sure that the SCCS business is not a factor would be to explicitly put the SCCS rules into the Makefile -- it's just two lines. This way one could easily make sure there are no other problems incurred (I wouldn't think so, but...), and tackle the SCCS/bk business later. --Kai - 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: 2.4.6 PCMCIA NET modular build breakage
On Sat, 7 Jul 2001, Russell King wrote: > Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone > know the correct fix, other than reversing the change? It should be fine. > Since all net cards are modules, object list for pcmcia_net.o is empty and > kernel can't be linked. Could you reproduce this? (I don't think you can) Rules.make takes care of an empty $(obj-y) and builds an empty $(O_TARGET) file in this case, so linking this in should work fine. --Kai - 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: 2.4.6 PCMCIA NET modular build breakage
On Sat, 7 Jul 2001, Russell King wrote: Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone know the correct fix, other than reversing the change? It should be fine. Since all net cards are modules, object list for pcmcia_net.o is empty and kernel can't be linked. Could you reproduce this? (I don't think you can) Rules.make takes care of an empty $(obj-y) and builds an empty $(O_TARGET) file in this case, so linking this in should work fine. --Kai - 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/
[BUG] Re: Linux 2.4.5-ac22
On Fri, 29 Jun 2001, Alan Cox wrote: > 2.4.5-ac20 > o Commence resync with 2.4.6pre5 I updated my laptop to 2.4.5-ac21 today. After reboot, I found a strange problem: My network card wouldn't initialize properly (eepro100). Jun 29 21:26:31 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Jun 29 21:26:31 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:26:31 vaio kernel: eth0: Invalid EEPROM checksum 0xff00, check settings before activating this device! Jun 29 21:26:31 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 9. Jun 29 21:26:31 vaio kernel: Board assembly ff-255, Physical connectors present: RJ45 BNC AUI MII Jun 29 21:26:31 vaio kernel: Primary interface chip unknown-15 PHY #31. Jun 29 21:26:31 vaio kernel: Secondary interface chip i82555. Jun 29 21:26:31 vaio kernel: Self test failed, status : Jun 29 21:26:31 vaio kernel: Failure to initialize the i82557. Jun 29 21:26:31 vaio kernel: Verify that the card is a bus-master capable slot.Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. rmmod'ing and insmod'ing eepro100 again fixed the problem: Jun 29 21:27:16 vaio kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Jun 29 21:27:16 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Jun 29 21:27:16 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:27:16 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 08:00:46:08:0E:5D, IRQ 9. Jun 29 21:27:16 vaio kernel: Receiver lock-up bug exists -- enabling work-around. Jun 29 21:27:16 vaio kernel: Board assembly 11-001, Physical connectors present: RJ45 Jun 29 21:27:16 vaio kernel: Primary interface chip i82555 PHY #1. Jun 29 21:27:16 vaio kernel: General self-test: passed. Jun 29 21:27:16 vaio kernel: Serial sub-system self-test: passed. Jun 29 21:27:16 vaio kernel: Internal registers self-test: passed. Jun 29 21:27:16 vaio kernel: ROM checksum self-test: passed (0x04f4518b). Jun 29 21:27:16 vaio kernel: Receiver lock-up workaround activated. Things weren't always exactly reproducible, but I found the following: - The problem doesn't seem to happen with -ac19, it starts with -ac20 - After cold reboot it doesn't seem to happen - I took eepro100.c from -ac19 and put into -ac20: Still the same problem, but everything would stay at 0xFF even after reloading - I backed out the pci changes from -ac19 to -ac20 - no change of behavior (hope I didn't screw up anything during this test) - I tried 2.4.6-pre5, same behavior as -ac20+ I have CONFIG_ACPI off, CONFIG_PM on, CONFIG_EEPRO100_PM on (when it still existed) lspci -vvxxx diff before/after loading the module the first (non-working) time: 00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Sony Corporation: Unknown device 8084 - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] Re: Linux 2.4.5-ac22
On Fri, 29 Jun 2001, Alan Cox wrote: 2.4.5-ac20 o Commence resync with 2.4.6pre5 I updated my laptop to 2.4.5-ac21 today. After reboot, I found a strange problem: My network card wouldn't initialize properly (eepro100). Jun 29 21:26:31 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin [EMAIL PROTECTED] and others Jun 29 21:26:31 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:26:31 vaio kernel: eth0: Invalid EEPROM checksum 0xff00, check settings before activating this device! Jun 29 21:26:31 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 9. Jun 29 21:26:31 vaio kernel: Board assembly ff-255, Physical connectors present: RJ45 BNC AUI MII Jun 29 21:26:31 vaio kernel: Primary interface chip unknown-15 PHY #31. Jun 29 21:26:31 vaio kernel: Secondary interface chip i82555. Jun 29 21:26:31 vaio kernel: Self test failed, status : Jun 29 21:26:31 vaio kernel: Failure to initialize the i82557. Jun 29 21:26:31 vaio kernel: Verify that the card is a bus-master capable slot.Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. Jun 29 21:26:31 vaio kernel: eth0: 0 multicast blocks dropped. rmmod'ing and insmod'ing eepro100 again fixed the problem: Jun 29 21:27:16 vaio kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Jun 29 21:27:16 vaio kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin [EMAIL PROTECTED] and others Jun 29 21:27:16 vaio kernel: PCI: Found IRQ 9 for device 00:0b.0 Jun 29 21:27:16 vaio kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 08:00:46:08:0E:5D, IRQ 9. Jun 29 21:27:16 vaio kernel: Receiver lock-up bug exists -- enabling work-around. Jun 29 21:27:16 vaio kernel: Board assembly 11-001, Physical connectors present: RJ45 Jun 29 21:27:16 vaio kernel: Primary interface chip i82555 PHY #1. Jun 29 21:27:16 vaio kernel: General self-test: passed. Jun 29 21:27:16 vaio kernel: Serial sub-system self-test: passed. Jun 29 21:27:16 vaio kernel: Internal registers self-test: passed. Jun 29 21:27:16 vaio kernel: ROM checksum self-test: passed (0x04f4518b). Jun 29 21:27:16 vaio kernel: Receiver lock-up workaround activated. Things weren't always exactly reproducible, but I found the following: - The problem doesn't seem to happen with -ac19, it starts with -ac20 - After cold reboot it doesn't seem to happen - I took eepro100.c from -ac19 and put into -ac20: Still the same problem, but everything would stay at 0xFF even after reloading - I backed out the pci changes from -ac19 to -ac20 - no change of behavior (hope I didn't screw up anything during this test) - I tried 2.4.6-pre5, same behavior as -ac20+ I have CONFIG_ACPI off, CONFIG_PM on, CONFIG_EEPRO100_PM on (when it still existed) lspci -vvxxx diff before/after loading the module the first (non-working) time: 00:0b.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Sony Corporation: Unknown device 8084 - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 9 Region 0: Memory at fecff000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at fcc0 [size=64] @@ -231,7 +232,7 @@ Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D2 PME-Enable- DSel=0 DScale=2 PME- -00: 86 80 29 12 13 00 90 02 08 00 00 02 08 42 00 00 +00: 86 80 29 12 17 00 90 02 08 00 00 02 08 42 00 00 10: 00 f0 cf fe c1 fc 00 00 00 00 d0 fe 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 4d 10 84 80 Looks like expected, and doesn't explain the problem, at least not to me. --Kai - 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: AVM A1 pcmcia, kernel 2.4.5-ac11 problem
On Tue, 12 Jun 2001, Boenisch Joerg wrote: > I hope not to be off topic! (In that case could you tell me where to ask?) You can try [EMAIL PROTECTED] or the newsgroup de.alt.comm.isdn4linux.de, but I can't guarantee success there, either. > Kernel of course is compiled with ISDN support and low-level AVM-A1-PCMCIA. > After installation in /lib/modules hisax.o can be found, but not avma1_cs.o > cardmgr[1070]: module /lib/modules/2.4.5-ac11/pcmcia/avma1_cs.o not > available The problem is obviously that you're lacking the avma1_cs.o module. I believe it was distributed separately and not included in the kernel tree / pcmcia-cs. If you want to go look for it, try linux-pcmcia on sourceforge.net, or your favorite web search engine. If you dig it up somewhere and get it working with 2.4.5, it would be nice if you let me know. We can then work together to integrate it into the kernel tree - I can't do it myself, because I don't have the card. --Kai - 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: AVM A1 pcmcia, kernel 2.4.5-ac11 problem
On Tue, 12 Jun 2001, Boenisch Joerg wrote: I hope not to be off topic! (In that case could you tell me where to ask?) You can try [EMAIL PROTECTED] or the newsgroup de.alt.comm.isdn4linux.de, but I can't guarantee success there, either. Kernel of course is compiled with ISDN support and low-level AVM-A1-PCMCIA. After installation in /lib/modules hisax.o can be found, but not avma1_cs.o cardmgr[1070]: module /lib/modules/2.4.5-ac11/pcmcia/avma1_cs.o not available The problem is obviously that you're lacking the avma1_cs.o module. I believe it was distributed separately and not included in the kernel tree / pcmcia-cs. If you want to go look for it, try linux-pcmcia on sourceforge.net, or your favorite web search engine. If you dig it up somewhere and get it working with 2.4.5, it would be nice if you let me know. We can then work together to integrate it into the kernel tree - I can't do it myself, because I don't have the card. --Kai - 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: PID of init != 1 when initrd with pivot_root
On Tue, 5 Jun 2001, W. Michael Petullo wrote: > > But the problem still remains. How do I make my /sbin/init run with PID 1 > > using initial ramdisk under the new root change mechanism? I don't want to > > use the old change_root mechanism... > > I had the same problem when doing some development for mkCDrec. > This project uses busybox, whose init does not run if its PID != 1. > I asked the busybox folks same question you did and never got a response. Maybe I'm wrong here, but I had the same problem at some point and my solution was to rename /linuxrc (to /linux, and booting with init=/linux). I believe the code which special cases /linuxrc might be in the way here. Maybe you want to try this, if it helps I think Documentation/initrd.txt needs to be updated. --Kai - 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: PID of init != 1 when initrd with pivot_root
On Tue, 5 Jun 2001, W. Michael Petullo wrote: But the problem still remains. How do I make my /sbin/init run with PID 1 using initial ramdisk under the new root change mechanism? I don't want to use the old change_root mechanism... I had the same problem when doing some development for mkCDrec. This project uses busybox, whose init does not run if its PID != 1. I asked the busybox folks same question you did and never got a response. Maybe I'm wrong here, but I had the same problem at some point and my solution was to rename /linuxrc (to /linux, and booting with init=/linux). I believe the code which special cases /linuxrc might be in the way here. Maybe you want to try this, if it helps I think Documentation/initrd.txt needs to be updated. --Kai - 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: PROBLEM: isdn connecting error(auth failed) with 2.4.4-ac9 and2.4.5
On Thu, 31 May 2001, CZUCZY Gergely wrote: > May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201... > May 27 15:00:51 kign kernel: isdn_net: ippp0 connected > May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote > number: 0651201201, Type: outgoing > May 27 15:00:51 kign ipppd[391]: PHASE_WAIT -> PHASE_ESTABLISHED, > ifunit: 0, linkunit: 0, fd: 7 > May 27 15:00:52 kign ipppd[391]: Remote message: Access Denied > May 27 15:00:52 kign ipppd[391]: PAP authentication failed > May 27 15:00:52 kign ipppd[391]: LCP terminated by peer That really looks more like an authentication problem. Is this problem reproducible, and does it vanish if you go back to 2.4.4? If the problem persists, contact me off list, and I'll try to sort it out. --Kai - 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: PROBLEM: isdn connecting error(auth failed) with 2.4.4-ac9 and2.4.5
On Thu, 31 May 2001, CZUCZY Gergely wrote: May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201... May 27 15:00:51 kign kernel: isdn_net: ippp0 connected May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote number: 0651201201, Type: outgoing May 27 15:00:51 kign ipppd[391]: PHASE_WAIT - PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7 May 27 15:00:52 kign ipppd[391]: Remote message: Access Denied May 27 15:00:52 kign ipppd[391]: PAP authentication failed May 27 15:00:52 kign ipppd[391]: LCP terminated by peer That really looks more like an authentication problem. Is this problem reproducible, and does it vanish if you go back to 2.4.4? If the problem persists, contact me off list, and I'll try to sort it out. --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make kmalloc error return unconditional in hysdn_net.c(245ac1)
On Mon, 28 May 2001, Rasmus Andersen wrote: > The patch below fixes what I believe is a bug in hysdn_net.c. > I cannot see how we can proceed under _any_ circumstances > after the kmalloc fails. Applies against 245ac1. Yep, you're obviously right. Thanks, I'll check in your patch into our CVS, and push it to Alan. Actually, maybe it makes sense to use alloc_netdev here, I'll have a look. Thanks a lot, --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make kmalloc error return unconditional in hysdn_net.c(245ac1)
On Mon, 28 May 2001, Rasmus Andersen wrote: The patch below fixes what I believe is a bug in hysdn_net.c. I cannot see how we can proceed under _any_ circumstances after the kmalloc fails. Applies against 245ac1. Yep, you're obviously right. Thanks, I'll check in your patch into our CVS, and push it to Alan. Actually, maybe it makes sense to use alloc_netdev here, I'll have a look. Thanks a lot, --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: > That being the case, we do face a question of design > philosophy, expressed as a policy question about how to design > rulesets. Actually two questions: > > 1. When we have a platform symbol for a reference design like MVME147, do >we stick to its spec sheet or consider it representative of all derivatives >(which may have other facilities)? > > I know my answer to this one, which I will implement unless there's > strong consensus otherwise. I go for explicitness. If we're going to > support MVME147 derivatives and variants in the ruleset, they get > their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the "basic" rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like "build me a kernel for the hardware I'm currently running on" (and let the user fine tune afterwards). --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the basic rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like build me a kernel for the hardware I'm currently running on (and let the user fine tune afterwards). --Kai - 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][RFC] more initcall cleanups
On Wed, 16 May 2001, Alexander Viro wrote:
> a) I2C stuff got converted to module_init() nicely. That took
> a lot of cruft away.
Definitely makes sense.
> b) init order is preserved. However, that worked only because
> none of the i2c initialization functions touch stuff from random.c
I don't think init order is preserved.
> c) I had to put i2c before char to preserve the ordering.
> Not a big deal, but I'm somewhat at loss here - how to do it without
> really ugly drivers/Makefile. Suggestions?
This part is not necessary. The ordering of subdir-y only has to do with
compilation ordering, not with link order. The link order for
drivers/char/* is set explicitly in the toplevel Makefile.
> d) if we set CONFIG_I2C to 'y' we don't include drivers/i2c
> into subdir-m. However, having i2c-core in kernel and the rest done as
> modules is OK with i2c itself. And I seriously suspect that it's
> a common situation. Am I right assuming that correct way to deal with
> that is to put i2c into mod-subdirs?
Yes, that's exactly what mod-subdirs is for.
> e) looks like rand_initialize() is in the same class as handling
> VFS/VM/etc. caches - global infrastructure. It definitely should be
> called before all other drivers. Notice that old device_init() was asking
> for trouble - it called parport_init() before chr_dev_init() (which calls
> rand_initialize()), so if somebody would try to feed some entropy into
> pool during the parport_init() we would get an interesting (and hard
> to understand) problem. Maybe we should move the call into basic_setup()?
I suppose I'm not the right one to comment on this, but it seems to make
sense to me.
> diff -urN S5-pre3-init-0/drivers/Makefile S5-pre3-init/drivers/Makefile
> --- S5-pre3-init-0/drivers/Makefile Wed May 16 16:26:35 2001
> +++ S5-pre3-init/drivers/Makefile Wed May 16 20:47:52 2001
> @@ -9,8 +9,13 @@
> mod-subdirs := dio mtd sbus video macintosh usb input telephony sgi i2o ide \
> scsi md ieee1394 pnp isdn atm fc4 net/hamradio i2c acpi
>
> -subdir-y := parport char block net sound misc media cdrom
> -subdir-m := $(subdir-y)
> +subdir-y := parport
> +subdir-m := parport
> +
> +subdir-$(CONFIG_I2C) += i2c
> +
> +subdir-y += char block net sound misc media cdrom
> +subdir-m += char block net sound misc media cdrom
>
>
> subdir-$(CONFIG_DIO) += dio
> @@ -40,7 +45,6 @@
>
> # CONFIG_HAMRADIO can be set without CONFIG_NETDEVICE being set -- ch
> subdir-$(CONFIG_HAMRADIO)+= net/hamradio
> -subdir-$(CONFIG_I2C) += i2c
> subdir-$(CONFIG_ACPI)+= acpi
>
> include $(TOPDIR)/Rules.make
As stated above, this change won't affect vmlinux at all.
> diff -urN S5-pre3-init-0/drivers/char/random.c S5-pre3-init/drivers/char/random.c
> --- S5-pre3-init-0/drivers/char/random.c Wed May 16 16:26:36 2001
> +++ S5-pre3-init/drivers/char/random.cWed May 16 20:40:12 2001
> @@ -1380,7 +1380,7 @@
> }
> }
>
> -void __init rand_initialize(void)
> +static int __init rand_initialize(void)
> {
> int i;
>
> @@ -1404,7 +1404,10 @@
> memset(_timer_state, 0, sizeof(struct timer_rand_state));
> memset(_timer_state, 0, sizeof(struct timer_rand_state));
> extract_timer_state.dont_count_entropy = 1;
> + return 0;
> }
> +
> +__initcall(rand_initialize);
>
> void rand_initialize_irq(int irq)
> {
prototype should be removed from include/linux/random.h
--Kai
-
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][RFC] more initcall cleanups
On Wed, 16 May 2001, Alexander Viro wrote:
a) I2C stuff got converted to module_init() nicely. That took
a lot of cruft away.
Definitely makes sense.
b) init order is preserved. However, that worked only because
none of the i2c initialization functions touch stuff from random.c
I don't think init order is preserved.
c) I had to put i2c before char to preserve the ordering.
Not a big deal, but I'm somewhat at loss here - how to do it without
really ugly drivers/Makefile. Suggestions?
This part is not necessary. The ordering of subdir-y only has to do with
compilation ordering, not with link order. The link order for
drivers/char/* is set explicitly in the toplevel Makefile.
d) if we set CONFIG_I2C to 'y' we don't include drivers/i2c
into subdir-m. However, having i2c-core in kernel and the rest done as
modules is OK with i2c itself. And I seriously suspect that it's
a common situation. Am I right assuming that correct way to deal with
that is to put i2c into mod-subdirs?
Yes, that's exactly what mod-subdirs is for.
e) looks like rand_initialize() is in the same class as handling
VFS/VM/etc. caches - global infrastructure. It definitely should be
called before all other drivers. Notice that old device_init() was asking
for trouble - it called parport_init() before chr_dev_init() (which calls
rand_initialize()), so if somebody would try to feed some entropy into
pool during the parport_init() we would get an interesting (and hard
to understand) problem. Maybe we should move the call into basic_setup()?
I suppose I'm not the right one to comment on this, but it seems to make
sense to me.
diff -urN S5-pre3-init-0/drivers/Makefile S5-pre3-init/drivers/Makefile
--- S5-pre3-init-0/drivers/Makefile Wed May 16 16:26:35 2001
+++ S5-pre3-init/drivers/Makefile Wed May 16 20:47:52 2001
@@ -9,8 +9,13 @@
mod-subdirs := dio mtd sbus video macintosh usb input telephony sgi i2o ide \
scsi md ieee1394 pnp isdn atm fc4 net/hamradio i2c acpi
-subdir-y := parport char block net sound misc media cdrom
-subdir-m := $(subdir-y)
+subdir-y := parport
+subdir-m := parport
+
+subdir-$(CONFIG_I2C) += i2c
+
+subdir-y += char block net sound misc media cdrom
+subdir-m += char block net sound misc media cdrom
subdir-$(CONFIG_DIO) += dio
@@ -40,7 +45,6 @@
# CONFIG_HAMRADIO can be set without CONFIG_NETDEVICE being set -- ch
subdir-$(CONFIG_HAMRADIO)+= net/hamradio
-subdir-$(CONFIG_I2C) += i2c
subdir-$(CONFIG_ACPI)+= acpi
include $(TOPDIR)/Rules.make
As stated above, this change won't affect vmlinux at all.
diff -urN S5-pre3-init-0/drivers/char/random.c S5-pre3-init/drivers/char/random.c
--- S5-pre3-init-0/drivers/char/random.c Wed May 16 16:26:36 2001
+++ S5-pre3-init/drivers/char/random.cWed May 16 20:40:12 2001
@@ -1380,7 +1380,7 @@
}
}
-void __init rand_initialize(void)
+static int __init rand_initialize(void)
{
int i;
@@ -1404,7 +1404,10 @@
memset(mouse_timer_state, 0, sizeof(struct timer_rand_state));
memset(extract_timer_state, 0, sizeof(struct timer_rand_state));
extract_timer_state.dont_count_entropy = 1;
+ return 0;
}
+
+__initcall(rand_initialize);
void rand_initialize_irq(int irq)
{
prototype should be removed from include/linux/random.h
--Kai
-
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: AVM Fritz! PCI v2.0
On Wed, 9 May 2001, Jochen Striepe wrote: > is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card > available? Using vanilla 2.2.19's HiSax driver doesn't seem to work, > and I found nothing at AVM's web page [1]. Did I miss someting? > > [1] http://www.avm.de/ You're right, the HiSax driver doesn't work with this card. Your only option is the binary-only CAPI driver, provided by AVM. You should find further information on the web page you mentioned. --Kai - 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: AVM Fritz! PCI v2.0
On Wed, 9 May 2001, Jochen Striepe wrote: is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card available? Using vanilla 2.2.19's HiSax driver doesn't seem to work, and I found nothing at AVM's web page [1]. Did I miss someting? [1] http://www.avm.de/ You're right, the HiSax driver doesn't work with this card. Your only option is the binary-only CAPI driver, provided by AVM. You should find further information on the web page you mentioned. --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001, J . A . Magallon wrote: > On 05.01 Keith Owens wrote: > > > > The patch appears to work but is it worth applying now? The existing > > 2.4 rules work fine and the entire kbuild system will be rewritten for > > 2.5, including the case you identified here. It struck me as a decent > > change but for no benefit and, given that the 2.4 kbuild system is so > > fragile, why not live with something we know works until 2.5 is > > available? Well, yes, that's an argument. However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. > We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. > 2.4 will be the stable and non "brain damaged" kernel in distros. > So every thing that can make 2.4 more clean, better. Think in 2.4.57, > and we still are in 4. And feature backports, and new drivers... > The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. Yes, 2.4 will be around for a long time from now. Of course, no experimental changes should be done now, but cleanup patches are applied all the time now. Or are you arguing that we shouldn't include patches which fix the compiler warnings either, just because it's proven that the current behavior works? Anyway, I also have the additional argument that the patches fixes at least theoretical bugs, because it adds flags handling for the link rules. I don't know if it ever happens, but one can imagine a case where foo-objs = foo1.o foo2.o, or foo-objs = foo1.o foo2.o foo3.o, respectively, depending on some config option. So if you go from the latter config to the former and rebuild, foo.o won't get relinked, you end up with the old version. Also, the patch allows you to rewrite e.g. fs/ext2/Makefile from --- obj-y:= acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \ ioctl.o namei.o super.o symlink.o obj-m:= $(O_TARGET) --- to --- obj-$(CONFIG_EXT2_FS) += ext2.o ext2-objs := acl.o balloc.o bitmap.o dir.o file.o fsync.o \ ialloc.o inode.o ioctl.o namei.o super.o symlink.o --- which fixes another fragile aspect of the current Makefiles, which you complained about yourself: make SUBDIRS=fs/ext2 is currently broken w.r.t to compilation flags. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001, J . A . Magallon wrote: On 05.01 Keith Owens wrote: The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? Well, yes, that's an argument. However, I don't think it's hard to verify that my patch works as well, it's about ten lines added to Rules.make. It's particularly easy to verify that it doesn't change behavior for objects listed in $(list-multi) at all. We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non brain damaged kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. Yes, 2.4 will be around for a long time from now. Of course, no experimental changes should be done now, but cleanup patches are applied all the time now. Or are you arguing that we shouldn't include patches which fix the compiler warnings either, just because it's proven that the current behavior works? Anyway, I also have the additional argument that the patches fixes at least theoretical bugs, because it adds flags handling for the link rules. I don't know if it ever happens, but one can imagine a case where foo-objs = foo1.o foo2.o, or foo-objs = foo1.o foo2.o foo3.o, respectively, depending on some config option. So if you go from the latter config to the former and rebuild, foo.o won't get relinked, you end up with the old version. Also, the patch allows you to rewrite e.g. fs/ext2/Makefile from --- obj-y:= acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \ ioctl.o namei.o super.o symlink.o obj-m:= $(O_TARGET) --- to --- obj-$(CONFIG_EXT2_FS) += ext2.o ext2-objs := acl.o balloc.o bitmap.o dir.o file.o fsync.o \ ialloc.o inode.o ioctl.o namei.o super.o symlink.o --- which fixes another fragile aspect of the current Makefiles, which you complained about yourself: make SUBDIRS=fs/ext2 is currently broken w.r.t to compilation flags. --Kai - 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] automatic multi-part link rules (fwd)
I sent this to the kbuild list about a week ago, and I received exactly
zero replies, so I'm posting to l-k now. This may mean that the idea is
totally stupid (but I'd like to know) or unquestionably good (that's what
I'd prefer :), well, maybe I'll get some feedback this time.
SHORT VERSION:
The attached patch allows to get rid of the "list-multi := ..." lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From: Kai Germaschewski <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [kbuild-devel] [PATCH] automatic multi-part link rules
Hi!
I'd like to get some comments on the appended patch. It removes the need
to put explicit link rules for multi-part objects in the individual
Makefiles in the subdirectores and leaves them to Rules.make instead.
I know that 2.5 kbuild will look entirely differently, but I consider this
patch useful for 2.4 as well, it's a cleanup which IMO can be applied
(after checking) to a stable kernel. (BTW: I have a lot of comments and
some code for kbuild-2.5 as well, but later).
To guarantee a smooth transition, the patch to Rules.make doesn't change
current behavior, at least with correct Makefiles. Today, a Makefile which
may build multi-part modules looks like the following:
list-multi := foo.o
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
foo.o: $(foo-objs)
$(LD) -r -o $@ $(foo-objs)
The patch ensures that for multi-part objects, which are listed in
list-multi, no automatic link rules is generated, so nothing changes
there. However, you now can remove the list-multi line and the link rule,
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
and everything will still work. Actually, there is one further advantage,
i.e. the link rule is subject to the usual flags handling now. That means
that we'll recognize when the command line changes and relink the
composite module, even if the individual parts were not touched.
There is also one minor drawback, due to make limitations: Even if only
one of the composite modules in a given directory needs to be rebuilt
(because e.g. one of its sources were touched), all the others get
relinked as well. That's not much of a problem, though, since linking is
really fast, as compared to compiling.
The patch shows the needed Rules.make adaption and demonstrates the
achievable cleanup in drivers/isdn/{,*/}Makefile. It works fine here.
--Kai
Index: linux_2_4/Rules.make
diff -u linux_2_4/Rules.make:1.1.1.4 linux_2_4/Rules.make:1.1.1.4.2.1
--- linux_2_4/Rules.make:1.1.1.4Sat Apr 28 18:17:43 2001
+++ linux_2_4/Rules.makeTue May 1 00:39:40 2001
@@ -118,6 +118,24 @@
) > $(dir $@)/.$(notdir $@).flags
endif
+#
+# Rule to link composite objects
+#
+
+# for make >= 3.78 the following is cleaner:
+# multi-used := $(foreach m,$(obj-y) $(obj-m), $(if $($(basename $(m))-objs), $(m)))
+multi-used := $(sort $(foreach m,$(obj-y) $(obj-m),$(patsubst %,$(m),$($(basename
+$(m))-objs
+ld-multi-used := $(filter-out $(list-multi),$(multi-used))
+ld-multi-objs := $(foreach m, $(ld-multi-used), $($(basename $(m))-objs))
+
+$(ld-multi-used) : %.o: $(ld-multi-objs)
+ rm -f $@
+ $(LD) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs), $^)
+ @ ( \
+ echo 'ifeq ($(strip $(subst $(comma),:,$(LD) $(EXTRA_LDFLAGS) $($(basename
+$@)-objs)),$$(strip $$(subst $$(comma),:,$$(LD) $$(EXTRA_LDFLAGS) $$($(basename
+$@)-objs)' ; \
+ echo 'FILES_FLAGS_UP_TO_DATE += $@' ; \
+ echo 'endif' \
+ ) > $(dir $@)/.$(notdir $@).flags
#
# This make dependencies quickly
@@ -198,8 +216,7 @@
#
ifdef CONFIG_MODULES
-multi-used := $(filter $(list-multi), $(obj-y) $(obj-m))
-multi-objs := $(foreach m, $(multi-used), $($(basename $(m))-objs))
+multi-objs := $(foreach m, $(obj-y) $(obj-m), $($(basename $(m))-objs))
active-objs:= $(sort $(multi-objs) $(obj-y) $(obj-m))
ifdef CONFIG_MODVERSIONS
Index: linux_2_4/drivers/isdn/Makefile
diff -u linux_2_4/drivers/isdn/Makefile:1.1.1.2
linux_2_4/drivers/isdn/Makefile:1.1.1.2.24.1
--- linux_2_4/drivers/isdn/Makefile:1.1.1.2 Tue Apr 24 00:50:53 2001
+++ linux_2_4/drivers/isdn/Makefile Tue May 1 00:39:58 2001
@@ -10,7 +10,6 @@
# Multipart objects.
-list-multi := isdn.o
isdn-objs := isdn_net.o isdn_tty.o isdn_v110.o isdn_common.o
# Optional parts of multipart objects.
@@ -49,8 +48,3 @@
# The global Rules.make.
include $(TOPDIR)/Rules.make
-
-# Link rules for multi-part drivers.
-
-isdn.o: $(isdn-objs)
- $(LD) -r -o $@ $(isdn-objs)
Index: linux_2_4/drivers/isdn/act2000/Makefile
diff -u linux_2_4/drivers/isdn/act2000/Makefile:1.1.1.1
linux_2_4/drivers/isdn/act2
[PATCH] compilation warning fixes
Newer gcc's (particularly the RH 7.0/7.1 2.96 versions) complain about implicit declaration of the function abs, and AFAICS they're right. What do people think about the appended patch to fix this? (There's more users than just isdn_audio.c, that's why I added a common header file). --Kai Index: linux_2_4/drivers/isdn/isdn_audio.c diff -u linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1.26.1 --- linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 Tue Apr 24 00:13:47 2001 +++ linux_2_4/drivers/isdn/isdn_audio.c Mon Apr 30 21:42:11 2001 @@ -25,6 +25,7 @@ #define __NO_VERSION__ #include #include +#include #include "isdn_audio.h" #include "isdn_common.h" Index: linux_2_4/include/linux/stdlib.h diff -u /dev/null linux_2_4/include/linux/stdlib.h:1.1.4.3 --- /dev/null Mon Apr 30 23:28:11 2001 +++ linux_2_4/include/linux/stdlib.hMon Apr 30 23:27:46 2001 @@ -0,0 +1,6 @@ +#ifndef __STDLIB_H__ +#define __STDLIB_H__ + +extern int abs (int i); + +#endif - 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] compilation warning fixes
Newer gcc's (particularly the RH 7.0/7.1 2.96 versions) complain about implicit declaration of the function abs, and AFAICS they're right. What do people think about the appended patch to fix this? (There's more users than just isdn_audio.c, that's why I added a common header file). --Kai Index: linux_2_4/drivers/isdn/isdn_audio.c diff -u linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1.26.1 --- linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 Tue Apr 24 00:13:47 2001 +++ linux_2_4/drivers/isdn/isdn_audio.c Mon Apr 30 21:42:11 2001 @@ -25,6 +25,7 @@ #define __NO_VERSION__ #include linux/module.h #include linux/isdn.h +#include linux/stdlib.h #include isdn_audio.h #include isdn_common.h Index: linux_2_4/include/linux/stdlib.h diff -u /dev/null linux_2_4/include/linux/stdlib.h:1.1.4.3 --- /dev/null Mon Apr 30 23:28:11 2001 +++ linux_2_4/include/linux/stdlib.hMon Apr 30 23:27:46 2001 @@ -0,0 +1,6 @@ +#ifndef __STDLIB_H__ +#define __STDLIB_H__ + +extern int abs (int i); + +#endif - 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] automatic multi-part link rules (fwd)
I sent this to the kbuild list about a week ago, and I received exactly
zero replies, so I'm posting to l-k now. This may mean that the idea is
totally stupid (but I'd like to know) or unquestionably good (that's what
I'd prefer :), well, maybe I'll get some feedback this time.
SHORT VERSION:
The attached patch allows to get rid of the list-multi := ... lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From: Kai Germaschewski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [kbuild-devel] [PATCH] automatic multi-part link rules
Hi!
I'd like to get some comments on the appended patch. It removes the need
to put explicit link rules for multi-part objects in the individual
Makefiles in the subdirectores and leaves them to Rules.make instead.
I know that 2.5 kbuild will look entirely differently, but I consider this
patch useful for 2.4 as well, it's a cleanup which IMO can be applied
(after checking) to a stable kernel. (BTW: I have a lot of comments and
some code for kbuild-2.5 as well, but later).
To guarantee a smooth transition, the patch to Rules.make doesn't change
current behavior, at least with correct Makefiles. Today, a Makefile which
may build multi-part modules looks like the following:
list-multi := foo.o
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
foo.o: $(foo-objs)
$(LD) -r -o $@ $(foo-objs)
The patch ensures that for multi-part objects, which are listed in
list-multi, no automatic link rules is generated, so nothing changes
there. However, you now can remove the list-multi line and the link rule,
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
and everything will still work. Actually, there is one further advantage,
i.e. the link rule is subject to the usual flags handling now. That means
that we'll recognize when the command line changes and relink the
composite module, even if the individual parts were not touched.
There is also one minor drawback, due to make limitations: Even if only
one of the composite modules in a given directory needs to be rebuilt
(because e.g. one of its sources were touched), all the others get
relinked as well. That's not much of a problem, though, since linking is
really fast, as compared to compiling.
The patch shows the needed Rules.make adaption and demonstrates the
achievable cleanup in drivers/isdn/{,*/}Makefile. It works fine here.
--Kai
Index: linux_2_4/Rules.make
diff -u linux_2_4/Rules.make:1.1.1.4 linux_2_4/Rules.make:1.1.1.4.2.1
--- linux_2_4/Rules.make:1.1.1.4Sat Apr 28 18:17:43 2001
+++ linux_2_4/Rules.makeTue May 1 00:39:40 2001
@@ -118,6 +118,24 @@
) $(dir $@)/.$(notdir $@).flags
endif
+#
+# Rule to link composite objects
+#
+
+# for make = 3.78 the following is cleaner:
+# multi-used := $(foreach m,$(obj-y) $(obj-m), $(if $($(basename $(m))-objs), $(m)))
+multi-used := $(sort $(foreach m,$(obj-y) $(obj-m),$(patsubst %,$(m),$($(basename
+$(m))-objs
+ld-multi-used := $(filter-out $(list-multi),$(multi-used))
+ld-multi-objs := $(foreach m, $(ld-multi-used), $($(basename $(m))-objs))
+
+$(ld-multi-used) : %.o: $(ld-multi-objs)
+ rm -f $@
+ $(LD) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs), $^)
+ @ ( \
+ echo 'ifeq ($(strip $(subst $(comma),:,$(LD) $(EXTRA_LDFLAGS) $($(basename
+$@)-objs)),$$(strip $$(subst $$(comma),:,$$(LD) $$(EXTRA_LDFLAGS) $$($(basename
+$@)-objs)' ; \
+ echo 'FILES_FLAGS_UP_TO_DATE += $@' ; \
+ echo 'endif' \
+ ) $(dir $@)/.$(notdir $@).flags
#
# This make dependencies quickly
@@ -198,8 +216,7 @@
#
ifdef CONFIG_MODULES
-multi-used := $(filter $(list-multi), $(obj-y) $(obj-m))
-multi-objs := $(foreach m, $(multi-used), $($(basename $(m))-objs))
+multi-objs := $(foreach m, $(obj-y) $(obj-m), $($(basename $(m))-objs))
active-objs:= $(sort $(multi-objs) $(obj-y) $(obj-m))
ifdef CONFIG_MODVERSIONS
Index: linux_2_4/drivers/isdn/Makefile
diff -u linux_2_4/drivers/isdn/Makefile:1.1.1.2
linux_2_4/drivers/isdn/Makefile:1.1.1.2.24.1
--- linux_2_4/drivers/isdn/Makefile:1.1.1.2 Tue Apr 24 00:50:53 2001
+++ linux_2_4/drivers/isdn/Makefile Tue May 1 00:39:58 2001
@@ -10,7 +10,6 @@
# Multipart objects.
-list-multi := isdn.o
isdn-objs := isdn_net.o isdn_tty.o isdn_v110.o isdn_common.o
# Optional parts of multipart objects.
@@ -49,8 +48,3 @@
# The global Rules.make.
include $(TOPDIR)/Rules.make
-
-# Link rules for multi-part drivers.
-
-isdn.o: $(isdn-objs)
- $(LD) -r -o $@ $(isdn-objs)
Index: linux_2_4/drivers/isdn/act2000/Makefile
diff -u linux_2_4/drivers/isdn/act2000/Makefile:1.1.1.1
linux_2_4/drivers/isdn/act2000/Makefile:1.1.1.1.28.1
--- linux_2_4
Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains
On Fri, 27 Apr 2001, David S. Miller wrote: > Kai, can you try this patch out? I think it does the right > thing. What I'm mostly interested in is if your ipchains > setup works for the resulting kernel, I've already checked > that it links properly. :-) If you get this mail, it works okay :-) (Just using a simple masquerading setup here) --Kai - 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: 2.4.4-pre7 build failure w/ IP NAT and ipchains
On Fri, 27 Apr 2001, David S. Miller wrote: >> net/network.o: In function `ip_nat_setup_info': >> net/network.o(.text+0x37b3e): undefined reference to `helpers' >> net/network.o(.text+0x37b54): undefined reference to `helpers' > > Your configuration seems impossible, somehow the config system allowed > you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting > CONFIG_IP_NF_CONNTRACK. Hmmh, actually the Config.in won't allow you to to set CONFIG_IP_NF_COMPAT_IPCHAINS if CONFIG_IP_NF_CONNTRACK=y, but I don't really understand that Config.in completely. (CONFIG_IP_NF_NAT_NEEDED is set, but AFAICS never referenced anywhere). Anyway, the appended patch fixed the problem for me, vmlinux links okay now - didn't try if it works, though. --Kai Index: net/ipv4/netfilter/ip_conntrack_core.c === RCS file: /scratch/kai/cvsroot/linux_2_4/net/ipv4/netfilter/ip_conntrack_core.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 ip_conntrack_core.c --- net/ipv4/netfilter/ip_conntrack_core.c 2001/04/24 00:20:29 1.1.1.3 +++ net/ipv4/netfilter/ip_conntrack_core.c 2001/04/26 20:49:36 @@ -46,7 +46,7 @@ void (*ip_conntrack_destroyed)(struct ip_conntrack *conntrack) = NULL; LIST_HEAD(expect_list); LIST_HEAD(protocol_list); -static LIST_HEAD(helpers); +LIST_HEAD(helpers); unsigned int ip_conntrack_htable_size = 0; static int ip_conntrack_max = 0; static atomic_t ip_conntrack_count = ATOMIC_INIT(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: 2.4.4-pre7 build failure w/ IP NAT and ipchains
On Fri, 27 Apr 2001, David S. Miller wrote: net/network.o: In function `ip_nat_setup_info': net/network.o(.text+0x37b3e): undefined reference to `helpers' net/network.o(.text+0x37b54): undefined reference to `helpers' Your configuration seems impossible, somehow the config system allowed you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting CONFIG_IP_NF_CONNTRACK. Hmmh, actually the Config.in won't allow you to to set CONFIG_IP_NF_COMPAT_IPCHAINS if CONFIG_IP_NF_CONNTRACK=y, but I don't really understand that Config.in completely. (CONFIG_IP_NF_NAT_NEEDED is set, but AFAICS never referenced anywhere). Anyway, the appended patch fixed the problem for me, vmlinux links okay now - didn't try if it works, though. --Kai Index: net/ipv4/netfilter/ip_conntrack_core.c === RCS file: /scratch/kai/cvsroot/linux_2_4/net/ipv4/netfilter/ip_conntrack_core.c,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 ip_conntrack_core.c --- net/ipv4/netfilter/ip_conntrack_core.c 2001/04/24 00:20:29 1.1.1.3 +++ net/ipv4/netfilter/ip_conntrack_core.c 2001/04/26 20:49:36 @@ -46,7 +46,7 @@ void (*ip_conntrack_destroyed)(struct ip_conntrack *conntrack) = NULL; LIST_HEAD(expect_list); LIST_HEAD(protocol_list); -static LIST_HEAD(helpers); +LIST_HEAD(helpers); unsigned int ip_conntrack_htable_size = 0; static int ip_conntrack_max = 0; static atomic_t ip_conntrack_count = ATOMIC_INIT(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: 2.4.4-pre7 build failure w/ IP NAT and ipchains
On Fri, 27 Apr 2001, David S. Miller wrote: Kai, can you try this patch out? I think it does the right thing. What I'm mostly interested in is if your ipchains setup works for the resulting kernel, I've already checked that it links properly. :-) If you get this mail, it works okay :-) (Just using a simple masquerading setup here) --Kai - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Dead symbol elimination, stage 1
On Thu, 19 Apr 2001, Eric S. Raymond wrote: > The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4 > source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo > involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol > is never set in these files. While I think your work CONFIG_ cleanup is generally a good idea and will remove a lot of cruft, I don't think the defconfigs are worth the effort (but maybe I'm missing something). First, they are only used as defaults, and any inconsistency should get cleaned up before the user even sees it. Second, removing dead entries is not all which is needed to get a defconfig which is necessarily consistent. So if you want to have these, why don't you do a cp arch/$ARCH/defconfig .config make oldconfig AFAICS, this should remove old cruft and provide a .config (to be used as defconfig) which is consistent with the current config.in's. Anyway, I put together a patch which should clean up some issues which I was reminded of because of your work in the ISDN subsystem. I appended it, I hope the maintainer of the Eicon code (Armin) will clean up the missing Configure.help entries for his drivers. --Kai diff -ur linux-2.4.4-pre4/Documentation/Configure.help linux-2.4.4-pre4.config/Documentation/Configure.help --- linux-2.4.4-pre4/Documentation/Configure.help Thu Apr 19 21:49:17 2001 +++ linux-2.4.4-pre4.config/Documentation/Configure.helpThu Apr 19 23:00:40 +2001 @@ -15430,6 +15430,16 @@ This enables HiSax support for the AMD7930 chips on some SPARCs. This code is not finished yet. +ELSA PCMCIA MicroLink cards +CONFIG_HISAX_ELSA_CS + This enables the PCMCIA client driver for the Elsa PCMCIA MicroLink + card + +Sedlbauer PCMCIA cards +CONFIG_HISAX_SEDLBAUER_CS $CONFIG_PCMCIA + This enables the PCMCIA client driver for the Sedlbauer Speed Star + and Speed Star II cards. + PCBIT-D support CONFIG_ISDN_DRV_PCBIT This enables support for the PCBIT ISDN-card. This card is @@ -15503,6 +15513,33 @@ compile it as a module, say M here and read Documentation/modules.txt. +CAPI2.0 /dev/capi20 support +CONFIG_ISDN_CAPI_CAPI20 + This option will provide the CAPI 2.0 interface to userspace + applications via /dev/capi20. Applications should use the standardized + libcapi20 to access this functionality. You should say Y/M here. + +CAPI2.0 Middleware support +CONFIG_ISDN_CAPI_MIDDLEWARE + This option will enhance the capabilities of the /dev/capi20 interface. + It will provide a means of moving a data connection, established + via the usual /dev/capi20 interface to a special tty device. If you want + to use pppd with pppdcapiplugin to dial up to your ISP, say Y here. + +CAPI2.0 filesystem support +CONFIG_ISDN_CAPI_CAPIFS_BOOL + This option provides a special file system, similar to /dev/pts with + device nodes for the special ttys established by using the middleware + extension above. If you want to use pppd with pppdcapiplugin to dial up + to your ISP, say Y here. + +CAPI2.0 capidrv interface support +CONFIG_ISDN_CAPI_CAPIDRV + This option provides the glue code to hook up CAPI driven cards to + the legacy isdn4linux link layer. If you have a card which is supported + by a CAPI driver, but still want to use old features like ippp + interfaces or ttyI emulation, say Y/M here. + AVM B1 ISA support CONFIG_ISDN_DRV_AVMB1_B1ISA Enable support for the ISA version of the AVM B1 card. @@ -15523,6 +15560,11 @@ AVM B1/M1/M2 PCMCIA support CONFIG_ISDN_DRV_AVMB1_B1PCMCIA Enable support for the PCMCIA version of the AVM B1 card. + +AVM B1/M1/M2 PCMCIA cs module +CONFIG_ISDN_DRV_AVMB1_AVM_CS + Enable the PCMCIA client driver for the AVM B1/M1/M2 + PCMCIA cards. AVM T1/T1-B PCI support CONFIG_ISDN_DRV_AVMB1_T1PCI diff -ur linux-2.4.4-pre4/drivers/isdn/Config.in linux-2.4.4-pre4.config/drivers/isdn/Config.in --- linux-2.4.4-pre4/drivers/isdn/Config.in Thu Apr 19 21:49:37 2001 +++ linux-2.4.4-pre4.config/drivers/isdn/Config.in Thu Apr 19 22:49:07 2001 @@ -110,8 +110,8 @@ tristate 'CAPI2.0 support' CONFIG_ISDN_CAPI if [ "$CONFIG_ISDN_CAPI" != "n" ]; then bool' Verbose reason code reporting (kernel size +=7K)' CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON - dep_bool' CAPI2.0 Middleware support (EXPERIMENTAL)' CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_EXPERIMENTAL dep_tristate' CAPI2.0 /dev/capi support' CONFIG_ISDN_CAPI_CAPI20 $CONFIG_ISDN_CAPI + dep_mbool ' CAPI2.0 Middleware support (EXPERIMENTAL)' +CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_ISDN_CAPI_CAPI20 $CONFIG_EXPERIMENTAL if [ "$CONFIG_ISDN_CAPI_MIDDLEWARE" = "y" ]; then dep_mbool'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS_BOOL $CONFIG_ISDN_CAPI_CAPI20 if [ "$CONFIG_ISDN_CAPI_CAPIFS_BOOL" = "y" ]; then diff -ur linux-2.4.4-pre4/drivers/isdn/avmb1/b1dma.c linux-2.4.4-pre4.config/drivers/isdn/avmb1/b1dma.c ---
Re: [kbuild-devel] Dead symbol elimination, stage 1
On Thu, 19 Apr 2001, Eric S. Raymond wrote: The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4 source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol is never set in these files. While I think your work CONFIG_ cleanup is generally a good idea and will remove a lot of cruft, I don't think the defconfigs are worth the effort (but maybe I'm missing something). First, they are only used as defaults, and any inconsistency should get cleaned up before the user even sees it. Second, removing dead entries is not all which is needed to get a defconfig which is necessarily consistent. So if you want to have these, why don't you do a cp arch/$ARCH/defconfig .config make oldconfig AFAICS, this should remove old cruft and provide a .config (to be used as defconfig) which is consistent with the current config.in's. Anyway, I put together a patch which should clean up some issues which I was reminded of because of your work in the ISDN subsystem. I appended it, I hope the maintainer of the Eicon code (Armin) will clean up the missing Configure.help entries for his drivers. --Kai diff -ur linux-2.4.4-pre4/Documentation/Configure.help linux-2.4.4-pre4.config/Documentation/Configure.help --- linux-2.4.4-pre4/Documentation/Configure.help Thu Apr 19 21:49:17 2001 +++ linux-2.4.4-pre4.config/Documentation/Configure.helpThu Apr 19 23:00:40 +2001 @@ -15430,6 +15430,16 @@ This enables HiSax support for the AMD7930 chips on some SPARCs. This code is not finished yet. +ELSA PCMCIA MicroLink cards +CONFIG_HISAX_ELSA_CS + This enables the PCMCIA client driver for the Elsa PCMCIA MicroLink + card + +Sedlbauer PCMCIA cards +CONFIG_HISAX_SEDLBAUER_CS $CONFIG_PCMCIA + This enables the PCMCIA client driver for the Sedlbauer Speed Star + and Speed Star II cards. + PCBIT-D support CONFIG_ISDN_DRV_PCBIT This enables support for the PCBIT ISDN-card. This card is @@ -15503,6 +15513,33 @@ compile it as a module, say M here and read Documentation/modules.txt. +CAPI2.0 /dev/capi20 support +CONFIG_ISDN_CAPI_CAPI20 + This option will provide the CAPI 2.0 interface to userspace + applications via /dev/capi20. Applications should use the standardized + libcapi20 to access this functionality. You should say Y/M here. + +CAPI2.0 Middleware support +CONFIG_ISDN_CAPI_MIDDLEWARE + This option will enhance the capabilities of the /dev/capi20 interface. + It will provide a means of moving a data connection, established + via the usual /dev/capi20 interface to a special tty device. If you want + to use pppd with pppdcapiplugin to dial up to your ISP, say Y here. + +CAPI2.0 filesystem support +CONFIG_ISDN_CAPI_CAPIFS_BOOL + This option provides a special file system, similar to /dev/pts with + device nodes for the special ttys established by using the middleware + extension above. If you want to use pppd with pppdcapiplugin to dial up + to your ISP, say Y here. + +CAPI2.0 capidrv interface support +CONFIG_ISDN_CAPI_CAPIDRV + This option provides the glue code to hook up CAPI driven cards to + the legacy isdn4linux link layer. If you have a card which is supported + by a CAPI driver, but still want to use old features like ippp + interfaces or ttyI emulation, say Y/M here. + AVM B1 ISA support CONFIG_ISDN_DRV_AVMB1_B1ISA Enable support for the ISA version of the AVM B1 card. @@ -15523,6 +15560,11 @@ AVM B1/M1/M2 PCMCIA support CONFIG_ISDN_DRV_AVMB1_B1PCMCIA Enable support for the PCMCIA version of the AVM B1 card. + +AVM B1/M1/M2 PCMCIA cs module +CONFIG_ISDN_DRV_AVMB1_AVM_CS + Enable the PCMCIA client driver for the AVM B1/M1/M2 + PCMCIA cards. AVM T1/T1-B PCI support CONFIG_ISDN_DRV_AVMB1_T1PCI diff -ur linux-2.4.4-pre4/drivers/isdn/Config.in linux-2.4.4-pre4.config/drivers/isdn/Config.in --- linux-2.4.4-pre4/drivers/isdn/Config.in Thu Apr 19 21:49:37 2001 +++ linux-2.4.4-pre4.config/drivers/isdn/Config.in Thu Apr 19 22:49:07 2001 @@ -110,8 +110,8 @@ tristate 'CAPI2.0 support' CONFIG_ISDN_CAPI if [ "$CONFIG_ISDN_CAPI" != "n" ]; then bool' Verbose reason code reporting (kernel size +=7K)' CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON - dep_bool' CAPI2.0 Middleware support (EXPERIMENTAL)' CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_EXPERIMENTAL dep_tristate' CAPI2.0 /dev/capi support' CONFIG_ISDN_CAPI_CAPI20 $CONFIG_ISDN_CAPI + dep_mbool ' CAPI2.0 Middleware support (EXPERIMENTAL)' +CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_ISDN_CAPI_CAPI20 $CONFIG_EXPERIMENTAL if [ "$CONFIG_ISDN_CAPI_MIDDLEWARE" = "y" ]; then dep_mbool'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS_BOOL $CONFIG_ISDN_CAPI_CAPI20 if [ "$CONFIG_ISDN_CAPI_CAPIFS_BOOL" = "y" ]; then diff -ur linux-2.4.4-pre4/drivers/isdn/avmb1/b1dma.c linux-2.4.4-pre4.config/drivers/isdn/avmb1/b1dma.c ---
Re: [ISDN-ERR]
On Fri, 30 Mar 2001, hugang wrote: > Hello all: > > --- > OPEN: 10.0.0.2 -> 202.99.16.1 UDP, port: 1024 -> 53 > ippp0: dialing 1 86310163... > isdn: HiSax,ch0 cause: E001B <--- error !! > isdn_net: local hangup ippp0 > ippp0: Chargesum is 0 > --- E001B is an ISDN cause (see "man isdn_cause") it means Location: (00) local Cause:(1B) Destination out of order which most likely indicates a cabling problem on your ISDN line. If you need further assistance, contact me privately or ask on [EMAIL PROTECTED], people on l-k don't really care. --Kai - 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: [ISDN-ERR]
On Fri, 30 Mar 2001, hugang wrote: Hello all: --- OPEN: 10.0.0.2 - 202.99.16.1 UDP, port: 1024 - 53 ippp0: dialing 1 86310163... isdn: HiSax,ch0 cause: E001B --- error !! isdn_net: local hangup ippp0 ippp0: Chargesum is 0 --- E001B is an ISDN cause (see "man isdn_cause") it means Location: (00) local Cause:(1B) Destination out of order which most likely indicates a cabling problem on your ISDN line. If you need further assistance, contact me privately or ask on [EMAIL PROTECTED], people on l-k don't really care. --Kai - 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: strange problem with /dev/isdninfo
On Wed, 21 Mar 2001, Joern Heissler wrote:
> I've got a strange problem with /dev/isdninfo:
>
> joern:~# cat /dev/isdninfo
> idmap: Hisax...
> chmap: 0 1 ...
>
> --> cat /dev/isdninfo works :-)
>
> Here's the problem:
>
> open("/dev/isdninfo", O_RDONLY) = 3
> read(3, "", 200) = 0
>
> Could someone please tell me what's wrong? I (and some other people) do not
>understand this.
Well, /dev/isdninfo will only return the info to you if it entirely fits
into the supplied buffer. So, you should try a read with 2048 bytes or so,
and it'll work just fine.
Not that I think that the current behavior is particularly smart, but
that's how things are.
--Kai
-
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: strange problem with /dev/isdninfo
On Wed, 21 Mar 2001, Joern Heissler wrote:
I've got a strange problem with /dev/isdninfo:
joern:~# cat /dev/isdninfo
idmap: Hisax...
chmap: 0 1 ...
-- cat /dev/isdninfo works :-)
Here's the problem:
open("/dev/isdninfo", O_RDONLY) = 3
read(3, "", 200) = 0
Could someone please tell me what's wrong? I (and some other people) do not
understand this.
Well, /dev/isdninfo will only return the info to you if it entirely fits
into the supplied buffer. So, you should try a read with 2048 bytes or so,
and it'll work just fine.
Not that I think that the current behavior is particularly smart, but
that's how things are.
--Kai
-
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: [CHECKER] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
> I'm planning on poking through everything which has been
> identified as a posible problem. But I won't start for
> several weeks - give the maintainers (if any) time to
> address these things.
I took a look at the ISDN issues, here's a patch which should fix most of
it (sleeping in IRQ, and unchecked user access still missing).
I'ld appreciate it if somebody felt like looking through it. The patch is
against current CVS, but applies against current 2.4.3-pre.
--Kai
diff -ur isdn-HEAD/drivers/isdn/avmb1/capi.c isdn-h/drivers/isdn/avmb1/capi.c
--- isdn-HEAD/drivers/isdn/avmb1/capi.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/avmb1/capi.cSat Mar 17 18:21:23 2001
@@ -1082,6 +1082,8 @@
return -ENODEV;
skb = alloc_skb(count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
kfree_skb(skb);
@@ -1501,6 +1503,8 @@
return -EINVAL;
skb = alloc_skb(CAPI_DATA_B3_REQ_LEN+count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
skb_reserve(skb, CAPI_DATA_B3_REQ_LEN);
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
Only in isdn-h/drivers/isdn/avmb1: capi.c%
diff -ur isdn-HEAD/drivers/isdn/avmb1/capidrv.c isdn-h/drivers/isdn/avmb1/capidrv.c
--- isdn-HEAD/drivers/isdn/avmb1/capidrv.c Thu Mar 15 17:05:56 2001
+++ isdn-h/drivers/isdn/avmb1/capidrv.c Sat Mar 17 18:23:33 2001
@@ -2065,8 +2065,8 @@
__u16 datahandle;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_sendbuf called with invalid driverId
%d!\n",
- card->contrnr, id);
+ printk(KERN_ERR "capidrv: if_sendbuf called with invalid driverId
+%d!\n",
+ id);
return 0;
}
if (debugmode > 1)
@@ -2137,8 +2137,8 @@
__u8 *p;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_readstat called with invalid driverId
%d!\n",
- card->contrnr, id);
+ printk(KERN_ERR "capidrv: if_readstat called with invalid driverId
+%d!\n",
+ id);
return -ENODEV;
}
Only in isdn-h/drivers/isdn/avmb1: capidrv.c%
diff -ur isdn-HEAD/drivers/isdn/hisax/config.c isdn-h/drivers/isdn/hisax/config.c
--- isdn-HEAD/drivers/isdn/hisax/config.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/hisax/config.c Sat Mar 17 18:07:41 2001
@@ -925,13 +925,12 @@
save_flags(flags);
cli();
- if (!(cs = (struct IsdnCardState *)
- kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC))) {
+ cs = kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC)
+ if (!cs) {
printk(KERN_WARNING
"HiSax: No memory for IsdnCardState(card %d)\n",
cardnr + 1);
- restore_flags(flags);
- return (0);
+ goto out;
}
memset(cs, 0, sizeof(struct IsdnCardState));
card->cs = cs;
@@ -950,241 +949,235 @@
#endif
cs->protocol = card->protocol;
- if ((card->typ > 0) && (card->typ <= ISDN_CTYPE_COUNT)) {
- if (!(cs->dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for dlog(card %d)\n",
- cardnr + 1);
- restore_flags(flags);
- return (0);
- }
- if (!(cs->status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for status_buf(card %d)\n",
- cardnr + 1);
- kfree(cs->dlog);
- restore_flags(flags);
- return (0);
- }
- cs->stlist = NULL;
- cs->status_read = cs->status_buf;
- cs->status_write = cs->status_buf;
- cs->status_end = cs->status_buf + HISAX_STATUS_BUFSIZE - 1;
- cs->typ = card->typ;
- strcpy(cs->iif.id, id);
- cs->iif.channels = 2;
- cs->iif.maxbufsize = MAX_DATA_SIZE;
- cs->iif.hl_hdrlen = MAX_HEADER_LEN;
- cs->iif.features =
- ISDN_FEATURE_L2_X75I |
- ISDN_FEATURE_L2_HDLC |
- ISDN_FEATURE_L2_HDLC_56K |
- ISDN_FEATURE_L2_TRANS |
- ISDN_FEATURE_L3_TRANS |
+ if (card->typ <= 0 || card->typ > ISDN_CTYPE_COUNT) {
+ printk(KERN_WARNING
+ "HiSax: Card Type %d out of range\n",
+ card->typ);
+ goto outf_cs;
+ }
+ if (!(cs->dlog =
Re: [CHECKER] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
I took a look at the ISDN issues, here's a patch which should fix most of
it (sleeping in IRQ, and unchecked user access still missing).
I'ld appreciate it if somebody felt like looking through it. The patch is
against current CVS, but applies against current 2.4.3-pre.
--Kai
diff -ur isdn-HEAD/drivers/isdn/avmb1/capi.c isdn-h/drivers/isdn/avmb1/capi.c
--- isdn-HEAD/drivers/isdn/avmb1/capi.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/avmb1/capi.cSat Mar 17 18:21:23 2001
@@ -1082,6 +1082,8 @@
return -ENODEV;
skb = alloc_skb(count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
kfree_skb(skb);
@@ -1501,6 +1503,8 @@
return -EINVAL;
skb = alloc_skb(CAPI_DATA_B3_REQ_LEN+count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
skb_reserve(skb, CAPI_DATA_B3_REQ_LEN);
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
Only in isdn-h/drivers/isdn/avmb1: capi.c%
diff -ur isdn-HEAD/drivers/isdn/avmb1/capidrv.c isdn-h/drivers/isdn/avmb1/capidrv.c
--- isdn-HEAD/drivers/isdn/avmb1/capidrv.c Thu Mar 15 17:05:56 2001
+++ isdn-h/drivers/isdn/avmb1/capidrv.c Sat Mar 17 18:23:33 2001
@@ -2065,8 +2065,8 @@
__u16 datahandle;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_sendbuf called with invalid driverId
%d!\n",
- card-contrnr, id);
+ printk(KERN_ERR "capidrv: if_sendbuf called with invalid driverId
+%d!\n",
+ id);
return 0;
}
if (debugmode 1)
@@ -2137,8 +2137,8 @@
__u8 *p;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_readstat called with invalid driverId
%d!\n",
- card-contrnr, id);
+ printk(KERN_ERR "capidrv: if_readstat called with invalid driverId
+%d!\n",
+ id);
return -ENODEV;
}
Only in isdn-h/drivers/isdn/avmb1: capidrv.c%
diff -ur isdn-HEAD/drivers/isdn/hisax/config.c isdn-h/drivers/isdn/hisax/config.c
--- isdn-HEAD/drivers/isdn/hisax/config.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/hisax/config.c Sat Mar 17 18:07:41 2001
@@ -925,13 +925,12 @@
save_flags(flags);
cli();
- if (!(cs = (struct IsdnCardState *)
- kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC))) {
+ cs = kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC)
+ if (!cs) {
printk(KERN_WARNING
"HiSax: No memory for IsdnCardState(card %d)\n",
cardnr + 1);
- restore_flags(flags);
- return (0);
+ goto out;
}
memset(cs, 0, sizeof(struct IsdnCardState));
card-cs = cs;
@@ -950,241 +949,235 @@
#endif
cs-protocol = card-protocol;
- if ((card-typ 0) (card-typ = ISDN_CTYPE_COUNT)) {
- if (!(cs-dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for dlog(card %d)\n",
- cardnr + 1);
- restore_flags(flags);
- return (0);
- }
- if (!(cs-status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for status_buf(card %d)\n",
- cardnr + 1);
- kfree(cs-dlog);
- restore_flags(flags);
- return (0);
- }
- cs-stlist = NULL;
- cs-status_read = cs-status_buf;
- cs-status_write = cs-status_buf;
- cs-status_end = cs-status_buf + HISAX_STATUS_BUFSIZE - 1;
- cs-typ = card-typ;
- strcpy(cs-iif.id, id);
- cs-iif.channels = 2;
- cs-iif.maxbufsize = MAX_DATA_SIZE;
- cs-iif.hl_hdrlen = MAX_HEADER_LEN;
- cs-iif.features =
- ISDN_FEATURE_L2_X75I |
- ISDN_FEATURE_L2_HDLC |
- ISDN_FEATURE_L2_HDLC_56K |
- ISDN_FEATURE_L2_TRANS |
- ISDN_FEATURE_L3_TRANS |
+ if (card-typ = 0 || card-typ ISDN_CTYPE_COUNT) {
+ printk(KERN_WARNING
+ "HiSax: Card Type %d out of range\n",
+ card-typ);
+ goto outf_cs;
+ }
+ if (!(cs-dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
+
[PATCH] Makefile fixes
Could people (particularly the affected maintainers) please look over the appended patch, which I'm planning to submit to Linus at an appropriate time. It contains a couple of small Makefile fixes, particularly o $(list-multi) is supposed to list composite modules, i.e. modules which are made out of multiple source files. Make sure that $(list-multi) is only defined where applicable, and that it really lists all composite objects. Some Makefiles forget this or use e.g. $(multi-objs) which is wrong. The variable $(list-multi) is used in Rules.make, currently only for dependencies, that's why most people haven't seen any problems yet. o For all foo.o listed in $(list-multi) there needs to be a $(foo-objs) which lists the actual parts of the composite module. Currently, there also needs to be a link rule for each of the composite objects, which looks like foo.o: $(foo-objs) $(LD) -r -o $@ $(foo-objs) The patch corrects places where this was done incorrectly. o some cleanup The reason behind this is that I'm planning to remove the need for the list-multi and the link rule, and this needs to be done in preparation. (But it's needed for correctness anyway). Patch is against 2.4.2-pre3 but still applies cleanly against 2.4.2-final. --Kai diff -ur linux-2.4.2-pre3/drivers/atm/Makefile linux-2.4.2-pre3.makefixes/drivers/atm/Makefile --- linux-2.4.2-pre3/drivers/atm/Makefile Sun Jan 21 01:27:44 2001 +++ linux-2.4.2-pre3.makefixes/drivers/atm/Makefile Fri Feb 16 22:02:02 2001 @@ -50,6 +50,9 @@ EXTRA_CFLAGS=-g +list-multi := fore_200e +fore_200e-objs := fore200e.o $(FORE200E_FW_OBJS) + include $(TOPDIR)/Rules.make @@ -82,9 +85,8 @@ objcopy -Iihex $< -Obinary $@.gz gzip -df $@.gz -# module build -fore_200e.o: fore200e.o $(FORE200E_FW_OBJS) - $(LD) -r -o $@ $< $(FORE200E_FW_OBJS) +fore_200e.o: $(fore_200e-objs) + $(LD) -r -o $@ $(fore_200e-objs) # firmware dependency stuff taken from drivers/sound/Makefile FORE200E_FW_UP_TO_DATE := diff -ur linux-2.4.2-pre3/drivers/char/Makefile linux-2.4.2-pre3.makefixes/drivers/char/Makefile --- linux-2.4.2-pre3/drivers/char/Makefile Thu Jan 4 22:00:55 2001 +++ linux-2.4.2-pre3.makefixes/drivers/char/MakefileFri Feb 16 21:54:28 2001 @@ -27,8 +27,6 @@ mod-subdirs:= joystick ftape drm pcmcia -list-multi := - KEYMAP =defkeymap.o KEYBD=pc_keyb.o CONSOLE =console.o diff -ur linux-2.4.2-pre3/drivers/char/agp/Makefile linux-2.4.2-pre3.makefixes/drivers/char/agp/Makefile --- linux-2.4.2-pre3/drivers/char/agp/Makefile Fri Dec 29 23:07:21 2000 +++ linux-2.4.2-pre3.makefixes/drivers/char/agp/MakefileFri Feb 16 21:54:28 +2001 @@ -7,7 +7,7 @@ export-objs := agpgart_be.o -multi-objs := agpgart.o +list-multi := agpgart.o agpgart-objs := agpgart_fe.o agpgart_be.o obj-$(CONFIG_AGP) += agpgart.o diff -ur linux-2.4.2-pre3/drivers/char/drm/Makefile linux-2.4.2-pre3.makefixes/drivers/char/drm/Makefile --- linux-2.4.2-pre3/drivers/char/drm/Makefile Fri Feb 16 21:51:13 2001 +++ linux-2.4.2-pre3.makefixes/drivers/char/drm/MakefileFri Feb 16 21:56:32 +2001 @@ -3,12 +3,10 @@ # the Direct Rendering Infrastructure (DRI) in XFree86 4.x. # -# drm.o is a fake target -- it is never built -# The real targets are in the module-list O_TARGET := drm.o -module-list := gamma.o tdfx.o r128.o ffb.o mga.o i810.o -export-objs := $(patsubst %.o,%_drv.o,$(module-list)) +export-objs := gamma_drv.o tdfx_drv.o r128_drv.o ffb_drv.o mga_drv.o \ + i810_drv.o # lib-objs are included in every module so that radical changes to the # architecture of the DRM support library can be made at a later time. @@ -42,6 +40,7 @@ endif endif +list-multi := gamma.o tdfx.o r128.o ffb.o mga.o i810.o gamma-objs := gamma_drv.o gamma_dma.o tdfx-objs := tdfx_drv.o tdfx_context.o r128-objs := r128_drv.o r128_cce.or128_context.o r128_bufs.o r128_state.o diff -ur linux-2.4.2-pre3/drivers/fc4/Makefile linux-2.4.2-pre3.makefixes/drivers/fc4/Makefile --- linux-2.4.2-pre3/drivers/fc4/Makefile Fri Dec 29 23:07:21 2000 +++ linux-2.4.2-pre3.makefixes/drivers/fc4/Makefile Fri Feb 16 21:54:28 2001 @@ -14,7 +14,7 @@ obj-$(CONFIG_FC4_SOC) += soc.o obj-$(CONFIG_FC4_SOCAL) += socal.o +include $(TOPDIR)/Rules.make + fc4.o: $(fc4-objs) $(LD) -r -o $@ $(fc4-objs) - -include $(TOPDIR)/Rules.make diff -ur linux-2.4.2-pre3/drivers/media/radio/Makefile linux-2.4.2-pre3.makefixes/drivers/media/radio/Makefile --- linux-2.4.2-pre3/drivers/media/radio/Makefile Fri Dec 29 23:07:22 2000 +++ linux-2.4.2-pre3.makefixes/drivers/media/radio/Makefile Fri Feb 16 21:54:28 +2001 @@ -9,21 +9,12 @@ # parent makes.. # -# Object file lists. - -obj-y := -obj-m := -obj-n := -obj- := - O_TARGET := radio.o # All of the (potential) objects that
[PATCH] Makefile fixes
Could people (particularly the affected maintainers) please look over the appended patch, which I'm planning to submit to Linus at an appropriate time. It contains a couple of small Makefile fixes, particularly o $(list-multi) is supposed to list composite modules, i.e. modules which are made out of multiple source files. Make sure that $(list-multi) is only defined where applicable, and that it really lists all composite objects. Some Makefiles forget this or use e.g. $(multi-objs) which is wrong. The variable $(list-multi) is used in Rules.make, currently only for dependencies, that's why most people haven't seen any problems yet. o For all foo.o listed in $(list-multi) there needs to be a $(foo-objs) which lists the actual parts of the composite module. Currently, there also needs to be a link rule for each of the composite objects, which looks like foo.o: $(foo-objs) $(LD) -r -o $@ $(foo-objs) The patch corrects places where this was done incorrectly. o some cleanup The reason behind this is that I'm planning to remove the need for the list-multi and the link rule, and this needs to be done in preparation. (But it's needed for correctness anyway). Patch is against 2.4.2-pre3 but still applies cleanly against 2.4.2-final. --Kai diff -ur linux-2.4.2-pre3/drivers/atm/Makefile linux-2.4.2-pre3.makefixes/drivers/atm/Makefile --- linux-2.4.2-pre3/drivers/atm/Makefile Sun Jan 21 01:27:44 2001 +++ linux-2.4.2-pre3.makefixes/drivers/atm/Makefile Fri Feb 16 22:02:02 2001 @@ -50,6 +50,9 @@ EXTRA_CFLAGS=-g +list-multi := fore_200e +fore_200e-objs := fore200e.o $(FORE200E_FW_OBJS) + include $(TOPDIR)/Rules.make @@ -82,9 +85,8 @@ objcopy -Iihex $ -Obinary $@.gz gzip -df $@.gz -# module build -fore_200e.o: fore200e.o $(FORE200E_FW_OBJS) - $(LD) -r -o $@ $ $(FORE200E_FW_OBJS) +fore_200e.o: $(fore_200e-objs) + $(LD) -r -o $@ $(fore_200e-objs) # firmware dependency stuff taken from drivers/sound/Makefile FORE200E_FW_UP_TO_DATE := diff -ur linux-2.4.2-pre3/drivers/char/Makefile linux-2.4.2-pre3.makefixes/drivers/char/Makefile --- linux-2.4.2-pre3/drivers/char/Makefile Thu Jan 4 22:00:55 2001 +++ linux-2.4.2-pre3.makefixes/drivers/char/MakefileFri Feb 16 21:54:28 2001 @@ -27,8 +27,6 @@ mod-subdirs:= joystick ftape drm pcmcia -list-multi := - KEYMAP =defkeymap.o KEYBD=pc_keyb.o CONSOLE =console.o diff -ur linux-2.4.2-pre3/drivers/char/agp/Makefile linux-2.4.2-pre3.makefixes/drivers/char/agp/Makefile --- linux-2.4.2-pre3/drivers/char/agp/Makefile Fri Dec 29 23:07:21 2000 +++ linux-2.4.2-pre3.makefixes/drivers/char/agp/MakefileFri Feb 16 21:54:28 +2001 @@ -7,7 +7,7 @@ export-objs := agpgart_be.o -multi-objs := agpgart.o +list-multi := agpgart.o agpgart-objs := agpgart_fe.o agpgart_be.o obj-$(CONFIG_AGP) += agpgart.o diff -ur linux-2.4.2-pre3/drivers/char/drm/Makefile linux-2.4.2-pre3.makefixes/drivers/char/drm/Makefile --- linux-2.4.2-pre3/drivers/char/drm/Makefile Fri Feb 16 21:51:13 2001 +++ linux-2.4.2-pre3.makefixes/drivers/char/drm/MakefileFri Feb 16 21:56:32 +2001 @@ -3,12 +3,10 @@ # the Direct Rendering Infrastructure (DRI) in XFree86 4.x. # -# drm.o is a fake target -- it is never built -# The real targets are in the module-list O_TARGET := drm.o -module-list := gamma.o tdfx.o r128.o ffb.o mga.o i810.o -export-objs := $(patsubst %.o,%_drv.o,$(module-list)) +export-objs := gamma_drv.o tdfx_drv.o r128_drv.o ffb_drv.o mga_drv.o \ + i810_drv.o # lib-objs are included in every module so that radical changes to the # architecture of the DRM support library can be made at a later time. @@ -42,6 +40,7 @@ endif endif +list-multi := gamma.o tdfx.o r128.o ffb.o mga.o i810.o gamma-objs := gamma_drv.o gamma_dma.o tdfx-objs := tdfx_drv.o tdfx_context.o r128-objs := r128_drv.o r128_cce.or128_context.o r128_bufs.o r128_state.o diff -ur linux-2.4.2-pre3/drivers/fc4/Makefile linux-2.4.2-pre3.makefixes/drivers/fc4/Makefile --- linux-2.4.2-pre3/drivers/fc4/Makefile Fri Dec 29 23:07:21 2000 +++ linux-2.4.2-pre3.makefixes/drivers/fc4/Makefile Fri Feb 16 21:54:28 2001 @@ -14,7 +14,7 @@ obj-$(CONFIG_FC4_SOC) += soc.o obj-$(CONFIG_FC4_SOCAL) += socal.o +include $(TOPDIR)/Rules.make + fc4.o: $(fc4-objs) $(LD) -r -o $@ $(fc4-objs) - -include $(TOPDIR)/Rules.make diff -ur linux-2.4.2-pre3/drivers/media/radio/Makefile linux-2.4.2-pre3.makefixes/drivers/media/radio/Makefile --- linux-2.4.2-pre3/drivers/media/radio/Makefile Fri Dec 29 23:07:22 2000 +++ linux-2.4.2-pre3.makefixes/drivers/media/radio/Makefile Fri Feb 16 21:54:28 +2001 @@ -9,21 +9,12 @@ # parent makes.. # -# Object file lists. - -obj-y := -obj-m := -obj-n := -obj- := - O_TARGET := radio.o # All of the (potential) objects that
Re: 2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o'
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
> SMP machine, 2x P3/700 on an Abit VP6.
> Never any trouble with the earlier 2.2.19pre's.
>
> a strace shows the hang to be in the delete_module("hisax") call.
I got another report of the same problem already. I'll try to sort it out
tomorrow.
What does "ps axwll" say for the rmmod process?
--Kai
-
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: 2.2.19pre10 locks up hard on unloading the isdn module 'hisax.o'
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
SMP machine, 2x P3/700 on an Abit VP6.
Never any trouble with the earlier 2.2.19pre's.
a strace shows the hang to be in the delete_module("hisax") call.
I got another report of the same problem already. I'll try to sort it out
tomorrow.
What does "ps axwll" say for the rmmod process?
--Kai
-
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: OOPS with 2.4.1-ac8
On Sun, 11 Feb 2001, Kurt Roeckx wrote: > I suddenly started to get those oopses. It didn't seem to cause > any problems tho. > Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80] > [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84] > [sys_newstat+21/108] > [system_call+51/64] This looks similar to an Oops posted by BaRT a couple of days ago. Out of curiosity, are you using ISDN, too? The oops doesn't seem to be related to the ISDN code AFAICS, but on the other hand you never know ;) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS with 2.4.1-ac8
On Sun, 11 Feb 2001, Kurt Roeckx wrote: I suddenly started to get those oopses. It didn't seem to cause any problems tho. Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80] [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84] [sys_newstat+21/108] [system_call+51/64] This looks similar to an Oops posted by BaRT a couple of days ago. Out of curiosity, are you using ISDN, too? The oops doesn't seem to be related to the ISDN code AFAICS, but on the other hand you never know ;) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 Kernel Crash
On Wed, 7 Feb 2001, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > On one of my linux boxen, that is used as an ISDN router after a 3 > > days of up time I get this: > > Read http://www.tux.org/lkml/#s4-3 > > Particularly the "Don't even bother..." part. The Call Trace was decoded by klogd, running it through ksymoops won't really work. AFAICS the trace makes sense. Since I can't think of any relation to the ISDN stack, I asked BaRT to post the trace to l-k, and I think it actually provides useful information. So I'ld hope somebody takes a look into this. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] micro-opt DEBUG_ADD_PAGE
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> No. The optimization is entirely legal - but the fact that
> "constant_test_bit()" uses a "volatile unsigned int *" is the reason why
> gcc thinks it can't optimize it.
This thing did attract me somewhat and I decided to learn a little about
compilers.
Result: Unfortunately it's not just the volatile, there's a bunch of
conditions you have to fulfill to have the compiler optimize this. (Sounds
like work for the compiler guys).
Test program is attached, inspecting the code (egcs 2.91.66 and
gcc-2.96 (-69) generate the same code gives the following conclusions:
- f1(unsigned long f): manually optimized
if (f & ((1 << 1) | (1 << 2) | (1 << 4))) {
-> optimized code (of course)
- f2(unsigned long f): leave some work to the compiler
if ((f & (1 << 1)) || (f & (1 << 2)) || (f & (1 << 4))) {
-> optimized code (good)
- f3(unsigned int f): use constant_test_bit macro
if (constant_test_bit(1, ) || constant_test_bit(2, ) ||
constant_test_bit(4, )) {
-> optimized code
where
#define constant_test_bit(nr, addr) \
(((1UL << (nr & 31)) & ((unsigned int*)(addr))[nr >> 5]) != 0)
(doesn't optimize when putting *const* unsigned int there)
- f4: same thing as f3, but use (unsigned long f) instead of
(unsigned int f)
-> no optimization
- f5: same thing as f3, but use inline function for constant_test_bit
-> no optimization
- f6: same thing as f3, but use test_bit instead of constant_test_bit,
where
#define test_bit(nr,addr) \
(__builtin_constant_p(nr) ? \
constant_test_bit((nr),(addr)) : \
variable_test_bit((nr),(addr)))
-> no optimization
Conclusion: With the compilers tested, lots of cases are not optimized
although the could be in theory:
- casting even from unsigned int to unsigned long breaks optimization
- macros are better than inline
- Even though evaluated at compile time, __builtin_constant_p breaks
optimization here, too.
BTW: volatile makes optimization impossible as well, of course, it leads
to repeated reloads of the variable, whereas otherwise it's cached in a
register in the above "no optimization" cases. That's expected behavior.
--Kai
Test code:
--
#define ADDR (*(volatile long *) addr)
static __inline__ int inl_constant_test_bit(int nr, const void * addr)
{
return ((1UL << (nr & 31)) & (((unsigned int *) addr)[nr >> 5])) != 0;
}
#define constant_test_bit(nr, addr) (((1UL << (nr & 31)) & ((unsigned int*)(addr))[nr
>> 5]) != 0)
static __inline__ int variable_test_bit(int nr, volatile void * addr)
{
int oldbit;
__asm__ __volatile__(
"btl %2,%1\n\tsbbl %0,%0"
:"=r" (oldbit)
:"m" (ADDR),"Ir" (nr));
return oldbit;
}
#define test_bit(nr,addr) \
(__builtin_constant_p(nr) ? \
constant_test_bit((nr),(addr)) : \
variable_test_bit((nr),(addr)))
int f1(unsigned long f)
{
if (f & ((1 << 1) | (1 << 2) | (1 << 4))) {
return 1;
}
return 0;
}
int f2(unsigned long f)
{
if ((f & (1 << 1)) || (f & (1 << 2)) || (f & (1 << 4))) {
return 1;
}
return 0;
}
int f3(unsigned int f)
{
if (constant_test_bit(1, ) || constant_test_bit(2, ) || constant_test_bit(4,
)) {
return 1;
}
return 0;
}
int f4(unsigned long f)
{
if (constant_test_bit(1, ) || constant_test_bit(2, ) || constant_test_bit(4,
)) {
return 1;
}
return 0;
}
int f5(unsigned int f)
{
if (inl_constant_test_bit(1, ) || inl_constant_test_bit(2, ) ||
inl_constant_test_bit(4, )) {
return 1;
}
return 0;
}
int f6(unsigned int f)
{
if (test_bit(1, ) || test_bit(2, ) || test_bit(4, )) {
return 1;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 Kernel Crash
On Wed, 7 Feb 2001, David Woodhouse wrote: [EMAIL PROTECTED] said: On one of my linux boxen, that is used as an ISDN router after a 3 days of up time I get this: Read http://www.tux.org/lkml/#s4-3 Particularly the "Don't even bother..." part. The Call Trace was decoded by klogd, running it through ksymoops won't really work. AFAICS the trace makes sense. Since I can't think of any relation to the ISDN stack, I asked BaRT to post the trace to l-k, and I think it actually provides useful information. So I'ld hope somebody takes a look into this. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression > oops on2.4.x)
On Fri, 2 Feb 2001, infernix wrote: > However, the patch hasn't been implemented yet, neither in 2.4.1 or in > 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :) > Could someone see to it that this mail reaches the kernel's isdn_ppp.c > maintainer and get this thing moving? Thanks. Look again. The patch you quoted is in patch-2.4.1.bz2. Don't know about 2.4.1-ac1. (But I doubt it's reverted there :) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: isdn_ppp.c bug (isdn_lzscomp.c aka STAC compression oops on2.4.x)
On Fri, 2 Feb 2001, infernix wrote: However, the patch hasn't been implemented yet, neither in 2.4.1 or in 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :) Could someone see to it that this mail reaches the kernel's isdn_ppp.c maintainer and get this thing moving? Thanks. Look again. The patch you quoted is in patch-2.4.1.bz2. Don't know about 2.4.1-ac1. (But I doubt it's reverted there :) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ipppd == pppd?
On 18 Jan 2001, Kai Henningsen wrote: > > This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the > > generic PPP layer yet. > > So, is this still planned? Any sort of timeline? Yes, however, it's always planned to dump the old ISDN link layer at some point and switch over to a CAPI based system. There's not really a timeline yet. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ipppd == pppd?
On 18 Jan 2001, Kai Henningsen wrote: This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the generic PPP layer yet. So, is this still planned? Any sort of timeline? Yes, however, it's always planned to dump the old ISDN link layer at some point and switch over to a CAPI based system. There's not really a timeline yet. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in modutils or drivers/isdn/hisax/
On Tue, 23 Jan 2001, Ingo Oeser wrote:
> To quote drivers/isdn/hisax/config.c:1710-1713
> static struct pci_device_id hisax_pci_tbl[] __initdata = {
> #ifdef CONFIG_HISAX_FRTIZPCI
> {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
>PCI_ANY_ID},
> #endif
>
> To quote my .config:
> CONFIG_ISDN_DRV_HISAX=m
> CONFIG_HISAX_FRITZPCI=y
>
> So the bug is indeed in the driver and is a speling mistake
> Patch is:
>
> --- linux/drivers/isdn/hisax/config.c.origFri Dec 29 23:07:22 2000
> +++ linux/drivers/isdn/hisax/config.c Tue Jan 23 15:07:54 2001
> @@ -1708,8 +1708,8 @@
> }
>
> static struct pci_device_id hisax_pci_tbl[] __initdata = {
> -#ifdef CONFIG_HISAX_FRTIZPCI
> - {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ,PCI_ANY_ID,
>PCI_ANY_ID},
> +#ifdef CONFIG_HISAX_FRITZPCI
> + {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
>PCI_ANY_ID},
> #endif
> #ifdef CONFIG_HISAX_DIEHLDIVA
> {PCI_VENDOR_ID_EICON,PCI_DEVICE_ID_EICON_DIVA20, PCI_ANY_ID,
>PCI_ANY_ID},
>
Close, but not quite. (Try compiling after your patch :)
Correct patch:
--- linux-2.4.0/drivers/isdn/hisax/config.c Fri Dec 29 23:07:22 2000
+++ linux-2.4.1-pre10.work/drivers/isdn/hisax/config.c Tue Jan 23 11:23:54 2001
@@ -1708,8 +1708,8 @@
}
static struct pci_device_id hisax_pci_tbl[] __initdata = {
-#ifdef CONFIG_HISAX_FRTIZPCI
- {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ,PCI_ANY_ID,
PCI_ANY_ID},
+#ifdef CONFIG_HISAX_FRITZPCI
+ {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_A1, PCI_ANY_ID,
+PCI_ANY_ID},
#endif
#ifdef CONFIG_HISAX_DIEHLDIVA
{PCI_VENDOR_ID_EICON,PCI_DEVICE_ID_EICON_DIVA20, PCI_ANY_ID,
PCI_ANY_ID},
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in modutils or drivers/isdn/hisax/
On Tue, 23 Jan 2001, Ingo Oeser wrote:
To quote drivers/isdn/hisax/config.c:1710-1713
static struct pci_device_id hisax_pci_tbl[] __initdata = {
#ifdef CONFIG_HISAX_FRTIZPCI
{PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
PCI_ANY_ID},
#endif
To quote my .config:
CONFIG_ISDN_DRV_HISAX=m
CONFIG_HISAX_FRITZPCI=y
So the bug is indeed in the driver and is a speling mistake
Patch is:
--- linux/drivers/isdn/hisax/config.c.origFri Dec 29 23:07:22 2000
+++ linux/drivers/isdn/hisax/config.c Tue Jan 23 15:07:54 2001
@@ -1708,8 +1708,8 @@
}
static struct pci_device_id hisax_pci_tbl[] __initdata = {
-#ifdef CONFIG_HISAX_FRTIZPCI
- {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ,PCI_ANY_ID,
PCI_ANY_ID},
+#ifdef CONFIG_HISAX_FRITZPCI
+ {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
PCI_ANY_ID},
#endif
#ifdef CONFIG_HISAX_DIEHLDIVA
{PCI_VENDOR_ID_EICON,PCI_DEVICE_ID_EICON_DIVA20, PCI_ANY_ID,
PCI_ANY_ID},
Close, but not quite. (Try compiling after your patch :)
Correct patch:
--- linux-2.4.0/drivers/isdn/hisax/config.c Fri Dec 29 23:07:22 2000
+++ linux-2.4.1-pre10.work/drivers/isdn/hisax/config.c Tue Jan 23 11:23:54 2001
@@ -1708,8 +1708,8 @@
}
static struct pci_device_id hisax_pci_tbl[] __initdata = {
-#ifdef CONFIG_HISAX_FRTIZPCI
- {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ,PCI_ANY_ID,
PCI_ANY_ID},
+#ifdef CONFIG_HISAX_FRITZPCI
+ {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_A1, PCI_ANY_ID,
+PCI_ANY_ID},
#endif
#ifdef CONFIG_HISAX_DIEHLDIVA
{PCI_VENDOR_ID_EICON,PCI_DEVICE_ID_EICON_DIVA20, PCI_ANY_ID,
PCI_ANY_ID},
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: (2.4.0->2.4.1-pre8) config problem with PCMCIA causing linkerror
On Wed, 17 Jan 2001, Derek Wildstar wrote: > With 2.4.0 thru 2.4.1-pre8 (could possibly be sooner than 2.4.0) > > PCMCIA_CONFIG_NETCARD is getting defined with CONFIG_PCMCIA, even when no > PCMCIA net cards are selected: > > 458 # PCMCIA network device support > 459 # > 460 CONFIG_NET_PCMCIA=y > 461 # CONFIG_PCMCIA_NETCARD is not set This looks more like a counterexample to what you're saying. Also, I don't see how it could happen that CONFIG_PCMCIA_NETCARD=y without CONFIG_NET_PCMCIA=y, from looking at the drivers/net/pcmcia/Config.in. (It may be still possible somehow because there is CONFIG_NET_PCMCIA=y in defconfig). > This causes the nonexistant drivers/net/pcmcia/pcmcia_net.o to try to be > linked. It looks like this is hepenning because CONFIG_NET_PCMCIA is > defined, but then CONFIG_PCMCIA_NETCARD is defined elsewhere. > > A patch is attached Your patch is wrong. It removes the config variable CONFIG_NET_PCMCIA, which is referenced in drivers/net/Makefile: subdir-$(CONFIG_NET_PCMCIA) += pcmcia So the pcmcia net drivers will never be built. I still don't see what's going wrong with the current code, but it can be simplified with the following patch. Does that work for you? --Kai diff -ur linux-2.4.1-pre8/Makefile linux-2.4.1-pre8.work/Makefile --- linux-2.4.1-pre8/Makefile Thu Jan 18 11:21:38 2001 +++ linux-2.4.1-pre8.work/Makefile Thu Jan 18 11:23:27 2001 @@ -155,7 +155,7 @@ DRIVERS-$(CONFIG_PCI) += drivers/pci/driver.o DRIVERS-$(CONFIG_MTD) += drivers/mtd/mtdlink.o DRIVERS-$(CONFIG_PCMCIA) += drivers/pcmcia/pcmcia.o -DRIVERS-$(CONFIG_PCMCIA_NETCARD) += drivers/net/pcmcia/pcmcia_net.o +DRIVERS-$(CONFIG_NET_PCMCIA) += drivers/net/pcmcia/pcmcia_net.o DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o diff -ur linux-2.4.1-pre8/drivers/net/pcmcia/Config.in linux-2.4.1-pre8.work/drivers/net/pcmcia/Config.in --- linux-2.4.1-pre8/drivers/net/pcmcia/Config.in Sun Nov 12 03:56:58 2000 +++ linux-2.4.1-pre8.work/drivers/net/pcmcia/Config.in Thu Jan 18 11:23:33 2001 @@ -32,13 +32,4 @@ fi fi -if [ "$CONFIG_PCMCIA_3C589" = "y" -o "$CONFIG_PCMCIA_3C574" = "y" -o \ - "$CONFIG_PCMCIA_FMVJ18X" = "y" -o "$CONFIG_PCMCIA_PCNET" = "y" -o \ - "$CONFIG_PCMCIA_NMCLAN" = "y" -o "$CONFIG_PCMCIA_SMC91C92" = "y" -o \ - "$CONFIG_PCMCIA_XIRC2PS" = "y" -o "$CONFIG_PCMCIA_RAYCS" = "y" -o \ - "$CONFIG_PCMCIA_NETWAVE" = "y" -o "$CONFIG_PCMCIA_WAVELAN" = "y" -o \ - "$CONFIG_PCMCIA_XIRTULIP" = "y" ]; then - define_bool CONFIG_PCMCIA_NETCARD y -fi - endmenu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (2.4.0-2.4.1-pre8) config problem with PCMCIA causing linkerror
On Wed, 17 Jan 2001, Derek Wildstar wrote: With 2.4.0 thru 2.4.1-pre8 (could possibly be sooner than 2.4.0) PCMCIA_CONFIG_NETCARD is getting defined with CONFIG_PCMCIA, even when no PCMCIA net cards are selected: 458 # PCMCIA network device support 459 # 460 CONFIG_NET_PCMCIA=y 461 # CONFIG_PCMCIA_NETCARD is not set This looks more like a counterexample to what you're saying. Also, I don't see how it could happen that CONFIG_PCMCIA_NETCARD=y without CONFIG_NET_PCMCIA=y, from looking at the drivers/net/pcmcia/Config.in. (It may be still possible somehow because there is CONFIG_NET_PCMCIA=y in defconfig). This causes the nonexistant drivers/net/pcmcia/pcmcia_net.o to try to be linked. It looks like this is hepenning because CONFIG_NET_PCMCIA is defined, but then CONFIG_PCMCIA_NETCARD is defined elsewhere. A patch is attached Your patch is wrong. It removes the config variable CONFIG_NET_PCMCIA, which is referenced in drivers/net/Makefile: subdir-$(CONFIG_NET_PCMCIA) += pcmcia So the pcmcia net drivers will never be built. I still don't see what's going wrong with the current code, but it can be simplified with the following patch. Does that work for you? --Kai diff -ur linux-2.4.1-pre8/Makefile linux-2.4.1-pre8.work/Makefile --- linux-2.4.1-pre8/Makefile Thu Jan 18 11:21:38 2001 +++ linux-2.4.1-pre8.work/Makefile Thu Jan 18 11:23:27 2001 @@ -155,7 +155,7 @@ DRIVERS-$(CONFIG_PCI) += drivers/pci/driver.o DRIVERS-$(CONFIG_MTD) += drivers/mtd/mtdlink.o DRIVERS-$(CONFIG_PCMCIA) += drivers/pcmcia/pcmcia.o -DRIVERS-$(CONFIG_PCMCIA_NETCARD) += drivers/net/pcmcia/pcmcia_net.o +DRIVERS-$(CONFIG_NET_PCMCIA) += drivers/net/pcmcia/pcmcia_net.o DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o diff -ur linux-2.4.1-pre8/drivers/net/pcmcia/Config.in linux-2.4.1-pre8.work/drivers/net/pcmcia/Config.in --- linux-2.4.1-pre8/drivers/net/pcmcia/Config.in Sun Nov 12 03:56:58 2000 +++ linux-2.4.1-pre8.work/drivers/net/pcmcia/Config.in Thu Jan 18 11:23:33 2001 @@ -32,13 +32,4 @@ fi fi -if [ "$CONFIG_PCMCIA_3C589" = "y" -o "$CONFIG_PCMCIA_3C574" = "y" -o \ - "$CONFIG_PCMCIA_FMVJ18X" = "y" -o "$CONFIG_PCMCIA_PCNET" = "y" -o \ - "$CONFIG_PCMCIA_NMCLAN" = "y" -o "$CONFIG_PCMCIA_SMC91C92" = "y" -o \ - "$CONFIG_PCMCIA_XIRC2PS" = "y" -o "$CONFIG_PCMCIA_RAYCS" = "y" -o \ - "$CONFIG_PCMCIA_NETWAVE" = "y" -o "$CONFIG_PCMCIA_WAVELAN" = "y" -o \ - "$CONFIG_PCMCIA_XIRTULIP" = "y" ]; then - define_bool CONFIG_PCMCIA_NETCARD y -fi - endmenu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ipppd == pppd? (was: Re: New features in Linux 2.4 - WonderfulWor...)
On 13 Jan 2001, Kai Henningsen wrote: > [EMAIL PROTECTED] (Joe Pranevich) wrote on 06.01.01 in ><[EMAIL PROTECTED]>: > > >much of the code, including a long awaited combination of the PPP > >layers from the ISDN layer and the serial device PPP layer, such as > > I've heard about that before, but I can find no hint about that in > Documentation/. The separate ipppd is still mentioned there. > > Plus, looking at the ISDN PPP sources also gives no hint. > > What's up? This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the generic PPP layer yet. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug (isdn-subsystem?) in 2.4.0
On Mon, 15 Jan 2001, Ronny Buchmann wrote:
> i have the following problem with kernel 2.4.0 (also with -ac6):
>
> kernel BUG at slab.c:1095!
> invalid operand:
> CPU: 0
I could reproduce the problem, the appended patch fixes it here. Linus,
could you please apply this for 2.4.1?
> ..
>
> (if you need the other numbers or anything else, ask me, i can reproduce
> it easily)
A decoded oops would be nice the next time, see
/REPORTING-BUGS
However, you gave enough information for me to reproduce the problem, so
it's fine this time.
Thanks,
--Kai
--- linux-2.4.1-pre2/drivers/isdn/isdn_v110.c% Sun Aug 6 21:43:42 2000
+++ linux-2.4.1-pre2/drivers/isdn/isdn_v110.c Mon Jan 15 22:31:43 2001
@@ -102,7 +102,7 @@
int i;
isdn_v110_stream *v;
- if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_KERNEL)) == NULL)
+ if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_ATOMIC)) == NULL)
return NULL;
memset(v, 0, sizeof(isdn_v110_stream));
v->key = key;
@@ -134,7 +134,7 @@
v->b = 0;
v->skbres = hdrlen;
v->maxsize = maxsize - hdrlen;
- if ((v->encodebuf = kmalloc(maxsize, GFP_KERNEL)) == NULL) {
+ if ((v->encodebuf = kmalloc(maxsize, GFP_ATOMIC)) == NULL) {
kfree(v);
return NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ipppd == pppd? (was: Re: New features in Linux 2.4 - WonderfulWor...)
On 13 Jan 2001, Kai Henningsen wrote: [EMAIL PROTECTED] (Joe Pranevich) wrote on 06.01.01 in [EMAIL PROTECTED]: much of the code, including a long awaited combination of the PPP layers from the ISDN layer and the serial device PPP layer, such as I've heard about that before, but I can find no hint about that in Documentation/. The separate ipppd is still mentioned there. Plus, looking at the ISDN PPP sources also gives no hint. What's up? This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the generic PPP layer yet. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bug (isdn-subsystem?) in 2.4.0
On Mon, 15 Jan 2001, Ronny Buchmann wrote:
i have the following problem with kernel 2.4.0 (also with -ac6):
kernel BUG at slab.c:1095!
invalid operand:
CPU: 0
I could reproduce the problem, the appended patch fixes it here. Linus,
could you please apply this for 2.4.1?
..
(if you need the other numbers or anything else, ask me, i can reproduce
it easily)
A decoded oops would be nice the next time, see
your linux kernel source/REPORTING-BUGS
However, you gave enough information for me to reproduce the problem, so
it's fine this time.
Thanks,
--Kai
--- linux-2.4.1-pre2/drivers/isdn/isdn_v110.c% Sun Aug 6 21:43:42 2000
+++ linux-2.4.1-pre2/drivers/isdn/isdn_v110.c Mon Jan 15 22:31:43 2001
@@ -102,7 +102,7 @@
int i;
isdn_v110_stream *v;
- if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_KERNEL)) == NULL)
+ if ((v = kmalloc(sizeof(isdn_v110_stream), GFP_ATOMIC)) == NULL)
return NULL;
memset(v, 0, sizeof(isdn_v110_stream));
v-key = key;
@@ -134,7 +134,7 @@
v-b = 0;
v-skbres = hdrlen;
v-maxsize = maxsize - hdrlen;
- if ((v-encodebuf = kmalloc(maxsize, GFP_KERNEL)) == NULL) {
+ if ((v-encodebuf = kmalloc(maxsize, GFP_ATOMIC)) == NULL) {
kfree(v);
return NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: That horrible hack from hell called A20
On Wed, 10 Jan 2001, rdunlap wrote: > Here's a patch to 2.2.19-pre7 that is essentially a backport of the > 2.4.0 gate-A20 code. > > This speeds up booting on my fast-A20 board (Celeron 500 MHz, no KBC) > from 2 min:15 seconds to . > > Kai, you reported that your system was OK with 2.4.0-test12-pre6. > Does that mean that it's OK with 2.4.0-final also? Yes, i would have complained otherwise ;-) > Comments? Should we be merging Peter's int 0x15-first patch with this? > And test for A20-gated after each step, before going to the next > method? Get that working and then backport it to 2.2.19? > Have their been any test reports on Peter's last patch? I didn't see > any, but if that should be the goal, I'll give it a whirl. > > I'd like to see this applied to 2.2.19. At least changing the long > delay so that it doesn't appear that Linux isn't going to boot... For what it's worth, 2.2.19pre7+your patch works fine here (across suspend). --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix nfs as module on 2.4.0-pre2
Obvious, I guess. --Kai diff -ur linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c --- linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c Sat Apr 22 01:08:52 2000 +++ linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c Fri Jan 12 01:00:40 +2001 @@ -35,6 +35,7 @@ EXPORT_SYMBOL(rpciod_down); EXPORT_SYMBOL(rpciod_up); EXPORT_SYMBOL(rpc_new_task); +EXPORT_SYMBOL(rpc_release_task); EXPORT_SYMBOL(rpc_wake_up_status); /* RPC client functions */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix nfs as module on 2.4.0-pre2
Obvious, I guess. --Kai diff -ur linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c --- linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c Sat Apr 22 01:08:52 2000 +++ linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c Fri Jan 12 01:00:40 +2001 @@ -35,6 +35,7 @@ EXPORT_SYMBOL(rpciod_down); EXPORT_SYMBOL(rpciod_up); EXPORT_SYMBOL(rpc_new_task); +EXPORT_SYMBOL(rpc_release_task); EXPORT_SYMBOL(rpc_wake_up_status); /* RPC client functions */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hisax/sportster dependency error
On Sat, 6 Jan 2001, Daniel Stodden wrote: > --- linux-2.4/drivers/isdn/hisax/Makefile.orig Sat Jan 6 02:47:31 2001 > +++ linux-2.4/drivers/isdn/hisax/Makefile Sat Jan 6 02:21:22 2001 > @@ -34,7 +34,7 @@ > hisax-objs-$(CONFIG_HISAX_ASUSCOM) += asuscom.o isac.o arcofi.o hscx.o > hisax-objs-$(CONFIG_HISAX_TELEINT) += teleint.o isac.o arcofi.o hfc_2bs0.o > hisax-objs-$(CONFIG_HISAX_SEDLBAUER) += sedlbauer.o isac.o arcofi.o hscx.o isar.o > -hisax-objs-$(CONFIG_HISAX_SPORTSTER) += sportster.o isac.o arcofi.o hfc_2bs0.o > +hisax-objs-$(CONFIG_HISAX_SPORTSTER) += sportster.o isac.o arcofi.o hfc_2bs0.o >hscx.o > hisax-objs-$(CONFIG_HISAX_MIC) += mic.o isac.o arcofi.o hfc_2bs0.o > hisax-objs-$(CONFIG_HISAX_NETJET) += nj_s.o netjet.o isac.o arcofi.o > hisax-objs-$(CONFIG_HISAX_NETJET_U) += nj_u.o netjet.o icc.o Thanks, I'll put that into the next ISDN update. > question: something which i missed to ask for about year now: > > bitch[3]:~$ cat /proc/ioports > -001f : dma1 > 0020-003f : pic1 > 0040-005f : timer > 0060-006f : keyboard > 0070-007f : rtc > 0080-008f : dma page reg > 00a0-00bf : pic2 > 00c0-00df : dma2 > 00f0-00ff : fpu > 0170-0177 : ide1 > 0220-022f : soundblaster > 0268-026f : sportster > 02f8-02ff : serial(set) > 0330-0333 : MPU-401 UART > 0376-0376 : ide1 > 0378-037a : parport0 > 03c0-03df : vga+ > 03c0-03df : matrox > 03f8-03ff : serial(set) > 0668-066f : sportster > 0a68-0a6f : sportster > 0cf8-0cff : PCI conf1 > 0e68-0e6f : sportster > 1268-126f : sportster > [...] > > could anyone explain this behaviour? > > the card is at io=0x268 irq=7 > > according to sportster.c:get_io_range, this appears to be perfectly > intentional, request_regioning 64x8 byte from 0x268 in 1024byte-steps. AFAIK, this is because the hardware is stupid and does decode the higher address lines. Therefore, the IO ports are mirrored every 1024 bytes and should be reserved to avoid potential conflicts with other devices. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hisax/sportster dependency error
On Sat, 6 Jan 2001, Daniel Stodden wrote: --- linux-2.4/drivers/isdn/hisax/Makefile.orig Sat Jan 6 02:47:31 2001 +++ linux-2.4/drivers/isdn/hisax/Makefile Sat Jan 6 02:21:22 2001 @@ -34,7 +34,7 @@ hisax-objs-$(CONFIG_HISAX_ASUSCOM) += asuscom.o isac.o arcofi.o hscx.o hisax-objs-$(CONFIG_HISAX_TELEINT) += teleint.o isac.o arcofi.o hfc_2bs0.o hisax-objs-$(CONFIG_HISAX_SEDLBAUER) += sedlbauer.o isac.o arcofi.o hscx.o isar.o -hisax-objs-$(CONFIG_HISAX_SPORTSTER) += sportster.o isac.o arcofi.o hfc_2bs0.o +hisax-objs-$(CONFIG_HISAX_SPORTSTER) += sportster.o isac.o arcofi.o hfc_2bs0.o hscx.o hisax-objs-$(CONFIG_HISAX_MIC) += mic.o isac.o arcofi.o hfc_2bs0.o hisax-objs-$(CONFIG_HISAX_NETJET) += nj_s.o netjet.o isac.o arcofi.o hisax-objs-$(CONFIG_HISAX_NETJET_U) += nj_u.o netjet.o icc.o Thanks, I'll put that into the next ISDN update. question: something which i missed to ask for about year now: bitch[3]:~$ cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 0220-022f : soundblaster 0268-026f : sportster 02f8-02ff : serial(set) 0330-0333 : MPU-401 UART 0376-0376 : ide1 0378-037a : parport0 03c0-03df : vga+ 03c0-03df : matrox 03f8-03ff : serial(set) 0668-066f : sportster 0a68-0a6f : sportster 0cf8-0cff : PCI conf1 0e68-0e6f : sportster 1268-126f : sportster [...] could anyone explain this behaviour? the card is at io=0x268 irq=7 according to sportster.c:get_io_range, this appears to be perfectly intentional, request_regioning 64x8 byte from 0x268 in 1024byte-steps. AFAIK, this is because the hardware is stupid and does decode the higher address lines. Therefore, the IO ports are mirrored every 1024 bytes and should be reserved to avoid potential conflicts with other devices. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 link error with modular PCMCIA
On Sat, 6 Jan 2001, Jochen Friedrich wrote: > Hi, > > problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are > compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o... This should fix it. --- drivers/net/Makefile% Fri Jan 5 15:10:11 2001 +++ drivers/net/MakefileSat Jan 6 23:48:28 2001 @@ -26,7 +26,7 @@ obj-$(CONFIG_ISDN) += slhc.o endif -subdir-$(CONFIG_PCMCIA) += pcmcia +subdir-$(CONFIG_NET_PCMCIA) += pcmcia subdir-$(CONFIG_TULIP) += tulip subdir-$(CONFIG_IRDA) += irda subdir-$(CONFIG_TR) += tokenring The problem is that CONFIG_PCMCIA is M, therefore drivers/net/pcmcia is not entered during "make vmlinux". The patch fixes this and will produce an (empty) pcmcia_net.o And, yes, the directory will also be entered when doing "make modules", because pcmcia is in $(mod-subdirs). --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 link error with modular PCMCIA
On Sat, 6 Jan 2001, Jochen Friedrich wrote: Hi, problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o... This should fix it. --- drivers/net/Makefile% Fri Jan 5 15:10:11 2001 +++ drivers/net/MakefileSat Jan 6 23:48:28 2001 @@ -26,7 +26,7 @@ obj-$(CONFIG_ISDN) += slhc.o endif -subdir-$(CONFIG_PCMCIA) += pcmcia +subdir-$(CONFIG_NET_PCMCIA) += pcmcia subdir-$(CONFIG_TULIP) += tulip subdir-$(CONFIG_IRDA) += irda subdir-$(CONFIG_TR) += tokenring The problem is that CONFIG_PCMCIA is M, therefore drivers/net/pcmcia is not entered during "make vmlinux". The patch fixes this and will produce an (empty) pcmcia_net.o And, yes, the directory will also be entered when doing "make modules", because pcmcia is in $(mod-subdirs). --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 on sparc64 build problems
On Fri, 5 Jan 2001, David S. Miller wrote: > The sparc64 config should never allow you to build the amd7930 and > dbri sbus sound drivers, that is a bug, and I'll fix that. However, there's supposedly the same problem for sparc32, because the ISDN support for the amd7930 apparantly never worked (it wasn't even selectable in the kernel-config), and thus the corresponding files in drivers/isdn/hisax were removed. Looks like this broke the sparc build. Is anybody willing to work with me on resolving this? --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 on sparc64 build problems
On Fri, 5 Jan 2001, David S. Miller wrote: The sparc64 config should never allow you to build the amd7930 and dbri sbus sound drivers, that is a bug, and I'll fix that. However, there's supposedly the same problem for sparc32, because the ISDN support for the amd7930 apparantly never worked (it wasn't even selectable in the kernel-config), and thus the corresponding files in drivers/isdn/hisax were removed. Looks like this broke the sparc build. Is anybody willing to work with me on resolving this? --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] isdn iprofd hang ttyI1...
On Wed, 3 Jan 2001, Andrea Baldoni wrote: > The iprofd contained in isdnutils 3.0 use the same buffer and buffer size > in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles. > > The kernel use different sizes, so iprofd set incorrect data, resulting in a > hang of the ttyI from 1 to last. I suppose the right way to implement profile > save & restore will be kernel-version independent and maybe I will work on > that, but at the moment I made the IIOCGETPRF and IIOCSETPRF IOCTLs symmetric: You're right, that reminds me of one of the rather low priority problems on my list. iprofd in 2.2 has the same problem, so I suppose there's nobody using it at all. Your patch looks fine, however I'ld prefer to rip out support for these ioctls completely. If one really needs it, one can achieve the same effect entirely from user space anyway. Even with your patch the current solution is not portable across 2.2 / 2.4 and therefore not acceptable as-is. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On 3 Jan 2001, Eric W. Biederman wrote: > Kai Germaschewski <[EMAIL PROTECTED]> writes: > > > I think the problem was that we relied on divert_if being initialized to > > zero automatically, which didn't happen because it was not declared static > > and therefore not in .bss (*is this true?*). > > All variables with static storage (not with static scope) if not explicitly > initialized are placed in the bss segment. In particular this > means that adding/removing a static changes nothing. The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when I found what was really going on. Other source files used a global initialized variable "divert_if" as well, so this became the same one as the one referenced in isdn_common.c. That's why it wasn't zero, it was explicitly initialized elsewhere. However, making divert_if static in isdn_common.c fixes the problem, because now it's really local to this file and therefore initialized to NULL. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On 3 Jan 2001, Eric W. Biederman wrote: Kai Germaschewski [EMAIL PROTECTED] writes: I think the problem was that we relied on divert_if being initialized to zero automatically, which didn't happen because it was not declared static and therefore not in .bss (*is this true?*). All variables with static storage (not with static scope) if not explicitly initialized are placed in the bss segment. In particular this means that adding/removing a static changes nothing. The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when I found what was really going on. Other source files used a global initialized variable "divert_if" as well, so this became the same one as the one referenced in isdn_common.c. That's why it wasn't zero, it was explicitly initialized elsewhere. However, making divert_if static in isdn_common.c fixes the problem, because now it's really local to this file and therefore initialized to NULL. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] isdn iprofd hang ttyI1...
On Wed, 3 Jan 2001, Andrea Baldoni wrote: The iprofd contained in isdnutils 3.0 use the same buffer and buffer size in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles. The kernel use different sizes, so iprofd set incorrect data, resulting in a hang of the ttyI from 1 to last. I suppose the right way to implement profile save restore will be kernel-version independent and maybe I will work on that, but at the moment I made the IIOCGETPRF and IIOCSETPRF IOCTLs symmetric: You're right, that reminds me of one of the rather low priority problems on my list. iprofd in 2.2 has the same problem, so I suppose there's nobody using it at all. Your patch looks fine, however I'ld prefer to rip out support for these ioctls completely. If one really needs it, one can achieve the same effect entirely from user space anyway. Even with your patch the current solution is not portable across 2.2 / 2.4 and therefore not acceptable as-is. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On Tue, 2 Jan 2001, Gerold Jury wrote:
> I have reversed the patches part by part, the only thing that makes a
> difference is the diversion services.
> The reason for this remains unknown for me.
I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the following patch fixes the problem?
I think the problem was that we relied on divert_if being initialized to
zero automatically, which didn't happen because it was not declared static
and therefore not in .bss (*is this true?*).
diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c
linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c
--- linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c Tue Jan 2 12:26:45
2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c Tue Jan 2 23:47:48
+2001
@@ -68,7 +68,7 @@
extern char *isdn_v110_revision;
#ifdef CONFIG_ISDN_DIVERSION
-isdn_divert_if *divert_if; /* interface to diversion module */
+static isdn_divert_if *divert_if; /* = NULL */
#endif CONFIG_ISDN_DIVERSION
@@ -2118,7 +2118,6 @@
}
#ifdef CONFIG_ISDN_DIVERSION
-extern isdn_divert_if *divert_if;
static char *map_drvname(int di)
{
I also attached a patch which disables diversion service being selected as
built-in during kernel config, because this doesn't work yet.
--Kai
diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/Config.in
linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in
--- linux-2.4.0-prerelease-diff/drivers/isdn/Config.in Tue Jan 2 12:26:45 2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in Tue Jan 2 23:46:00
+2001
@@ -23,7 +23,7 @@
mainmenu_option next_comment
comment 'ISDN feature submodules'
dep_tristate 'isdnloop support' CONFIG_ISDN_DRV_LOOP $CONFIG_ISDN
- dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN
+ dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN m
endmenu
comment 'low-level hardware drivers'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote: > On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote: > > The ISDN changes for the HISAX drivers > > that came in since test12 have introduced a bug that causes a > > AIEE-something and a complete kernel hang when i hangup the isdn line. > > I also saw this on my Alpha. Plus it hung one while the machine was idle > and an analog phone call came in. > > For me disabling 'diversion services' solved the problem. Whether this fixed > the problem or only hides it I don't know :) I'm looking into this, but I'm not quite there yet. I don't believe it really is connected to the INIT_LIST_HEAD changes, diversion services and the Makefile changes are a more likely suspect. It'ld be nice if I could reproduce it but I can't as of yet. If somebody could catch a call trace, that would help a lot, too. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-rerelease] driver/net/Makefile bug (pcmcia)
On Tue, 2 Jan 2001, Andreas Jellinghaus wrote: > modules for pcmcia network cards are not build by the kernel. I just tried, and I don't see this problem. What's your .config? > subdir-$(CONFIG_PCMCIA) += pcmcia > > should be > > ifeq ($(CONFIG_PCMCIA),y) > subdir-y += pcmcia > subdir-m += pcmcia > endif > > because CONFIG_PCMCIA=y but CONFIG_PCMCIA_SOMENETWORKDRIVER=m No, pcmcia is in $(mod-subdirs), which leads to "make" entering drivers/net/pcmcia when MAKING_MODULES, even if pcmcia is only in $(subdir-y). BTW: CONFIG_PCMCIA is a tristate, so the above would break CONFIG_PCMCIA=m. > maybe even bett is useing CONFIG_NET_PCMCIA instead of CONFIG_PCMCIA. Yes, that makes sense to me. Proposed patch: diff -ur linux-2.4.0-prerelease-diff/drivers/net/Makefile linux-2.4.0-prerelease-diff.work/drivers/net/Makefile --- linux-2.4.0-prerelease-diff/drivers/net/MakefileTue Jan 2 12:26:45 2001 +++ linux-2.4.0-prerelease-diff.work/drivers/net/Makefile Tue Jan 2 12:50:42 +2001 @@ -26,7 +26,7 @@ obj-$(CONFIG_ISDN) += slhc.o endif -subdir-$(CONFIG_PCMCIA) += pcmcia +subdir-$(CONFIG_NET_PCMCIA) += pcmcia subdir-$(CONFIG_TULIP) += tulip subdir-$(CONFIG_IRDA) += irda subdir-$(CONFIG_TR) += tokenring [This doesn't fix any bugs, but it slightly optimizes the build process because drivers/net/pcmcia will only be entered when PCMCIA net drivers are selected] --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0-rerelease] driver/net/Makefile bug (pcmcia)
On Tue, 2 Jan 2001, Andreas Jellinghaus wrote: modules for pcmcia network cards are not build by the kernel. I just tried, and I don't see this problem. What's your .config? subdir-$(CONFIG_PCMCIA) += pcmcia should be ifeq ($(CONFIG_PCMCIA),y) subdir-y += pcmcia subdir-m += pcmcia endif because CONFIG_PCMCIA=y but CONFIG_PCMCIA_SOMENETWORKDRIVER=m No, pcmcia is in $(mod-subdirs), which leads to "make" entering drivers/net/pcmcia when MAKING_MODULES, even if pcmcia is only in $(subdir-y). BTW: CONFIG_PCMCIA is a tristate, so the above would break CONFIG_PCMCIA=m. maybe even bett is useing CONFIG_NET_PCMCIA instead of CONFIG_PCMCIA. Yes, that makes sense to me. Proposed patch: diff -ur linux-2.4.0-prerelease-diff/drivers/net/Makefile linux-2.4.0-prerelease-diff.work/drivers/net/Makefile --- linux-2.4.0-prerelease-diff/drivers/net/MakefileTue Jan 2 12:26:45 2001 +++ linux-2.4.0-prerelease-diff.work/drivers/net/Makefile Tue Jan 2 12:50:42 +2001 @@ -26,7 +26,7 @@ obj-$(CONFIG_ISDN) += slhc.o endif -subdir-$(CONFIG_PCMCIA) += pcmcia +subdir-$(CONFIG_NET_PCMCIA) += pcmcia subdir-$(CONFIG_TULIP) += tulip subdir-$(CONFIG_IRDA) += irda subdir-$(CONFIG_TR) += tokenring [This doesn't fix any bugs, but it slightly optimizes the build process because drivers/net/pcmcia will only be entered when PCMCIA net drivers are selected] --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote: On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote: The ISDN changes for the HISAX drivers that came in since test12 have introduced a bug that causes a AIEE-something and a complete kernel hang when i hangup the isdn line. I also saw this on my Alpha. Plus it hung one while the machine was idle and an analog phone call came in. For me disabling 'diversion services' solved the problem. Whether this fixed the problem or only hides it I don't know :) I'm looking into this, but I'm not quite there yet. I don't believe it really is connected to the INIT_LIST_HEAD changes, diversion services and the Makefile changes are a more likely suspect. It'ld be nice if I could reproduce it but I can't as of yet. If somebody could catch a call trace, that would help a lot, too. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
On Tue, 2 Jan 2001, Gerold Jury wrote:
I have reversed the patches part by part, the only thing that makes a
difference is the diversion services.
The reason for this remains unknown for me.
I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the following patch fixes the problem?
I think the problem was that we relied on divert_if being initialized to
zero automatically, which didn't happen because it was not declared static
and therefore not in .bss (*is this true?*).
diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c
linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c
--- linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c Tue Jan 2 12:26:45
2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c Tue Jan 2 23:47:48
+2001
@@ -68,7 +68,7 @@
extern char *isdn_v110_revision;
#ifdef CONFIG_ISDN_DIVERSION
-isdn_divert_if *divert_if; /* interface to diversion module */
+static isdn_divert_if *divert_if; /* = NULL */
#endif CONFIG_ISDN_DIVERSION
@@ -2118,7 +2118,6 @@
}
#ifdef CONFIG_ISDN_DIVERSION
-extern isdn_divert_if *divert_if;
static char *map_drvname(int di)
{
I also attached a patch which disables diversion service being selected as
built-in during kernel config, because this doesn't work yet.
--Kai
diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/Config.in
linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in
--- linux-2.4.0-prerelease-diff/drivers/isdn/Config.in Tue Jan 2 12:26:45 2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in Tue Jan 2 23:46:00
+2001
@@ -23,7 +23,7 @@
mainmenu_option next_comment
comment 'ISDN feature submodules'
dep_tristate 'isdnloop support' CONFIG_ISDN_DRV_LOOP $CONFIG_ISDN
- dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN
+ dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN m
endmenu
comment 'low-level hardware drivers'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre4 fails to compile
On Sat, 23 Dec 2000, ebi4 wrote: > ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory > make: *** [vmlinux] Error 1 I sent the following patch to Linus already. It should fix the problem. --Kai diff -ur linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile linux-2.4.0-test13-pre3.1/drivers/ieee1394/Makefile --- linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile Tue Dec 19 21:44:15 2000 +++ linux-2.4.0-test13-pre3.1/drivers/ieee1394/Makefile Wed Dec 20 12:42:07 2000 @@ -23,7 +23,8 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) -include $(TOPDIR)/Rules.make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre4 fails to compile
On Sat, 23 Dec 2000, ebi4 wrote: ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory make: *** [vmlinux] Error 1 I sent the following patch to Linus already. It should fix the problem. --Kai diff -ur linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile linux-2.4.0-test13-pre3.1/drivers/ieee1394/Makefile --- linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile Tue Dec 19 21:44:15 2000 +++ linux-2.4.0-test13-pre3.1/drivers/ieee1394/Makefile Wed Dec 20 12:42:07 2000 @@ -23,7 +23,8 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) -include $(TOPDIR)/Rules.make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: test13-pre2 fails "make xconfig" in isdn/Config.in
On Sat, 16 Dec 2000, Gunther Mayer wrote: > apply this patch if like to fix this obvious error > with "make xconfig" on plain tree: > ./tkparse < ../arch/i386/config.in >> kconfig.tk > drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate >condition > make[1]: *** [kconfig.tk] Error 1 > make[1]: Leaving directory `/usr/src/linux/scripts' > > --- linux/drivers/isdn/Config.in-240t13pre2-origSat Dec 16 12:20:59 2000 > +++ linux/drivers/isdn/Config.inSat Dec 16 12:21:48 2000 > @@ -95,7 +95,7 @@ >dep_bool 'Eicon PCI DIVA Server BRI/PRI/4BRI support' >CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI >bool 'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA > fi > - dep_tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS > + bool ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS > fi > > # CAPI subsystem Sorry, my bad. (Note to myself: Always test changes before submitting with make menuconfig and make xconfig). However, the correct fix is: Only in linux-2.4.0-test13-pre2.work/: .menuconfig.log diff -ur linux-2.4.0-test13-pre2/drivers/isdn/Config.in linux-2.4.0-test13-pre2.work/drivers/isdn/Config.in --- linux-2.4.0-test13-pre2/drivers/isdn/Config.in Sat Dec 16 15:36:21 2000 +++ linux-2.4.0-test13-pre2.work/drivers/isdn/Config.in Sat Dec 16 15:39:47 2000 @@ -95,7 +95,7 @@ dep_bool 'Eicon PCI DIVA Server BRI/PRI/4BRI support' CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI bool 'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA fi - dep_tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS + tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS fi # CAPI subsystem BTW: There's probably issues with ISDN built non-modular, because that patch didn't have much testing yet. I'll go through different cases now. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: test13-pre2 fails make xconfig in isdn/Config.in
On Sat, 16 Dec 2000, Gunther Mayer wrote: apply this patch if like to fix this obvious error with "make xconfig" on plain tree: ./tkparse ../arch/i386/config.in kconfig.tk drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate condition make[1]: *** [kconfig.tk] Error 1 make[1]: Leaving directory `/usr/src/linux/scripts' --- linux/drivers/isdn/Config.in-240t13pre2-origSat Dec 16 12:20:59 2000 +++ linux/drivers/isdn/Config.inSat Dec 16 12:21:48 2000 @@ -95,7 +95,7 @@ dep_bool 'Eicon PCI DIVA Server BRI/PRI/4BRI support' CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI bool 'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA fi - dep_tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS + bool ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS fi # CAPI subsystem Sorry, my bad. (Note to myself: Always test changes before submitting with make menuconfig and make xconfig). However, the correct fix is: Only in linux-2.4.0-test13-pre2.work/: .menuconfig.log diff -ur linux-2.4.0-test13-pre2/drivers/isdn/Config.in linux-2.4.0-test13-pre2.work/drivers/isdn/Config.in --- linux-2.4.0-test13-pre2/drivers/isdn/Config.in Sat Dec 16 15:36:21 2000 +++ linux-2.4.0-test13-pre2.work/drivers/isdn/Config.in Sat Dec 16 15:39:47 2000 @@ -95,7 +95,7 @@ dep_bool 'Eicon PCI DIVA Server BRI/PRI/4BRI support' CONFIG_ISDN_DRV_EICON_PCI $CONFIG_PCI bool 'Eicon S,SX,SCOM,Quadro,S2M support' CONFIG_ISDN_DRV_EICON_ISA fi - dep_tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS + tristate ' Build Eicon driver type standalone' CONFIG_ISDN_DRV_EICON_DIVAS fi # CAPI subsystem BTW: There's probably issues with ISDN built non-modular, because that patch didn't have much testing yet. I'll go through different cases now. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] test12-pre8 task queue fix batch
On Sun, 10 Dec 2000, Mohammad A. Haque wrote: > More fixes. Ignore previous. diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c linux-2.4.0-test12/drivers/atm/ambassador.c --- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul 7 00:37:24 2000 +++ linux-2.4.0-test12/drivers/atm/ambassador.c Sun Dec 10 19:44:09 2000 @@ -2397,7 +2397,7 @@ #ifdef FILL_RX_POOLS_IN_BH // initialise bottom half - dev->bh.next = 0; + INIT_LIST_HEAD(>bh.list); dev->bh.sync = 0; dev->bh.routine = (void (*)(void *)) fill_rx_pools; dev->bh.data = dev; > (and so on) I don't think this is the right fix. First of all, if one needed to the INIT_LIST_HEAD, some new macro should be introduced (INIT_TASK or something), which takes care of the .list and .sync structures. So when something was about to change again in the future, you wouldn't have to go through all the files and fix them again. But: The INIT_LIST_HEAD is unnecessary and misleading at least, because tqueue->list is not a list head, it's there to allow for adding the struct tqueue onto a task_queue. So we have the task_queue, that's the list head - it needs to be initialized, and that's already done via DECLARE_TASK_QUEUE. Then we have tasks to be added to the list (struct tqueue), their .list members don't need to be initialized because they get set when the task is queued on a task_queue (in queue_task). So I think the correct fix is just to remove the offending lines. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] test12-pre8 task queue fix batch
On Sun, 10 Dec 2000, Mohammad A. Haque wrote: More fixes. Ignore previous. diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c linux-2.4.0-test12/drivers/atm/ambassador.c --- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul 7 00:37:24 2000 +++ linux-2.4.0-test12/drivers/atm/ambassador.c Sun Dec 10 19:44:09 2000 @@ -2397,7 +2397,7 @@ #ifdef FILL_RX_POOLS_IN_BH // initialise bottom half - dev-bh.next = 0; + INIT_LIST_HEAD(dev-bh.list); dev-bh.sync = 0; dev-bh.routine = (void (*)(void *)) fill_rx_pools; dev-bh.data = dev; (and so on) I don't think this is the right fix. First of all, if one needed to the INIT_LIST_HEAD, some new macro should be introduced (INIT_TASK or something), which takes care of the .list and .sync structures. So when something was about to change again in the future, you wouldn't have to go through all the files and fix them again. But: The INIT_LIST_HEAD is unnecessary and misleading at least, because tqueue-list is not a list head, it's there to allow for adding the struct tqueue onto a task_queue. So we have the task_queue, that's the list head - it needs to be initialized, and that's already done via DECLARE_TASK_QUEUE. Then we have tasks to be added to the list (struct tqueue), their .list members don't need to be initialized because they get set when the task is queued on a task_queue (in queue_task). So I think the correct fix is just to remove the offending lines. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
On Thu, 7 Dec 2000, Russell King wrote: > Linus Torvalds writes: > > - me: UHCI drivers really need to enable bus mastering. > > But it'll already be turned on if pci_assign_unassigned_resources() is > called. This calls pdev_enable_device for every single device, which > turns on the bus master bit in the PCI command register. Maybe I'm stating something which is obvious to everybody, but note that pci_assign_unassigned_resources is only called from ./arch/alpha/kernel/pci.c: pci_assign_unassigned_resources(); ./arch/mips/ddb5074/pci.c: pci_assign_unassigned_resources(); ./arch/arm/kernel/bios32.c: pci_assign_unassigned_resources(); so it looks like most archs don't use it anyway. (And that's supposedly why pci_set_master helped people on x86) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
On Thu, 7 Dec 2000, Russell King wrote: Linus Torvalds writes: - me: UHCI drivers really need to enable bus mastering. But it'll already be turned on if pci_assign_unassigned_resources() is called. This calls pdev_enable_device for every single device, which turns on the bus master bit in the PCI command register. Maybe I'm stating something which is obvious to everybody, but note that pci_assign_unassigned_resources is only called from ./arch/alpha/kernel/pci.c: pci_assign_unassigned_resources(); ./arch/mips/ddb5074/pci.c: pci_assign_unassigned_resources(); ./arch/arm/kernel/bios32.c: pci_assign_unassigned_resources(); so it looks like most archs don't use it anyway. (And that's supposedly why pci_set_master helped people on x86) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
