"Barry K. Nathan" wrote:
>
> H. Peter Anvin wrote:
>
> > Alan Cox wrote:
>
> [snip]
>
> > > ia32 is an intel trademark. Using it for non intel products is probably an
> > > actionable matter ..
> > >
> >
> > Yet another reason to ignore it.
>
> Speaking of using it for non-Intel products, thi
H. Peter Anvin wrote:
> Alan Cox wrote:
[snip]
> > ia32 is an intel trademark. Using it for non intel products is probably an
> > actionable matter ..
> >
>
> Yet another reason to ignore it.
Speaking of using it for non-Intel products, this is a line from
Documentation/Changes in Linux 2.4.
Alan Cox wrote:
>
> > > True enough, personally I prefer "x86".
> >
> > ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...
>
> ia32 is an intel trademark. Using it for non intel products is probably an
> actionable matter ..
>
Yet another reason to ignore it.
-hpa
--
> > True enough, personally I prefer "x86".
>
> ia32 is the official name. OTOH, i[3-6]86 _are_ different beasts...
ia32 is an intel trademark. Using it for non intel products is probably an
actionable matter ..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Horst von Brand wrote:
>
> "H. Peter Anvin" <[EMAIL PROTECTED]>said:
> > Alan Cox wrote:
>
> [...]
>
> > > > We should never have used anything but "i386" as the utsname... sigh.
>
> > > Its questionable if we should include the 'i'
>
> > True enough, personally I prefer "x86".
>
> ia32 is t
"H. Peter Anvin" <[EMAIL PROTECTED]>said:
> Alan Cox wrote:
[...]
> > > We should never have used anything but "i386" as the utsname... sigh.
> > Its questionable if we should include the 'i'
> True enough, personally I prefer "x86".
ia32 is the official name. OTOH, i[3-6]86 _are_ different b
Alan Cox wrote:
>
> > > - make Pentium IV and other post-P6 processors use the "i686"
> > > family name (same fix as the system_utsname.machine init fix
> > > which went into include/asm-i386/bugs.h in test10-pre4)
> > >
> >
&
Alan Cox wrote:
>
> > > - make Pentium IV and other post-P6 processors use the "i686"
> > > family name (same fix as the system_utsname.machine init fix
> > > which went into include/asm-i386/bugs.h in test10-pre4)
> > >
> >
&
> > - make Pentium IV and other post-P6 processors use the "i686"
> > family name (same fix as the system_utsname.machine init fix
> > which went into include/asm-i386/bugs.h in test10-pre4)
> >
>
> We should never have used anything
On Thu, 26 Oct 2000, Rik van Riel wrote:
> On Wed, 25 Oct 2000, Roger Larsson wrote:
>
> > I noted that even try_to_free_buffers locks lru_list_lock.
>
> lru_list_lock != pagemap_lru_lock
>
btw, while we are at it, I am not able to reproduce this with test10-pre5
but am still running tests wi
On Wed, 25 Oct 2000, Roger Larsson wrote:
> I noted that even try_to_free_buffers locks lru_list_lock.
lru_list_lock != pagemap_lru_lock
cheers,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.s
Not.
It does not lock anything else...
This was not a problem.
/RogerL
Roger Larsson wrote:
>
> Hi again,
>
> Please ignore my patch suggestion from getblk -
> it will give problems later - in alloc...
>
> It is grow_buffers that might need to lock the
> other ones too...
>
> /RogerL
>
> -
Hi again,
Please ignore my patch suggestion from getblk -
it will give problems later - in alloc...
It is grow_buffers that might need to lock the
other ones too...
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > >
> > > Hi guys,
> > >
> > > When running SPEC SFS tests against 2.4.0-test10-pre4 on a 4-way SMP
> > > machine with 6G RAM (highmem+PAE enabled) I got
> > >
> > > __alloc_pages: 0-order allocation failed.
> > >
> > &
a spin lock there - which one? disassembly of
try_to_free_buffers?
/RogerL
Rajagopal Ananthanarayanan wrote:
>
> Tigran Aivazian wrote:
> >
> > Hi guys,
> >
> > When running SPEC SFS tests against 2.4.0-test10-pre4 on a 4-way SMP
> > machine wit
Tigran Aivazian wrote:
>
> Hi guys,
>
> When running SPEC SFS tests against 2.4.0-test10-pre4 on a 4-way SMP
> machine with 6G RAM (highmem+PAE enabled) I got
>
> __alloc_pages: 0-order allocation failed.
>
> (probably coming from nfsd, why don't we print ei
Hi guys,
When running SPEC SFS tests against 2.4.0-test10-pre4 on a 4-way SMP
machine with 6G RAM (highmem+PAE enabled) I got
__alloc_pages: 0-order allocation failed.
(probably coming from nfsd, why don't we print eip of the caller there?)
and the machine locked up (but pingable).
d to start reading directories before the oops
> occurred...Haven't been able to duplicate the oops on 2.4.0-test9.
Content-Description: 2.4.0-test10pre4 oops log
> Oct 19 17:58:13 uyema kernel: kernel BUG at vmscan.c:102!
Remove lines 101-104 in mm/vmscan.c of linux-2.4.0-test10
Hi!
> >> > * include/asm-i386/elf.h:
> >> > - make Pentium IV and other post-P6 processors use the "i686"
> >> > family name (same fix as the system_utsname.machine init fix
> >> > which went into include/asm-i386/bugs.h in
Myles Uyema writes:
> This kernel panic occurred when I attempted to dump my ext2 filesystem
> /home onto /mnt/ide/backup. My exact dump command was:
>
> dump -0 -u -M -f /mnt/ide/backup/home -B 2096128 /home
>
> I believe dump managed to start reading directories before the oops
> occurred...H
[1.] One line summary of the problem:
2.4.0-test10-pre4 produces an oops while using gpm
[2.] Full description of the problem/report:
I got the enclosed oops the following way:
cd to kernel source tree;
ls -lR;
when the listing is complete, use [SHIFT][PAGEUP] to scroll back as far
as possible
On Fri, 20 Oct 2000, Pavel Machek wrote:
>> > * include/asm-i386/elf.h:
>> > - make Pentium IV and other post-P6 processors use the "i686"
>> > family name (same fix as the system_utsname.machine init fix
>> > which went into include/a
Hi!
> > * include/asm-i386/elf.h:
> > - make Pentium IV and other post-P6 processors use the "i686"
> > family name (same fix as the system_utsname.machine init fix
> > which went into include/asm-i386/bugs.h in test10-pre4)
> >
>
> We
Why don't you capture the oops via serial console, pipe it through
ksymoops and send us a decent output, please? As is, your output is
useless as it contains _your_ kernel's virtual addresses which are
obviously different from _mine_.
Regards,
Tigran
-
To unsubscribe from this list: send the lin
Kernel: 2.4.0-test10-pre4
All items listed in Documentation/Changes are up to date.
Here is the stack-dump that occurred in the crash:
invalid operand:
CPU: 0
EIP: 0010:[]
EFLAGS: 00010292
eax: 001c ebx: c110fc58 ecx: c01f8928 edx: 0021
esi: 0100 edi: 0001 ebp: 03ff2045 esp
System is a 486DX2 66 MHz, 16 MB ram running redhat 7.0 with the
latest (Oct 20) patches. The kernel was compiled for it on a faster
machine, the only additional patch is the netfilter mss patch.
Here are the 2 instances of this bug:
Oct 21 15:16:42 morel kernel: kernel BUG at
Hi,
Attached is a tarball with the log of the event, a config used for the
kernel and dmesg output for overview of what the machine is. The BUG ocurred
while XFree 4 was running, the swap wasn't allocated at all, half of the
machine's memory was free. BUG ocurred two times, the second time it w
sfer the dirty bit to the page struct so that we
*know* there is no information loss.
If the above is correct, then the following patch should do (untested).
Oh, I think I missed adding pte_same in the generic pgtable.h macros, too.
I'm willing to take a closer look if you think it's ne
My 2.4.0-test10-pre4 box died overnight, apparently around 4 am when the
nightly cron-jobs run. The last thing logged looks interesting:
kernel BUG at vmscan.c:102!
invalid operand:
CPU:0
EIP:0010:[try_to_swap_out+252/796]
EFLAGS: 00010286
eax: 001c ebx: 0100 ecx
This kernel panic occurred when I attempted to dump my ext2 filesystem
/home onto /mnt/ide/backup. My exact dump command was:
dump -0 -u -M -f /mnt/ide/backup/home -B 2096128 /home
I believe dump managed to start reading directories before the oops
occurred...Haven't been able to duplicate the
[EMAIL PROTECTED] wrote...
> kernel BUG at vmscan.c:102!
I hit the same bug() an hour ago.
It was preceeded by a complete system lock up (not even sysrq worked)
and then fsck oopsed after triggering the above bug.
The lockup happened whilst I was diffing two kernel trees.
Seems large amounts of
On Fri, 20 Oct 2000, Ben LaHaise wrote:
>
> The primary reason I added the BUG was that if this is valid, it means
> that the pte has to be removed from the page tables first with
> pte_get_and_clear since it can be modified by the other CPU. Although
> this may be safe for shm, I think it's v
In article <[EMAIL PROTECTED]>, Matt Yourst <[EMAIL PROTECTED]> wrote:
>The following bug was just logged for 2.4.0-test10-pre4.
Just remove the two BUG() tests at lines 101-103 in mm/vmscan.c: they
seem to be bogus, and what they test for isn't actually a bug at all..
The following bug was just logged for 2.4.0-test10-pre4.
The machine was recompiling glibc (off a ReiserFS 3.6.18 filesystem)
and X was just running a screensaver at the time this happened. X was
locked up and I couldn't switch to a console, so I killed it with
Alt+SysRq. I was then able t
Ben,
you added these two BUG() conditions in your atomic pte patch:
> diff -ur v2.4.0-test10-pre2/mm/vmscan.c work-10-2/mm/vmscan.c
> --- v2.4.0-test10-pre2/mm/vmscan.cFri Oct 13 17:18:37 2000
> +++ work-10-2/mm/vmscan.c Fri Oct 13 17:19:47 2000
> @@ -99,6 +98,10 @@
> if (PageSwa
I got this oops dding partitions. test10-pre3
works fine.
below is a representative sample.
Thanks
-- todd --
root@pcx4168:~# fdisk -l /dev/hda
Disk /dev/hda: 255 heads, 63 sectors, 1216 cylinders
Units = cylinders of 16065 * 512 bytes
Device BootStart EndBlocks Id Syst
.machine init fix
> which went into include/asm-i386/bugs.h in test10-pre4)
>
We should never have used anything but "i386" as the utsname... sigh.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to sho
This patch should fix the Pentium IV and other CPU detection
glitches which remain in test10-pre4.
The necessary fixes are:
* arch/i386/kernel/setup.c:
- (Pentium IV) don't goto name_decoded, return instead; otherwise
x86_model_id which was grabbed from the extended cpuid levels
On Thu, 19 Oct 2000, Pau wrote:
> I've compiled and installed test10-pre4 in my laptop and I have had to
> reboot 4 times in less than a day.
>
> sysrq key is working so I attach some traces.
Sorry to follow up my self but... definately it happens when it starts
swapping.
I've compiled and installed test10-pre4 in my laptop and I have had to
reboot 4 times in less than a day.
sysrq key is working so I attach some traces.
If something more is needed just tell me.
Pau
Oct 19 11:02:45 pau kernel: kernel BUG at vmscan.c:102!
Oct 19 11:02:45 pau kernel: in
Date:Thu, 19 Oct 2000 15:42:23 +0400
From: Ivan Kokshaysky <[EMAIL PROTECTED]>
The pte_same() macro is defined only for i386. Here is #define for
alpha, but it should be suitable for all other ports too.
It actually belongs in asm-generic/pgtable.h
I've already sent Linus a
On Wed, Oct 18, 2000 at 03:46:45PM -0700, Linus Torvalds wrote:
> Ok, more of the "lots of small fixes" patches. The most notable of which
> is probably the atomic PTE patches by Ben LaHaise, which fixes the
> long-standing lost dirty bits problem under SMP, and also cleans up some
> of the ia32 P
xists in the tree and nothing should reference it anymore :-)
Here try this from your linux/ tree;
bash$ egrep x25_proto_init `find . -type f -name "*.[ch]"`
If that command prints anything, you have mis-patched your tree
when going to test10-pre4.
BTW, you could have eliminated some of t
On Wed, 18 Oct 2000, Robert M. Love wrote:
> for file include/net/x25.h, test10-pre4 contains this patch:
> with this, the file failed to compile -- the kernel compiles fine with it
> added back.
i wrote too fast -- while there is a problem with x25 in the current
kernel, it may n
for file include/net/x25.h, test10-pre4 contains this patch:
...
extern void x25_kill_by_neigh(struct x25_neigh *);
-#include
-
/* x25_dev.c */
...
with this, the file failed to compile -- the kernel compiles fine with it
added back.
--
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED
Ok, more of the "lots of small fixes" patches. The most notable of which
is probably the atomic PTE patches by Ben LaHaise, which fixes the
long-standing lost dirty bits problem under SMP, and also cleans up some
of the ia32 PAE mode issues.
The other noticeable one is the undefined C code thing
46 matches
Mail list logo
