Re: Linux 2.2.20pre7
Hi Alan. > Linux 2.2 is now firmly into maintainance state. Patches for > neat new ideas belong in 2.4. Generally new drivers belong in > 2.4 (possibly in 2.2 as well after 2.4 shows them stable). > Expect me to be very picky on changes to the core code now. Can I submit the attached patch for both 2.2 and 2.4 kernels? It adds a new script that lists all the configuration variables used, together with details of how many times each variable is used. Best wishes from Riley. scripts/varlist
Re: Linux 2.2.20pre7
Hi Alan. Linux 2.2 is now firmly into maintainance state. Patches for neat new ideas belong in 2.4. Generally new drivers belong in 2.4 (possibly in 2.2 as well after 2.4 shows them stable). Expect me to be very picky on changes to the core code now. Can I submit the attached patch for both 2.2 and 2.4 kernels? It adds a new script that lists all the configuration variables used, together with details of how many times each variable is used. Best wishes from Riley. scripts/varlist
Re: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi Peter. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? >>> Perhaps, but is has absolutely nothing to do with the rest of >>> this discussion. >> The `lock halt` bug patch was specific to the Cyrix processors >> (not to be confused with the `lock registers` patch for the >> Intel processors, and I noted that the processor in question was >> a Cyrix one, hence the comment. > Oh. Sorry, I don't know about "lock halt" and its effects. > However, if it refers to the instruction sequence LOCK HLT I > find it hard to believe it would have the symptoms described. I don't have the paperwork to hand, and my memory isn't brilliant, but the bug was something along the lines of Cyrix processors trashing the SP if the instruction preceding (or following, I'm not sure which) a HLT opcode was locked, and the patch was to remove some instances in the kernel source where that occurred. It's quite possibly unrelated, but... Best wishes from Riley. - 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: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi Peter. >> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? > Perhaps, but is has absolutely nothing to do with the rest of > this discussion. The `lock halt` bug patch was specific to the Cyrix processors (not to be confused with the `lock registers` patch for the Intel processors, and I noted that the processor in question was a Cyrix one, hence the comment. Best wishes from Riley. - 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: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi HPA. >> Some time ago I installed Linux (Redhat 6.0) on my pc (Cx486 8M >> RAM) and gcc had a lot of signal 11 (a couple every hour) I was >> upgrading the kernel every time there was a new kernel and from >> 2.2.12(or 14) no more signal 11 (very rare) Is this still a >> hardware problem ? Was a bug in kernel ? >> I think the last answer is more obvious.(or the gcc had a bug >> and the kernel -- a workaround). > Most likely is that your *hardware* had a bug and the new kernel > a workaround (this is quite common), but without more detail it > is very hard to know. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Best wishes from Riley. - 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: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi HPA. Some time ago I installed Linux (Redhat 6.0) on my pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a couple every hour) I was upgrading the kernel every time there was a new kernel and from 2.2.12(or 14) no more signal 11 (very rare) Is this still a hardware problem ? Was a bug in kernel ? I think the last answer is more obvious.(or the gcc had a bug and the kernel -- a workaround). Most likely is that your *hardware* had a bug and the new kernel a workaround (this is quite common), but without more detail it is very hard to know. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Best wishes from Riley. - 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: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi Peter. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Perhaps, but is has absolutely nothing to do with the rest of this discussion. The `lock halt` bug patch was specific to the Cyrix processors (not to be confused with the `lock registers` patch for the Intel processors, and I noted that the processor in question was a Cyrix one, hence the comment. Best wishes from Riley. - 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: [Re: gcc: internal compiler error: program cc1 got fatal signal11]
Hi Peter. Wasn't 2.2.12 the kernel that included the `lock halt` bug patch? Perhaps, but is has absolutely nothing to do with the rest of this discussion. The `lock halt` bug patch was specific to the Cyrix processors (not to be confused with the `lock registers` patch for the Intel processors, and I noted that the processor in question was a Cyrix one, hence the comment. Oh. Sorry, I don't know about lock halt and its effects. However, if it refers to the instruction sequence LOCK HLT I find it hard to believe it would have the symptoms described. I don't have the paperwork to hand, and my memory isn't brilliant, but the bug was something along the lines of Cyrix processors trashing the SP if the instruction preceding (or following, I'm not sure which) a HLT opcode was locked, and the patch was to remove some instances in the kernel source where that occurred. It's quite possibly unrelated, but... Best wishes from Riley. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
Hi Russell, Adam. >> So, I guess something like Keith Owens's patch would be the way >> to go, with some additional definitions (CONFIG_AGP, CONFIG_PCI, >> CONFIG_ISA, CONFIG_EISA, CONFIG_PCMCIA, and possibly others). >> I am not sure which other conditionals might also be incorrectly >> ignored by some instances of dep_xxx. Below, I have included a >> list of the 52 CONFIG_* variables that are used as arguments to >> dep_xxx in 2.4.6-pre6 and appear in arch/*/config.in. > I have confirmed that Keith Owens patch doesn't work with > xconfig - you can't select any option which has been > define_bool'd to 'n'. I've followed this thread with interest, and think I've followed both sides of the argument, so can I summarise: 1. Adam's point is that there are dep_* statements in the config setup that have been used to say that a particular option is dependant upon a particular architecture, but this doesn't work. 2. Russell's point is that Adam's point is correct, but the patch that Adam submitted can't be used as it breaks other things. 3. MY understanding of the situation is that ALL architecture specific config lines are EXPECTED to be in the arch/*/config.in files, where they will only even be seen when the relevant architecture is being compiled for. As a result of this, I would summarise this discussion as saying that there is a bug in the kernel config scripts in that some options that should be located in the architecture-specific config files are in the all-architecture config files instead. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6p6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
Hi Russell, Adam. So, I guess something like Keith Owens's patch would be the way to go, with some additional definitions (CONFIG_AGP, CONFIG_PCI, CONFIG_ISA, CONFIG_EISA, CONFIG_PCMCIA, and possibly others). I am not sure which other conditionals might also be incorrectly ignored by some instances of dep_xxx. Below, I have included a list of the 52 CONFIG_* variables that are used as arguments to dep_xxx in 2.4.6-pre6 and appear in arch/*/config.in. I have confirmed that Keith Owens patch doesn't work with xconfig - you can't select any option which has been define_bool'd to 'n'. I've followed this thread with interest, and think I've followed both sides of the argument, so can I summarise: 1. Adam's point is that there are dep_* statements in the config setup that have been used to say that a particular option is dependant upon a particular architecture, but this doesn't work. 2. Russell's point is that Adam's point is correct, but the patch that Adam submitted can't be used as it breaks other things. 3. MY understanding of the situation is that ALL architecture specific config lines are EXPECTED to be in the arch/*/config.in files, where they will only even be seen when the relevant architecture is being compiled for. As a result of this, I would summarise this discussion as saying that there is a bug in the kernel config scripts in that some options that should be located in the architecture-specific config files are in the all-architecture config files instead. Best wishes from Riley. - 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: Cosmetic JFFS patch.
Hi David. >> Perhaps even a boot flag of some sort to de-activate the >> printing of the /proc/credits during the kernel boot sequence. >> Or would the community rather an opt-in scenario... > KERN_BANNER Where would you put that in the sequence? Best wishes from Riley. - 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: Cosmetic JFFS patch.
Hi David. Perhaps even a boot flag of some sort to de-activate the printing of the /proc/credits during the kernel boot sequence. Or would the community rather an opt-in scenario... KERN_BANNER Where would you put that in the sequence? Best wishes from Riley. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Config variable scripts
Hi Alan. The enclosed patch was originally developed for the ELKS kernel, but will apply equally well against any Linux kernel as it only adds new scripts to the scripts subdirectory. The new scripts are as follows: 1. renvar Renames configuration variables in all files they occur in in the entire source tree. 2. varlist Lists all configuration variables currently in use, together with the number of files in which they occur. Can you apply this against both the 2.2 and 2.4 trees please? Best wishes from Riley. Config variable scripts
[PATCH] Config variable scripts
Hi Alan. The enclosed patch was originally developed for the ELKS kernel, but will apply equally well against any Linux kernel as it only adds new scripts to the scripts subdirectory. The new scripts are as follows: 1. renvar Renames configuration variables in all files they occur in in the entire source tree. 2. varlist Lists all configuration variables currently in use, together with the number of files in which they occur. Can you apply this against both the 2.2 and 2.4 trees please? Best wishes from Riley. Config variable scripts
Re: Allocating non-contigious memory
Hi Alan. >> What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K >> pages and get the pci bus address for each page? Bonus points >> is they're virtually contiguous, but that's not necessary. >> IIRC, the old vmalloc-then-walk-the-pagetables trick is >> considered out-of-bounds nowadays. > If you want it virtually contiguous then copy the code from bttv > that out-of-bounds or otherwise is now found in about 8 drivers > in the kernel. Would it be useful to turn that particular code into a subroutine that is called from each driver, or would that cause other problems? Best wishes from Riley. - 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: Allocating non-contigious memory
Hi Alan. What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K pages and get the pci bus address for each page? Bonus points is they're virtually contiguous, but that's not necessary. IIRC, the old vmalloc-then-walk-the-pagetables trick is considered out-of-bounds nowadays. If you want it virtually contiguous then copy the code from bttv that out-of-bounds or otherwise is now found in about 8 drivers in the kernel. Would it be useful to turn that particular code into a subroutine that is called from each driver, or would that cause other problems? Best wishes from Riley. - 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: For comment: draft BIOS use document for the kernel
Hi Alan. Brief critique... > Linux 2.4 BIOS usage reference > Boot Sequence > - > > Linux is normally loaded either directly as a bootable floppy > image or from hard disk via a boot loader called lilo. The > kernel image is transferred into low memory and a parameter > block above it. > > When booting from floppy disk the BIOS disk parameter tables are > replaced by a new table set up to allow a maximum sector count > of 36 (the track size for a 2.88Mb ED floppy) > > int 0x13, AH=0x02 is issued to to probe and find the disk geometry. > int 0x13, AH=0x00 is used to reset the floppy controller. > int 0x13, AH=0x02 is then issued repeatedly to load tracks of > data. The boot loader ensures no issued requests cross the > track boundaries > > int 0x10 service 3 is used during the boot loading sequence to > obtain the cursor position. int 0x10 service 13 is used to > display loading messages as the loading procedure continues. int > 0x10 AH=0xE is used to display a progress bar of '=' characters > during the bootstrap > > Control is then transferred to the loaded image whether by the > floppy boot loader or other services That looks OK. > Kernel Setup > > > The initial kernel setup executes in 16bit mode. While in 16bit > mode the kernel calls and caches data from several 16bit calls > whose data is not available in 32bit mode > > It then uses int 0x10 AH=0x0E in order to print initial progress > banners so that immediate feedback on the boot status is > available. The 0x07 character is issued as well as printable > characters and is expected to generate a bell. > > Memory detection is done as follows, attempting to handle the > various methods that have been available over time That looks OK. > Memory Sizing > - > > Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read > the E820 map. A maximum of 32 blocks are supported by current > kernels. The 'SMAP' signature is required and tested. In > addition the SMAP signature is restored each call, although not > required by the specification in order to handle some know BIOS > bugs. > > If the E820 call fails then the INT 15 AX=0xE801 service is > called and the results are sanity checked. In particular the > code zeroes the CX/DX return values in order to detect BIOS > implementations that do not set them usable memory data. That looks OK. > It also handles older BIOSes that return AX/BX but not AX/BX data. Please explain that a little more clearly - it means nothing to me. > When service E801 is used the kernel assumes that usable memory > extends from 4K to the bottom of the EBDA, and from 1Mbyte to > the top of the E801 area. > > If neither service is available then INT 0x15 AH=0x88 is invoked > in order to get the memory size, up to 64Mb by the original IBM > PC BIOS service. That looks OK. > Peripherals > --- > > Having sized memory the kernel moves on to set up peripherals. > The BIOS INT 0x16, AH=0x03 service is invoked in order to set > the keyboard repeat rate and the video BIOS is the called to set ^^^ > up video modes. Assuming that should be "then", that's fine. > The kernel tries to identify the video in terms of its generic > features. Initially it invokes INT 0x10 AH=0x12 to test for the > presence of EGA/VGA as oppose to CGA/MGA/HGA hardware. > > INT 0x10 AH=0x03 is used to obtain the cursor position, and INT > 0x10, AH=0x0F is used to obtain the video page and the mode. If > EGA or VGA are present the normal BIOS locations of 0x485 and > 0x484 are used to obtain the font size and the screen height. > > VESA BIOS video services are used to obtain the amount of video > memory (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 > protected mode interface data if available (INT 0x10, > AX=0x4F0A). Users are able to select graphical video modes (INT > 0x10 AX=0x4F02), or if not available the pre VESA mode setup. > The presence of the VESA BIOS is checked by the VESA get mode > information call (INT 0x10 AX=0x4F01) That's fine. > Special modes will also invoke INT 0x10 AH=0x1200 (Alternate > print screen), INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 > AH=0x1201 (to turn off cursor emulation) and INT 0x10 AH=0x01 > (to set up the cursor). What do you mean by "Special modes" ? > Having completed video set up the hard disk data for hda and hdb > is copied from the low memory BIOS area into the kernel tables. > INT 0x13 AH-0x15 is used to check if a second disk is present. Is that only for hda and hdb, or is hdc/hdd checked for as well? > INT 0x15, AH=0xC0 is invoked in order to check for MCA bus > machines. If an MCA systab is available the first block of the > table is also saved into the kernel's own data areas. That's fine. > INT 0x11 is used to check for a PS/2 mouse. If this function > reports that a PS/2 pointing
Re: For comment: draft BIOS use document for the kernel
Hi Alan. Brief critique... Linux 2.4 BIOS usage reference Boot Sequence - Linux is normally loaded either directly as a bootable floppy image or from hard disk via a boot loader called lilo. The kernel image is transferred into low memory and a parameter block above it. When booting from floppy disk the BIOS disk parameter tables are replaced by a new table set up to allow a maximum sector count of 36 (the track size for a 2.88Mb ED floppy) int 0x13, AH=0x02 is issued to to probe and find the disk geometry. int 0x13, AH=0x00 is used to reset the floppy controller. int 0x13, AH=0x02 is then issued repeatedly to load tracks of data. The boot loader ensures no issued requests cross the track boundaries int 0x10 service 3 is used during the boot loading sequence to obtain the cursor position. int 0x10 service 13 is used to display loading messages as the loading procedure continues. int 0x10 AH=0xE is used to display a progress bar of '=' characters during the bootstrap Control is then transferred to the loaded image whether by the floppy boot loader or other services That looks OK. Kernel Setup The initial kernel setup executes in 16bit mode. While in 16bit mode the kernel calls and caches data from several 16bit calls whose data is not available in 32bit mode It then uses int 0x10 AH=0x0E in order to print initial progress banners so that immediate feedback on the boot status is available. The 0x07 character is issued as well as printable characters and is expected to generate a bell. Memory detection is done as follows, attempting to handle the various methods that have been available over time That looks OK. Memory Sizing - Firstly a call is made to BIOS INT 15 AX=0xE820 in order to read the E820 map. A maximum of 32 blocks are supported by current kernels. The 'SMAP' signature is required and tested. In addition the SMAP signature is restored each call, although not required by the specification in order to handle some know BIOS bugs. If the E820 call fails then the INT 15 AX=0xE801 service is called and the results are sanity checked. In particular the code zeroes the CX/DX return values in order to detect BIOS implementations that do not set them usable memory data. That looks OK. It also handles older BIOSes that return AX/BX but not AX/BX data. Please explain that a little more clearly - it means nothing to me. When service E801 is used the kernel assumes that usable memory extends from 4K to the bottom of the EBDA, and from 1Mbyte to the top of the E801 area. If neither service is available then INT 0x15 AH=0x88 is invoked in order to get the memory size, up to 64Mb by the original IBM PC BIOS service. That looks OK. Peripherals --- Having sized memory the kernel moves on to set up peripherals. The BIOS INT 0x16, AH=0x03 service is invoked in order to set the keyboard repeat rate and the video BIOS is the called to set ^^^ up video modes. Assuming that should be then, that's fine. The kernel tries to identify the video in terms of its generic features. Initially it invokes INT 0x10 AH=0x12 to test for the presence of EGA/VGA as oppose to CGA/MGA/HGA hardware. INT 0x10 AH=0x03 is used to obtain the cursor position, and INT 0x10, AH=0x0F is used to obtain the video page and the mode. If EGA or VGA are present the normal BIOS locations of 0x485 and 0x484 are used to obtain the font size and the screen height. VESA BIOS video services are used to obtain the amount of video memory (INT 0x10 AX=0x4F00) and then to obtain the VESA 2.0 protected mode interface data if available (INT 0x10, AX=0x4F0A). Users are able to select graphical video modes (INT 0x10 AX=0x4F02), or if not available the pre VESA mode setup. The presence of the VESA BIOS is checked by the VESA get mode information call (INT 0x10 AX=0x4F01) That's fine. Special modes will also invoke INT 0x10 AH=0x1200 (Alternate print screen), INT 0x10 AH=0x11 (to set 8x8 font), INT 0x10 AH=0x1201 (to turn off cursor emulation) and INT 0x10 AH=0x01 (to set up the cursor). What do you mean by Special modes ? Having completed video set up the hard disk data for hda and hdb is copied from the low memory BIOS area into the kernel tables. INT 0x13 AH-0x15 is used to check if a second disk is present. Is that only for hda and hdb, or is hdc/hdd checked for as well? INT 0x15, AH=0xC0 is invoked in order to check for MCA bus machines. If an MCA systab is available the first block of the table is also saved into the kernel's own data areas. That's fine. INT 0x11 is used to check for a PS/2 mouse. If this function reports that a PS/2 pointing device is present the kernel will also verify directly with the PS/2 controller itself that the
Re: any good diff merging utility?
Hi Ivan.
>>> I like to build kernels with a bunch of patches on top to test
>>> new stuff. The problem is that it takes a lot of effort to fix
>>> all the failed hunks during patching that really wouldn't have
>>> to be failed if only patch was a little more inteligent and
>>> could merge several patches into one ( if possible) or if could
>>> take into account already applied patches.
>> The basic problem here is that the "failed hunks" are usually there
>> because of conflicts between the two patches in question, and as a
>> result, they are not as easy to merge automagically as one might at
>> first assume.
> Very often the case is that they indeed can be merged automagically.
> For example two patches inserting few lines right after the #include
> lines.
> patch1:
> @@ 10,1 10,2 @@
> #include
> +#include <1.h>
> patch2:
> @@ 10,1 10,2 @@
> #include
> +#include <2.h>
> The patch will fail to patch :-). But there is no real conflict
> between the patches.
True, but how about the following (from one I had to merge recently):
Q> patch1:
Q> @@ 137,3 142,5
Q> for( ptr=head; *ptr; ptr=ptr->next ) {
Q> + ctr += ptr->qty;
Q> table[ctr] += ptr->qty;
Q> + total += table[ctr];
Q> }
Q> patch2:
Q> @@ 137,2 146,3
Q> for( ptr=head; *ptr; ptr=ptr->next ) {
Q> + total += table[ctr];
Q> table[ctr] += ptr->qty;
How would you merge those two patches?
>>> Well, are there any utilities to merge diffs? I couldn't find
>>> any on freshmeat. So what are you using to stack many patches
>>> onto the kernel tree? Just manualy modify the diff? I'll try to
>>> write something more automatic if nothing comes up.
>> I once came across a utility called "diff3" that was designed to
>> take a patch for one version of a package and create an
>> equivalent patch for another version of the same package, but I
>> haven't been able to find it again since my hard drive crashed.
> diff3 comes from gnu diffutils
> . But all
> it does is comparing three FILES for differencies.
If it does that, then it does all you need. Assume, for example, that
you have two patches to ORIGINAL.DOC that overlap each other, these
being PATCH1.DIFF and PATCH2.DIFF respectively...
Q> gzip -9 < ORIGINAL.DOC > ORIGINAL.DOC.GZ
Q> patch < PATCH1.DIFF
Q> mv ORIGINAL.DOC ORIGINAL.DOC.V1
Q> gunzip < ORIGINAL.DOC.GZ > ORIGINAL.DOC
Q> patch < PATCH2.DIFF
Q> mv ORIGINAL.DOC ORIGINAL.DOC.V2
At this point, you have copies of the patched versions of that file as
produced by the two patches separately. If my memory's right (I don't
have diff3 to hand) you then do...
Q> diff3 ORIGINAL.DOC.V1 ORIGINAL.DOC.V2 REVISED.DOC
...and end up with REVISED.DOC being the result of taking ORIGINAL.DOC
and applying both PATCH1.DIFF and PATCH2.DIFF in parallel. You can
then do...
Q> gunzip < ORIGINAL.DOC.GZ > ORIGINAL.DOC
Q> diff -u ORIGINAL.DOC REVISED.DOC
...to get a consolidated diff that applies both patches.
Best wishes from Riley.
-
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: any good diff merging utility?
Hi Ivan. > I like to build kernels with a bunch of patches on top to test > new stuff. The problem is that it takes a lot of effort to fix > all the failed hunks during patching that really wouldn't have > to be failed if only patch was a little more inteligent and > could merge several patches into one ( if possible) or if could > take into account already applied patches. The basic problem here is that the "failed hunks" are usually there because of conflicts between the two patches in question, and as a result, they are not as easy to merge automagically as one might at first assume. > Well, are there any utilities to merge diffs? I couldn't find > any on freshmeat. So what are you using to stack many patches > onto the kernel tree? Just manualy modify the diff? I'll try to > write something more automatic if nothing comes up. I once came across a utility called "diff3" that was designed to take a patch for one version of a package and create an equivalent patch for another version of the same package, but I haven't been able to find it again since my hard drive crashed. Best wishes from Riley. - 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: any good diff merging utility?
Hi Ivan. I like to build kernels with a bunch of patches on top to test new stuff. The problem is that it takes a lot of effort to fix all the failed hunks during patching that really wouldn't have to be failed if only patch was a little more inteligent and could merge several patches into one ( if possible) or if could take into account already applied patches. The basic problem here is that the failed hunks are usually there because of conflicts between the two patches in question, and as a result, they are not as easy to merge automagically as one might at first assume. Well, are there any utilities to merge diffs? I couldn't find any on freshmeat. So what are you using to stack many patches onto the kernel tree? Just manualy modify the diff? I'll try to write something more automatic if nothing comes up. I once came across a utility called diff3 that was designed to take a patch for one version of a package and create an equivalent patch for another version of the same package, but I haven't been able to find it again since my hard drive crashed. Best wishes from Riley. - 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.2.19 DMA problem
Hi there. A friend of mine is having a problem with the 2.2.19 kernel on one of his boxes, and has asked for some advice which is beyond my experience so I'm asking here: Is this a kernel problem or something else? First, the hardware, as best we can determine: Vesa VLB motherboard, model unknown. Intel 486dx4/100 stepping 0. 48 Mb of RAM eth0 is an RTL8009 chipset configured for 0x300/IRQ9 Serial port 0x3f8/4 (16550A) connects to an external modem Serial port 0x2f8/3 (16550A) is unused The boix in question isn't used for compiling, but here's what the ver_linux script from 2.2.18 produced on it: binutils: 2.9.5.0.22 util-linux: 2.10f modutils: 2.3.21 e2fsprogs: 1.18 PPP:2.3.11 Linux C Library:2.1.3 Dynamic Linker (ldd): 2.1.3 Procps: 2.0.6 Net-tools: 1.54 Console-tools: 0.3.3 Sh-utils: 2.0 The machine that compiled the kernel has: Gnu-C: egcs-2.91.66 Gnu Make: 3.77 Binutils: 2.9.1.0.24 The problem machine irregularly spams the following over both the console and syslog (taken from syslog): Q> Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q> ne_block_output.[DMAstat:1][irqlock:1][intr:0] Q> Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q> ne_get_8390_hdr.[DMAstat:1][irqlock:0][intr:1] When this happens, the spam can be stopped by `ifconfig eth0 down` but the card is totally dead and can only be restarted by rebooting the machine. Can anybody advise on likely solutions, as this is his firewall gateway machine, so causes quite a bit of inconvenience. Best wishes from Riley. - 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.2.19 DMA problem
Hi there. A friend of mine is having a problem with the 2.2.19 kernel on one of his boxes, and has asked for some advice which is beyond my experience so I'm asking here: Is this a kernel problem or something else? First, the hardware, as best we can determine: Vesa VLB motherboard, model unknown. Intel 486dx4/100 stepping 0. 48 Mb of RAM eth0 is an RTL8009 chipset configured for 0x300/IRQ9 Serial port 0x3f8/4 (16550A) connects to an external modem Serial port 0x2f8/3 (16550A) is unused The boix in question isn't used for compiling, but here's what the ver_linux script from 2.2.18 produced on it: binutils: 2.9.5.0.22 util-linux: 2.10f modutils: 2.3.21 e2fsprogs: 1.18 PPP:2.3.11 Linux C Library:2.1.3 Dynamic Linker (ldd): 2.1.3 Procps: 2.0.6 Net-tools: 1.54 Console-tools: 0.3.3 Sh-utils: 2.0 The machine that compiled the kernel has: Gnu-C: egcs-2.91.66 Gnu Make: 3.77 Binutils: 2.9.1.0.24 The problem machine irregularly spams the following over both the console and syslog (taken from syslog): Q Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q ne_block_output.[DMAstat:1][irqlock:1][intr:0] Q Jun 9 17:34:04 Doorstep kernel: eth0: DMAing conflict in Q ne_get_8390_hdr.[DMAstat:1][irqlock:0][intr:1] When this happens, the spam can be stopped by `ifconfig eth0 down` but the card is totally dead and can only be restarted by rebooting the machine. Can anybody advise on likely solutions, as this is his firewall gateway machine, so causes quite a bit of inconvenience. Best wishes from Riley. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4 folks
Hi Peter. > I've trying to move some of my servers to 2.4.4 kernel from > 2.2.x. Everything goes fine, notable perfomance increase > occures, but the problem is I'm really often touch the following > problem: > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > __alloc_pages: 1-order allocation failed. > This message may also show 1-order, 0-order, 3-order failures > (only one type at the time). This problems also appeared then I > tried to use 2.4.1-2.4.3 kernels. > This sometimes leads to system hang, sometimes some processes > gets unkillable (even by kill -9) and in some cases I do not see > any bad results from this, but still this does not looks the > right thing to happen. > The problem is the systems this happens on are not short of > memory. Here is the free output for the system I had this > happened this morning: > rat:~ # free > Mem: 10286281025820 2808 0 9340 332412 > -/+ buffers/cache: 684068 344560 > Swap: 2097136 02097136 > Does anyone has any ideas about this problem ? I'm not up to date with the 2.4 series at the moment, but... Looking at the figures you're showing, this looks like you have 1024M of RAM. It used to be necessary to recompile the kernel if you had more than (going from memory) 976M of RAM, where you had to change a configuration option to select 2G of paging space instead of the default 3G thereof, and this looks suspiciously like this problem to me. Can anybody confirm whether this limitation still applies? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4 folks
Hi Peter. I've trying to move some of my servers to 2.4.4 kernel from 2.2.x. Everything goes fine, notable perfomance increase occures, but the problem is I'm really often touch the following problem: __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. __alloc_pages: 1-order allocation failed. This message may also show 1-order, 0-order, 3-order failures (only one type at the time). This problems also appeared then I tried to use 2.4.1-2.4.3 kernels. This sometimes leads to system hang, sometimes some processes gets unkillable (even by kill -9) and in some cases I do not see any bad results from this, but still this does not looks the right thing to happen. The problem is the systems this happens on are not short of memory. Here is the free output for the system I had this happened this morning: rat:~ # free Mem: 10286281025820 2808 0 9340 332412 -/+ buffers/cache: 684068 344560 Swap: 2097136 02097136 Does anyone has any ideas about this problem ? I'm not up to date with the 2.4 series at the moment, but... Looking at the figures you're showing, this looks like you have 1024M of RAM. It used to be necessary to recompile the kernel if you had more than (going from memory) 976M of RAM, where you had to change a configuration option to select 2G of paging space instead of the default 3G thereof, and this looks suspiciously like this problem to me. Can anybody confirm whether this limitation still applies? Best wishes from Riley. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. Since you appear to be determined to ignore reason and stick to your misguided guns I'll leave you to destroy all the good work that has gone into the Linux kernel's documentation and make it something even Bill Gates would be proud of. However, I'll stick to documentation that actually tells people what they need to know whilst you do so. Best wishes from Riley. * On Fri, 23 Mar 2001, Albert D. Cahalan wrote: > Riley Williams writes: > > Hi Albert. > > >>>> The rule should be like this: > >>>> > >>>> List the lowest version number required to get > >>>> 2.2.xx-level features while running a 2.4.xx kernel. > > >>> Replace that "a 2.2.xx" with "my current" and remove all > >>> restrictions on what the current kernel is, and that becomes > >>> an important question. > >> > >> No, not "my current" but "the previous stable". I say "2.2.xx" > >> because that is the previous stable kernel. > > > > Again, saying either "2.2.xx" or "the previous stable" is meaningless. > > Saying "The 2.2 kernel series" might have some meaning if it was not > > for the fact that the requirements differ for different members of > > that (or any other) kernel series. > > Oh please. List whatever the hell is needed for an upgrade from any > of 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, ..., 2.2.255 of course. > Also include previous 2.4.xx kernels, in case some bastard decided to > break stuff within a stable kernel series... like PPP for example. > > > On Saturday night, I had the pleasure of upgrading a system from the > > 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14 > > kernel to the 2.4.2 one. Although the target kernel version was the > > same, several subsystems needed upgrading on the former that did NOT > > need upgrading on the latter, and that was just to compile the thing! > > So what? Your point is??? Obviously one system was partly upgraded. > > > According to you, both of these upgrades would have required EXACTLY > > THE SAME upgrades to be made, but that isn't the case. > > I never claimed that. > > >> If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. > > > > Fairy Nuff. > > > > However, your argument still fails, simply because of its reliance on > > the assumption that an entire kernel series has static requirements > > when such just isn't the case. > > There is no such assumption. > > If 2.2.4 needs foo-1.7 while 2.2.5 and 2.4.4 need foo-1.8, then > foo gets listed. If 2.1.99 needs bar-0.6 while 2.2.0 and 2.4.4 > need bar 0.7, then there is no need to list bar. Never mind that > both foo and bar are up to version 666, since that isn't needed. > > >> The important thing is to avoid version number inflation. I don't > >> even bother reading the changes file, because I know it is bogus. > >> Nearly all of my old software works great with a 2.4.xx kernel. > > > > The fact that you said "Nearly all" shows that your argument is false, > > since your argument has been that NO software needs upgrading. > > > > Can I suggest that you re-read my previous missive, and actually look > > at the points raised. If you do, we might just get a sensible > > discussion on this subject... > > Try it yourself, w/o alcohol. I didn't argue "NO software...". > > > Incidentally, your argument to date has assumed that everybody always > > installs every single kernel version. In my opinion, that is a very > > dangerous assumption to make. > > Nope. Most people go from one stable series to the next, often skipping > the first and last few revisions. (2.2.6, 2.2.9, 2.2.17, 2.4.3, 2.4.8...) > > > A more responsible assumption would be > > that the person wishing to upgrade to the version in this particular > > kernel source tree has a random system installed, and wishes to know: > > That random system should be capable of working with at least > one kernel from the previous stable series. > > > 1. What is the absolute minimum upgrades required to compile the > > kernel in the source tree I have just downloaded? > > > > 2. What is the absolute minimum upgrades required to install the > > kernel in the source tree I have just downloaded and compiled? > > > > 3. What is the absolute minimum upgrades required to enable me > > to run
Re: [PATCH] Improved version reporting
Hi Albert. Since you appear to be determined to ignore reason and stick to your misguided guns I'll leave you to destroy all the good work that has gone into the Linux kernel's documentation and make it something even Bill Gates would be proud of. However, I'll stick to documentation that actually tells people what they need to know whilst you do so. Best wishes from Riley. * On Fri, 23 Mar 2001, Albert D. Cahalan wrote: Riley Williams writes: Hi Albert. The rule should be like this: List the lowest version number required to get 2.2.xx-level features while running a 2.4.xx kernel. Replace that "a 2.2.xx" with "my current" and remove all restrictions on what the current kernel is, and that becomes an important question. No, not "my current" but "the previous stable". I say "2.2.xx" because that is the previous stable kernel. Again, saying either "2.2.xx" or "the previous stable" is meaningless. Saying "The 2.2 kernel series" might have some meaning if it was not for the fact that the requirements differ for different members of that (or any other) kernel series. Oh please. List whatever the hell is needed for an upgrade from any of 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, ..., 2.2.255 of course. Also include previous 2.4.xx kernels, in case some bastard decided to break stuff within a stable kernel series... like PPP for example. On Saturday night, I had the pleasure of upgrading a system from the 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14 kernel to the 2.4.2 one. Although the target kernel version was the same, several subsystems needed upgrading on the former that did NOT need upgrading on the latter, and that was just to compile the thing! So what? Your point is??? Obviously one system was partly upgraded. According to you, both of these upgrades would have required EXACTLY THE SAME upgrades to be made, but that isn't the case. I never claimed that. If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. Fairy Nuff. However, your argument still fails, simply because of its reliance on the assumption that an entire kernel series has static requirements when such just isn't the case. There is no such assumption. If 2.2.4 needs foo-1.7 while 2.2.5 and 2.4.4 need foo-1.8, then foo gets listed. If 2.1.99 needs bar-0.6 while 2.2.0 and 2.4.4 need bar 0.7, then there is no need to list bar. Never mind that both foo and bar are up to version 666, since that isn't needed. The important thing is to avoid version number inflation. I don't even bother reading the changes file, because I know it is bogus. Nearly all of my old software works great with a 2.4.xx kernel. The fact that you said "Nearly all" shows that your argument is false, since your argument has been that NO software needs upgrading. Can I suggest that you re-read my previous missive, and actually look at the points raised. If you do, we might just get a sensible discussion on this subject... Try it yourself, w/o alcohol. I didn't argue "NO software...". Incidentally, your argument to date has assumed that everybody always installs every single kernel version. In my opinion, that is a very dangerous assumption to make. Nope. Most people go from one stable series to the next, often skipping the first and last few revisions. (2.2.6, 2.2.9, 2.2.17, 2.4.3, 2.4.8...) A more responsible assumption would be that the person wishing to upgrade to the version in this particular kernel source tree has a random system installed, and wishes to know: That random system should be capable of working with at least one kernel from the previous stable series. 1. What is the absolute minimum upgrades required to compile the kernel in the source tree I have just downloaded? 2. What is the absolute minimum upgrades required to install the kernel in the source tree I have just downloaded and compiled? 3. What is the absolute minimum upgrades required to enable me to run the kernel I have just compiled from this source tree, assuming that I wish to retain the use of the shell scripts that I developed under my previous kernel? 4. What other upgrades are recommended for reasons of system security or stability? Good, assuming "reasons of system security or stability" relates to problems that a kernel upgrade might cause. 5. What further upgrades are required to enable me to make use of the advertised new facilities in this kernel? This is noise. Such upgrades are not required. 6. What additional subsystems could be upgraded if desired? This is worse
Re: [PATCH] Improved version reporting
Hi Albert. >>> The rule should be like this: >>> >>>List the lowest version number required to get >>>2.2.xx-level features while running a 2.4.xx kernel. >> That's a meaningless definition, and can only be taken as such. What >> use would such a list be to somebody wishing (like I recently was) to >> upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 >> kernel instead? > ... >>> Basically I ask: would existing scripts for a 2.2.xx kernel >>> break? If the old mount can still do what it used to do, then >>> "mount" need not be listed at all. >> Replace that "a 2.2.xx" with "my current" and remove all restrictions >> on what the current kernel is, and that becomes an important question. > No, not "my current" but "the previous stable". I say "2.2.xx" because > that is the previous stable kernel. Again, saying either "2.2.xx" or "the previous stable" is meaningless. Saying "The 2.2 kernel series" might have some meaning if it was not for the fact that the requirements differ for different members of that (or any other) kernel series. On Saturday night, I had the pleasure of upgrading a system from the 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14 kernel to the 2.4.2 one. Although the target kernel version was the same, several subsystems needed upgrading on the former that did NOT need upgrading on the latter, and that was just to compile the thing! According to you, both of these upgrades would have required EXACTLY THE SAME upgrades to be made, but that isn't the case. > If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. Fairy Nuff. However, your argument still fails, simply because of its reliance on the assumption that an entire kernel series has static requirements when such just isn't the case. > The important thing is to avoid version number inflation. I don't > even bother reading the changes file, because I know it is bogus. > Nearly all of my old software works great with a 2.4.xx kernel. The fact that you said "Nearly all" shows that your argument is false, since your argument has been that NO software needs upgrading. Can I suggest that you re-read my previous missive, and actually look at the points raised. If you do, we might just get a sensible discussion on this subject... Incidentally, your argument to date has assumed that everybody always installs every single kernel version. In my opinion, that is a very dangerous assumption to make. A more responsible assumption would be that the person wishing to upgrade to the version in this particular kernel source tree has a random system installed, and wishes to know: 1. What is the absolute minimum upgrades required to compile the kernel in the source tree I have just downloaded? 2. What is the absolute minimum upgrades required to install the kernel in the source tree I have just downloaded and compiled? 3. What is the absolute minimum upgrades required to enable me to run the kernel I have just compiled from this source tree, assuming that I wish to retain the use of the shell scripts that I developed under my previous kernel? 4. What other upgrades are recommended for reasons of system security or stability? 5. What further upgrades are required to enable me to make use of the advertised new facilities in this kernel? 6. What additional subsystems could be upgraded if desired? 7. I note that some upgrades are only required if certain of the subsystems are installed. Which upgrades are these, and which subsystems are they dependant on? Personally, I'd be quite willing to work on a system to document the requirements and classifying each requirement according to the above system. However, as a pre-requisite, I would need agreement that such was (a) worth doing, and (b) of interest to the kernel developers. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. The rule should be like this: List the lowest version number required to get 2.2.xx-level features while running a 2.4.xx kernel. That's a meaningless definition, and can only be taken as such. What use would such a list be to somebody wishing (like I recently was) to upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 kernel instead? ... Basically I ask: would existing scripts for a 2.2.xx kernel break? If the old mount can still do what it used to do, then "mount" need not be listed at all. Replace that "a 2.2.xx" with "my current" and remove all restrictions on what the current kernel is, and that becomes an important question. No, not "my current" but "the previous stable". I say "2.2.xx" because that is the previous stable kernel. Again, saying either "2.2.xx" or "the previous stable" is meaningless. Saying "The 2.2 kernel series" might have some meaning if it was not for the fact that the requirements differ for different members of that (or any other) kernel series. On Saturday night, I had the pleasure of upgrading a system from the 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14 kernel to the 2.4.2 one. Although the target kernel version was the same, several subsystems needed upgrading on the former that did NOT need upgrading on the latter, and that was just to compile the thing! According to you, both of these upgrades would have required EXACTLY THE SAME upgrades to be made, but that isn't the case. If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. Fairy Nuff. However, your argument still fails, simply because of its reliance on the assumption that an entire kernel series has static requirements when such just isn't the case. The important thing is to avoid version number inflation. I don't even bother reading the changes file, because I know it is bogus. Nearly all of my old software works great with a 2.4.xx kernel. The fact that you said "Nearly all" shows that your argument is false, since your argument has been that NO software needs upgrading. Can I suggest that you re-read my previous missive, and actually look at the points raised. If you do, we might just get a sensible discussion on this subject... Incidentally, your argument to date has assumed that everybody always installs every single kernel version. In my opinion, that is a very dangerous assumption to make. A more responsible assumption would be that the person wishing to upgrade to the version in this particular kernel source tree has a random system installed, and wishes to know: 1. What is the absolute minimum upgrades required to compile the kernel in the source tree I have just downloaded? 2. What is the absolute minimum upgrades required to install the kernel in the source tree I have just downloaded and compiled? 3. What is the absolute minimum upgrades required to enable me to run the kernel I have just compiled from this source tree, assuming that I wish to retain the use of the shell scripts that I developed under my previous kernel? 4. What other upgrades are recommended for reasons of system security or stability? 5. What further upgrades are required to enable me to make use of the advertised new facilities in this kernel? 6. What additional subsystems could be upgraded if desired? 7. I note that some upgrades are only required if certain of the subsystems are installed. Which upgrades are these, and which subsystems are they dependant on? Personally, I'd be quite willing to work on a system to document the requirements and classifying each requirement according to the above system. However, as a pre-requisite, I would need agreement that such was (a) worth doing, and (b) of interest to the kernel developers. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. >> +o Mount # 2.10e# mount --version > Concerning mount: (i) the version mentioned is too old, >>> Exactly why? Mere missing features don't make for a required >>> upgrade. Version number inflation should be resisted. >> These days you can mount several filesystems at the same mount >> point. The old mount does not understand this at all. Recent >> versions of mount act better in this respect, even though it is >> still easy to confuse them. > The rule should be like this: > List the lowest version number required to get > 2.2.xx-level features while running a 2.4.xx kernel. That's a meaningless definition, and can only be taken as such. What use would such a list be to somebody wishing (like I recently was) to upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 kernel instead? The ONLY kernel version that any list can be meaningful for is that of the kernel source tree it is a member of, and that leads to the following definition for the versions to be included in such a list: List the lowest version number required to compile this kernel, and to allow the resulting kernel to be used as the heart of a running system. Basically, required upgrades can fall into any of the following categories, and need to be dealt with accordingly: 1. Development tools used to compile and/or link the kernel. 2. System libraries needed to run these development tools: 3. System tools that interact intimately with the kernel. If the kernel interface changes in an incompatible way, these will also need to be updated. 4. System tools that analyse kernel-supplied information and advise the user of the results. 5. Other tools that are dependant on kernel version. 6. Other tools that have been upgraded. My opinion is that only tools that fall in category (6) should be omitted from the list. > Remember what the purpose of the table is. It is a list of > REQUIRED upgrades. Failure to upgrade should result in a broken > system. So pppd must be listed, since somebody changed the > kernel API for 2.4.1. > If I run the mount command from Red Hat 6.2, using it as > intended for a 2.2.xx kernel, doesn't everything work? There > won't be any multi-mount confusion because 2.2.xx can't do that > anyway. There isn't any problem with NFSv3 either, since 2.2.xx > lacks NFSv3. Whilst that's a good question, it misses the whole point of such a list. Can I replace it with a more realistic one: If I take a random Linux-based system and boot it using the kernel I've just compiled using this kernel source tree, will it work? If not, what is the minimum that I need to upgrade to make it work? Remember, there's absolutely NOTHING in ANY of the kernel source trees that depends on what a particular user is running on their system before they get that source tree. > Basically I ask: would existing scripts for a 2.2.xx kernel > break? If the old mount can still do what it used to do, then > "mount" need not be listed at all. Replace that "a 2.2.xx" with "my current" and remove all restrictions on what the current kernel is, and that becomes an important question. After all, if I take the network print server I'm running with a 2.0.19 kernel and drop a 2.4.2 kernel in, will it work without any other changes? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
>> {Shrug} Thinking isn't sufficient - check your facts.
> Poor Riley,
>
> Probably I should not answer, I think you know all the facts
> already. But just to be sure:
> (i) There are two different packages, kbd and a forked version,
> console-tools. Both contain roughly the same programs. In your
> earlier mails you seemed aware of that, but now you report that
> the console-tools version of loadkeys does not want to print a
> kbd version. No surprise there.
You make claims for me there that I've never made, so can I suggest
you get your facts right this time. For reference:
1. My claim was NOT that the loadkeys from console-tools does
not print a kbd version, as you claim in the comment quoted
above. I claimed that it doesn't print ANY version, including
one for loadkeys itself.
2. YOUR claim was that the loadkeys command ALWAYS displays the
version number, so the command in ver_linux is thus always
guaranteed to produce a version number. MY claim was that
at least one loadkeys command fails to do so, and thus that
one can't expect it to do so.
Thank you for confirming that your claim was false.
> (ii) I am the maintainer of both mount and util-linux.
> If I say that there exists no more recent version of mount
> than the one found in util-linux, you can believe me.
Neither of us has claimed otherwise, nor have we been disputing that.
YOUR claim was that all systems always have the same version of mount
and util-linux installed, even when they are from different packages.
MY claim was that no such guarantee can be given, as it's possible for
somebody to upgrade either without upgrading the other when they are
supplied separately.
Again, thank you for confirming that your claimwas false.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
{Shrug} Thinking isn't sufficient - check your facts.
Poor Riley,
Probably I should not answer, I think you know all the facts
already. But just to be sure:
(i) There are two different packages, kbd and a forked version,
console-tools. Both contain roughly the same programs. In your
earlier mails you seemed aware of that, but now you report that
the console-tools version of loadkeys does not want to print a
kbd version. No surprise there.
You make claims for me there that I've never made, so can I suggest
you get your facts right this time. For reference:
1. My claim was NOT that the loadkeys from console-tools does
not print a kbd version, as you claim in the comment quoted
above. I claimed that it doesn't print ANY version, including
one for loadkeys itself.
2. YOUR claim was that the loadkeys command ALWAYS displays the
version number, so the command in ver_linux is thus always
guaranteed to produce a version number. MY claim was that
at least one loadkeys command fails to do so, and thus that
one can't expect it to do so.
Thank you for confirming that your claim was false.
(ii) I am the maintainer of both mount and util-linux.
If I say that there exists no more recent version of mount
than the one found in util-linux, you can believe me.
Neither of us has claimed otherwise, nor have we been disputing that.
YOUR claim was that all systems always have the same version of mount
and util-linux installed, even when they are from different packages.
MY claim was that no such guarantee can be given, as it's possible for
somebody to upgrade either without upgrading the other when they are
supplied separately.
Again, thank you for confirming that your claimwas false.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. +o Mount # 2.10e# mount --version Concerning mount: (i) the version mentioned is too old, Exactly why? Mere missing features don't make for a required upgrade. Version number inflation should be resisted. These days you can mount several filesystems at the same mount point. The old mount does not understand this at all. Recent versions of mount act better in this respect, even though it is still easy to confuse them. The rule should be like this: List the lowest version number required to get 2.2.xx-level features while running a 2.4.xx kernel. That's a meaningless definition, and can only be taken as such. What use would such a list be to somebody wishing (like I recently was) to upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 kernel instead? The ONLY kernel version that any list can be meaningful for is that of the kernel source tree it is a member of, and that leads to the following definition for the versions to be included in such a list: List the lowest version number required to compile this kernel, and to allow the resulting kernel to be used as the heart of a running system. Basically, required upgrades can fall into any of the following categories, and need to be dealt with accordingly: 1. Development tools used to compile and/or link the kernel. 2. System libraries needed to run these development tools: 3. System tools that interact intimately with the kernel. If the kernel interface changes in an incompatible way, these will also need to be updated. 4. System tools that analyse kernel-supplied information and advise the user of the results. 5. Other tools that are dependant on kernel version. 6. Other tools that have been upgraded. My opinion is that only tools that fall in category (6) should be omitted from the list. Remember what the purpose of the table is. It is a list of REQUIRED upgrades. Failure to upgrade should result in a broken system. So pppd must be listed, since somebody changed the kernel API for 2.4.1. If I run the mount command from Red Hat 6.2, using it as intended for a 2.2.xx kernel, doesn't everything work? There won't be any multi-mount confusion because 2.2.xx can't do that anyway. There isn't any problem with NFSv3 either, since 2.2.xx lacks NFSv3. Whilst that's a good question, it misses the whole point of such a list. Can I replace it with a more realistic one: If I take a random Linux-based system and boot it using the kernel I've just compiled using this kernel source tree, will it work? If not, what is the minimum that I need to upgrade to make it work? Remember, there's absolutely NOTHING in ANY of the kernel source trees that depends on what a particular user is running on their system before they get that source tree. Basically I ask: would existing scripts for a 2.2.xx kernel break? If the old mount can still do what it used to do, then "mount" need not be listed at all. Replace that "a 2.2.xx" with "my current" and remove all restrictions on what the current kernel is, and that becomes an important question. After all, if I take the network print server I'm running with a 2.0.19 kernel and drop a 2.4.2 kernel in, will it work without any other changes? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
> Neither am I - but, according to comments from RedHat a while back,
> they repackage mount separately because they provide a NEWER version
> of mount than is in the util-linux package. This will ALSO result in
> `mount --version` giving the wrong answer...
> There is no newer version.
Why do RedHat claim there is then?
> In ancient times I came with frequent releases of mount, at a time
> when util-linux was released very infrequently. These years mount
> is part of util-linux, and util-linux is released frequently.
{Shrug} Persuade RedHat of that, not me - they're the ones who release
it separately. Taken directly from RedHat's FTP site, I note that Red
Hat 6.2 includes RPM's for both mount-2.10f-1.i386.rpm and
util-linux-2.10f-7.i386.rpm which, whilst different releases of the
same version, is sufficient to prove your argument false. I can't get
into their 7.0 tree atm to check due to network congestion, so can't
comment on that...
> Unless one can guarantee that the util-linux and mount packages are
> the SAME version, mount can't be guaranteed to report the version of
> the util-linux package installed. RedHat provide a NEWER version of
> mount to util-linux so that guarantee doesnae exist.
> I do not think they do.
{Shrug} Thinking isn't sufficient - check your facts.
> > You are mistaken, as is proved by the reports that contain a kbd
> > line: a grep on linux-kernel for this Februari shows people with
> > Kbd 0.96, 0.99 and 1.02.
>
> {Shrug} Please explain why I was unable to get ver_linux to report a
> When other people can and you cannot, why should I explain your failure?
> Let me just check. A version from 1993:
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 0.81
>
> A version from 2001:
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
I tried the version that came as part of Red Hat 6.2 as installed
unmodified on the system I'm using. According to the rpm command, I
see...
Q> $ rpm -qf `which loadkeys`
Q> console-tools-19990829-10
Q> $
I've now tried that on FOUR different systems running Red Hat 6.2, the
last of them a fresh install direct from genuine RH 6.2 CD's with NO
changes since, and all four report the same and do exactly the same to
the command in ver_linux so I have to assume that the command in
ver_linux is UNABLE to determine a version number with this release of
Linux.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
> [Yes, I wrote, replying to your mail, just because I happened to
> notice the incorrect or debatable lines in your patch. Let me cc
> the Changes maintainer - maybe Chris Ricker.]
-o util-linux 2.10o # fdformat --version
+o util-linux # 2.10o# fdformat --version
>>> Looking at fdformat to get the util-linux version is perhaps not
>>> the most reliable way - some people have fdformat from elsewhere.
>>> Using mount --version would be better - I am not aware of any
>>> other mount distribution.
>> RedHat distribute mount separately from util-linux and I
>> wouldnae be surprised if others do the same...
> I am not aware of any distribution that ships some version of
> util-linux, but replaces its mount part by an older version. I
> think that even in cases where, because of historical reasons,
> util-linux is repackaged in several parts, mount --version gives
> the right answer.
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
+In addition, it is wise to ensure that the following packages are
+at least at the versions suggested below, although these may not
+be required, depending on the exact configuration of your system:
+
+o Console Tools # 0.3.3# loadkeys -V
+o Mount # 2.10e# mount --version
>>> Concerning mount:
>>>
>>> (i) the version mentioned is too old,
>> As stated in my original post, I've no idea what the correct
>> version should be as it's not documented anywhere I can find.
>>> (ii) mount is in util-linux.
>> Not on RedHat systems.
> There is no other source. Some people like to repack but that
> has no influence on versions.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
>>> Conclusion: the mount line should be deleted entirely.
Conclusion: Both the mount and util-linux lines are REQUIRED.
>>> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
>>> I am not aware of any reason to recommend the use of
>>> console-tools.
>> Neither am I. The ver_linux script has lines for determining the
>> versions for both Console Tools and Kbd but on EVERY system I've
>> tried, including Slackware, RedHat, Debian, Caldera, and SuSE
>> based ones, the line for determining Kbd versiondoesnae work.
>> I've just included the line that worked, and ignored the Kbd one
>> as I can see no point including something that doesnae work.
> You are mistaken, as is proved by the reports that contain a kbd
> line: a grep on linux-kernel for this Februari shows people with
> Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
kbd line on ANY of the systems I tried, including systems with it
definately installed. I tried it out manually on several such systems,
and ALL reported the SAME error message to the `loadkeys -h` command
used in scripts/ver_linux which is:
Q> $ loadkeys -h 2>&1 > x
Q> Usage: loadkeys [option...] [mapfile...]
Q> valid options are:
Q> -c --clearcompose clear kernel compose table
Q> -d --default load default keymap file
Q> -m --mktable output a "defkeymap.c" to stdout
Q> -s --clearstrings clear kernel string table
Q> -q --quietbe silent
Q> -v --verbose report the changes
Q> -v --verbose report more changes
Q> -h --help display this help text and exit
Q> -V --version display version information and exit
Q> $
Also, please advise where the version number is in that text...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
[Yes, I wrote, replying to your mail, just because I happened to
notice the incorrect or debatable lines in your patch. Let me cc
the Changes maintainer - maybe Chris Ricker.]
-o util-linux 2.10o # fdformat --version
+o util-linux # 2.10o# fdformat --version
Looking at fdformat to get the util-linux version is perhaps not
the most reliable way - some people have fdformat from elsewhere.
Using mount --version would be better - I am not aware of any
other mount distribution.
RedHat distribute mount separately from util-linux and I
wouldnae be surprised if others do the same...
I am not aware of any distribution that ships some version of
util-linux, but replaces its mount part by an older version. I
think that even in cases where, because of historical reasons,
util-linux is repackaged in several parts, mount --version gives
the right answer.
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
+In addition, it is wise to ensure that the following packages are
+at least at the versions suggested below, although these may not
+be required, depending on the exact configuration of your system:
+
+o Console Tools # 0.3.3# loadkeys -V
+o Mount # 2.10e# mount --version
Concerning mount:
(i) the version mentioned is too old,
As stated in my original post, I've no idea what the correct
version should be as it's not documented anywhere I can find.
(ii) mount is in util-linux.
Not on RedHat systems.
There is no other source. Some people like to repack but that
has no influence on versions.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
Conclusion: the mount line should be deleted entirely.
Conclusion: Both the mount and util-linux lines are REQUIRED.
Concerning Console Tools: maybe kbd-1.05 is uniformly better.
I am not aware of any reason to recommend the use of
console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE
based ones, the line for determining Kbd versiondoesnae work.
I've just included the line that worked, and ignored the Kbd one
as I can see no point including something that doesnae work.
You are mistaken, as is proved by the reports that contain a kbd
line: a grep on linux-kernel for this Februari shows people with
Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
kbd line on ANY of the systems I tried, including systems with it
definately installed. I tried it out manually on several such systems,
and ALL reported the SAME error message to the `loadkeys -h` command
used in scripts/ver_linux which is:
Q $ loadkeys -h 21 x
Q Usage: loadkeys [option...] [mapfile...]
Q valid options are:
Q -c --clearcompose clear kernel compose table
Q -d --default load default keymap file
Q -m --mktable output a "defkeymap.c" to stdout
Q -s --clearstrings clear kernel string table
Q -q --quietbe silent
Q -v --verbose report the changes
Q -v --verbose report more changes
Q -h --help display this help text and exit
Q -V --version display version information and exit
Q $
Also, please advise where the version number is in that text...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
There is no newer version.
Why do RedHat claim there is then?
In ancient times I came with frequent releases of mount, at a time
when util-linux was released very infrequently. These years mount
is part of util-linux, and util-linux is released frequently.
{Shrug} Persuade RedHat of that, not me - they're the ones who release
it separately. Taken directly from RedHat's FTP site, I note that Red
Hat 6.2 includes RPM's for both mount-2.10f-1.i386.rpm and
util-linux-2.10f-7.i386.rpm which, whilst different releases of the
same version, is sufficient to prove your argument false. I can't get
into their 7.0 tree atm to check due to network congestion, so can't
comment on that...
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
I do not think they do.
{Shrug} Thinking isn't sufficient - check your facts.
You are mistaken, as is proved by the reports that contain a kbd
line: a grep on linux-kernel for this Februari shows people with
Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
When other people can and you cannot, why should I explain your failure?
Let me just check. A version from 1993:
% ./loadkeys -h 21 | head -1
loadkeys version 0.81
A version from 2001:
% ./loadkeys -h 21 | head -1
loadkeys version 1.06
Maybe nothing has changed here the past eight years. It just works.
Perhaps you tried some modified version.
I tried the version that came as part of Red Hat 6.2 as installed
unmodified on the system I'm using. According to the rpm command, I
see...
Q $ rpm -qf `which loadkeys`
Q console-tools-19990829-10
Q $
I've now tried that on FOUR different systems running Red Hat 6.2, the
last of them a fresh install direct from genuine RH 6.2 CD's with NO
changes since, and all four report the same and do exactly the same to
the command in ver_linux so I have to assume that the command in
ver_linux is UNABLE to determine a version number with this release of
Linux.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Andries.
>> -o util-linux 2.10o # fdformat --version
>> +o util-linux # 2.10o# fdformat --version
> Looking at fdformat to get the util-linux version is perhaps not
> the most reliable way - some people have fdformat from fd-utils
> or so.
{Shrug} That's the command that was in both Documentation/Changes and
in scripts/ver_linux and I just left what was already there, as shown
by your quote. Somebody MUCH more knowledgable than me regarding
kernel requirements can sort that out.
> Using mount --version would be better - I am not aware of any
> other mount distribution.
RedHat distribute mount separately from util-linux and I wouldnae be
surprised if others do the same...
>> +In addition, it is wise to ensure that the following packages are at least
>> +at the versions suggested below, although these may not be required,
>> +depending on the exact configuration of your system:
>> +
>> +o Console Tools # 0.3.3# loadkeys -V
>> +o Mount # 2.10e# mount --version
> Concerning mount:
>
> (i) the version mentioned is too old,
Probably. As stated, that's what's currently installed here, and I
havenae the foggiest whether any of them need upgrading as there's
nothing I've been able to find to say what the minimum version is.
> (ii) mount is in util-linux.
Not on RedHat systems.
> Conclusion: the mount line should be deleted entirely.
Maybe, but that's not for me to decide. Whoever wrote ver_linux
obviously thought it important.
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE based
ones, the line for determining Kbd versiondoesnae work. I've just
included the line that worked, and ignored the Kbd one as I can see no
point including something that doesnae work.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Improved version reporting
Hi all. As a result of private email correspondance I have recently received, I became aware that the current system of identifying the versions of the various subsystems required to support any particular kernel version is inadequate, and decided to do something about it. The enclosed patch is my offering to rectify this. The problems identified are: 1. Different subsystems are identified in Documentation/Changes and in scripts/ver_linux, probably due to the difficulty of maintaining two files in sync with each other. As a result, it is not clear what the required versions of some subsystems are. 2. The existing script does not make it clear which subsystems need to be updated. The user is expected to decide by cross-referencing the details it provides with those provided elsewhere. 3. The command to perform this analysis is not immediately obvious. My offering (developed against the 2.4.2 kernel source tree) does away with all three of these problems by: A. Making Documentation/Changes the sole source of information on the subsystems required. The script I have developed then reads the table in this file, and uses commands listed therein to determine the installed versions of the relevant subsystems. The format of this table had to be changed slightly to accommodate the script, but this was done without impairing the readability thereof. B. Adding lines to Documentation/Changes to document those subsystems listed by scripts/ver_linux that were not already in the table in Documentation/Changes so that all relevant subsystems are considered. This was done by adding a separate table formatted identically to the existing one, but indicating that the subsystems therein may not be required. Note that the "required versions" listed in this new table are those installed on my system, with the exception of the Linux C++ library which is apparently not installed here. These versions need to be tweaked to reflect the actual requirements for that kernel. C. Comparing the installed and required versions of each subsystem, and indicating the results of that comparison in the displayed results by colouring the name of the subsystem. A facility to disable this is also included, and is activated by providing a parameter to the script. Any parameter will serve this function. D. Inserting lines in the primary Makefile to allow `make vsn` to run the relevant command to generate the results with colouring, and `make vsnbw` to do so without colours. Both change the permissions of the script to make it an executable. There is ONE problem with this method, which I have not been able to solve. This is that the command used by scripts/ver_linux to determine the installed version of the Gnu C Library can't be replicated using the method this script is based on, and I have had to replace it with a simpler script which may produce different results in some cases. If this is a problem, it is open to others to solve as I have licensed this under version 2 (only) of the Gnu General Public Licence. Best wishes from Riley. --- linux/Documentation/Changes~Fri Feb 16 23:53:08 2001 +++ linux/Documentation/Changes Tue Mar 13 23:38:46 2001 @@ -48,16 +48,31 @@ Card) hardware, for example, you probably needn't concern yourself with pcmcia-cs. -o Gnu C 2.91.66 # gcc --version +o Gnu C # 2.91.66 # gcc --version -o Gnu make 3.77# make --version +o Gnu make # 3.77 # make --version -o binutils 2.9.1.0.25 # ld -v +o binutils # 2.9.1.0.25 # ld -v -o util-linux 2.10o # fdformat --version +o util-linux # 2.10o# fdformat --version -o modutils 2.4.2 # insmod -V +o modutils # 2.4.2# insmod -V -o e2fsprogs 1.19# tune2fs +o e2fsprogs # 1.19 # tune2fs -o reiserfsprogs 3.x.0b # reiserfsck 2>&1|grep reiserfsprogs +o reiserfsprogs # 3.x.0b # reiserfsck 2>&1|grep reiserfsprogs -o pcmcia-cs 3.1.21 # cardmgr -V +o pcmcia-cs # 3.1.21 # cardmgr -V -o PPP2.4.0 # pppd --version +o PPP# 2.4.0# pppd --version /dev/tty -o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version +o isdn4k-utils # 3.1pre1 # isdnctrl 2>&1|grep version + +In addition, it is wise to ensure that the following packages are at least +at the versions suggested below, although these may not be required, depending +on the exact configuration of your system: + +o Console Tools # 0.3.3# loadkeys -V +o Current Kernel #
[PATCH] Improved version reporting
Hi all. As a result of private email correspondance I have recently received, I became aware that the current system of identifying the versions of the various subsystems required to support any particular kernel version is inadequate, and decided to do something about it. The enclosed patch is my offering to rectify this. The problems identified are: 1. Different subsystems are identified in Documentation/Changes and in scripts/ver_linux, probably due to the difficulty of maintaining two files in sync with each other. As a result, it is not clear what the required versions of some subsystems are. 2. The existing script does not make it clear which subsystems need to be updated. The user is expected to decide by cross-referencing the details it provides with those provided elsewhere. 3. The command to perform this analysis is not immediately obvious. My offering (developed against the 2.4.2 kernel source tree) does away with all three of these problems by: A. Making Documentation/Changes the sole source of information on the subsystems required. The script I have developed then reads the table in this file, and uses commands listed therein to determine the installed versions of the relevant subsystems. The format of this table had to be changed slightly to accommodate the script, but this was done without impairing the readability thereof. B. Adding lines to Documentation/Changes to document those subsystems listed by scripts/ver_linux that were not already in the table in Documentation/Changes so that all relevant subsystems are considered. This was done by adding a separate table formatted identically to the existing one, but indicating that the subsystems therein may not be required. Note that the "required versions" listed in this new table are those installed on my system, with the exception of the Linux C++ library which is apparently not installed here. These versions need to be tweaked to reflect the actual requirements for that kernel. C. Comparing the installed and required versions of each subsystem, and indicating the results of that comparison in the displayed results by colouring the name of the subsystem. A facility to disable this is also included, and is activated by providing a parameter to the script. Any parameter will serve this function. D. Inserting lines in the primary Makefile to allow `make vsn` to run the relevant command to generate the results with colouring, and `make vsnbw` to do so without colours. Both change the permissions of the script to make it an executable. There is ONE problem with this method, which I have not been able to solve. This is that the command used by scripts/ver_linux to determine the installed version of the Gnu C Library can't be replicated using the method this script is based on, and I have had to replace it with a simpler script which may produce different results in some cases. If this is a problem, it is open to others to solve as I have licensed this under version 2 (only) of the Gnu General Public Licence. Best wishes from Riley. --- linux/Documentation/Changes~Fri Feb 16 23:53:08 2001 +++ linux/Documentation/Changes Tue Mar 13 23:38:46 2001 @@ -48,16 +48,31 @@ Card) hardware, for example, you probably needn't concern yourself with pcmcia-cs. -o Gnu C 2.91.66 # gcc --version +o Gnu C # 2.91.66 # gcc --version -o Gnu make 3.77# make --version +o Gnu make # 3.77 # make --version -o binutils 2.9.1.0.25 # ld -v +o binutils # 2.9.1.0.25 # ld -v -o util-linux 2.10o # fdformat --version +o util-linux # 2.10o# fdformat --version -o modutils 2.4.2 # insmod -V +o modutils # 2.4.2# insmod -V -o e2fsprogs 1.19# tune2fs +o e2fsprogs # 1.19 # tune2fs -o reiserfsprogs 3.x.0b # reiserfsck 21|grep reiserfsprogs +o reiserfsprogs # 3.x.0b # reiserfsck 21|grep reiserfsprogs -o pcmcia-cs 3.1.21 # cardmgr -V +o pcmcia-cs # 3.1.21 # cardmgr -V -o PPP2.4.0 # pppd --version +o PPP# 2.4.0# pppd --version /dev/tty -o isdn4k-utils 3.1pre1 # isdnctrl 21|grep version +o isdn4k-utils # 3.1pre1 # isdnctrl 21|grep version + +In addition, it is wise to ensure that the following packages are at least +at the versions suggested below, although these may not be required, depending +on the exact configuration of your system: + +o Console Tools # 0.3.3# loadkeys -V +o Current Kernel # 2.2.10
RE: 2.4.2 Linux Kernel and latest binutils
Hi Nick. > Hi. I just compiled the 2.4.2 Linux Kernel on my machine and > ran into trouble with the linker. I had just installed the > latest build of binutils and apparently they changed the command > line flag from -oformat to --oformat, so the Makefile needed to > be edited in order to get it to compile. I'm not sure if you're > who's supposed to get mail on this or not, so if not, sorry :-) It's not something I can deal with personally, but the person responsible will be on the Linux-Kernel mailing list. I've taken the liberty of forwarding my reply there as well, with your original message quoted above. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.2 Linux Kernel and latest binutils
Hi Nick. Hi. I just compiled the 2.4.2 Linux Kernel on my machine and ran into trouble with the linker. I had just installed the latest build of binutils and apparently they changed the command line flag from -oformat to --oformat, so the Makefile needed to be edited in order to get it to compile. I'm not sure if you're who's supposed to get mail on this or not, so if not, sorry :-) It's not something I can deal with personally, but the person responsible will be on the Linux-Kernel mailing list. I've taken the liberty of forwarding my reply there as well, with your original message quoted above. Best wishes from Riley. - 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: About Celeron processor memory barrier problem
Hi Linus.
On Sun, 24 Dec 2000, Linus Torvalds wrote:
> On Sun, 24 Dec 2000, Tim Wright wrote:
>>> Which is all fine, but maybe the kernel really ought to detect
>>> that problem and complain at boot time?
>>>
>>> Or does that happen already?
>> There was a similar thread to this recently. The issue is that if
>> you choose the wrong processor type, you may not even be able to
>> complain.
Perhaps the boot and setup code should always be compiled to assume that
it's running on an i386 (or whatever the lowest common denominator is)
until it has verified that the correct processor is actually present?
Memory says that the boot and setup code is discarded during the boot
process, so this shouldn't cause any problems.
> Indeed. Some of the issues end up just becoming compiler flags,
> which means that anything that uses C is "tainted" by the processor
> choice. And happily there isn't all that much non-C in the kernel
> any more.
> One thing we _could_ potentially do is to simplify the CPU selection
> a bit, and make it a two-stage process. Basically have a
> bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
> which most people who just want to get the best kernel would use.
> Less confusion that way.
Something along the lines of the enclosed patch ???
Best wishes from Riley.
***
--- linux-2.2.18/arch/i386/config.in~ Tue Dec 12 12:59:50 2000
+++ linux-2.2.18/arch/i386/config.inMon Jan 1 11:44:23 2001
@@ -9,16 +9,36 @@
bool 'Prompt for development and/or incomplete code/drivers' CONFIG_EXPERIMENTAL
endmenu
mainmenu_option next_comment
comment 'Processor type and features'
+bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
+if [ "$CONFIG_CPU_CURRENT" = "y" ]; then
+
+
+ ####
+ ## Select current CPU. This is NOT valid in config.in ##
+ ## as it doesn't work with `make xconfig` at all, and ##
+ ## may not work with `make menuconfig` either.##
+ ####
+ ## The scripts/cpu shell script produces the variable ##
+ ## for the current processor or CONFIG_CPU_UNKNOWN if ##
+ ## it is unable to determine the current processor. ##
+ ####
+
+
+ define_bool `bash -c scripts/cpu` y
+
+fi
+if [ "$CONFIG_CPU_CURRENT" != "y" -o "$CONFIG_CPU_UNKNOWN" = "y" ]; then
-choice 'Processor family' \
+ choice ' Processor family' \
"386CONFIG_M386 \
486/Cx486 CONFIG_M486 \
586/K5/5x86/6x86 CONFIG_M586 \
Pentium/K6/TSC CONFIG_M586TSC \
PPro/6x86MXCONFIG_M686" PPro
+fi
#
# Define implied options from the CPU selection here
#
if [ "$CONFIG_M386" != "y" ]; then
define_bool CONFIG_X86_WP_WORKS_OK y
--- linux-2.2.18/scripts/cpu~ Thu Jan 1 01:00:00 1970
+++ linux-2.2.18/scripts/cpuMon Jan 1 14:39:11 2001
@@ -0,0 +1,33 @@
+#!/bin/bash
+
+function analyse() {
+ local CPU=CONFIG_CPU_UNKNOWN
+ local WORD
+
+ while read WORD ; do
+ case ".$WORD" in
+ .amd_k5)CPU=CONFIG_M586 ;;
+ .amd_k6)CPU=CONFIG_M586TSC ;;
+ .i386) CPU=CONFIG_M386 ;;
+ .i486) CPU=CONFIG_M486 ;;
+ .i586) CPU=CONFIG_M586 ;;
+ .pentium) CPU=CONFIG_M586 ;;
+ esac
+# echo "DEBUG: WORD = '$WORD', CPU = $CPU" >&2
+ done
+ echo $CPU
+}
+
+function model() {
+ uname -m
+ grep '^model name' /proc/cpuinfo | cut -d : -f 2-
+}
+
+function prepare() {
+ tr '(-' ' _'\
+ | tr -cd 'A-Z a-z_0-9\n'\
+ | tr A-Z a-z\
+ | tr -s ' ' '\n'
+}
+
+model | prepare | analyse
-
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: About Celeron processor memory barrier problem
Hi Linus.
On Sun, 24 Dec 2000, Linus Torvalds wrote:
On Sun, 24 Dec 2000, Tim Wright wrote:
Which is all fine, but maybe the kernel really ought to detect
that problem and complain at boot time?
Or does that happen already?
There was a similar thread to this recently. The issue is that if
you choose the wrong processor type, you may not even be able to
complain.
Perhaps the boot and setup code should always be compiled to assume that
it's running on an i386 (or whatever the lowest common denominator is)
until it has verified that the correct processor is actually present?
Memory says that the boot and setup code is discarded during the boot
process, so this shouldn't cause any problems.
Indeed. Some of the issues end up just becoming compiler flags,
which means that anything that uses C is "tainted" by the processor
choice. And happily there isn't all that much non-C in the kernel
any more.
One thing we _could_ potentially do is to simplify the CPU selection
a bit, and make it a two-stage process. Basically have a
bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
which most people who just want to get the best kernel would use.
Less confusion that way.
Something along the lines of the enclosed patch ???
Best wishes from Riley.
***
--- linux-2.2.18/arch/i386/config.in~ Tue Dec 12 12:59:50 2000
+++ linux-2.2.18/arch/i386/config.inMon Jan 1 11:44:23 2001
@@ -9,16 +9,36 @@
bool 'Prompt for development and/or incomplete code/drivers' CONFIG_EXPERIMENTAL
endmenu
mainmenu_option next_comment
comment 'Processor type and features'
+bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
+if [ "$CONFIG_CPU_CURRENT" = "y" ]; then
+
+
+ ####
+ ## Select current CPU. This is NOT valid in config.in ##
+ ## as it doesn't work with `make xconfig` at all, and ##
+ ## may not work with `make menuconfig` either.##
+ ####
+ ## The scripts/cpu shell script produces the variable ##
+ ## for the current processor or CONFIG_CPU_UNKNOWN if ##
+ ## it is unable to determine the current processor. ##
+ ####
+
+
+ define_bool `bash -c scripts/cpu` y
+
+fi
+if [ "$CONFIG_CPU_CURRENT" != "y" -o "$CONFIG_CPU_UNKNOWN" = "y" ]; then
-choice 'Processor family' \
+ choice ' Processor family' \
"386CONFIG_M386 \
486/Cx486 CONFIG_M486 \
586/K5/5x86/6x86 CONFIG_M586 \
Pentium/K6/TSC CONFIG_M586TSC \
PPro/6x86MXCONFIG_M686" PPro
+fi
#
# Define implied options from the CPU selection here
#
if [ "$CONFIG_M386" != "y" ]; then
define_bool CONFIG_X86_WP_WORKS_OK y
--- linux-2.2.18/scripts/cpu~ Thu Jan 1 01:00:00 1970
+++ linux-2.2.18/scripts/cpuMon Jan 1 14:39:11 2001
@@ -0,0 +1,33 @@
+#!/bin/bash
+
+function analyse() {
+ local CPU=CONFIG_CPU_UNKNOWN
+ local WORD
+
+ while read WORD ; do
+ case ".$WORD" in
+ .amd_k5)CPU=CONFIG_M586 ;;
+ .amd_k6)CPU=CONFIG_M586TSC ;;
+ .i386) CPU=CONFIG_M386 ;;
+ .i486) CPU=CONFIG_M486 ;;
+ .i586) CPU=CONFIG_M586 ;;
+ .pentium) CPU=CONFIG_M586 ;;
+ esac
+# echo "DEBUG: WORD = '$WORD', CPU = $CPU" 2
+ done
+ echo $CPU
+}
+
+function model() {
+ uname -m
+ grep '^model name' /proc/cpuinfo | cut -d : -f 2-
+}
+
+function prepare() {
+ tr '(-' ' _'\
+ | tr -cd 'A-Z a-z_0-9\n'\
+ | tr A-Z a-z\
+ | tr -s ' ' '\n'
+}
+
+model | prepare | analyse
-
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/
2.2.18: Patch to SysRq code
Hi Alan.
The enclosed patch deals with two problems relating to the Magic SysRq
function, as follows:
1. One of my pet peeves with SysRq as implemented is the apparently
random order theoptions as listed in the SysRq help list. This
patch sorts that list into case-insensitive alphabetical order.
2. According to the above-mentioned help list, the log level can be
set in the range 0 to 8. The code additionally allows log level
9 to be set, so this was added to the list.
Best wishes from Riley.
diff -urN linux-2.2.18.old/drivers/char/sysrq.c linux-2.2.18/drivers/char/sysrq.c
--- linux-2.2.18.old/drivers/char/sysrq.c Thu May 4 01:16:39 2000
+++ linux-2.2.18/drivers/char/sysrq.c Tue Dec 12 13:23:23 2000
@@ -134,16 +134,18 @@
orig_log_level = 8;
break;
default:/* Unknown: help */
- if (kbd)
- printk("unRaw ");
+ printk("Boot kIll killalL loglevel0-9 ");
+ if (sysrq_power_off)
+ printk("Off ");
#ifdef CONFIG_VT
if (tty)
printk("saK ");
#endif
- printk("Boot ");
- if (sysrq_power_off)
- printk("Off ");
- printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll
killalL\n");
+ printk("showMem showPc showTasks Sync tErm Unmount ");
+ if (kbd)
+ printk("unRaw ");
+ printk("\n");
+
/* Don't use 'A' as it's handled specially on the Sparc */
}
2.2.18: Configuration documentation
Hi Alan. I've just done a comparison of the configuration variables listed in the config.in files against those listed in the Configure.help file. I have enclosed the bash script I wrote to perform this analysis, and would like to submit it for inclusion with the kernel as the file... ./scripts/listvars The results indicate three types of problems with these variables: 1. 452 variables occur in the config.in files, but are never defined in Configure.help at all. I can think of the following reasons for this occurring: a. This will include variables from `choice` lines that do not need to be defined as they will never be asked for. Remember that only the first variable in any `choice` list is asked for by the help systems. b. This will include variables that should be documented, but are not. This needs to be corrected. 2. 50 variables occur in Configure.help but are never referenced in any of the config.in files. I can think of two reasons for this: a. The option is now obsolete, in which case the accompanying help text should also be deleted. b. The option is spelt differently (a typo) in the config.in files to how it is spelt in the Configure.help file, in which case the spelling needs to be standardised. The following may be cases where this has happenned: config.in version Configure.help version ~ ~~ CONFIG_ADVANCED CONFIG_ADVANCED_CPU CONFIG_OLD_BELKIN_DONGLECONFIG_OLD_BELKING_DONGLE CONFIG_SOUND_VMIDI CONFIG_SOUND_MIDI ~ ~~ There could easily be others, and equally well, the above may not be equivalent pairs. 3. There are four variables that are documented twice each in the Config.help file, two of which never occur in the config.in files. These are as follows: Config Help Variable ~~ 1 2 CONFIG_ADFS_FS <**> 2 CONFIG_ATOMWIDE_SERIAL <**> 2 CONFIG_DUALSP_SERIAL 1 2 CONFIG_RADIO_CADET ~~ I have presumed that the duplicate descriptions need to be merged, and have attached a patch to do so. The results produced from this analysis are shown below, with the items marked with '<**>' being the ones that appear to be missing in each case. They are sorted into ASCII order, and are grouped by the first 9 characters of the variable name. Config Help Variable ~~ 1 1 CONFIG_060_WRITETHROUGH 1<**> CONFIG_1GB 1<**> CONFIG_2GB 1<**> CONFIG_3215 1<**> CONFIG_3215_CONSOLE 1<**> CONFIG_3C515 1 1 CONFIG_60XX_WDT 3 1 CONFIG_6PACK 1 1 CONFIG_6xx 1 1 CONFIG_82C710_MOUSE 1<**> CONFIG_8xx 2 1 CONFIG_A2065 1 1 CONFIG_A2091_SCSI 1 1 CONFIG_A3000_SCSI 1<**> CONFIG_A4000T_SCSI 1<**> CONFIG_A4091_SCSI 1<**> CONFIG_ABSTRACT_CONSOLE 1 1 CONFIG_AC3200 1 1 CONFIG_ACENIC 1 1 CONFIG_ACER_PICA_61 1 1 CONFIG_ACI_MIXER 1 1 CONFIG_ACQUIRE_WDT 1 1 CONFIG_ACSI_MULTI_LUN 1 1 CONFIG_ACTISYS_DONGLE 1<**> CONFIG_AD1816_BASE 1<**> CONFIG_AD1816_CLOCK 1<**> CONFIG_AD1816_DMA 1<**> CONFIG_AD1816_DMA2 1<**> CONFIG_AD1816_IRQ 2 1 CONFIG_ADBMOUSE 2<**> CONFIG_ADDIN_FOOTBRIDGE 1 2 CONFIG_ADFS_FS 1<**> CONFIG_ADVANCED <**> 1 CONFIG_ADVANCED_CPU 1 1 CONFIG_AEDSP16 4 1 CONFIG_AEDSP16_BASE 1 1 CONFIG_AEDSP16_MPU401 1 1 CONFIG_AEDSP16_MPU_IRQ 1 1 CONFIG_AEDSP16_MSS 1 1 CONFIG_AEDSP16_MSS_DMA 1 1 CONFIG_AEDSP16_MSS_IRQ 1 1 CONFIG_AEDSP16_SBPRO 1 1 CONFIG_AEDSP16_SB_DMA 1 1 CONFIG_AEDSP16_SB_IRQ 1 1 CONFIG_AFFS_FS 1 1 CONFIG_AGP 1 1 CONFIG_AGP_ALI 1 1 CONFIG_AGP_AMD 1 1 CONFIG_AGP_I810 1 1 CONFIG_AGP_INTEL 1 1 CONFIG_AGP_SIS 1 1 CONFIG_AGP_VIA 2 1 CONFIG_AIC7XXX_CMDS_PER_DEVICE 2 1 CONFIG_AIC7XXX_PROC_STATS 2 1 CONFIG_AIC7XXX_RESET_DELAY 2 1 CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT 1 1 CONFIG_ALGOR_P4032 1 1 CONFIG_ALIGNMENT_TRAP 1<**> CONFIG_ALL_PPC 1<**> CONFIG_ALPHA_ALCOR 3<**> CONFIG_ALPHA_APECS 2<**> CONFIG_ALPHA_AVANTI 1<**> CONFIG_ALPHA_BOOK1 1<**> CONFIG_ALPHA_CABRIOLET 3<**> CONFIG_ALPHA_CIA 1<**> CONFIG_ALPHA_DP264 1<**> CONFIG_ALPHA_EB164 2<**> CONFIG_ALPHA_EB64P 1<**> CONFIG_ALPHA_EB66 1<**>
2.2.18: Configuration documentation
Hi Alan. I've just done a comparison of the configuration variables listed in the config.in files against those listed in the Configure.help file. I have enclosed the bash script I wrote to perform this analysis, and would like to submit it for inclusion with the kernel as the file... ./scripts/listvars The results indicate three types of problems with these variables: 1. 452 variables occur in the config.in files, but are never defined in Configure.help at all. I can think of the following reasons for this occurring: a. This will include variables from `choice` lines that do not need to be defined as they will never be asked for. Remember that only the first variable in any `choice` list is asked for by the help systems. b. This will include variables that should be documented, but are not. This needs to be corrected. 2. 50 variables occur in Configure.help but are never referenced in any of the config.in files. I can think of two reasons for this: a. The option is now obsolete, in which case the accompanying help text should also be deleted. b. The option is spelt differently (a typo) in the config.in files to how it is spelt in the Configure.help file, in which case the spelling needs to be standardised. The following may be cases where this has happenned: config.in version Configure.help version ~ ~~ CONFIG_ADVANCED CONFIG_ADVANCED_CPU CONFIG_OLD_BELKIN_DONGLECONFIG_OLD_BELKING_DONGLE CONFIG_SOUND_VMIDI CONFIG_SOUND_MIDI ~ ~~ There could easily be others, and equally well, the above may not be equivalent pairs. 3. There are four variables that are documented twice each in the Config.help file, two of which never occur in the config.in files. These are as follows: Config Help Variable ~~ 1 2 CONFIG_ADFS_FS ** 2 CONFIG_ATOMWIDE_SERIAL ** 2 CONFIG_DUALSP_SERIAL 1 2 CONFIG_RADIO_CADET ~~ I have presumed that the duplicate descriptions need to be merged, and have attached a patch to do so. The results produced from this analysis are shown below, with the items marked with '**' being the ones that appear to be missing in each case. They are sorted into ASCII order, and are grouped by the first 9 characters of the variable name. Config Help Variable ~~ 1 1 CONFIG_060_WRITETHROUGH 1** CONFIG_1GB 1** CONFIG_2GB 1** CONFIG_3215 1** CONFIG_3215_CONSOLE 1** CONFIG_3C515 1 1 CONFIG_60XX_WDT 3 1 CONFIG_6PACK 1 1 CONFIG_6xx 1 1 CONFIG_82C710_MOUSE 1** CONFIG_8xx 2 1 CONFIG_A2065 1 1 CONFIG_A2091_SCSI 1 1 CONFIG_A3000_SCSI 1** CONFIG_A4000T_SCSI 1** CONFIG_A4091_SCSI 1** CONFIG_ABSTRACT_CONSOLE 1 1 CONFIG_AC3200 1 1 CONFIG_ACENIC 1 1 CONFIG_ACER_PICA_61 1 1 CONFIG_ACI_MIXER 1 1 CONFIG_ACQUIRE_WDT 1 1 CONFIG_ACSI_MULTI_LUN 1 1 CONFIG_ACTISYS_DONGLE 1** CONFIG_AD1816_BASE 1** CONFIG_AD1816_CLOCK 1** CONFIG_AD1816_DMA 1** CONFIG_AD1816_DMA2 1** CONFIG_AD1816_IRQ 2 1 CONFIG_ADBMOUSE 2** CONFIG_ADDIN_FOOTBRIDGE 1 2 CONFIG_ADFS_FS 1** CONFIG_ADVANCED ** 1 CONFIG_ADVANCED_CPU 1 1 CONFIG_AEDSP16 4 1 CONFIG_AEDSP16_BASE 1 1 CONFIG_AEDSP16_MPU401 1 1 CONFIG_AEDSP16_MPU_IRQ 1 1 CONFIG_AEDSP16_MSS 1 1 CONFIG_AEDSP16_MSS_DMA 1 1 CONFIG_AEDSP16_MSS_IRQ 1 1 CONFIG_AEDSP16_SBPRO 1 1 CONFIG_AEDSP16_SB_DMA 1 1 CONFIG_AEDSP16_SB_IRQ 1 1 CONFIG_AFFS_FS 1 1 CONFIG_AGP 1 1 CONFIG_AGP_ALI 1 1 CONFIG_AGP_AMD 1 1 CONFIG_AGP_I810 1 1 CONFIG_AGP_INTEL 1 1 CONFIG_AGP_SIS 1 1 CONFIG_AGP_VIA 2 1 CONFIG_AIC7XXX_CMDS_PER_DEVICE 2 1 CONFIG_AIC7XXX_PROC_STATS 2 1 CONFIG_AIC7XXX_RESET_DELAY 2 1 CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT 1 1 CONFIG_ALGOR_P4032 1 1 CONFIG_ALIGNMENT_TRAP 1** CONFIG_ALL_PPC 1** CONFIG_ALPHA_ALCOR 3** CONFIG_ALPHA_APECS 2** CONFIG_ALPHA_AVANTI 1** CONFIG_ALPHA_BOOK1 1** CONFIG_ALPHA_CABRIOLET 3** CONFIG_ALPHA_CIA 1** CONFIG_ALPHA_DP264 1** CONFIG_ALPHA_EB164 2** CONFIG_ALPHA_EB64P 1** CONFIG_ALPHA_EB66 1** CONFIG_ALPHA_EB66P 1** CONFIG_ALPHA_EIGER 2** CONFIG_ALPHA_EISA
2.2.18: Patch to SysRq code
Hi Alan.
The enclosed patch deals with two problems relating to the Magic SysRq
function, as follows:
1. One of my pet peeves with SysRq as implemented is the apparently
random order theoptions as listed in the SysRq help list. This
patch sorts that list into case-insensitive alphabetical order.
2. According to the above-mentioned help list, the log level can be
set in the range 0 to 8. The code additionally allows log level
9 to be set, so this was added to the list.
Best wishes from Riley.
diff -urN linux-2.2.18.old/drivers/char/sysrq.c linux-2.2.18/drivers/char/sysrq.c
--- linux-2.2.18.old/drivers/char/sysrq.c Thu May 4 01:16:39 2000
+++ linux-2.2.18/drivers/char/sysrq.c Tue Dec 12 13:23:23 2000
@@ -134,16 +134,18 @@
orig_log_level = 8;
break;
default:/* Unknown: help */
- if (kbd)
- printk("unRaw ");
+ printk("Boot kIll killalL loglevel0-9 ");
+ if (sysrq_power_off)
+ printk("Off ");
#ifdef CONFIG_VT
if (tty)
printk("saK ");
#endif
- printk("Boot ");
- if (sysrq_power_off)
- printk("Off ");
- printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll
killalL\n");
+ printk("showMem showPc showTasks Sync tErm Unmount ");
+ if (kbd)
+ printk("unRaw ");
+ printk("\n");
+
/* Don't use 'A' as it's handled specially on the Sparc */
}
Re: That horrible hack from hell called A20
Hi Peter. On Tue, 5 Dec 2000, H. Peter Anvin wrote: > Linus Torvalds wrote: >> Actually, I bet I know what's up. >> >> Want to bet $5 USD that suspend/resume saves the keyboard A20 state, >> but does NOT save the fast-A20 gate information? >> >> So anything that enables A20 with only the fast A20 gate will find >> that A20 is disabled again on resume. >> >> Which would make Linux _really_ unhappy, needless to say. Instant >> death in the form of a triple fault (all of the Linux kernel code is >> in the 1-2MB area, which would be invisible), resulting in an >> instant reboot. >> >> Peter, we definitely need to do the keyboard A20, even if fast-A20 >> works fine. > Yup. It's a BIOS bug, oh what a shocker... (that never happens, > right)? One alternative would presumably be to reserve a block in the 0-1M region for a routine to be called on resume that makes sure everything is set up correctly. However, from the various comments, I gather that such is not viable as it's already been excluded for other reasons, but nobody seems to say precicely what the problems with this idea are? I would presume such a routine would be set up such that when it's time to suspend, a call is made to that routine at its 0-1M address, so when the resume kicks in, it sees an IP in the 0-1M region to resume to. As part of the kernel start-up, the kernel would reserve the page in question, then copy the suspend/resume code to it, and only then would it enable the suspend/resume facility. Best wishes from Riley. --- * Why didn't Linus Torvalds write the resume specification, * rather than those idiots at MacroHard !!! - 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: That horrible hack from hell called A20
Hi Peter. On Tue, 5 Dec 2000, H. Peter Anvin wrote: Linus Torvalds wrote: Actually, I bet I know what's up. Want to bet $5 USD that suspend/resume saves the keyboard A20 state, but does NOT save the fast-A20 gate information? So anything that enables A20 with only the fast A20 gate will find that A20 is disabled again on resume. Which would make Linux _really_ unhappy, needless to say. Instant death in the form of a triple fault (all of the Linux kernel code is in the 1-2MB area, which would be invisible), resulting in an instant reboot. Peter, we definitely need to do the keyboard A20, even if fast-A20 works fine. Yup. It's a BIOS bug, oh what a shocker... (that never happens, right)? One alternative would presumably be to reserve a block in the 0-1M region for a routine to be called on resume that makes sure everything is set up correctly. However, from the various comments, I gather that such is not viable as it's already been excluded for other reasons, but nobody seems to say precicely what the problems with this idea are? I would presume such a routine would be set up such that when it's time to suspend, a call is made to that routine at its 0-1M address, so when the resume kicks in, it sees an IP in the 0-1M region to resume to. As part of the kernel start-up, the kernel would reserve the page in question, then copy the suspend/resume code to it, and only then would it enable the suspend/resume facility. Best wishes from Riley. --- * Why didn't Linus Torvalds write the resume specification, * rather than those idiots at MacroHard !!! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.X patch query (with initial PATCH against 2.2.17)
Hi Horst. >>> Also, part of my plan was to check that the disk is >>> already in this non-standard format, and refuse to >>> dump if not. This would ensure that doing so didn't >>> overwrite somebody's master boot disk by accident, as >>> such disks will not normally be in this non-standard >>> format. >> Just write a magic number somewhere to the disk and >> mark these blocks bad in the fat. Then just check if >> the blocks are marked as bad and contain the magic >> number. No need for a special disk format per se... There's much better reasons for using a special format than that. Horst has hit the main one - code simplicity. > Why any filesystem at all? Just dump the whole on the > diskette in the drive. If root doesn't know what they > are doing fiddling with SysRq, they deserve it in any > case. No FAT, MS-DOS, VFAT or whatever. Just a plain > formated diskette. That argument's a non-starter in my book - the difference between writing a raw floppy and one with an MS-DOS type filesystem on it comes down to prepending a fixed header to the data, nothing more. The MS-DOS type of filesystem is one of the simplest one can get, but the standard version thereof used with floppies is just a PITA to work with. What I've done is to remain compatible with it, but tweak the parameters to produce a much simpler version thereof. > Remember, this has to be absolutely as simple and > robust as possible, and have minimal impact on the > rest of the kernel... That's precicely why I'm using the modified filesystem I referred to in a previous post. Can I suggest that, before you complain any more about it, you actually try it out? I wrote and released the formatter that produces the said filesystem many months ago now, and can easily send you a copy to play with. It's also its own source code, as the said formatter is written entirely as a BASH shell script, and the fact that it's done that way should speak for itself as to the simplicity of the format used. Basically, from a programming point of view, it comes down to writing a raw disk, but prepending a fixed header (size 4k on a 1440k floppy) to the log being written, and gaining a LOT of advantages with virtually no disadvantages. For reference, here's a few of the features of the said format: 1. Disks in this format can be read from and written to by MS-DOS 2.11, 3.10, 5.00 and 6.22 and by Windows 95, 98 and NT (all tested). 2. Disks formatted in this format do NOT use any extra tracks or sectors per track over those formatted in the standard format. 3. From a programmer's viewpoint, the resulting format is MUCH simpler to handle than the standard one. 4. The data area available on the disk is maximised for any particular physical layout. The first two features mean that the resulting disks can be used on ANY standard floppy drive. The third means that the so-called bloat just will not exist. The fourth is the one that people seem to have concentrated on, but is irrelevant for this application. That particular feature is only really relevant for backup disks. > ...(no "must now pull in RW-floppy-format + fat + > msdos modules to do SysRq-D", no " must be built > into the kernel for SysRq-D to work" (at most "floppy > in kernel", more can be hard to swallow in limited > environments where this will be most needed as the > only/principal way of looking at logs)). None of that is required to use this format - it is designed to (a) be fully compatible with the requirements of MS-DOS 2.00 and later (including WIndows 9x and NT, and (b) be as simple as possible for the programmer to code. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.X patch query (with initial PATCH against 2.2.17)
Hi Horst. Also, part of my plan was to check that the disk is already in this non-standard format, and refuse to dump if not. This would ensure that doing so didn't overwrite somebody's master boot disk by accident, as such disks will not normally be in this non-standard format. Just write a magic number somewhere to the disk and mark these blocks bad in the fat. Then just check if the blocks are marked as bad and contain the magic number. No need for a special disk format per se... There's much better reasons for using a special format than that. Horst has hit the main one - code simplicity. Why any filesystem at all? Just dump the whole on the diskette in the drive. If root doesn't know what they are doing fiddling with SysRq, they deserve it in any case. No FAT, MS-DOS, VFAT or whatever. Just a plain formated diskette. That argument's a non-starter in my book - the difference between writing a raw floppy and one with an MS-DOS type filesystem on it comes down to prepending a fixed header to the data, nothing more. The MS-DOS type of filesystem is one of the simplest one can get, but the standard version thereof used with floppies is just a PITA to work with. What I've done is to remain compatible with it, but tweak the parameters to produce a much simpler version thereof. Remember, this has to be absolutely as simple and robust as possible, and have minimal impact on the rest of the kernel... That's precicely why I'm using the modified filesystem I referred to in a previous post. Can I suggest that, before you complain any more about it, you actually try it out? I wrote and released the formatter that produces the said filesystem many months ago now, and can easily send you a copy to play with. It's also its own source code, as the said formatter is written entirely as a BASH shell script, and the fact that it's done that way should speak for itself as to the simplicity of the format used. Basically, from a programming point of view, it comes down to writing a raw disk, but prepending a fixed header (size 4k on a 1440k floppy) to the log being written, and gaining a LOT of advantages with virtually no disadvantages. For reference, here's a few of the features of the said format: 1. Disks in this format can be read from and written to by MS-DOS 2.11, 3.10, 5.00 and 6.22 and by Windows 95, 98 and NT (all tested). 2. Disks formatted in this format do NOT use any extra tracks or sectors per track over those formatted in the standard format. 3. From a programmer's viewpoint, the resulting format is MUCH simpler to handle than the standard one. 4. The data area available on the disk is maximised for any particular physical layout. The first two features mean that the resulting disks can be used on ANY standard floppy drive. The third means that the so-called bloat just will not exist. The fourth is the one that people seem to have concentrated on, but is irrelevant for this application. That particular feature is only really relevant for backup disks. ...(no "must now pull in RW-floppy-format + fat + msdos modules to do SysRq-D", no "foo must be built into the kernel for SysRq-D to work" (at most "floppy in kernel", more can be hard to swallow in limited environments where this will be most needed as the only/principal way of looking at logs)). None of that is required to use this format - it is designed to (a) be fully compatible with the requirements of MS-DOS 2.00 and later (including WIndows 9x and NT, and (b) be as simple as possible for the programmer to code. Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.X patch query (with initial PATCH against 2.2.17)
Hi Horst.
>> Before I go any further with this, I would like to ask a few
>> questions relating to it:
>> 1. Is there any likelihood of this making it into the official
>>kernel, or am I just wasting my time?
> Depends, I'd say... perhaps after a long shakeout and much use.
Fair enough - I'd expect that much...
>> 2. Would I be right in thinking it's too late for either the
>>2.2 or 2.4 kernels ???
> No way.
Good...
I've included a patch against 2.2.17 that deals with all of the
existing files and implements a version of this facility that just
prints "(Not yet implemented)" into the SysLog. The final version will
basically consist of this patch with the printk("Not yet implemeted")
replaced by a call to the routine to actually perform the dump, plus a
new file kernel/dumplog.c containing the said routine.
Note that this patch tweaks ALL of the current architecture config.in
files to replace the CONFIG_MAGIC_SYSRQ definition with a command to
include the new arch/sysrq.in file at that point, and all the options
relating to SYSRQ are in this new file instead.
>> 5. I was wondering about providing some means of selecting
>>whether to dump to /dev/fd0 or /dev/fd1 (or others if
>>present). What would be your opinion on this?
> Keep it as simple as possible. I'd leave the option open if not
> hard, but not implement it at all at first.
OK. Initially, I'll look at dropping it strictly to /dev/fd0 and leave
the /dev/fd1 code until later.
>> 6. A while back, I developed a high-level floppy formatter
>>that produces a non-standard DOS-compatible format that
>>allows 1436k of data on a 1440k floppy, and produced a
>>bash script that would produce disks formatted in this
>>format.
>>My current plans are for SYSRQ-D to raw write direct to
>>/dev/fd0 and effectively reformat the disks in this
>>format, dropping the log file thereon in the process. I
>>don't plan on doing the low-level format, just the
>>high-level one.
> KISS, again. What use is a non-standard 1436Kb DOS format when
> writing at most 1Mb?
The said floppy formatter also works with other capacity disks, and
always minimises the system overhead for the disk size.
Also, part of my plan was to check that the disk is already in this
non-standard format, and refuse to dump if not. This would ensure that
doing so didn't overwrite somebody's master boot disk by accident, as
such disks will not normally be in this non-standard format.
> I'd just dump it raw to /dev/fd0, whoever wants to read it later
> will have all kinds of tools at hand.
> Remember:
> - Bloat
That's one reason why I was glad to note the error in the comments in
kernel/printk.c that I sent a patch to correct last week - this patch
will be MUCH simpler as a result.
> - This will have to work even in a thoroughly hosed system to be
> of any use
It's for precicely that reason that I'm working on it.
Best wishes from Riley.
--- linux-2.2.17/arch/alpha/config.in~ Mon Sep 4 18:39:16 2000
+++ linux-2.2.17/arch/alpha/config.in Tue Oct 31 13:18:57 2000
@@ -299,8 +299,7 @@
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'Kernel FP software completion' CONFIG_MATHEMU
else
define_bool CONFIG_MATHEMU y
fi
-
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/arm/config.in~Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/arm/config.in Tue Oct 31 13:19:11 2000
@@ -214,7 +214,7 @@
mainmenu_option next_comment
comment 'Kernel hacking'
bool 'Debug kernel errors' CONFIG_DEBUG_ERRORS
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/i386/config.in~ Mon Sep 4 18:39:16 2000
+++ linux-2.2.17/arch/i386/config.inTue Oct 31 13:29:03 2000
@@ -204,8 +204,7 @@
mainmenu_option next_comment
comment 'Kernel hacking'
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
-
--- linux-2.2.17/arch/m68k/config.in~ Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/m68k/config.inTue Oct 31 13:19:27 2000
@@ -448,8 +448,8 @@
mainmenu_option next_comment
comment 'Kernel hacking'
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
bool 'Remote debugging support' CONFIG_KGDB
endmenu
--- linux-2.2.17/arch/mips/config.in~ Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/mips/config.inTue Oct 31 13:19:42 2000
@@ -303,7 +303,7 @@
bool ' Build fp execption handler module' CONFIG_MIPS_FPE_MODULE
fi
if [ "$CONFIG_SERIAL" = "y" ]; then
bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
fi
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/ppc/config.in~Mon Sep 4 18:39:16 2000
+++
Re: 2.2.X patch query (with initial PATCH against 2.2.17)
Hi Horst.
Before I go any further with this, I would like to ask a few
questions relating to it:
1. Is there any likelihood of this making it into the official
kernel, or am I just wasting my time?
Depends, I'd say... perhaps after a long shakeout and much use.
Fair enough - I'd expect that much...
2. Would I be right in thinking it's too late for either the
2.2 or 2.4 kernels ???
No way.
Good...
I've included a patch against 2.2.17 that deals with all of the
existing files and implements a version of this facility that just
prints "(Not yet implemented)" into the SysLog. The final version will
basically consist of this patch with the printk("Not yet implemeted")
replaced by a call to the routine to actually perform the dump, plus a
new file kernel/dumplog.c containing the said routine.
Note that this patch tweaks ALL of the current architecture config.in
files to replace the CONFIG_MAGIC_SYSRQ definition with a command to
include the new arch/sysrq.in file at that point, and all the options
relating to SYSRQ are in this new file instead.
5. I was wondering about providing some means of selecting
whether to dump to /dev/fd0 or /dev/fd1 (or others if
present). What would be your opinion on this?
Keep it as simple as possible. I'd leave the option open if not
hard, but not implement it at all at first.
OK. Initially, I'll look at dropping it strictly to /dev/fd0 and leave
the /dev/fd1 code until later.
6. A while back, I developed a high-level floppy formatter
that produces a non-standard DOS-compatible format that
allows 1436k of data on a 1440k floppy, and produced a
bash script that would produce disks formatted in this
format.
My current plans are for SYSRQ-D to raw write direct to
/dev/fd0 and effectively reformat the disks in this
format, dropping the log file thereon in the process. I
don't plan on doing the low-level format, just the
high-level one.
KISS, again. What use is a non-standard 1436Kb DOS format when
writing at most 1Mb?
The said floppy formatter also works with other capacity disks, and
always minimises the system overhead for the disk size.
Also, part of my plan was to check that the disk is already in this
non-standard format, and refuse to dump if not. This would ensure that
doing so didn't overwrite somebody's master boot disk by accident, as
such disks will not normally be in this non-standard format.
I'd just dump it raw to /dev/fd0, whoever wants to read it later
will have all kinds of tools at hand.
Remember:
- Bloat
That's one reason why I was glad to note the error in the comments in
kernel/printk.c that I sent a patch to correct last week - this patch
will be MUCH simpler as a result.
- This will have to work even in a thoroughly hosed system to be
of any use
It's for precicely that reason that I'm working on it.
Best wishes from Riley.
--- linux-2.2.17/arch/alpha/config.in~ Mon Sep 4 18:39:16 2000
+++ linux-2.2.17/arch/alpha/config.in Tue Oct 31 13:18:57 2000
@@ -299,8 +299,7 @@
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'Kernel FP software completion' CONFIG_MATHEMU
else
define_bool CONFIG_MATHEMU y
fi
-
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/arm/config.in~Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/arm/config.in Tue Oct 31 13:19:11 2000
@@ -214,7 +214,7 @@
mainmenu_option next_comment
comment 'Kernel hacking'
bool 'Debug kernel errors' CONFIG_DEBUG_ERRORS
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/i386/config.in~ Mon Sep 4 18:39:16 2000
+++ linux-2.2.17/arch/i386/config.inTue Oct 31 13:29:03 2000
@@ -204,8 +204,7 @@
mainmenu_option next_comment
comment 'Kernel hacking'
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
-
--- linux-2.2.17/arch/m68k/config.in~ Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/m68k/config.inTue Oct 31 13:19:27 2000
@@ -448,8 +448,8 @@
mainmenu_option next_comment
comment 'Kernel hacking'
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
bool 'Remote debugging support' CONFIG_KGDB
endmenu
--- linux-2.2.17/arch/mips/config.in~ Wed Jun 7 22:26:42 2000
+++ linux-2.2.17/arch/mips/config.inTue Oct 31 13:19:42 2000
@@ -303,7 +303,7 @@
bool ' Build fp execption handler module' CONFIG_MIPS_FPE_MODULE
fi
if [ "$CONFIG_SERIAL" = "y" ]; then
bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
fi
-bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+source ../sysrq.in
endmenu
--- linux-2.2.17/arch/ppc/config.in~Mon Sep 4 18:39:16 2000
+++ linux-2.2.17/arch/ppc/config.in Tue Oct 31 13:20:01 2000
@@ -195,9
2.2.X patch query
Hi Alan. You may remember a while back a suggestion that panic messages be dumped to floppy so they can be read afterwards. I've been looking into this idea for a while, in between working on my plans to get married, and looking for a job somewhere, and I think I have the bones of it laid out now. I'm NOT planning on making panics automatically dump to floppy. What I was looking at instead was to add a SysRq option to dump the current syslog buffer to floppy. This would be available at any time, but ONLY if the kernel has SYSRQ support compiled in, and has additionally enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In addition, it would need to be enabled at runtime, probably by writing to a root-owned /proc file with 0600 permissions. Before I go any further with this, I would like to ask a few questions relating to it: 1. Is there any likelihood of this making it into the official kernel, or am I just wasting my time? 2. Would I be right in thinking it's too late for either the 2.2 or 2.4 kernels ??? Assuming it'd be of interest to Linus and yourself... 3. My investigations so far have indicated that the current syslog buffer at 16k is too small to guarantee that all the relevant messages are still there. I would therefore be looking at increasing this to at least 32k, and would probably include a config menu to select the size to use if CONFIG_SYSRQ_DUMPLOG is enabled, offering 32k, 64k, 128k, 256k, 512k and 1M as options. Would this cause any problems? 4. My choice would be to use SYSRQ-D to activate this. Are there any other plans for that combination, that you are aware of? 5. I was wondering about providing some means of selecting whether to dump to /dev/fd0 or /dev/fd1 (or others if present). What would be your opinion on this? 6. A while back, I developed a high-level floppy formatter that produces a non-standard DOS-compatible format that allows 1436k of data on a 1440k floppy, and produced a bash script that would produce disks formatted in this format. My current plans are for SYSRQ-D to raw write direct to /dev/fd0 and effectively reformat the disks in this format, dropping the log file thereon in the process. I don't plan on doing the low-level format, just the high-level one. Can you see anything wrong with this idea? Best wishes from Riley. - 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/
2.2.X patch query
Hi Alan. You may remember a while back a suggestion that panic messages be dumped to floppy so they can be read afterwards. I've been looking into this idea for a while, in between working on my plans to get married, and looking for a job somewhere, and I think I have the bones of it laid out now. I'm NOT planning on making panics automatically dump to floppy. What I was looking at instead was to add a SysRq option to dump the current syslog buffer to floppy. This would be available at any time, but ONLY if the kernel has SYSRQ support compiled in, and has additionally enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In addition, it would need to be enabled at runtime, probably by writing to a root-owned /proc file with 0600 permissions. Before I go any further with this, I would like to ask a few questions relating to it: 1. Is there any likelihood of this making it into the official kernel, or am I just wasting my time? 2. Would I be right in thinking it's too late for either the 2.2 or 2.4 kernels ??? Assuming it'd be of interest to Linus and yourself... 3. My investigations so far have indicated that the current syslog buffer at 16k is too small to guarantee that all the relevant messages are still there. I would therefore be looking at increasing this to at least 32k, and would probably include a config menu to select the size to use if CONFIG_SYSRQ_DUMPLOG is enabled, offering 32k, 64k, 128k, 256k, 512k and 1M as options. Would this cause any problems? 4. My choice would be to use SYSRQ-D to activate this. Are there any other plans for that combination, that you are aware of? 5. I was wondering about providing some means of selecting whether to dump to /dev/fd0 or /dev/fd1 (or others if present). What would be your opinion on this? 6. A while back, I developed a high-level floppy formatter that produces a non-standard DOS-compatible format that allows 1436k of data on a 1440k floppy, and produced a bash script that would produce disks formatted in this format. My current plans are for SYSRQ-D to raw write direct to /dev/fd0 and effectively reformat the disks in this format, dropping the log file thereon in the process. I don't plan on doing the low-level format, just the high-level one. Can you see anything wrong with this idea? Best wishes from Riley. - 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/
Obviously-correct patch to 2.2.17
Hi Alan. This patch simply corrects a couple of comments in the said file to reflect what the code actually does rather than (presumably) what the code used to do at some time in the distant past. In my case, I've been working on a patch for the kernel that uses these facilities, and was getting confused because of the discrepancy between what the comments say and what actually happens. It wasn't until I realised that the comments were just plain wrong that I was able to sort the thing out, so I'm submitting this patch to prevent others having the same problem. Incidentally, the code as it stands actually simplifies the patch I was working on considerably, and I regard this as a useful feature as a result. I don't have the latest 2.4-pre kernel to hand to check, but it's quite likely that this patch can also be applied to that with the same results. Best wishes from Riley. * Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/ --- linux-2.2.17/kernel/printk.c~ Wed Oct 27 01:53:42 1999 +++ linux-2.2.17/kernel/printk.cSat Oct 28 10:01:20 2000 @@ -109,12 +109,12 @@ * Commands to do_syslog: * * 0 -- Close the log. Currently a NOP. * 1 -- Open the log. Currently a NOP. * 2 -- Read from the log. - * 3 -- Read up to the last 4k of messages in the ring buffer. + * 3 -- Read all messages remaining in the ring buffer. - * 4 -- Read and clear last 4k of messages in the ring buffer + * 4 -- Read and clear all messages remaining in the ring buffer * 5 -- Clear ring buffer. * 6 -- Disable printk's to console * 7 -- Enable printk's to console * 8 -- Set level of messages printed to console */
Obviously-correct patch to 2.2.17
Hi Alan. This patch simply corrects a couple of comments in the said file to reflect what the code actually does rather than (presumably) what the code used to do at some time in the distant past. In my case, I've been working on a patch for the kernel that uses these facilities, and was getting confused because of the discrepancy between what the comments say and what actually happens. It wasn't until I realised that the comments were just plain wrong that I was able to sort the thing out, so I'm submitting this patch to prevent others having the same problem. Incidentally, the code as it stands actually simplifies the patch I was working on considerably, and I regard this as a useful feature as a result. I don't have the latest 2.4-pre kernel to hand to check, but it's quite likely that this patch can also be applied to that with the same results. Best wishes from Riley. * Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/ --- linux-2.2.17/kernel/printk.c~ Wed Oct 27 01:53:42 1999 +++ linux-2.2.17/kernel/printk.cSat Oct 28 10:01:20 2000 @@ -109,12 +109,12 @@ * Commands to do_syslog: * * 0 -- Close the log. Currently a NOP. * 1 -- Open the log. Currently a NOP. * 2 -- Read from the log. - * 3 -- Read up to the last 4k of messages in the ring buffer. + * 3 -- Read all messages remaining in the ring buffer. - * 4 -- Read and clear last 4k of messages in the ring buffer + * 4 -- Read and clear all messages remaining in the ring buffer * 5 -- Clear ring buffer. * 6 -- Disable printk's to console * 7 -- Enable printk's to console * 8 -- Set level of messages printed to console */
Re: kernel governance
Hi Tony. > sorry for the cold call - i've been trying to find a statement > about 'kernel governance' and how new code is accepted into the > kernel... To help anybody else wondering about these issues, I've cc'd my reply to the Linux-Kernel mailing list for comments. However, please note that the comments herein are expressions of my own opinions, and may not reflect those of other developers. Additional comments from other developers should be cc'd to Tony as I don't think he's on this list. However, I am on the list, so there is no need to CC to me... > any hints? Well, I'm not even sure what you mean by "kernel governance" but the way to get your code into the kernel is well documented. Here's a basic summary of the procedure: 1. Subscribe to the Linux-Kernel mailing list. This is where ALL issues relating to the ENTIRE Linux kernel are thrown open for discussion. I will warn you in advance that this is a VERY active list and it is not unusual to get 300+ emails a day in that one list. My personal record from the Linux-Kernel list alone is 793 emails in one day. Make sure you can handle emails in that sort of volume first. 2. Monitor the list for AT LEAST 15 DAYS to see what issues are being discussed at the moment. In particular, watch out for ANY emails from "Linus Torvalds" or "Alan Cox" which mention such things as "Feature Freeze". 3. When you are satisfied with your understanding of the dynamics of the Linux-Kernel mailing list, post an email (sent using "Plain Text" mode - HTML emails are IGNORED by MANY of the kernel developers simply because of the volume of mail on the list. This email should contain a description of the purpose of your code, and should have attached to it (in MIME format) a PATCH against the relevant CURRENT kernel source tree that is in UNIFIED DIFF FORMAT. This format is generated by applying the -u4 parameter to the diff command. Note that the patch should NOT be embedded in the text of the email as doing so will almost certainly make the patch useless - it will either get munged by your email sending software or by the recipients mail reading software. Either the subject line or the descriptive text MUST state which kernel the patch file was generated against, and the email MUST have a subject line, preferably with the word PATCH in upper case together with a short (less than 40 character) description of what issue the patch deals with. Note that the current kernels can normally be determined by pointing your web browser to http://www.kernel.org and scrolling down to the bottom of the page. 4. Watch out for comments on your patch, and DEAL WITH THEM. Some people just ignore any comments, apparently on the assumption that they know what the kernel needs better than those who have been working on it far longer than they have, and after a while, the developers just stop reading their emails. You will also receive comments from people who have either just plain misunderstood your post, or who operate on the basis that their code is sacrosanct and your patch against it isn't worth considering as a result. Again, you will have to find a way of dealing with them. One basic rule here though: NEVER FLAME ANYBODY - NOT EVEN IN RESPONSE TO A FLAME. You'll only get yourself a bad name and reputation by doing so. The following are common reasons for patches posted to the Linux Kernel Developers mailing list being rejected: a. The patch is too complex. A patch that deals with too many issues will be rejected simply because of its size, as those who are responsible for the relevant part(s) of the kernel just don't have time to go through them. If you have dealt with several issues and the patches for each issue do not overlap, send the relevant patch for each issue in a separate email dealing just with that issue. If you have dealt with several issues and the patches overlap, you basically have two choices: 1. If the patch dealing just with the issues that overlap is not too large (say less than 50 lines in length), send a combined patch dealing just with the issues that overlap, and enumerate precicely which issues are dealt with, emphasising that they overlap. 2. If the patch is too large, decide which of the issues is "most important" and send a patch dealing just with that issue. Wait to see what happens to that patch, then send a patch against the result dealing with the next most important issue. Note that in this context, where there are three or more patches overlapping, the "most important" patch is often the one that has the result of de-overlapping most of the other patches. Note that "patches overlap" in the above means
Re: kernel governance
Hi Tony. sorry for the cold call - i've been trying to find a statement about 'kernel governance' and how new code is accepted into the kernel... To help anybody else wondering about these issues, I've cc'd my reply to the Linux-Kernel mailing list for comments. However, please note that the comments herein are expressions of my own opinions, and may not reflect those of other developers. Additional comments from other developers should be cc'd to Tony as I don't think he's on this list. However, I am on the list, so there is no need to CC to me... any hints? Well, I'm not even sure what you mean by "kernel governance" but the way to get your code into the kernel is well documented. Here's a basic summary of the procedure: 1. Subscribe to the Linux-Kernel mailing list. This is where ALL issues relating to the ENTIRE Linux kernel are thrown open for discussion. I will warn you in advance that this is a VERY active list and it is not unusual to get 300+ emails a day in that one list. My personal record from the Linux-Kernel list alone is 793 emails in one day. Make sure you can handle emails in that sort of volume first. 2. Monitor the list for AT LEAST 15 DAYS to see what issues are being discussed at the moment. In particular, watch out for ANY emails from "Linus Torvalds" or "Alan Cox" which mention such things as "Feature Freeze". 3. When you are satisfied with your understanding of the dynamics of the Linux-Kernel mailing list, post an email (sent using "Plain Text" mode - HTML emails are IGNORED by MANY of the kernel developers simply because of the volume of mail on the list. This email should contain a description of the purpose of your code, and should have attached to it (in MIME format) a PATCH against the relevant CURRENT kernel source tree that is in UNIFIED DIFF FORMAT. This format is generated by applying the -u4 parameter to the diff command. Note that the patch should NOT be embedded in the text of the email as doing so will almost certainly make the patch useless - it will either get munged by your email sending software or by the recipients mail reading software. Either the subject line or the descriptive text MUST state which kernel the patch file was generated against, and the email MUST have a subject line, preferably with the word PATCH in upper case together with a short (less than 40 character) description of what issue the patch deals with. Note that the current kernels can normally be determined by pointing your web browser to http://www.kernel.org and scrolling down to the bottom of the page. 4. Watch out for comments on your patch, and DEAL WITH THEM. Some people just ignore any comments, apparently on the assumption that they know what the kernel needs better than those who have been working on it far longer than they have, and after a while, the developers just stop reading their emails. You will also receive comments from people who have either just plain misunderstood your post, or who operate on the basis that their code is sacrosanct and your patch against it isn't worth considering as a result. Again, you will have to find a way of dealing with them. One basic rule here though: NEVER FLAME ANYBODY - NOT EVEN IN RESPONSE TO A FLAME. You'll only get yourself a bad name and reputation by doing so. The following are common reasons for patches posted to the Linux Kernel Developers mailing list being rejected: a. The patch is too complex. A patch that deals with too many issues will be rejected simply because of its size, as those who are responsible for the relevant part(s) of the kernel just don't have time to go through them. If you have dealt with several issues and the patches for each issue do not overlap, send the relevant patch for each issue in a separate email dealing just with that issue. If you have dealt with several issues and the patches overlap, you basically have two choices: 1. If the patch dealing just with the issues that overlap is not too large (say less than 50 lines in length), send a combined patch dealing just with the issues that overlap, and enumerate precicely which issues are dealt with, emphasising that they overlap. 2. If the patch is too large, decide which of the issues is "most important" and send a patch dealing just with that issue. Wait to see what happens to that patch, then send a patch against the result dealing with the next most important issue. Note that in this context, where there are three or more patches overlapping, the "most important" patch is often the one that has the result of de-overlapping most of the other patches. Note that "patches overlap" in the above means that
Re: Attempting to mount Zip causes floppy access (2.2.16)
Hi Nick. > I have a zip disk which I attempted to mount using the following > fstab entry: > /dev/sda4 /zip vfat noauto,nodev,nosuid,user ===8<=== CUT ===>8=== > The Zip is a bit suspect, as when I attempted to transfer stuff > from a Windows machine, it reported the size as a few Mb, and > had to be formatted. I don't know if the media is going bad, but > I have just dd'd the contents off without problems. > If I try and look at the partition table, "cfdisk" refuses, and > "fdisk" complains bitterly. If I try and "dd if=/dev/sda4" then > this just hangs, again in "wait_on_buffer". Is this connected with the L-K thread a while back about some jumper on newer ZipDrives needing to be changed for them to work properly? My ZipDrive is old enough not to be affected by that problem, so I didn't take too much notice of the thread, but I vaguely remember it. I can't help re your floppy query though...sorry... Best wishes from Riley. - 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: Attempting to mount Zip causes floppy access (2.2.16)
Hi Nick. I have a zip disk which I attempted to mount using the following fstab entry: /dev/sda4 /zip vfat noauto,nodev,nosuid,user ===8=== CUT ===8=== The Zip is a bit suspect, as when I attempted to transfer stuff from a Windows machine, it reported the size as a few Mb, and had to be formatted. I don't know if the media is going bad, but I have just dd'd the contents off without problems. If I try and look at the partition table, "cfdisk" refuses, and "fdisk" complains bitterly. If I try and "dd if=/dev/sda4" then this just hangs, again in "wait_on_buffer". Is this connected with the L-K thread a while back about some jumper on newer ZipDrives needing to be changed for them to work properly? My ZipDrive is old enough not to be affected by that problem, so I didn't take too much notice of the thread, but I vaguely remember it. I can't help re your floppy query though...sorry... Best wishes from Riley. - 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/
