Re: Alan Cox quote? (was: Re: accounting for threads)
>>>>> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes: >>>>> "MC" == Mike Castle <[EMAIL PROTECTED]> writes: MC> What about the "UNIX is starting to smell bad" comment? :-> GN> I believe that it comes from a paper that Pike presented at a GN> OSDI (or the Usenix general) last year on the theme of OS GN> Research being dead. Links to it were also posted on /. around GN> that time... Oops. I was wrong. I found the presentation I was referring to and it doesn't have this quote. Sorry, I'll get my pattern matching unit looked at pronto. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> "MC" == Mike Castle <[EMAIL PROTECTED]> writes: MC> What about the "UNIX is starting to smell bad" comment? :-> I believe that it comes from a paper that Pike presented at a OSDI (or the Usenix general) last year on the theme of OS Research being dead. Links to it were also posted on /. around that time... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
MC == Mike Castle [EMAIL PROTECTED] writes: MC What about the UNIX is starting to smell bad comment? :- I believe that it comes from a paper that Pike presented at a OSDI (or the Usenix general) last year on the theme of OS Research being dead. Links to it were also posted on /. around that time... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
GN == Georg Nikodym [EMAIL PROTECTED] writes: MC == Mike Castle [EMAIL PROTECTED] writes: MC What about the UNIX is starting to smell bad comment? :- GN I believe that it comes from a paper that Pike presented at a GN OSDI (or the Usenix general) last year on the theme of OS GN Research being dead. Links to it were also posted on /. around GN that time... Oops. I was wrong. I found the presentation I was referring to and it doesn't have this quote. Sorry, I'll get my pattern matching unit looked at pronto. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac13, APM, and Dell Inspiron 8000
I've been running 2.4.5 on my new Dell I8000 without too many problems. Last night I built -ac13 (on my porch) and booted it without incident. Later, going inside and re-connecting the AC I notice that the thing's hung. I play around a bit and discover that the act of plugging or unplugging the power cord will hang the box. This lead me to disable all power manglement in the BIOS. No joy. This problem does not exist using straight 2.4.5. Has anybody else seen this? Any debugging suggestions? Or stated differently, has anybody with this machine arrived at a configuration that avoids weirdness in the power management framework? In case it's interesting, here's the lspci output: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03) 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP 02:03.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10) 02:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) 02:0f.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 8027 03:00.0 Ethernet controller: 3Com Corporation 3CCFE575BT Cyclone CardBus (rev 01) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac13, APM, and Dell Inspiron 8000
I've been running 2.4.5 on my new Dell I8000 without too many problems. Last night I built -ac13 (on my porch) and booted it without incident. Later, going inside and re-connecting the AC I notice that the thing's hung. I play around a bit and discover that the act of plugging or unplugging the power cord will hang the box. This lead me to disable all power manglement in the BIOS. No joy. This problem does not exist using straight 2.4.5. Has anybody else seen this? Any debugging suggestions? Or stated differently, has anybody with this machine arrived at a configuration that avoids weirdness in the power management framework? In case it's interesting, here's the lspci output: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03) 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP 02:03.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10) 02:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) 02:0f.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 8027 03:00.0 Ethernet controller: 3Com Corporation 3CCFE575BT Cyclone CardBus (rev 01) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Minor addition to pci.ids
For a cPCI card I'm working with... Cheers. --- 1.23.1.1/drivers/pci/pci.idsSun Mar 25 13:14:20 2001 +++ 1.25/drivers/pci/pci.idsMon Apr 9 11:46:36 2001 @@ -920,6 +920,7 @@ ac51 PCI1420 ac52 PCI1451 PC card Cardbus Controller ac53 PCI1421 PC card Cardbus Controller + ac60 PCI2040 PCI to DSP Bridge Controller fe00 FireWire Host Controller fe03 12C01A FireWire Host Controller 104d Sony Corporation - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Minor addition to pci.ids
For a cPCI card I'm working with... Cheers. --- 1.23.1.1/drivers/pci/pci.idsSun Mar 25 13:14:20 2001 +++ 1.25/drivers/pci/pci.idsMon Apr 9 11:46:36 2001 @@ -920,6 +920,7 @@ ac51 PCI1420 ac52 PCI1451 PC card Cardbus Controller ac53 PCI1421 PC card Cardbus Controller + ac60 PCI2040 PCI to DSP Bridge Controller fe00 FireWire Host Controller fe03 12C01A FireWire Host Controller 104d Sony Corporation - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
> "MBT" == Michael B Trausch <[EMAIL PROTECTED]> writes: MBT> Is this fixable the "right" way? On my box, which started its life as a RH7, I've been editing /etc/security/console.perms as I've discovered problems. I don't know if this is the right way but thus far I've: - changed the line to read: =tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] (just added the vc/... pattern) - changed the line to read: =/dev/cdroms/* /dev/cdwriter* (removed the /dev/cdrom* and added /dev/cdroms/*) I have not had reason (ie. xmms works) to change the sound settings, which are: =/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer Hope that helps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
> "M" == Meunier writes: M> Not true. I'm pretty sure /dev/.devfsd is only created when you M> mount devfs at boot time or via mount -t devfs devfs /dev in your M> system initialization script. Creating /dev/.devfsd with touch M> defeats the purpose of /etc/rc.sysinit example. Right you are. I looked at all this stuff _before_ I had devfs mounted. It never occured to me that "-e /dev/.devfsd" had a connotation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
"M" == Meunier iso-8859-1 writes: M Not true. I'm pretty sure /dev/.devfsd is only created when you M mount devfs at boot time or via mount -t devfs devfs /dev in your M system initialization script. Creating /dev/.devfsd with touch M defeats the purpose of /etc/rc.sysinit example. Right you are. I looked at all this stuff _before_ I had devfs mounted. It never occured to me that "-e /dev/.devfsd" had a connotation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
"MBT" == Michael B Trausch [EMAIL PROTECTED] writes: MBT Is this fixable the "right" way? On my box, which started its life as a RH7, I've been editing /etc/security/console.perms as I've discovered problems. I don't know if this is the right way but thus far I've: - changed the console line to read: console=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] (just added the vc/... pattern) - changed the cdrom line to read: cdrom=/dev/cdroms/* /dev/cdwriter* (removed the /dev/cdrom* and added /dev/cdroms/*) I have not had reason (ie. xmms works) to change the sound settings, which are: sound=/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer Hope that helps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
> "hm" == hiren mehta <[EMAIL PROTECTED]> writes: hm> Hi, I am trying to compile devfsd on my system running RedHat hm> linux 7.0 (kernel 2.2.16-22). I get the error "RTLD_NEXT" hm> undefined. I am not sure where this symbol is defined. Is there hm> anything that I am missing on my system. Oh yeah, here's the two other things I forgot. The install target of the devfsd GNUmakefile attempts to copy the devfsd.8 man page into /usr/man/man8 which doesn't exist. RH7 has its man pages in /usr/share/man though you might prefer /usr/local/man, whatever. I just changed the GNUmakefile. Also, RH7's /etc/rc.sysinit can already start devfsd automatically with the following line: [ -e /dev/.devfsd -a -x /sbin/devfsd ] && /sbin/devfsd /dev So, all you have to do is create an empty file /dev/.devfsd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
> "hm" == hiren mehta <[EMAIL PROTECTED]> writes: hm> Hi, I am trying to compile devfsd on my system running RedHat hm> linux 7.0 (kernel 2.2.16-22). I get the error "RTLD_NEXT" hm> undefined. I am not sure where this symbol is defined. Is there hm> anything that I am missing on my system. make CEXTRAS=-D_GNU_SOURCE is one way to get around this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
> "JJ" == John Jasen <[EMAIL PROTECTED]> writes: JJ> On Thu, 1 Feb 2001, William Knop wrote: >> >One thing that I've noticed with devfs is that all the old-style >> >names are symlinks. >> >> Hmm... I have no symlinks until the module loads. Therefore X sees >> no /dev/input/mouse, doesn't ask the kernel for it, the kernel >> doesn't load the module, and DevFS doesn't add the /dev >> entry. There's got to be an easy way around this. Perhaps it has >> already been implimented, but I haven't been able to get anything >> to work well (manual loading for me). JJ> change your XF86Config file to point to /dev/psaux Or /dev/input/mice if you use a USB thang. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modules and DevFS
"JJ" == John Jasen [EMAIL PROTECTED] writes: JJ On Thu, 1 Feb 2001, William Knop wrote: One thing that I've noticed with devfs is that all the old-style names are symlinks. Hmm... I have no symlinks until the module loads. Therefore X sees no /dev/input/mouse, doesn't ask the kernel for it, the kernel doesn't load the module, and DevFS doesn't add the /dev entry. There's got to be an easy way around this. Perhaps it has already been implimented, but I haven't been able to get anything to work well (manual loading for me). JJ change your XF86Config file to point to /dev/psaux Or /dev/input/mice if you use a USB thang. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
"hm" == hiren mehta [EMAIL PROTECTED] writes: hm Hi, I am trying to compile devfsd on my system running RedHat hm linux 7.0 (kernel 2.2.16-22). I get the error "RTLD_NEXT" hm undefined. I am not sure where this symbol is defined. Is there hm anything that I am missing on my system. make CEXTRAS=-D_GNU_SOURCE is one way to get around this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with devfsd compilation
"hm" == hiren mehta [EMAIL PROTECTED] writes: hm Hi, I am trying to compile devfsd on my system running RedHat hm linux 7.0 (kernel 2.2.16-22). I get the error "RTLD_NEXT" hm undefined. I am not sure where this symbol is defined. Is there hm anything that I am missing on my system. Oh yeah, here's the two other things I forgot. The install target of the devfsd GNUmakefile attempts to copy the devfsd.8 man page into /usr/man/man8 which doesn't exist. RH7 has its man pages in /usr/share/man though you might prefer /usr/local/man, whatever. I just changed the GNUmakefile. Also, RH7's /etc/rc.sysinit can already start devfsd automatically with the following line: [ -e /dev/.devfsd -a -x /sbin/devfsd ] /sbin/devfsd /dev So, all you have to do is create an empty file /dev/.devfsd - 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: Possible Bug: drivers/sound/maestro.c
> "MBT" == Michael B Trausch <[EMAIL PROTECTED]> writes: MBT> I've been using this driver and this hardware since I started MBT> running Kernel 2.2.16. It _works_, however, whenever I have a MBT> program that I compile that's especially large (the kernel, MBT> glibc, etc.), or copy/move lots of files around, the driver MBT> starts to fuzz lots of the sound going to the card - even after MBT> the activity causing the load has stopped. It happens in both MBT> the left and the right channel, and the only way to resolve it MBT> is to kill the process with /dev/dsp open (typically mpg123), MBT> and then start it again. FWIW, I too was having this kind of problem. When I starting living on 2.4.x kernels the problem went away. Also gone were sound dropping out when I busied my machine with compiles things. Of course, I'm omitting the irrelevant detail of the absence of the pci_enable_dev() call 2.4.0-testX where X<12 which caused the driver to not work at all. - 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: Possible Bug: drivers/sound/maestro.c
"MBT" == Michael B Trausch [EMAIL PROTECTED] writes: MBT I've been using this driver and this hardware since I started MBT running Kernel 2.2.16. It _works_, however, whenever I have a MBT program that I compile that's especially large (the kernel, MBT glibc, etc.), or copy/move lots of files around, the driver MBT starts to fuzz lots of the sound going to the card - even after MBT the activity causing the load has stopped. It happens in both MBT the left and the right channel, and the only way to resolve it MBT is to kill the process with /dev/dsp open (typically mpg123), MBT and then start it again. FWIW, I too was having this kind of problem. When I starting living on 2.4.x kernels the problem went away. Also gone were sound dropping out when I busied my machine with compiles things. Of course, I'm omitting the irrelevant detail of the absence of the pci_enable_dev() call 2.4.0-testX where X12 which caused the driver to not work at all. - 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/
Driver migration question
So, rather than repeated ask questions of the form: How do I change X (a 2.2 thingy in my driver) to the blessed form on 2.4.x? I'm wondering if there's a driver in the kernel tree that somebody can point to and say, "This is how drivers should be done." In particular, I'm interested in networking drivers but any non-trivial driver will do. - 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/
Driver migration question
So, rather than repeated ask questions of the form: How do I change X (a 2.2 thingy in my driver) to the blessed form on 2.4.x? I'm wondering if there's a driver in the kernel tree that somebody can point to and say, "This is how drivers should be done." In particular, I'm interested in networking drivers but any non-trivial driver will do. - 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?] Coding Style
> "CF" == Christopher Friesen <[EMAIL PROTECTED]> writes: CF> This is why the autocompletion of functions and struct members in CF> VC++ is awfully nice...hit the first few unique letters and it CF> will complete the rest of the function for you, then hit tab and CF> keep going. Is there anything with that functionality under CF> Linux? Yup. Emacs users can use the mis-named dynamic abbreviation function (daddrev-expand which I have mapped to M-/). - 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?] Coding Style
> "MH" == Mike Harrold <[EMAIL PROTECTED]> writes: MH> For exactly the reverse of that reason. Typing capital letters is MH> a heck of a lot more difficult that addint an underscore. MH> Then there is reasability. MH> void ThisIsMyDumbassFunctionName MH> if MUCH more difficult to read than MH> void this_is_my_clear_and_easy_function_name I think that the distinction is moot and this argument a waste of time. If you are anything more than a code tourist, you should have no trouble dealing with mnemonic names. So the above can become: /* * timcaefn == this is my clear and easy function name */ void timcaefn (void); If you're at all concerned about RSI, your fingers will thank you. :-) :-) :-) - 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?] Coding Style
"MH" == Mike Harrold [EMAIL PROTECTED] writes: MH For exactly the reverse of that reason. Typing capital letters is MH a heck of a lot more difficult that addint an underscore. MH Then there is reasability. MH void ThisIsMyDumbassFunctionName MH if MUCH more difficult to read than MH void this_is_my_clear_and_easy_function_name I think that the distinction is moot and this argument a waste of time. If you are anything more than a code tourist, you should have no trouble dealing with mnemonic names. So the above can become: /* * timcaefn == this is my clear and easy function name */ void timcaefn (void); If you're at all concerned about RSI, your fingers will thank you. :-) :-) :-) - 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?] Coding Style
"CF" == Christopher Friesen [EMAIL PROTECTED] writes: CF This is why the autocompletion of functions and struct members in CF VC++ is awfully nice...hit the first few unique letters and it CF will complete the rest of the function for you, then hit tab and CF keep going. Is there anything with that functionality under CF Linux? Yup. Emacs users can use the mis-named dynamic abbreviation function (daddrev-expand which I have mapped to M-/). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> Looks good, except that you need to keep the option flags for
KO> backwards compatibility. There are a *lot* of scripts out there
KO> which invoke klogd with various options and they will fail with
KO> this change. It is OK to issue a warning message "klogd options
KO> -[iIpkx] are no longer supported" as long as klogd continues to
KO> run. Otherwise you will get a lot of irate users complaining
KO> that klogd is failing at boot time.
You're right. Here's YAP:
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Mon Dec 11 20:50:49 2000
+++ b/src/sysklogd-1.3-31/klogd.c Mon Dec 11 20:50:49 2000
@@ -763,7 +763,7 @@
chdir ("/");
#endif
/* Parse the command-line. */
- while ((ch = getopt(argc, argv, "c:df:nosv")) != EOF)
+ while ((ch = getopt(argc, argv, "c:df:nosviIk:px")) != EOF)
switch((char)ch)
{
case 'c': /* Set console message level. */
@@ -788,6 +788,20 @@
case 'v':
printf("klogd %s-%s\n", VERSION, PATCHLEVEL);
exit (1);
+
+ /* Obsolete options */
+ case 'i':
+ /* FALLTHRU */
+ case 'I':
+ /* FALLTHRU */
+ case 'k':
+ /* FALLTHRU */
+ case 'p':
+ /* FALLTHRU */
+ case 'x':
+ fprintf(stderr,
+ "klogd: %c option is obsolete. Ignoring\n", ch);
+ break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
>>>>> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes:
GN> Here's a patch (against sysklogd-1.3-31) that completely tear out
GN> the symbol processing code.
Doh! Forgot a chunk (to be applied after the others):
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Mon Dec 11 20:28:24 2000
+++ b/src/sysklogd-1.3-31/Makefile Mon Dec 11 20:28:24 2000
@@ -63,8 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
>>>>> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> klogd maps the kernel messages from text to syslog levels and
KO> does some fiddling with kernel log levels at start up. It needs
KO> to be more than a simple 'cat'. When symbol handling was added
KO> to klogd, ksymoops was built into the kernel and very unreliable.
KO> Since then ksymoops has been moved to a separate package and is
KO> now reliable. Alas oops handling in sysklogd has not kept up to
KO> date and is now the problem area.
Thanks for the background.
KO> Linus, please do not apply.
KO> User space applications _must_ not include kernel headers. Even
KO> modutils does not include linux/module.h, it has its own portable
KO> (kernels 2.0 - 2.4) version.
KO> I have strongly recommended to the sysklogd maintainers that they
KO> strip all the symbol handling from klogd. The oops decoding in
KO> klogd is hopelessly out of date and broken.
Here's a patch (against sysklogd-1.3-31) that completely tear out the
symbol processing code.
Additionally, after application, the following files may be removed:
ksyms.h
ksym.c
ksym_mod.c
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Mon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/Makefile Mon Dec 11 19:32:22 2000
@@ -63,9 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o ksym_mod.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o \
- ksym_mod.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o ksym.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Mon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/klogd.c Mon Dec 11 19:32:22 2000
@@ -415,7 +415,6 @@
if (symbol_lookup) {
if ( reload_symbols > 1 )
InitKsyms(symfile);
- InitMsyms();
}
reload_symbols = change_state = 0;
return;
@@ -1059,7 +1058,6 @@
{
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
if ( (logsrc = GetKernelLogSrc()) == kernel )
LogKernelLine();
@@ -1075,7 +1073,6 @@
logsrc = GetKernelLogSrc();
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
/* The main loop. */
diff -Nru a/src/sysklogd-1.3-31/ksym.c b/src/sysklogd-1.3-31/ksym.c
--- a/src/sysklogd-1.3-31/ksym.cMon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/ksym.cMon Dec 11 19:32:22 2000
@@ -656,9 +656,6 @@
last = sym_array[lp].name;
}
- if ( (last = LookupModuleSymbol(value, sym)) != (char *) 0 )
- return(last);
-
return((char *) 0);
}
@@ -749,7 +746,7 @@
* open for patches.
*/
if ( i_am_paranoid &&
-(strstr(line, "Oops:") != (char *) 0) && !InitMsyms() )
+(strstr(line, "Oops:") != (char *) 0) )
Syslog(LOG_WARNING, "Cannot load kernel module symbols.\n");
diff -Nru a/src/sysklogd-1.3-31/ksyms.h b/src/sysklogd-1.3-31/ksyms.h
--- a/src/sysklogd-1.3-31/ksyms.h Mon Dec 11 19:32:23 2000
+++ b/src/sysklogd-1.3-31/ksyms.h Mon Dec 11 19:32:23 2000
@@ -32,4 +32,3 @@
/* Function prototypes. */
extern char * LookupSymbol(unsigned long, struct symbol *);
-extern char * LookupModuleSymbol(unsigned long int, struct symbol *);
diff -Nru a/src/sysklogd-1.3-31/klogd.8 b/src/sysklogd-1.3-31/klogd.8
--- a/src/sysklogd-1.3-31/klogd.8 Mon Dec 11 19:32:23 2000
+++ b/src/sysklogd-1.3-31/klogd.8 Mon Dec 11 19:32:23 2000
@@ -3,6 +3,8 @@
.\" Sun Jul 30 01:35:55 MET: Martin Schulze: Updates
.\" Sun Nov 19 23:22:21 MET: Martin Schulze: Updates
.\" Mon Aug 19 09:42:08 CDT 1996: Dr. G.W. Wettstein: Updates
+.\" Mon Dec 11 2000: Georg Nikodym: Removal of documentation related to
+.\" symbol resolution (the code has been removed).
.\"
.TH KLOGD 8 "24 November 1995" "Version 1.3" "Linux System Administration"
.SH NAME
@@ -17,16 +19,10 @@
.RB [ " \-f "
.I fname
]
-.RB [ " \-iI " ]
.RB [ " \-n " ]
.RB [ " \-o " ]
-.RB [ " \-p " ]
.RB [ " \-s " ]
-.RB [ " \-k "
-.I fname
-]
.RB [ " \-v " ]
-.RB [ " \-x " ]
.LP
.SH DESCRIPTION
.B klogd
@@ -45,12 +41,6 @@
.BI "\-f " file
Log mess
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO klogd maps the kernel messages from ntext to syslog levels and
KO does some fiddling with kernel log levels at start up. It needs
KO to be more than a simple 'cat'. When symbol handling was added
KO to klogd, ksymoops was built into the kernel and very unreliable.
KO Since then ksymoops has been moved to a separate package and is
KO now reliable. Alas oops handling in sysklogd has not kept up to
KO date and is now the problem area.
Thanks for the background.
KO Linus, please do not apply.
KO User space applications _must_ not include kernel headers. Even
KO modutils does not include linux/module.h, it has its own portable
KO (kernels 2.0 - 2.4) version.
KO I have strongly recommended to the sysklogd maintainers that they
KO strip all the symbol handling from klogd. The oops decoding in
KO klogd is hopelessly out of date and broken.
Here's a patch (against sysklogd-1.3-31) that completely tear out the
symbol processing code.
Additionally, after application, the following files may be removed:
ksyms.h
ksym.c
ksym_mod.c
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Mon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/Makefile Mon Dec 11 19:32:22 2000
@@ -63,9 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o ksym_mod.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o \
- ksym_mod.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o ksym.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Mon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/klogd.c Mon Dec 11 19:32:22 2000
@@ -415,7 +415,6 @@
if (symbol_lookup) {
if ( reload_symbols 1 )
InitKsyms(symfile);
- InitMsyms();
}
reload_symbols = change_state = 0;
return;
@@ -1059,7 +1058,6 @@
{
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
if ( (logsrc = GetKernelLogSrc()) == kernel )
LogKernelLine();
@@ -1075,7 +1073,6 @@
logsrc = GetKernelLogSrc();
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
/* The main loop. */
diff -Nru a/src/sysklogd-1.3-31/ksym.c b/src/sysklogd-1.3-31/ksym.c
--- a/src/sysklogd-1.3-31/ksym.cMon Dec 11 19:32:22 2000
+++ b/src/sysklogd-1.3-31/ksym.cMon Dec 11 19:32:22 2000
@@ -656,9 +656,6 @@
last = sym_array[lp].name;
}
- if ( (last = LookupModuleSymbol(value, sym)) != (char *) 0 )
- return(last);
-
return((char *) 0);
}
@@ -749,7 +746,7 @@
* open for patches.
*/
if ( i_am_paranoid
-(strstr(line, "Oops:") != (char *) 0) !InitMsyms() )
+(strstr(line, "Oops:") != (char *) 0) )
Syslog(LOG_WARNING, "Cannot load kernel module symbols.\n");
diff -Nru a/src/sysklogd-1.3-31/ksyms.h b/src/sysklogd-1.3-31/ksyms.h
--- a/src/sysklogd-1.3-31/ksyms.h Mon Dec 11 19:32:23 2000
+++ b/src/sysklogd-1.3-31/ksyms.h Mon Dec 11 19:32:23 2000
@@ -32,4 +32,3 @@
/* Function prototypes. */
extern char * LookupSymbol(unsigned long, struct symbol *);
-extern char * LookupModuleSymbol(unsigned long int, struct symbol *);
diff -Nru a/src/sysklogd-1.3-31/klogd.8 b/src/sysklogd-1.3-31/klogd.8
--- a/src/sysklogd-1.3-31/klogd.8 Mon Dec 11 19:32:23 2000
+++ b/src/sysklogd-1.3-31/klogd.8 Mon Dec 11 19:32:23 2000
@@ -3,6 +3,8 @@
.\" Sun Jul 30 01:35:55 MET: Martin Schulze: Updates
.\" Sun Nov 19 23:22:21 MET: Martin Schulze: Updates
.\" Mon Aug 19 09:42:08 CDT 1996: Dr. G.W. Wettstein: Updates
+.\" Mon Dec 11 2000: Georg Nikodym: Removal of documentation related to
+.\" symbol resolution (the code has been removed).
.\"
.TH KLOGD 8 "24 November 1995" "Version 1.3" "Linux System Administration"
.SH NAME
@@ -17,16 +19,10 @@
.RB [ " \-f "
.I fname
]
-.RB [ " \-iI " ]
.RB [ " \-n " ]
.RB [ " \-o " ]
-.RB [ " \-p " ]
.RB [ " \-s " ]
-.RB [ " \-k "
-.I fname
-]
.RB [ " \-v " ]
-.RB [ " \-x " ]
.LP
.SH DESCRIPTION
.B klogd
@@ -45,12 +41,6 @@
.BI "\-f " file
Log messages to the specified filename rather than to the syslog facility.
.TP
-.BI "\-i \-I"
-Signal th
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"GN" == Georg Nikodym [EMAIL PROTECTED] writes:
GN Here's a patch (against sysklogd-1.3-31) that completely tear out
GN the symbol processing code.
Doh! Forgot a chunk (to be applied after the others):
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Mon Dec 11 20:28:24 2000
+++ b/src/sysklogd-1.3-31/Makefile Mon Dec 11 20:28:24 2000
@@ -63,8 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO Looks good, except that you need to keep the option flags for
KO backwards compatibility. There are a *lot* of scripts out there
KO which invoke klogd with various options and they will fail with
KO this change. It is OK to issue a warning message "klogd options
KO -[iIpkx] are no longer supported" as long as klogd continues to
KO run. Otherwise you will get a lot of irate users complaining
KO that klogd is failing at boot time.
You're right. Here's YAP:
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Mon Dec 11 20:50:49 2000
+++ b/src/sysklogd-1.3-31/klogd.c Mon Dec 11 20:50:49 2000
@@ -763,7 +763,7 @@
chdir ("/");
#endif
/* Parse the command-line. */
- while ((ch = getopt(argc, argv, "c:df:nosv")) != EOF)
+ while ((ch = getopt(argc, argv, "c:df:nosviIk:px")) != EOF)
switch((char)ch)
{
case 'c': /* Set console message level. */
@@ -788,6 +788,20 @@
case 'v':
printf("klogd %s-%s\n", VERSION, PATCHLEVEL);
exit (1);
+
+ /* Obsolete options */
+ case 'i':
+ /* FALLTHRU */
+ case 'I':
+ /* FALLTHRU */
+ case 'k':
+ /* FALLTHRU */
+ case 'p':
+ /* FALLTHRU */
+ case 'x':
+ fprintf(stderr,
+ "klogd: %c option is obsolete. Ignoring\n", ch);
+ break;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes: KO> You only removed the module symbol handling. The problem is that KO> the entire klogd oops handling is out of date and broken. I KO> recommend removing all oops processing from klogd, which means KO> that klogd does not need any symbols nor System.map. You're right. My goal was to quickly get our build working again. I had no expectation that anybody else on the planet would give a crap about my patch... But since you seem to and while we're doing extreme surgery, why have klogd at all? Every other unix, kernel messages are handled by the syslog system. What problem did klogd solve and does that problem still exist today? Stated differently, aren't you just proposing to reduce klogd to: cat < /proc/kmsg > /dev/log & (I know that this won't work on my box, but you get the idea) Anyway, I'll look into simplifying klogd as you suggest... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"KO" == Keith Owens [EMAIL PROTECTED] writes: KO You only removed the module symbol handling. The problem is that KO the entire klogd oops handling is out of date and broken. I KO recommend removing all oops processing from klogd, which means KO that klogd does not need any symbols nor System.map. You're right. My goal was to quickly get our build working again. I had no expectation that anybody else on the planet would give a crap about my patch... But since you seem to and while we're doing extreme surgery, why have klogd at all? Every other unix, kernel messages are handled by the syslog system. What problem did klogd solve and does that problem still exist today? Stated differently, aren't you just proposing to reduce klogd to: cat /proc/kmsg /dev/log (I know that this won't work on my box, but you get the idea) Anyway, I'll look into simplifying klogd as you suggest... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> I would prefer to see the oops decoding completely removed from
KO> klogd. The only justification for klogd converting the oops is
KO> to save users from running ksymoops by hand. I would not mind
KO> klogd capturing the oops text, forking to run ksymoops then
KO> logging the ksymoops output. Just as along as the original text
KO> was left alone and the ksymoops output was obviously
KO> distinguished from real kernel output.
Since nobody else has weighed in on this issue, I quickly did the
necessary to effect Keith's suggestion. What follows is a patch to
sysklogd-1.3-31 (which after applying, ksym_mod.c can be removed):
# This is a BitKeeper generated patch for the following project:
# Project Name: Trans-lab fsimage sub-gate
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.60-> 1.62
# src/sysklogd-1.3-31/ksym.c 1.1 -> 1.2
# src/sysklogd-1.3-31/klogd.c 1.1 -> 1.2
# src/sysklogd-1.3-31/ksyms.h 1.1 -> 1.2
# src/sysklogd-1.3-31/Makefile1.1 -> 1.2
#
# The following is the BitKeeper ChangeSet Log
#
# 00/12/07 [EMAIL PROTECTED] 1.61
# Remove ksym_mod.c to fix sysklogd build
#
# 00/12/07 [EMAIL PROTECTED] 1.62
# Remove a remaining prototype associated with the now deleted ksym_mod.c
#
#
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
@@ -63,9 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o ksym_mod.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o \
- ksym_mod.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o ksym.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
@@ -415,7 +415,6 @@
if (symbol_lookup) {
if ( reload_symbols > 1 )
InitKsyms(symfile);
- InitMsyms();
}
reload_symbols = change_state = 0;
return;
@@ -1059,7 +1058,6 @@
{
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
if ( (logsrc = GetKernelLogSrc()) == kernel )
LogKernelLine();
@@ -1075,7 +1073,6 @@
logsrc = GetKernelLogSrc();
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
/* The main loop. */
diff -Nru a/src/sysklogd-1.3-31/ksym.c b/src/sysklogd-1.3-31/ksym.c
--- a/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
@@ -656,9 +656,6 @@
last = sym_array[lp].name;
}
- if ( (last = LookupModuleSymbol(value, sym)) != (char *) 0 )
- return(last);
-
return((char *) 0);
}
@@ -749,7 +746,7 @@
* open for patches.
*/
if ( i_am_paranoid &&
-(strstr(line, "Oops:") != (char *) 0) && !InitMsyms() )
+(strstr(line, "Oops:") != (char *) 0) )
Syslog(LOG_WARNING, "Cannot load kernel module symbols.\n");
diff -Nru a/src/sysklogd-1.3-31/ksyms.h b/src/sysklogd-1.3-31/ksyms.h
--- a/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
@@ -32,4 +32,3 @@
/* Function prototypes. */
extern char * LookupSymbol(unsigned long, struct symbol *);
-extern char * LookupModuleSymbol(unsigned long int, struct symbol *);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO I would prefer to see the oops decoding completely removed from
KO klogd. The only justification for klogd converting the oops is
KO to save users from running ksymoops by hand. I would not mind
KO klogd capturing the oops text, forking to run ksymoops then
KO logging the ksymoops output. Just as along as the original text
KO was left alone and the ksymoops output was obviously
KO distinguished from real kernel output.
Since nobody else has weighed in on this issue, I quickly did the
necessary to effect Keith's suggestion. What follows is a patch to
sysklogd-1.3-31 (which after applying, ksym_mod.c can be removed):
# This is a BitKeeper generated patch for the following project:
# Project Name: Trans-lab fsimage sub-gate
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.60- 1.62
# src/sysklogd-1.3-31/ksym.c 1.1 - 1.2
# src/sysklogd-1.3-31/klogd.c 1.1 - 1.2
# src/sysklogd-1.3-31/ksyms.h 1.1 - 1.2
# src/sysklogd-1.3-31/Makefile1.1 - 1.2
#
# The following is the BitKeeper ChangeSet Log
#
# 00/12/07 [EMAIL PROTECTED] 1.61
# Remove ksym_mod.c to fix sysklogd build
#
# 00/12/07 [EMAIL PROTECTED] 1.62
# Remove a remaining prototype associated with the now deleted ksym_mod.c
#
#
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
@@ -63,9 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o ksym_mod.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o \
- ksym_mod.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o ksym.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
@@ -415,7 +415,6 @@
if (symbol_lookup) {
if ( reload_symbols 1 )
InitKsyms(symfile);
- InitMsyms();
}
reload_symbols = change_state = 0;
return;
@@ -1059,7 +1058,6 @@
{
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
if ( (logsrc = GetKernelLogSrc()) == kernel )
LogKernelLine();
@@ -1075,7 +1073,6 @@
logsrc = GetKernelLogSrc();
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
/* The main loop. */
diff -Nru a/src/sysklogd-1.3-31/ksym.c b/src/sysklogd-1.3-31/ksym.c
--- a/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
@@ -656,9 +656,6 @@
last = sym_array[lp].name;
}
- if ( (last = LookupModuleSymbol(value, sym)) != (char *) 0 )
- return(last);
-
return((char *) 0);
}
@@ -749,7 +746,7 @@
* open for patches.
*/
if ( i_am_paranoid
-(strstr(line, "Oops:") != (char *) 0) !InitMsyms() )
+(strstr(line, "Oops:") != (char *) 0) )
Syslog(LOG_WARNING, "Cannot load kernel module symbols.\n");
diff -Nru a/src/sysklogd-1.3-31/ksyms.h b/src/sysklogd-1.3-31/ksyms.h
--- a/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
@@ -32,4 +32,3 @@
/* Function prototypes. */
extern char * LookupSymbol(unsigned long, struct symbol *);
-extern char * LookupModuleSymbol(unsigned long int, struct symbol *);
-
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/
linux-2.4.0-test11 and sysklogd-1.3-31
sysklogd 1.3-31 no longer compiles using the latest headers in test11. Strictly speaking this isn't a kernel bug... sysklogd's ksym_mod.c includes In test11, added struct inter_module_entry. Its first member is "struct list_head list;". This necessitates the inclusion of . The trouble is that is almost completely protected by #ifdef __KERNEL__. sysklogd, obviously, doesn't compile with __KERNEL__ so the struct inter_module_entry declaration is impossible and the compilation fails. It's not clear to me who's code needs changing so I'm sending both to linux-kernel and to some of the people that have the misfortune of being listed on the sysklogd man page. - 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/
linux-2.4.0-test11 and sysklogd-1.3-31
sysklogd 1.3-31 no longer compiles using the latest headers in test11. Strictly speaking this isn't a kernel bug... sysklogd's ksym_mod.c includes linux/module.h In test11, linux/module.h added struct inter_module_entry. Its first member is "struct list_head list;". This necessitates the inclusion of linux/list.h. The trouble is that linux/list.h is almost completely protected by #ifdef __KERNEL__. sysklogd, obviously, doesn't compile with __KERNEL__ so the struct inter_module_entry declaration is impossible and the compilation fails. It's not clear to me who's code needs changing so I'm sending both to linux-kernel and to some of the people that have the misfortune of being listed on the sysklogd man page. - 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/
aironet4500_cs
Am I foolish to expect the aironet4500_cs (and friends) to work with my shiny new Cisco Aironet 340 pcmcia card? If not, anybody got any helpful hints on how to get things off the ground? - 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/
aironet4500_cs
Am I foolish to expect the aironet4500_cs (and friends) to work with my shiny new Cisco Aironet 340 pcmcia card? If not, anybody got any helpful hints on how to get things off the ground? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0"
> "AB" == Andries Brouwer <[EMAIL PROTECTED]> writes: AB> No insult intended. It is just that if there is an abyss AB> somewhere, I like to stay at least a meter away from it. Someone AB> else may think that one inch suffices. I see you propose a lot AB> of changes that yield a negligable advantage and reduce stability AB> a tiny little bit. That is pushing Linux in the direction of this AB> abyss. You notice that the view gets better, and I get nervous. Can somebody stop this train load of bunk? Uninitialized global variables always have a initial value of zero. Static or otherwise. Period. Anybody with more than a week's experience programming knows this. It's idiomatic. Just as in English one says, "Go away!" knowing that "You", the implied subject of the imperative sentence, will be understood. Andries, please devote your impressive energy to fixing _real_ bugs. This kind of argument is best left until we're _really_ low on other things to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
"AB" == Andries Brouwer [EMAIL PROTECTED] writes: AB No insult intended. It is just that if there is an abyss AB somewhere, I like to stay at least a meter away from it. Someone AB else may think that one inch suffices. I see you propose a lot AB of changes that yield a negligable advantage and reduce stability AB a tiny little bit. That is pushing Linux in the direction of this AB abyss. You notice that the view gets better, and I get nervous. Can somebody stop this train load of bunk? Uninitialized global variables always have a initial value of zero. Static or otherwise. Period. Anybody with more than a week's experience programming knows this. It's idiomatic. Just as in English one says, "Go away!" knowing that "You", the implied subject of the imperative sentence, will be understood. Andries, please devote your impressive energy to fixing _real_ bugs. This kind of argument is best left until we're _really_ low on other things to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] maestro 2E not enabled
Second try (probably since I didn't correctly follow all the rules
before, thanks for the timely discussion).
The Maestro 2E on my laptop, which worked on 2.2 kernels, stopped
working on 2.4.0. Where stopped working means no sound and "pauses"
when interacting with the driver.
The symptom was hundreds of:
maestro: APU register select failed.
messages (there were other messages, but they were difficult to find
in all the noise) when the driver was loaded and a few hundred more if
anybody attempted to talk to the device.
maestro.c had not changed significantly since 2.2 (certainly not
anywhere close to the code emitting these messages).
lspci showed that the device was "[disabled]". Quick comparison
against other drivers showed that maestro.c was missing a call to
pci_enable_device().
Attached (well, inlined, really) is a patch that adds that call plus
some teardown logic in the event of failure.
By way of full disclosure, I have previously sent out this patch to
lkml and the maestro-users list. Zach has added it to what sounds
like a huge list but not explicitly blessed it (which is
understandable since I didn't really provide any of the above
information in said posting).
Thanks.
= maestro.c 1.12 vs 1.13 =
--- 1.12/drivers/sound/maestro.cSat Nov 11 13:33:13 2000
+++ 1.13/drivers/sound/maestro.cMon Nov 20 10:19:38 2000
@@ -3392,6 +3392,19 @@
ess = >channels[0];
+ if (pci_enable_device(pcidev)) {
+ printk (KERN_ERR "maestro: pci_enable_device() failed\n");
+ for (i = 0; i < NR_DSPS; i++) {
+ struct ess_state *s = >channels[i];
+ if (s->dev_audio != -1)
+ unregister_sound_dsp(s->dev_audio);
+ }
+ release_region(card->iobase, 256);
+ unregister_reboot_notifier(_nb);
+ kfree(card);
+ return 0;
+ }
+
/*
* Ok card ready. Begin setup proper
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] maestro 2E not enabled
Second try (probably since I didn't correctly follow all the rules
before, thanks for the timely discussion).
The Maestro 2E on my laptop, which worked on 2.2 kernels, stopped
working on 2.4.0. Where stopped working means no sound and "pauses"
when interacting with the driver.
The symptom was hundreds of:
maestro: APU register select failed.
messages (there were other messages, but they were difficult to find
in all the noise) when the driver was loaded and a few hundred more if
anybody attempted to talk to the device.
maestro.c had not changed significantly since 2.2 (certainly not
anywhere close to the code emitting these messages).
lspci showed that the device was "[disabled]". Quick comparison
against other drivers showed that maestro.c was missing a call to
pci_enable_device().
Attached (well, inlined, really) is a patch that adds that call plus
some teardown logic in the event of failure.
By way of full disclosure, I have previously sent out this patch to
lkml and the maestro-users list. Zach has added it to what sounds
like a huge list but not explicitly blessed it (which is
understandable since I didn't really provide any of the above
information in said posting).
Thanks.
= maestro.c 1.12 vs 1.13 =
--- 1.12/drivers/sound/maestro.cSat Nov 11 13:33:13 2000
+++ 1.13/drivers/sound/maestro.cMon Nov 20 10:19:38 2000
@@ -3392,6 +3392,19 @@
ess = card-channels[0];
+ if (pci_enable_device(pcidev)) {
+ printk (KERN_ERR "maestro: pci_enable_device() failed\n");
+ for (i = 0; i NR_DSPS; i++) {
+ struct ess_state *s = card-channels[i];
+ if (s-dev_audio != -1)
+ unregister_sound_dsp(s-dev_audio);
+ }
+ release_region(card-iobase, 256);
+ unregister_reboot_notifier(maestro_nb);
+ kfree(card);
+ return 0;
+ }
+
/*
* Ok card ready. Begin setup proper
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
patch for maestro 2e
I found that the maestro 2E sound hardware didn't want to make noise
for me under 2.4. Today I got itchy and scratched. Here's a patch:
(keller) 1021$ bk diffs -u drivers/sound/maestro.c
= drivers/sound/maestro.c 1.11 vs edited =
--- 1.11/drivers/sound/maestro.cTue Aug 29 10:09:15 2000
+++ edited/drivers/sound/maestro.c Mon Nov 13 20:53:01 2000
@@ -3390,6 +3390,19 @@
ess = >channels[0];
+ if (pci_enable_device(pcidev)) {
+ printk (KERN_ERR "maestro: pci_enable_device() failed\n");
+ for (i = 0; i < NR_DSPS; i++) {
+ struct ess_state *s = >channels[i];
+ if (s->dev_audio != -1)
+ unregister_sound_dsp(s->dev_audio);
+ }
+ release_region(card->iobase, 256);
+ unregister_reboot_notifier(_nb);
+ kfree(card);
+ return 0;
+ }
+
/*
* Ok card ready. Begin setup proper
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
patch for maestro 2e
I found that the maestro 2E sound hardware didn't want to make noise
for me under 2.4. Today I got itchy and scratched. Here's a patch:
(keller) 1021$ bk diffs -u drivers/sound/maestro.c
= drivers/sound/maestro.c 1.11 vs edited =
--- 1.11/drivers/sound/maestro.cTue Aug 29 10:09:15 2000
+++ edited/drivers/sound/maestro.c Mon Nov 13 20:53:01 2000
@@ -3390,6 +3390,19 @@
ess = card-channels[0];
+ if (pci_enable_device(pcidev)) {
+ printk (KERN_ERR "maestro: pci_enable_device() failed\n");
+ for (i = 0; i NR_DSPS; i++) {
+ struct ess_state *s = card-channels[i];
+ if (s-dev_audio != -1)
+ unregister_sound_dsp(s-dev_audio);
+ }
+ release_region(card-iobase, 256);
+ unregister_reboot_notifier(maestro_nb);
+ kfree(card);
+ return 0;
+ }
+
/*
* Ok card ready. Begin setup proper
*/
-
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: compiling 2.4.0-test10 kernel
>>>>> "KO" == Keith Owens <[EMAIL PROTECTED]> writes: KO> On Fri, 10 Nov 2000 11:23:29 -0500 (EST), "Georg Nikodym" KO> <[EMAIL PROTECTED]> wrote: C> i've manged to successfully compile 2.4.0-test10 kernel. however, C> upon startup there are some failed/error messages: C> 1. finding module dependencies: depmod *** Unresolved symbols in C> /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o >> >> There are two things you can do about this: >> >> 1. Disable module versioning. >> 2. Copy the System.map file that's made during the kernel build to >> /boot/System.map-2.4.0-test10. KO> System.map has nothing, repeat nothing to do with depmod at KO> startup. Yes, you can run depmod reading from a System.map but KO> that only makes sense before you boot the new kernel. Once you KO> have booted your new kernel, depmod -a reads from kernel memory, KO> not System.map. OK. Makes sense. My first kicks at building and running a kernel had these problems (with module loading) until I added the copying of System.map to my installation procedure. I was led to this by messages in /var/log/messages... Thanks for the additional pointers. KO> Q. Why do I get unresolved symbols like foo__ver_foo in modules? KO> A. If /proc/ksyms or the output from depmod -ae contains symbols KO> like KO> "foo__ver_foo" then you have been bitten by the broken Makefile KO> code for symbol versioning. The only safe way to recover is save KO> your config, delete everything, restore the config and recompile. KO> mv .config .. make mrproper mv ../.config . make oldconfig make KO> dep clean bzImage modules install, boot OK, but I guess my question wasn't very clear. I have a kernel tree, I add a printk to maestro.c and make modules. I cannot load the module until I rebuild and reinstall everything. Is there a way to avoid this headache, or, stated differently: What's the prescribed way to be able to load, unload, build, test modules? - 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: compiling 2.4.0-test10 kernel
> "C" == Corisen <[EMAIL PROTECTED]> writes: C> hi, i'm currently running RH7, with 2.2.16-22 kernel, gcc 2.96 on C> a Sharp Actius 250 notebook. C> i've manged to successfully compile 2.4.0-test10 kernel. however, C> upon startup there are some failed/error messages: C> 1. finding module dependencies: depmod *** Unresolved symbols in C> /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o There are two things you can do about this: 1. Disable module versioning. 2. Copy the System.map file that's made during the kernel build to /boot/System.map-2.4.0-test10. Personally, I do 2. Though, now I'm attempting to get the maestro driver working again and this is getting in my way. So my question to those that know more is what is the correct way to build a module such that it'll insmod in the face of module versioning. Is this something for the FAQ? C> 2. Starting NFS lockd: lockdsvc: Invalid argument [FAILED] I've been ignoring this (I'm sure at my peril). C> during shutdown, the following failed messages was noticed: C> 1. Turning off accounting: aacton: Function not implemented You can try enabling BSD process accounting in your configuration. I have not and also get this message (and don't care). C> 2. Shutting down NFS lockd [FAILED] As above. C> the system is also not able to shutdown/power off completely after C> "shutdown -h now". however, using RH7 2.2.16 kernel, the notebook C> was able to power off. how can i configure it to turn off C> automatically? My laptop (a Fujitsu E6520 stop powering off with RH7 regardless of whether I used the supplied kernel or the test10 that I built), so consider yourself lucky ;-) Also, the default compiler on RH7 is not correct. Use kgcc instead (ie. make CC=kgcc bzImage). The gcc2.96 is said/known not to work for kernel work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: compiling 2.4.0-test10 kernel
"C" == Corisen [EMAIL PROTECTED] writes: C hi, i'm currently running RH7, with 2.2.16-22 kernel, gcc 2.96 on C a Sharp Actius 250 notebook. C i've manged to successfully compile 2.4.0-test10 kernel. however, C upon startup there are some failed/error messages: C 1. finding module dependencies: depmod *** Unresolved symbols in C /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o There are two things you can do about this: 1. Disable module versioning. 2. Copy the System.map file that's made during the kernel build to /boot/System.map-2.4.0-test10. Personally, I do 2. Though, now I'm attempting to get the maestro driver working again and this is getting in my way. So my question to those that know more is what is the correct way to build a module such that it'll insmod in the face of module versioning. Is this something for the FAQ? C 2. Starting NFS lockd: lockdsvc: Invalid argument [FAILED] I've been ignoring this (I'm sure at my peril). C during shutdown, the following failed messages was noticed: C 1. Turning off accounting: aacton: Function not implemented You can try enabling BSD process accounting in your configuration. I have not and also get this message (and don't care). C 2. Shutting down NFS lockd [FAILED] As above. C the system is also not able to shutdown/power off completely after C "shutdown -h now". however, using RH7 2.2.16 kernel, the notebook C was able to power off. how can i configure it to turn off C automatically? My laptop (a Fujitsu E6520 stop powering off with RH7 regardless of whether I used the supplied kernel or the test10 that I built), so consider yourself lucky ;-) Also, the default compiler on RH7 is not correct. Use kgcc instead (ie. make CC=kgcc bzImage). The gcc2.96 is said/known not to work for kernel work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: compiling 2.4.0-test10 kernel
"KO" == Keith Owens [EMAIL PROTECTED] writes: KO On Fri, 10 Nov 2000 11:23:29 -0500 (EST), "Georg Nikodym" KO [EMAIL PROTECTED] wrote: C i've manged to successfully compile 2.4.0-test10 kernel. however, C upon startup there are some failed/error messages: C 1. finding module dependencies: depmod *** Unresolved symbols in C /lib/modules/2.4.0-test10/kernel/arch/i386/kernel/apm.o There are two things you can do about this: 1. Disable module versioning. 2. Copy the System.map file that's made during the kernel build to /boot/System.map-2.4.0-test10. KO System.map has nothing, repeat nothing to do with depmod at KO startup. Yes, you can run depmod reading from a System.map but KO that only makes sense before you boot the new kernel. Once you KO have booted your new kernel, depmod -a reads from kernel memory, KO not System.map. OK. Makes sense. My first kicks at building and running a kernel had these problems (with module loading) until I added the copying of System.map to my installation procedure. I was led to this by messages in /var/log/messages... Thanks for the additional pointers. KO Q. Why do I get unresolved symbols like foo__ver_foo in modules? KO A. If /proc/ksyms or the output from depmod -ae contains symbols KO like KO "foo__ver_foo" then you have been bitten by the broken Makefile KO code for symbol versioning. The only safe way to recover is save KO your config, delete everything, restore the config and recompile. KO mv .config .. make mrproper mv ../.config . make oldconfig make KO dep clean bzImage modules install, boot OK, but I guess my question wasn't very clear. I have a kernel tree, I add a printk to maestro.c and make modules. I cannot load the module until I rebuild and reinstall everything. Is there a way to avoid this headache, or, stated differently: What's the prescribed way to be able to load, unload, build, test modules? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] usb-uhci locks up on boot half the time
> "DF" == David Ford <[EMAIL PROTECTED]> writes: DF> Ok, in test10, for every 2 out of 5 boots, this particular DF> workstation locks up hard as it reaches the following: I have a similar problem. My work around is to, by hand, modprobe usbmouse, wait, modprobe usb-uhci... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] usb-uhci locks up on boot half the time
"DF" == David Ford [EMAIL PROTECTED] writes: DF Ok, in test10, for every 2 out of 5 boots, this particular DF workstation locks up hard as it reaches the following: I have a similar problem. My work around is to, by hand, modprobe usbmouse, wait, modprobe usb-uhci... - 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/
