SMP Kernel 2.0.33 compile errors
Hi all, (Please reply to [EMAIL PROTECTED], i'm currently off the list) My current system : Tyan TomcatIII Duel Board (S1563D) Pentium Class 430 HX 2 Pentium 200 Non-MMX processors 64 mgs ram (mixed 70s/60s unfortunatly) 120 mgs swap partition 3 Hard Drives: hda: Conner Peripherals 170MB w/32kB Cache (Win95) hdb: WDC AC34000L, 3815MB w/256kB Cache (Linux 'root`) hdc: QUANTUM LPS540A, 516MB w/96kB Cache (linux) 1 CD-Rom: hdh: MATSHITA CR-581, ATAPI CDROM drive Sound Blaster 16 Card All SCSI hardware removed When compiling Linux version 2.0.33 without SMP support everything going fine. But i run into an error with SMP support included. Durring the compile it does the following: make[2]: Entering directory `/usr/src/linux/drivers/sound' gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -D__SMP__ -pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -D__SMP__ -c -o adlib_card.o adlib_card.c ( Cut for shortness ) gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -D__SMP__ -pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -D__SMP__ -c -o sound_switch.o sound_switch.c sound_switch.c: In function `init_status': sound_switch.c:97: parse error before `SOUND_CONFIG_DATE' make[2]: *** [sound_switch.o] Error 1 make[2]: Leaving directory `/usr/src/linux/drivers/sound' make[1]: *** [sub_dirs] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [linuxsubdirs] Error 2 Root [/usr/src/linux]# Now if i remove all sound support it gets this make[3]: Entering directory `/usr/src/linux/fs/fat' ( Cut for shortness ) gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -D__SMP__ -pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -D__SMP__ -c -o inode.o inode.c /usr/src/linux/include/asm/atomic.h: In function `atomic_dec_and_test': In file included from /usr/src/linux/include/linux/mm.h:15, from /usr/src/linux/include/linux/locks.h:5, from inode.c:20: /usr/src/linux/include/asm/atomic.h:62: parse error before `)' /usr/src/linux/include/asm/atomic.h:58: warning: unused variable `c' /usr/src/linux/include/asm/atomic.h:63: warning: control reaches end of non-void function /usr/src/linux/include/asm/atomic.h: At top level: /usr/src/linux/include/asm/atomic.h:63: parse error before `)' make[3]: *** [inode.o] Error 1 make[3]: Leaving directory `/usr/src/linux/fs/fat' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/fs/fat' make[1]: *** [sub_dirs] Error 2 make[1]: Leaving directory `/usr/src/linux/fs' make: *** [linuxsubdirs] Error 2 Root [/usr/src/linux]# Has anyone run into this problem? Should i continue to remove non-essential support and see if works or can i assume it is something else? Any help would appreciated with this. --Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.0.33
On Mon, Apr 06, 1998 at 10:56:09AM -0400, Lewis, James M. wrote: I tried using my old .config file from 2.0.30 and menuconfig did not show me the NLS and code page options. I had to use the default .config file and go from scratch. Also, if you don't say Y to the NLS support, the kernel won't compile. (Why have a choice if there isn't any?) Yeah, mybe a mail to linux-kernel could help? Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel 2.0.33
Since I've upgraded to this kernel(2.0.33), whenever a vfat partition is mounted, the kernel complains about not being able to find NLS charset cp437 module. I haven't found anywhere in the menuconfig options a listing for that module. Any hints as to where one can find it? -- -= Sent by Debian 1.3 Linux =- Thomas Kocourek KD4CIK @[EMAIL PROTECTED]@westgac3.dragon.com Remove @_@ for correct Email address --... ...-- ... -.. . -.- -.. - -.-. .. -.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.0.33
On Sun, Apr 05, 1998 at 09:56:01PM -0400, [EMAIL PROTECTED] wrote: Since I've upgraded to this kernel(2.0.33), whenever a vfat partition is mounted, the kernel complains about not being able to find NLS charset cp437 module. I haven't found anywhere in the menuconfig options a listing for that module. Any hints as to where one can find it? I don't use menuconfig, but if you use config, there is a question like NLS support or Native Language Support near the msdos question. If you have this, you must also say Y to the correct codepage(s) and iso charsets. Then it'll work. This is new with 2.0.33. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.0.33
On Sun, 5 Apr 1998, tko wrote: Since I've upgraded to this kernel(2.0.33), whenever a vfat partition is mounted, the kernel complains about not being able to find NLS charset cp437 module. I haven't found anywhere in the menuconfig options a listing for that module. Any hints as to where one can find it? I use xconfig. NLS charsets can be found in section 'filesystems' --- Heute ist nicht alle Tage, ich komme wieder, keine Frage!!! Joerg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: kernel 2.0.33
I tried using my old .config file from 2.0.30 and menuconfig did not show me the NLS and code page options. I had to use the default .config file and go from scratch. Also, if you don't say Y to the NLS support, the kernel won't compile. (Why have a choice if there isn't any?) jim -- From: Marcus Brinkmann[SMTP:[EMAIL PROTECTED] Sent: Monday, April 06, 1998 12:31 AM To: [EMAIL PROTECTED]; debian-user@lists.debian.org Cc: The recipient's address is unknown. Subject:Re: kernel 2.0.33 On Sun, Apr 05, 1998 at 09:56:01PM -0400, [EMAIL PROTECTED] wrote: Since I've upgraded to this kernel(2.0.33), whenever a vfat partition is mounted, the kernel complains about not being able to find NLS charset cp437 module. I haven't found anywhere in the menuconfig options a listing for that module. Any hints as to where one can find it? I don't use menuconfig, but if you use config, there is a question like NLS support or Native Language Support near the msdos question. If you have this, you must also say Y to the correct codepage(s) and iso charsets. Then it'll work. This is new with 2.0.33. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compiling kernel 2.0.33, libc6-dev
Hi, The kernel is delibrately independent of any kernel related header files you may have installed (or that libc6 uses). It is OK to compile 2.0.33 on your machine. The newer kernel-source packages do not provide kernel-headers anymore, since the kernel-source package is architecture independent, and kernel-headers actually vary between architectures. May I recommend kernel-package package from misc? It has been designed to minimize problems during a kernel compliation. Please do read /usr/soc/kernel-package/README.gz for step by step instructions and pitfalls. I shall include the Rationale for kernel-package below manoj -- What to say to annoy a performance artist: Hey, I saw something just like that on The Gong Show! Matt Groening Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E Advantages of using make-kpkg -- -- - - I have been asked several times about the advantages of using the kernel-package package over the traditional Linux way of hand compiling kernels, and I have come up with this list. This is off the top of my head, I'm sure to have missed points yet. Any additions welcomed. i) Convenience. I used to compile kernels manually, and it involved a series of steps to be taken in order; kernel-package was written to take all the required steps (it has grown beyond that now, but essentially, that is what it does). This is especially important to novices: make-kpkg takes all the steps required to compile a kernel, and installation of kernels is a snap. ii) It allows you to keep multiple version of kernel images on your machine with no fuss. iii) It has a facility for you to keep multiple flavours of the same kernel version on your machine (you could have a stable 2.0.33 version, and a 2.0.33 version patched with the latest drivers, and not worry about contaminating the modules in /lib/modules) iv) It knows that some architectures do not have vmlinuz (using vmlinux instead), and other use zImage rather than bzImage, and calls the appropriate target, and takes care of moving the correct file into place. v) Several other kernel module packages are hooked into kernel-package, so one can seamlessly compile, say, pcmcia modules at the same time as one compiles a kernel, and be assured that the modules so compiled are compatible. vi) It enables you to use the package management system to keep track of the kernels created. Using make-kpkg creates a .deb file, and dpkg can track it for you. This facilitates the task of other packages that depend on the kernel packages. vii) It keeps track of the configuration file for each kernel image in /boot, which is part of the image package, and hence is the kernel image and the configuration file are always together. viii) It allows to create a package with the headers, or the sources, also as a deb file, and enables the package management system to keep track of those (and there are packages that depend on the package management system being aware of these packages) ix) Since the kernel image package is a full fledged Debian package, it comes with maintainer scripts, which take care of details like offering to make a boot disk, manipulating symbolic links in / so that you can make boot loader scripts static (just refer to the symbolic links, rather than the real image files; the names of the symbolic links do not change, but the kernel image file names change with the version) x) There is support for the multitudinous sub architectures that have blossomed under the umbrella of the m68k architecture. xi) There is support there for optionally applying patches to the kernel provided as a kernel-patch .deb file, and building a patched kernel auto-magically, and still retain an UN-patched kernel source tree Disadvantages of using make-kpkg - -- - - i) This is a cookie cutter approach to compiling kernels, and there are people who like being close to the bare metal. ii) This is not how it is done in the non-Debian world. This flouts tradition. (It has been pointed out, though, that this is fast becoming Debian tradition) iii) It forces you to use fakeroot or sudo or super or be root to create a kernel image .deb file (this is not as bad as it used to be before fakeroot) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compiling kernel 2.0.33, libc6-dev
On 01 Apr 1998 12:27:13 CST, Manoj Srivastava wrote: Hi, The kernel is delibrately independent of any kernel related header files you may have installed (or that libc6 uses). It is OK to compile 2.0.33 on your machine. That's good. The newer kernel-source packages do not provide kernel-headers anymore, since the kernel-source package is architecture independent, and kernel-headers actually vary between architectures. Then does the kernel-* package information (whatever it's called) needs to be updated? --8- Description: Linux kernel source. This package provides the source code for the Linux kernel, as well as the scripts that maintain the symbolic link /usr/src/linux). This also contains everything in the package kernel-headers-2.0.33, and thus if you install kernel-source-2.0.33 you do not also need to install kernel-headers-2.0.33. --8- I still don't understand why libc6-dev depends on kernel-headers-2.0.32. I realize I'm almost certainly showing off my ignorance, but this seems highly counter-intuitive. Would someone please briefly explain how a programming language library depends on (of all things) kernel-headers-2.0.32? Call me what you will, this just seems silly. I'd like to uninstall kernel-header-2.0.32 now that I have kernel-headers-2.0.33 and kernel-source-2.0.33 installed, but dselect won't let me. Why do I still need kernel-headers-2.0.32? I smell something fishy going on here. May I recommend kernel-package package from misc? It has been designed to minimize problems during a kernel compliation. Please do read /usr/soc/kernel-package/README.gz for step by step instructions and pitfalls. I shall include the Rationale for kernel-package below I've used kernel-package several times and I think it's great. -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compiling kernel 2.0.33, libc6-dev
Hi,
David == David Stern [EMAIL PROTECTED] writes:
David Then does the kernel-* package information (whatever it's
David called) needs to be updated?
--8 -
David Description: Linux kernel source. This package provides the
David source code for the Linux kernel, as well as the scripts that
David maintain the symbolic link /usr/src/linux). This also contains
David everything in the package kernel-headers-2.0.33, and thus if
David you install kernel-source-2.0.33 you do not also need to
David install kernel-headers-2.0.33.
--8 -
*Groan*. Yes, I think so. Expect a new kernel-package in
Incoming shortly.
manoj
__
$Id: README.headers,v 1.5 1998/03/05 22:44:57 srivasta Exp $
This is the Debian GNU/Linux prepackaged version of the Linux kernel
headers. Linux was written by Linus Torvalds
[EMAIL PROTECTED] and others.
This package was put together by Simon Shapiro [EMAIL PROTECTED], from
sources retrieved from directories under
ftp.cs.helsinki.fi:/pub/Software/Linux/Kernel/
This package contains the Linux kernel header files.
Kernel Headers and libc6-dev package
Need for kernel include files
=== == === =
Even though GNU libc 2.0 (a.k.a. libc6) provides an uniform
interface to C programmers, one should realize that it needs
different underpinnings on different architectures and operating
systems (remember, glibc2 is multi-OS).
glibc provides all the standard files that the C standard and
POSIX require, and those in turn call in OS and platform specific
headers as required transparently to the user. There is an a complete
divorce of the kernel-level interface from the user-level interface:
the application programmer does not need to know kernel level details
at all.
But this has been taken by some to mean that
/usr/include/{linux,asm} would be superfluous, which is a technical
impossibility given that glibc2 is not an architecture and OS
specific library.
I do not believe it is easy for glibc to present an interface
that does not match the underlying OS, and quite possibly people just
punted. If there is a mismatch between the user level structures and
the kernel level structures, then libc6 library shall have to install
translating wrappers around system calls (not such a great idea for
high performance systems). I can foresee cases where it would not be
possible to implement these wrappers, given a sufficiently large set
of architectures and OS's.
In the case of Linux, the kernel header files are the
underpinnings of the architecture independent interface.
Take a simple general ANSI C include file like errno.h. This
in turn includes /usr/include/errnos.h, which includes
/usr/include/linux/errno.h, which in turn includes
/usr/include/asm/errno.h. See? A simple, standard include file like
errno.h, and one needs kernel include files for that.
Traditional two symlink approach
=== === ===
Under libc5, it was standard for part of the user interface to
libc to be exported from the kernel includes, via /usr/include/linux
and /usr/include/asm. Traditionally, this was done by linking those
two directories to the appropriate directories in
/usr/src/linux/include. This is the method documented in the install
instructions for the kernel sources, even today.
Why that is bad
=== == ===
Kernel headers no longer make sense exporting to user space
(in early days of Linux, that was not true). It is beginning to get
harder to synchronize the libc and the kernel headers as in the old
days; now linking with the latest kernel headers may subtly break new
code since the headers linked with are different from the compiled
library. In addition, the specter of programs breaking with new
kernel headers was preventing needed new features from being added to
the kernel (and damping innovative experimentation in kernel
development) (see appendix A for details).
Besides, the kernel itself no longer needs /usr/include/linux/*
at all, so keeping the libc and kernel headers the same aren't
needed for kernel development.
The headers were included in Debian's libc5-dev after a rash
of very buggy alpha kernel releases (1.3.7* or something like that)
that proceeded to break compilations, etc. Kernel versions are
changed far more rapidly than libc is, and there are higher chances
that people install a custom kernel than they install custom libc.
Add to that the fact that few programs really need the more
volatile elements of the header files (that is, things
Re: compiling kernel 2.0.33, libc6-dev
On 01 Apr 1998 16:00:51 CST, Manoj Srivastava wrote: Hi, David == David Stern [EMAIL PROTECTED] writes: David Then does the kernel-* package information (whatever it's David called) needs to be updated? --8 - David Description: Linux kernel source. This package provides the David source code for the Linux kernel, as well as the scripts that David maintain the symbolic link /usr/src/linux). This also contains David everything in the package kernel-headers-2.0.33, and thus if David you install kernel-source-2.0.33 you do not also need to David install kernel-headers-2.0.33. --8 - *Groan*. Yes, I think so. Expect a new kernel-package in Incoming shortly. I didn't mean to imply that it was that important, but according to that README (see Debian's libc6 method), it looks like that should've been changed beginning with kernel-[headers,source]-2.0.32 . That seems like such a minor issue to upload all four kernel-[headers,source]-2.0.[32,33]. I think I'll set the hold in dselect. I'd read that README previously, but didn't find it consistent. Now it makes sense. Thanks. There is still one outstanding issue: dselect won't live up to the depend in libc6-dev and allow kernel-headers-2.0.32 to be uninstalled if kernel-headers-2.0.33 is installed. Why is that? -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compiling kernel 2.0.33, libc6-dev
On Wed, 01 Apr 1998 15:11:41 PST, David Stern wrote: I didn't mean to imply that it was that important, but according to that READ ME (see Debian's libc6 method), it looks like that should've been changed b eginning with kernel-[headers,source]-2.0.32 . That seems like such a minor issue to upload all four kernel-[headers,source]-2.0.[32,33]. I think I'll s et the hold in dselect. The dreaded self-correction. Apparently, headers is alright, so I meant two packages, not four (kernel-source-2.0.[32,33]). There's also a reference to libc5-dev in the description field of both headers packages (kernel-headers-2.0.[32,33]) which looks suspicious. (Should it be libc6-dev?) -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
compiling kernel 2.0.33, libc6-dev
Hi, The 2.0.32 kernel did wonderful things for my adaptec 2940-uw, but 2.0.33 has been out for quite a while now, and I was thinking about compiling a new kernel. I'm not at all sure how libc6-dev 's dependency on stable 2.0.32 kernel-headers pertains to compiling a 2.0.33 kernel. Is 2.0.33 implicitly unstable, or can someone please clarify this matter? Also, why does the libc6-dev maintainer say that kernel-source does not provide kernel-headers, when the packages say that they do (in bug track)? Are there any other issues I should be aware of when compiling a 2.0.33 kernel, like bugs, or a new compiler I should be using? -- David Stern -- http://weber.u.washington.edu/~kotsya [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.0.33
On Mon, Mar 09, 1998 at 02:44:07PM -0300, Mario Olimpio de Menezes wrote: Can I use the 2.0.33 deb package from hamm in a bo machine without upgrade the whole system to hamm? Yes. Adam Klein -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
kernel 2.0.33 smbfs bug
Hi! there is a bug in kernel 2.0.33 which woes files' timestamp on mounted NT4 shares. There is already a bugfix patch, which seems to slip into 2.0.34. kernel-source-2.0.33-2 didn't include this patch. My questions: -shall I report this as bug or wait till kernel-*-2.0.34? -against what shall I file this bug? Regards Rainer --- KeyID=58341901 fingerprint=A5 57 04 B3 69 88 A1 FB 78 1D B5 64 E0 BF 72 EB -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
Kernel 2.0.33 questions
I recently bought an HP 7200i CD-RW, an internal EIDE device. I was wondering if 1) Kernel 2.0.33 (or perhaps one of the 2.1 series) supports CD-RW format? 2) Kernel 2.0.33 supports the Joliet extensions to ISO9660? 3) Any CD-Writer software currently available for Linux natively supports burning on an internal EIDE device? Martin Jackson: [EMAIL PROTECTED] === Information Science Major Mankato State University === -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
kernel 2.0.33
HI, Can I use the 2.0.33 deb package from hamm in a bo machine without upgrade the whole system to hamm? Thanks, []s Mario O.de MenezesMany are the plans in a man's heart, but IPEN-CNEN/SP is the Lord's purpose that prevails http://curiango.ipen.br/~mario Prov. 19.21 -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
Re: Kernel 2.0.33 questions
Martin Jackson wrote: I recently bought an HP 7200i CD-RW, an internal EIDE device. I was wondering if 1) Kernel 2.0.33 (or perhaps one of the 2.1 series) supports CD-RW format? Not a kernel issue. The kernel supports ATAPI (e/ide) devices- so if the drive reads it, it works. 2) Kernel 2.0.33 supports the Joliet extensions to ISO9660? the debian 2.0.33 kernel has the joilet patches, but they aren't in the standard 2.0.xx series kernels yet, afaik. 3) Any CD-Writer software currently available for Linux natively supports burning on an internal EIDE device? cdrecord supports it- I'm currently using cdrecoed 1.6a7 with a HP 7110i atapi cd-rw drive just fine. It supports cd-r[w] media just fine. -- E-mail the word unsubscribe to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED] .
