freeing memory

[mdaljeet]

hi,

i am allocating some 1000 bytes of memory as folows

f_malloc()
{
 .
 for (i=1 to 10)
 {
 size = 1000;
 pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
 }
 ...
}

and freeing the allocated memory as follows

f_free()
{
 .
 for (i=1 to 10)
 {
 kfree(pAddr[i]);
 }
}

pAddr is defined as 'unsigned long pAddr[10]'

But when f_free executes i ran into problems and computer hangs.
What can be the problem?

regards,
daljeet.


-
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/

Re: freeing memory

[Bordi Zhou]

  It's not a fault of kernel, it's just a mistake.
you should use
for(i=0 to 9)
pAddr[10] only has a range of 0 to 9.
miic> f_malloc()
miic> {
miic>  .
miic>  for (i=1 to 10)
miic>  {
miic>  size = 1000;
miic>  pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
miic>  }
miic>  ...
miic> }

miic> and freeing the allocated memory as follows

miic> f_free()
miic> {
miic>  .
miic>  for (i=1 to 10)
miic>  {
miic>  kfree(pAddr[i]);
miic>  }
miic> }

miic> pAddr is defined as 'unsigned long pAddr[10]'

miic> But when f_free executes i ran into problems and computer hangs.
miic> What can be the problem?


-
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/

Re: freeing memory

[Marcus Sundberg]

[EMAIL PROTECTED] writes:

> hi,
> 
> i am allocating some 1000 bytes of memory as folows
> 
> f_malloc()
> {
>  .
>  for (i=1 to 10)
>  {
>  size = 1000;
>  pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);

[snip]

> pAddr is defined as 'unsigned long pAddr[10]'
> 
> But when f_free executes i ran into problems and computer hangs.
> What can be the problem?

i == 10 will write past the end of your array.
Get a good book about C and read it.

//Marcus
-- 
---+---
Marcus Sundberg|   Phone: +46 707 452062
  Embedded Systems Consultant  |  Email: [EMAIL PROTECTED]
   Cendio Systems AB   |   http://www.cendio.com
-
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/

just a small VM idea

[Samium Gromoff]

Let`s imagine were having two mounted swap partitions.
Current situation, if im not going wrong is the next:
  swapping to 1st partition, till there is a space on it
  then swapping to the next one...
But if make two basic checks:
   1) if these partitions are on different drives
   2) i/o speed is approx the same
we can do parallel page writes/reads, therefore
in fact twicing swapping i/o...

sorry for my ugly english/lameness

-
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/

[PATCH] Make sure cpu_data[] is cache line aligned

[Andi Kleen]

Hi Alan,

cpu_data[] should be cache line aligned to make the per CPU pte allocation
tricks work without false sharing. This patch ensure this 
(against 2.2.18pre15). Without it it is rather a gamble (1 : 8). With 32
byte cache lines it probably does not hurt too much because the stuff
at the beginning of cpuinfo_x86 is not frequently accessed, and it ensures
that the hot fields are separated by at least 32bytes, but with P4-SMP and 
K7-SMP that will likely not work anymore.

Please apply,


-Andi

--- linux-work/arch/i386/kernel/smp.c-BOOTFIX   Fri Oct 20 06:19:46 2000
+++ linux-work/arch/i386/kernel/smp.c   Sun Oct 22 10:57:11 2000
@@ -112,7 +112,9 @@
 static volatile unsigned long cpu_callout_map[NR_CPUS] = {0,}; /* We always use 0 the 
rest is ready for parallel delivery */
 volatile unsigned long smp_invalidate_needed;  /* Used for the invalidate map 
that's also checked in the spinlock */
 volatile unsigned long kstack_ptr; /* Stack vector for booting 
CPUs*/
-struct cpuinfo_x86 cpu_data[NR_CPUS];  /* Per CPU bogomips and other 
parameters*/
+struct cpuinfo_x86 cpu_data[NR_CPUS] 
+__attribute__((__section(".data.cacheline_aligned"),__align__(SMP_CACHE_BYTES)));
+   /* Per CPU bogomips and other parameters*/
 static unsigned int num_processors = 1;/* Internal processor 
count */
 unsigned char boot_cpu_id = 0; /* Processor that is doing the 
boot up  */
 static int smp_activated = 0;  /* Tripped once we need to 
start cross invalidating */
-
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/

[PATCH] Fix 32byte cacheline dependency

[Andi Kleen]

Hi Alan,

This patch against 2.2.18pre15 replaces the hardcoded 32 byte cache line
alignment for the .data.cacheline_aligned section with a dynamic one 
depending on asm/cache.h [so that K7-SMP will hopefully be handled gratefully]

Please apply,


-Andi


--- linux-work/arch/i386/Makefile-BOOTFIX   Thu May  4 02:16:30 2000
+++ linux-work/arch/i386/Makefile   Sun Oct 22 10:39:15 2000
@@ -25,22 +25,27 @@
 
 ifdef CONFIG_M386
 CFLAGS := $(CFLAGS) -m386 -DCPU=386
+CPU := 386
 endif
 
 ifdef CONFIG_M486
 CFLAGS := $(CFLAGS) -m486 -DCPU=486
+CPU := 486
 endif
 
 ifdef CONFIG_M586
 CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 
-DCPU=586
+CPU := 586
 endif
 
 ifdef CONFIG_M586TSC
 CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 
-DCPU=586
+CPU := 586
 endif
 
 ifdef CONFIG_M686
 CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 
-DCPU=686
+CPU := 686
 endif
 
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
@@ -65,7 +70,7 @@
 vmlinux: arch/i386/vmlinux.lds
 
 arch/i386/vmlinux.lds: arch/i386/vmlinux.lds.S FORCE
-   $(CPP) -C -P -I$(HPATH) -imacros $(HPATH)/asm-i386/page_offset.h -Ui386 
arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds
+   $(CPP) -DCPU=${CPU} -C -P -I$(HPATH) -imacros $(HPATH)/asm-i386/page_offset.h 
+-Ui386 arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds
 
 FORCE: ;
 
--- linux/arch/i386/vmlinux.lds.S   Fri Oct 20 06:19:26 2000
+++ linux-work/arch/i386/vmlinux.lds.S  Sun Oct 22 10:47:16 2000
@@ -1,6 +1,7 @@
 /* ld script to make i386 Linux kernel
  * Written by Martin Mares <[EMAIL PROTECTED]>;
  */
+#include  
 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
 OUTPUT_ARCH(i386)
 ENTRY(_start)
@@ -53,7 +54,7 @@
   __init_end = .;
 
 
-  . = ALIGN(32);
+  . = ALIGN(L1_CACHE_BYTES);
   .data.cacheline_aligned : { *(.data.cacheline_aligned) }
 
   . = ALIGN(4096);
-
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/

Re: just a small VM idea

[Tigran Aivazian]

On Sun, 22 Oct 2000, Samium Gromoff wrote:

> Let`s imagine were having two mounted swap partitions.

swap partitions are never mounted, there is no swapfs for Linux (and it is
arguable whether we need one).


> Current situation, if im not going wrong is the next:
[nice, but a few years late :) ideas deleted]

you are in fact wrong. You can either check the source in mm/swapfile.c
or, even easier, read the manual page for swapon(2) which explains the use
of priorities, which was in Linux since the early days of 1.3.6 (i.e. many
years ago). Basically, you can add swap devices with multiple priorities
and then a highest priority one is exhausted before using a lower-priority
one. If all areas are the same priority, then pages are allocated using
round robin algorithm, i.e. alternating between them.

Regards,
Tigra



-
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/

[bug] floppy act. LED comes on after APM resume

[David Ford]

Ok, this is getting really humorous and I've no way to explain it.

Every few kernels I install on my laptop, when doing an APM resume, the
floppy activity LED comes on and stays on until I do something to change
the status of the floppy such as attempting a mount (with or without a
floppy in the drive).  Simply inserting a floppy or eject/insert doesn't
fix it.

Being on a laptop, this can be a significant power drain when I'm
running off the battery.  It's an NEC Versa LX, the floppy is the
standard 1.44 that comes with it.

Any takers?

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[Andi Kleen]

On Sat, Oct 21, 2000 at 09:44:31PM +0200, bert hubert wrote:
> On Sat, Oct 21, 2000 at 08:50:54AM +0200, Andi Kleen wrote:
> 
> > Linux 2.4 has the "dataready" filter in form of the (currently undocumented)
> > TCP_DEFER_ACCEPT option.
> 
> Patch follows beneath. On a related note, I'm not sure if this is right
> (connecting to a daemon using TCP_DEFER_ACCEPT)

Yes, looks very broken. I guess there was a reason why it was never documented.

Sorry for advertising it as a working feature.




-Andi

-
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/

Update to autofs4 for new(-ish) VFS stuff

[Jeremy Fitzhardinge]

Ever since the addition of struct vfs_mount, autofs4 has got the "is this
filesystem busy" test wrong.  This patch against 2.4.0-test9 makes it
smarter.

J


--- linux.orig/CREDITS  Tue Oct  3 17:30:15 2000
+++ linux/CREDITS   Tue Oct  3 17:56:04 2000
@@ -795,13 +795,16 @@
 S: Germany
 
 N: Jeremy Fitzhardinge
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+W: http://www.goop.org/~jeremy
+D: author of userfs filesystem
 D: Improved mmap and munmap handling
 D: General mm minor tidyups
-S: 67 Surrey St.
-S: Darlinghurst, Sydney
-S: New South Wales 2010
-S: Australia
+D: autofs v4 filesystem rework
+S: 987 Alabama St
+S: San Francisco
+S: SA, 94110
+S: USA
 
 N: Ralf Flaxa
 E: [EMAIL PROTECTED]
diff -x *.o -x *~ -x *.flags -x .depend -x .hdepend -u 2.3/fs/autofs4/expire.c 
local-2.3/fs/autofs4/expire.c
--- linux.orig/fs/autofs4/expire.c  Wed Sep  6 18:02:29 2000
+++ linux/fs/autofs4/expire.c   Sat Oct 21 19:07:24 2000
@@ -3,7 +3,7 @@
  * linux/fs/autofs/expire.c
  *
  *  Copyright 1997-1998 Transmeta Corporation -- All Rights Reserved
- *  Copyright 1999 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
+ *  Copyright 1999-2000 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
  *
  * This file is part of the Linux kernel and is made available under
  * the terms of the GNU General Public License, version 2, or at your
@@ -15,46 +15,139 @@
 
 /*
  * Determine if a subtree of the namespace is busy.
+ *
+ * mnt is the mount tree under the autofs mountpoint
  */
