Re: Oops in 2.4.0-ac5
On Wed, 10 Jan 2001 15:23:14 -0500,
Nathan Walp [EMAIL PROTECTED] wrote:
Here it is... I opted to cut out the 1200-odd warnings, which from the
look of them were all because i'm running it under 2.4.0-ac4 (which
boots fine).
ksymoops defaults to using /proc entries from the current system. This
is fine for most people but you have to override the default when
decoding an oops from another kernel.
ksymoops -KL -m /boot/System.map-2.4.0-ac5
ignores the running ksyms and lsmod files, removing your warnings.
EIP; c01129ba setup_apic_nmi_watchdog+a/90 =
Trace; c0100191 L6+0/2
Code; c01129ba setup_apic_nmi_watchdog+a/90
_EIP:
Code; c01129ba setup_apic_nmi_watchdog+a/90 =
0: 0f 30 wrmsr =
Code; c01129bc setup_apic_nmi_watchdog+c/90
This is why my original NMI for UP code in kdb uses wrmsr_eio() instead
of wrmsr. wrmsr_eio() catches errors where the APIC does not support
the msr and returns EIO instead of oopsing and taking the kernel with
it. I could never persuade Ingo to use wrmsr_eio() and check the
return code, maybe this will change his mind. Extract from kdb v1.7.
/*
* {rd,wr}msr_eio by HPA, moved from arch/i386/msr.c to here.
* Keith Owens.
*/
/* Note: "err" is handled in a funny way below. Otherwise one version
of gcc or another breaks. */
extern inline int wrmsr_eio(u32 reg, u32 eax, u32 edx)
{
int err;
asm volatile(
"1: wrmsr\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %4,%0\n"
"jmp 2b\n"
".previous\n"
".section __ex_table,\"a\"\n"
".align 4\n"
".long 1b,3b\n"
".previous"
: "=bDS" (err)
: "a" (eax), "d" (edx), "c" (reg), "i" (-EIO), "0" (0));
return err;
}
.
/*
* Activate or deactivate NMI watchdog via a local APIC.
*/
int setup_apic_nmi_watchdog(int value)
{
int ret, eax;
if (!test_bit(X86_FEATURE_APIC, boot_cpu_data.x86_capability))
return(-EIO);
if (nmi_watchdog_source nmi_watchdog_source != 1)
return(0); /* Not using local APIC */
/* Disable performance counters 0, 1 for all NMI changes */
nmi_watchdog = proc_nmi_watchdog = nmi_watchdog_source = 0;
if ((ret = wrmsr_eio(EVNTSEL0, 0, 0)) ||
(ret = wrmsr_eio(EVNTSEL1, 0, 0)) ||
(ret = wrmsr_eio(PERFCTR0, 0, 0)) ||
(ret = wrmsr_eio(PERFCTR1, 0, 0)))
goto exit;
if (!value)
return(0);
/* Must set before activation to catch first NMI */
nmi_watchdog = proc_nmi_watchdog = nmi_watchdog_source = 1;
eax = 1 20 /* Interrupt on overflow */
| 1 17 /* OS mode */
| 1 16 /* User mode */
| 0x79; /* Event, cpu clocks not halted */
if ((ret = wrmsr_eio(EVNTSEL1, eax, 0))
|| (ret = set_nmi_counter_local()))
goto exit;
apic_write_around(APIC_LVTPC, APIC_DM_NMI);
eax = 1 22; /* Enable performance counters, only using ctr1 */
ret = wrmsr_eio(EVNTSEL0, eax, 0);
exit:
if (ret)
nmi_watchdog = proc_nmi_watchdog = nmi_watchdog_source = 0;
else
printk(KERN_INFO "Activated NMI via local APIC\n");
return(ret);
}
-
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: Problem with module versioning in 2.4.0
On Thu, 11 Jan 2001 00:17:41 + (GMT), Alan Cox [EMAIL PROTECTED] wrote: jeremyhu wrote See below for my origional problem. It seems the problem lies in the module versioning option. Not quite Probably is. When the system boots, I am spammed with the following line: insmod: /lib/modules/2.4.0/kernel/net/unix/unix.o: insmod net-pf-1 failed What happens is this kernel needs unix sockets kernel invokes modprobe modprobe opens a unix socket kernel needs unix sockets kernel invokes modprobe . kmod.c has code to catch that recursive case and abort it. The problem is not the loop per se, it is caused by that insmod unix.o failing on every attempt. That is almost certainly caused by bad symbol versions. See http://www.tux.org/lkml/#s8-8. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Thu, 11 Jan 2001 16:38:50 +1100, Antony Suter [EMAIL PROTECTED] wrote: Allen Unueco wrote: I ran into this while hacking the Nvidia kernel driver to work with 2.4.0. I got the driver working but it's not 100% Also where did get_module_symbol() and put_module_symbol() go? Patches for the NVIDIA binary X drivers following all these kernel changes can be gotten from IRC server irc.openprojects.net, channel #nvidia. Or from http://ex.shafted.com.au/nvidia/ And what a pile of crud those patches are!! Instead of using the clean replacement interface for get_module_symbol, nvidia/patch-2.4.0-PR hard codes the old get_module_symbol algorithm as inline code. This patch violates the modules interface by accessing modules.c internal data. It still suffers from all the problems that get_module_symbol had. Because it is hard coded as inline code instead of a common function, will be much harder to fix when it breaks. Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. - 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 kernel paging error
On Thu, 11 Jan 2001 08:23:33 + (GMT), Mark Hindley [EMAIL PROTECTED] wrote: As I use the kernel module autoloader I also have a cron entry for rmmod -a which runs every so often to clear out the unused modules. Although the logs record rmmod running, they don't say what if any modules were removed. If you define /var/log/ksymoops than modutils will save the symbol table at every insert or delete of a module, all neatly timestamped. Useful for debugging module related oops. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Thu, 11 Jan 2001 11:42:24 +,
David Woodhouse [EMAIL PROTECTED] wrote:
Taking away get_module_symbol() and providing a replacement which has link
order problems wasn't really very sensible.
It's too late to do the sensible thing and deprecate the old version rather
than having a 'flag day'. But can we at least fix the link order crap?
struct static_inter_module_entry {
const char *im_name;
const void *userdata;
};
#define inter_module_register_static(x,y) \
static struct static_inter_module_entry __ime_##x \
__attribute__((unused,__section__(".intermodule")) \
= { #x, y };
.. and the obvious for looking in that table in inter_module_get().
If object X registers data for object Y to use then X _must_ initialise
before Y. It does not matter whether the registration method is static
or dynamic, the initialisation order must be observed.
Q. With your suggested static method, what happens when Y initialises
before X, calls inter_module_get, retrieves X's static data and
starts to use it before X has initialised?
A. Oops!
The whole point of registration methods is that the owner of the data
decides when they are ready to provide the service. Ensuring that code
is initialised in the correct order, with providers starting before
consumers, is a fact of life.
I dislike the method that the kernel uses to control initialisation
order, but that is an entirely separate problem from inter_module_xxx.
What we really want at startup is a correct initialisation order. What
we have is the order that objects are selected in a Makefile which maps
to the link order of objects in vmlinux which maps to the listed order
of init routines in section .init.text which maps to initialisation
order. The mechanism is three layers away from the problem and it is
difficult to understand for many people.
It would be much nicer to define ordering sets. Code in driver foo
needs the code in driver bar to initialise first. cfi_probe cannot
initialise until cfi_cmdset_0001 and cfi_cmdset_0002 have initialised.
Declare it that way so it is clear what is going on and why, instead of
being implied by the Makefile order via three layers of indirection.
Then let the kernel build system do whatever it takes to honour the
documented initialisation order.
The problem is, Linus likes the current method.
-
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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Thu, 11 Jan 2001 12:32:10 +, David Woodhouse [EMAIL PROTECTED] wrote: I'm not suggesting that we change it drastically, only that we add the option of static (compile-time) registration for those entries which require it. So you want two services, one static for code that does not do any initialisation and one dynamic for code that does do initialisation. Can you imagine the fun when somebody adds startup code to a routine that was using static registration? Oh dear, I added init code so I have to remember to change from static to dynamic registration, and that affects the link order so now I have to tweak the Makefile. Thanks, but no thanks! Stick to one method that works for all routines, dynamic registration. If that imposes the occasional need for a couple of extra calls in some routines and for people to think about initialisation order right from the start then so be it, it is a small price to pay for long term stability and ease of maintenance. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Thu, 11 Jan 2001 13:09:13 + (GMT), Alan Cox [EMAIL PROTECTED] wrote: Stick to one method that works for all routines, dynamic registration. If that imposes the occasional need for a couple of extra calls in some routines and for people to think about initialisation order right from the start then so be it, it is a small price to pay for long term stability and ease of maintenance. What happens when we get a loop in init order because of binding and other init order conflicts? The kernel does not support circular dependencies between providers and consumers. It does not matter whether they are built into vmlinux or loaded as modules, there can be no loops in the directed graph of dependencies. It just does not make sense. A while ago there was accidentally a loop between two ppp related modules, each needed a routine in the other module. modprobe would not load them. Even if it could have loaded them, it would have been impossible to unload, both modules would have had a use count on the other. The fix was to remove the incorrect loop, it was a programming error. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Fri, 12 Jan 2001 03:12:47 +0100, Ingo Oeser [EMAIL PROTECTED] wrote: So why don't we use sth. like depmod for these issues and get the link order automagically (like we get module load order)? depmod handles dependencies on symbols. Module Y needs a symbol from module X so modprobe must load X before Y. This is a link/load problem which depmod handles fairly well. The initialisation order is a dependency on actions, not on symbols. Code F cannot start until code E has initialised so execute E before F. This should have *NOTHING* to do with link order, but it is implemented as a side effect of link ordering which confuses people. People need to realise that the problem is initialisation order, nothing more, nothing less. You have to determine and document the startup requirements for your code. Only you know what the startup pre-requisites for your code are, there is no way for another program to determine this from the source. Document your startup requirements, implement according to the documentation and your problems go away. Initialisation order is not the problem, the implementation is the problem. The method currently used to control initialisation order sucks. It is better than the original method (lots of conditional calls in main.c) but it still sucks. * Initialisation order is set by the order of structures in section .initcall.init. * The order of the structures in .initcall.init is set by the order that objects are linked into vmlinux. * The link order for vmlinux is derived from a combination of line order within a Makefile plus an overriding directory link order from the top level Makefile and parent Makefiles. * Because order is a side effect of adding a line to a Makefile, the order requirements are rarely documented. It is no wonder that people have problems getting the initialisation order correct. I want to completely remove this multi layered method for setting initialisation order and go back to basics. I want the programmer to say "initialise E and F after G, H and I". The kernel build system works out the directed graph of initialisation order then controls the execution of startup code to satisfy this graph. That still means controlling link order to achieve the required result. But with my approach the complexity would be handled by kbuild based on explicit rules which are documented in the local Makefile, instead of the complexity being handled by programmer via implicit rules scattered over several layers of Makefiles. A typical graph would have scsi disk depends on scsi host adaptor group which depends on pci. Within the scsi host adaptor group you might need to initialise one driver before another, so just declare the few inter-driver dependencies. kbuild would automatically initialise pci then the scsi host adaptors (in the correct order) then scsi disk. Most of the objects have fairly simple execution dependencies, e.g. all file systems depend on core fs code having already executed. There are no dependencies between most file systems so most file systems could initialise in any order[1] which means they could be linked in any order within the file system group. I am ready and willing to code this method, it would make kbuild a lot easier to code, as well as making future maintainence a lot easier. Linus refuses to accept this approach. He insists that kernel coders explicitly specify the link order for everything, via Makefile order[2]. As long as Linus insists on kernel coders explicitly controlling the entire link order, we are stuck with the current method. I have tried to change his mind without success. [1] vfat is one obvious exception, it needs dos first. Also the first few built in file systems must execute in a defined order because that in turn controls the probe order for mount. But this order should be explicitly declared, not as a side effect of the line order in fs/Makefile. [2] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg10520.html - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Fri, 12 Jan 2001 10:27:34 + (GMT), David Woodhouse [EMAIL PROTECTED] wrote: On Fri, 12 Jan 2001, Keith Owens wrote: A typical graph would have scsi disk depends on scsi host adaptor group which depends on pci. No. sd will happily take over any existing devices when as and when they arrive. It doesn't have to be loaded last. Likewise, in theory at least, host adaptor drivers using the new PCI driver code would respond correctly to the PCI code being initialised (and calling their -probe routine) later, although that doesn't happen now. You just proved my point. It is extremely difficult to deduce the required initialisation order by reading an undocumented Makefile where the init order is implemented as a side effect of selection order. The existing method implies link order when none is required. Most of the objects have fairly simple execution dependencies, e.g. all file systems depend on core fs code having already executed. Er... Why? They call register_filesystem() which uses a lock which is staticly initialised. Don't order stuff for the sake of it. If there are filesystems which _do_ require the VFS to be initialised first, those filesystems can be marked as such. I'm not aware of any. I was using scsi and fs as examples, no need to pick holes in the examples. But ... fs/buffer.c:module_init(bdflush_init) fs/pipe.c:module_init(init_pipe_fs) fs/fcntl.c:module_init(fasync_init) fs/locks.c:module_init(filelock_init) fs/dnotify.c:module_init(dnotify_init) I'm no filesystem expert but it appears that some of those core initialisation routines must be executed before most filesystems can start. In particular, filelock_init() must be executed before any filesystem that supports locks is initialised. All I want is a way to staticly add entries to the inter_module_xxx tables at compile time, because I _have_ done the analysis, and I'm saying that's when they should be made available. Firstly inter_module_xxx is only used by that very small subset of code where there are no constraints on whether the caller and callee can be in kernel, in modules or a mixture _and_ some of the objects are optional. It is a special case because most code handles this problem through CONFIG options. If X needs (Y, Z) and X is built into the kernel then (Y, Z) must also be built into the kernel. If Y or Z are optional then control the calls to those functions with CONFIG options. Almost all of the kernel handles it properly though CONFIG, so inter_module_xxx is already a process to handle a few special cases. Secondly you want static inter_module_xxx tables for a small subset of these special cases, where the source has no other initialisation code. This is piling special cases on special cases. Adding static inter_module_xxx tables requires * changes to linux/modules.h to define the new table format and * changes to vmlinux.lds for _every_ architecture to bring all the static tables together in vmlinux and * new initialisation code in module.c to read and load all the static tables at boot time and * extra code in modutils to find any static tables in modules and * an extension to struct modules to let modutils pass information about the static tables to the kernel and * the kernel code will only work with an upgraded modutils. That is a lot of work for a very few special cases. OTOH, you could just swap the order of 3 lines in drivers/mtd/Makefile. Guess which alternative I am going for? - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Fri, 12 Jan 2001 13:01:12 +0100, Daniel Phillips [EMAIL PROTECTED] wrote: Keith Owens wrote: I want to completely remove this multi layered method for setting initialisation order and go back to basics. I want the programmer to say "initialise E and F after G, H and I". The kernel build system works out the directed graph of initialisation order then controls the execution of startup code to satisfy this graph. I don't doubt you will come up with a workable solution at build time. However, working out a valid graph at execution time is trivial and efficient, given a list of precedence relations of the kind you're suggesting. In fact you don't even have to work out the graph before starting the initialization, it's also trivial to keep a count of unsatisfied initialization conditions at the beginning of each initialization sequence and block until the count goes to zero. (In essence, evaluate a priority sort on the fly.) It is safer to evaluate the graph at link time in case somebody mistakenly codes a dependency loop, that is an abort case. Finding that you have a loop at load time and aborting the kernel is a little too drastic for my tastes. In any case it is academic. Linus insists on link order being explicitly and completely specified by the programmer and he likes the link order being implied by Makefile order. So there is no point in working on a better system. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Fri, 12 Jan 2001 20:11:30 +0100, Christian Zander [EMAIL PROTECTED] wrote: Saying that I should have made use of this mechanism for the specific code in the Nvidia driver that we are talking about clearly shows that you didn't look at it. The module used get_module_symbol to search its own symbol table for parameters that may have been passed to it at load time. My apologies. I read the patch, not the full source code and the patch does not have enough programming context to show that the driver is only searching its own symbol space. In my own defense, the references to spinlock_t unload_lock and MOD_CAN_QUERY(mp) in the patch are highly misleading, those statements only make sense when you are looking at a symbol table for another module. When searching your own symbol table the current module must be live with a non-zero use count, not being unloaded and it can always be queried. Contrary to what you're saying, the patch does not just inline the old get_module_symbol algorithm nor does it access any of module.c's internal data. unload_lock and MOD_CAN_QUERY were copied verbatim from the old get_module_symbol, even though they are completely unnecessary. That looks like inlining the old algorithm to me. struct module_symbol, mp-nsyms and mp-syms are module.c internal data. If it is ever necessary to change those structures, nothing outside module.c, the 32/64 handlers for module system calls and modutils should be affected. Now if I change module_symbol, other bits of the kernel will unexpectedly break, this is not good. Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. Excellent comment - it is just as appropriate as it is helpful. Over emphasis for humorous effect. Must remember to add smiley. What this patch and David Woodhouse's comments show is that I need to look at a generic and safe mechanism for kernel/module symbol lookup. The existing static mechanism works for fixed symbol names but does not work for symbol names that are generated at run time nor for symbols that may or may not be present. get_module_symbol() "worked" but was horribly unsafe. It broke with module versions, it did zero type checking which left the code open to version skew and it assumed that all addresses are equivalent to an unsigned long. That last point is especially important for IA64 where function pointers do not reference the function directly, instead they point to a function descriptor with two fields, one of which is the function address. Casting the unsigned long address of a function into a function pointer fails miserably on IA64, and gcc does not even give any warnings. foo = (int (*)(int))get_module_symbol(NULL, "funcname") is architecture dependent. Using EXPORT_SYMBOL_NOVERS() to "fix" the modversions problem for get_module_symbol() removes all inter module checks on the relevant symbols. Not just for the caller of get_module_symbol for all modules that access those symbols. This leaves too much code open to version skew and is not acceptable. inter_module_xxx is modversions safe. It still does no type checking because it uses void * for the data structure, but the exporter and user have to declare their common data area which reduces the chance of version skew. I am still not happy about this possibility of skew but anything is better than no checks at all. Passing a data structure which contains real declarations for function pointers instead of assuming you can cast a number to a function pointer makes inter_module_xxx architecture independent. I will look at a general kernel and module symbol lookup routine that does the job properly. The hard part is making sure that the provider and consumer have exactly the same types for a symbol. Both get_module_symbol and inter_module_xxx completely bypass the modversions checks and are wide open to undetectable version skew, although inter_module_xxx is a little bit safer. Any replacement for these functions must be able to do type checking at run time, which probably means it is 2.5 code. And yes, David, it should be able to handle static data. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Sat, 13 Jan 2001 10:46:44 + (GMT),
David Woodhouse [EMAIL PROTECTED] wrote:
On Sat, 13 Jan 2001, Keith Owens wrote:
Actually, my testing showed that modutils was quite OK with symbols which
may or may not be present. But compiling such code into the kernel, at
least on MIPS and m68k, didn't work.
Weak symbols were added to gcc somewhere between 2.7.2.3 and 2.91.66.
At least two architectures are using versions of gcc that predate (by a
few days) the addition of weak symbols. Davem hit this problem on
sparc with the weak references to kallsyms, he had to define the
symbols instead of letting them resolve to zero, gcc on sparc silently
ignored weak.
I doubt this would have implemented weak symbols completely, though.
Fixing up the reference in weaktest.o if myfun.o was loaded later, etc.
And we don't really want to 'fix' that either.
Weak is not enough. We need dynamic symbol binding if we plan to
support a cooperative model for objects instead of a strict hierarchic
model.
BTW, modutils cannot automatically fill in upward references when a
module is loaded. A reference is a use count, an automatic reference
would be an automatic use count with no way of removing it. Code that
calls upwards to a symbol must perform an overt action to get the
reference and cope with the case when the symbol is not there. Think
of it as a probe, "do I have facility XXX yet?". It is up to the
caller to probe as often as required. Hot plugging for symbols, wheee!
That last point is especially important for IA64 where function
pointers do not reference the function directly, instead they point to
a function descriptor with two fields, one of which is the function
address. Casting the unsigned long address of a function into a
function pointer fails miserably on IA64, and gcc does not even give
any warnings. foo = (int (*)(int))get_module_symbol(NULL, "funcname")
is architecture dependent.
But fixable.
Probably not. The generated IA64 object code for this case is
completely wrong, not surprising since we are lying to gcc.
x.o: file format elf64-ia64-little
Disassembly of section .text:
test1:
unsigned long value = 0xc0002000; // example, not a real ia64 address
void test1(void)
{
0: [MII] alloc r34=ar.pfs,4,4,0
void (*test2)(void);
6: mov r35=r12 // test2
c: adds r12=-16,r12 // adjust stack pointer
10: [MII] nop.m 0x0
test2 = (void (*)(void))value;
16: mov r33=b0 // save return address
12: GPREL22 value
1c: addl r14=0,r1;; // value
20: [MMI] ld8 r14=[r14];; // value
26: st8 [r35]=r14// test2 = value 0xc0002000
2c: nop.i 0x0
test2();
30: [MII] ld8 r14=[r35]// read test2, 0xc0002000
36: mov r32=r1;; // save current global pointer
3c: nop.i 0x0
40: [MII] ld8 r15=[r14]// dereference test2, wrong
46: adds r14=8,r14;; // test2 + 8, 0xc0002008
4c: nop.i 0x0
50: [MII] ld8 r1=[r14] // new gp from 0xc0002008, wrong
56: mov b6=r15;; // target function, wrong
5c: nop.i 0x0
60: [MIB] nop.m 0x0
66: nop.i 0x0
6c: br.call.sptk.many b0=b6;; // call indirect function, oops
70: [MII] mov r1=r32 // restore gp
By casting 'test2 = (void (*)(void))value' we claim that value is the
address of the the function descriptor which must contain
{ actual address of function, global data pointer for function }
gcc trusts us and tries to use the data at location 0xc0002000 as a
function descriptor. Because get_module_symbol() returns the address
of the first instruction in a function, that code would load the actual
address and global pointer from the first 16 bytes of the function's
code area. Needless to say, it does not work.
Fixing this would mean tweaking get_module_symbol() on IA64 to
recognise that the symbol is a function, build a function descriptor on
the fly and return the address of the descriptor. But the information
about the types of symbols is not available in the kernel nor in
modules after they are loaded, get_module_symbol() cannot differentiate
between functions and anything else. There is also the small matter of
grubbing around in the arch dependent bit of struct modules to find the
global pointer for the target function, more complexity.
But what about keeping a separate table, with PUBLISH_SYMBOL() or
something slightly more sensibly named? That way, get_published_symbol()
can only get at those symbols which were supposed to be listed, and if
Re: Where did vm_operations_struct-unmap in 2.4.0 go?
On Sat, 13 Jan 2001 12:46:00 +0100,
Christian Zander [EMAIL PROTECTED] wrote:
I see what you mean. What do you suggest should be done in the context of
the driver? As you can easily tell, I'm not overly familiar with the
internal workings of the kernel. That and the mere impossibility to get
any kind of help at the mere mention of the Nvidia driver module ("go bitch
at nvidia", "who cares", ...) do not exactly make it easier to fix problems
that arise from changes to the kernel.
Hmm, can I charge Nvidia for this fix?
The only reason you are looking at symbols is to map Nvidia registry
names to module symbols. There are 9 registry names, 4 of which are
#ifdeffed out.
MODULE_PARM(NVreg_resman_debuglevel, "i");
MODULE_PARM(NVreg_VideoMemoryTypeOverride, "i");#ifdeffed out
MODULE_PARM(NVreg_EnableVia4x, "i");
MODULE_PARM(NVreg_ReqAGPRate, "i"); #ifdeffed out
MODULE_PARM(NVreg_SkipBiosPost, "i"); #ifdeffed out
MODULE_PARM(NVreg_UseKernelAGP, "i");
MODULE_PARM(NVreg_UpdateKernelAGP, "i");#ifdeffed out
MODULE_PARM(NVreg_ReqAGPSBA, "i");
MODULE_PARM(NVreg_ReqAGPFW, "i");
Simple fix is an array to map names to addresses.
struct {
const char *name;
int *value;
} linux_registry[] = {
{ "resman_debuglevel", NVreg_resman_debuglevel },
{ "EnableVia4x",NVreg_EnableVia4x },
{ "UseKernelAGP", NVreg_UseKernelAGP },
{ "ReqAGPSBA", NVreg_ReqAGPSBA },
{ "ReqAGPFW", NVreg_ReqAGPFW },
};
Changing osRegistryLookup to scan that array for the registry name and
return the address of the corresponding variable is left as an exercise
for the reader.
-
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.1pre3 compile problems
On Sat, 13 Jan 2001 07:33:47 -0400, "Garst R. Reese" [EMAIL PROTECTED] wrote: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-DEXPORT_SYMTAB -c ksyms.c In file included from /usr/src/linux/include/linux/modversions.h:93, from /usr/src/linux/include/linux/module.h:21, from ksyms.c:14: /usr/src/linux/include/linux/modules/i386_ksyms.ver:76: warning: `cpu_data' redefined cd /usr/src/linux/kernel gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes \ -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe \ -mpreferred-stack-boundary=2 -march=i586 \ -DEXPORT_SYMTAB -c ksyms.c -E /var/tmp/ksyms.i Compress /var/tmp/ksyms.i and mail it to me (not the list). - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Sat, 13 Jan 2001 15:09:40 + (GMT), David Woodhouse [EMAIL PROTECTED] wrote: Lack of [module symbol] runtime typechecking isn't a showstopper. It is when users try to insert modules from kernel A into kernel B when the ABI changed between A and B. This is not type checking to catch kernel programmers, it is ABI checking to catch user errors. This is becoming more important as the kernel moves towards hot plugging devices, especially for binary only drivers. It is far better for the kernel community if modutils can say "cannot load module foo because its interfaces do not match the kernel, upgrade module foo". That forces the maintenance load back onto the binary supplier and removes the questions from l-k, including many of the oops reports with binary only drivers in the module list. Module symbol versions are the only way to catch ABI changes. I do not want to add a mechanism for accessing symbols dynamically if it cannot detect ABI changes, it leaves the kernel open to difficult to diagnose user errors. I'm doing the hard work now to save everybody time later. Ignore the fact that the existing module symbol version implementation is broken as designed. http://gear.torque.net/kbuild/archive/1280.html lists the major problems with make dep, genksyms has all those problems plus several of its own. As part of the Makefile rewrite for 2.5, I am redesigning module symbol versions from scratch. I agree that inter_module_xxx does not check ABI. That was not for lack of trying, but it cannot be done in 2.4, it needs a major redesign of module symbols and the makefiles. It will be possible in 2.5. - 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: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9
On Sat, 13 Jan 2001 16:12:13 -0500 (EST),
Werner Puschitz [EMAIL PROTECTED] wrote:
Is there a safe way to add debug information like simple string prints in
arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
so that I can see at the console where the boot process hangs?
Time for another version of my VIDEO_CHAR patch.
-
If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output. There is a technique for using the video display to indicate
boot progress so you can localize the problem. Reporting "my kernel
hangs during boot at line nnn in routine xyz" is a lot better than "my
kernel hangs during boot".
The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR. This macro takes a character
position and a single character value to be displayed. Use different
positions on the screen for different levels of code and use different
characters in one position to indicate which stage that level is up to.
For example, with the patch below, the string EAC at hang indicates
parse_options(), checksetup().
The patch below is generic, except for the definition of VIDEO_CHAR
which is ix86 specific. If this patch ever becomes part of the main
kernel then VIDEO_CHAR needs to be moved to an arch specific header.
If any arch other than ix86 uses this technique, please mail
[EMAIL PROTECTED] with your definition of VIDEO_CHAR.
You can plant VIDEO_CHAR calls anywhere you like, up to the call to
mem_init(). After mem_init has done its work and memory has been
remapped, VIDEO_CHAR cannot write to video memory, it will oops.
However by then the console has been initialized so you can use printk.
Demonstration patch against 2.4.0. This only uses screen positions 0,
1, 2. If you want to drill down into lower level routines, just use
screen positions 3 onwards. To activate the debugging, add
#define DEBUG_VIDEO_CHAR
to the start of init/main.c.
Index: 0.1/init/main.c
--- 0.1/init/main.c Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/k/11_main.c 1.1
644)
+++ 0.1(w)/init/main.c Sun, 14 Jan 2001 11:27:20 +1100 kaos (linux-2.4/k/11_main.c 1.1
+644)
@@ -77,6 +77,13 @@ extern int con3215_activate(void);
#error Sorry, your GCC is too old. It builds incorrect kernels.
#endif
+#ifdef DEBUG_VIDEO_CHAR
+/* ix86 specific */
+#define VIDEO_CHAR(c, v) (*((volatile char *)(0xb8000 + 2*(c))) = (v))
+#else
+#define VIDEO_CHAR(c, v)
+#endif
+
extern char _stext, _etext;
extern char *linux_banner;
@@ -432,12 +439,14 @@ static void __init parse_options(char *l
char *next,*quote;
int args, envs;
+ VIDEO_CHAR(1, 'A');
if (!*line)
return;
args = 0;
envs = 1; /* TERM is set to 'linux' by default */
next = line;
while ((line = next) != NULL) {
+ VIDEO_CHAR(2, 'A');
quote = strchr(line,'"');
next = strchr(line, ' ');
while (next != NULL quote != NULL quote next) {
@@ -450,9 +459,11 @@ static void __init parse_options(char *l
next = strchr(next+1, ' ');
}
}
+ VIDEO_CHAR(2, 'B');
if (next != NULL)
*next++ = 0;
if (!strncmp(line,"init=",5)) {
+ VIDEO_CHAR(3, 'A');
line += 5;
execute_command = line;
/* In case LILO is going to boot us with default command line,
@@ -463,8 +474,10 @@ static void __init parse_options(char *l
args = 0;
continue;
}
+ VIDEO_CHAR(2, 'C');
if (checksetup(line))
continue;
+ VIDEO_CHAR(2, 'D');
/*
* Then check if it's an environment variable or
@@ -480,9 +493,12 @@ static void __init parse_options(char *l
if (*line)
argv_init[++args] = line;
}
+ VIDEO_CHAR(2, 'E');
}
+ VIDEO_CHAR(1, 'B');
argv_init[args+1] = NULL;
envp_init[envs+1] = NULL;
+ VIDEO_CHAR(1, 'C');
}
@@ -526,16 +542,27 @@ asmlinkage void __init start_kernel(void
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
+ VIDEO_CHAR(0, 'A');
lock_kernel();
+ VIDEO_CHAR(0, 'B');
printk(linux_banner);
+ VIDEO_CHAR(0, 'C');
setup_arch(command_line);
+ VIDEO_CHAR(0, 'D');
printk("Kernel command line: %s\n", saved_command_line);
+ VIDEO_CHAR(0, 'E');
parse_options(command_line);
+ VIDEO_CHAR(0, 'F');
trap_init();
+ VIDEO_CHAR(0, 'G');
init_IRQ();
+ VIDEO_CHAR(0, 'H');
sched_init();
Re: Where did vm_operations_struct-unmap in 2.4.0 go?
On Sun, 14 Jan 2001 09:43:21 + (GMT), David Woodhouse [EMAIL PROTECTED] wrote: On Sun, 14 Jan 2001, Keith Owens wrote: That forces the maintenance load back onto the binary supplier and removes the questions from l-k, including many of the oops reports with binary only drivers in the module list. No. The correct response to that is _already_ "You have a binary-only module. Even in the kernel it was compiled against, you are not supported. Goodbye". I wish that Linus had never agreed to binary only modules. But as long as they are allowed, I want to detect problems with binary only modules before they hit the rest of the kernel and end up as questions on l-k. Note I said allowed, not supported. I refuse to support any binary only modules, my standard response to problems logged against binary modules is "remove them and reproduce the problem". Checking for ABI violations is not supporting binary modules, it is detecting that they are stuffed and telling the user to go pester their supplier instead of polluting l-k with questions that will be ignored. - 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: Where did vm_operations_struct-unmap in 2.4.0 go?
On Sun, 14 Jan 2001 13:47:29 -0800 (PST), Linus Torvalds [EMAIL PROTECTED] wrote: On Sun, 14 Jan 2001, David Woodhouse wrote: That's the one flaw in the inter_module_get() stuff - we could do with a way to put entries in the table at _compile_ time, rather than _only_ at run time. Ok, I can buy that. Not having to initialize explicitly would be nice, but if so we should make module loading do it automatically too ... It might be nice but it is also expensive. Adding static inter_module_xxx tables requires * changes to linux/modules.h to define the new table format and * changes to vmlinux.lds for _every_ architecture to bring all the static tables together in vmlinux and * new initialisation code in module.c to read and load all the static tables at boot time and * extra code in modutils to find any static tables in modules and * an extension to struct modules to let modutils pass information about the static tables to the kernel and * the kernel code will only work with an upgraded modutils. That is a lot of work for a very few special cases. OTOH, you could just add a few lines of __initcall code in two source files (which I did when I wrote inter_module_xxx) and swap the order of 3 lines in drivers/mtd/Makefile. Guess which alternative I am going for? IMHO any automatic method that relies on ELF sections and/or modutils support is the wrong approach, it is a complex solution with external dependencies when we already have a simple solution with no external dependencies. What next, static tables for file system registration, for device registration? - 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 4GB memory setting in 2.4.0 stable
On Mon, 15 Jan 2001 20:09:14 -0200 (BRST),
Marcelo Tosatti [EMAIL PROTECTED] wrote:
On Tue, 16 Jan 2001, Rainer Mager wrote:
EIP; f889e044 END_OF_CODE+385bfe34/ =
Trace; f889d966 END_OF_CODE+385bf756/
It seems the oops is happening in a module's function.
You have to make ksymoops parse the oops output against a System.map which
has all modules symbols. Load each module by hand with the insmod -m
option ("insmod -m module.o") and _append_ the outputs to System.map.
No need, just create directory /var/log/ksymoops. insmod and rmmod
will automatically save the list of modules and the symbol table on
every module load or unload, neatly timestamped. When you get an oops,
find the entries just before the oops and point ksymoops at those.
ksymoops -m /lib/modules/2.4.0/System.map \
-k /var/log/ksymoops/20010116093850.ksyms \
-l /var/log/ksymoops/20010116093850.modules oops.txt
man insmod, section KSYMOOPS ASSISTANCE. Much easier than trying to
reproduce the environment by hand.
-
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: Pass module parameters to built-in drivers
On Sun, 21 Jan 2001 15:54:56 +1100, David Luyer [EMAIL PROTECTED] wrote: Here's a proposed v2.4 "quick fix" to allow specifying "module parameters" to any of the many drivers without option parsers when built in to the kernel. Fundamental problem: you assume that each module is built from a source of the same name, this is not true. For example, scsi_mod is built from several objects, including scsi.c and scsi_scan.c which contain MODULE_PARM. With your patch the user has to do scsi.c:scsihosts="..." scsi_scan.c:max_scsi_luns=n (built in) or options scsi_mod scsihosts="..." max_scsi_luns=n (module) Inconsistent methods for setting the same parameter are bad. I can and will do this cleanly in 2.5. Parameters will be always be keyed by the module name, even if they are compiled in. Adding an inconsistent method to 2.4 then changing to a correct method in 2.5 is a bad idea, wait until we can do it right. - 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: krnl newbie: problems with EXPORT_SYMBOL()
On Wed, 17 Jan 2001 19:18:40 +0100 (MET), Michael Palme [EMAIL PROTECTED] wrote: ive got a problem with the EXPORT_SYMBOL() macro. d801e0dc symbol_exported_R__symbol_exported FAQ alert! http://www.tux.org/lkml/#s8-8 - 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: Pass module parameters to built-in drivers
On Mon, 22 Jan 2001 21:55:23 + (GMT), Russell King [EMAIL PROTECTED] wrote: Hmm, don't we already have all that __setup() stuff laying around? Ok, it might not be built into the .o for modules, but it could be. Could we not do something along the lines of: 1. User passes parameters on the kernel command line. 2. modprobe reads the kernel command line and sorts out those that correspond to the __setup() stuff in the module being loaded. 3. modprobe combines in any extra settings from /etc/modules.conf IIRC, this would satisfy the original posters intentions, presumably without too much hastle? Apart from the fact that it is completely backwards from the original intent. The problem is objects that have MODULE_PARM but no __setup. - 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/
Announce: modutils 2.4.2 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://ftp.country.kernel.org/pub/linux/utils/kernel/modutils/v2.4 modutils-2.4.2.tar.gz Source tarball, includes RPM spec file modutils-2.4.2-1.src.rpmAs above, in SRPM format modutils-2.4.2-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 patch-modutils-2.4.2.gz Patch from modutils 2.4.0 to 2.4.2. Sparc and IA64 binaries to follow. Related kernel patches. patch-2.4.0-persistent.gz Adds persistent data and generic string support to kernel 2.4.0. Optional. Changelog extract * genksym changes: Remove 'attribute' as a C keyword, add 'restrict', '__restrict', '__restrict__', '_Bool'. Thanks to Richard Henderson. * Log modprobe commands in /var/log/ksymoops. This one's for Wichert. * Revert to a single USB table format. USB maintainers will not support anybody on 2.4.0-prerelease or earlier. This version of modutils is being released under protest. It completely drops support for USB device ids on kernel 2.4.0-prerelease and earlier. If you are running a kernel before 2.4.0 and you still want depmod support for USB tables on that earlier kernel, DO NOT install modutils 2.4.2. If you are switching between 2.4.0 and earlier kernels and you want USB support on old and new kernels then you have to switch versions of modutils when you switch your kernel. Breaking backwards compatibility goes completely against the grain for modutils. It goes to a lot of bother to support users on older kernels and to ensure that any mix of new modutils and old kernels will work, even down to kernel 2.0. The USB maintainers are refusing to support USB on anything older than 2.4.0, without that support Linus will not take my kernel patch that maintains backwards compatibility. So I have no choice but to break backwards compatibility. If you applied my kernel patch patch-2.4.0-hotplug, remove it and reboot after installing modutils 2.4.2. Note to distributors. The genksyms change corrects a bug which caused semi-random symbol checksums, changing the order of include statements could change the checksum. As a side effect of the fix, modules compiled with symbol versions using genksyms 2.4.2 may not match a kernel compiled with genksyms = 2.4.2 and vice versa. This correction should only affect binary only modules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE6bWePi4UHNye0ZOoRAnMsAKDhHRNwFo7sdo0GKcFewM9cXd+gWACfTib5 r3yo+Gv3yDedJCMdkbA4CH0= =Krng -END PGP SIGNATURE- - 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-ac10 compile errors
On Tue, 23 Jan 2001 10:48:14 +, Anders Karlsson [EMAIL PROTECTED] wrote: The procedure I have gone through to compile the kernel are as follows: a) Copy the .config file safe b) Remove the previous kernel tree c) Extract the pristine 2.4.0 kernel tree d) Apply the 2.4.0-ac10 patch make mrproper here e) Copy the .config in to the new /usr/src/linux tree f) make oldconfig g) make dep h) make bzImage - 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-ac10 compile errors
On Tue, 23 Jan 2001 12:16:11 +, Anders Karlsson [EMAIL PROTECTED] wrote: Even if it is a pristine kernel tree? What function does the 'make mrproper' fill on an unused kernel tree? Depends on how you removed the old tree. If you did 'rm -rf *' then some dot files are left around. make mrproper removes dot files, it may or may not be the fix. - 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: stripping symbols from modules
On Tue, 23 Jan 2001 17:34:15 -0500, "MEHTA,HIREN (A-SanJose,ex1)" [EMAIL PROTECTED] wrote: Is there any way to strip symbols from modules .o files ? Not safely. Some symbols must be kept to assist insmod and hot plugging, strip does not know about these special symbols. Why do you need to strip modules anyway? I don't see the point unless you are critically low on disk space. Stripping the symbols makes it much harder to debug oops in modules, ksymoops needs all the symbols. - 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: stripping symbols from modules
On Tue, 23 Jan 2001 16:15:24 -0700,
[EMAIL PROTECTED] wrote:
That is what I was guessing. But insmod does not need all symbols
present in the .o.
I need to do this because when I release the driver to the customer,
I don't want them to be aware of some of the symbols. I understand
that this is against the open source policy. But that's how it is
and it is beyond my control. Is there any way to export only
selected symbols as required by insmod ? As of now I am not worried
about ksymoops.
I used this script back in the dim distant days when emergency boot
systems had to fit on floppies. Not tested since 1998, YMMV. At the
very least it needs to be updated to keep MODULE_GENERIC_TABLE()
symbols.
#!/bin/sh
#
# Given a list of objects, strip all static symbols except those
# required by insmod.
#
# Copyright Keith Owens [EMAIL PROTECTED]. GPL.
# Sat Feb 1 12:52:17 EST 1997
#
# Mainly intended for reducing the size of modules to save space
# on emergency and install disks. Be aware that removing the
# static symbols reduces the amount of diagnostic information
# available for oops. Not recommended for normal module usage.
#
# This code requires the modules use MODULE_PARM and EXPORT_.
# Do not strip modules that have not been converted to use
# MODULE_PARM or are using the old method of exporting symbols.
# In particular do not use on modules prior to 2.1.20 (approx).
#
# The objects are stripped in /tmp, only if the strip works is
# the original overwritten. If the command line to strip the
# symbols becomes too long, the strip is done in multiple passes.
# Running strip_module twice on the same object is safe (and a
# waste of time).
#
cat /tmp/$$.awk \EOF
BEGIN {
strip = "/usr/bin/objcopy";
nm = "/usr/bin/nm";
cp = "/bin/cp";
mv = "/bin/mv";
rm = "/bin/rm";
tmp = "/tmp";
command_size = 400; # arbitrary but safe
getline "/proc/self/stat";
pid = $1;
tmpcopy = tmp "/" pid ".object";
nmout = tmp "/" pid ".nmout";
for (i = 1; i ARGC; ++i)
strip_module(ARGV[i]);
do_command(rm " -f " tmpcopy " " nmout);
exit(0);
}
function strip_module(object,
keep_symbol, to_strip, symbol, command, changed) {
do_command(cp " -a " object " " tmpcopy);
do_command(nm " " tmpcopy " " nmout);
# delete array_name sometimes breaks, internal error, play safe
for (symbol in keep_symbol)
delete keep_symbol[symbol];
for (symbol in to_strip)
delete to_strip[symbol];
new_module_format = 0;
while ((getline nmout) 0) {
$0 = substr($0, 10);
# b static variable, uninitialised
# d static variable, initialised
# r static array, initialised
# t static label/procedures
if ($1 ~ /[bdrt]/)
to_strip[$2] = "";
else if ($1 != "?")
keep_symbol[$2] = "";
else if ($0 ~ /\? __ksymtab_/)
keep_symbol[substr($2, 11)] = "";
else if ($0 ~ /\? __module_parm_/)
keep_symbol[substr($2, 15)] = "";
if ($0 ~ /\? __module/)
new_module_format = 1;
}
close(nmout);
command = "";
changed = 0;
if (new_module_format) {
for (symbol in to_strip) {
if (!(symbol in keep_symbol)) {
changed = 1;
if (length(command) command_size) {
do_command(strip command " " tmpcopy);
command = "";
}
command = command " --strip-symbol=" symbol;
}
}
}
if (command != "") {
changed = 1;
do_command(strip command " " tmpcopy);
}
if (changed)
do_command(mv " " tmpcopy " " object);
}
function do_command(command) {
if ((ret = system(command)) != 0)
giveup("command \"" command "\" failed " ret, ret);
}
function giveup(message, ret) {
print "strip_module: " message "/dev/stderr";
exit(ret);
}
EOF
awk -f /tmp/$$.awk "$@"
ret=$?
rm -f /tmp/$$.awk
exit $ret
-
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: Pass module parameters to built-in drivers
On Wed, 24 Jan 2001 08:32:35 -0500,
Paul Gortmaker [EMAIL PROTECTED] wrote:
I'm curious as to what boot argument equivalent you envision for e.g.
options ne io=0x280,0x300 irq=10,12 bad=0,1
ne.io=0x280,0x300 ne.irq=10,12 ne.bad=0,1. I might even be generous
and handle ne{io=0x280,0x300 irq=10,12 bad=0,1}
If a parameter name is unique amongst all compiled in objects then it
does not need the object/module name, although it is recommended.
-
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: pcmcia modules install path
On Thu, 25 Jan 2001 00:59:07 +0100, "J . A . Magallon" [EMAIL PROTECTED] wrote: Just a silly question. The pcmcia modules in 2.4.x get installed in /lib/modules/`uname -r`/pcmcia, instead of /lib/modules/`uname -r`/kernel/whatever Is there any special reason for that or is just a harmelss buglet ? Deliberate. Old versions of pcmcia-cs used a hard coded insmod from /lib/modules/`uname -r`/pcmcia. Newer versions use modprobe and do not care where the module is stored. The pcmcia directory is a migration aid and will disappear after kernel 2.4.1. All entries under pcmcia should be symlinks anyway. - 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: Linux 2.4.0ac12
On Fri, 26 Jan 2001 17:46:12 -0800 (PST), "Sergey Kubushin" [EMAIL PROTECTED] wrote: Modules still don't load: === Cut === ide-mod.o: Can't handle sections of type 32131 ide-probe-mod.o: Can't handle sections of type 256950710 ide-disk.o: Can't handle sections of type 688840897 ext2.o: Can't handle sections of type 69429248 === Cut === Works for me. # uname -a Linux ocs4 2.4.0-ac12 #1 SMP Sat Jan 27 17:37:12 EST 2001 i686 unknown # lsmod Module Size Used by binfmt_misc 3696 0 nfsd 71632 0 (autoclean) vfat 11504 1 fat32448 0 [vfat] af_packet 8720 0 (unused) isofs 19216 0 (unused) sg 26752 0 (unused) loop7680 0 (unused) nfs82720 0 (unused) lockd 50416 0 [nfsd nfs] sunrpc 62464 0 [nfsd nfs lockd] tulip 37232 1 # insmod -V 21 | head -1 insmod version 2.4.2 # gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) # ld -v GNU ld version 2.9.5 (with BFD 2.9.5.0.22) - 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: Linux 2.4.0ac12
--- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens [EMAIL PROTECTED] To: Peter Kaczuba [EMAIL PROTECTED] cc: "Sergey Kubushin" [EMAIL PROTECTED] Subject: Re: Linux 2.4.0ac12 In-reply-to: Your message of "Sat, 27 Jan 2001 12:06:57 BST." [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 2001 22:25:02 +1100 Message-ID: [EMAIL PROTECTED] On Sat, 27 Jan 2001 12:06:57 +0100, Peter Kaczuba [EMAIL PROTECTED] wrote: On 2001-01-27 1:46:12 "Sergey Kubushin" [EMAIL PROTECTED] wrote: Modules still don't load: === Cut === ide-mod.o: Can't handle sections of type 32131 ide-probe-mod.o: Can't handle sections of type 256950710 ide-disk.o: Can't handle sections of type 688840897 ext2.o: Can't handle sections of type 69429248 === Cut === Could anybody seeing this problem please pick a small object that is failing and mail it to [EMAIL PROTECTED] - not to linux-kernel. gzipped and uuencoded preferred, I will take MIME if you have no other option. I also need to know the versions of modutils, gcc and binutils that you are running. --- End of Blind-Carbon-Copy - 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: Knowing what options a kernel was compiled with
On Sat, 27 Jan 2001 22:21:41 -0700, Jacob Anawalt [EMAIL PROTECTED] wrote: Is there a way to know what options a running kernel was compiled with, if you dont have access to the source or configure files it was compiled off of? No. You have to insist that whoever distributes the kernel binary also distributes the .config file that it was compiled with. Don't bother arguing that the kernel should record this info, it has been discussed before and rejected. This is a problem for the distributors, not for the kernel. - 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: Knowing what options a kernel was compiled with
On Sun, 28 Jan 2001 00:13:48 -0500, "Matthew Pitts" [EMAIL PROTECTED] wrote: Some distributions DO include the config. It may be located in the /boot dir with a name CONFIG-2.2.10 or similar. I know that Caldera 2.3 shiped that way(2.4 may also). If you have the install CDROM, the kernel source install may have it (e.g. Linux-Mandrake 7.x). I know that some distributions ship .config but not all do. A long way down on my TODO list is "submit a requirement to FHS that .config, System.map and other kernel related text files must be shipped in directory foo". I would like foo to be /lib/modules/`uname -r` since that directory is already kernel specific, but we have to handle kernels without modules and disks with restricted size in /lib. However that discussion is best held on the FHS/LSB lists, not l-k. - 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/
Ram disk problems in 2.4.0ac12
On Fri, 26 Jan 2001 17:46:12 -0800 (PST), "Sergey Kubushin" [EMAIL PROTECTED] wrote: Modules still don't load: === Cut === ide-mod.o: Can't handle sections of type 32131 ide-probe-mod.o: Can't handle sections of type 256950710 ide-disk.o: Can't handle sections of type 688840897 ext2.o: Can't handle sections of type 69429248 === Cut === modutils has been ruled out as the cause of this problem. The objects are valid but when they are loaded they come up as corrupt. Modules work fine for me on 2.4.0-ac12, when they are loaded from disk. Both people reporting this bug are using initrd so the obvious culprit is the ram disk code. - 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: problem exporting symbols from a lkm
On Sun, 28 Jan 2001 19:16:06 +0100, SR (c) 2000 [EMAIL PROTECTED] wrote: my /proc/ksyms shows that the exported symbols from 8390.o are different from the other symbols because they have "_R__ver_" in front of them. FAQ http://www.tux.org/lkml/#s8-8 - 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] 2.4.1-pre11 remove pcmcia compatibility from Makefile
The _modinst_post_pcmcia target was added to Makefile in 2.4.0-test6-pre3,
August 5 2000. It was a compatibility aid until people upgraded to a
version of pcmcia-cs that used modprobe instead of insmod. Five months
later, it is time to remove _modinst_post_pcmcia.
Linus, please apply at any convenient time, no hurry.
Index: 1-pre11.1/Makefile
--- 1-pre11.1/Makefile Mon, 29 Jan 2001 10:00:50 +1100 kaos (linux-2.4/T/c/50_Makefile
1.1.2.10 644)
+++ 1-pre11.1(w)/Makefile Mon, 29 Jan 2001 17:10:07 +1100 kaos
+(linux-2.4/T/c/50_Makefile 1.1.2.10 644)
@@ -372,17 +372,8 @@ else
depmod_opts:= -b $(INSTALL_MOD_PATH) -r
endif
.PHONY: _modinst_post
-_modinst_post: _modinst_post_pcmcia
+_modinst_post:
if [ -r System.map ]; then $(DEPMOD) -ae -F System.map $(depmod_opts)
$(KERNELRELEASE); fi
-
-# Backwards compatibilty symlinks for people still using old versions
-# of pcmcia-cs with hard coded pathnames on insmod. Remove
-# _modinst_post_pcmcia for kernel 2.4.1.
-.PHONY: _modinst_post_pcmcia
-_modinst_post_pcmcia:
- cd $(MODLIB); \
- mkdir -p pcmcia; \
- find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
.PHONY: $(patsubst %, _modinst_%, $(SUBDIRS))
$(patsubst %, _modinst_%, $(SUBDIRS)) :
-
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: Knowing what options a kernel was compiled with
On Mon, 29 Jan 2001 12:41:31 -0800, Torrey Hoffman [EMAIL PROTECTED] wrote: Should someone submit a patch to copy the .config to a standard location as part of "make install" or "make modules_install"? If included in the official sources, that good example would encourage the distribution maintainers do the same. Not until FHS decide what that standard location is. An entry in FHS will carry far more weight with distributors than a kernel Makefile patch. - 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.2.18: apm initialised before dmi_scan?
On Tue, 30 Jan 2001 22:47:02 +1100 (EST), Neale Banks [EMAIL PROTECTED] wrote: Looking more closely at a 2.2.18 bootup tonight I see that apm stuff appears in dmesg before dmi_scan does (I added "#define DUMP_DMI" in dmi_scan.c). If this implies that apm is initialised *before* the dmi_scan then there is potentially a problem with buggy BIOSen that oops instead of reporting power status This should fix the link order, at the (small) expense of compiling dmi_scan for exported symbols, even though it does not really export symbols. Against 2.2.18. Index: 18.1/arch/i386/kernel/Makefile --- 18.1/arch/i386/kernel/Makefile Thu, 23 Nov 2000 11:48:07 +1100 kaos (linux-2.2/E/b/40_Makefile 1.1.4.4 644) +++ 18.2(w)/arch/i386/kernel/Makefile Tue, 30 Jan 2001 23:47:17 +1100 kaos +(linux-2.2/E/b/40_Makefile 1.1.4.4 644) @@ -15,8 +15,8 @@ all: kernel.o head.o init_task.o O_TARGET := kernel.o O_OBJS := process.o signal.o entry.o traps.o irq.o vm86.o \ ptrace.o ioport.o ldt.o setup.o time.o sys_i386.o \ - bluesmoke.o dmi_scan.o -OX_OBJS := i386_ksyms.o + bluesmoke.o +OX_OBJS := i386_ksyms.o dmi_scan.o MX_OBJS := ifdef CONFIG_PCI - 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: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001 16:45:16 -0500 (EST), "Richard B. Johnson" [EMAIL PROTECTED] wrote: The subject says it all. `make dep` is now broken. make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' Makefile:29: *** target pattern contains no `%'. Stop. Which version of make are you running? - 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: unresolved symbol in 2.4.1 depmod.
On Tue, 30 Jan 2001 14:15:20 -0600 (CST), Jason Michaelson [EMAIL PROTECTED] wrote: Greetings. I've just procured myself a copy of 2.4.1, and tried to build it. At the tail end of a make modules_install, the following error occurs: depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/md/md.o depmod: name_to_kdev_t name_to_kdev_t is defined in init/main.c. It is not exported so it cannot be called from modules. name_to_kdev_t *cannot* be exported because it is defined as __init, the code has gone by the time the module is loaded. Ask the md maintainer for a fix. - 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 -- Unresolved symbols in radio-miropcm20.o
On Tue, 30 Jan 2001 13:08:12 -0800, Miles Lane [EMAIL PROTECTED] wrote: depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/media/radio/radio-miropcm20.o depmod:aci_write_cmd depmod:aci_indexed_cmd depmod:aci_write_cmd_d Those symbols are defined in drivers/sound/aci.c but are not exported for other modules to use. The aci and miropcm20 code needs to be changed to support use as modules. Also the config.in files need fixing for these files, it is possible to select combinations of aci and miropcm20 that will fail to link (miropcm20 built in, aci not selected or selected as a module) or fail to load (miropcm20 selected as a module, aci not selected). - 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: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001 17:57:44 -0500 (EST), "Richard B. Johnson" [EMAIL PROTECTED] wrote: On Wed, 31 Jan 2001, Keith Owens wrote: On Tue, 30 Jan 2001 16:45:16 -0500 (EST), "Richard B. Johnson" [EMAIL PROTECTED] wrote: The subject says it all. `make dep` is now broken. make[4]: Entering directory `/usr/src/linux-2.4.1/drivers/acpi' Makefile:29: *** target pattern contains no `%'. Stop. Which version of make are you running? 3.74 y'a mean even make isn't make anymore? You mean that nobody reads Documentation/Changes any more? Current Minimal Requirements o Gnu make 3.77# make --version PEBCAK. - 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: Version 2.4.1 cannot be built.
On Tue, 30 Jan 2001 18:09:48 -0500 (EST), "Richard B. Johnson" [EMAIL PROTECTED] wrote: On Wed, 31 Jan 2001, Keith Owens wrote: You mean that nobody reads Documentation/Changes any more? Seldom, only once or twice a day. Guess that's not often enough to keep up on the new tool requirements. make 3.77 was added to Documentation/Changes in 2.4.0-test7-pre4.1, approx. 15 Aug 2000. - 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: unresolved symbol in 2.4.1 depmod.
On Tue, 30 Jan 2001 18:27:40 -0500, [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you write: On Tue, 30 Jan 2001 14:15:20 -0600 (CST), Jason Michaelson [EMAIL PROTECTED] wrote: Greetings. I've just procured myself a copy of 2.4.1, and tried to build it. At the tail end of a make modules_install, the following error occurs: depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/drivers/md/md.o depmod: name_to_kdev_t name_to_kdev_t is defined in init/main.c. It is not exported so it cannot be called from modules. name_to_kdev_t *cannot* be exported because it is defined as __init, the code has gone by the time the module is loaded. Ask the md maintainer for a fix. How did this used to work, then? The call to name_to_kdev_t has been in the md code since (according to the code comments) May, 2000; the module worked fine as of 2.4.1-pre10, which is the last version I used. It might have worked as built in code, I would be astounded if it ever worked as a module on a standard kernel after that code was added. name_to_kdev_t has been defined as this since at least 2.4.0-test1. kdev_t __init name_to_kdev_t(char *line) You cannot export a symbol marked __init and expect it to work. - 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 -- Unresolved symbols in radio-miropcm20.o
On Wed, 31 Jan 2001 09:46:19 +0100 (CET), [EMAIL PROTECTED] (Arjan van de Ven) wrote: Unfortionatly, this is impossible. The miropcm config question is asked before the "sound" question, and the aci question is asked after that (all in ake config). In 2.2.x we have an #ifdef in the driver that causes an #error with a description of the problem and the solution. Someone stripped that #ifdef out of the driver during 2.3.something. I thought the config problem was too hard for the current config language. Oh well, just have to wait until CML2 is part of the kernel, sometime in 2.5. - 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.2.18: apm initialised before dmi_scan?
On Wed, 31 Jan 2001 22:54:22 +1100 (EST), Neale Banks [EMAIL PROTECTED] wrote: If this is a correct and justifiable fix for 2.2 then in 2.4 should dmi_scan.o be included in export-objs? Or is there a "better" way of doing this? It should already be correct in 2.4. In 2.2 the OX_OBJS list is independent from the O_OBJS list and OX_OBJS is linked first, causing strange out of order problems. In 2.4 export-objs is a subset of the object list and export-objs does not impose any link ordering. - 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: v2.4.1 missing EXPORT_SYMBOL
On Wed, 31 Jan 2001 15:44:29 -0500 (EST), Eric Kasten [EMAIL PROTECTED] wrote: Quick bug report for kernel 2.4.1. There needs to be a EXPORT_SYMBOL(name_to_kdev_t); at the bottom of linux/init/main.c. name_to_kdev_t is used by the md driver (and maybe others). If the driver is built as a module it won't load due to the missing symbol. Don't blame us when the driver gets an oops. name_to_kdev_t is defined __init so the code is discarded after boot and the area is reused as scratch space. You must not EXPORT_SYMBOL() any __init or __exit code. The only place name_to_kdev_t is used in md is in the md_setup routine, that routine probably only makes sense when md is built in, not when md is a module. I recommend wrapping md_setup and all its data in #ifndef MODULE. - 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.2.18 - failed to exec /sbin/modprobe -s -k binfmt-464c
On Wed, 31 Jan 2001 14:17:56 -0700, "Josh Higham" [EMAIL PROTECTED] wrote: failed to exec /sbin/modprobe -s -k binfmt-464c You compiled your kernel with support for ELF objects as a module. You execute an ELF program, the kernel tries to autoload the ELF module using modprobe which is an ELF program. But you need ELF support to run modprobe, curse and recurse. Compile the kernel with builtin ELF, not a module. - 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: Power usage Q and parallel make question (separate issues)
On Wed, 31 Jan 2001 19:02:03 -0800, LA Walsh [EMAIL PROTECTED] wrote: This seems to serialize the delete, run the mod-installs in parallel, then run the depmod when they are done. It works, until somebody does this make -j 4 modules modules_install There is not, and never has been, any interlock between make modules and make modules_install. If you let modules_install run in parallel then people will be tempted to issue the incorrect command above instead of the required separate commands. make -j 4 modules make -j 4 modules_install You gain a few seconds on module_install but leave more room for user error. All of this is cleaned up in the 2.5 kbuild system (work in progress). I have carefully coded the 2.5 kbuild system so it can be used on 2.4 kernels as well. If you don't mind being an earlier adopter, this will be fixed in a few weeks. - 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: Power usage Q and parallel make question (separate issues)
On Thu, 01 Feb 2001 00:13:17 -0800, LA Walsh [EMAIL PROTECTED] wrote: Keith Owens wrote: It works, until somebody does this make -j 4 modules modules_install --- But that doesn't work now. Agreed, but letting modules_install parallel run increases the risk of somebody doing that. Most users will think that they can combine two parallel runs into a single command, but if they are forced to single thread modules_install it reduces the risk of user error. A bit of documentation at the beginning of the Makefile would do wonders for kernel-developer (not end user, please!) clarity. I've oft'asked the question as to what really is supported. I've tried things like make dep bzImage modules -- I noticed it didn't work fairly quickly. Same with modules/modules_install -- people would probably figure that one out, but just a bit of documentation would help even that. The 2.5 kbuild system will be fully documented, all the way from reasons for doing things down to how they are down. Trust me on this! I have had too many problems with undocumented changes in kbuild. - 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: Detecting Red Hat builds ?
On Thu, 10 May 2001 17:25:29 +0100 (BST), [EMAIL PROTECTED] wrote: The problem is I have a driver that includes syncppp.h which in the releases from kernel.org is in linux/drivers/net/wan/ up to and including 2.4.2 after which it moves to linux/include/net/. Do it in the Makefile. Untested: ifneq ($(wildcard $(TOPDIR)/include/net/syncppp.h),) CFLAGS_driver_name.o += -I $(TOPDIR)/include/net else CFLAGS_driver_name.o += -I $(TOPDIR)/drivers/net/wan endif and the driver does #include syncppp.h. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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-ac6 compile error in plip.c
On Thu, 10 May 2001 08:46:43 -0500, Moses McKnight [EMAIL PROTECTED] wrote: Hi, I get the following error trying to compile 2.4.4-ac6 using gcc 2.95.4 (debian package). plip.c:1412: __setup_str_plip_setup causes a section type conflict The first __initdata is marked as const, the second is not, a section cannot contain both const and non-const data. Against 2.4.4-ac6. Index: 4.16/drivers/net/plip.c --- 4.16/drivers/net/plip.c Thu, 26 Apr 2001 12:38:49 +1000 kaos (linux-2.4/l/c/23_plip.c 1.2.1.3 644) +++ 4.16(w)/drivers/net/plip.c Fri, 11 May 2001 14:50:39 +1000 kaos +(linux-2.4/l/c/23_plip.c 1.2.1.3 644) @@ -120,7 +120,7 @@ #include linux/parport.h -static const char version[] __initdata = +static char version[] __initdata = KERN_INFO NET3 PLIP version 2.4-parport [EMAIL PROTECTED]\n; /* Maximum number of devices to support. */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [OT] Keith Owens your email address isn't working
On Fri, 11 May 2001 05:47:16 -0400 (EDT), Mike A. Harris [EMAIL PROTECTED] wrote: Whenever I post to linux-kernel with your name in the Cc or To, the mail bounces back 5 days later Your mail is coming from 24.70.141.118 which has no reverse DNS and is somewhere in shaw.ca. I have received too much spam from shaw.ca and they do not seem to do anything about it so 24.70.141.118 hit my spam traps. You should be able to get through now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 in 2.4.4-ac6, ksymoops output included
On Fri, 11 May 2001 17:52:24 -0400 (EDT), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ksymoops 2.4.1 on i686 2.4.4-ac6. Options used Warning (read_object): no symbols in /lib/modules/2.4.4-ac6/build/drivers/pnp/pnp.o ksymoops should not be reading objects from /build/. It looks like you are running an old modutils, you need at least modutils 2.4.2 for 2.4 kernels. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Minor nit to pick
On Mon, 14 May 2001 00:16:50 -0400 (EDT), [EMAIL PROTECTED] wrote: After running make menuconfig (and it's friends) you get told to type make bzImage which is only right for i386, and IMHO should be changed to be arch dependant. The 2.5 Makefile rewrite splits the kernel build into three phases: configure, compile to vmlinux/modules and convert vmlinux to the required install format. bzImage is an example of install format and install formats will be architecture dependent in 2.5. We're working on it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Mon, 14 May 2001 23:55:37 +0100 (BST), Alan Cox [EMAIL PROTECTED] wrote: And lilo ? Also hdparm raidtools psmisc mtools mt-st gpm joystick kmod, /etc/modules.conf: alias block-major-what-random-number-did-the-kernel-pick-this-time driver_name - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Kernel 2.2.19 + VIA chipset + strange behaviour
On Tue, 15 May 2001 18:04:35 +0930 (CST), Jonathan Woithe [EMAIL PROTECTED] wrote: ksymoops 2.4.1 on i686 2.2.19. Options used Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry module_list was added to the export list in 2.2.17 so the message above implies that you are using kernel build information from 2.2.17 in your 2.2.19 build. I suggest you follow http://www.tux.org/lkml/#s8-8 and see if your problems recur after a completely clean kernel build. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Kernel 2.2.19 + VIA chipset + strange behaviour
Bug in include/linux/module.h. Patch against 2.2.19. This does not
explain your oops, the ksymoops message is a separate bug.
Index: 19.1/include/linux/module.h
--- 19.1/include/linux/module.h Tue, 12 Sep 2000 13:37:17 +1100 kaos
(linux-2.2/F/51_module.h 1.1.7.2 644)
+++ 19.1(w)/include/linux/module.h Wed, 16 May 2001 12:52:53 +1000 kaos
+(linux-2.2/F/51_module.h 1.1.7.2 644)
@@ -228,9 +228,9 @@ const char __module_using_checksums[] __
#define MOD_DEC_USE_COUNT do { } while (0)
#define MOD_IN_USE 1
-extern struct module *module_list;
-
#endif /* !__GENKSYMS__ */
+
+extern struct module *module_list;
#endif /* MODULE */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: make menuconfig - cosmetic question
On Thu, 17 May 2001 16:07:40 +0200, Martin.Knoblauch [EMAIL PROTECTED] wrote: This is a multi-part message in MIME format. Please turn off MIME when sending to linux-kernel, especially those useless vcards at the end of your mail. When I diff config files pocessed by make [old]config and make menueconfig, it seems that menuconfig is not writing out some of the comments that the other versions do write. Congratulations, you have found reason #93 for replacing the current configuration system (CML1) with something better - CML1 has multiple parsers with subtly different rules and output. CML2 will fix this, in kernel 2.5. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: newbie problem: compiling kernel 2.4.4, make modules_install , Help please !
On Thu, 17 May 2001 20:50:46 +0200 (CEST), Joel Cordonnier [EMAIL PROTECTED] wrote: It's the first time that i try to compile my own kernel. At the moment, I have an old RH 6.1 with a 2.2.12 kernel. - make modules_install == PROBLEM ! FIRST the message say that no argument -F exist for the command /sbin/depmod. Always read Documentation/Changes and check that *all* your utilities are up to date before working on a new kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.4.4-ac11 network drivers cleaning
On Sat, 19 May 2001 17:58:49 -0400, Jeff Garzik [EMAIL PROTECTED] wrote: Finally, I don't know if I mentioned this earlier, but to be complete and optimal, version strings should be a single variable 'version', such that it can be passed directly to printk like printk(version); Nit pick. That has random side effects if version contains any '%' characters. Make it printk(%s\n, version); Not quite as optimal but safer. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
On Sat, 19 May 2001 22:14:33 -0400, Ben Bridgwater [EMAIL PROTECTED] wrote: To present a dumbed down UI targeted for Aunt Millie or whoever against the protests of the mainstream kernel tool audience makes zero sense to me, as don't Eric's repeated antagonistic comments. How many times do we have to say this? CML2 supports everybody from Aunt Millie (novice mode) through non-standard machine configurations (expert mode) through Linus (vi .config, make oldconfig). Pick the level of configuration that you need. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: CML2 design philosophy heads-up
On Sun, 20 May 2001 11:18:56 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: David Woodhouse [EMAIL PROTECTED]: The dependencies in CML1 are (supposed to be) absolute - the 'advisory' dependencies you're adding are arguably a useful feature, but please don't make it possible to confuse the two, and please do make sure it's possible to disable the latter form. I don't understand this request. I have no concept of `advisory' dependencies. What are you talking about? Is my documentation horribly unclear? People read documentation? No chance. Some people have got it into their heads that the Aunt Tillie method of configuration will be the only one allowed. They do not realise that this is the novice method, experts can still do what they like. For dwm's advisory dependencies, read novice mode, and of course it can be overridden by people who know what they are doing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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 for sbus makefile bug
On Sun, 20 May 2001 11:47:38 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Somebody failed to track a module name change. -obj-$(CONFIG_BBC_I2C) += bbc.o +obj-$(CONFIG_BBC_I2C) += bbc_i2c.o bbc-objs := bbc_i2c.o bbc_envctrl.o The module is bbc.o, bbc_i2c.o is a sub-object of bbc.o, the selection is correct (2.4.5-pre4). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: compile failure in 2.4.5-pre4
On Mon, 21 May 101 16:38:45 +1000 (EST), Allan Duncan [EMAIL PROTECTED] wrote: drivers/ide/ide-pci.c:711 if (!IDE_PCI_DEVID_EQ(d-devid, DEVID_CS5530) for (i = 0; i 1000; ++i) printf(I must scan kernel archives before report bugs\n); http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg45470.html Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 (We are just a number) Who is number 1? You are number 6. I am not a number, I am a free man! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: const __init
On Sun, 20 May 2001 17:34:48 -0400,
Jeff Garzik [EMAIL PROTECTED] wrote:
(let me know if the following test is flawed)
[jgarzik@rum tmp]$ cat sectest.c
#include linux/module.h
#include linux/init.h
static const char version[] __initdata = foo;
[jgarzik@rum tmp]$ gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o sectest.o sectest.c
[jgarzik@rum tmp]$
No section type conflict appears.
With just one variable in initdata there is no conflict, it takes two
to conflict.
static const char var1[] __attribute__ ((__section__ (.data.init))) = foo;
int main(void) { return(0); }
static int var2[] __attribute__ ((__section__ (.data.init))) = {0,1};
does cause a section conflict, egcs 1.1.2.
Interestingly enough, if var[12] are together, without the intervening
text, then gcc does not flag an error, instead it puts both variables
in section .data.init and marks it as read only. This looks like a bug
in gcc.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Hang with SMP 2.4.4 snd log
On Mon, 21 May 2001 10:26:20 +0200 (CEST), kees [EMAIL PROTECTED] wrote: I got a next hang with my SMP system, kdb log attached. Something strange with the backtrace for CPU 0. Here is the first cut from the kdb log.. I do not trust either of those backtraces. There is no way to get from do_nmi to do_exit. The presence of unknown entries indicates that the cpu 0 back trace is bad. Also all the ebp pointers are suspect, they are way out of range for the task addresses. You could be looking at a stack overrun or just random corruption of kernel data. If you can reproduce the problem, set KDBDEBUG=0xff and bt. That will debug kdb and produce a lot of output. Send it to me, although I suspect it will just prove that you have stack corruption. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001 16:38:34 -0400,
John Stoffel [EMAIL PROTECTED] wrote:
All that CML2 does is enforce dependencies in the configuration
language. You can't make a .config which conflicts. Admittedly
there's nothing stopping you from hacking it with vi after the fact,
but why?
CML2 will not stop you hacking .config by hand. But the 2.5 makefile
rewrite will, because we have had too many bug reports caused by people
who hand edited .config, did not revalidate it and generated invalid
kernels. Yes, you can hand edit .config. No, you cannot compile until
.config has been (re-)validated.
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h, this should not
happen.
@echo Always run make one of {menu,old,x}config after manually updating
.config.
@/bin/false
And before people complain: Don't create a config that violates the CML
rules, correct the CML rules, the Makefiles and the source so .config
is valid. The kernel build requires a valid .config.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Background to the argument about CML2 design philosophy
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips [EMAIL PROTECTED] wrote:
On Tuesday 22 May 2001 02:59, Keith Owens wrote:
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h,
this should not happen. @echo Always run make one of
{menu,old,x}config after manually updating .config. @/bin/false
Ahem. What is wrong with revalidating it automatically? *Then* if there's a
problem, bother the user.
Revalidate using which tool? Did the user even mean to edit .config?
This is a case where the user has to decide what to do.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac14
Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac14
On Wed, 23 May 2001 05:36:20 -0400, Olivier Galibert [EMAIL PROTECTED] wrote: On Wed, May 23, 2001 at 07:07:38PM +1000, Keith Owens wrote: What is the point of including it in the kernel source tree without the code to convert it to ser_a2232fw.h? Nobody can use ser_a2232fw.ax, it is just bloat. We don't provide the binutils or gcc with the kernel either. The 6502 is a rather well known processor. Try plonking 6502 assembler in google and you'll have a lot of choice. I can accept that, but only if there is some documentation in drivers/char/Makefile to tell people which 6502 assembler to use and how it should be run, preferably including the commands used by the maintainer to generate ser_a2232fw.h. Comment out the commands to prevent them being used by mistake (we don't want another aic7xxx debacle) but it should be documented. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: CML2 design philosophy heads-up
cc trimmed back to mailing lists only. On Fri, 18 May 2001 10:53:53 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: (a) Back off the capability approach. That is, accept that people doing configuration are going to explicitly and exhaustively specify low-level hardware. No, you loose one of the nicer features of CML2. (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied whenever a SCSI card is configured, etc. As a specific case this needs doing anyway, to handle SCSI emulation over IDE, irrespective of the board type. It needs mid layer but no SCSI driver and can be done on a PC right now. As a general question, I prefer selecting machine type foo to mean just that, you get the devices supported by foo. (c) Decide not to support this case and document the fact in the rulesfile. If you're going put gunge on the VME bus that replaces the SBC's on-board facilities, you can hand-hack your own configs. In general this is the best option, if you create a non-standard configuration for machine foo then it is your problem, not everybody else's. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8
On Fri, 25 May 2001 08:31:24 -0700 (PDT), dean gaudet [EMAIL PROTECTED] wrote: another possibility for a debugging mode for the kernel would be to hack gcc to emit something like the following in the prologue of every function (after the frame is allocated): IKD already does that, via the CONFIG_DEBUG_KSTACK, CONFIG_KSTACK_METER and CONFIG_KSTACK_THRESHOLD options. No need to hack gcc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: new aic7xxx oopses with AHA2940
On Sat, 26 May 2001 18:05:29 +0200, Marc Schiffbauer [EMAIL PROTECTED] wrote: I have problems with the new aic7xxx-Driver. These problems exist with vanilla (2.4.4, 2.5.5, other d.k.) and -ac May 26 17:52:33 homer kernel: EIP: 0010:[usbcore:usb_devfs_handle_Re9c5f87f+161255/198895517] May 26 17:52:33 homer kernel: Call Trace: [usbcore:usb_devfs_handle_Re9c5f87f+162269/198894503] [usbcore:usb_devfs_handle_Re9c5f87f+164966/198891806] [__delay+19/48] [usbcore:usb_devfs_handle_Re9c5f87f+166493/198890279] [usbcore:usb_devfs_handle_Re9c5f87f+117712/198939060] [usbcore:usb_devfs_handle_Re9c5f87f+185577/198871195] [usbcore:usb_devfs_handle_Re9c5f87f+171751/198885021] Does it crash with the USB-Driver?? But USB works fine... even after the Oops Because you are using a broken version of klogd that stuffs up oops traces. Change klogd to run as klogd -x (probably in /etc/rc.d/init.d/syslog) so it keeps its broken fingers off the oops. Since you are failing during modprobe, creating /var/log/ksymoops is a good idea, man insmod, see KSYMOOPS ASSISTANCE. Reproduce the problem to get a clean oops trace then run it through ksymoops, using the saved module data in /var/log/ksymoops. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8
On Fri, 25 May 2001 10:27:53 +0200, Andi Kleen [EMAIL PROTECTED] wrote: On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote: Nothing in arch/i386/kernel/traps.c uses a task gate, they are all interrupt, trap, system or call gates. I guarantee that kdb on ix86 and ia64 uses the same kernel stack as the failing task, the starting point for the kdb backtrace is itself and it does not follow segment switches. I would consider this a bug in kdb then. No more of a bug than panic(), show_stack(), printk() and all the other routines that get called during a kernel problem. They all use the current kernel stack and they work almost all the time. Kernel stack overflows are symptoms of bad code, so fix the code, not the recovery routines. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8
On Fri, 25 May 2001 08:11:07 +0100, David Welch [EMAIL PROTECTED] wrote: Why not use a task gate for the double fault handler points to a per-processor TSS with a seperate stack. This would allow limited recovery from a kernel stack overlay. It is far too late by then. struct task is at the bottom of the kernel stack, a stack overflow would corrupt the task data long before the hardware was involved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.5 + ReiserFS + SMP + umount = oops
On Sun, 27 May 2001 06:04:28 +0200 (CEST), Rene [EMAIL PROTECTED] wrote: hmm I feel quite certain that I am using /dev/tty - is there some way I can check this? /etc/inittab, lines for mingetty, getty or agetty. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FWD: [RHSA-2000:108-02] Updated modutils fixing local root
On Sat, 27 May 2001 21:11:25, [EMAIL PROTECTED] (Joseph S Price) wrote: Red Hat, Inc. Security Advisory Synopsis: Updated modutils fixing local root security bug available Advisory ID: RHSA-2000:108-02 Issue date:2000-11-16 Updated on:2000-11-16 Product: Red Hat Linux Keywords: modutils root exploit security What is the point of sending a 6 month old security report to linux-kernel? That exploit was fixed a couple of days after it was reported. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8
On Fri, 25 May 2001 10:20:15 +0200, Andi Kleen [EMAIL PROTECTED] wrote: On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote: The only way to avoid those problems is to move struct task out of the kernel stack pages and to use a task gate for the stack fault and double fault handlers, instead of a trap gate (all ix86 specific). Those methods are expensive, at a minimum they require an extra page for every process plus an extra stack per cpu. I have not even considered the extra cost of using task gates for the interrupts nor how this method would complicate methods for getting the current struct task pointer. It is not worth the bother, we write better kernel code than that. When you don't try to handle recursive stack/double faults it only requires a single static stack per CPU. With some tricks and minor races it is also possible to handle multiple ones. That is exactly what I said above, a separate fault task with its own stack for every cpu. But there is no point in doing this to detect a hardware stack overflow when the overflow has already corrupted the struct task which is at the bottom of the stack segment. To get any benefit from hardware detection of kernel stack overflow you must also dedicate the stack segment to hold only stack data. That means moving struct task to yet another page, adding an extra page per task. It is just too expensive, we write better code than that. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: unresolved symbols printk ?
On Tue, 29 May 2001 15:54:36 +0200, Nico Schottelius [EMAIL PROTECTED] wrote: Just a small question, what could be the reason I have a broken Makefile ? This seems to happen frequently, if there is a need to name it into the lkml. I am surprised a makefile gets screwed up ? It is the makefile design for modversions that is broken. The entire makefile system is being redesigned and rewritten from scratch for kernel 2.5. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] 4 security holes in 2.4.4-ac8
On 30 May 2001 11:38:13 +0200, Andi Kleen [EMAIL PROTECTED] wrote: David S. Miller [EMAIL PROTECTED] writes: Dawson Engler writes: Is there any way to automatically find these? E.g., is any routine with asmlinkage callable from user space? This is only universally done in generic and x86 specific code, other ports tend to forget asmlinkage simply because most ports don't need it. Even i386 doesn't need it because the stack frame happens to have the right order of the arguments at the right position. Just you can get into weird bugs when any function modifies their argument because it'll be still modified after syscall restart but only depending if the compiler used a temporary register or not. For IA64 you *must* use asmlinkage because the first 8 parameters are passed in registers. gcc will happily modify the register values which will mess up syscall restart, unless you use asmlinkage to force gcc to take copies of parameters and modify the copies. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] for Linux IRDA initialisation bug 2.4.5
On Fri, 1 Jun 2001 23:32:46 +1000, Matt Chapman [EMAIL PROTECTED] wrote: I've found that if you compile IRDA into the kernel, irda_proto_init gets called twice - once at do_initcalls time, and once explicitly in do_basic_setup - eventually resulting in a hang (as register_netdevice_notifier gets called twice with the same struct, and it's list becomes circular). The suggested patch has one non-obvious side effect which somebody in irda needs to verify is OK. Previously irda_proto_init() and irda_device_init() were called after every other driver had initialized. Now irda_proto_init() is called based on the object order in the top level Makefile, so irda is initialized before i2c, telephony, acpi and mddev. Is this a valid initialization order? If not, move DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o to the end of the drivers list and document why it needs to be there. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac6
ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.8-2.4.5-ac6.gz is available. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.2: /proc/config.gz
On Thu, 31 Aug 2000 15:08:49 -0400 (EDT), Chris Meadors [EMAIL PROTECTED] wrote: What about those of us who don't have modules enabled. "make modules_install" complains. I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules for modules. Or on my machines I won't even have to create /lib/modules. The directory name is irrelevant, we just want one place to store information for a specific kernel. Right now we have /boot/vmlinuz, /boot/System.map with symlinks to the real vmlinuz and map, /lib/modules/version contains modules and the symlink to the kernel source tree, nothing contains .config. Is it just me or does this design make no sense? Having one directory per installed kernel containing vmlinuz, map, config, build symlink, modules and any future kernel related data makes sense. Whether you call it /lib/modules/version or /lib/kernel/version is irrelevant. The fact that "make modules_install" complains without modules configured in is also irrelevant, that little bit of the Makefile is easily fixed, but there is no point in changing the Makefile until we agree on a design change. The only problem I can see with the single directory model is on disks where /lib/module/version/vmlinuz is past cylinder 1024, although that restriction is fast disappearing. Even this problem can be easily fixed by a new Makefile target (make install_low) which copies vmlinuz to /boot as well as /lib/module/version. - 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-test7 spurious '##' patches
On Thu, 31 Aug 2000 21:44:16 -0700, Richard Henderson [EMAIL PROTECTED] wrote: On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote: Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version 2.96-ia64-000717 snap 000828. It complained about various include files, "pasting would not give a valid preprocessing token", this version of gcc is a bit more paranoid about the use of '##'. -#define dprintk(args...)dfprintk(FACILITY, ## args) +#define dprintk(args...)dfprintk(FACILITY, args) This one isn't. This is a gcc extension to remove the previous token if "args" is empty. So you'd get dfprintk(FACILITY); instead of dfprintk(FACILITY, ); I know about that extension and I originally tried dfprintk(FACILITY , ##args) which is what gcc info recommends, but that still gave a warning message. Since this particular macro requires at least one argument (dprintk() and dfprintk(FACILITY) are meaningless), it was easier to remove the '##'. - 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/
Glad we did not add NTFS stream support
http://www.net-security.org/text/articles/viruses/generation.shtml describes a new generation of viruses which use NTFS stream support to hide themselves. "Certainly, this virus begins a new era in computer virus creation," said Eugene Kaspersky, Head of Anti-Virus Research at Kaspersky Lab. "The 'Stream Companion' technology the virus uses to plant itself into files makes its detection and disinfection extremely difficult to complete." - 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: Compiler warnings
On Wed, 6 Sep 2000 21:49:44 +0100 (BST), Alan Cox [EMAIL PROTECTED] wrote: Use a different gcc. There are reasons people shipping 2.96 for intel x86 also include egcs. The kernel isnt ready for 2.96 Out of curiousity, which compiler would you recommend for IA64 kernels? The latest unwind code is in the bleeding edge version of gcc, which just happens to have the problems with '##' as well. - 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: modules directory
On Wed, 6 Sep 2000 18:07:13 -0400 (EDT), "Richard B. Johnson" [EMAIL PROTECTED] wrote: Ahaa! Aye... Does this imply that there will, in the future, be other than '/kernel/drivers' as modules? Or is this (I fear) another change that; "Doesn't have to be better, only different..." /lib/modules/`uname -r`/ modules.dep modules.pcimap System.map .config Any other text files that are kernel specific build symlink kernel/ modules that came from the kernel source tree pcmcia/ modules from external pcmcia package xyz/ modules from third party xyz package, e.g. vmware The old method of mixing multiple sources into fs/, drivers/ net/ etc. made it impossible to clean out old kernel modules automatically during make modules_install. A common class of problem was caused by old modules when somebody changed an option from a module to in kernel but did not clean out the old modules first. Not any more. The old modules_install method relied on human definition of the mapping from source tree to fs/, net/, misc/ etc. Kernel developers got this wrong all the time, which is why half the modules incorrectly ended up in misc/. Even worse, you could have multiple copies of modules, on in say fs/, the other in misc/ and you never knew which one was being used. Not any more. - 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: test8-pre6 file corruption and oops
On 08 Sep 2000 01:40:55 +0200, "Juan J. Quintela" [EMAIL PROTECTED] wrote: "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes: hi I only can guess that you are using a wrong System.map for doing the ksymoops. __mon_yday is an array, not a function, the backtrace don't make sense. Later, Juan "waiting for a nice backtrace" :))) kenneth Sep 7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] [__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] [ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] That is caused by klogd assuming it knows where the System.map is and blindly using the wrong one. Sorry folks but klogd as distributed is broken. Either start klogd with "-x" or apply ftp://ftp.ocs.com.au/pub/ksymoops/v2.3/patch-sysklogd-1-3-31-ksymoops-1.gz and use ksymoops to get a real back trace. - 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-test8-pre1 is quite bad / how about integrating Rik's VM
On Thu, 7 Sep 2000 19:14:26 -0500, Michael Elizabeth Chastain [EMAIL PROTECTED] wrote: Yeah. Long transition, plus user education (which never works, dontcha know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). http://www.linuxdoc.org/LDP/lkmpg/mpg.html, by Ori Pomerantz. He does not have time to maintain it any more so I have volunteered to take it over. Now I just have to find some free time to update it, maybe after the ski season in Oz has finished. - 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: Weird module dependencies in some netfilter modules
On Thu, 7 Sep 2000 23:39:11 -0300, Cesar Eduardo Barros [EMAIL PROTECTED] wrote: My modules.dep has the following lines: /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_nat_ftp.o: /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/iptable_nat.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ipchains.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_conntrack.o Please run nm -A /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/*.o and mail the result to me ([EMAIL PROTECTED]), not the list. - 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: Weird module dependencies in some netfilter modules
On Thu, 7 Sep 2000 23:39:11 -0300, Cesar Eduardo Barros [EMAIL PROTECTED] wrote: My modules.dep has the following lines: /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_nat_ftp.o: /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/iptable_nat.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ipchains.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_conntrack.o Forget about running "nm -A" on the modules, MEC has already done it. ipchains does not export any symbols, nor does it suppress symbol export so the default is export everything. This results in duplicate exported symbols which confuses depmod. This patch appears to fix the problem. Index: 0-test8-pre6.4/net/ipv4/netfilter/ipchains_core.c --- 0-test8-pre6.4/net/ipv4/netfilter/ipchains_core.c Fri, 26 May 2000 13:10:01 +1000 kaos (linux-2.4/g/2_ipchains_c 1.1 644) +++ 0-test8-pre6.4(w)/net/ipv4/netfilter/ipchains_core.c Fri, 08 Sep 2000 15:27:43 ++1100 kaos (linux-2.4/g/2_ipchains_c 1.1 644) @@ -67,6 +67,8 @@ * This software is provided ``AS IS'' without any warranties of any kind. */ #include linux/config.h +#include linux/module.h +EXPORT_NO_SYMBOLS; #include asm/uaccess.h #include asm/system.h Advance warning. Starting with kernel/modutils 2.5, the default on module symbols will be changed from "export everything unless explicitly suppressed" to "export nothing unless explicitly requested". That will probably break a few modules, but that is what development kernels are for. - 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/
Flavours of deceased bovine
Just had an ext2 filesystem on SCSI that was corrupt. The first two words of the group descriptor had been overwritten with 0xdeadbeef, 0x. The filesystem is fixed now but trying to track down the problem is difficult, there are 50+ places in the kernel that use 0xdeadbeef. I strongly suggest that people use different variants of dead beef to make it easier to work out where any corruption is coming from. Perhaps change the last 2-3 digits so magic values would be 0xdeadb000 to 0xdeadbfff, assuming it does not affect any other code. - 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: Flavours of deceased bovine
On Fri, 8 Sep 2000 04:24:16 -0400 (EDT), Alexander Viro [EMAIL PROTECTED] wrote: On Fri, 8 Sep 2000, Keith Owens wrote: Just had an ext2 filesystem on SCSI that was corrupt. The first two words of the group descriptor had been overwritten with 0xdeadbeef, 0x. The filesystem is fixed now but trying to track down the problem is difficult, there are 50+ places in the kernel that use 0xdeadbeef. Fsck... Which version was it? A heavily hacked SGI internal version, based on 2.4.0-test5 with bits backported from later kernels and kdb. - 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: test8-pre6 file corruption and oops
On Fri, 08 Sep 2000 10:33:35 +0200, Kenneth Johansson [EMAIL PROTECTED] wrote: Is there some way I can fix the old report I don't have a unprocessed version of the oops as klogd "fixed" it automatically. The raw data has been lost. Do you feel like grubbing through whichever System.map klogd used and converting label+offset back to hex ;) If not then the oops is probably useless. - 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: [OMG] test8-pre6 horribly, awfully screwed!
On Fri, 08 Sep 2000 23:50:32 -1100, Daniel Stone [EMAIL PROTECTED] wrote: When I boot up, I have a netfilter init script. It loads many netfilter modules, among them, ipt_LOG, ipt_state, and ipt_limit. When they load, whammo, instant OOPS. ip_conntrack_irc is also among them. You might have been bitten by the spurious dependencies that pulls in both ipchains and ip_conntrack which do not co-exist well. It has been reported that modules.dep contains lines like this. /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_nat_ftp.o: /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/iptable_nat.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ipchains.o \ /lib/modules/2.4.0-test8-pre1/kernel/net/ipv4/netfilter/ip_conntrack.o ipchains does not export any symbols, nor does it suppress symbol export so the default is export everything. This results in duplicate exported symbols which confuses depmod. This patch appears to fix the problem, apply, make modules, make modules_install. Index: 0-test8-pre6.4/net/ipv4/netfilter/ipchains_core.c --- 0-test8-pre6.4/net/ipv4/netfilter/ipchains_core.c Fri, 26 May 2000 13:10:01 +1000 kaos (linux-2.4/g/2_ipchains_c 1.1 644) +++ 0-test8-pre6.4(w)/net/ipv4/netfilter/ipchains_core.c Fri, 08 Sep 2000 15:27:43 ++1100 kaos (linux-2.4/g/2_ipchains_c 1.1 644) @@ -67,6 +67,8 @@ * This software is provided ``AS IS'' without any warranties of any kind. */ #include linux/config.h +#include linux/module.h +EXPORT_NO_SYMBOLS; #include asm/uaccess.h #include asm/system.h - 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: test8-pre6 file corruption and oops
On Fri, 08 Sep 2000 23:09:14 +0200, Kenneth Johansson [EMAIL PROTECTED] wrote: I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd so it can't possibly choose the wrong file but is there some reason to turn off the lookup in klogd and use ksymoops ?? klogd only handles some architectures. klogd only knows about some messages for the architectures it does handle. klogd does not verify that it was passed the correct System.map. klogd does not always know about loaded modules. Even when klogd knows about loaded modules, it does not use the __insmod symbols to correctly map the modules. I could go on but you get the idea. - 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: Reversing klogd's EIP Resolution.
On Sat, 09 Sep 2000 19:20:15 +0100, Ralph Corderoy [EMAIL PROTECTED] wrote: 01:52:30 EIP:0010:[dput+77/328] I believe I should be able to look up dput in the System.map klogd is using, add on the offset, and then look that number up in the real System.map. Is this doable? Your best option is to convert dput+77 back to 8 digit hex and run the resulting log through ksymoops. +77/328 is offset 77, the next label that klogd knows about is 328 bytes later, ignore the /328. AFAIK klogd prints offsets in decimal but check the source code of sysklogd/ksym.c to be sure. - 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/
Announce: modutils 2.3.16 is available
Fastest download from kernel.org. Mirror at ftp://ftp.**.kernel.org/pub/linux/utils/kernel/modutils/v2.3 replace '**' with your favourite kernel.org mirror. Master at ftp://ftp.ocs.com.au/pub/modutils/v2.3. (slow) patch-modutils-2.3.16.gzPatch from modutils 2.3.15 to 2.3.16 modutils-2.3.16.tar.gz Source tarball, includes RPM spec file modutils-2.3.16-1.src.rpm As above, in SRPM format modutils-2.3.16-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 Changelog extract * Increase maximum symbols in map from 10,000 to 100,000. * Add __archdata section on architectures that need arch specific data in loaded modules (IA64 is first). * Ignore unresolved references if there are no relocation entries for them. Some versions of gcc generate spurious unresolved externals which are not actually used. * Update modules.conf man page by John Levon. * Simplify path list, defaults are almost all [toplevel] only. * Add prune command to modules.conf man page. The change to simplify the path list should give the same behaviour as the previous messy list of directories, for kernel and pcmcia files This change means that modutils now scans *all* directories under /lib/modules/version by default. If you have other directories under LMV (e.g. LMV/vmware) those directories are now scanned automatically. Let me know ASAP if this change causes any problems. Third party modules whose source is compiled separately from the kernel source tree should install into their own directory under LMV, they should not pollute the LMV/kernel directory. Kernel builds from 2.4.0-test6 onwards remove all of LMV/kernel during modules install, to ensure that the kernel directory contains no old modules. So anything that pollutes LMV/kernel will be lost during kernel install. - 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: Dave's Power Store News Welcomes You!
On Sat, 9 Sep 2000 22:25:42 -0400 (EDT), "David Greenwalt" [EMAIL PROTECTED] wrote: [spam snipped] http://www.thepowerstore.com www.thepowerstore.com, 206.180.232.118 is part of The Diamond Lane (NETBLK-TDL-BLK) 2415 Radley Court #1 Hayward, CA 94545 US Netname: TDL-BLK Netblock: 206.180.224.0 - 206.180.239.255 Maintainer: TDL Coordinator: NICOLAUS, DON (DN-ARIN) [EMAIL PROTECTED] 5107826610 (FAX) (510)782-4738 (FAX) (510)782-4738 http://www.aweber.com/r.php?i=powerstorenewse=linux-kernel%40vger.kernel.org www.aweber.com, 216.205.135.103 is part of Interliant (NETBLK-ILNT-DW1) 66 Perimeter Center East Atlanta, GA 30346 US Netname: ILNT-DW1 Netblock: 216.205.128.0 - 216.205.159.255 Coordinator: Galiano, Aj (AG138-ARIN) [EMAIL PROTECTED] 770-673-2202 Go forth and complain. - 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/
