Re: [PATCH, RFC] adjust legacy IDE resource setting
On Wed, Feb 14, 2007 at 03:05:24PM +, Jan Beulich wrote: > The change to force legacy mode IDE channels' resources to fixed > non-zero values confuses (at least some versions of) X, because the > values reported by the kernel and those readable from PCI config space > aren't consistent anymore. Therefore, this patch arranges for the > respective BARs to also get updated if possible. > > Signed-off-by: Jan Beulich <[EMAIL PROTECTED]> > > --- linux-2.6.20/drivers/pci/probe.c 2007-02-04 19:44:54.0 +0100 > +++ 2.6.20-pci-ide-legacy/drivers/pci/probe.c 2007-02-14 15:54:58.0 > +0100 ... On Wed, Feb 14, 2007 at 04:09:36PM +, Alan wrote: > > Of course I also opened a bug against X, as I too think it's doing something > > wrong here. > > If you can add a comment about why it is done (X problem) then it looks > fine to me. This would be nice in 2.6.20-stable, too. - 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, RFC] adjust legacy IDE resource setting
On Wed, Feb 14, 2007 at 03:05:24PM +, Jan Beulich wrote: The change to force legacy mode IDE channels' resources to fixed non-zero values confuses (at least some versions of) X, because the values reported by the kernel and those readable from PCI config space aren't consistent anymore. Therefore, this patch arranges for the respective BARs to also get updated if possible. Signed-off-by: Jan Beulich [EMAIL PROTECTED] --- linux-2.6.20/drivers/pci/probe.c 2007-02-04 19:44:54.0 +0100 +++ 2.6.20-pci-ide-legacy/drivers/pci/probe.c 2007-02-14 15:54:58.0 +0100 ... On Wed, Feb 14, 2007 at 04:09:36PM +, Alan wrote: Of course I also opened a bug against X, as I too think it's doing something wrong here. If you can add a comment about why it is done (X problem) then it looks fine to me. This would be nice in 2.6.20-stable, too. - 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: Documenting MS_RELATIME
On Mon, Feb 12, 2007 at 06:49:39PM +0100, Jan Engelhardt wrote: > >The one problem with noatime is that mutt's 'new mail arrived' breaks > > Just why does not it use mtime then to check for New Mail Arrived, like I have always used: --enable-buffy-sizeUse file size attribute instead of access time Support was there at least in 1998, maybe before. - 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: Documenting MS_RELATIME
On Mon, Feb 12, 2007 at 06:49:39PM +0100, Jan Engelhardt wrote: The one problem with noatime is that mutt's 'new mail arrived' breaks Just why does not it use mtime then to check for New Mail Arrived, like I have always used: --enable-buffy-sizeUse file size attribute instead of access time Support was there at least in 1998, maybe before. - 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.6.19 file content corruption on ext3
On Thu, Dec 28, 2006 at 11:00:46AM -0800, Linus Torvalds wrote: > And I have a test-program that shows the corruption _much_ easier (at > least according to my own testing, and that of several reporters that back > me up), and that seems to show the corruption going way way back (ie going > back to Linux-2.6.5 at least, according to one tester). That was a Fedora kernel. Has anyone seen the corruption in vanilla 2.6.18 (or older)? - 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] mm: fix page_mkclean_one
On Wed, Dec 27, 2006 at 07:04:34PM -0800, Linus Torvalds wrote: > [ Modified test-program that tells you where the corruption happens (and > when the missing parts were supposed to be written out) appended, in > case people care. ] Hi 2.6.18 (and 2.6.18.6) is ok, 2.6.19-rc1 is broken. I tried some snapshots between them but they hung before shell (2.6.18-git11, 2.6.18-git16, 2.6.18-git20, 2.6.18-git21). 2.6.18-git22 booted and was broken. (UP, no preempt) -Petri - 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] mm: fix page_mkclean_one
On Wed, Dec 27, 2006 at 07:04:34PM -0800, Linus Torvalds wrote: [ Modified test-program that tells you where the corruption happens (and when the missing parts were supposed to be written out) appended, in case people care. ] Hi 2.6.18 (and 2.6.18.6) is ok, 2.6.19-rc1 is broken. I tried some snapshots between them but they hung before shell (2.6.18-git11, 2.6.18-git16, 2.6.18-git20, 2.6.18-git21). 2.6.18-git22 booted and was broken. (UP, no preempt) -Petri - 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.6.19 file content corruption on ext3
On Thu, Dec 28, 2006 at 11:00:46AM -0800, Linus Torvalds wrote: And I have a test-program that shows the corruption _much_ easier (at least according to my own testing, and that of several reporters that back me up), and that seems to show the corruption going way way back (ie going back to Linux-2.6.5 at least, according to one tester). That was a Fedora kernel. Has anyone seen the corruption in vanilla 2.6.18 (or older)? - 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: EXT2-fs error in 2.4.0
On Wed, Jan 10, 2001 at 12:04:28PM -0700, Andreas Dilger wrote: > Decoding the first few words to hex, then ASCII gives > sts.pte_spinlock > #define pgtable_cache_size (pgt_quicklists.pgtable_cache_sz) > #define pgd_ > > and I it continues. The defines are from include/asm-sparc/pgalloc.h > and it is possible the first few words are out-of-order frees of indirect > blocks or something. In any case, were you just untarring a 2.4 kernel > tree at the time of this problem? That would be a bad thing, since it > would point to a bug still in the 2.4.0 kernel. > > Alternately, were you just rm -r an old kernel tree? Is it possible you > have not fsck'd this filesystem since running one of 2.4.0-test10 through > 2.4.0-test12 (or maybe even test13)? In this case, it is possible that > the filesystem was corrupted with the older kernels, but you just didn't > notice it if it was in an unused kernel tree. It was a file system where I do not work much, so after looking the time stamps of the directories and studying bash_history I am now rather sure what I was doing then: 'rm -rf linux-2.2.19pre7'. But it was not exactly an old kernel tree because I had built it only today morning while running 2.4.0. (It was not an old tree just patched today but I untarred it fresh from a 2.2.18 tar ball and patched and compiled it after that). The box had been running 2.4.0 continuously since Sunday 7 Jan and I rebooted it today afternoon only after I had seen the fs error messages. Until Sunday I was using only 2.2 kernels. Before Sunday and 2.4.0 the file system was last fscked on Saturday the 6th because of a power loss! I did once try some 2.4.0-test kernel on this box but it was a long time ago (I don't remember which exact version number the kernel had). It seemed to start up ok then but after starting netscape and moving its windows it hung and I had to power reset the box and of course it fscked immediately. But it was a long time ago and after that I have only used 2.2 kernels. Hmm. It surely seems 2.4.0 is to blame here, I'm afraid. - 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/
EXT2-fs error in 2.4.0
Got these in 2.4.0. Sorry if it's a known problem: I haven't been following the list very closely. This is a 100 MHz pentium and the kernel was compiled with gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). After booting to 2.2.latest.latest fsck did its fscking without telling anything. Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 779318387, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600484464, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1852403827, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1801678700, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1680017961, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1852401253, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1735401573, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1818386804, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1633902437, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600481379, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1702521203, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 538976288, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1881677856, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1902081127, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1801677173, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1953720684, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1735405171, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1818386804, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1633902437, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600481379, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 170490483, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1717920803, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 543518313, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600415600, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1751343459, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1769168741, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 151610746, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1952935976, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1769304415, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1768713059, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 779318387, count = 1 Jan 10 16:28:22
EXT2-fs error in 2.4.0
Got these in 2.4.0. Sorry if it's a known problem: I haven't been following the list very closely. This is a 100 MHz pentium and the kernel was compiled with gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). After booting to 2.2.latest.latest fsck did its fscking without telling anything. Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 779318387, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600484464, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1852403827, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1801678700, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1680017961, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1852401253, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1735401573, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1818386804, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1633902437, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600481379, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1702521203, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 538976288, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1881677856, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1902081127, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1801677173, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1953720684, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1735405171, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1818386804, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1633902437, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600481379, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 170490483, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1717920803, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 543518313, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1600415600, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1751343459, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1769168741, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 151610746, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1952935976, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1769304415, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1768713059, count = 1 Jan 10 16:28:22 elektroni kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 779318387, count = 1 Jan 10 16:28:22
Re: EXT2-fs error in 2.4.0
On Wed, Jan 10, 2001 at 12:04:28PM -0700, Andreas Dilger wrote: Decoding the first few words to hex, then ASCII gives sts.pte_spinlock #define pgtable_cache_size (pgt_quicklists.pgtable_cache_sz) #define pgd_ and I it continues. The defines are from include/asm-sparc/pgalloc.h and it is possible the first few words are out-of-order frees of indirect blocks or something. In any case, were you just untarring a 2.4 kernel tree at the time of this problem? That would be a bad thing, since it would point to a bug still in the 2.4.0 kernel. Alternately, were you just rm -r an old kernel tree? Is it possible you have not fsck'd this filesystem since running one of 2.4.0-test10 through 2.4.0-test12 (or maybe even test13)? In this case, it is possible that the filesystem was corrupted with the older kernels, but you just didn't notice it if it was in an unused kernel tree. It was a file system where I do not work much, so after looking the time stamps of the directories and studying bash_history I am now rather sure what I was doing then: 'rm -rf linux-2.2.19pre7'. But it was not exactly an old kernel tree because I had built it only today morning while running 2.4.0. (It was not an old tree just patched today but I untarred it fresh from a 2.2.18 tar ball and patched and compiled it after that). The box had been running 2.4.0 continuously since Sunday 7 Jan and I rebooted it today afternoon only after I had seen the fs error messages. Until Sunday I was using only 2.2 kernels. Before Sunday and 2.4.0 the file system was last fscked on Saturday the 6th because of a power loss! I did once try some 2.4.0-test kernel on this box but it was a long time ago (I don't remember which exact version number the kernel had). It seemed to start up ok then but after starting netscape and moving its windows it hung and I had to power reset the box and of course it fscked immediately. But it was a long time ago and after that I have only used 2.2 kernels. Hmm. It surely seems 2.4.0 is to blame here, I'm afraid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0-ac2
On Fri, Jan 05, 2001 at 05:35:03PM +, Alan Cox wrote:
>
>
> o E820 handling fixup (Andrea Arcangeli)
I guess this was supposed to be partly backed out for 2.4 too:
--- linux-2.4.0/arch/i386/kernel/setup.c.orig Sun Dec 31 20:26:18 2000
+++ linux-2.4.0/arch/i386/kernel/setup.cFri Jan 5 23:43:34 2001
@@ -518,7 +518,7 @@
e820.nr_map = 0;
add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- add_memory_region(HIGH_MEMORY, (mem_size << 10) - HIGH_MEMORY,
E820_RAM);
+ add_memory_region(HIGH_MEMORY, (mem_size << 10), E820_RAM);
}
printk("BIOS-provided physical RAM map:\n");
print_memory_map(who);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.0-ac2
On Fri, Jan 05, 2001 at 05:35:03PM +, Alan Cox wrote:
o E820 handling fixup (Andrea Arcangeli)
I guess this was supposed to be partly backed out for 2.4 too:
--- linux-2.4.0/arch/i386/kernel/setup.c.orig Sun Dec 31 20:26:18 2000
+++ linux-2.4.0/arch/i386/kernel/setup.cFri Jan 5 23:43:34 2001
@@ -518,7 +518,7 @@
e820.nr_map = 0;
add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- add_memory_region(HIGH_MEMORY, (mem_size 10) - HIGH_MEMORY,
E820_RAM);
+ add_memory_region(HIGH_MEMORY, (mem_size 10), E820_RAM);
}
printk("BIOS-provided physical RAM map:\n");
print_memory_map(who);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre3
On Fri, Dec 22, 2000 at 12:52:32AM +, Alan Cox wrote:
>
> 2.2.19pre3
> o Fix e820 handling (Andrea Arcangeli)
arch/i386/kernel/setup.c:
/* compare results from other methods and take the greater */
if (ALT_MEM_K < EXT_MEM_K) {
mem_size = EXT_MEM_K;
who = "BIOS-88";
} else {
mem_size = ALT_MEM_K;
who = "BIOS-e801";
}
e820.nr_map = 0;
- add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- add_memory_region(HIGH_MEMORY, mem_size << 10, E820_RAM);
+ add_memory_region(0, i386_endbase, E820_RAM);
+ add_memory_region(HIGH_MEMORY, (mem_size << 10)-HIGH_MEMORY,
+E820_RAM);
I think in case of BIOS-88 it now sees 1 Meg less than should. int 15, ah=88
gives the amount of extended memory above 1 Meg and it gets copied to
EXT_MEM_K. So HIGH_MEMORY should not be subtracted from it. (On the other
hand in case of BIOS-e801 ALT_MEM_K includes lower memory. I guess the
direct comparison of memory sizes ALT_MEM_K and EXT_MEM_K is not ok.)
linux-2.2.19pre3 on my 486 with 49152 k of RAM:
BIOS-provided physical RAM map:
BIOS-88: 000a @ (usable)
BIOS-88: 02e0 @ 0010 (usable)
Memory: 46128k/48128k available
linux-2.2.18 or linux-2.2.19pre2 :
Memory: 47144k/49152k available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre3
On Fri, Dec 22, 2000 at 12:52:32AM +, Alan Cox wrote: > > o Optimise kernel compiler detect, kgcc before(Peter Samuelson) > gcc272 also kwhich doesn't seem to work ok with several arguments if sh is bash-1.14.7: $ sh scripts/kwhich kgcc gcc272 cc gcc kgcc:gcc272:cc:gcc: not found If sh is bash-2.04 or ash-0.3.7 it works ok: $ sh scripts/kwhich kgcc gcc272 cc gcc /usr/bin/kgcc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre3
On Fri, Dec 22, 2000 at 12:52:32AM +, Alan Cox wrote: o Optimise kernel compiler detect, kgcc before(Peter Samuelson) gcc272 also kwhich doesn't seem to work ok with several arguments if sh is bash-1.14.7: $ sh scripts/kwhich kgcc gcc272 cc gcc kgcc:gcc272:cc:gcc: not found If sh is bash-2.04 or ash-0.3.7 it works ok: $ sh scripts/kwhich kgcc gcc272 cc gcc /usr/bin/kgcc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre3
On Fri, Dec 22, 2000 at 12:52:32AM +, Alan Cox wrote:
2.2.19pre3
o Fix e820 handling (Andrea Arcangeli)
arch/i386/kernel/setup.c:
/* compare results from other methods and take the greater */
if (ALT_MEM_K EXT_MEM_K) {
mem_size = EXT_MEM_K;
who = "BIOS-88";
} else {
mem_size = ALT_MEM_K;
who = "BIOS-e801";
}
e820.nr_map = 0;
- add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- add_memory_region(HIGH_MEMORY, mem_size 10, E820_RAM);
+ add_memory_region(0, i386_endbase, E820_RAM);
+ add_memory_region(HIGH_MEMORY, (mem_size 10)-HIGH_MEMORY,
+E820_RAM);
I think in case of BIOS-88 it now sees 1 Meg less than should. int 15, ah=88
gives the amount of extended memory above 1 Meg and it gets copied to
EXT_MEM_K. So HIGH_MEMORY should not be subtracted from it. (On the other
hand in case of BIOS-e801 ALT_MEM_K includes lower memory. I guess the
direct comparison of memory sizes ALT_MEM_K and EXT_MEM_K is not ok.)
linux-2.2.19pre3 on my 486 with 49152 k of RAM:
BIOS-provided physical RAM map:
BIOS-88: 000a @ (usable)
BIOS-88: 02e0 @ 0010 (usable)
Memory: 46128k/48128k available
linux-2.2.18 or linux-2.2.19pre2 :
Memory: 47144k/49152k available
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre2
On Sun, Dec 17, 2000 at 04:38:02PM +0100, Kurt Garloff wrote: > On Sun, Dec 17, 2000 at 12:56:56PM +0200, Petri Kaukasoina wrote: > > I guess the new memory detect does not work correctly with my old work > > horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with > > a version number of 51-000-0001169_0011-101094-SIS550X-H. > > > > 2.2.18 reports: > > Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k >init) > > > > 2.2.19pre2 reports: > > Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k >init) > > > > 57344k is 56 Megs which is correct. > > 54784k is only 53.5 Megs. > > It's this patch that changes things for you: > o E820 memory detect backport from 2.4(Michael Chen) > > The E820 memory detection parses a list from the BIOS, which specifies > the amount of memory, holes, reserved regions, ... > Apparently, your BIOS does not do it completely correctly; otherwise you > should have had crashes before ... OK, I booted 2.4.0-test12 which even prints that list: BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0348 @ 0010 (usable) BIOS-e820: 0010 @ fec0 (reserved) BIOS-e820: 0010 @ fee0 (reserved) BIOS-e820: 0001 @ (reserved) Memory: 52232k/54784k available (831k kernel code, 2164k reserved, 62k data, 168k init, 0k highmem) The last three reserved lines correspond to the missing 2.5 Megs. What are they? 2.2.18 sees all 56 Megs and works ok and after adding mem=56M on the kernel command line even 2.2.19pre2 works ok with all the 56 Megs. No crashes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre2
On Sun, Dec 17, 2000 at 04:38:02PM +0100, Kurt Garloff wrote: On Sun, Dec 17, 2000 at 12:56:56PM +0200, Petri Kaukasoina wrote: I guess the new memory detect does not work correctly with my old work horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with a version number of 51-000-0001169_0011-101094-SIS550X-H. 2.2.18 reports: Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k init) 2.2.19pre2 reports: Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k init) 57344k is 56 Megs which is correct. 54784k is only 53.5 Megs. It's this patch that changes things for you: o E820 memory detect backport from 2.4(Michael Chen) The E820 memory detection parses a list from the BIOS, which specifies the amount of memory, holes, reserved regions, ... Apparently, your BIOS does not do it completely correctly; otherwise you should have had crashes before ... OK, I booted 2.4.0-test12 which even prints that list: BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0348 @ 0010 (usable) BIOS-e820: 0010 @ fec0 (reserved) BIOS-e820: 0010 @ fee0 (reserved) BIOS-e820: 0001 @ (reserved) Memory: 52232k/54784k available (831k kernel code, 2164k reserved, 62k data, 168k init, 0k highmem) The last three reserved lines correspond to the missing 2.5 Megs. What are they? 2.2.18 sees all 56 Megs and works ok and after adding mem=56M on the kernel command line even 2.2.19pre2 works ok with all the 56 Megs. No crashes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre2
I guess the new memory detect does not work correctly with my old work horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with a version number of 51-000-0001169_0011-101094-SIS550X-H. 2.2.18 reports: Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k init) 2.2.19pre2 reports: Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k init) 57344k is 56 Megs which is correct. 54784k is only 53.5 Megs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre2
I guess the new memory detect does not work correctly with my old work horse. It is a 100 MHz pentium with 56 Megs RAM. AMIBIOS dated 10/10/94 with a version number of 51-000-0001169_0011-101094-SIS550X-H. 2.2.18 reports: Memory: 55536k/57344k available (624k kernel code, 412k reserved, 732k data, 40k init) 2.2.19pre2 reports: Memory: 53000k/54784k available (628k kernel code, 408k reserved, 708k data, 40k init) 57344k is 56 Megs which is correct. 54784k is only 53.5 Megs. - 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: Kernel 2.2.18 and GCC versions
On Fri, Oct 13, 2000 at 12:26:02AM +0100, Alan Cox wrote: > egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use > to build it. Its also the recommended compiler. What do you mean by _the_ recommended compiler? Is 2.7.2.3 recommended no more? Is there some benefit using egcs-1.1.2 instead of 2.7.2.3? Should Changes be changed? 2.2.18pre15: Version 1.1.2 seems okay; if you have to have a binary, you may be successful using that. In general, however, gcc-2.7.2.3 is known to be stable, while egcs and others have not been as thoroughly tested yet. - 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: Kernel 2.2.18 and GCC versions
On Fri, Oct 13, 2000 at 12:26:02AM +0100, Alan Cox wrote: egcs-1.1.2 builds 2.2.18pre. I know this because thats the compiler I use to build it. Its also the recommended compiler. What do you mean by _the_ recommended compiler? Is 2.7.2.3 recommended no more? Is there some benefit using egcs-1.1.2 instead of 2.7.2.3? Should Changes be changed? 2.2.18pre15: Version 1.1.2 seems okay; if you have to have a binary, you may be successful using that. In general, however, gcc-2.7.2.3 is known to be stable, while egcs and others have not been as thoroughly tested yet. - 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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
On Sun, Oct 01, 2000 at 01:01:34AM +0100, Alan Cox wrote:
> I've dropped Miquel's version into my tree. He simply side steps the entire
> 'which which' issue and uses scripts/kwhich
Peter Samuelson's version worked in my Slackware systems. Miquel's kwhich is
ok too.
Another problem in Makefile. I guess this change between pre 12 and 13 is a
typo:
CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
- else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else if [ -x /bin/bash ]; then echo /bin/bash2; \
else echo sh; fi ; fi)
I have ash as /bin/sh and there's also /bin/bash but no /bin/bash2.
$ make oldconfig
Syntax error: "(" unexpected (expecting "then")
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/bash2 scripts/Configure -d arch/i386/config.in
make: /bin/bash2: Command not found
make: *** [oldconfig] Error 127
-
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: We interrupt you regularly scheduled catfight for.. Linux 2.2.18pre13
On Sun, Oct 01, 2000 at 01:01:34AM +0100, Alan Cox wrote:
I've dropped Miquel's version into my tree. He simply side steps the entire
'which which' issue and uses scripts/kwhich
Peter Samuelson's version worked in my Slackware systems. Miquel's kwhich is
ok too.
Another problem in Makefile. I guess this change between pre 12 and 13 is a
typo:
CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
- else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else if [ -x /bin/bash ]; then echo /bin/bash2; \
else echo sh; fi ; fi)
I have ash as /bin/sh and there's also /bin/bash but no /bin/bash2.
$ make oldconfig
Syntax error: "(" unexpected (expecting "then")
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/bash2 scripts/Configure -d arch/i386/config.in
make: /bin/bash2: Command not found
make: *** [oldconfig] Error 127
-
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.18pre12 fix for some distros
On Sat, Sep 30, 2000 at 01:16:21AM +0100, Alan Cox wrote: > -CC =$(CROSS_COMPILE)$(shell if [ -n "`which gcc272 2>/dev/null`" ]; then echo >"`which gcc272`";\ > - else if [ -n "`which kgcc 2>/dev/null`" ]; then echo "`which kgcc`"; else\ > +CC =$(CROSS_COMPILE)$(shell if [ -n "`which gcc272 >/dev/null 2>/dev/null`" ]; >then echo "`which gcc272`";\ > + else if [ -n "`which kgcc >/dev/null 2>/dev/null`" ]; then echo "`which >kgcc`"; else\ Doesn't work here in a couple of Slackware systems (I don't remember version numbers). 'which' seems to print the error message to stdout, not stderr so the compiler of choice will be 'which: no gcc272 in (/bin:/usr/bin:/usr/X11/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin)' How about something like CC =$(CROSS_COMPILE)$(shell if [ -x /usr/bin/gcc272 -o -x /usr/local/bin/gcc272 ]; then echo "gcc272"; \ else if [ -x /usr/bin/kgcc -o -x /usr/local/bin/kgcc ]; then echo "kgcc"; \ else echo "cc"; fi ; fi) -D__KERNEL__ -I$(HPATH) Or wherever kgcc and gcc272 are installed in those systems where they have them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre12 fix for some distros
On Sat, Sep 30, 2000 at 01:16:21AM +0100, Alan Cox wrote: -CC =$(CROSS_COMPILE)$(shell if [ -n "`which gcc272 2/dev/null`" ]; then echo "`which gcc272`";\ - else if [ -n "`which kgcc 2/dev/null`" ]; then echo "`which kgcc`"; else\ +CC =$(CROSS_COMPILE)$(shell if [ -n "`which gcc272 /dev/null 2/dev/null`" ]; then echo "`which gcc272`";\ + else if [ -n "`which kgcc /dev/null 2/dev/null`" ]; then echo "`which kgcc`"; else\ Doesn't work here in a couple of Slackware systems (I don't remember version numbers). 'which' seems to print the error message to stdout, not stderr so the compiler of choice will be 'which: no gcc272 in (/bin:/usr/bin:/usr/X11/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin)' How about something like CC =$(CROSS_COMPILE)$(shell if [ -x /usr/bin/gcc272 -o -x /usr/local/bin/gcc272 ]; then echo "gcc272"; \ else if [ -x /usr/bin/kgcc -o -x /usr/local/bin/kgcc ]; then echo "kgcc"; \ else echo "cc"; fi ; fi) -D__KERNEL__ -I$(HPATH) Or wherever kgcc and gcc272 are installed in those systems where they have them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
