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 or
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 dua
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
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 cyc
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...
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 lates
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
+def
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 (w
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
us
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 f
> > 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 t
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
gt;
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
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 4
> 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
d version 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 o
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
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 inte
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 p
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 paramete
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 udela
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
> +++ linux/arch/i
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 lo
of re-sending) (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]
S
[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 att
[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 a
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
N
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 pat
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.
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] __initdat
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 w
"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 regi
> 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 lis
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 symb
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
[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 2.4.0test13pre3/drivers/media/Mak
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, Pe
[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 a
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?
--
[Albert Cranford]
> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/drm/r128.o
He's right. Linus, please apply.
Peter
--- test13pre3/drivers/char/Makefile.orig Wed Dec 13 23:56:01 2000
+++ test13pre3/drivers/char/MakefileSun Dec 17 23:55:00 2000
@@ -25,6 +25,7
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...
:(
jjs
Albert Cranford wrote:
> With CONFIG_DRM_R128=m
> we fail to produce module linux/drivers/char/dr
With CONFIG_DRM_R128=m
we fail to produce module linux/drivers/char/drm/r128.o
Any thoughts.
Albert
Linus Torvalds wrote:
>
> The most noticeable part of this is that the run_task_queue fix should
> cure the lockup that some people have seen.
>
> The shmfs cleanup should be unnoticeable except
known problem with netfilter. I think someone is working on it.
Robert Lynch wrote:
>
> I find that running these kernels (because of a netfilter modules
> compile error, didn't try test13-pre1 or 2) in X my entire system
> freezes, requiring a hard reboot. With test12 final, suddenly
> the scr
I find that running these kernels (because of a netfilter modules
compile error, didn't try test13-pre1 or 2) in X my entire system
freezes, requiring a hard reboot. With test12 final, suddenly
the screen streaked, then froze.
No oops, just the freeze.
Been a while (when I used to run Windoze)
When trying to build video.o as a module, video.o doesn't get copied
to /lib/modules/* during installation.
-
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/
When trying to compile linux-2.4.0-test13-pre3 with the following
.config:
kernel configuration
I got the following error message:
--
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o
hackers are funny people: They count the time in patchlevels.
On Mon, 18 Dec 2000, Martin Josefsson wrote:
> On Mon, 18 Dec 2000, Martin Josefsson wrote:
>
> > On Mon, 18 Dec 2000, Alan Cox wrote:
> >
> > > > I compiled test13-pre3 a few minutes ago and when runnin
On Mon, 18 Dec 2000, Martin Josefsson wrote:
> On Mon, 18 Dec 2000, Alan Cox wrote:
>
> > > I compiled test13-pre3 a few minutes ago and when running
> > > make modules_install I got this:
> > >
> > > depmod: *** Unresolved symbols in
>/lib/mo
On Mon, 18 Dec 2000, Alan Cox wrote:
> > I compiled test13-pre3 a few minutes ago and when running
> > make modules_install I got this:
> >
> > depmod: *** Unresolved symbols in
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> > depmod: buf
> I compiled test13-pre3 a few minutes ago and when running
> make modules_install I got this:
>
> depmod: *** Unresolved symbols in
>/lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
> depmod: buffer_insert_inode_queue
> depmod: fsync_inode_buffers
Jeff
Hi
I compiled test13-pre3 a few minutes ago and when running
make modules_install I got this:
depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/fs/ext2/ext2.o
depmod: buffer_insert_inode_queue
depmod: fsync_inode_buffers
As you may have noticed I have ext2
The most noticeable part of this is that the run_task_queue fix should
cure the lockup that some people have seen.
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 s
65 matches
Mail list logo