-static int is_tree_busy(struct vfsmount *mnt)
+static inline int is_vfsmnt_tree_busy(struct vfsmount *mnt)
 {
struct vfsmount *this_parent = mnt;
struct list_head *next;
int count;
 
-   spin_lock(&dcache_lock);
-   count = atomic_read(&mnt->mnt_count) - 2;
-   if (!is_autofs4_dentry(mnt->mnt_mountpoint))
-   count--;
+   count = atomic_read(&mnt->mnt_count) - 1;
+
 repeat:
next = this_parent->mnt_mounts.next;
+   DPRINTK(("is_vfsmnt_tree_busy: mnt=%p, this_parent=%p, next=%p\n",
+mnt, this_parent, next));
 resume:
-   while (next != &this_parent->mnt_mounts) {
-   struct list_head *tmp = next;
-   struct vfsmount *p = list_entry(tmp, struct vfsmount,
+   for( ; next != &this_parent->mnt_mounts; next = next->next) {
+   struct vfsmount *p = list_entry(next, struct vfsmount,
mnt_child);
-   next = tmp->next;
-   /* Decrement count for unused children */
-   count += atomic_read(&p->mnt_count) - 2;
+
+   /* -1 for struct vfs_mount's normal count, 
+  -1 to compensate for child's reference to parent */
+   count += atomic_read(&p->mnt_count) - 1 - 1;
+
+   DPRINTK(("is_vfsmnt_tree_busy: p=%p, count now %d\n",
+p, count));
+
if (!list_empty(&p->mnt_mounts)) {
this_parent = p;
goto repeat;
}
/* root is busy if any leaf is busy */
-   if (atomic_read(&p->mnt_count) > 1) {
-   spin_unlock(&dcache_lock);
+   if (atomic_read(&p->mnt_count) > 1)
return 1;
-   }
}
-   /*
-* All done at this level ... ascend and resume the search.
-*/
+
+   /* All done at this level ... ascend and resume the search. */
if (this_parent != mnt) {
next = this_parent->mnt_child.next; 
this_parent = this_parent->mnt_parent;
goto resume;
}
-   spin_unlock(&dcache_lock);
+
+   DPRINTK(("is_vfsmnt_tree_busy: count=%d\n", count));
+   return count != 0; /* remaining users? */
+}
+
+/* Traverse a dentry's list of vfsmounts and return the number of
+   non-busy mounts */
+static int check_vfsmnt(struct vfsmount *mnt, struct dentry *dentry)
+{
+   int ret = 0;
+   struct list_head *tmp;
+
+   list_for_each(tmp, &dentry->d_vfsmnt) {
+   struct vfsmount *vfs = list_entry(tmp, struct vfsmount, 
+ mnt_clash);
+   DPRINTK(("check_vfsmnt: mnt=%p, dentry=%p, tmp=%p, vfs=%p\n",
+mnt, dentry, tmp, vfs));
+   if (vfs->mnt_parent != mnt || /* don't care about busy-ness of other 
+namespaces */
+   !is_vfsmnt_tree_busy(vfs))
+   ret++;
+   }
+
+   DPRINTK(("check_vfsmnt: ret=%d\n", ret));
+   return ret;
+}
+
+/* Check dentry tree for busyness.  If a dentry appears to be busy
+   because it is a mountpoint, check to see if the mounted
+   filesystem is busy. */
+static int is_tree_busy(struct vfsmount *topmnt, struct dentry *top)
+{
+   struct dentry *this_parent;
+   struct list_head *next;
+   int count;
+
+   count = atomic_read(&top->d_count);
+   
+   DPRINTK(

Re: [Criticism] On the discussion about C++ modules

[Linux Kernel Developer]

Wasn't the original complaint that the kernel headers use C++ keyword
and thus prevent the writing of, at least some, modules in C++.  I have
written C++ code before that was as least as fast as comparable C code and
more efficient in some ways.  Whether this could be or not be reproduced in
kernel code I do not know.  So far I have done my kernel programming in C.
However even if I or other programmers would like to give this a try it is
my understanding we cannot because of the header situation.  I think it is
unfair to attack C++ kernel code that is unable to come into existence, at
least without jumping through a bunch of hoops, due to external influences
(i.e. the incompatible headers).

On a separate note.  Isn't one of the philosophies behind Linux the idea
of freedom.  If people wish to try and program their modules in C++ for
whatever reason, be it porting from existing code or to object orient their
code, should they be free to do so.  If the header situation is true, which
I am not sure of since I have not tried to do C++ programming in kernel
code, then people aren't free to write modules however they wished.  Seeing
as fixing the headers should be rather trivial and probably is the right
thing to do anyway (using existing language keywords is a bad idea) I do not
see why this same flame war must erupt every time the header situation is
brought up.  Its not as if C++ code would all of the sudden popup in the
kernel core forcing everybody to use C++.  At best a driver here and there
might start using it and its continual usage would depend on if its
implementation is successful or not.  And those drivers themselves are
extremely likely to be self-contained thus not affecting anybody else's
kernel code.

> If C++ really is that good for kernel modules, I'd like to
> see some code that proves it can be done without too much
> of a performance hit (or without a performance hit at all?).
>
> Sending 500 rants to the kernel list isn't even close to
> being productive. Sending 1 patch is...
>
> regards,
>
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
>
> http://www.conectiva.com/ http://www.surriel.com/
>
> -
> 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/
>

-
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/

Re: USB problem in 2.2.18pre17

[Hans-Joachim Baader]

Hi Greg,

> > my digital camera (Kodak DC 280) doesn't work with USB in 2.2.18pre17
> > (and previos kernels). It did work with 2.4.0-test9. Here's the log:
> 
> What is the BIOS setting of MPS?  If it's 1.4, please try 1.1
> 
> Let me know if this helps out any.

With 1.1 it works great. Can you fix this to work with 1.4 too?

Many thanks,
hjb
-- 
http://www.pro-linux.de/ - Germany's largest volunteer Linux support site
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[bert hubert]

On Sun, Oct 22, 2000 at 11:48:22AM +0200, Andi Kleen wrote:

> > Patch follows beneath. On a related note, I'm not sure if this is right
> > (connecting to a daemon using TCP_DEFER_ACCEPT)
> 
> Yes, looks very broken. I guess there was a reason why it was never
> documented.

>From a userland perspective, it works very well. It just wastes packets.

> Sorry for advertising it as a working feature.

The fix should be easy. I'm looking in to it.

Regards,

bert hubert

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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/

Re: [Criticism] On the discussion about C++ modules

[David Weinehall]

On Sun, Oct 22, 2000 at 06:42:19AM -0400, Linux Kernel Developer wrote:
> Wasn't the original complaint that the kernel headers use C++
> keyword and thus prevent the writing of, at least some, modules in
> C++.  I have written C++ code before that was as least as fast as
> comparable C code and more efficient in some ways.  Whether this
> could be or not be reproduced in kernel code I do not know.  So
> far I have done my kernel programming in C.  However even if I or
> other programmers would like to give this a try it is my
> understanding we cannot because of the header situation.  I think
> it is unfair to attack C++ kernel code that is unable to come into
> existence, at least without jumping through a bunch of hoops, due
> to external influences (i.e. the incompatible headers).

Yup, it's simple as hell to fix the occurences. Simply use an
interactive commandline find+sed expression and you should be happy.
It might take some time, but it's not complex.

And NOONE has forbidden the C++ lovers to do this. To my knowledge,
noone has done this, so far. WHY should the workload of this change
be laid on the programmers who don't feel any need for C++ in the
kernel?

I bet that all people who want to play with C++ in the kernel would
like this kind of patch. Cook it up, post the url to it somewhere and
bask in the glory.

> On a separate note.  Isn't one of the philosophies behind Linux the
> idea of freedom.  If people wish to try and program their modules in

Uhmmm, the original philosophy behind Linux was Linus not being able
to afford to pay for the legacy Unixen and Tannenbaum refusing to
accept any improvements to Minux... "I like free beer"... Of course,
realising that others might be in the same situation, he decided to
release the kernel under the GPL.

But the question is, do you REALLY think that it's a coincidence that
Linus is still a benevolent dictator? This isn't exactly the
developmentmodel of total freedom, isn't? The Mozilla-model comes
closer, and I bet there are even more open projects. But do they
work as good? Nope.

But the GPL gives you every right to change this. You're fully free to
fork the kernel WHENEVER you like. You can then change the goals of
your new kernelproject completely and make it fully C++, if you like.

But I doubt you'd succeed. Not because of your skills (I know nothing
about them), but because C++ isn't a one-concept language. Is an
aggregate of every damn new, cool programming concept, barring
functional programming. This simply doesn't cut it in a kernel.

If you succeed, however, I wish you good luck.

> C++ for whatever reason, be it porting from existing code or to object
> orient their code, should they be free to do so.  If the header

Yup. And I want to try out my modules coded in Visual Cobol, APL,
and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.

> situation is true, which I am not sure of since I have not tried to do
> C++ programming in kernel code, then people aren't free to write
> modules however they wished.  Seeing as fixing the headers should be

As long as they don't have any delusions that those modules will
be accepted into the mainline kernel, then yes.

> rather trivial and probably is the right thing to do anyway (using
> existing language keywords is a bad idea) I do not see why this same

I bet that a lot of the variable-names we use are keywords in this or
that language.

> flame war must erupt every time the header situation is brought up.
> Its not as if C++ code would all of the sudden popup in the kernel
> core forcing everybody to use C++.  At best a driver here and there

No, this is an "at worst" situation. Fast corruption can be dealt with
efficiently; just return to an earlier kernel and fork from there.
Slow corruption is another matter altogether.

Then again, I trust our benevolent dictator's judgement. I'm pretty
confident he won't let the kernel become contaminated.

> might start using it and its continual usage would depend on if its
> implementation is successful or not.  And those drivers themselves are
> extremely likely to be self-contained thus not affecting anybody
> else's kernel code.

If C++ really is what we save us all from an uncertain destiny and
the lack thereof is what keeps every good kernelhacker in existance from
participating, then I'm pretty confident that the merits of a C++
kernel would pretty fast become obvious. Devote one of your servers to
be a CVS-server for the C++ kernelbranch and let people hack away. For
every single kernelrelease you then release a patch-set that contains
the difference between the two trees. This isn't particularly hard.
You could as Larry McVoy for BitKeeper if you like, if you need
something better than CVS.

Good luck!


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  ht

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[kuznet]

Hello!

> The SYN/ACK handshake appears to go well, and telnet reports a connection
> (the daemon doesn't, no data has been sent). However, Linux keeps sending
> SYNs, which keep getting ACKed. I'm not sure if this is desired behavior. It
> appears to be a side effect of the TCP_DEFER_ACCEPT timeout implementation,
> which seems to hijack the SYNACK_RESEND timeout.

Until actively connecting client will send some data,
service will and must retransmit syn-ack. Otherwise you will lose connection.

DEFER_ACCEPT (like data_ready filter) applies only
to sessions, which expect some data from client as beginning
of transaction. F.e. HTTP.


> Also, this timeout is not quite the number of seconds specified to
> setsockopt, because of this.

It is rounded up to 3*2^N seconds.

Alexey
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[bert hubert]

On Sun, Oct 22, 2000 at 04:25:39PM +0400, [EMAIL PROTECTED] wrote:

> Until actively connecting client will send some data,
> service will and must retransmit syn-ack. Otherwise you will lose connection.

I don't see why. This is a trace with my patch applied, can you tell me
what's wrong with it?

$ telnet 0 2500
27.253640 l.1192 > l.2500: S 1201711948:1201711948(0) win 32280  (DF) [tos 0x10]
27.253756 l.2500 > l.1192: S 1189762934:1189762934(0) ack 1201711949 win 32280  (DF)
27.253825 l.1192 > l.2500: . ack 1 win 32280  (DF) 
[tos 0x10]
Connection established, and I send no data

After half a minute, I send 'quit':
08.195229 l.1192 > l.2500: P 1:7(6) ack 1 win 32280  
(DF) [tos 0x10]
08.195383 l.2500 > l.1192: . ack 7 win 32274  (DF)
08.350985 l.2500 > l.1192: P 1:39(38) ack 7 win 32274  (DF)
08.351032 l.1192 > l.2500: . ack 39 win 32242  (DF) 
[tos 0x10]
08.376599 l.2500 > l.1192: P 39:82(43) ack 7 win 32274  (DF)
08.376644 l.1192 > l.2500: . ack 82 win 32199  (DF) 
[tos 0x10]
08.379948 l.2500 > l.1192: F 82:82(0) ack 7 win 32274  (DF)
08.380253 l.1192 > l.2500: F 7:7(0) ack 83 win 32696  
(DF) [tos 0x10]
08.380312 l.2500 > l.1192: . ack 8 win 32274  (DF)
Connection is gone.

This looks exactly correct to me. I don't see why we'd need repeated SYNACKs
between establishment of the connection and the arrival of the first data
packet. Why would we lose the connection? 

> DEFER_ACCEPT (like data_ready filter) applies only
> to sessions, which expect some data from client as beginning
> of transaction. F.e. HTTP.

Of course, but I see no reason to send spurious SYNACKs which have clearly
been ACKed.

I am but a humble amateur in TCP/IP matters, so please explain your
reasoning.

Regards,

bert hubert

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[kuznet]

Hello!

> Connection established, and I send no data

But why did you set DEFER_ACCEPT then? 8)

I explained when it can be used.


> packet. Why would we lose the connection? 

Not enter "quit", wait until connection will timeout.
(It is not very soon normally). And look what happens.
Hint: the picture, which you will see is prohibited.
It becomes legal, as soon as we do not enter ESTABLISHED
state. Your ACK is just ignored and we continue to retransmit
SYN-ACK being in SYN-RECV.

Alexey
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[bert hubert]

On Sun, Oct 22, 2000 at 04:56:41PM +0400, [EMAIL PROTECTED] wrote:
> Hello!
> 
> > Connection established, and I send no data
> 
> But why did you set DEFER_ACCEPT then? 8)

I was just experimenting.

> It becomes legal, as soon as we do not enter ESTABLISHED
> state. Your ACK is just ignored and we continue to retransmit
> SYN-ACK being in SYN-RECV.

With my patch applied:

43.392834 l.1311 > l.2500: S 3232293621:3232293621(0) win 32280  (DF) [tos 0x10]
43.392948 l.2500 > l.1311: S 3229276625:3229276625(0) ack 3232293622 win 32280  (DF)
43.393018 l.1311 > l.2500: . ack 1 win 32280  (DF) 
[tos 0x10]

(time passes, and I send some data)

51.370011 l.1311 > l.2500: P 1:3(2) ack 1 win 32280  
(DF) [tos 0x10]
51.370102 l.2500 > l.1311: R 3229276626:3229276626(0) win 0 (DF) [tos 0x10]

Ok, this surely is incorrect. However, sending spurious SYNACK packets
doesn't seem like the way to solve this problem. I know it complicates the
kernel, but if we do connection preprocessing, shouldn't we also do teardown
in case of timeout?

Thanks for the explanation.

Regards,

bert hubert

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[kuznet]

Hello!

> Ok, this surely is incorrect. However, sending spurious SYNACK packets
> doesn't seem like the way to solve this problem.

They are _not_ spurious. Connection did not enter ESTABLISHED state.
If it entered this state, we would have no rights to timeout.
It should be closed with FIN etc. etc.

In fact we do the only thing, which is possible without further
violation of protocol.

About uglyness. Violations of protocol are ugly. When all
the things proceed in a legal way undistingushable,
it is beautiful. 8)

> kernel, but if we do connection preprocessing, shouldn't we also do teardown
> in case of timeout?

In the case of timeout no special actions are required, that's point.


Alexey
-
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/

Re: TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7

[bert hubert]

On Sun, Oct 22, 2000 at 05:33:53PM +0400, [EMAIL PROTECTED] wrote:

> About uglyness. Violations of protocol are ugly. When all
> the things proceed in a legal way undistingushable,
> it is beautiful. 8)

Ok, I'm convinced. The only thing I don't like is that to untrained
observers, the repeated SYNACKs suggest packet loss, but I guess we'll have
to live with that.

Thanks again for the explanation. The manpage patch remains correct, so
Andries, please apply.

Regards,

bert hubert

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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/

Re: getting module symbols into ksyms

[Jerry Kelley]

Yes, I know about the HTML crap. I realized after I sent it what I had done
and knew I'd get flack about it.

Regarding the issue, I'm using 2.2.14-5.0. I'll have to check version of
ksymoops and modutils.

It's too bad that a seemingly simple question like this ends up being so
complicated. I'll get the details.

- Original Message -
From: "Keith Owens" <[EMAIL PROTECTED]>
To: "Jerry Kelley" <[EMAIL PROTECTED]>
Cc: "linux kernel" <[EMAIL PROTECTED]>
Sent: Saturday, October 21, 2000 9:11 PM
Subject: Re: getting module symbols into ksyms


> On Sat, 21 Oct 2000 10:41:08 -0500,
> "Jerry Kelley" <[EMAIL PROTECTED]> wrote:
> >I'm trying to debug the oops that my module is generating. When I use =
> >ksymoops on the oops text I get a warning saying that the module is in =
> >lsmod but is not found in ksyms. I have two questions:
>
> Please send in plain text instead of quoted printable+HTML, it uses
> less bandwidth for exactly the same result.  Tools, Options, Send, set
> Mail send for Plain text.
>
> You provided zero details about your system, no indication of which
> kernel, modutils or ksymoops you are running.  So the only help that
> can be provided is to tell you to upgrade to the latest modutils and
> ksymoops[*] and try again.  If you still have a problem, provide
> details next time.
>
> [*] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3
> ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3
>

-
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/

Re: getting module symbols into ksyms

[Jerry Kelley]

kernel = 2.2.14-5.0 for i686 UP
insmod reports version 2.3.10-pre1
ksymoops is 0.7c

If the insmod version is not the same as modutils some guidance on finding
the modutils version would be appreciated. (The system installed is the
RedHat 6.2 distribution.)

Thanks in advance.

Jerry

- Original Message -
From: "Keith Owens" <[EMAIL PROTECTED]>
To: "Jerry Kelley" <[EMAIL PROTECTED]>
Cc: "linux kernel" <[EMAIL PROTECTED]>
Sent: Saturday, October 21, 2000 9:11 PM
Subject: Re: getting module symbols into ksyms


> On Sat, 21 Oct 2000 10:41:08 -0500,
> "Jerry Kelley" <[EMAIL PROTECTED]> wrote:
> >I'm trying to debug the oops that my module is generating. When I use =
> >ksymoops on the oops text I get a warning saying that the module is in =
> >lsmod but is not found in ksyms. I have two questions:
>
> Please send in plain text instead of quoted printable+HTML, it uses
> less bandwidth for exactly the same result.  Tools, Options, Send, set
> Mail send for Plain text.
>
> You provided zero details about your system, no indication of which
> kernel, modutils or ksymoops you are running.  So the only help that
> can be provided is to tell you to upgrade to the latest modutils and
> ksymoops[*] and try again.  If you still have a problem, provide
> details next time.
>
> [*] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3
> ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3
>

-
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/

Re: question wrt context switching during disk i/o

[Anton Blanchard]

 
> bdflush is broken in current kernels.  I posted to linux-mm about this,
> but Rik et al haven't shown any interest.  I normally see bursts of 
> up to around 40K cs/second when doing writes; I hacked a little 
> premption counter into the kernel and verified that they're practially
> all bdflush...

I found that during a dbench run we were calling bdflush to synchronously
flush out buffers too early. Changing nfract in /proc/sys/vm/bdflush from
40 to 100 improved this a lot.

Looking at the code we seem to be doubling the number of dirty buffers
(dirty *= 200). Can someone explain this?

Anton

int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
int shortage;

dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();

