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.
>
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 slow
"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/e
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 messy.
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
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 regis
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 inli
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
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 t
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, r
"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
[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 ...
wil
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 saf
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.
>
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.
Ch
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 *) proc_alloc_m
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
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_
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" i
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)
> } > {
> } > retur
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)
ad
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
> shou
e _LINUX_MM_STRUCT_H
+/*
+ * 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;
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 an
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 h
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 SM
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,
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 Deve
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 cho
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
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
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
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
"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 enable
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).
>
"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 w
"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 wha
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 t
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 imme
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 CONFIG_JOLI
"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
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 ge
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 initi
[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
> > right-to-left
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 po
Miles Lane wrote:
>
> Hi,
>
> Yesterday I reported a problem compiling with SMP enabled for an
> Athlon-targetted kernel. I wonder whether this is because there
> are no Athlon SMP systems out there, yet? If so, then if the
> architecture selected is Athlon, the SMP option should not be
> avail
Michael Elizabeth Chastain wrote:
>
> > and then I made the soft link to point to the new directory.
>
> If you are talking about a soft link named "linux", just completely
> delete it and reset it to the value that it had when you installed
> your distribution and then never touch it again.
>
Alan Cox wrote:
>
[AH>>]
> > larger ide-patch. What is it going to take to just accept it?
>
> I'd prefer to do it bit by bit, driver by driver without touching the core
> and picking the important and stable drivers first.
On one machine, I have applied ide-2.2.17.all.2904.patch
just to ge
54 matches
Mail list logo
