mirabilos wrote:
>
> Hi,
> I have got that patch with "movl %2,%%edx" and removing the tmp
> and still cannot compile with the same error message I posted yesterday.
> The problem seems to be that, with or without "inline", it seems to
> put a reference into main.o of arch/i386/boot/compressed.
mirabilos wrote:
Hi,
I have got that patch with movl %2,%%edx and removing the tmp
and still cannot compile with the same error message I posted yesterday.
The problem seems to be that, with or without inline, it seems to
put a reference into main.o of arch/i386/boot/compressed.
So I
Petr Vandrovec wrote:
>
> Hi Alan,
> can you apply this patch to next 2.4.4-acX ? This fixes problem with
> gcc3.0 (20010426) unable to compile this under some conditions. As
> __up_write() uses same code ("i" instead of tmp variable), I think
> that you should apply this. It can cause
"Richard B. Johnson" wrote:
>
> I noticed that my favorite "errno" has now gotten trashed by
> the newer 'C' runtime libraries.
>
> ENOTTY has been for ages, "Not a typewriter".
> It's now been changed to "Inappropriate ioctl for device".
>
> Methinks that this means that
Richard B. Johnson wrote:
I noticed that my favorite errno has now gotten trashed by
the newer 'C' runtime libraries.
ENOTTY has been for ages, Not a typewriter.
It's now been changed to Inappropriate ioctl for device.
Methinks that this means that ../linux/include/asm/errno.h now
Petr Vandrovec wrote:
Hi Alan,
can you apply this patch to next 2.4.4-acX ? This fixes problem with
gcc3.0 (20010426) unable to compile this under some conditions. As
__up_write() uses same code (i instead of tmp variable), I think
that you should apply this. It can cause slower
Alan Cox wrote:
>
> > Trace; c01b956a
> > Trace; c01b3fb5
> > Trace; c01b9aca
> > Trace; c01b9380
> > Trace; c01b9940
> > Trace; c01bd457
> > Trace; c01b4d2a
> > Trace; c01b5010
> > Trace; c01b51ff
>
> We seem to be several layers into recursive use of the ide driver - which
> shouldnt
Alan Cox wrote:
>
>
> > IIRC this thread is about boot going catatonic right after unloading
> > __initmem.
>
> Nope. Its about memory corruptions. Your bug sounds very different
>
> > Earlier, it looks like handle_mm_fault is being triggered from
> > fast_clear_page.
>
> That would be
Alan Cox wrote:
IIRC this thread is about boot going catatonic right after unloading
__initmem.
Nope. Its about memory corruptions. Your bug sounds very different
Earlier, it looks like handle_mm_fault is being triggered from
fast_clear_page.
That would be messy. The other way
Alan Cox wrote:
Trace; c01b956a ide_build_dmatable+2a/120
Trace; c01b3fb5 ide_set_handler+55/60
Trace; c01b9aca ide_dmaproc+11a/210
Trace; c01b9380 ide_dma_intr+0/b0
Trace; c01b9940 dma_timer_expiry+0/70
Trace; c01bd457 do_rw_disk+257/300
Trace; c01b4d2a ide_wait_stat+7a/e0
Alan Cox wrote:
>
> > the memory copy in the fast_page_copy routine. The machine then
> > proceeded
> > not to stop at my panic, but I got my "normal" oopses. I then had an
>
> Ok
>
> > idea and removed all the prefetch instructions from the beginning of the
> > routine and tried the
Alan Cox wrote:
the memory copy in the fast_page_copy routine. The machine then
proceeded
not to stop at my panic, but I got my normal oopses. I then had an
Ok
idea and removed all the prefetch instructions from the beginning of the
routine and tried the resultin kernel. I now
Hi,
In include/asm-i386/rwsem.h:__up_read(), the auto variable 'tmp' is
asserted to be in edx. This patch adjusts the constraint to match
the variable.
It could be argued that tmp should be declared register instead. I
didn't because the function is inlined. The compiler will know how
much
Hello,
I missed one, patch is incremental to the previous one.
Tom
$ diff -u include/asm-i386/checksum.h.orig include/asm-i386/checksum.h
--- include/asm-i386/checksum.h.origSun May 6 07:05:35 2001
+++ include/asm-i386/checksum.h Sun May 6 07:06:52 2001
@@ -100,10 +100,8 @@
static
Hello,
This patch stops the warning "Multiline strings are deprecated" from
gcc 3.0 [20010423] in include/asm-i386/checksum.h. I expect there
are more of these to be found.
Cheers,
Tom
$ diff -u include/asm-i386/checksum.h~ include/asm-i386/checksum.h
--- include/asm-i386/checksum.h~
Hello,
This patch stops the warning Multiline strings are deprecated from
gcc 3.0 [20010423] in include/asm-i386/checksum.h. I expect there
are more of these to be found.
Cheers,
Tom
$ diff -u include/asm-i386/checksum.h~ include/asm-i386/checksum.h
--- include/asm-i386/checksum.h~Mon
Hello,
I missed one, patch is incremental to the previous one.
Tom
$ diff -u include/asm-i386/checksum.h.orig include/asm-i386/checksum.h
--- include/asm-i386/checksum.h.origSun May 6 07:05:35 2001
+++ include/asm-i386/checksum.h Sun May 6 07:06:52 2001
@@ -100,10 +100,8 @@
static
Hi,
In include/asm-i386/rwsem.h:__up_read(), the auto variable 'tmp' is
asserted to be in edx. This patch adjusts the constraint to match
the variable.
It could be argued that tmp should be declared register instead. I
didn't because the function is inlined. The compiler will know how
much
Mark Hahn wrote:
>
> On Fri, 4 May 2001, Seth Goldberg wrote:
>
> > Hi,
> >
> > Before I go any further with this investigation, I'd like to get an
> > idea
> > of how much of a performance improvement the K7 fast_page_copy will give
> > me.
> > Can someone suggest the best benchmark to test
Mark Hahn wrote:
On Fri, 4 May 2001, Seth Goldberg wrote:
Hi,
Before I go any further with this investigation, I'd like to get an
idea
of how much of a performance improvement the K7 fast_page_copy will give
me.
Can someone suggest the best benchmark to test the speed of this
Seth Goldberg wrote:
>
> Hi,
>
> So it seems that CONFIG_X86_USE_3DNOW is simply used to
> enable access to the routines in mmx.c (the athlon-optimized
> routines on CONFIG_K7 kernels), so then it appears that somehow
> this is corrupting memory / not behaving as it should (very
> technical,
Seth Goldberg wrote:
Hi,
So it seems that CONFIG_X86_USE_3DNOW is simply used to
enable access to the routines in mmx.c (the athlon-optimized
routines on CONFIG_K7 kernels), so then it appears that somehow
this is corrupting memory / not behaving as it should (very
technical, right?)
"Mike A. Harris" wrote:
>
> Would the current state of athlon support be considered stable?
> I've got a colleague interested in getting a dual athlon box, and
> I'll be making the decision as to what hardware to purchase. I'm
> wondering is dual Athlon viable for a business solution right
>
Mike A. Harris wrote:
Would the current state of athlon support be considered stable?
I've got a colleague interested in getting a dual athlon box, and
I'll be making the decision as to what hardware to purchase. I'm
wondering is dual Athlon viable for a business solution right
now, or is
[Cc: trimmed]
Russell King wrote:
>
[...]
>
> Generally it seems like diff needs to produce one more line of context, and
> most of these problems will go away. Yes, there will still be the odd
> problem, so then it becomes the "how much do you crank the setting" problem.
>
$ diff -6 ...
Lee Leahu wrote:
>
> On Friday 20 April 2001 20:39, you wrote:
> > Lee Leahu <[EMAIL PROTECTED]> writes:
> > > would somebody be kind enough to explain why writing to
> > > the ntfs file system is extremely dangerous, and what are the
> > > developers doing to make writing to ntfs filesystem
Lee Leahu wrote:
On Friday 20 April 2001 20:39, you wrote:
Lee Leahu [EMAIL PROTECTED] writes:
would somebody be kind enough to explain why writing to
the ntfs file system is extremely dangerous, and what are the
developers doing to make writing to ntfs filesystem safe?
It's
[Cc: trimmed]
Russell King wrote:
[...]
Generally it seems like diff needs to produce one more line of context, and
most of these problems will go away. Yes, there will still be the odd
problem, so then it becomes the "how much do you crank the setting" problem.
$ diff -6 ...
will
Maneesh Soni wrote:
>
> Just a couple of points:
>
> On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
> [...]
> > +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
> > +
> Why not make this static?
> Initializer should be SPIN_LOCK_UNLOCKED.
>
Maneesh Soni wrote:
Just a couple of points:
On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
[...]
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
Why not make this static?
Initializer should be SPIN_LOCK_UNLOCKED.
Thanks, you're right on both counts.
Linus, Alan
I wrote:
>
> The proc_alloc_map bitfield is unprotected by any lock, and
> find_first_zero_bit() is not atomic. Concurrent module loading can race
> here.
Hello,
Here is a patch for this. It looks like callers are always in user context
(kmalloc flag GFP_KERNEL), so I used a light spinlock.
I wrote:
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
Hello,
Here is a patch for this. It looks like callers are always in user context
(kmalloc flag GFP_KERNEL), so I used a light spinlock.
Hello,
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
static int make_inode_number(void)
{
int i = find_first_zero_bit((void *)
Hello,
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
static int make_inode_number(void)
{
int i = find_first_zero_bit((void *)
Oliver Xymoron wrote:
>
> On Sun, 1 Apr 2001, Jeff Garzik wrote:
>
> > On Sun, 1 Apr 2001, David Lang wrote:
> > > if we want to get the .config as part of the report then we need to make
> > > it part of the kernel in some standard way (the old /proc/config flamewar)
> > > it's difficult
Oliver Xymoron wrote:
On Sun, 1 Apr 2001, Jeff Garzik wrote:
On Sun, 1 Apr 2001, David Lang wrote:
if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config flamewar)
it's difficult enough sometimes
Ulrich Drepper wrote:
>
> [EMAIL PROTECTED] writes:
>
> > with the new ansi standard, this use of __inline__ is no longer
> > necessary,
>
> This is not correct. Since the semantics of inline in C99 and gcc
> differ all code which depends on the gcc semantics should continue to
> use
Ulrich Drepper wrote:
[EMAIL PROTECTED] writes:
with the new ansi standard, this use of __inline__ is no longer
necessary,
This is not correct. Since the semantics of inline in C99 and gcc
differ all code which depends on the gcc semantics should continue to
use __inline__ since
Bill Wendling wrote:
>
> The use of the ternary operator is superfluous, though...and makes the
> code look ugly IMNSHO :).
>
You are correct. Please ignore my thinko.
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Bill Wendling wrote:
>
> Also sprach Andre Hedrick:
> } On Mon, 19 Feb 2001, Pozsar Balazs wrote:
> }
> } > from drivers/ide/ide-features.c:
> } >
> } > /*
> } > * All hosts that use the 80c ribbon mus use!
> } > */
> } > byte eighty_ninty_three (ide_drive_t *drive)
> } > {
> } >
Bill Wendling wrote:
Also sprach Andre Hedrick:
} On Mon, 19 Feb 2001, Pozsar Balazs wrote:
}
} from drivers/ide/ide-features.c:
}
} /*
} * All hosts that use the 80c ribbon mus use!
} */
} byte eighty_ninty_three (ide_drive_t *drive)
} {
} return ((byte)
Bill Wendling wrote:
The use of the ternary operator is superfluous, though...and makes the
code look ugly IMNSHO :).
You are correct. Please ignore my thinko.
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hi Alan,
The polishing is done. Versus 2.4.1 again.
Summary:
struct task_struct{...} moved to a new file, linux/task_struct.h.
struct sigpending{...} moved to a new file, linux/sigpending.h.
remove line linux/capability.c:17 #include (blessed by Andrew
Morgan)
Hi Alan,
The polishing is done. Versus 2.4.1 again.
Summary:
struct task_struct{...} moved to a new file, linux/task_struct.h.
struct sigpending{...} moved to a new file, linux/sigpending.h.
remove line linux/capability.c:17 #include linux/fs.h (blessed by Andrew
Morgan)
Manfred Spraul wrote:
>
> Tom Leete wrote:
> >
> > +
> > +#ifndef _LINUX_MM_H
> > +struct vm_area_struct;
> > +#endif
> > +
> Are the #ifndef's necessary?
> Could you try to remove the #ifndef and always declare the struct? gcc
> shouldn't
+/*
+ * linux/struct_mm.h
+ * Extracted from linux/sched.h: 02/09/2001 Tom Leete
+ *
+ */
+
+#ifdef __KERNEL__
+
+#include
+#include
+#include
+#include
+
+
+#ifndef _LINUX_MM_H
+struct vm_area_struct;
+#endif
+
+struct mm_struct {
+ struct vm_area_struct * mmap; /* list of VMAs
/include/linux/mm_struct.h Sat Feb 10 08:02:15 2001
@@ -0,0 +1,47 @@
+#ifndef _LINUX_MM_STRUCT_H
+#define _LINUX_MM_STRUCT_H
+/*
+ * linux/struct_mm.h
+ * Extracted from linux/sched.h: 02/09/2001 Tom Leete
+ *
+ */
+
+#ifdef __KERNEL__
+
+#include linux/list.h
+#include asm/atomic.h
+#include asm
Manfred Spraul wrote:
Tom Leete wrote:
+
+#ifndef _LINUX_MM_H
+struct vm_area_struct;
+#endif
+
Are the #ifndef's necessary?
Could you try to remove the #ifndef and always declare the struct? gcc
shouldn't complain.
Probably not necessary, but that seemed tidier if the struct
Andre Hedrick wrote:
>
> Make it and I will care and post it on kernel.org for you.
> I need that patch soon.
>
> On Thu, 1 Feb 2001, Tom Leete wrote:
>
> > Alan Cox wrote:
> > > The string.h code was fine, someone came along and put in a ridiculous loop
Alan Cox wrote:
>
> We have a very large number of memcpy's of unknown short length (often in
> interrupts) that are close to branches. A lot of
>
> if(foo==NULL)
> return
> memcpy(..
>
> stuff for example.
>
> Im more than happy for someone to do the benches
Alan Cox wrote:
>
> > It's not an incompatibility with the k7 chip, just bad code in
> > include/asm-i386/string.h. in_interrupt() cannot be called from there.
>
> The string.h code was fine, someone came along and put in a ridiculous loop
> in the include dependancies and broke it. Nobody has
Alan Cox wrote:
It's not an incompatibility with the k7 chip, just bad code in
include/asm-i386/string.h. in_interrupt() cannot be called from there.
The string.h code was fine, someone came along and put in a ridiculous loop
in the include dependancies and broke it. Nobody has had the
Alan Cox wrote:
We have a very large number of memcpy's of unknown short length (often in
interrupts) that are close to branches. A lot of
if(foo==NULL)
return
memcpy(..
stuff for example.
Im more than happy for someone to do the benches and prove me
Andre Hedrick wrote:
Make it and I will care and post it on kernel.org for you.
I need that patch soon.
On Thu, 1 Feb 2001, Tom Leete wrote:
Alan Cox wrote:
The string.h code was fine, someone came along and put in a ridiculous loop
in the include dependancies and broke
Peter Samuelson wrote:
>
> [Tom Leete]
> > It's not an incompatibility with the k7 chip, just bad code in
> > include/asm-i386/string.h.
>
> So you're saying SMP *is* supported on Athlon? Do motherboards exist?
>
> Peter
No, I'm saying that SMP locking
David Ford wrote:
>
> Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP?
>
>
>
> -d
>
> Stephen Frost wrote:
>
> > * David Ford ([EMAIL PROTECTED]) wrote:
> > > A person just brought up a problem in #kernelnewbies, building an SMP
> > > kernel doesn't work very well,
David Ford wrote:
Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP?
/idle questions
-d
Stephen Frost wrote:
* David Ford ([EMAIL PROTECTED]) wrote:
A person just brought up a problem in #kernelnewbies, building an SMP
kernel doesn't work very well,
Andre Hedrick wrote:
>
> ER, they work but must compile as PII/Celeron :-(
> A bunch of memcpy header stuff fails to compile
> current is one of the left overs in some cases.
>
> I will dive deeper in monday, just wanting some feed back first.
>
> Cheers,
>
> Andre Hedrick
> Linux ATA
Andre Hedrick wrote:
ER, they work but must compile as PII/Celeron :-(
A bunch of memcpy header stuff fails to compile
current is one of the left overs in some cases.
I will dive deeper in monday, just wanting some feed back first.
Cheers,
Andre Hedrick
Linux ATA Development
Peter Horton wrote:
>
> Building 2.4.1-pre8 for K7 gives 'current' undefined errors in the headers
> included from init/main.c. Looks like something included from asm/string.h
> is missing an include. The problems go away if I remove
> CONFIG_X86_USE3DNOW=y from the config.
>
> P.
The other
Peter Horton wrote:
Building 2.4.1-pre8 for K7 gives 'current' undefined errors in the headers
included from init/main.c. Looks like something included from asm/string.h
is missing an include. The problems go away if I remove
CONFIG_X86_USE3DNOW=y from the config.
P.
The other choices
Robert Kaiser wrote:
>
> Hi list,
>
> I can't seem to get the new 2.4.0 kernel running on a 386 CPU.
> The kernel was built for a 386 Processor, Math emulation has been enabled.
> I tried three different 386 boards. Execution seems to get as far as
> pagetable_init() in arch/i386/mm/init.c,
Robert Kaiser wrote:
Hi list,
I can't seem to get the new 2.4.0 kernel running on a 386 CPU.
The kernel was built for a 386 Processor, Math emulation has been enabled.
I tried three different 386 boards. Execution seems to get as far as
pagetable_init() in arch/i386/mm/init.c, then it
Johan Groth wrote:
>
> Hi,
> I wonder if anyone can help me with compilation of kernel 2.4.0. I've
> run make mrproper; make menuconfig; make dep and then I try to build the
> kernel with make bzImage but that fails utterly. I get the following
> message:
[...]
>
Johan Groth wrote:
Hi,
I wonder if anyone can help me with compilation of kernel 2.4.0. I've
run make mrproper; make menuconfig; make dep and then I try to build the
kernel with make bzImage but that fails utterly. I get the following
message:
[...]
/usr/src/linux/include/asm/string.h: In
Linus Torvalds wrote:
>
> On Thu, 4 Jan 2001, Tom Leete wrote:
> >
> > kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486.
> > Oops is repeatable.
>
> Looks like your mm->mmlist list is corrupted from the very start.
>
> Can you humo
Hello,
kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486.
Oops is repeatable.
I caught this one on serial console just as init begins:
$ ksymoops -K -L -O -v /boot/vmlinux-2.4.0-prerelease -m
/boot/System.map-2.4.0-prerelease tleete.prerelease.oops
ksymoops 2.3.5 on i486
Hello,
kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486.
Oops is repeatable.
I caught this one on serial console just as init begins:
$ ksymoops -K -L -O -v /boot/vmlinux-2.4.0-prerelease -m
/boot/System.map-2.4.0-prerelease tleete.prerelease.oops
ksymoops 2.3.5 on i486
Linus Torvalds wrote:
On Thu, 4 Jan 2001, Tom Leete wrote:
kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486.
Oops is repeatable.
Looks like your mm-mmlist list is corrupted from the very start.
Can you humor me and make sure you do a "make clean&qu
Matt Wright wrote:
>
> I've looked for answers to this question before, but all I could find was
> someone asking a similar question and no replies...
>
> I'm having great trouble getting 2.4.0-testX to compile on my system when
> I select Athlon/K7 as the Processor Family
>
> I've
Matt Wright wrote:
I've looked for answers to this question before, but all I could find was
someone asking a similar question and no replies...
I'm having great trouble getting 2.4.0-testX to compile on my system when
I select Athlon/K7 as the Processor Family
I've attached below
"David S. Miller" wrote:
> This is basically what is in my tree right now. However, there was
> one reporter who claimed that after this kind of change he still was
> able to lockup/OOPS his machine by logging into X as a user who had
> his home directory over NFS. This was with netfilter
Harald Welte wrote:
>
> On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote:
> >From: Rusty Russell <[EMAIL PROTECTED]>
> >Date: Mon, 18 Dec 2000 14:15:52 +1100
> >
> >Alexey is right, locking is screwed (explains some reports of
> >occasional failure during rmmod).
>
Harald Welte wrote:
On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote:
From: Rusty Russell [EMAIL PROTECTED]
Date: Mon, 18 Dec 2000 14:15:52 +1100
Alexey is right, locking is screwed (explains some reports of
occasional failure during rmmod).
Patch
"David S. Miller" wrote:
This is basically what is in my tree right now. However, there was
one reporter who claimed that after this kind of change he still was
able to lockup/OOPS his machine by logging into X as a user who had
his home directory over NFS. This was with netfilter enabled
"Mohammad A. Haque" wrote:
>
> I do the following
>
> sudo modprobe iptable_nat
>
> Module Size Used by
> iptable_nat17440 0 (unused)
> ip_conntrack 19808 1 [iptable_nat]
> ip_tables 12320 3 [iptable_nat]
>
> Oops start flying by
"Mohammad A. Haque" wrote:
I do the following
sudo modprobe iptable_nat
Module Size Used by
iptable_nat17440 0 (unused)
ip_conntrack 19808 1 [iptable_nat]
ip_tables 12320 3 [iptable_nat]
Oops start flying by when I
"David S. Miller" wrote:
>
>Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST)
>From: "Mohammad A. Haque" <[EMAIL PROTECTED]>
>
>I'll be trying in a few hours.
>
> Meanwhile for people wanting the crashes to be fixed, please
> apply this patch.
>
> This was _always_ broken, and really
"David S. Miller" wrote:
Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST)
From: "Mohammad A. Haque" [EMAIL PROTECTED]
I'll be trying in a few hours.
Meanwhile for people wanting the crashes to be fixed, please
apply this patch.
This was _always_ broken, and really what netfilter
Hello,
This from attempting to read a nfs mounted directory. ext2 in this case,
also had one with isofs over nfs.
This looks suspiciously like Jasper Spaans' current report on raid5.
Tom
Unable to handle kernel NULL pointer dereference at virtual address 003c
printing eip:
c01c0c32
*pde
Hello,
This from attempting to read a nfs mounted directory. ext2 in this case,
also had one with isofs over nfs.
This looks suspiciously like Jasper Spaans' current report on raid5.
Tom
Unable to handle kernel NULL pointer dereference at virtual address 003c
printing eip:
c01c0c32
*pde
Linus Torvalds wrote:
>
> It's not a new bug - it's an old bug that apparently is uncovered by a
> new stricter test.
>
> Apparently loopback unlocks an already unlocked page - which has always
> been a serious offense, but has never been detected before.
>
> test12-pre6+ detects it, and thus
Linus Torvalds wrote:
It's not a new bug - it's an old bug that apparently is uncovered by a
new stricter test.
Apparently loopback unlocks an already unlocked page - which has always
been a serious offense, but has never been detected before.
test12-pre6+ detects it, and thus the
Ishikawa wrote:
>
> 2.4.0-test-11: K7 compile error: `current' missing in string macro.
>
> Symptom:
> 2.4.0-test11 won't compile with K7 if we choose it for CPU.
>
> The compile error is attached at the end.
>
> The same config except for CPU (AMD K6) works.
> The diff of config is shown
Ishikawa wrote:
2.4.0-test-11: K7 compile error: `current' missing in string macro.
Symptom:
2.4.0-test11 won't compile with K7 if we choose it for CPU.
The compile error is attached at the end.
The same config except for CPU (AMD K6) works.
The diff of config is shown immediately
Hi,
Here is another.
Tom
--- linux-2.4.0-test11/arch/i386/kernel/setup.c.origSat Nov 18 01:55:18
2000+++ linux-2.4.0-test11/arch/i386/kernel/setup.c Sat Nov 18 07:43:19 2000
@@ -2178,7 +2178,7 @@
if (tsc_disable && cpu_has_tsc) {
printk("Disabling TSC...\n");
Hi,
The second and third arguments of get_joliet_filename() are swapped.
Tom
--- linux-2.4.0-test11/fs/isofs/namei.c.origSat Nov 18 01:55:55 2000
+++ linux-2.4.0-test11/fs/isofs/namei.c Sat Nov 18 07:08:05 2000
@@ -127,7 +127,7 @@
dpnt = tmpname;
#ifdef
Hi,
The second and third arguments of get_joliet_filename() are swapped.
Tom
--- linux-2.4.0-test11/fs/isofs/namei.c.origSat Nov 18 01:55:55 2000
+++ linux-2.4.0-test11/fs/isofs/namei.c Sat Nov 18 07:08:05 2000
@@ -127,7 +127,7 @@
dpnt = tmpname;
#ifdef
Hi,
Here is another.
Tom
--- linux-2.4.0-test11/arch/i386/kernel/setup.c.origSat Nov 18 01:55:18
2000+++ linux-2.4.0-test11/arch/i386/kernel/setup.c Sat Nov 18 07:43:19 2000
@@ -2178,7 +2178,7 @@
if (tsc_disable cpu_has_tsc) {
printk("Disabling TSC...\n");
"David S. Miller" wrote:
>
>Date: Mon, 13 Nov 2000 18:05:24 -0500
>From: Tom Leete <[EMAIL PROTECTED]>
>
>Your net/ipv4/tcp.c patch from the NE2000 thread cured them even
>before I found the hardware fault. Has that patch gone to the
>q
"David S. Miller" wrote:
Date: Mon, 13 Nov 2000 18:05:24 -0500
From: Tom Leete [EMAIL PROTECTED]
Your net/ipv4/tcp.c patch from the NE2000 thread cured them even
before I found the hardware fault. Has that patch gone to the
queue? I recommend it.
The bugs I w
Hi,
My lockup problems started increasing in frequency, and it
became obvious that they were independent of the kernel I
booted. The shoe dropped, nic was failing. It's salvage now.
The bizarre shift errors on ftp are gone, so the data I sent
is irrelevant to the kernel.
The soft hangs I was
Hi,
My lockup problems started increasing in frequency, and it
became obvious that they were independent of the kernel I
booted. The shoe dropped, nic was failing. It's salvage now.
The bizarre shift errors on ftp are gone, so the data I sent
is irrelevant to the kernel.
The soft hangs I was
Hi,
This bug was triggered by trying ctrl-alt-del for reboot in
test10-pre5. It appears to show schedule() getting stuck in
a loop with the stack growing unbounded.
Unfortunately, the module list and symbols are not exposed.
I don't know what had been unloaded before the bug
triggered. The
Hi,
This bug was triggered by trying ctrl-alt-del for reboot in
test10-pre5. It appears to show schedule() getting stuck in
a loop with the stack growing unbounded.
Unfortunately, the module list and symbols are not exposed.
I don't know what had been unloaded before the bug
triggered. The
[CC trimmed]
Bill Wendling wrote:
>
> Also sprach Tom Leete:
> }
> } You are correct that in C the rightmost argument is always
> } at the open end of the stack, and that varargs require that.
> } The opposite is called the Pascal convention.
> }
> Where in the standar
Peter Samuelson wrote:
>
> [Matti Aarnio]
> > > That depends mainly on question: Does your stack grow up or down ?
>
> [Ben Pfaff]
> > No it doesn't. It depends mainly on whether the ABI for the machine
> > says that arguments are pushed onto the stack in left-to-right or
> >
Peter Samuelson wrote:
[Matti Aarnio]
That depends mainly on question: Does your stack grow up or down ?
[Ben Pfaff]
No it doesn't. It depends mainly on whether the ABI for the machine
says that arguments are pushed onto the stack in left-to-right or
right-to-left order. You
[CC trimmed]
Bill Wendling wrote:
Also sprach Tom Leete:
}
} You are correct that in C the rightmost argument is always
} at the open end of the stack, and that varargs require that.
} The opposite is called the Pascal convention.
}
Where in the standard does it say this? It's probably
Sean Estabrooks wrote:
>
> Hi Andre,
>
> The if() logic must then rely on implementation specific compiler
> details and not have any optimizations which break this code. While it may
> "WORK" it isn't particularly reliable code.
>
> Sean
Nope, the logical ops are sequence
1 - 100 of 106 matches
Mail list logo