dirty *= 200;
soft_dirty_limit = tot * bdf_prm.b_un.nfract;
hard_dirty_limit = soft_dirty_limit * 2;

/* First, check for the "real" dirty limit. */
if (dirty > soft_dirty_limit) {
if (dirty > hard_dirty_limit)
return 1;
return 0;
}


-
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/

Idea for new kernel configurator

[Jason Hihn]

First let me introduce myself and explain where I am coming from. I'm a
just out of college software engineer, I've been using Linux since about
1994. I hope this is the right place to air this idea. I've never
dabbled in the kernel other than applying some patches. Recently at work
I've had to develop an application which would allow a user to configure
a device, even if that device was invented after the application was
written. This is done extracting information (an XML file) out of the
device which allows the software to create an interface for configuring
the device... and that's where my idea comes from.
(Quick, someone document this before it is patented!)

If the linux kernel was represented by XML objects in documents, then
the same idea as above could be applied and extended. The user interface
could be 2 windows, one 'in-the-kernel' pool and one 'not-in-the-kernel'
pool. (I am thinking either icons, like folders, or trees) to add
something into the kernel, just drag and drop, to take something out
drag and drop. To configure parameters right click and select stuff off
of a context menu, or pop up a property page.

The advantages of this are:
1) If carefully abstracted, the same software could be used not only for
the kernel but other software things as well (PHP (--with-mysql,
--with-postgres would be drag and dropable features), etc) Which
would provide a familiar, consistent interface

2) My mother could configure and build the kernel with very little
instruction (She'd probably have to phone-a-friend though)

3) It's conceptually ideal. In the kernel, out of the kernel. Property
sheets to adjust params, etc.

4) Installing patches could be done as well. Either another Patches
window, or the functionality could be enabled at the proper software
module.

5) The application [sh|c]ould handle the build/install process and give
a status bar.

6) It allows me to contribute something and give back to the community
that has given me so much.

7) Even if the kernel people do not decide to XML describe the kernel,
it would be possible by a 3rd party to apply the XML documents to the
tree and allow people to use such a tool.

The down sides are: (few)
1) Graphical display required.

2) Patch contributors now need to make an additional XML file

3) how are overlapping patches handle?

As a final note, I regret to say I don't have time to actually code such
a project at this time, but I'd like to help as much as I can.

I submit this idea for your approval and critique
(Has it already been done?? - not to my knowledge)


-
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/

2.4.0-test9 Total freeze with LPRng-3.6.26

[Meino Christian Cramer]

hi,

 I got a total freeze, while trying the command 'lpr example_textfile.txt' on
 a machine with no attached printer.
 Unfortunately there was no log according to this.

 I am using LPRng-3.6.26 with Linux-2.4.0-test9.

 If I can help to gather additional informations, please give me a
 hint, how to achieve this.

 Kind regards,
 Meino
 

-
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/

Re: USB problem in 2.2.18pre17

[Greg KH]

On Sun, Oct 22, 2000 at 12:53:26PM +0200, Hans-Joachim Baader wrote:
> Hi Greg,
> 
> > > my digital camera (Kodak DC 280) doesn't work with USB in 2.2.18pre17
> > > (and previos kernels). It did work with 2.4.0-test9. Here's the log:
> > 
> > What is the BIOS setting of MPS?  If it's 1.4, please try 1.1
> > 
> > Let me know if this helps out any.
> 
> With 1.1 it works great. Can you fix this to work with 1.4 too?

Sorry, but that's the pci and interrupt handling sections of the kernel
from what I can tell, and that probably isn't going to be changed for
2.2.x.  If you really want MPS 1.4, you will have to stick with the
2.4.x kernel.

Glad it's working now.

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
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/

Re: linux-2.4.0-test9

[Akira YOSHIYAMA]

Hi all ,

At first, thank you Jeff Garzik for your advise. I added 
debug infomations to apm.c and have tried it. See below:

(APM driver enabled and output tons of debug messages)...
apm_do_idle(): line 564
apm_bios_call_simple(): line 484
..

(and yenta driver was loaded and it proved pcmcia sockets)
apm_do_idle(): line 564
apm_bios_call_simple(): line 484
...
apm_do_idle(): line 564
apm_bios_call_simple(): line 484
apm_do_busy(): line 580
apm_bios_call_simple(): line 484
apm_event_handler(): line 1096
check_events(): line 998
get_event(): line 980
apm_get_event(): line 531
apm_bios_call(): line 449

apm_get_info(): line 1381
apm_get_power_status(): line 708
apm_bios_call(): line 449

(System hangs. It didn't accept any kernel-sysrq request,
 perhaps because of hardware lock-up.)

I think I need to add some debug infomation to yenta driver.
Anyone comments? Have you used yenta driver and apm driver
with no problem?

Thanks,

A.Yoshiyama
[EMAIL PROTECTED]



-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux mobile2 2.4.0-test9 #1 Mon Oct 9 00:15:50 JST 2000 i686 unknown
Kernel modules 2.3.16
Gnu C  2.95.2
Binutils   2.10.0.26
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount  2.10o
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0i
Modules Loaded ide-cs pcnet_cs 8390 ds yenta_socket pcmcia_core rtc nls_cp932 
esssolo1 soundcore vfat fat autofs4

No Subject

[Tulika Pradhan]

hi !


i need to use ramdisk for root for my embedded linux ppc board.
is there some way that i can combine the images vmlinux and ramdisk
image so that they cn be loaded by the bootloader as a single image ?
the reason i need this is because i am using a existing loader which can
simply download the image and execute it.

please cc the reply to my email as i am not on the mailing list.

regards,

tulika



_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

-
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/

kernel BUG at vmscan.c:102!

[Richard Torkar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Doing some heavy i/o on my 2.4.0-test10 (rar) while downloading at
10Mb/s at the same time resulted in this:

Oct 22 20:03:38 toor kernel: kernel BUG at vmscan.c:102!
Oct 22 20:03:38 toor kernel: invalid operand: 
Oct 22 20:03:38 toor kernel: CPU:1
Oct 22 20:03:38 toor kernel: EIP:0010:[try_to_swap_out+250/768]
Oct 22 20:03:38 toor kernel: EFLAGS: 00010286
Oct 22 20:03:38 toor kernel: eax: 001c   ebx: 4f00   ecx: c12e6000 edx: 
0021
Oct 22 20:03:38 toor kernel: esi: c11d96a0   edi: 06f64045   ebp: 4f00 esp: 
c12e7e88
Oct 22 20:03:38 toor kernel: ds: 0018   es: 0018   ss: 0018
Oct 22 20:03:38 toor kernel: Process kswapd (pid: 2, stackpage=c12e7000)
Oct 22 20:03:38 toor kernel: Stack: c0219ae5 c0219ce4 0066 0001  
40081000 c7424200 4007f000
Oct 22 20:03:38 toor kernel:40081000 c012cdaf c784c3e0 c7833a60 4008 
c7424200 0004 c78ce400
Oct 22 20:03:38 toor kernel:40081000 40081000 c78ce400 0011 c010c430 
0001 c02a1050 000b
Oct 22 20:03:38 toor kernel: Call Trace: [tvecs+7101/66488] 
[swap_out_vma+287/432] [handle_IRQ_event+96/144] [do_softirq+109/160] [do_IRQ+231/256] 
[swap_out_mm+76/128]

ver_linux output:

[toor@/usr/src/linux/scripts]$ sh ver_linux
- -- Versions installed: (if some fields are empty or look
- -- unusual then possibly you have very old versions)
Linux toor 2.4.0-test10 #2 SMP Thu Oct 19 10:30:23 CEST 2000 i686 unknown
Kernel modules 2.3.14
Gnu C  2.96
Gnu Make   3.79.1
Binutils   2.10.0.18
Linux C Library2.1.94
Dynamic linker ldd (GNU libc) 2.1.94
Procps 2.0.7
Mount  2.10m
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded mga 3c59x opl3 sb sb_lib uart401 sound soundcore

Standard RH 7.0 with all updates applied.


Any more info needed? If so just ask :) 

I don't have the right modutils but on the other hand some how I don't
think that's the problem.



/Richard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Made with pgp4pine 1.75-6

iD8DBQE58y1pUSLExYo23RsRAmVGAKDK/Whq3a9VHbfysdA8b0KSS1lFLACgxTUx
u9NQzrFESfIk5BKgKeBNhM0=
=vRyy
-END PGP SIGNATURE-


-
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/

Crash on boot with 2.4.0-test10-pre4

[Jon Akers]

This problem presented itself on boot, and occurred after the system had
frozen on me. I watched the system freeze in the first place (Netscape
crashed it, I believe)

Current system configuration is as follows:

AMD K6-200 w/ 64MB RAM, Adaptec 2930 Ultra-SCSI.

GCC version: egcs-2.91.66
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: c116beb4
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 2, stackpage=116b000)
Stack: c01c9865 c01c9a24 0066 40104000 c11dc080 40103000 40108000
c01f90b0
    c01265bb c11dc080 c11da3e0 40103000 c11d840c 0004
40103000
   c11da3e0 c11dc080 0004 c11d840c 40503000 c11db400 40108000
40108008
Call Trace: [] [] [] []
[] [] []
 [] [] [] []
Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 24 9a 1c c0


-
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/

Re: TRACED] Re: "Tux" is the wrong logo for Linux

[Mark H. Wood]

On Thu, 19 Oct 2000, Richard B. Johnson wrote:
[snippage]
> Cary, NC. can't be very large. There are, probably, three persons in
> the whole county than have computers. Two haven't been booted since
> the day the were received by the kids because they've been busy
> studying for the M-CAP test.

The home of SAS Institute?  You're kidding, right?

-- 
Mark H. Wood, Lead System Programmer   [EMAIL PROTECTED]
The AVR menu said, "if you are running Novell, press 4."  Eric Schmidt
is running Novell; the rest of us are running Netware.

-
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/

[PATCH] 2.2.18pre17 updates to IDE-floppy driver

[Paul Bristow]

Andre, Alan, others,

As agreed with Gadi and Andre I have taken over the ide-floppy driver
maintainence from Gadi Oxman (thanks for all your work so far Gadi!). 
Anyone with outstanding patches/suggestions etc could you send them to
me?

Please find attached the patch to update the IDE-Floppy driver to
include IOMEGA Clik! (or PocketZip) support.  This patch applies cleanly
to 2.2.17 and 2.2.18pre17.  Details on how to use the Clik! drive with
this patch are available at http://paulbristow.net/linux/clik.html

This updated driver has been tested as a module and compiled in, and the
Clik! mods did not break my LS-120 drive. 

I also include a patch to the CREDITS and MAINTAINERS file so people
know where to reach me.

Now to get it working in 2.4...

Regards,

-- 

Paul

Email: [EMAIL PROTECTED] 
(NOTE: change from [EMAIL PROTECTED] as mail.com unreliable)
Web: http://paulbristow.net
ICQ: #11965223

diff -u -b --exclude='*.o' --exclude='.*' --exclude='*.a' --exclude=System.map 
linux-2.2.17/CREDITS linux-2.2.17-pb/CREDITS
--- linux-2.2.17/CREDITSMon Sep  4 19:39:15 2000
+++ linux-2.2.17-pb/CREDITS Sun Oct 22 15:56:46 2000
@@ -290,6 +290,11 @@
 S: Lancaster, LA1 4DN
 S: UK, England
 
+N: Paul Bristow
+E: [EMAIL PROTECTED]
+W: http://paulbristow.net/linux
+D: ide-floppy maintainer
+
 N: Andries Brouwer
 E: [EMAIL PROTECTED]
 D: random Linux hacker
Common subdirectories: linux-2.2.17/Documentation and linux-2.2.17-pb/Documentation
diff -u -b --exclude='*.o' --exclude='.*' --exclude='*.a' --exclude=System.map 
linux-2.2.17/MAINTAINERS linux-2.2.17-pb/MAINTAINERS
--- linux-2.2.17/MAINTAINERSMon Sep  4 19:39:16 2000
+++ linux-2.2.17-pb/MAINTAINERS Sun Oct 22 19:55:27 2000
@@ -446,12 +446,19 @@
 L: [EMAIL PROTECTED]
 S: Maintained
 
-IDE/ATAPI TAPE/FLOPPY DRIVERS
+IDE/ATAPI TAPE DRIVERS
 P: Gadi Oxman
 M: Gadi Oxman <[EMAIL PROTECTED]>
 L: [EMAIL PROTECTED]
 S: Maintained
 
+IDE/ATAPI FLOPPY DRIVERS
+P: Paul Bristow
+M: Paul Bristow <[EMAIL PROTECTED]>
+W:  http://paulbristow.net/linux
+L: [EMAIL PROTECTED]
+S: Maintained
+
 IP FIREWALL
 P: Paul Russell
 M: [EMAIL PROTECTED]
Common subdirectories: linux-2.2.17/arch and linux-2.2.17-pb/arch
Common subdirectories: linux-2.2.17/drivers and linux-2.2.17-pb/drivers
Common subdirectories: linux-2.2.17/fs and linux-2.2.17-pb/fs
Common subdirectories: linux-2.2.17/include and linux-2.2.17-pb/include
Common subdirectories: linux-2.2.17/init and linux-2.2.17-pb/init
Common subdirectories: linux-2.2.17/ipc and linux-2.2.17-pb/ipc
Common subdirectories: linux-2.2.17/kernel and linux-2.2.17-pb/kernel
Common subdirectories: linux-2.2.17/lib and linux-2.2.17-pb/lib
Common subdirectories: linux-2.2.17/mm and linux-2.2.17-pb/mm
Common subdirectories: linux-2.2.17/modules and linux-2.2.17-pb/modules
Common subdirectories: linux-2.2.17/net and linux-2.2.17-pb/net
Common subdirectories: linux-2.2.17/scripts and linux-2.2.17-pb/scripts
Binary files linux-2.2.17/vmlinux and linux-2.2.17-pb/vmlinux differ


--- linux-2.2.17/drivers/block/ide-floppy.c Mon Sep  4 19:39:16 2000
+++ linux-2.2.17-pb/drivers/block/ide-floppy.c  Sun Oct 22 20:30:10 2000
@@ -2,6 +2,7 @@
  * linux/drivers/block/ide-floppy.cVersion 0.9 Jul   4, 1999
  *
  * Copyright (C) 1996 - 1999 Gadi Oxman <[EMAIL PROTECTED]>
+ * Copyright (C) 2000Paul Bristow <[EMAIL PROTECTED]>
  */
 
 /*
@@ -29,9 +30,14 @@
  * Ver 0.9   Jul  4 99   Fix a bug which might have caused the number of
  *bytes requested on each interrupt to be zero.
  *Thanks to <[EMAIL PROTECTED]> for pointing this out.
+ * Ver 0.91  Dec 11 99   Added IOMEGA Clik! drive support by 
+ *   <[EMAIL PROTECTED]>
+ * Ver 0.92  Oct 22 00   Paul Bristow became official maintainer for this i
+ *   driver.  Included Powerbook internal zip kludge.
+ *   
  */
 
-#define IDEFLOPPY_VERSION "0.9"
+#define IDEFLOPPY_VERSION "0.92"
 
 #include 
 #include 
