Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote: [snip of Petr's system info] > Okay. Mine, as far as I can tell, only depends on the L2 cache being set > to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under > 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS > for this motherboard available. It's a TD5TH version 1.1 > > H. Have you tried booting with an hercmono (if you can get your paws > on one, that is)?. > > > Right after 'Freeing unused kernel memory...' > I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 > without fbcon. With fbcon it would appear to switch video mode and > freeze with a black screen with cursor at the bottom, at that point. > > And then I get an oops dump in the swapper task. I'll try decoding it in a > little while, since I'll have to manually input it. Here we go: I DID have to copy it onto paper and type it in after rebooting. >>EIP; c01354a6<= Trace; c0217d72 Trace; c02180da Trace; c0186e85 Trace; c019e238 Trace; c01a22b7 Trace; c019fb0e Trace; c01a21d0 Trace; c010c2d1 Trace; c010c4b8 Trace; c0108d40 Trace; c010ac00 Trace; c0108d40 Trace; c0108dbc Trace; c0108dd2 Trace; c0105000 Trace; c01001cf Code; c01354a6 <_EIP>: Code; c01354a6<= 0: 0f 0b ud2a <= Code; c01354a8 2: 83 c4 0c add$0xc,%esp Code; c01354ab 5: 90nop Code; c01354ac 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c01354b0 a: 8d 5e 28 lea0x28(%esi),%ebx Code; c01354b3 d: 8d 46 2c lea0x2c(%esi),%eax Code; c01354b6 10: 39 46 2c cmp%eax,0x2c(%esi) Code; c01354b9 13: 74 00 je 15 <_EIP+0x15> c01354bb - 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: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: > On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: > > > > Pardon me for not fully groking the issues here and possibly coming to a > > wrong conclusion, but this has to do with SMP systems crashing at APIC > > init time, just before penguin display (with fbcon at least)? If so, I > > have a board that does this with certain cache settings made in the BIOS. > > It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. > > I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte > site for 6VXD7 (two PIII/800). I did not looked for updates today yet. > > I tried to change C2P Concurrency & Master (en/dis), AGP Mode (1x/2x/4x), > Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) > (24 combinations total), but any combination dies if there are read > accesses to videoram during startup. Today I finally digged out some > old ISA VGA (Realtek), plugged it in and - it dies too. So it does not > depend on bus type. Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. - 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: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte site for 6VXD7 (two PIII/800). I did not looked for updates today yet. I tried to change C2P Concurrency Master (en/dis), AGP Mode (1x/2x/4x), Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) (24 combinations total), but any combination dies if there are read accesses to videoram during startup. Today I finally digged out some old ISA VGA (Realtek), plugged it in and - it dies too. So it does not depend on bus type. Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. - 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: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote: [snip of Petr's system info] Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. Here we go: I DID have to copy it onto paper and type it in after rebooting. EIP; c01354a6 end_buffer_io_async+ea/12c = Trace; c0217d72 tvecs+3a1e/b81c Trace; c02180da tvecs+3d86/b81c Trace; c0186e85 end_that_request_first+65/c0 Trace; c019e238 ide_end_request+34/88 Trace; c01a22b7 read_intr+e7/120 Trace; c019fb0e ide_intr+12a/194 Trace; c01a21d0 read_intr+0/120 Trace; c010c2d1 handle_IRQ_event+59/84 Trace; c010c4b8 do_IRQ+a8/fc Trace; c0108d40 default_idle+0/34 Trace; c010ac00 ret_from_intr+0/20 Trace; c0108d40 default_idle+0/34 Trace; c0108dbc cpu_idle+28/54 Trace; c0108dd2 cpu_idle+3e/54 Trace; c0105000 empty_bad_page+0/1000 Trace; c01001cf L6+0/2 Code; c01354a6 end_buffer_io_async+ea/12c _EIP: Code; c01354a6 end_buffer_io_async+ea/12c = 0: 0f 0b ud2a = Code; c01354a8 end_buffer_io_async+ec/12c 2: 83 c4 0c add$0xc,%esp Code; c01354ab end_buffer_io_async+ef/12c 5: 90nop Code; c01354ac end_buffer_io_async+f0/12c 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c01354b0 end_buffer_io_async+f4/12c a: 8d 5e 28 lea0x28(%esi),%ebx Code; c01354b3 end_buffer_io_async+f7/12c d: 8d 46 2c lea0x2c(%esi),%eax Code; c01354b6 end_buffer_io_async+fa/12c 10: 39 46 2c cmp%eax,0x2c(%esi) Code; c01354b9 end_buffer_io_async+fd/12c 13: 74 00 je 15 _EIP+0x15 c01354bb end_buffer_io_async+ff/12c - 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: Startup IPI (was: Re: test13-pre3)
Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. -- Ferret - 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: CPU attachent and detachment in a running Linux system
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote: > Hi, > > >> I still wonder what you and other people think about the idea of an > >> interface where the parts of the kernel with per-cpu dependencies should > >> register two functions... > >Why not compile kernel with structeres big enough for 32 processors, > >and then just add CPUs up to the limit without changing anything? > > That's a good point and it would probably work for attachment of cpus, but > it won't work for detachment because there are some data structures that > need to be updated if a cpu gets detached. For example it would be nice > to flush the per-cpu cache of the detached cpu in the slabcache. Then one > has to think of pending tasklets for the detached cpu which should be > moved to another cpu and then there are a lot of per-cpu data structures > in the networking part of the kernel.. most of them seem to be for > statistics only but I think these structures should be updated in any > case. > So at least for detaching it would make sense to register functions which > will be called whenever a cpu gets detached. Plus userspace CPU monitors will need to know when the CPU arrangement has changed. - 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: [OT] Re: Linus's include file strategy redux
On Sun, 17 Dec 2000, Peter Samuelson wrote: > > [[EMAIL PROTECTED]] > > One last question: WHY is the kernel's top-level Makefile handling > > this symlink? > > Where do you think it should be handled? 'make modules_install' seems > like the most logical place, to me. I think making the symlink should be handled outside the proper scope of the top-level Makefile, for reasons I have brought up earlier in this discussion; The Makefile is simply not equipped to know the full state of the system it is being run for outside the simple case of one single machine. s/WHY is/For which specific reasons is/ Anyway, the associated discussions cleared up nearly all the technical-related questions I had. The remaining questions relate toward policy-issues orthogontal to implementation details. I am still a little unclear on the nature of the problem this symlink is meant to solve. - 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: [OT] Re: Linus's include file strategy redux
On Sun, 17 Dec 2000, Peter Samuelson wrote: [[EMAIL PROTECTED]] One last question: WHY is the kernel's top-level Makefile handling this symlink? Where do you think it should be handled? 'make modules_install' seems like the most logical place, to me. I think making the symlink should be handled outside the proper scope of the top-level Makefile, for reasons I have brought up earlier in this discussion; The Makefile is simply not equipped to know the full state of the system it is being run for outside the simple case of one single machine. s/WHY is/For which specific reasons is/ Anyway, the associated discussions cleared up nearly all the technical-related questions I had. The remaining questions relate toward policy-issues orthogontal to implementation details. I am still a little unclear on the nature of the problem this symlink is meant to solve. - 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: CPU attachent and detachment in a running Linux system
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote: Hi, I still wonder what you and other people think about the idea of an interface where the parts of the kernel with per-cpu dependencies should register two functions... Why not compile kernel with structeres big enough for 32 processors, and then just add CPUs up to the limit without changing anything? That's a good point and it would probably work for attachment of cpus, but it won't work for detachment because there are some data structures that need to be updated if a cpu gets detached. For example it would be nice to flush the per-cpu cache of the detached cpu in the slabcache. Then one has to think of pending tasklets for the detached cpu which should be moved to another cpu and then there are a lot of per-cpu data structures in the networking part of the kernel.. most of them seem to be for statistics only but I think these structures should be updated in any case. So at least for detaching it would make sense to register functions which will be called whenever a cpu gets detached. Plus userspace CPU monitors will need to know when the CPU arrangement has changed. - 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: Startup IPI (was: Re: test13-pre3)
Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. -- Ferret - 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: [OT] Re: Linus's include file strategy redux
On Sun, 17 Dec 2000, Peter Samuelson wrote: > > [[EMAIL PROTECTED] <[EMAIL PROTECTED]>] > > I have not moved or deleted a tree. I do not HAVE a kernel tree in > > the first place. Therefore, nothing for the symlink to point to when > > I install the kernel. > > If this is not the machine you compile your kernels on, why are you > compiling your external modules on it? One last question: WHY is the kernel's top-level Makefile handling this symlink? - 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: [OT] Re: Linus's include file strategy redux
On Sun, 17 Dec 2000, Peter Samuelson wrote: [[EMAIL PROTECTED] [EMAIL PROTECTED]] I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel. If this is not the machine you compile your kernels on, why are you compiling your external modules on it? One last question: WHY is the kernel's top-level Makefile handling this symlink? - 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: [OT] Re: Linus's include file strategy redux
On Sat, 16 Dec 2000, Peter Samuelson wrote: > > [[EMAIL PROTECTED]] > > Do you have an alternative reccomendation? I've shown where the > > symlink method WILL fail. You disagree that having the configured > > headers copied is a workable idea. What else is there? > > 4.5 more megabytes, per kernel, on my root filesystem. (That's *after* > pruning the extra include/asm-*/'s.) Thanks but no thanks. Yep. Did not occur to me at the time I asked. Someone else pointed this out to me also. VERY good point, but still needed to be explicitely mentioned. > Symlinks fail only if you move or delete your tree. By doing that, you > have proven that you actually know what and where your kernel sources > are, which in turn is strong evidence that you are not in need of those > "External Module Compiling for Dummies" scripts. I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel. > Conversely, by actually trusting a random script to compile an external > module unaided, the user is all but declaring himself incapable of > messing around with the /usr/src/linux that came pre-installed. You are assuming there is a /usr/src/linux that came pre-installed. This is not a valid assumption. - 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: Linus's include file strategy redux
On 16 Dec 2000, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> wrote: > >On 15 Dec 2000, Miquel van Smoorenburg wrote: > > > >> I think /lib/modules/`uname -r`/ should contain a script that > >> reproduces the CFLAGS used to compile the kernel. > > > >However it happens, the necessary information THAT I KNOW OF is: > >0) The kernel headers under linux/include > >1) The state information generated by running make configure ; make dep ; > >make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg > >configure which does the same thing but adds packaging-specific metadata. > > That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h Ah, thank you for resolving the state information for me. =) > >A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r` > >will not always work, because: > >0) The destination may not even exist (if the kernel has been installed > >onto another machine) > > Yes but in that case, how are you going to compile a module without > the kernel headers anyway. If you compiled a kernel on one > machine and you know that you want to be able to compile modules > on the second machine you need to copy over /usr/src/linux-x.y.z/include > as well. My point was that this symlink makes an assumption that is not always valid. And assuming things that are not always valid (opposing to things that do not always exist) is generally Wrong. > >1) The destination has no metadata or has the WRONG metadata (if I've just > >compiled and installed 2.4.0-test11 on my i386, then am now building same > >for my sun4c) > > As I said the kconfig script should do some simple sanity checks- > compare version and architecture at least. > > >I have been recently told that a full copy of kernel headers and metadata > >in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman > >who informed me of this hasn't yet shown why. > > Because lots of use have a small root file system of just 30 MB ? Yes, yes. Very good point. So (as I was thinking this morning as I awoke) the symlink could stay, IF it could be guarenteed not to be dangling on the target machine. I suspect making the symlink should therefore be left to the administrator or local package manager. We still can say that IF the symlink exists and is not dangling, that third-party modules source MAY ASSUME it points to headers configured for the running kernel. But the kernel build process SHOULD NOT make the symlink. > Hmm, but as soon as you start thinking about cross-compiles etc > you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR, > NM etc etc. Yuck. It would probably be better to put all that info > in /usr/src/linux/Config.make, and use the current "build" symlink. > A module makefile would then look like this: > > #! /usr/bin/make -f > > # You might want to point BUILD somewhere else. > BUILD = /lib/modules/$(shell uname -r)/build > include $(BUILD)/Config.make > > module.o: > $(CC) $(CFLAGS) -c module.c > > Ah yes, this is probably a much better approach then a kconfig script s/better/simpler/ A kconfig script will of course need to override BUILD in certain cases, but with make this is trivial. This solves one specific outstanding issue, and IMO at first glance before my first cup of coffee should solve it well. But a kconfig script is meant to do many other things as well. Some of these other things are big enough to be held until 2.5.0, and are mentioned in another post. - 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: [OT] Re: Linus's include file strategy redux
On Sat, 16 Dec 2000, Keith Owens wrote: > On Fri, 15 Dec 2000 19:37:49 -0800 (PST), > [EMAIL PROTECTED] wrote: > >Do you have an alternative reccomendation? I've shown where the symlink > >method WILL fail. You disagree that having the configured headers copied > >is a workable idea. What else is there? > > Use the pcmcia-cs method. Ask where the kernel headers with a sensible > default if the user just presses . Well yes, but can you ask the user non-interactively and get a sensible answer? - 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: What about 'kernel package'? was: Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, richard offer wrote: > > * $ from [EMAIL PROTECTED] at "15-Dec: 8:22pm" | sed "1,$s/^/* /" > * > * > * Once again, I'd like to suggest Debian's kernel package system as a good > * working example of this sort of administrative-level kernel management. I > * brought this up on the list once before, maybe eight months ago, but I > * recall not even one reply worth of discussion about it. I have a fairly > * basic idea of what could be done to merge part of 'make-kpkg' into the > * kernel-side management, but I'd like to see some other trained eyeballs > * taking a look. > > I'm not familiar with Debian at all.. do you have some pointers to information > on make-kpkg ? Off the top of my head: * perl script (but this can be changed if we wanted to adopt it) * Has build support for kernel 'flavours': 2.2.17-flavour * Has build support for modules outside of the kernel tree: alsa and lm-sensors, and others * Has support for cross-compiling the kernel and modules, by passing a single destination-archetecture paramater, with the support of an installed cross-compilation suite. Has full support for building Debian packages (of course!): * Kernel image * Kernel headers: placed into /usr/src/kernel-headers- * Kernel source: placed into /usr/src/kernel-source- * External modules The package build features could technically be seperated off into stubs on the main package. but it seems Connectiva is working on merging Red Hat's and Debian's packaging systems into something the LSB can adopt, if I hear correctly. Some of my ideas regarding the use of kernel-package with the main kernel source: * Simplifies the build of third-party modules AT KERNEL BUILD TIME: The sources go into /usr/src/modules/ * Protects against the dreaded accidental overwriting of current kernel image and modules but is easily enough overridden: newbie or asleep-at-console protection. * Could be easily hooked into local package management system. * The current monolithic kernel tarball could be split up to take advantage of the modules build system, although the configuration scripts would have to be changed. This would have a liability that code outside the core kernel tree would be more difficult to compile into a kernel, but would benefit by allowing non-core components to be developed and released asynchronously. A non-core component would be anything not required for booting, basic networking, or console access. Examples: infrared, multimedia, and sound. Areas in which the kernel-package system would need to be improved: * Support for building new modules after kernel build time. This is a current issue which could be more easily solved in the framework of kernel-package. * Support for calling an interactive configuration. * Scripting support to run a user-defined sequence with a single command. A typical build cycle on my build machine goes like: # make-kpkg clean # make menuconfig (if I need to change or interactively verify my options) # make-kpkg --revision=. configure # make-kpkg modules-clean # make-kpkg modules # make-kpkg kernel-headers (which I usually skip for personal use) # make-kpkg kernel-image I end up with package files called something like: kernel-image-2.4.0-test11_heathen.01_i386.deb kernel-headers-2.4.0-test11_heathen.01_i386.deb alsa-modules-2.4.0-test11_0.5.9d+heathen.01_i386.deb Getting it: * The package is called 'kernel-package', and you can download the source for it through www.debian.org * The archives ARE undergoing reorganisation at this time, so if anyone has troubles I can place a copy onto my webserver. - 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: [OT] Re: Linus's include file strategy redux
On Sat, 16 Dec 2000, Keith Owens wrote: On Fri, 15 Dec 2000 19:37:49 -0800 (PST), [EMAIL PROTECTED] wrote: Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there? Use the pcmcia-cs method. Ask where the kernel headers with a sensible default if the user just presses ENTER. Well yes, but can you ask the user non-interactively and get a sensible answer? - 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: Linus's include file strategy redux
On 16 Dec 2000, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On 15 Dec 2000, Miquel van Smoorenburg wrote: I think /lib/modules/`uname -r`/ should contain a script that reproduces the CFLAGS used to compile the kernel. However it happens, the necessary information THAT I KNOW OF is: 0) The kernel headers under linux/include 1) The state information generated by running make configure ; make dep ; make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg configure which does the same thing but adds packaging-specific metadata. That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h Ah, thank you for resolving the state information for me. =) A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r` will not always work, because: 0) The destination may not even exist (if the kernel has been installed onto another machine) Yes but in that case, how are you going to compile a module without the kernel headers anyway. If you compiled a kernel on one machine and you know that you want to be able to compile modules on the second machine you need to copy over /usr/src/linux-x.y.z/include as well. My point was that this symlink makes an assumption that is not always valid. And assuming things that are not always valid (opposing to things that do not always exist) is generally Wrong. 1) The destination has no metadata or has the WRONG metadata (if I've just compiled and installed 2.4.0-test11 on my i386, then am now building same for my sun4c) As I said the kconfig script should do some simple sanity checks- compare version and architecture at least. I have been recently told that a full copy of kernel headers and metadata in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman who informed me of this hasn't yet shown why. Because lots of use have a small root file system of just 30 MB ? Yes, yes. Very good point. So (as I was thinking this morning as I awoke) the symlink could stay, IF it could be guarenteed not to be dangling on the target machine. I suspect making the symlink should therefore be left to the administrator or local package manager. We still can say that IF the symlink exists and is not dangling, that third-party modules source MAY ASSUME it points to headers configured for the running kernel. But the kernel build process SHOULD NOT make the symlink. Hmm, but as soon as you start thinking about cross-compiles etc you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR, NM etc etc. Yuck. It would probably be better to put all that info in /usr/src/linux/Config.make, and use the current "build" symlink. A module makefile would then look like this: #! /usr/bin/make -f # You might want to point BUILD somewhere else. BUILD = /lib/modules/$(shell uname -r)/build include $(BUILD)/Config.make module.o: $(CC) $(CFLAGS) -c module.c Ah yes, this is probably a much better approach then a kconfig script s/better/simpler/ A kconfig script will of course need to override BUILD in certain cases, but with make this is trivial. This solves one specific outstanding issue, and IMO at first glance before my first cup of coffee should solve it well. But a kconfig script is meant to do many other things as well. Some of these other things are big enough to be held until 2.5.0, and are mentioned in another post. - 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: [OT] Re: Linus's include file strategy redux
On Sat, 16 Dec 2000, Peter Samuelson wrote: [[EMAIL PROTECTED]] Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there? 4.5 more megabytes, per kernel, on my root filesystem. (That's *after* pruning the extra include/asm-*/'s.) Thanks but no thanks. Yep. Did not occur to me at the time I asked. Someone else pointed this out to me also. VERY good point, but still needed to be explicitely mentioned. Symlinks fail only if you move or delete your tree. By doing that, you have proven that you actually know what and where your kernel sources are, which in turn is strong evidence that you are not in need of those "External Module Compiling for Dummies" scripts. I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel. Conversely, by actually trusting a random script to compile an external module unaided, the user is all but declaring himself incapable of messing around with the /usr/src/linux that came pre-installed. You are assuming there is a /usr/src/linux that came pre-installed. This is not a valid assumption. - 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: What about 'kernel package'? was: Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, richard offer wrote: * $ from [EMAIL PROTECTED] at "15-Dec: 8:22pm" | sed "1,$s/^/* /" * * * Once again, I'd like to suggest Debian's kernel package system as a good * working example of this sort of administrative-level kernel management. I * brought this up on the list once before, maybe eight months ago, but I * recall not even one reply worth of discussion about it. I have a fairly * basic idea of what could be done to merge part of 'make-kpkg' into the * kernel-side management, but I'd like to see some other trained eyeballs * taking a look. I'm not familiar with Debian at all.. do you have some pointers to information on make-kpkg ? Off the top of my head: * perl script (but this can be changed if we wanted to adopt it) * Has build support for kernel 'flavours': 2.2.17-flavour * Has build support for modules outside of the kernel tree: alsa and lm-sensors, and others * Has support for cross-compiling the kernel and modules, by passing a single destination-archetecture paramater, with the support of an installed cross-compilation suite. Has full support for building Debian packages (of course!): * Kernel image * Kernel headers: placed into /usr/src/kernel-headers-version * Kernel source: placed into /usr/src/kernel-source-version * External modules The package build features could technically be seperated off into stubs on the main package. but it seems Connectiva is working on merging Red Hat's and Debian's packaging systems into something the LSB can adopt, if I hear correctly. Some of my ideas regarding the use of kernel-package with the main kernel source: * Simplifies the build of third-party modules AT KERNEL BUILD TIME: The sources go into /usr/src/modules/package * Protects against the dreaded accidental overwriting of current kernel image and modules but is easily enough overridden: newbie or asleep-at-console protection. * Could be easily hooked into local package management system. * The current monolithic kernel tarball could be split up to take advantage of the modules build system, although the configuration scripts would have to be changed. This would have a liability that code outside the core kernel tree would be more difficult to compile into a kernel, but would benefit by allowing non-core components to be developed and released asynchronously. A non-core component would be anything not required for booting, basic networking, or console access. Examples: infrared, multimedia, and sound. Areas in which the kernel-package system would need to be improved: * Support for building new modules after kernel build time. This is a current issue which could be more easily solved in the framework of kernel-package. * Support for calling an interactive configuration. * Scripting support to run a user-defined sequence with a single command. A typical build cycle on my build machine goes like: # make-kpkg clean # make menuconfig (if I need to change or interactively verify my options) # make-kpkg --revision=hostname.build # configure # make-kpkg modules-clean # make-kpkg modules # make-kpkg kernel-headers (which I usually skip for personal use) # make-kpkg kernel-image I end up with package files called something like: kernel-image-2.4.0-test11_heathen.01_i386.deb kernel-headers-2.4.0-test11_heathen.01_i386.deb alsa-modules-2.4.0-test11_0.5.9d+heathen.01_i386.deb Getting it: * The package is called 'kernel-package', and you can download the source for it through www.debian.org * The archives ARE undergoing reorganisation at this time, so if anyone has troubles I can place a copy onto my webserver. - 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/
What about 'kernel package'? was: Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, richard offer wrote: > In article <91e0vj$b6alr$[EMAIL PROTECTED]> you write: > >In article <[EMAIL PROTECTED]>, > >LA Walsh <[EMAIL PROTECTED]> wrote: > >>It was at that > >>point, the externally compiled module "barfed", because like many modules, > >>it expected, like many externally compiled modules, that it could simply > >>access all of it's needed files through /usr/include/linux which it gets > >>by putting /usr/include in it's path. I've seen commercial modules like > >>vmware's kernel modules use a similar system where they expect > >>/usr/include/linux to contain or point to headers for the currently running > >>kernel. > > > >vmware asks you nicely > > > >where are the running kernels include files [/usr/src/linux/include" > > > > >And then compiles the modules with -I/path/to/include/files > > > >In fact, the 2.2.18 kernel already puts a 'build' symlink in > >/lib/modules/`uname -r` that points to the kernel source, > >which should be sufficient to solve this problem.. almost. > > Don't get me started on that... The link points back to where the code > was when it was built, not where it is installed. This makes a difference > if you're building RPMs... in which case the link points back to (for > example) /usr/src/sgi/BUILD/linux- and not > /usr/src/linux-/. > > And, top it all... once the build is completed the BUILD directory > is deleted. > > > Good Idea, but poorly thought out. [snip] Once again, I'd like to suggest Debian's kernel package system as a good working example of this sort of administrative-level kernel management. I brought this up on the list once before, maybe eight months ago, but I recall not even one reply worth of discussion about it. I have a fairly basic idea of what could be done to merge part of 'make-kpkg' into the kernel-side management, but I'd like to see some other trained eyeballs taking a look. - 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: Linus's include file strategy redux
On Fri, 15 Dec 2000, J . A . Magallon wrote:
>
> On 2000/12/15 Werner Almesberger wrote:
> > LA Walsh wrote:
> >
> > Exception: opaque types; there one would have to go via a __ identifier,
> > i.e.
> >
> > /foo.h defines struct __foo ...;
> > /bar.h includes /foo.h
> >and uses #define FOOSIZE sizeof(struct __foo)
> > /foo.h either typedef struct __foo foo_t;
> > or #define foo __foo /* ugly */
> >
>
> Easier: public kernel interfaces only work through pointers.
> /foo.h typedef struct foo foo_t;
>foo_t* foo_new();
> /foo.h includes /foo.h
>struct foo { ... };
>and uses #define FOOSIZE sizeof(foo_t)
>
> Drawback: public access is slow (always through foo_set__field(foo_t*))
> private access from kernel or modules is fast (foo_t->x = ...)
> Advantage: kernel can change, foo_t internals can change and it is binary
> compatible. Even public headers can be kernel version
> independent.
I think collectively we're mixing what should really be two seperate but
related issues: userland interface from /usr/include/linux; and exported
kernel header interface for third-party modules.
>From a first reading, your Drawback: appears to belong to the sphere of
kernel interface, and your Advantage: to the sphere of userland interface.
But on the second reading (after opening a bottle of Jones) I can see how
the Advantage: would apply to both spheres.
I'm just asking that people please try to be a little more precise with
the rather imprecise list language.
--Ferret
-
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: Linus's include file strategy redux
On 15 Dec 2000, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > LA Walsh <[EMAIL PROTECTED]> wrote: > >It was at that > >point, the externally compiled module "barfed", because like many modules, > >it expected, like many externally compiled modules, that it could simply > >access all of it's needed files through /usr/include/linux which it gets > >by putting /usr/include in it's path. I've seen commercial modules like > >vmware's kernel modules use a similar system where they expect > >/usr/include/linux to contain or point to headers for the currently running > >kernel. > > vmware asks you nicely > > where are the running kernels include files [/usr/src/linux/include" > > > And then compiles the modules with -I/path/to/include/files > > In fact, the 2.2.18 kernel already puts a 'build' symlink in > /lib/modules/`uname -r` that points to the kernel source, > which should be sufficient to solve this problem.. almost. > > It doesn't tell you the specific flags used to compile the kernel, > such as -m486 -DCPU=686 > > > So at that point it becomes what we should name it under > >/usr/include/linux. Should it be: > >1) "/usr/include/linux/sys" (my preference) > > /usr should be static. It could be a read-only NFS mount. > Putting system dependant configuration info here (which a > /usr/include/linux/sys symlink *is*) is wrong. > > I think /lib/modules/`uname -r`/ should contain a script that > reproduces the CFLAGS used to compile the kernel. That way, > you not only get the correct -I/path/to/kernel/include but > the other compile-time flags (like -m486 etc) as well. [snip script] However it happens, the necessary information THAT I KNOW OF is: 0) The kernel headers under linux/include 1) The state information generated by running make configure ; make dep ; make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg configure which does the same thing but adds packaging-specific metadata. A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r` will not always work, because: 0) The destination may not even exist (if the kernel has been installed onto another machine) 1) The destination has no metadata or has the WRONG metadata (if I've just compiled and installed 2.4.0-test11 on my i386, then am now building same for my sun4c) I have been recently told that a full copy of kernel headers and metadata in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman who informed me of this hasn't yet shown why. Debian's kernel package system allows for the creation of a kernel-headers package which I THINK contains the correct metadata, but I've not verified. This is placed into /usr/src/kernel-headers-`uname -r`/. This is distro-specific but still A technically sound solution AFAIK. And not much different than mentioned in the directly preceding paragraph. Who else can offer an alternative solution, to the specific problem of making configured KERNEL headers available for building third-party modules? --Ferret - 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: [OT] Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, Ingo Oeser wrote: > On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote: > > > Maybe you did not notice, but for months we have > > > /lib/modules/`uname -r`/build/include, which points to kernel headers, > > > and which should be used for compiling out-of-tree kernel modules > > > (i.e. latest vmware uses this). > > > > This symlink really should be a copy instead, because the finished kernel > > may be installed on a machine that does not have kernel source installed > > on it. Dangling symlinks are BAD. > > But if you compile for another machine, this copy is bad. It also > takes to much time and space to create this copy. > > I really disagree here. Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there? - 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: [OT] Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, Petr Vandrovec wrote: > On 15 Dec 00 at 10:23, Dana Lacoste wrote: > > > On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote: > > > > > It's the version that's in cvs, I just did an cvs update. It's > > > been in it for ages. If it's wrong, someone *please* correct it. > > > > I think this is the important part. > > This subject has come up quite a few times in the past > > couple of weeks on the scyld (eepro/tulip) mailing lists. > > > > Essentially, whatever solution is implemented MUST ensure : > > > > 1 - glibc will work properly (the headers in /usr/include/* don't > > change in an incompatible manner) > > > > 2 - programs that need to compile against the current kernel MUST > > be able to do so in a quasi-predictable manner. > > Maybe you did not notice, but for months we have > /lib/modules/`uname -r`/build/include, which points to kernel headers, > and which should be used for compiling out-of-tree kernel modules > (i.e. latest vmware uses this). This symlink really should be a copy instead, because the finished kernel may be installed on a machine that does not have kernel source installed on it. Dangling symlinks are BAD. - 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: Linus's include file strategy redux
On Fri, 15 Dec 2000, Werner Almesberger wrote: > Alexander Viro wrote: > > In the situation above they should have -I/include > > in CFLAGS. Always had to. No links, no pain in ass, no interference with > > userland compiles. > > As long as there's a standard location for "", > this is fine. In most cases, the tree one expects to find is "roughly > the kernel we're running". Actually, maybe a script to provide the > path would be even better (*). Such a script could also complain if > there's an obvious problem. > > I think there are three possible directions wrt visibility of kernel > headers: > > - non at all - anything that needs kernel headers needs to provide them >itself > - kernel-specific extentions only; libc is self-contained, but user >space can get items from .../include/linux (the current glibc >approach) > - share as much as possible; libc relies on kernel for "standard" >definitions (the libc5 approach, and also reasonably feasible >today) > > My personal preference is the third direction, because it simplifies the > deployment of new "standard" elements, and changes to existing interfaces. > The first direction would effectively discourage any new interfaces or > changes to existing ones, while the second direction allows at least a > moderate amount of flexibility for kernel-specific interfaces. In my > experiments with newlib, I was largely able to use the third approach. > > I don't want to re-open the discussion on which way is better for glibc, > but I think we can agree that "clean" kernel headers are always a good > idea. > > So we get at least the following levels of visibility: > > 0) kernel-internal interfaces; should only be visible to "base" kernel > 1) public kernel interfaces; should be visible to modules (exposing > type 0 interfaces to modules may create ways to undermine the GPL) > 2) interfaces to kernel-specific user space tools (modutils, mount, > etc.); should be visible to user space that really wants them > 3) interface to common non-POSIX extensions (BSD system calls, etc.); > should be visible to user space on request, or on an opt-out basis > 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be > visible unconditionally (**) > > Distinguishing level 0 and 1 is always a little difficult. It seems > that a "kmodcc" that inserts the necessary flags would be useful there > (*). There needs to be a clear distinction between level 1 and 2 (the > current #ifdef __KERNEL__). This boundary could certainly be improved > be moving user-space-visible header files to a separate directory. > > Levels 2, 3, and 4 are more difficult to separate, because the people > who know what should go where are not always the ones writing the > kernel headers. Perhaps some more input from libc hackers could help. > > (*) Crude examples for such scripts (for newlib): newlib-flags and > newlib-cc in > ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/ > newlib-linux-20.tar.gz > > (**) Multiple versions of the interface can be a problem here, e.g. > struct oldold_utsname vs. struct old_utsname vs. > struct new_utsname. It would be nice to have them prefixed at > least with __. Maybe a __LATEST_utsname macro would be useful > too ;-) (I know, breaks binary compatibility, hence the > smiley.) > > So ... what's the opinion on slowly introducing a redirection via > scripts ? Just out of curiosity, what would happen with redirection if your source tree for 'the currently running kernel' version happens to be configured for a different 'the currently running kernel', perhaps a machine of a foreign arch that you are cross-compiling for? I do this: I use ONE machine to compile kernels for five: four i386 and one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does this redirection leave them? - 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: Linus's include file strategy redux
On Fri, 15 Dec 2000, Werner Almesberger wrote: Alexander Viro wrote: In the situation above they should have -Iwherever_the_tree_lives/include in CFLAGS. Always had to. No links, no pain in ass, no interference with userland compiles. As long as there's a standard location for "wherever_the_tree_lives", this is fine. In most cases, the tree one expects to find is "roughly the kernel we're running". Actually, maybe a script to provide the path would be even better (*). Such a script could also complain if there's an obvious problem. I think there are three possible directions wrt visibility of kernel headers: - non at all - anything that needs kernel headers needs to provide them itself - kernel-specific extentions only; libc is self-contained, but user space can get items from .../include/linux (the current glibc approach) - share as much as possible; libc relies on kernel for "standard" definitions (the libc5 approach, and also reasonably feasible today) My personal preference is the third direction, because it simplifies the deployment of new "standard" elements, and changes to existing interfaces. The first direction would effectively discourage any new interfaces or changes to existing ones, while the second direction allows at least a moderate amount of flexibility for kernel-specific interfaces. In my experiments with newlib, I was largely able to use the third approach. I don't want to re-open the discussion on which way is better for glibc, but I think we can agree that "clean" kernel headers are always a good idea. So we get at least the following levels of visibility: 0) kernel-internal interfaces; should only be visible to "base" kernel 1) public kernel interfaces; should be visible to modules (exposing type 0 interfaces to modules may create ways to undermine the GPL) 2) interfaces to kernel-specific user space tools (modutils, mount, etc.); should be visible to user space that really wants them 3) interface to common non-POSIX extensions (BSD system calls, etc.); should be visible to user space on request, or on an opt-out basis 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be visible unconditionally (**) Distinguishing level 0 and 1 is always a little difficult. It seems that a "kmodcc" that inserts the necessary flags would be useful there (*). There needs to be a clear distinction between level 1 and 2 (the current #ifdef __KERNEL__). This boundary could certainly be improved be moving user-space-visible header files to a separate directory. Levels 2, 3, and 4 are more difficult to separate, because the people who know what should go where are not always the ones writing the kernel headers. Perhaps some more input from libc hackers could help. (*) Crude examples for such scripts (for newlib): newlib-flags and newlib-cc in ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/ newlib-linux-20.tar.gz (**) Multiple versions of the interface can be a problem here, e.g. struct oldold_utsname vs. struct old_utsname vs. struct new_utsname. It would be nice to have them prefixed at least with __. Maybe a __LATEST_utsname macro would be useful too ;-) (I know, breaks binary compatibility, hence the smiley.) So ... what's the opinion on slowly introducing a redirection via scripts ? Just out of curiosity, what would happen with redirection if your source tree for 'the currently running kernel' version happens to be configured for a different 'the currently running kernel', perhaps a machine of a foreign arch that you are cross-compiling for? I do this: I use ONE machine to compile kernels for five: four i386 and one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does this redirection leave them? - 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: [OT] Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, Petr Vandrovec wrote: On 15 Dec 00 at 10:23, Dana Lacoste wrote: On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote: It's the version that's in cvs, I just did an cvs update. It's been in it for ages. If it's wrong, someone *please* correct it. I think this is the important part. This subject has come up quite a few times in the past couple of weeks on the scyld (eepro/tulip) mailing lists. Essentially, whatever solution is implemented MUST ensure : 1 - glibc will work properly (the headers in /usr/include/* don't change in an incompatible manner) 2 - programs that need to compile against the current kernel MUST be able to do so in a quasi-predictable manner. Maybe you did not notice, but for months we have /lib/modules/`uname -r`/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this). This symlink really should be a copy instead, because the finished kernel may be installed on a machine that does not have kernel source installed on it. Dangling symlinks are BAD. - 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: Linus's include file strategy redux
On Fri, 15 Dec 2000, J . A . Magallon wrote:
On 2000/12/15 Werner Almesberger wrote:
LA Walsh wrote:
Exception: opaque types; there one would have to go via a __ identifier,
i.e.
public/foo.h defines struct __foo ...;
public/bar.h includes public/foo.h
and uses #define FOOSIZE sizeof(struct __foo)
private/foo.h either typedef struct __foo foo_t;
or #define foo __foo /* ugly */
Easier: public kernel interfaces only work through pointers.
public/foo.h typedef struct foo foo_t;
foo_t* foo_new();
private/foo.h includes public/foo.h
struct foo { ... };
and uses #define FOOSIZE sizeof(foo_t)
Drawback: public access is slow (always through foo_set__field(foo_t*))
private access from kernel or modules is fast (foo_t-x = ...)
Advantage: kernel can change, foo_t internals can change and it is binary
compatible. Even public headers can be kernel version
independent.
I think collectively we're mixing what should really be two seperate but
related issues: userland interface from /usr/include/linux; and exported
kernel header interface for third-party modules.
From a first reading, your Drawback: appears to belong to the sphere of
kernel interface, and your Advantage: to the sphere of userland interface.
But on the second reading (after opening a bottle of Jones) I can see how
the Advantage: would apply to both spheres.
I'm just asking that people please try to be a little more precise with
the rather imprecise list language.
--Ferret
-
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/
What about 'kernel package'? was: Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, richard offer wrote: In article 91e0vj$b6alr$[EMAIL PROTECTED] you write: In article [EMAIL PROTECTED], LA Walsh [EMAIL PROTECTED] wrote: It was at that point, the externally compiled module "barfed", because like many modules, it expected, like many externally compiled modules, that it could simply access all of it's needed files through /usr/include/linux which it gets by putting /usr/include in it's path. I've seen commercial modules like vmware's kernel modules use a similar system where they expect /usr/include/linux to contain or point to headers for the currently running kernel. vmware asks you nicely where are the running kernels include files [/usr/src/linux/include" And then compiles the modules with -I/path/to/include/files In fact, the 2.2.18 kernel already puts a 'build' symlink in /lib/modules/`uname -r` that points to the kernel source, which should be sufficient to solve this problem.. almost. Don't get me started on that... The link points back to where the code was when it was built, not where it is installed. This makes a difference if you're building RPMs... in which case the link points back to (for example) /usr/src/sgi/BUILD/linux-version and not /usr/src/linux-version/. And, top it all... once the build is completed the BUILD directory is deleted. Good Idea, but poorly thought out. [snip] Once again, I'd like to suggest Debian's kernel package system as a good working example of this sort of administrative-level kernel management. I brought this up on the list once before, maybe eight months ago, but I recall not even one reply worth of discussion about it. I have a fairly basic idea of what could be done to merge part of 'make-kpkg' into the kernel-side management, but I'd like to see some other trained eyeballs taking a look. - 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: Linus's include file strategy redux
On Thu, 14 Dec 2000, Alexander Viro wrote: > > > On Thu, 14 Dec 2000, David Riley wrote: > > > Alexander Viro wrote: > > > > > > Actually, I suspect that quite a few of us had done that since long - > > > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I > > > remember what exactly it was - ISTR that it was restore(8) built with > > > 1.3. headers and playing funny games on 1.2, but it might be > > > something else... > > > > So then what's the correct header tree to put in /usr/include/linux? I > > could use the stock 2.2.14-patched headers that came with the dist, but > > how often does it need to be updated? Or should I use the latest 2.2? > > Whatever your libc was built against. It shouldn't matter that much, > but when shit hits the fan... you really don't want to be there. > > Look at it that way: you don't want to build some object files with one > set of headers, some - with another and link them together. Now, > s/some object files/libc/. With a minimal luck you will be OK, but > it's easier not to ask for trouble in the first place. Yep. At one point, about six months ago, I recompiled glibc 2.0.7(?) against 2.2.15(?) with USB backport due to occational USB v4l device-related bus locks, recompiled the v4l app I was using (w3cam package I think) and the problems mostly went away. As far as I understand it's a matter of a kernel/userland seperation. But again, sometimes you just have to update your libc. - 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: Linus's include file strategy redux
On Thu, 14 Dec 2000, Alexander Viro wrote: On Thu, 14 Dec 2000, David Riley wrote: Alexander Viro wrote: Actually, I suspect that quite a few of us had done that since long - IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I remember what exactly it was - ISTR that it was restore(8) built with 1.3.something headers and playing funny games on 1.2, but it might be something else... So then what's the correct header tree to put in /usr/include/linux? I could use the stock 2.2.14-patched headers that came with the dist, but how often does it need to be updated? Or should I use the latest 2.2? Whatever your libc was built against. It shouldn't matter that much, but when shit hits the fan... you really don't want to be there. Look at it that way: you don't want to build some object files with one set of headers, some - with another and link them together. Now, s/some object files/libc/. With a minimal luck you will be OK, but it's easier not to ask for trouble in the first place. Yep. At one point, about six months ago, I recompiled glibc 2.0.7(?) against 2.2.15(?) with USB backport due to occational USB v4l device-related bus locks, recompiled the v4l app I was using (w3cam package I think) and the problems mostly went away. As far as I understand it's a matter of a kernel/userland seperation. But again, sometimes you just have to update your libc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 not liking high disk i/o
Can you tell us what controller chipset you have (output of lspci should be fine) and if your hard drive has DMA or uDMA enabled? There have been a few other reports of oopsen and fs corruption during periods of high interrupt activity. Mine seems to occur whenever I saturate my local network with traffic to/from the machine, but it is fine if I turn DMA off (using hdparm -d0 /dev/hda) On Tue, 12 Dec 2000, Mohammad A. Haque wrote: > Hey guys, > > Any one else experiencing problems when they do lots of disk activity > in test12? > > I was able to grab the tail end of an oops. Probably not too usefull. > > Code: 89 42 04 89 10 b8 01 00 00 00 07 43 04 00 00 00 00 c7 03 00 > Aiee, killing interrupt handler > Kernel panic: Attempted to kill the idle task! > In interrupt handler - not syncing. > > If I Alt+SysRq+s I get more oops (only tails again) and if I do it > enough times it hits a BUG and reboots immediately. > -- > > = > Mohammad A. Haque http://www.haque.net/ >[EMAIL PROTECTED] > > "Alcohol and calculus don't mix. Project Lead >Don't drink and derive." --Unknown http://wm.themes.org/ >[EMAIL PROTECTED] > = > > - > 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/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 not liking high disk i/o
Can you tell us what controller chipset you have (output of lspci should be fine) and if your hard drive has DMA or uDMA enabled? There have been a few other reports of oopsen and fs corruption during periods of high interrupt activity. Mine seems to occur whenever I saturate my local network with traffic to/from the machine, but it is fine if I turn DMA off (using hdparm -d0 /dev/hda) On Tue, 12 Dec 2000, Mohammad A. Haque wrote: Hey guys, Any one else experiencing problems when they do lots of disk activity in test12? I was able to grab the tail end of an oops. Probably not too usefull. Code: 89 42 04 89 10 b8 01 00 00 00 07 43 04 00 00 00 00 c7 03 00 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In interrupt handler - not syncing. If I Alt+SysRq+s I get more oops (only tails again) and if I do it enough times it hits a BUG and reboots immediately. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/ - 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/
PROBLEM: ATAPI DMA hangs/fs corruption, on 2.4.0-test1x
1) ATAPI DMA hangs and fs corruption, Acer Aspire with 2.4.0-test1x
2) Using the 2.0.4-test1x Ali M15x3 driver in DMA transfer mode on my Acer
Aspire (Running Debian/GNU Linux) with heavy network load I get DMA
timeouts and/or (so far) minor filesystem corruption. Minor just means
that nothing important has been clobbered yet.
3) Kernel Network subsystem IDE subsystem FS corruption
4) Linux version 2.4.0-test10 (root@heathen) (gcc version 2.95.2 2220
(Debian GNU/Linux)) #1 Thu Nov 2 20:46:13 PST 2000
5) Usually there is no Oops message; the system hangs until DMA is
disabled and/or the affected fs is mounted ro. Only one time did I get an
Oops and that was followed by a spontaneous reboot.
6) Heavy bing/ping-flooding to AND from the machine during disk activity
can trigger the problem, and also heavy NFS activity (one of the machine's
fs is exported NFS). Generating graphic thumbnails (I use xv) over 1GB of
images on the remote machine on the exported NFS is also a good trigger.
7.1a) Machine with the problem:
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux tarot 2.4.0-test10 #1 Thu Nov 2 20:46:13 PST 2000 i586 unknown
Kernel modules 2.3.19
Gnu C 2.95.2
Gnu Make 3.78.1
Binutils 2.9.5.0.37
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount 2.10f
Net-tools 2.05
Kbd0.99
Sh-utils 2.0
7.1b) Machine that compiled the kernel:
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux heathen 2.4.0-test11 #1 SMP Sun Dec 3 20:40:07 PST 2000 i586 unknown
Kernel modules 2.3.21
Gnu C 2.95.2
Gnu Make 3.79.1
Binutils 2.10.1.0.2
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount 2.10q
Net-tools 2.05
Console-tools 0.2.3
Sh-utils 2.0i
7.2) Local machine:
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 4
model name : Pentium MMX
stepping: 3
cpu MHz : 232.000116
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 mmx
bogomips: 463.67
7.3) No modules loaded.
7.4)
idalton@tarot:~$ cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(set)
0376-0376 : ide1
0378-037a : parport1
03bc-03be : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0778-077a : parport1
0cf8-0cff : PCI conf1
7000-707f : VIA Technologies, Inc. VT86C100A [Rhine 10/100]
7000-707f : eth0
7400-74ff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
7800-780f : Acer Laboratories Inc. [ALi] M5219
7800-7807 : ide0
7808-780f : ide1
idalton@tarot:~$ cat /proc/iomem
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-03ff : System RAM
0010-002a6927 : Kernel code
002a6928-002c1a6f : Kernel data
0510-0510007f : VIA Technologies, Inc. VT86C100A [Rhine 10/100]
0510-0510007f : eth0
0520-05200fff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
0600-06ff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT]
0600-06ff : atyfb
0720-07200fff : Acer Laboratories Inc. [ALi] M5237 USB
0720-07200fff : usb-ohci
7.5)
idalton@tarot:~$ sudo lspci -vv
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1521 [Aladdin III] (rev
1d)
Subsystem: Acer Laboratories Inc. [ALi]: Unknown device 1521
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- 15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq
}
RawCHS=13328/15/63, TrkSize=57600, SectSize=600, ECCbytes=22
BuffType=3(DualPortCache), BuffSize=256kB, MaxMultSect=16, MultSect=16
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=0
CurCHS=13328/15/63, CurSects=12594960, LBA=yes, LBAsects=12594960
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
IORDY=on/off, tPIO={min:160,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2
Currently I am keeping DMA turned off until I have something better to
test.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please
PROBLEM: ATAPI DMA hangs/fs corruption, on 2.4.0-test1x
1) ATAPI DMA hangs and fs corruption, Acer Aspire with 2.4.0-test1x 2) Using the 2.0.4-test1x Ali M15x3 driver in DMA transfer mode on my Acer Aspire (Running Debian/GNU Linux) with heavy network load I get DMA timeouts and/or (so far) minor filesystem corruption. Minor just means that nothing important has been clobbered yet. 3) Kernel Network subsystem IDE subsystem FS corruption 4) Linux version 2.4.0-test10 (root@heathen) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Thu Nov 2 20:46:13 PST 2000 5) Usually there is no Oops message; the system hangs until DMA is disabled and/or the affected fs is mounted ro. Only one time did I get an Oops and that was followed by a spontaneous reboot. 6) Heavy bing/ping-flooding to AND from the machine during disk activity can trigger the problem, and also heavy NFS activity (one of the machine's fs is exported NFS). Generating graphic thumbnails (I use xv) over 1GB of images on the remote machine on the exported NFS is also a good trigger. 7.1a) Machine with the problem: -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux tarot 2.4.0-test10 #1 Thu Nov 2 20:46:13 PST 2000 i586 unknown Kernel modules 2.3.19 Gnu C 2.95.2 Gnu Make 3.78.1 Binutils 2.9.5.0.37 Linux C Library2.1.3 Dynamic linker ldd: version 1.9.11 Procps 2.0.6 Mount 2.10f Net-tools 2.05 Kbd0.99 Sh-utils 2.0 7.1b) Machine that compiled the kernel: -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux heathen 2.4.0-test11 #1 SMP Sun Dec 3 20:40:07 PST 2000 i586 unknown Kernel modules 2.3.21 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.10.1.0.2 Linux C Library libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.6 Mount 2.10q Net-tools 2.05 Console-tools 0.2.3 Sh-utils 2.0i 7.2) Local machine: processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 4 model name : Pentium MMX stepping: 3 cpu MHz : 232.000116 fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 mmx bogomips: 463.67 7.3) No modules loaded. 7.4) idalton@tarot:~$ cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(set) 0376-0376 : ide1 0378-037a : parport1 03bc-03be : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(set) 0778-077a : parport1 0cf8-0cff : PCI conf1 7000-707f : VIA Technologies, Inc. VT86C100A [Rhine 10/100] 7000-707f : eth0 7400-74ff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] 7800-780f : Acer Laboratories Inc. [ALi] M5219 7800-7807 : ide0 7808-780f : ide1 idalton@tarot:~$ cat /proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-03ff : System RAM 0010-002a6927 : Kernel code 002a6928-002c1a6f : Kernel data 0510-0510007f : VIA Technologies, Inc. VT86C100A [Rhine 10/100] 0510-0510007f : eth0 0520-05200fff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] 0600-06ff : ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] 0600-06ff : atyfb 0720-07200fff : Acer Laboratories Inc. [ALi] M5237 USB 0720-07200fff : usb-ohci 7.5) idalton@tarot:~$ sudo lspci -vv 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1521 [Aladdin III] (rev 1d) Subsystem: Acer Laboratories Inc. [ALi]: Unknown device 1521 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort+ SERR- PERR- Latency: 32 set 00:02.0 ISA bridge: Acer Laboratories Inc. [ALi] M1523 (rev b3) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort+ MAbort+ SERR- PERR- Latency: 0 set 00:04.0 VGA compatible controller: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 9a) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 4754 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR-
Re: [linux-fbdev] [PATCH] mdacon SMP fix
I will test this soon, hopefully. I move tomorrow, and will be bringing my
X environment and my audio environment into my dual P200 machine. This is
against which kernel? 2.4.0-test10 prepatch, or?
On Mon, 16 Oct 2000, James Simmons wrote:
>
> ANyone with a MDA card on a SMP or even UP machione please test this
> patch. This patch should fix any SMP deadlocks that could happen with
> a MDA card. Thank you.
>
> --- mdacon.c.orig Wed Oct 11 18:09:01 2000
> +++ mdacon.c Wed Oct 11 18:14:18 2000
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -44,6 +45,7 @@
> #include
> #include
>
> +static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
>
> /* description of the hardware layout */
>
> @@ -80,7 +82,6 @@
> MODULE_PARM(mda_last_vc, "1-255i");
> #endif
>
> -
> /* MDA register values
> */
>
> @@ -110,23 +111,24 @@
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port);
> outb_p(val, mda_value_port);
>
> - restore_flags(flags);
> + spin_unlock_irqrestore(_lock, flags);
> }
>
> static void write_mda_w(unsigned int val, unsigned char reg)
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port); outb_p(val >> 8, mda_value_port);
> outb_p(reg+1, mda_index_port); outb_p(val & 0xff, mda_value_port);
>
> + spin_unlock_irqrestore(_lock, flags);
> restore_flags(flags);
> }
>
> @@ -134,15 +136,14 @@
> {
> unsigned long flags;
>
> - save_flags(flags); cli();
> + spin_lock_irqsave(_lock, flags);
>
> outb_p(reg, mda_index_port);
> outb (val, mda_value_port);
>
> udelay(20); val = (inb_p(mda_value_port) == val);
>
> - restore_flags(flags);
> -
> + spin_unlock_irqrestore(_lock, flags);
> return val;
> }
>
>
Re: [linux-fbdev] [PATCH] mdacon SMP fix
I will test this soon, hopefully. I move tomorrow, and will be bringing my
X environment and my audio environment into my dual P200 machine. This is
against which kernel? 2.4.0-test10 prepatch, or?
On Mon, 16 Oct 2000, James Simmons wrote:
ANyone with a MDA card on a SMP or even UP machione please test this
patch. This patch should fix any SMP deadlocks that could happen with
a MDA card. Thank you.
--- mdacon.c.orig Wed Oct 11 18:09:01 2000
+++ mdacon.c Wed Oct 11 18:14:18 2000
@@ -37,6 +37,7 @@
#include linux/vt_kern.h
#include linux/vt_buffer.h
#include linux/selection.h
+#include linux/spinlock.h
#include linux/ioport.h
#include linux/delay.h
#include linux/init.h
@@ -44,6 +45,7 @@
#include asm/io.h
#include asm/vga.h
+static spinlock_t mda_lock = SPIN_LOCK_UNLOCKED;
/* description of the hardware layout */
@@ -80,7 +82,6 @@
MODULE_PARM(mda_last_vc, "1-255i");
#endif
-
/* MDA register values
*/
@@ -110,23 +111,24 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(mda_lock, flags);
outb_p(reg, mda_index_port);
outb_p(val, mda_value_port);
- restore_flags(flags);
+ spin_unlock_irqrestore(mda_lock, flags);
}
static void write_mda_w(unsigned int val, unsigned char reg)
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(mda_lock, flags);
outb_p(reg, mda_index_port); outb_p(val 8, mda_value_port);
outb_p(reg+1, mda_index_port); outb_p(val 0xff, mda_value_port);
+ spin_unlock_irqrestore(mda_lock, flags);
restore_flags(flags);
}
@@ -134,15 +136,14 @@
{
unsigned long flags;
- save_flags(flags); cli();
+ spin_lock_irqsave(mda_lock, flags);
outb_p(reg, mda_index_port);
outb (val, mda_value_port);
udelay(20); val = (inb_p(mda_value_port) == val);
- restore_flags(flags);
-
+ spin_unlock_irqrestore(mda_lock, flags);
return val;
}
