1. test13-pre3, e2fs corruption
2. running my box 4h 30min i wanted edit some files, the filenames
were wrong and other files didnt have the correct data.
i unmounted the drive with the data and a e2fsck said
wrong group names...bad superblock...
after reboot without check
1. test13-pre3, e2fs corruption
2. running my box 4h 30min i wanted edit some files, the filenames
were wrong and other files didnt have the correct data.
i unmounted the drive with the data and a e2fsck said
wrong group names...bad superblock...
after reboot without check
On Wed, 20 Dec 2000, Petr Vandrovec wrote:
> /usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
Well, the test looks reasonable if the system load is low. Still the
performance is surprisingly low -- after changing the transfer width to 16
bits I ran the test on my
On Wed, 20 Dec 2000, Petr Vandrovec wrote:
/usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
Well, the test looks reasonable if the system load is low. Still the
performance is surprisingly low -- after changing the transfer width to 16
bits I ran the test on my
Hello,
When I use 'make menuconfig' on 2.4.0-test13-pre3 to select DRM and the
Matrox DRM driver as a module, I get a .config with CONFIG_DRM=y and
CONFIG_DRM_MGA=m. However, this causes drivers/char/Makefile to skip the
drm subdirectory when compiling modules: its only reference to CONFIG_DRM
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
> > it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
> > take 3.48ms, and this does not correspond with needed 200us udelay.
>
> Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
> read or write
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR',
> yes (as verified in generated code...)? No change, still dies, as expected
> (do not forget that before it dies, it can do ~0x1300 write-read cycles
I've forgotten indeed...
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR',
yes (as verified in generated code...)? No change, still dies, as expected
(do not forget that before it dies, it can do ~0x1300 write-read cycles
I've forgotten indeed...
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
take 3.48ms, and this does not correspond with needed 200us udelay.
Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
read or write cycle
Hello,
When I use 'make menuconfig' on 2.4.0-test13-pre3 to select DRM and the
Matrox DRM driver as a module, I get a .config with CONFIG_DRM=y and
CONFIG_DRM_MGA=m. However, this causes drivers/char/Makefile to skip the
drm subdirectory when compiling modules: its only reference to CONFIG_DRM
The saga continues into test13-pre3-ac3:
(last good tdfx.o was from test12)
# uname -a
Linux jyro.mirai.cx 2.4.0-test13pre3-ac3 #1 Tue Dec 19 21:26:36 PST 2000 i586
unknown
# lsmod
Module Size Used by
iptable_filter 1872 0 (autoclean) (unused)
ip_nat_ftp
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote:
[snip of Petr's system info]
> Okay. Mine, as far as I can tell, only depends on the L2 cache being set
> to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under
> 'Chipset Features Setup' on my BIOS. This is unfortunately the
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or
specific model #) but not vanilla alpha.
--- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000
+++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000
@@ -4,6 +4,7 @@
#
define_bool CONFIG_UID16 n
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
> >
> > Pardon me for not fully groking the issues here and possibly coming to a
> > wrong conclusion, but this has to do with SMP systems crashing at APIC
> > init time, just before penguin display
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote:
> > When I replaced address with 0xC01B8000 (some cachable memory), it worked
> > fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
> > it is just set as cacheable in chipset), it works too.
>
> Hmm, a read from an uncached
I'm glad to report that 2.4.0-test13-pre3 fixes the lockup (and
odd Oops messages) problems I had from test12 til test13-pre2. I've been
running it on both of my computers for a day and a half and everything is
OK.
At first, we thought it had something to do with the modules I was
using, but I
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> Uh. It took couple of hours to find it. Just place
>
> { int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i < 6553600;
>i++) { *p; } }(**)
>
> instead of udelay(300) and this loop does not
> > In the case where it boots does it also report mismatched MTRRs ??
>
> Yes, it complains. But BIOS correctly reports x1/x2 depending on
> number of CPUs I plug into motherboard, so I believe that it did
> some initialization before it start loading OS.
That may explain the hangs. Intel docs
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
>
> Pardon me for not fully groking the issues here and possibly coming to a
> wrong conclusion, but this has to do with SMP systems crashing at APIC
> init time, just before penguin display (with fbcon at least)? If so, I
> have a board that does
On 18 Dec 00 at 23:51, Alan Cox wrote:
> > Yeah. Just do not read video memory when another CPU starts. I'll try
> > disabling cache on both CPUs, maybe it will make some difference, as
> > secondary CPU should start with caches disabled. But maybe that it is
> > just broken AGP bus, and
TED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: [patch-2.4.0-test13-pre3] rootfs (3rd attempt)
Hi Linus,
The "final" version of yesterday contained two bugs (thanks to Andreas
Dilger for spotting both of them). This version contains 0 bugs and was
very thorou
Torvalds [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [patch-2.4.0-test13-pre3] rootfs (3rd attempt)
Hi Linus,
The "final" version of yesterday contained two bugs (thanks to Andreas
Dilger for spotting both of them). This version contains 0 bugs and was
very thoroughly tested
On 18 Dec 00 at 23:51, Alan Cox wrote:
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else.
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this
In the case where it boots does it also report mismatched MTRRs ??
Yes, it complains. But BIOS correctly reports x1/x2 depending on
number of CPUs I plug into motherboard, so I believe that it did
some initialization before it start loading OS.
That may explain the hangs. Intel docs don't
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish.
I'm glad to report that 2.4.0-test13-pre3 fixes the lockup (and
odd Oops messages) problems I had from test12 til test13-pre2. I've been
running it on both of my computers for a day and a half and everything is
OK.
At first, we thought it had something to do with the modules I was
using, but I
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote:
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Hmm, a read from an uncached
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote:
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or
specific model #) but not vanilla alpha.
--- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000
+++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000
@@ -4,6 +4,7 @@
#
define_bool CONFIG_UID16 n
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote:
[snip of Petr's system info]
Okay. Mine, as far as I can tell, only depends on the L2 cache being set
to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under
'Chipset Features Setup' on my BIOS. This is unfortunately the latest
The saga continues into test13-pre3-ac3:
(last good tdfx.o was from test12)
# uname -a
Linux jyro.mirai.cx 2.4.0-test13pre3-ac3 #1 Tue Dec 19 21:26:36 PST 2000 i586
unknown
# lsmod
Module Size Used by
iptable_filter 1872 0 (autoclean) (unused)
ip_nat_ftp
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this with certain cache settings made in the BIOS.
It's a
> List: linux-kernel
> Subject: Re: test13-pre3 woes
> From: Peter Samuelson <[EMAIL PROTECTED]>
> Date: 2000-12-18 9:19:13
> [Download message RAW]
>
>
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunate
sion 2.3.21
...
> The most important question: Did you run "make dep" after doing the patch?
Yes, after the patch, it was, as always:
make clean
make menuconfig
make dep bzlilo modules modules_install
Same problem with 2.4.0-test13-pre3-ac1 on
my Linux workstation at the office, wh
> Yeah. Just do not read video memory when another CPU starts. I'll try
> disabling cache on both CPUs, maybe it will make some difference, as
> secondary CPU should start with caches disabled. But maybe that it is
> just broken AGP bus, and nothing else. But until I find what's really
> broken
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
> > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
> > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
>
> Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
> if accessing one bus or
This patch updates the Makefiles used by Linux/m68k to the new Makefile syntax.
Additionally I fixed a bug in arch/ppc/amiga/Makefile (for APUS).
--- linux-2.4.0-test13-pre3/MakefileMon Dec 18 12:34:22 2000
+++ linux-m68k-test13-pre3/Makefile Mon Dec 18 12:40:50 2000
@@ -159,7 +159,7
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
> The appended patch fixes the following:
>
> 1) We cannot unlock the page in shmem_writepage on ooswap since
>page_launder will do this later.
>
> 2) We should set the inode number of SYSV segments to the (user)
>shmid and not the
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
> It is possible. But it is hard to track, as it works with serial console,
> and it is not possible to paint characters to VGA screen, as vgacon uses
> hardware panning instead of scrolling :-( And if it dies, shift-pageup
> apparently does not work...
On Mon, 18 Dec 2000, Andreas Dilger wrote:
> If I could add one thing here (we have had a 2.2 patch like this for testing
> with ext3) - if you specify the rootfstype parameter don't use the "quiet"
> option to read_super, so you know why it couldn't mount a specific filesystem
> as root, and/or
Tigran, you write:
> Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
> to do the same it did before + panic when rootfs= is given but failed to
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote:
> On Mon, 18 Dec 2000, Petr Vandrovec wrote:
>
> > No. Without udelay() before first printk() it just does not boot on my
> > motherboard. There were two choices: either remove all printk() from
> > these loops (define Dprintk to null), or add
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
> No. Without udelay() before first printk() it just does not boot on my
> motherboard. There were two choices: either remove all printk() from
> these loops (define Dprintk to null), or add udelay(x), where x >= 200,
> before first printk. I sent patch
On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
> What is this change about?
>
> diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
>linux/arch/i386/kernel/smpboot.c
> --- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
> +++
just a typo in the comment, sorry. Corrected version below.
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec
). Now,
everyone is (hopefully) happy.
Tested under 2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel
Ok, the version below doesn't look too bad, except a couple things, see
below:
On Mon, 18 Dec 2000, Peter Samuelson wrote:
> -__setup("rootfs=", rootfs_setup);
> +__setup("rootfstype=", rootfs_setup);
this is wrong. If the parameter is "rootfstype" then the function is
rootfstype_setup(). Too
(the original got lost
because of the mail-abuse vs btconnect's randomness)
>From [EMAIL PROTECTED] Mon Dec 18 15:20:08 2000
Date: Mon, 18 Dec 2000 14:44:32 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2
[Andries Brouwer]
> (i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
> It gives some property of the root filesystem, but which?
> (ii) It is a bad idea to arbitrarily select "ext2".
> (iii) [...] Thus, if the boot option rootfstype is given, I prefer a
> boot failure over a kernel
[Tigran Aivazian]
> no, because it would cause a "spurious" call to get_fs_type("") which
> we don't want to happen (by default i.e. -- if user _really_ wants it
> that is ok). The default of "ext2" is fine.
I still disagree -- super.c is no place to dictate the default root
filesystem. And I
Peter, Alan,
thanks, this solved the problem - 2.4.0-test13pre3 is up 'n running ;)
BTW: Is it possible to shut off these "apic error on CPU0" messages."
Now I know that my board is not well designed, so what should these
messages help me? They blow up my /var/log/messages only...
kind regards
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
> The shmfs cleanup should be unnoticeable except to users who use SAP
> with huge shared memory segments, where Christoph Rohlands work not
> only makes the code much more readable, it should also make it
> dependable..
:-)
The appended
In article <[EMAIL PROTECTED]> you write:
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
>...
> Those symbols are rather generic and rather
From: Tigran Aivazian <[EMAIL PROTECTED]>
+rootfs=[KNL] Use filesystem type specified (e.g. rootfs=ext2) for
root.
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
+static char rootfs[128]
On Mon, 18 Dec 2000, Peter Samuelson wrote:
>
> [Tigran Aivazian]
> > +/* this can be set at boot time, e.g. rootfs=ext2
> > + * if set to invalid value or if read_super() fails on the specified
> > + * filesystem type then mount_root() will go through all registered filesystems.
> > + */
> >
/
udelay(200);
If we need 600usecs of delay for certain systems, then why not just make
it like below?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED],
[Tigran Aivazian]
> +/* this can be set at boot time, e.g. rootfs=ext2
> + * if set to invalid value or if read_super() fails on the specified
> + * filesystem type then mount_root() will go through all registered filesystems.
> + */
> +static char rootfs[128] __initdata = "ext2";
Better that
"Tigran Aivazian wrote:"
> In November last year I wrote support for a new boot parameter called
> "rootfs" implementing functionality similar to UnixWare7, i.e. being
> able to specify the filesystem type to try first in mount_root() and if
> this fails then go on to the usual loop over all
> you may be right there is no module "video.o". The problem is, there should
> be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/
> and this is missing in test13pre2 and test13pre3. The modules are not built.
Its a small makefile error again. The directories are not
lt, I have kernel panics because it successfully mounts the garbage as
a valid ext2 filesystem simply because the real filesystem on the block
device happens to use the location of the block containing superblock
different than ext2.
Therefore, please consider this tiny patch, tested against
2.4.0-t
depmod -ae -F System.map 2.4.0-test13-pre3
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/dsbr100.o
depmod: video_register_device
depmod: video_unregister_device
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test13-pre3/kernel/drivers
[J Sloan]
> The module now compiles and gets installed -
> Unfortunately, attempting to load it does not go well:
>
> kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
> kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up
> kernel/drivers/char/drm/tdfx.o: unresolved
Niels Kristian Bech Jensen wrote:
> Does this patch fix your problem?
>
> --- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000
> +++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000
> @@ -16,6 +16,8 @@
>
> O_TARGET := char.o
>
> +mod-subdirs := drm
Niels Kristian Bech Jensen wrote:
Does this patch fix your problem?
--- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000
+++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000
@@ -16,6 +16,8 @@
O_TARGET := char.o
+mod-subdirs := drm
+
obj-y += tty_io.o n_tty.o
[J Sloan]
The module now compiles and gets installed -
Unfortunately, attempting to load it does not go well:
kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up
kernel/drivers/char/drm/tdfx.o: unresolved symbol
depmod -ae -F System.map 2.4.0-test13-pre3
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/dsbr100.o
depmod: video_register_device
depmod: video_unregister_device
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-test13-pre3/kernel/drivers
lt, I have kernel panics because it successfully mounts the garbage as
a valid ext2 filesystem simply because the real filesystem on the block
device happens to use the location of the block containing superblock
different than ext2.
Therefore, please consider this tiny patch, tested against
2.4.0-t
you may be right there is no module "video.o". The problem is, there should
be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/
and this is missing in test13pre2 and test13pre3. The modules are not built.
Its a small makefile error again. The directories are not
"Tigran Aivazian wrote:"
In November last year I wrote support for a new boot parameter called
"rootfs" implementing functionality similar to UnixWare7, i.e. being
able to specify the filesystem type to try first in mount_root() and if
this fails then go on to the usual loop over all
[Tigran Aivazian]
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[128] __initdata = "ext2";
Better that we
If we need 600usecs of delay for certain systems, then why not just make
it like below?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available
On Mon, 18 Dec 2000, Peter Samuelson wrote:
[Tigran Aivazian]
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char
From: Tigran Aivazian [EMAIL PROTECTED]
+rootfs=[KNL] Use filesystem type specified (e.g. rootfs=ext2) for
root.
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
+static char rootfs[128] __initdata
In article [EMAIL PROTECTED] you write:
[J Sloan]
The module now compiles and gets installed -
Unfortunately, attempting to load it does not go well:
kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
...
Those symbols are rather generic and rather important. Sounds
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
The shmfs cleanup should be unnoticeable except to users who use SAP
with huge shared memory segments, where Christoph Rohlands work not
only makes the code much more readable, it should also make it
dependable..
:-)
The appended patch
Peter, Alan,
thanks, this solved the problem - 2.4.0-test13pre3 is up 'n running ;)
BTW: Is it possible to shut off these "apic error on CPU0" messages."
Now I know that my board is not well designed, so what should these
messages help me? They blow up my /var/log/messages only...
kind regards
[Tigran Aivazian]
no, because it would cause a "spurious" call to get_fs_type("") which
we don't want to happen (by default i.e. -- if user _really_ wants it
that is ok). The default of "ext2" is fine.
I still disagree -- super.c is no place to dictate the default root
filesystem. And I
btconnect's randomness)
From [EMAIL PROTECTED] Mon Dec 18 15:20:08 2000
Date: Mon, 18 Dec 2000 14:44:32 + (GMT)
From: Tigran Aivazian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 De
[Andries Brouwer]
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
(ii) It is a bad idea to arbitrarily select "ext2".
(iii) [...] Thus, if the boot option rootfstype is given, I prefer a
boot failure over a kernel attempt
Ok, the version below doesn't look too bad, except a couple things, see
below:
On Mon, 18 Dec 2000, Peter Samuelson wrote:
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
this is wrong. If the parameter is "rootfstype" then the function is
rootfstype_setup(). Too
). Now,
everyone is (hopefully) happy.
Tested under 2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel
just a typo in the comment, sorry. Corrected version below.
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec
On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
What is this change about?
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
linux/arch/i386/kernel/smpboot.c
--- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
+++
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x), where x = 200,
before first printk. I sent patch
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote:
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x),
Tigran, you write:
Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
to do the same it did before + panic when rootfs= is given but failed to
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter
On Mon, 18 Dec 2000, Andreas Dilger wrote:
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter don't use the "quiet"
option to read_super, so you know why it couldn't mount a specific filesystem
as root, and/or
On Mon, 18 Dec 2000, Petr Vandrovec wrote:
It is possible. But it is hard to track, as it works with serial console,
and it is not possible to paint characters to VGA screen, as vgacon uses
hardware panning instead of scrolling :-( And if it dies, shift-pageup
apparently does not work... And
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user)
shmid and not the internal
This patch updates the Makefiles used by Linux/m68k to the new Makefile syntax.
Additionally I fixed a bug in arch/ppc/amiga/Makefile (for APUS).
--- linux-2.4.0-test13-pre3/MakefileMon Dec 18 12:34:22 2000
+++ linux-m68k-test13-pre3/Makefile Mon Dec 18 12:40:50 2000
@@ -159,7 +159,7
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
if accessing one bus or another
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my
atch?
Yes, after the patch, it was, as always:
make clean
make menuconfig
make dep bzlilo modules modules_install
Same problem with 2.4.0-test13-pre3-ac1 on
my Linux workstation at the office, where the
token ring driver fails as well (olympic.o)
BTW, in my experience to date with kernels from
List: linux-kernel
Subject: Re: test13-pre3 woes
From: Peter Samuelson [EMAIL PROTECTED]
Date: 2000-12-18 9:19:13
[Download message RAW]
[J Sloan]
The module now compiles and gets installed -
Unfortunately, attempting to load it does not go well:
kernel/drivers/char
Pardon me for not fully groking the issues here and possibly coming to a
wrong conclusion, but this has to do with SMP systems crashing at APIC
init time, just before penguin display (with fbcon at least)? If so, I
have a board that does this with certain cache settings made in the BIOS.
It's a
[Norbert Breun]
> The problem is, there should be a directory "media" under
> /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in
> test13pre2 and test13pre3. The modules are not built.
Does this help? I think it's right.
Peter
diff -urk.orig
Peter,
you may be right there is no module "video.o". The problem is, there should
be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/
and this is missing in test13pre2 and test13pre3. The modules are not built.
kind regards
Norbert
On Monday 18 December 2000 07:11,
[Mikael Djurfeldt]
> When trying to build video.o as a module, video.o doesn't get copied
> to /lib/modules/* during installation.
There is no video.o module. If video.o is built at all, it is linked
into the vmlinux image directly. The modules in that directory will be
atyfb.o, tdfxfb.o and
On Mon, 18 Dec 2000, J Sloan wrote:
> Similar problem here - with CONFIG_DRM_TDFX=m
> I have not gotten a tdfx.o module complied since the
> start of the test13-pre series...
>
> So no quake 3 arena unless I want to play at < 1 fps...
>
Does this patch fix your problem?
--
1 - 100 of 128 matches
Mail list logo