@@ -60,6 +66,7 @@
  */
 #include "ide.h"
 
+
 /*
  * The following are used to debug the driver.
  */
@@ -1205,6 +1212,15 @@
idefloppy_flexible_disk_page_t *page;
int capacity, lba_capacity;
 
+/* Inserted by Paul Bristow
+ *  The IOMEGA Clik! drive does not support this command
+ *  so I removed it and fake the important parameters.  
+ *  This does not appear to have any major side effects,
+ *  so I hope everything is OK.
+ */
+if (!strstr(drive->id->model,"Clik")) {
+
+
idefloppy_create_mode_sense_cmd (&pc, IDEFLOPPY_FLEXIBLE_DISK_PAGE, 
MODE_SENSE_CURRENT);
if (idefloppy_queue_pc_tail (drive,&pc)) {
printk (KERN_ERR "ide-floppy: Can't get flexible disk page 
parameters\n");
@@ -1235,6 +1251,16 @@
capacity = IDEFLOPPY_MIN(capacity, lba_capacity);
floppy->bloc

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Dr. Kelsey Hudson]

> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
> 
> 
> --
>   Mike A. Harris  -  Linux advocate  -  Open source advocate
>   Computer Consultant - Capslock Consulting
>  Copyright 2000 all rights reserved
> --

Apparently Linus doesn't like the way it handles interrupts or something,
and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
use it ;p

 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
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/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Mike A. Harris]

On Sun, 22 Oct 2000, Dr. Kelsey Hudson wrote:

>Date: Sun, 22 Oct 2000 13:39:09 -0700 (PDT)
>From: Dr. Kelsey Hudson <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: David Woodhouse <[EMAIL PROTECTED]>,
> Linux Kernel mailing list <[EMAIL PROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3
>
>> Is there a major compelling reason that this patch isn't included
>> in the standard kernel tree?
>> 
>> 
>> --
>>   Mike A. Harris  -  Linux advocate  -  Open source advocate
>>   Computer Consultant - Capslock Consulting
>>  Copyright 2000 all rights reserved
>> --
>
>Apparently Linus doesn't like the way it handles interrupts or something,
>and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
>use it ;p

Someone has explained to me why it isn't included, and it made
decent sense to me.  Probably best left as a patch...


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

#[Mike A. Harris bash tip #1 - separate history files per virtual console]
# Put the following at the bottom of your ~/.bash_profile
[ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir
tty |grep "^/dev/tty[0-9]" >& /dev/null && \
export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///')

-
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/

Kernel 2.2.17 with RedHat 7 Problem !

[Hamid Hashemi Golpayegani]

Hi ,

I have download kernel-2.2.17 from kernel.org and wanna to compile it under
redhat 7 . when compiling start after few minutes show me this error message
:

make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
raditional -c checksum.S -o checksum.o
checksum.S:231: badly punctuated parameter list in #define
checksum.S:237: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2

I have install this kernel with same setting on RedHat 6.2 without any
problem !
Any idea ?

Thank You
Hamid Hashemi

-
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/

IDE-Floppy and devfs

[Andreas Franck]

Hi Paul, hi linux-kernel audience,

some szggestion for the upcoming 2.4 release ide-floppy driver: It
really works
nice without devfs, but the ide-floppy behaviour in connection with
devfs is
a bit strange.

If ide-floppy is compiled as a module, which is loaded (or autoloaded by
some smart 
devfs rule) when no disk is in the drive, NO devfs entries are created,
so there
is no way to access the drive. Even worse, when a disk is inserted, the
module is
still loaded so there is no way to access the disk! Only manual
unloading and reloading
of the module will do the trick.

I'd suggest something like the cdrom approach: There is always one
device node for
removable devices, regardless of any media present in the drive. This
could
be /dev/ide/host0/bus1/target1/lun0/floppy or something like that. 

Accessing this file should trigger a probe for the media (which may be
partitioned
in ide-floppy devices, which makes life a bit harder). By this probe,
the 
/dev/ide/.../lun0/disc and /dev/ide/.../lun0/part4 (or any other
partitions) 
might be created, if there is a medium in the drive; a symlink to the
"right" partition
(part4 for normal ZIP disks, AFAIK) shhould be placed in a directory of
its own,
for example /dev/ide/floppy/c0b1t1u0, and anotherone perhaps in
/dev/idefloppy/floppy0
or something.

I have already implemented the first half of this (creation of the
floppy node which will
trigger the partition scan when accessed), I have attached my patch for
review here.
Its still quite hackish, but I'm sure you can follow my ideas with what
I explained above
- if not, don't hesitate to ask.

->- snip -<-

-- 
->>>--- Andreas Franck <<<-
---<<< [EMAIL PROTECTED] --->>>---
->>> Keep smiling! <<<-
-
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/

oops when doing stupid thing

[FORT David]

Hi, i got the following oops, to obtain it i've done something stupid:
i'm using quite frequently a serial console, today my computer was
already running,
i've unplugged the serial console and have plugged a modem instead, and
then the oops.
That's not really a bad oops as it takes me 20 minutes to figure. I'd
rather say that it's me
who is stupid, but may my stupidy lead to an oops ?

Oct 22 18:23:33 Djinn kernel: NMI Watchdog detected LOCKUP on CPU1,
registers:
Oct 22 18:23:33 Djinn kernel: CPU:1
Oct 22 18:23:33 Djinn kernel: EIP:0010:[serial_in+55/60]
Oct 22 18:23:33 Djinn kernel: EFLAGS: 0022
Oct 22 18:23:33 Djinn kernel: eax: 0301   ebx: 000a535f   ecx:
001e   edx: 03fd
Oct 22 18:23:33 Djinn kernel: esi: c026e34b   edi: c027fa80   ebp:
c026e34c   esp: c4001f54
Oct 22 18:23:33 Djinn kernel: ds: 0018   es: 0018   ss: 0018
Oct 22 18:23:33 Djinn kernel: Process cc1 (pid: 2247,
stackpage=c4001000)
Oct 22 18:23:33 Djinn kernel: Stack: c01788b8 c027fa80 0005 c0226700
001b c026e346 c026e361 0006
Oct 22 18:23:33 Djinn kernel:0005 c0119053 c0226700 c026e346
001b  002c 
Oct 22 18:23:33 Djinn kernel:0862b138 00200082 0001 c026e361
001e c01114bf c01e74a0 0001
Oct 22 18:23:33 Djinn kernel: Call Trace: [serial_console_write+92/308]
[printk+291/368] [smp_error_interrupt+67/72]
[call_spurious_interrupt+12800/31336] [call_error_interrupt+5/12]
Oct 22 18:23:33 Djinn kernel: Code: 0f b6 c0 c3 90 53 8b 54 24 08 8b 44
24 0c 8b 5c 24 10 83 7a
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f b6 c0  movzbl %al,%eax
Code;  0003 Before first symbol
   3:   c3ret
Code;  0004 Before first symbol
   4:   90nop
Code;  0005 Before first symbol
   5:   53push   %ebx
Code;  0006 Before first symbol
   6:   8b 54 24 08   mov0x8(%esp,1),%edx
Code;  000a Before first symbol
   a:   8b 44 24 0c   mov0xc(%esp,1),%eax
Code;  000e Before first symbol
   e:   8b 5c 24 10   mov0x10(%esp,1),%ebx
Code;  0012 Before first symbol
  12:   83 7a 00 00   cmpl   $0x0,0x0(%edx)


--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière   0240726275 %
% 44470 Thouare, France[EMAIL PROTECTED] %
% ICU:78064991   AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
%  -datamining <-/|   .~. %
%  -networking/flashed PHP3 coming soon   |   /V\L  I  N  U  X%
%  -opensource|  // \\ >Fear the Penguin< %
%  -GNOME/enlightenment/GIMP  | /(   )\   %
%   feel enlighted|  ^^-^^%
%   http://ibonneace.dnsalias.org/ when connected %
%-%



-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

Hamid,

RedHat includes two versions of gcc.  gcc-2.96 is a developmental snapshot 
of the compiler project and is not able to build a kernel.  Also included 
is kgcc, as in KernelGCC, which is what you should be using.  If you don't 
have the kgcc...rpm installed, install that and use it.

David

At 04:54 PM 10/22/00, Hamid Hashemi Golpayegani wrote:
>Hi ,
>
>I have download kernel-2.2.17 from kernel.org and wanna to compile it under
>redhat 7 . when compiling start after few minutes show me this error message
>:
>
>make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
>gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
>raditional -c checksum.S -o checksum.o
>checksum.S:231: badly punctuated parameter list in #define
>checksum.S:237: badly punctuated parameter list in #define
>make[2]: *** [checksum.o] Error 1
>make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make[1]: *** [first_rule] Error 2
>make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make: *** [_dir_arch/i386/lib] Error 2
>
>I have install this kernel with same setting on RedHat 6.2 without any
>problem !
>Any idea ?
>
>Thank You
>Hamid Hashemi
>
>-
>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/


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
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/

Re: Crash on boot with 2.4.0-test10-pre4

[Tigran Aivazian]

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 line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: oops when doing stupid thing

[FORT David]

FORT David wrote:

> Hi, i got the following oops, to obtain it i've done something stupid:
> i'm using quite frequently a serial console, today my computer was
> already running,
> i've unplugged the serial console and have plugged a modem instead, and
> then the oops.
> That's not really a bad oops as it takes me 20 minutes to figure. I'd
> rather say that it's me
> who is stupid, but may my stupidy lead to an oops ?
>
> Oct 22 18:23:33 Djinn kernel: NMI Watchdog detected LOCKUP on CPU1,
> registers:
> Oct 22 18:23:33 Djinn kernel: CPU:1
> Oct 22 18:23:33 Djinn kernel: EIP:0010:[serial_in+55/60]
> Oct 22 18:23:33 Djinn kernel: EFLAGS: 0022
> Oct 22 18:23:33 Djinn kernel: eax: 0301   ebx: 000a535f   ecx:
> 001e   edx: 03fd
> Oct 22 18:23:33 Djinn kernel: esi: c026e34b   edi: c027fa80   ebp:
> c026e34c   esp: c4001f54
> Oct 22 18:23:33 Djinn kernel: ds: 0018   es: 0018   ss: 0018
> Oct 22 18:23:33 Djinn kernel: Process cc1 (pid: 2247,
> stackpage=c4001000)
> Oct 22 18:23:33 Djinn kernel: Stack: c01788b8 c027fa80 0005 c0226700
> 001b c026e346 c026e361 0006
> Oct 22 18:23:33 Djinn kernel:0005 c0119053 c0226700 c026e346
> 001b  002c 
> Oct 22 18:23:33 Djinn kernel:0862b138 00200082 0001 c026e361
> 001e c01114bf c01e74a0 0001
> Oct 22 18:23:33 Djinn kernel: Call Trace: [serial_console_write+92/308]
> [printk+291/368] [smp_error_interrupt+67/72]
> [call_spurious_interrupt+12800/31336] [call_error_interrupt+5/12]
> Oct 22 18:23:33 Djinn kernel: Code: 0f b6 c0 c3 90 53 8b 54 24 08 8b 44
> 24 0c 8b 5c 24 10 83 7a
> Using defaults from ksymoops -t elf32-i386 -a i386
>
> Code;   Before first symbol
>  <_EIP>:
> Code;   Before first symbol
>0:   0f b6 c0  movzbl %al,%eax
> Code;  0003 Before first symbol
>3:   c3ret
> Code;  0004 Before first symbol
>4:   90nop
> Code;  0005 Before first symbol
>5:   53push   %ebx
> Code;  0006 Before first symbol
>6:   8b 54 24 08   mov0x8(%esp,1),%edx
> Code;  000a Before first symbol
>a:   8b 44 24 0c   mov0xc(%esp,1),%eax
> Code;  000e Before first symbol
>e:   8b 5c 24 10   mov0x10(%esp,1),%ebx
> Code;  0012 Before first symbol
>   12:   83 7a 00 00   cmpl   $0x0,0x0(%edx)

I'm quoting myself, i forgot to tell that it was using 2.4.0test10-pre4,

with vmscan BUG corrected.

--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière   0240726275 %
% 44470 Thouare, France[EMAIL PROTECTED] %
% ICU:78064991   AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
%  -datamining <-/|   .~. %
%  -networking/flashed PHP3 coming soon   |   /V\L  I  N  U  X%
%  -opensource|  // \\ >Fear the Penguin< %
%  -GNOME/enlightenment/GIMP  | /(   )\   %
%   feel enlighted|  ^^-^^%
%   http://ibonneace.dnsalias.org/ when connected %
%-%



-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:24:32AM +0330, Hamid Hashemi Golpayegani wrote:
> Hi ,
> 
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :

Due to bugs in the Linux kernel, it may only be compiled by certain versions
of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
(linux/Documentation/Changes). 

Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
distributions are beginning to ship GCC 2.95 and later. Those distributions
typically include an alternative gcc for compiling the kernel. RedHat has
kgcc, and you should compile the kernel with that.

You might want to take this opportunity to rethink your decision to 'upgrade'
your distributions kernel. Most distributions (including RedHat) ship
patched kernels that include features and fixes not in the Linus kernels
in order to better fit their users needs. If you install 2.2.17, you will
lose: AGP support, USB support, greatly improved raid and NFS, and many other
things. 

Any bug fixes that are in 2.2.17 have probably already been applied to your
stock kernel.

(Alan has a 2.2.18pre that has most of these things included)

You will likely get the best support and stability from the kernel the
distributor recommends you run.

If you are going to upgrade, you should at least consider going to
2.4.0test-flavor-of-week, so that your crashes will at least contribute to
Linux development. :)
-
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/

Re: AMD CPU misdetection?

[Andreas Eibach]

- Original Message - 
From: "Vince Weaver" <[EMAIL PROTECTED]>

> A plain K6:
>model   : AMD-K6tm w/ multimedia extensions
> 
> A K6-2:
>model name  : AMD-K6(tm) 3D processor
> 
> A K6-3:
>model name  : AMD-K6(tm) 3D+ Processor
> 
> A K6-2+:
>   model name  : AMD-K6(tm)-III Processor
[...]
> It tends to be confusing, but the value you get is proper for your chip.

Yes, this is really confusing ;)) (in different sense)

Vince, wasn't it supposed to be

 A K6-2+:
model name  : AMD-K6(tm) 3D+ Processor 

 A K6-3:
   model name  : AMD-K6(tm)-III Processor

This would make a lot more sense.

:-)
 just my 0.02 euro
 Andreas

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jurgen Kramer]

Hi,

You can blame it on the compiler which is included with RH7.0. It's a
pre-release version of
some sort. It seems that the gcc people are not happy that RH included this
version with RH7.

Cheers,

Jurgen


Hamid Hashemi Golpayegani wrote:

> Hi ,
>
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :
>
> make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
> gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
> raditional -c checksum.S -o checksum.o
> checksum.S:231: badly punctuated parameter list in #define
> checksum.S:237: badly punctuated parameter list in #define
> make[2]: *** [checksum.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
> make: *** [_dir_arch/i386/lib] Error 2
>
> I have install this kernel with same setting on RedHat 6.2 without any
> problem !
> Any idea ?
>
> Thank You
> Hamid Hashemi
>
> -
> 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/

-
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/

Re: [PATCH] cpu detection fixes for test10-pre4

[Pavel Machek]

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 should never have used anything but "i386" as the utsname... sigh.

We stil can do that: make 2.4.0 use i386 for utsname on all x86 machines
(except x86-64 ;-), and let people adapt.
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
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/

Re: Proposal: driver initialization pipelining

[Pavel Machek]

Hi!

> There ought to be _some_ initializations that don't require interrupts?
> Registering the file systems and network protocols, stuff like that?

Give up on IDE, it is too broken.

You should get away with paralelising USB and SCSI scan.

Perhaps you can speed boot up with initrd+modules, possibly improving module
inits (but they are probably good enough). With modules, I can imagine 
USB+SCSI scans running in paralel.
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 22:54:32 Hamid Hashemi Golpayegani wrote:
> Hi ,
> 
> I have download kernel-2.2.17 from kernel.org and wanna to compile it under
> redhat 7 . when compiling start after few minutes show me this error message
> :
> 
> make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
> gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
> raditional -c checksum.S -o checksum.o
> checksum.S:231: badly punctuated parameter list in #define
> checksum.S:237: badly punctuated parameter list in #define

It seems to be a silly bug in 2.96 cpp. If your distro has something called kgcc
or egcs, install it and configure the kernel to be built with it (in main
Makefile
and in arch/i386/Makefile).

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
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/

Re: [Criticism] On the discussion about C++ modules

[Horst von Brand]

"Linux Kernel Developer" <[EMAIL PROTECTED]> said:
> Wasn't the original complaint that the kernel headers use C++ keyword
> and thus prevent the writing of, at least some, modules in C++.  I have
> written C++ code before that was as least as fast as comparable C code and
> more efficient in some ways.  Whether this could be or not be reproduced in
> kernel code I do not know.  So far I have done my kernel programming in C.
> However even if I or other programmers would like to give this a try it is
> my understanding we cannot because of the header situation.  I think it is
> unfair to attack C++ kernel code that is unable to come into existence, at
> least without jumping through a bunch of hoops, due to external influences
> (i.e. the incompatible headers).

The "incompatible headers" can be cured mostly with just:

extern "C" {
#define new header_new
#define ...
#include 
#undef new
#undef ...
}

If they can't go this far, or create a local patch for the offending
headers (perhaps even suggesting it for inclusion) I don't see why they
should even be considered, not to mention taken seriously...

> On a separate note.  Isn't one of the philosophies behind Linux the idea
> of freedom. 

"Freedom" as in "you are free to do what you want" and "you are free to
suggest whatever you want". Not free as in "feel free to suggest anything,
we'll bend over backwards to please you".

>  If people wish to try and program their modules in C++ for
> whatever reason, be it porting from existing code or to object orient their
> code, should they be free to do so.

Linux _is_ object-oriented. Much more so than most C++ programs I've seen.

> If the header situation is true, which
> I am not sure of since I have not tried to do C++ programming in kernel
> code, then people aren't free to write modules however they wished.

But they are! It is just a fact of Linux that by writing them in plain C it
is easier to do than in C++, FORTRAN or Emacs LISP. You can't expect the
head kernel hackers to devote their (precious, and probably way too little)
hacking time to create this kind of infrastructure for the lazy few.

> Seeing
> as fixing the headers should be rather trivial and probably is the right
> thing to do anyway (using existing language keywords is a bad idea) I do not
> see why this same flame war must erupt every time the header situation is
> brought up.

Fix it, send in a patch and get over it. Given your email address, this
should be a no-brainer for you.  At the very least, such a patch will
(hopefully) stop this nonsense.

>  Its not as if C++ code would all of the sudden popup in the
> kernel core forcing everybody to use C++.  At best a driver here and there
> might start using it and its continual usage would depend on if its
> implementation is successful or not.  And those drivers themselves are
> extremely likely to be self-contained thus not affecting anybody else's
> kernel code.

I'd prefer the kernel staying plain C, with no admixtures. Just MHO, of
course. What somebody else does in the privacy of their own trees is their
bussiness, as always.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: freeing memory

[Horst von Brand]

[EMAIL PROTECTED] said:
> i am allocating some 1000 bytes of memory as folows
> 
> f_malloc()
> {
>  .
>  for (i=1 to 10)
>  {
>  size = 1000;
>  pAddr[i] = (unsigned long) kmalloc(size, GFP_DMA | GFP_BUFFER);
>  }
>  ...
> }

You don't check if you got the memory (GFP_DMA is _hard_ to get)
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
> 
> Due to bugs in the Linux kernel, it may only be compiled by certain versions
> of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> (linux/Documentation/Changes). 

"Bugs" in the kernel are related with things like supposing that the compilers 
makes things (such as alignment or padding in structs) in certain way, that 
could be done in any other way, but are done 'that' way in gcc.

> Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
> distributions are beginning to ship GCC 2.95 and later. Those distributions
> typically include an alternative gcc for compiling the kernel. RedHat has
> kgcc, and you should compile the kernel with that.
>
I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
2.96 what is broken.

> You might want to take this opportunity to rethink your decision to 'upgrade'
> your distributions kernel. Most distributions (including RedHat) ship
> patched kernels that include features and fixes not in the Linus kernels
> in order to better fit their users needs. If you install 2.2.17, you will
> lose: AGP support, USB support, greatly improved raid and NFS, and many other
> things. 
> 
> Any bug fixes that are in 2.2.17 have probably already been applied to your
> stock kernel.
> 
> (Alan has a 2.2.18pre that has most of these things included)
> 

That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
distro with that name. So users can know they are installing 2.2.18-pre, and
not 2.2.17.



-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
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/

Re: interaction between kernel and glibc

[Richard Polton]

So what are these unusual conditions? Why would I not need to recompile?
If the interface changes then glibc will need recompiling and as
far as I can see, the kernel interfaces change relatively often,
particularly in the development tree. Moreover, how does one tell
which kernel the C library was built against anyway?

Thanks,

Richard

Mark Hahn wrote:
> 
> > to the kernel, as I am currently running 2.4.0-test9. The version of
> > glibc is 2.1.3 and was
> > installed via an rpm from rpmfind.net. The symptoms of the problem are
> 
> perhaps you should get the rpm from an official RH mirror.
> I'm running 2.1.3 with no problem at all (on most every dev
> kernel for a long, long time).  perhaps also consider possible
> interaction with other components, such as ld.so, ncurses, etc.
> even hardware, or timekeeping daemons.
> 
> you DEFINITELY do not need to recompile glibc except under
> unusual conditions...
-
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/

Re: getting module symbols into ksyms

[Keith Owens]

On Sun, 22 Oct 2000 10:26:04 -0500, 
"Jerry Kelley" <[EMAIL PROTECTED]> wrote:
>kernel = 2.2.14-5.0 for i686 UP
>insmod reports version 2.3.10-pre1
>ksymoops is 0.7c

Upgrade both modutils and ksymoops, both are well out of date.  Also
kernel 2.2.14 does not have the code to handle symbols if you get an
oops during module initialization, you need at least kernel 2.2.15 for
that.

ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3
ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3

-
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/

Topic for discussion: OS Design

[Dwayne C . Litzenberger]

First of all, I'd like to say that I'm not writing this to piss anyone off.
It's not a flame, a troll, or a personal attack on anyone.   I my writing will
aid in the improvement of Linux.  Please read this with as much neutrality as
you can summon.

Although I am a programmer, I am not yet a kernel hacker, so some of my claims
may be false.  Feel free to correct me.

"Practice what you preach; don't preach what you practice."


A few years ago, there was an intense debate around the question of
cooperative vs. preemptive multitasking operating system design.  Today,
however, cooperative multitasking is a thing of the past, and it is virtually
undisputed that the preemptive multitasking design is highly superior to the
cooperative one.

What's the difference?  Well, operating systems employing cooperative
multitasking are no longer in the mainstream.  There is no longer a need to
pointlessly defend the status quo.

Linux's loadable modules design is insufficient.  I have several reasons for
making this claim:

1. Many things are inaccessible to the modules: There are relatively few
kernel modifications that can be compiled without patching the pristine
sources.

2. The modules API is unstable.  Some people say this is because of the
exceedingly rapid development cycle of Linux.  I beg to differ.  I believe it
is because there is no real planned structure in the API -- just passing
highly volatile internal data structures around.

3. Modules can very easily crash the whole kernel.  This is because each
module does not get to run in its own protected memory space, as it would in a
well-designed microkernel.

4. The kernel HTTPD is just masking a slow networking design.  Yes, I agree
that high-level protocols should be eventually incorporated into a
standardized interface in an operating system.  However, there would be no
need for a kernel-based httpd if the kernel was efficient enough.  This leads
into my next point:

5. Linus tends to blame patches for inadequacies in the kernel.  The PC
speaker driver is a perfect example: No driver should have to do something
"dirty" in order to function, because the operating system should provide
clean ways to do this.


It would seem that a microkernel design would fix most of these problems.  Two
very elegant operating systems, namely the Amiga's exec.library and QNX's
Neutrino (I'm sure you can name others), used microkernels, and they were both
*very* efficient.  However, there are some drawbacks to microkernels that have
been raised (and I don't have the expertise to argue about them), but I think
there are enough intelligent people here that we can come up with a new OS
design that takes the best from both worlds.  This may require a new mailing
list.

So, my question is this:  What are some of Linux's design problems, and what
fundamental changes could be made for a long-run benefit?

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- Please have the courtesy to respond to any requests or questions I may have.
- See the mail headers for GPG/advertising/homepage information.

 PGP signature

Re: 2.4.0-test9 Total freeze with LPRng-3.6.26

[Keith Owens]

On Sun, 22 Oct 2000 18:53:41 +0200, 
Meino Christian Cramer <[EMAIL PROTECTED]> wrote:
> I got a total freeze, while trying the command 'lpr example_textfile.txt' on
> a machine with no attached printer.
> Unfortunately there was no log according to this.
>
> I am using LPRng-3.6.26 with Linux-2.4.0-test9.
>
> If I can help to gather additional informations, please give me a
> hint, how to achieve this.

Apply the kernel debugger patch and recompile, making sure you select
the NMI oopser option if you are running uniprocessor.  Instead of a
freeze you should get an NMI oops after 5 seconds and drop into kdb,
you need a text console or a serial console to talk to kdb.  Start with
a backtrace command (bt) to see where the problem is, it is probably
spinning on a lock.

ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.5-2.4.0-test9-pre9.gz
fits kernels >= 2.4.0-test9-pre9 && < 2.4.0-test10-pre4, including
2.4.0-test9.

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 12:15:08AM +0200, J . A . Magallon wrote:
> On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:
> > 
> > Due to bugs in the Linux kernel, it may only be compiled by certain versions
> > of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> > (linux/Documentation/Changes). 
> 
> "Bugs" in the kernel are related with things like supposing that the compilers 
> makes things (such as alignment or padding in structs) in certain way, that 
> could be done in any other way, but are done 'that' way in gcc.

The standards state what you can and can not depend on. If you depend on
something that is unspecified then you are broken. Of course, the kernel is
special-case software so this kind of thing can be expected.
 
> I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> 2.96 what is broken.

It compiles. Does it really work fine for all tasks and all people? Who
knows. It is know that your described configuration is not very well tested.

If 2.96 is broken, I'd appreciate it if you would describe the breakage. 
 
> That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
> AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
> distro with that name. So users can know they are installing 2.2.18-pre, and
> not 2.2.17.

RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
with a 2.2.16-22 which is the richest description that the current framework
allows. They also ship a source package which contains each patch separate
from the source. 

The reason they didn't call it 2.2.18-blah is because 2.2.17 didn't even
exist when they started their fork. Had they chosen to call their version
2.2.50 or whatever it would have caused needless confusion and perhaps
started a versioning war (i.e. SuSE with new 2.2.666 kernel! Mandrake with
2.2.777 kernel!).

They are rightfully (IMHO) letting the mainline developers increment the
kernel numbers while they denote their version with -nn. GCC doesn't have
the ability to -nn and because of that RedHat denoted their patched snapshot
2.96 and a frigging war ensued.

The unfortunate consequence of the kernel versioning is most users can't
understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
-
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/

Re: Topic for discussion: OS Design

[Jes Sorensen]

> "Dwayne" == Dwayne C Litzenberger <[EMAIL PROTECTED]> writes:

Dwayne> First of all, I'd like to say that I'm not writing this to
Dwayne> piss anyone off.  It's not a flame, a troll, or a personal
Dwayne> attack on anyone.  I my writing will aid in the improvement of
Dwayne> Linux.  Please read this with as much neutrality as you can
Dwayne> summon.

Oh my, not another one of those ;-(

Lets try and kill this on on the rise and avoid another flame war
caused by someone who hasn't tried to write single line of code on his
own.

Dwayne> Linux's loadable modules design is insufficient.  I have
Dwayne> several reasons for making this claim:

Dwayne> 1. Many things are inaccessible to the modules: There are
Dwayne> relatively few kernel modifications that can be compiled
Dwayne> without patching the pristine sources.

Your point being?

Dwayne> 2. The modules API is unstable.  Some people say this is
Dwayne> because of the exceedingly rapid development cycle of Linux.
Dwayne> I beg to differ.  I believe it is because there is no real
Dwayne> planned structure in the API -- just passing highly volatile
Dwayne> internal data structures around.

And this is a good thing, we want an efficient API not something that
people are afraid to break in order to solve problems - if we have a
bug or we can improve the API we should improve the API. Yes you can
claim you can design your way out of everything and everybody who's
written real code knows thats not the case. Code and design is an
iterative proces.

Dwayne> 3. Modules can very easily crash the whole kernel.  This is
Dwayne> because each module does not get to run in its own protected
Dwayne> memory space, as it would in a well-designed microkernel.

Oh my, did you just take the first lecture in a junior OS course?
Putting them in their own protected memory space is a) similar to
putting things in user space except for interrupt handling and b) very
inefficient for passing data around inside the kenel. The next lecture
in your course should cover context switches and page table
modifications and the cost of these.

Dwayne> 4. The kernel HTTPD is just masking a slow networking design.
Dwayne> Yes, I agree that high-level protocols should be eventually
Dwayne> incorporated into a standardized interface in an operating
Dwayne> system.  However, there would be no need for a kernel-based
Dwayne> httpd if the kernel was efficient enough.  This leads into my
Dwayne> next point:

Which kernel httpd? tux or khttpd? Tux is designed for the specweb
pissing contest, thats what specweb is all about. khttpd should be
replaced by something like phttpd which is a sigio based web
server. The performance has little to do with the networking
design.

Dwayne> 5. Linus tends to blame patches for inadequacies in the
Dwayne> kernel.  The PC speaker driver is a perfect example: No driver
Dwayne> should have to do something "dirty" in order to function,
Dwayne> because the operating system should provide clean ways to do
Dwayne> this.

A lot of drivers are badly designed and a lot of hardware is badly
designed, in particular PC hardware ;-( I don't know the details on
the PC speaker driver, but it is clearly something dear to you.

Dwayne> It would seem that a microkernel design would fix most of
Dwayne> these problems.  Two very elegant operating systems, namely
Dwayne> the Amiga's exec.library and QNX's Neutrino (I'm sure you can
Dwayne> name others), used microkernels, and they were both *very*
Dwayne> efficient.  However, there are some drawbacks to microkernels
Dwayne> that have been raised (and I don't have the expertise to argue
Dwayne> about them), but I think there are enough intelligent people
Dwayne> here that we can come up with a new OS design that takes the
Dwayne> best from both worlds.  This may require a new mailing list.

And if you had done your homework you would also know that
exec.library is based on running in a single shared memory
space. There is a reason why micro kernels are practically dead.

Dwayne> So, my question is this: What are some of Linux's design
Dwayne> problems, and what fundamental changes could be made for a
Dwayne> long-run benefit?

Actually one of the biggest problems we have is the noise ratio caused
by people not doing their homework and then raising issues on the list
expecting everybody to take them serious.

Jes
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Brian F. G. Bidulock]

-- Forwarded message --

-BEGIN PGP SIGNED MESSAGE-


It has come to our attention that some GNU/Linux distributions are
currently shipping with ``GCC 2.96''.

We would like to point out that GCC 2.96 is not a formal GCC release nor
will there ever be such a release.  Rather, GCC 2.96 has been the code-
name for our development branch that will eventually become GCC 3.0.

Current snapshots of GCC, and any version labeled 2.96, produce object
files that are not compatible with those produced by either GCC 2.95.2 or
the forthcoming GCC 3.0.  Therefore, programs built with these snapshots
will not be compatible with any official GCC release.  Actually, C and
Fortran code will probably be compatible, but code in other languages,
most notably C++ due to incompatibilities in symbol encoding (``mangling''),
the standard library and the application binary interface (ABI), is likely
to fail in some way.  Static linking against C++ libraries may make a
binary more portable, at the cost of increasing file size and memory use.

To avoid any confusion, we have bumped the version of our current
development branch to GCC 2.97.

Please note that both GCC 2.96 and 2.97 are development versions; we
do not recommend using them for production purposes.  Binaries built
using any version of GCC 2.96 or 2.97 will not be portable to systems
based on one of our regular releases.

If you encounter a bug in a compiler labeled 2.96, we suggest you
contact whoever supplied the compiler as we can not support 2.96
versions that were not issued by the GCC team.

Please see http://gcc.gnu.org/snapshots.html if you want to use our
latest snapshots.  We suggest you use 2.95.2 if you are uncertain.

The GCC Steering Committee 



- -- 
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: [EMAIL PROTECTED]
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/mjr/linux/cola.html

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBOeYfu1rUI/eHXJZ5AQFr/gP+Joi8J8CMFQ5k8hk9oCRuJKP0A9lnThrP
dKTbH2XnvVuBZ7ibcHenZHe1vVdRuxUyWxle4/Tg8QnQ2ON0smuPb2ibI0ie2W+7
RoCfe76XJ85e348JkkQgFSzSqsVbHV34KWp6H7ajyhTxRtONXCC07vxHT5I/GlTv
snmoSbKXPZg=
=yXqv
-END PGP SIGNATURE-

-- 
Brian F. G. Bidulock
[EMAIL PROTECTED]
http://www.openss7.org/
-
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/

Re: Topic for discussion: OS Design

[Dwayne C . Litzenberger]

On Mon, Oct 23, 2000 at 08:53:26AM +1000, Peter Waltenberg wrote:
> Use the GNU Hurd, it won't run on most hardware you'd like to use, and it's
> probably slower than Linux, but it's a microkernel.

I'll ignore that.

> I've worked with microkernels, IMHO, they suck :). Good idea, but fundamentally
> flawed. The same things that make them more robust (and they are more robust)
> also kill performance.

Could you elaborate?  AFAIK, both Neutrino and exec.library are microkernels,
and they by no means lack performance.  Even Windows is a microkernel (sort
of), and it doesn't lack in performance that much.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- Please have the courtesy to respond to any requests or questions I may have.
- See the mail headers for GPG/advertising/homepage information.

 PGP signature

Re: Kernel 2.2.17 with RedHat 7 Problem !

[J . A . Magallon]

On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
>  
> > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > 2.96 what is broken.
> 
> It compiles. Does it really work fine for all tasks and all people? Who
> knows. It is know that your described configuration is not very well tested.
> 
> If 2.96 is broken, I'd appreciate it if you would describe the breakage.

With the kernel, it refuses to compile somehthing (checksum.S) related with
varargs in macros that is perefectly legal reading the info files for gcc.
 
> RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> with a 2.2.16-22 which is the richest description that the current framework
> allows. They also ship a source package which contains each patch separate
> from the source. 

The '22' there is the package version, not related to the gcc or kernel
version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
If they discover the left a pair of icons at home, the new package is
thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

> 
> The unfortunate consequence of the kernel versioning is most users can't
> understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
>

And should not be that way, because 17 usually includes all the patches to
16 that mutate it in -22, and even more.

-- 
Juan Antonio Magallon Lacarta  mailto:[EMAIL PROTECTED]

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Jan Dvorak]

On Sun, Oct 22, 2000 at 05:43:30PM -0400, Gregory Maxwell wrote:
> Due to bugs in the Linux kernel, it may only be compiled by certain versions
> of GCC. GCC 2.7.2 or EGCS 1.1.2 are only supported compilers
> (linux/Documentation/Changes). 
> 
> Unfortunately, 2.7.2 and EGCS 1.1.2 are really crappy C++ compilers so many
> distributions are beginning to ship GCC 2.95 and later. Those distributions
> typically include an alternative gcc for compiling the kernel. RedHat has
> kgcc, and you should compile the kernel with that

I am using gcc 2.95.2 from its release, and i doesn't encounter any problems
on kernel compilation. Yes, i saw compiling problems on mailing lists, but i
think, that gcc 2.95.2 should be used widely as kernel compiler. It's better
than forcing users to have old 2.7.2.3 (even 2.95.2 is now year old), or to
have 2 compilers - one for 'normal' programs, second for compiling kernel.
It's more stable than gcc 2.95(.1), much more stable than pgcc,*cc, and its
millenia far from gcc 2.96 snapshot. It will be nice to point in Changes
*explicitly*, that gcc 2.96 will not work, that gcc 2.95.2 will work in most
cases, and if it will not (or if error in runtime), try to use egcs-whatever or
gcc 2.7.2.*. Gcc 2.95.2 (in fact anything > 2.7.2.3) is there compared as equal to
pgcc, which is unfair. 

Jan Dvorak <[EMAIL PROTECTED]>

-
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/

Re: Topic for discussion: OS Design

[Dwayne C . Litzenberger]

Yikes!  Within 5 minutes, I already got a few personal attacks! (and some very
insightful messages as well.)

I'll end this here before it gets too out-of-control.

I should have done my homework before posting.  I don't totally agree that my
posts were wrong (as an end user, I can definitely see that Linux needs
serious work), but I should have seen that this would start a flame war, and
been sufficiently armed to enter into an argument like this.  I'm not, so I'll
just shut up now.

-> Please don't continue to flame me: I've learned my lesson. <-

I'm a teenager that's been programming (mostly in AmigaBASIC) for about 11
years now.  I've only been doing C for the last 1-2 years (though I'm learning
quickly).  I want to get familiar with kernel programming.

I've been told that I should start with writing a driver.  Any good online
resources on doing this (eg. hardware specs, x86 assembler resources,
tutorials, etc)?  I learn quickly, but I have no idea where to begin.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- Please have the courtesy to respond to any requests or questions I may have.
- See the mail headers for GPG/advertising/homepage information.

 PGP signature

test10-pre nfs compile failure

[Paul Jakma]

i've gotten the following message the last 2 times i've tried to
compile the kernel (test10-pre{3,4}):

make[2]: Entering directory `/misc/src/linux-2.4.0/fs/nfs'
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe  -mpreferred-stack-boundary=2
-march=athlon  -fno-strict-aliasing -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h   -c -o proc.o proc.c
In file included from /usr/src/linux/include/linux/sunrpc/types.h:14,
 from /usr/src/linux/include/linux/sunrpc/sched.h:14,
 from /usr/src/linux/include/linux/sunrpc/clnt.h:13,
 from proc.c:40:
/usr/src/linux/include/linux/sunrpc/debug.h:57:57: warning: nothing
can be pasted after this token
proc.c:262: redefinition of `nfs_proc_unlink_setup'
proc.c:237: `nfs_proc_unlink_setup' previously defined here
proc.c:278: redefinition of `nfs_proc_unlink_done'
proc.c:253: `nfs_proc_unlink_done' previously defined here
{standard input}: Assembler messages:
{standard input}:882: Fatal error: Symbol nfs_proc_unlink_setup
already defined.make[2]: *** [proc.o] Error 1
make[2]: Leaving directory `/misc/src/linux-2.4.0/fs/nfs'
make[1]: *** [_modsubdir_nfs] Error 2
make[1]: Leaving directory `/misc/src/linux-2.4.0/fs'
make: *** [_mod_fs] Error 2

does anyone know what this could be? (i've done a make mrproper).

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Money can't buy love, but it improves your bargaining position.
-- Christopher Marlowe


-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Mon, Oct 23, 2000 at 01:00:14AM +0200, J . A . Magallon wrote:
> On Mon, 23 Oct 2000 00:36:14 Gregory Maxwell wrote:
> >  
> > > I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> > > 2.96 what is broken.
> > 
> > It compiles. Does it really work fine for all tasks and all people? Who
> > knows. It is know that your described configuration is not very well tested.
> > 
> > If 2.96 is broken, I'd appreciate it if you would describe the breakage.
> 
> With the kernel, it refuses to compile somehthing (checksum.S) related with
> varargs in macros that is perefectly legal reading the info files for gcc.

The file is compiled with -traditional. The ellipses (for optionality) are a
GNU extension. The kernel contains the bug. Not gcc.

The kernel gurus agree that the kernel is broken and not GCC.
for example:
http://www.cs.helsinki.fi/linux/linux-kernel/2000-39/0495.html  

> > RedHat (and others) doesn't just call 'their' 2.2.16 2.2.16. RedHat 7 ships
> > with a 2.2.16-22 which is the richest description that the current framework
> > allows. They also ship a source package which contains each patch separate
> > from the source. 
> 
> The '22' there is the package version, not related to the gcc or kernel
> version. When RH (or Mandrake) package a thing in an rpm, is thing-2.3.4-1.rpm.
> If they discover the left a pair of icons at home, the new package is
> thing-2.3.4-2.rpm. If they misplaced an script, new one is thing-2.3.4-3.rpm.
> But thing is still 2.3.4. So you could have kernel-2.2.18pre7-1.rpm.
> If they discover a patch was badly applied, public kernel-2.2.18pre7-2.rpm.
> If they apply NEW patches, from pre 8, it is now kernel-2.2.18pre8-1.rpm.

Applying patches, adding scripts, etc sure sounds like a new version to me.

And the kernel that ships with RedHat 7 is 2.2.16 + patches and is
called (by them) 2.2.16-22 (which is what uname reports too). This kernel
has numerous advantages over 2.2.17.


> > 
> > The unfortunate consequence of the kernel versioning is most users can't
> > understand that 2.2.16-22 > 2.2.17 in terms of usability for most users.
> >
> 
> And should not be that way, because 17 usually includes all the patches to
> 16 that mutate it in -22, and even more.

It doesn't. 17 doesn't included 1/4 of what is in RedHat's 2.2.16-22 and
2.2.16-22 doesn't include everything in 2.2.17 (it's called testing and
avoiding shipping software they haven't tested).

RedHat has no control over what goes into the mainline 2.2.n. 

You are completely nuts if you think that distributions should wait
for a feature to appear in the mainline before including it in their
distribution. 

Doing so would certainly have a negative effect on the development of the
mainline kernel due to pressure to include features that are not ready for
the mainline.

Distributors have different goals from the mainline kernel developers, and
thus they ship different kernels.

-
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/

Re: Topic for discussion: OS Design

[davej]

[EMAIL PROTECTED] proclaimed...

> Could you elaborate?  AFAIK, both Neutrino and exec.library are
> microkernels, and they by no means lack performance.

Whilst I've not used Neutrino, I did use exec.library for several
years (and was part of a project to rewrite the bad parts before
CBM went down the pan).

I'm not sure the point you're trying to make.
AmigaOS had Device drivers in userspace (Well, AmigaOS didn't
really have a kernel/user space divide), which generally
worked ok for the Amiga, but are not practical in Linux.

- AmigaOS didn't have to worry about issues like SMP.
  Linux runs on archs other than m68k, where we _do_ have
  to worry about such things.

- AmigaOS had no memory protection, and no concept of
  userspace/kernelspace, so it was perfectly acceptable
  for a userspace driver to handle interrupts etc, bash
  hardware registers etc..
  Linux (on x86 for example) has to run priveledged instructions
  in kernel mode, which require a context switch.

If you really think AmigaOS has anything which Linux could benefit
from, send patches. Otherwise, well...

> Even Windows is a microkernel (sort of)
> and it doesn't lack in performance that much.

This doesn't even justify a reply.
Please go read an OS internals book before you make such comments.

regards,

d.
-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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/

Re: AMD CPU misdetection?

[davej]

Andreas Eibach proclaimed..

>Vince, wasn't it supposed to be
>
> A K6-2+:
>model name  : AMD-K6(tm) 3D+ Processor 
>
> A K6-3:
>   model name  : AMD-K6(tm)-III Processor

I don't think so.

The K6-2 yeilds what you mentioned above.
The K6-2+ is actually the CPU that was released
_after_ K6-3. Go figure.

Why they didn't call it K6-4 is anyones guess.
(See Pentium IV thread for more CPU naming nonsense)
I guess Intel aren't the only ones who lose it occasionally.

davej;

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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/

raid2 patches for 2.2.x

[Wakko Warner]

Something higher than the one for kernel 2.2.11  I found it once, but I can't
find it again.  (and people.redhat.com isn't accepting http connections)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
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/

K6-2+ name (was Re: AMD CPU misdetection?)

[Barry K. Nathan]

> The K6-2+ is actually the CPU that was released
> _after_ K6-3. Go figure.
> 
> Why they didn't call it K6-4 is anyones guess.

I read somewhere (I don't have a URL handy, sorry) that the reason AMD went
with K6-2+ is that, apparently, the K6-2 name is well-known, and they
wanted to build on that...

-Barry K. Nathan <[EMAIL PROTECTED]>
-
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/

Re: Topic for discussion: OS Design

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> A few years ago, there was an intense debate around the question of
> cooperative vs. preemptive multitasking operating system design.  Today,
> however, cooperative multitasking is a thing of the past, and it is virtual=
> ly
> undisputed that the preemptive multitasking design is highly superior to the
> cooperative one.

No, this completely depends on the Task the OS has to do and the Hardware
the OS has to run on. Cooperative Systems can have a lot more throughput
than time sliced systems.

> It would seem that a microkernel design would fix most of these problems.  =
> Two
> very elegant operating systems, namely the Amiga's exec.library and QNX's
> Neutrino (I'm sure you can name others), used microkernels, and they were b=
> oth
> *very* efficient.

The problem is, that Linux is not a Microkernel Based System. So if you want
a microkernel based system ust used one. There are lot out there. Based on
MACH or whatever. You can consier to work with the HURD. I mean it is not a
bad idea to rethink design of the Linux Kernel, but changing it into a
Microkernel means rewriting it. And I am not sure it will helo the Linux
development a lot (remeber ist WAS the fastest among all others, this can be
due to the fact that the monolitic kernel is supperior in development
effords).

Grettings
Bernd
-
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/

re: K6-2+ name (was Re: AMD CPU misdetection?)

[davej]

In the words of Barry K. Nathan :

> > Why they didn't call it K6-4 is anyones guess.
> I read somewhere (I don't have a URL handy, sorry) that the reason AMD
> went with K6-2+ is that, apparently, the K6-2 name is well-known, and
> they wanted to build on that...

Sounds like a marketing thing.
Not really an excuse imo. The "Oh, K6-4. I must upgrade" brigade would've
justified the name for more than confusing people. At least K6-2+
is mostly used in laptops from what I've seen, so the confusion is
limited.

Maybe there just wasn't enough architectural difference between the
K6-3 & the K6-2+ to justify calling it the K6-4. AFAIR, the powersaving
speed changing is the only thing thats changed.

I'm buying a K6-2+ laptop tomorrow, so I guess I'll find out more then :)

davej;

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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/

Re: Proposal: driver initialization pipelining

[Andre Hedrick]

On Fri, 20 Oct 2000, Pavel Machek wrote:

> Hi!
> 
> > There ought to be _some_ initializations that don't require interrupts?
> > Registering the file systems and network protocols, stuff like that?
> 
> Give up on IDE, it is too broken.

Yeah S- Can the whole thing and 90% of all users of Linux??

> You should get away with paralelising USB and SCSI scan.

Go read the rules of detection in the ATA Standard.

> Perhaps you can speed boot up with initrd+modules, possibly improving module
> inits (but they are probably good enough). With modules, I can imagine 
> USB+SCSI scans running in paralel.

It does not work that way.
As a SuSEman you know better than to comment on things that you have no
clue about...

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
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/

Re: K6-2+ name (was Re: AMD CPU misdetection?)

[Brian Gerst]

"Barry K. Nathan" wrote:
> 
> > The K6-2+ is actually the CPU that was released
> > _after_ K6-3. Go figure.
> >
> > Why they didn't call it K6-4 is anyones guess.
> 
> I read somewhere (I don't have a URL handy, sorry) that the reason AMD went
> with K6-2+ is that, apparently, the K6-2 name is well-known, and they
> wanted to build on that...

IIRC, the K6-2+ is really a K6-3 core with the on-chip L2 cache disabled
because of defects.

--
Brian Gerst
-
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/

Re: Topic for discussion: OS Design

[Ralf Baechle]

On Sun, Oct 22, 2000 at 04:58:45PM -0600, Dwayne C . Litzenberger wrote:

> Could you elaborate?  AFAIK, both Neutrino and exec.library are microkernels,
> and they by no means lack performance.  Even Windows is a microkernel (sort
> of), and it doesn't lack in performance that much.

Exec.library with it's aproximately 6kb can hardly be compared with a
full featured kernel like Linux.  Look at something like filesystems.
If you write a multithreaded filesystem for the Amiga you'll hit alot
of complexity which you'll never have to think about for a monolithic
kernel.  Makes monolithic kernels look sweet as sugar in comparison.

  Ralf
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Mon, 23 Oct 2000, Hamid Hashemi Golpayegani wrote:

>Hi ,
>
>I have download kernel-2.2.17 from kernel.org and wanna to compile it under
>redhat 7 . when compiling start after few minutes show me this error message
>:
>
>make[2]: Entering directory `/usr/src/linux/arch/arch/i386/lib'
>gcc -D__KERNEL__ -I/usr/src/linux-2.2.17/include -D__ASSEMBLY__ -D__SMP__ -t
>raditional -c checksum.S -o checksum.o
>checksum.S:231: badly punctuated parameter list in #define
>checksum.S:237: badly punctuated parameter list in #define
>make[2]: *** [checksum.o] Error 1
>make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make[1]: *** [first_rule] Error 2
>make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
>make: *** [_dir_arch/i386/lib] Error 2
>
>I have install this kernel with same setting on RedHat 6.2 without any
>problem !
>Any idea ?

On Red Hat 7, you _MUST_ use the "kgcc" compiler to compile
kernels by editing the top level makefile and changing "gcc" to
"kgcc".


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

Need general help or technical support with Red Hat Linux 6.2?  Join the user 
support mailing list by sending a message to "[EMAIL PROTECTED]"
with the word "subscribe" on the subject line.

-
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/

Re: K6-2+ name (was Re: AMD CPU misdetection?)

[Vince Weaver]

> IIRC, the K6-2+ is really a K6-3 core with the on-chip L2 cache disabled
> because of defects.

Hmmm I don't think so.  From the dmesg of my K6-2+ [a 500Mhz underclocked
to 75Mhzx6 on my poor PA-2007 motherboard]

CPU: L1 I Cache: 32K  L1 D Cache: 32K (32 bytes/line)
CPU: L2 Cache: 128K
CPU: AMD-K6(tm)-III Processor stepping 04

Features of the K6-2+ are the L2-cache, the smaller mask size, the
Power-Now stuff, and some Athlon 3dnow extensions.

And to whoever doubted my list of K6 model names, believe me, I have
accounts on machines with K6, K6-2, K6-III, and K6-2+, so I have much
experience trying to get sane CPU types from AMD's lousy model field.

Vince

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 13
model name  : AMD-K6(tm)-III Processor
stepping: 4
cpu MHz : 450.13
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 sep mtrr pge mmx 3dnowext 
3dnow
bogomips: 897.84


-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Mike A. Harris]

On Sun, 22 Oct 2000, Jurgen Kramer wrote:

>Date: Sun, 22 Oct 2000 23:02:19 +0200
>From: Jurgen Kramer <[EMAIL PROTECTED]>
>To: Hamid Hashemi Golpayegani <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: Kernel 2.2.17 with RedHat 7 Problem !
>
>Hi,
>
>You can blame it on the compiler which is included with RH7.0.

This is incorrect and misleading.  The *KERNEL* has bugs that
require an older gcc.  Red Hat 7.0 includes an older gcc called
"kgcc" in order to compile kernels.

>It's a pre-release version of some sort.  It seems that the gcc
>people are not happy that RH included this version with RH7.

Which is irrelevant since Red Hat 7 includes kgcc which is
intended for kernel builds.

--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Mike A. Harris Linux tip #1 - 50 line mode]
Is the 80x25 line screen too small for you?  If you want more screen real
estate, you can set 50 column mode by editing your /etc/lilo.conf file, and 
adding a new line with "vga=ext" to the global section near the top.  Save
and exit, then run "lilo".  Next time you boot, you'll have a nice big 80x50 
screen.

-
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/

Re: [PATCH] cpu detection fixes for test10-pre4

[Mike A. Harris]

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/asm-i386/bugs.h in test10-pre4)
>> > 
>> 
>> We should never have used anything but "i386" as the utsname... sigh.
>
>We stil can do that: make 2.4.0 use i386 for utsname on all x86 machines
>(except x86-64 ;-), and let people adapt.

Better yet, make it use "ia32" to avoid confusion.


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

Microsoft Windows(tm). A thirty-two bit extension and graphical shell
to a sixteen bit patch to an eight bit operating system originally
coded for a four bit microprocessor which was written by a two-bit
company that can't stand one bit of competition.

-
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/

Re: Topic for discussion: OS Design

[Mike A. Harris]

On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:

>Although I am a programmer, I am not yet a kernel hacker, so some of my claims

Point 1.

>*very* efficient.  However, there are some drawbacks to microkernels that have
>been raised 

Point 2.

>(and I don't have the expertise to argue about them),

Point 3.

That pretty much answers the question right there IMHO.  This is
an FAQ.

>So, my question is this:  What are some of Linux's design problems, and what
>fundamental changes could be made for a long-run benefit?

Not by turning it into a microkernel.  Suggesting it is nothing
more than religious CS BS.


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Mike A. Harris Linux tip #1 - 50 line mode]
Is the 80x25 line screen too small for you?  If you want more screen real
estate, you can set 50 column mode by editing your /etc/lilo.conf file, and 
adding a new line with "vga=ext" to the global section near the top.  Save
and exit, then run "lilo".  Next time you boot, you'll have a nice big 80x50 
screen.

-
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/

CML 0.8.2 available

[Eric S. Raymond]

The latest version is always available at http://www.tuxedo.org/~esr/kbuild/

Release 0.8.2: Sun Oct 22 21:52:47 EDT 2000
* Added -W option to permit undefined symbols in -I files.
* Miscellaneous typo fixes.

This version is synchronized with 2.4.0-test9.  I believe it is ready
for production use, but not all of the rules file is certified as yet.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Power concedes nothing without a demand. It never did, and it never will.
Find out just what people will submit to, and you have found out the exact
amount of injustice and wrong which will be imposed upon them; and these will
continue until they are resisted with either words or blows, or with both.
The limits of tyrants are prescribed by the endurance of those whom they
oppress.
-- Frederick Douglass, August 4, 1857
-
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/

Re: test10-pre nfs compile failure

[Paul Jakma]

ok... 

looks like a patch went wrong at some point. (or i forgot to remove a
patch from Trond from a little while ago).

apologies,

Paul Jakma.

On Sun, 22 Oct 2000, Mark Hahn wrote:

> > i've gotten the following message the last 2 times i've tried to
> > compile the kernel (test10-pre{3,4}):
> 
> which gcc are you using?  looks like you're using RH7's user-level gcc,
> not kgcc.

-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Jurgen Kramer <[EMAIL PROTECTED]> said:

> You can blame it on the compiler which is included with RH7.0. It's a
> pre-release version of some sort. It seems that the gcc people are not
> happy that RH included this version with RH7.

It is the *kernel's* fault, as far as can be ascertained now. The compiler
is stricter, and implements new optimizations, for which the kernel (being
only ever compiled with gcc) is just unprepared.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

"Brian F. G. Bidulock" <[EMAIL PROTECTED]> said:
> It has come to our attention that some GNU/Linux distributions are
> currently shipping with ``GCC 2.96''.

Please, not again!

Red Hat 7.0's "GCC 2.96" is binary compatible for C with all past and
future versions. It will probably not be binary compatible with C++ for
gcc-3.0. But then again, _none_ of the extant C++ compiler versions are
binary compatible, each needs its own libstdc++, so this is mostly a
non-issue.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

Gregory Maxwell <[EMAIL PROTECTED]> said:

[...]

> If you are going to upgrade, you should at least consider going to
> 2.4.0test-flavor-of-week, so that your crashes will at least contribute to
> Linux development. :)

Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
reorganization of / here (had to reinstall several packages, and lost most
of root's account configuration), and it also nibbled at /usr/src (it
screwed up a directory, and I suspect it bit my gcc tree updated daily from
CVS, for which I have a backup).

Sorry, no further data.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Horst von Brand]

c> 
"J . A . Magallon" <[EMAIL PROTECTED]> said:
> On Sun, 22 Oct 2000 23:43:30 Gregory Maxwell wrote:

[...]

> I am now compiling my 2.2.18-pre kernels with gcc-2.95 and work fine. It is
> 2.96 what is broken.

2.95.2 has been working with kernels for quite some time. 2.96+ should (?)
work with latest 2.2.18-pre, at least patches in that direction will be
integrated by Alan.

[...]

> That should not be done that way. A 2.2.17 kernel is a 2.2.17. If you want
> AGP, or USB, build a kernel and name it 2.2.18-pre17 and offer it in your
> distro with that name. So users can know they are installing 2.2.18-pre, and
> not 2.2.17.

Red Hat 7.0's current kernel is 2.2.16-22, i.e., a heavily patched 2.2.16
announced as such.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Gregory Maxwell]

On Sun, Oct 22, 2000 at 10:12:06PM -0300, Horst von Brand wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> said: 
> [...]
> > If you are going to upgrade, you should at least consider going to
> > 2.4.0test-flavor-of-week, so that your crashes will at least contribute to
> > Linux development. :)
> 
> Careful there! 2.4.0-test10-pre3 on i686 is the prime suspect in massive
> reorganization of / here (had to reinstall several packages, and lost most
> of root's account configuration), and it also nibbled at /usr/src (it
> screwed up a directory, and I suspect it bit my gcc tree updated daily from
> CVS, for which I have a backup).

Thanks. After four years of participating on this list, I guess I've come to
ignore the occasional devel-kernel-eats-my-filesystem. :)
-
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/

Tux 2 Patents

[Jeff V. Merkey]

Update on Tux 2 Patent analysis.

Of the three patents identified by Daniel, one has been eliminated as 
a potential for infringement and the other two have not.  We have obtained 
copies from the USPTO of the full patent files for the patents originally
identified (3).  The detail on one of the patents provided looks very 
suspect and Brian is emailing Daniel for a detailed description (we need 
a very detailed description at this point to compare to each claim of
what will be implemented in Tux vs. what's claimed in these patents.)

After Brian gets a very detailed writeup from Daniel, we will be able to 
proceed with the claim comparison by the patent attorneys.  One of the NetApp
patents is somewhat broad in it's claims, and we need to compare
Daniel's claims vs. NetApp's claims one claim at a time.  

This is a time consuming and detailed process, so it may be a week or so 
longer until Malinkrodt completes their analysis.

Jeff

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[David Relson]

At 09:14 PM 10/22/00, Horst von Brand wrote:
>Jurgen Kramer <[EMAIL PROTECTED]> said:
>
> > You can blame it on the compiler which is included with RH7.0. It's a
> > pre-release version of some sort. It seems that the gcc people are not
> > happy that RH included this version with RH7.
>
>It is the *kernel's* fault, as far as can be ascertained now. The compiler
>is stricter, and implements new optimizations, for which the kernel (being
>only ever compiled with gcc) is just unprepared.

The problem, as I understand it, is that gcc-2.96 handles language 
constructs slightly different than older compilers.  This is a preprocessor 
change, not an optimization problem.

To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
worked with compilers (some years ago), I always took it as an article of 
faith that the same answer(s) would be generated whether optimization was 
turned on or not.  Optimization should always be a way to do a task either 
quicker (fewer instructions executing, less executing time, etc) or shorter 
(less memory needed for the instructions).  Optimization should never, 
never give a different result.  Having new optimizations break an executing 
program is simply wrong.

David


>--
>Horst von Brand [EMAIL PROTECTED]
>Casilla 9G, Vin~a del Mar, Chile   +56 32 672616


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
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/

Re: getting module symbols into ksyms

[Jerry Kelley]

Thanks for the info. I'll give it a try.

Jerry

- Original Message - 
From: "Keith Owens" <[EMAIL PROTECTED]>
To: "Jerry Kelley" <[EMAIL PROTECTED]>
Cc: "linux kernel" <[EMAIL PROTECTED]>
Sent: Sunday, October 22, 2000 5:24 PM
Subject: Re: getting module symbols into ksyms 


> On Sun, 22 Oct 2000 10:26:04 -0500, 
> "Jerry Kelley" <[EMAIL PROTECTED]> wrote:
> >kernel = 2.2.14-5.0 for i686 UP
> >insmod reports version 2.3.10-pre1
> >ksymoops is 0.7c
> 
> Upgrade both modutils and ksymoops, both are well out of date.  Also
> kernel 2.2.14 does not have the code to handle symbols if you get an
> oops during module initialization, you need at least kernel 2.2.15 for
> that.
> 
> ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3
> ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3
> 

-
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/

Re: Kernel 2.2.17 with RedHat 7 Problem !

[Michael Meissner]

On Sun, Oct 22, 2000 at 11:16:36PM -0400, David Relson wrote:
> At 09:14 PM 10/22/00, Horst von Brand wrote:
> >Jurgen Kramer <[EMAIL PROTECTED]> said:
> >
> > > You can blame it on the compiler which is included with RH7.0. It's a
> > > pre-release version of some sort. It seems that the gcc people are not
> > > happy that RH included this version with RH7.
> >
> >It is the *kernel's* fault, as far as can be ascertained now. The compiler
> >is stricter, and implements new optimizations, for which the kernel (being
> >only ever compiled with gcc) is just unprepared.
> 
> The problem, as I understand it, is that gcc-2.96 handles language 
> constructs slightly different than older compilers.  This is a preprocessor 
> change, not an optimization problem.
> 
> To say "new optimizations ... kernel ... unprepared" is incorrect.  Having 
> worked with compilers (some years ago), I always took it as an article of 
> faith that the same answer(s) would be generated whether optimization was 
> turned on or not.  Optimization should always be a way to do a task either 
> quicker (fewer instructions executing, less executing time, etc) or shorter 
> (less memory needed for the instructions).  Optimization should never, 
> never give a different result.  Having new optimizations break an executing 
> program is simply wrong.

Ummm, that should read "Having new optimizations break a correct exeucting
program...".  For example, the following program:

#include 

int main(){
  int i;
  printf ("i = %d\n", i);
  return 0;
}

will necessarily print different values for i, depending on the optimization
level, what was on the stack and in the registers when main started, and
possibly other criteria.  Just because a program is executing, it doesn't mean
it is correct.

Both the kernel and the compiler are large complex pieces of software, and
almost certainly have bugs in them, and over the years, I have certainly found
some of these bugs as I use new versions of each.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
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/

Re: Topic for discussion: OS Design

[Dwayne C . Litzenberger]

[snip]
> crossing memory protection domains is slow, there's no way around
> it (except better hardware).

So what we really need to do is get some custom "RAM blitter" into our
hardware to do the memory copies needed for fast context switching and message
passing.

Too bad nobody on this list works at an electronics design company... ;-P

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- Please have the courtesy to respond to any requests or questions I may have.
- See the mail headers for GPG/advertising/homepage information.

 PGP signature

Re: IDE disk slow? There's help...

[Jeremy Fitzhardinge]

On Fri, Oct 20, 2000 at 01:22:59PM -0700, Andre Hedrick wrote:
> On Fri, 20 Oct 2000 [EMAIL PROTECTED] wrote:
> 
> > [EMAIL PROTECTED] wrote..
> > 
> > > I reliably get 30MB/s with my IBM 30G 7200rpm ATA66 drive, using a
> > > Via VT82C586 controller.  2.4.0-test9.  Modern drives are really fast.
> > 
> > Hmm, I'm confused here.
> > VIA 586 can only do up to UDMA 2, which should return speeds less than
> > that. My system has an identical configuration, and I get ~12MB/s
> 
> No the are the pci device ide but different guts.  This is the ugliness
> that most never see.

I think you left some words out.  Are you saying that this is one of those
chips which change PCI id in order to give the appearance of backwards
compatability?  That it's not really a VT82C586?

Thanks,
J

 PGP signature

Re: Topic for discussion: OS Design

[Dwayne C . Litzenberger]

I'll explain my reason for this rant.

The Amiga was my second computer, and the one I spend most of my computing
life on.  I've grown up noticing all the things the PC/Windows did wrong while
the Amiga did it right (mostly UI stuff).

Later, I got my own PC, running Windows 95.  Horror.  Win95 is an absolutely
bug-infested piece of you-know-what.  However, at that time, I believed that
Windows==PC, so I thought it was the PC hardware that was at fault.

Then, I heard of Linux, and installed it.  What a difference!  Much faster,
and sooo stable!  I loved it.  It was still clunky, and slow (compare a
P120MHz to an Amiga 7.14Mhz -- should be 16x as fast, but it's not), but I
still thought it was because of the PC hardware.  Executable code sizes bugged
me a bit (usually 10-100x larger than Amiga).

Then I got the QNX demodisk.  It was amazing what they could fit on that disk!
It was also smooth and fast, too.  I started to doubt that the PC hardware was
solely at fault for the inefficiency of the software running on it.

Later, I downloaded the actual QNX RTOS CD (go try it: http://get.qnx.com/),
and this confirmed my suspicions that PC hardware was capable of relatively
efficient operation.

So, then, I was asking myself: WHY is Linux so slow and clunky in comparison?
I knew that GCC was not the most efficient compiler in the world, but it
wasn't that bad.

Then I start hearing about khttpd, something that (ideally) should go in user
space, hardware drivers are rejected (PCSP is my example, but what if some
other device is as kludgy as the pcsp?  Will it be rejected too?), and
software-suspend mysteriously disappears from Alan's -ac patches.  X (a
hardware driver) is in user space, and so is svgalib.  It all looks very
messy.  The atyfb still doesn't work for my Rage Pro (2.2.x, anyway.  Never
tried 2.[34]).  Patches for features I want are a nightmare.

My complaint is from a user's point of view.  This particular user wants
software-suspend, pcsp, reiserfs, USB, and agpgart.  This user also wants a
smooth GUI, a mouse pointer that doesn't flinch under load, and a small enough
system that he won't have to be swapping all the time (not entirely kernel's
fault).  All these things are reasonable.

Somebody here with a bit more knowledge should really take an hard look at
QNX.  From a user's standpoint, it's a very clean and efficient (fast) OS.  Is
it possible to have something that is as clean as a microkernel, while
minimizing the overhead?

I must apologize for saying what seemed to be another "Linux should be a
microkernel".  That was not my intent.  I indended to start a discussion
(!argument) about looking for the best of both worlds (or a new idea
altogether) of monolithic and micro- kernels.

-- 
Dwayne C. Litzenberger - [EMAIL PROTECTED]

- Please always Cc to me when replying to me on the lists.
- Please have the courtesy to respond to any requests or questions I may have.
- See the mail headers for GPG/advertising/homepage information.

 PGP signature

[OT] Re: K6-2+ name (was Re: AMD CPU misdetection?)

[Barry K. Nathan]

> IIRC, the K6-2+ is really a K6-3 core with the on-chip L2 cache disabled
> because of defects.

My recollection (starting with the K6-3+ and then going to the K6-2+ - if
there are any errors, please correct me):

The K6-3+ is a K6-3 produced on a smaller process (180nm, as opposed to
the K6-3's 250nm (I think it was 250, anyway)). Some of these also have
PowerNow(tm), which is like Intel's SpeedStep(tm) but with a wider range of
speeds.

The K6-2+ is a K6-3+ with half of the on-chip L2 cache disabled.

Anyway, my previous email was describing the rationale that AMD used to
arrive at the K6-2+ name.

-Barry K. Nathan <[EMAIL PROTECTED]>
-
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/

Re: IDE disk slow? There's help...

[Andre Hedrick]

On Sun, 22 Oct 2000, Jeremy Fitzhardinge wrote:

> > No the are the pci device ide but different guts.  This is the ugliness
> > that most never see.
> 
> I think you left some words out.  Are you saying that this is one of those
> chips which change PCI id in order to give the appearance of backwards
> compatability?  That it's not really a VT82C586?

Okay,

The North/South Bridge combination names will change but ATA/IDE device
ID's are identical.  This is how the features differ from one to the
other.

So your ATA-33 limited will report the same ID as an ATA-66.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
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/

Re: Request for info on proc system update frequency

[Jeremy Fitzhardinge]

On Wed, Oct 18, 2000 at 04:48:48PM +0100, Stephen Tweedie wrote:
> On Tue, Oct 17, 2000 at 12:31:24AM -0400, John Kacur wrote:
> > I'm trying to understand how the proc file system works. In particular
> > I'd like to know more about the algorithm by which the information is
> > updated and how frequently.
> 
> It is "live": the file contents are generated on demand when you read
> them.  A very few proc files include time-averaged data (such as the
> load average); everything else is absolutely uptodate.

...at the instant you read it.  It may be out of date a nanosecond later.
[Yes, a nit-pick, but worth making clear to the original poster.]

J

 PGP signature

Re: Topic for discussion: OS Design

[Jeff V. Merkey]

On Sun, Oct 22, 2000 at 09:56:52PM -0600, Dwayne C . Litzenberger wrote:
> [snip]
> > crossing memory protection domains is slow, there's no way around
> > it (except better hardware).
> 
> So what we really need to do is get some custom "RAM blitter" into our
> hardware to do the memory copies needed for fast context switching and message
> passing.
> 
> Too bad nobody on this list works at an electronics design company... ;-P

Dwayne,

Why don't you get with the C++ guy on the list talking about C++ kernels,
Eray Ozkural ([EMAIL PROTECTED]) and the two of you design a processor
that's optimized to run C++ with 0 overhead memory protection (3 clocks max
to go through a ring 3 -> 0 gate).  Who knows?  Maybe you could design 
a new processor for us to use that just implements two super RISC 
instructions, 'set bugs off' and 'do what I'm thinking'.

:-)

Jeff

> 
> -- 
> Dwayne C. Litzenberger - [EMAIL PROTECTED]
> 
> - Please always Cc to me when replying to me on the lists.
> - Please have the courtesy to respond to any requests or questions I may have.
> - See the mail headers for GPG/advertising/homepage information.


-
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/

Re: 2.2.18pre17: usb-uhci verbosity

[David Rees]

On Fri, Oct 20, 2000 at 08:59:00PM -0400, Martin Hicks wrote:
> 
> I moved from 2.2.18pre15 to 2.2.18pre17 and now I get the following
> usb-uhci stuff being spewed to my terminal:
> 
> Oct 20 20:54:19 plato kernel: usb-uhci.c: interrupt, status 3, frame# 704
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1088
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1472
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1856
> 
> Everything seems to be functioning correctly though.  Reason?

Not sure, but I saw the same thing on my machine.  No one had any ideas,
but I moved to the altertative uhci driver and things work great and no
more messages.

-Dave
-
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/

Re: question wrt context switching during disk i/o

[Mike Galbraith]

On Sat, 21 Oct 2000, Mike Galbraith wrote:

> On Sat, 21 Oct 2000, Mike Galbraith wrote:
> 
> > On Fri, 20 Oct 2000, Mark Hahn wrote:
> > 
> > > > This is something that has been bugging me for a while.  I notice
> > > > on my system that during disk write we do much context switching,
> > > > but not during disk read.  Why is that?
> > > 
> > > bdflush is broken in current kernels.  I posted to linux-mm about this,
> > > but Rik et al haven't shown any interest.  I normally see bursts of 
> > > up to around 40K cs/second when doing writes; I hacked a little 
> > > premption counter into the kernel and verified that they're practially
> > > all bdflush...
> > 
> > P.S.
> > 
> > I took a ktrace snapshot of iozone doing 8k writes. This seems like
> > a strange and expensive way to only unplug a device ;-)  Anyone know
> > why?

Hi self :) You think I know now, so let's ask Rik.

> > c010a976  system_call +<22/40> (0.16) pid(257)
> > c0131bc0  sys_write +<10/d8> (0.12) pid(257)
> > ...
> > c010a99a  ret_from_sys_call +<6/19> (0.20) pid(257)
> > c0117f7b  schedule +<13/404> (2.14) pid(257->5)
> > c01091a3  __switch_to +<13/cc> (1.16) pid(5)
> > c01888c6  generic_unplug_device + (0.27) pid(5)
> > c0117f7b  schedule +<13/404> (0.51) pid(5->257)
> > c01091a3  __switch_to +<13/cc> (0.30) pid(257)
> > c010a99a  ret_from_sys_call +<6/19> (1.20) pid(257)
> 
> (arg!) P.P.S
> 
> That was perhaps too brief to be clear exactly what I mean.
> 
> In a trace segment 263 milliseconds long we switch to kflushd
> 279 times.  251 of 279 cases are exactly the above.

Greetings Rik,

Because it's seemingly stuck in __get_request_wait().  Under heavy
I/O, this means that page_launder() isn't going to be able to do
anything for extended periods of time.  Doesn't this mean that bdflush
isn't a good place to do asychronous scrubbing?

I moved it into __alloc_pages() in place of wakeup_bdflush().  It
doesn't seem to either help or hurt anything though :-/.

-Mike

-
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/

Topic for discussion: OS Design

[Nick Piggin]

> So what we really need to do is get some custom "RAM blitter" into our
> hardware to do the memory copies needed for fast context switching and 
> message passing.

don't you think you should quit while you're behind?

> Too bad nobody on this list works at an electronics design company... ;-P

you would probably be surprised.

Nick.


-
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/

Re: Idea for new kernel configurator

[Chirag Kantharia]

On Sun, Oct 22, 2000 at 12:17:24PM -0400, Jason Hihn wrote:
| dabbled in the kernel other than applying some patches. Recently at work
| I've had to develop an application which would allow a user to configure
| a device, even if that device was invented after the application was
| written. This is done extracting information (an XML file) out of the
| device which allows the software to create an interface for configuring
| the device... and that's where my idea comes from.
| (Quick, someone document this before it is patented!)

One question: how do you plan to "extract" information from the device
without a device driver?

| If the linux kernel was represented by XML objects in documents, then
| the same idea as above could be applied and extended. The user interface
| could be 2 windows, one 'in-the-kernel' pool and one 'not-in-the-kernel'

True, XML technology can be applied to a lot of scenarios. Kernel's not
one of them. The objectives while applying XML and that of designing a
super fast, scalable kernel are different.

chyrag.
-- 
Chirag Kantharia  http://slashetc.net/chyrag/

My colleagues believe that I'm wasting my time, Mr. Anderson.
 -- Agent Smith, The Matrix

-
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/

Contact address for Donald Becker

[Brian F. G. Bidulock]

Does anyone know the current contact e-mail address
for Donald Becker?

I was wishing to contact him concerning a possible
GPL violation concerning some of his Linux driver
code.

-- 
Brian F. G. Bidulock
[EMAIL PROTECTED]
http://www.openss7.org/
-
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/

2.4.0test10pre4 lockups

[Andi Kleen]

Hi Linus,

I've seen 3 user land lockups with test10pre4 so far on my UP K6-400, running
it for a day.  test9 which ran before for more than a week
was rock stable. They all happened during some IO load (e.g. a gcc compile
or a loop mke2fs), usually with some CPU eaters running in the background.
I unfortunately did not catch any logs, because all crashes happened with
X active. The machine did usually still answer to ping, but the userland
seemed to be dead (ssh not answering). In the first case I managed to log in
but it locked during a ps ax.

The machine has an ALI IDE chipset with IDE disks.


-Andi

-
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/