Re: Massive speed slowdown with any kernel after 2.4.1

[Rik van Riel]

On Wed, 7 Feb 2001, Alexander Trotsai wrote:

> I have PIII/128Mb/IDE uDMA 66 PC I try 2.4.1ac1, ac2 and
> 2.4.2pre1 And all this kernel after message "Freeing unused
> kernel memmory" highly slowing Even cursor (I have framebuffer)
> blink slowly But

Turn off ACPI

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.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/

Massive speed slowdown with any kernel after 2.4.1

[Alexander Trotsai]

Hello all

I have PIII/128Mb/IDE uDMA 66 PC
I try 2.4.1ac1, ac2 and 2.4.2pre1
And all this kernel after message "Freeing unused kernel memmory" highly slowing
Even cursor (I have framebuffer) blink slowly
But (via vmstat) no processor used, no disk operation.
I try to compile both gcc from redhat and kgcc and have no difference
But with the same config 2.4.0ac10 work Ok.


Info -- RIPE: MAGE-RIPE, InterNic: AT2963, ICQ: 18035130
PGP: ftp://blackhole.adamant.net/pgp/mykey.pgp.asc
Trouble of the day: excessive collisions & not enough packet ambulances
-
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.4 kernel & gcc code generation: a bug?

[H. Peter Anvin]

Followup to:  <3A8108F8.2476.21D0F5@localhost>
By author:"Ulrich Windl" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> You'll notice that %edx is not pushed at the start of the function. 
> Unless the caller saves that, edx will be spilled. Depending on the 
> level of optimization this can be bad. Am I wrong?
> 

Yes.  %eax, %edx and %ecx are defined as caller-saved registers.  Each
function is free to clobber them at will.

Now, if you saw the same for %ebx, %ebp, %esi or %edi, that would be
bad.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] New zerocopy patch.

[David S. Miller]

Against 2.4.2-pre1:

ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p1-2.diff.gz

Only one notable change since the last installment, but
an important one:

1) When doing paged SKB sendmsg(), use csum_and_copy_from_user
   instead of copy_from_user.

   The problem is that there appears to be some performance bug
   with some x86 processors when doing non-8-byte aligned memcpy
   operations via rep/movsl (P-II Mendocino is one known chip with
   the problem).

   So this change aims to remove this x86 anomaly from the zerocopy
   performance characteristics so we can see if there are some real
   implementation issues compared to running without the zerocopy
   patch applied.

   This is not to say that the x86 memcpy performance thing is being
   ignored, Linus and others are working on what to do about that
   seperately.

Please test, thanks.

Later,
David S. Miller
[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/

2.4 kernel & gcc code generation: a bug?

[Ulrich Windl]

Trying to find out what got broken in kernel 2.4, I was so clueless as 
to compare assembly output for 2.2.18 with 2.4.1. However the assembler 
is quite different, as 2.4 uses the more advanced optimizations of gcc-
2.95.2. Anyway:

1) spinlocks look strange in 2.2(!):

.globl rtc_lock
.typertc_lock,@object
.sizertc_lock,0
rtc_lock:
.globl i8253_lock

while in 2.4.1 they look like this:

.globl rtc_lock
.align 4
.typertc_lock,@object
.sizertc_lock,4
rtc_lock:
.long 0
.globl i8253_lock


2) gcc seems to fail to save registers that are marked "spilled" in 
inline asm's constraints, like rdtsc():

/* nanoseconds since last timer interrupt (using the CPU cycle-counter) */
static inline unsigned long do_exact_nanotime(void)
{
register unsigned long eax asm("ax");
register unsigned long edx asm("dx");
unsigned long result;


rdtsc(eax, edx);/* Read the Time Stamp Counter 
*/

/* .. relative to previous jiffy (32 bits is enough) */
eax -= last_tsc_low;/* tsc_low delta */

/*
 * Time offset = (tsc_low delta << 4) * exact_nanotime_quotient
 * = (tsc_low delta << 4) * (nsecs_per_clock)
 * = (tsc_low delta << 4) * (nsecs_per_jiffy /
 *  clocks_per_jiffy)
 *
 * Using a mull instead of a divl saves up to 31 clock cycles
 * in the critical path.
 */
__asm__("mull %2"
:"=a" (eax), "=d" (edx)
:"rm" (exact_nanotime_quotient),
 "0" (eax << 4));

/* our adjusted time offset in nanoseconds */
result = nanodelay_at_last_interrupt + edx;
return result;
}

.text
.align 4
.typedo_exact_nanotime,@function
do_exact_nanotime:
#APP
rdtsc
#NO_APP
subl last_tsc_low,%eax
sall $4,%eax
#APP
mull exact_nanotime_quotient
#NO_APP
movl nanodelay_at_last_interrupt,%eax
addl %edx,%eax
ret
.Lfe7:
.sizedo_exact_nanotime,.Lfe7-do_exact_nanotime
.local  last_rtc_update
.comm   last_rtc_update,4,4
.comm   timer_ack,4,4
.ident  "GCC: (GNU) 2.95.2 19991024 (release)"

#endif


You'll notice that %edx is not pushed at the start of the function. 
Unless the caller saves that, edx will be spilled. Depending on the 
level of optimization this can be bad. Am I wrong?

Regards,
Ulrich
P.S: Not subscribed here, so plese CC: if possible.

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

having a hard time with 2.4.x

[Ulrich Windl]

Hello,

I have some news on the topic of timekeeping in Linux-2.4:

As Alan Cox pointed out the ACPI changes between 2.4.0 and 2.4.1 created a 
extremely slow console output (if not more). Configuring away ACPI support 
solved that problem.

However there is still a problem that I cannot explain. I wrote a test program 
for my modified kernel (I did not try the original one). I'll include the 
program plus results (if you want to see the patch go to 
ftp.kernel.org/pub/linux/daemons/ntp/PPS and get PPS-2.4.0-pre3.tar.bz2 (patch 
plus signature)):

#include
#include
#define NTP_NANO
#include

int main()
{
struct timextx;
longlastns = 0;

tx.modes = 0;
while(1)
{
adjtimex();
printf("%d %d %d\n",
   tx.time.tv_sec, tx.time.tv_nsec,
   tx.time.tv_nsec - lastns);
lastns = tx.time.tv_nsec;
fflush(stdout);
}
}
/*--
The following anomalies were examined by running the program for a few
seconds, redirecting output into a file:
981488742 428870884 428870884
981488742 429242679 371795
981488742 429258279 15600
981488742 429266001 7722
981488742 429273781 7780
981488742 429281142 7361
...this is just the startup, filling the caches; 7us seems acceptable
981488742 442133766 7235
981488742 442155740 21974
981488742 442164248 8508
981488742 442171719 7471
... some occasional jitter seems acceptable, too
981488742 451557086 7280
981488742 451564393 7307
981488742 461600593 10036200
981488742 461609928 9335
981488742 461617263 7335
...here we lost 10ms, possibly due to scheduling
981488742 991589894 7317
981488742 991597171 7277
981488743 1628395 -989968776
981488743 1636937 8542
...the new second seems to begin a bit early; I'm missing about 8ms
981488743 991650854 7411
981488743 991658147 7293
981488744 1724546 -989933601
981488744 1732344 7798
...this is quite reproducible
981488751 294943079 7327
981488751 294950364 7285
981488751 294957703 7339
981488751 294964994 7291
981488751 294964995 1
981488751 294964996 1
981488751 294964997 1
981488751 294964998 1
981488751 294964999 1
...here something strange happened: time refused to advance, forcing
...the code to generate synthetic time (add 1ns). Here comes the end:
981488751 294967294 1
981488751 294967295 1
981488747 0 -294967295
981488747 37804096 37804096
981488747 37811711 7615
981488747 37819006 7295
...time went back by four seconds! This happened again:
981488752 294967292 1
981488752 294967293 1
981488752 294967294 1
981488752 294967295 1
981488748 0 -294967295
981488748 100304297 100304297
981488748 100311973 7676
981488748 100319231 7258
...but sometimes the second overflows correctly:
981488748 87866 7315
981488748 95152 7286
981488749 2417 -92735
981488749 9995 7578
981488749 17227 7232
...
981488749 91971 30023
981488750 747 -91224
981488750 8405 7658
981488750 15531 7126

Here is a simplified sample with microseconds instead, after having removed
two spinlocks (as they are in 2.2.18):

981487863 665701 665701
981487863 666048 347
981487863 666062 14
981487863 666071 9
981487863 666078 7
...start as usual
981487863 668825 7
981487863 668832 7
981487863 668855 23
981487863 668863 8
...some jitter
981487863 673861 7
981487863 673869 8
981487863 673876 7
981487863 683930 10054
981487863 683938 8
981487863 683946 8
...and scheduling
981487863 993871 8
981487863 993879 8
981487864 3905 -989974
981487864 3913 8
981487864 3920 7
...we still lack 10ms during overflow...
981487869 293860 7
981487869 293867 7
981487869 293875 8
981487869 293875 0
981487869 293875 0
...then time also refuses to advance
981487869 293941 0
981487869 293941 0
981487866 28937 -265004
981487866 28946 9
981487866 28954 8
...eventually loosing a few seconds

Possible explanation for negative time: 2^32/5 == 8.5,
i.e. the low 32bit of the TSC will overflow every 8.5 seconds on a
500MHz CPU, probably causing a bad interpolation between ticks.
But: Why doesn't the effect occur with kernel 2.2??? 

 *--*/

Regards,
Ulrich
P.S.: I'm not subscribed here, so CC: is appreciated.


-
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: OK to mount multiple FS in one dir?

[John R Lenton]

On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote:
> 
> [Wakko Warner]
> > I have a question, why was this idea even considered?
> 
> Al Viro likes Plan9 process-local namespaces.  He seems to be trying to
> move Linux in that direction.  In the past year he has been hacking the
> semantics of filesystems and mounting, probably with namespaces as an
> eventual goal, and this is one of the things that has fallen out of the
> implementation.

Aren't "translucid" mounts the idea behind this?
-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
For courage mounteth with occasion.
-- William Shakespeare, "King John"
-
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: Software Mestizo Manifesto

[Michael B. Trausch]

This is very intesting seeing as the story I read in the Newspaper (USA
Today) on encryption and terrorism today is an example of this.

It seems that people are using open source software to do idiotic
things. Many open source references were made in the article, I should
see if the article is online at all to maybe be able to use it as a
reference.

The only thing is that the good uses of the software are still
promenent, and what really bugs me is that the Government wants to step
into having a "Master Key" for everything as such... they can decrypt
stuff as is, but they have to spend lots of money if they want to do it
and that'll keep them in check verses having a "Master Key" that can
decrypt everything in a given encryption method.  That's just plain
stupid.

- Mike

Roberto Diaz wrote:
> 
> Hi this is off-topic sorry.
> 
> I am trying to make a manifesto in order to attach it to all my gpl'd
> developments.. due to limitations in my english I would like to ask for
> your help... and maybe you can have a couple of new ideas to improve it.
> 
> I am doing this because gpl'd developments usually involves people all
> around the world.. and being aware that a lot of gpl'd / GNU resources are
> used by fascist, terrorist and that kind of "people" everyday.. well maybe
> is a begginig.
> 
> Please help the way you can.
> 
> for now is just this:
> 
> /**  Software Mestizo Manifesto  *
>  * This code is **Software Mestizo** meaning it has been developed with
>  * the help of a lot of individuals no matter their racial or cultural
>  * origin, they all work together in peace and harmony in the belief of
>  * humankind fraternity, using this software with the purpose to harm
>  * this principles is to harm this software itself, uncivilizated and
>  * completely unethical. Please use it only in the context of this
>  * principles or dont use it if you dont agree the spirit of the Authors.
>  */
> 
> Regards
> 
> Roberto
> 
> 
> Roberto Diaz <[EMAIL PROTECTED]>
> http://vivaldi.dtts.net
> Powered by ddt dynamic DNS
> Powered by GNU running on a Linux kernel.
> Powered by Debian (The real wonder)
> 
> Concerto Grosso Op. 3/8 A minor
> Antonio Vivaldi (so... do you need beautiful words?)
> 
> 
> -
> 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/

[PATCH] updates for KLSI usb->ethernet

[Eric Sandeen]

This patch, against 2.4.1-ac4, does the following for the KLSI
USB->ethernet adapter:

(patch at http://lager.dyndns.org/kaweth/KLSI-2.4.1-ac4.patch.bz2)

o Fixes firmware downloading.  If firmware is already loaded
  and an attempt is made to download it again, the device
  will hang.  This will happen on a warm boot. Driver now 
  checks the bcdDevice value, which changes after firmware 
  is loaded.  It does this via usb_get_device_descriptor() 
  to avoid caching.  If device already has firmware, it will 
  skip the download.

o Reports bcdDevice revision in debugging messages

o Updates firmware revision, fresh from KLSI

o Actually _uses_ interrupt parameter passed to
  kaweth_trigger_firmware()

o added function prototype for 
  kaweth_internal_control_msg() to avoid warning

o spells "receive" correctly.  :)

There is another way to handle the firmware download check - there is a
chunk of firmware which can be downloaded that causes the device to
disconnect, wait, then reconnect to the USB bus.  When it reappears, it
has the new bcdDevice value in the descriptor.

This might be a better way to go, so that the device descriptor doesn't
silently change.  I've also seen some errors when I try to re-read the
device descriptor with usb_get_device_descriptor(), for some reason.

Any thoughts on what would be more correct, 

a) device descriptor silently changes
b) device magically disconnects/reconnects on its own

Both seem a bit odd, but take your pick.  :)

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

hotplugging with regular PCI cards

[Adam J. Richter]

I saw an interesting demonstration at LinuxWorld last week.
Compaq had a machine that did hot plugging with regular PCI cards (not
Compact PCI).  If anyone out there is familiar with this machine,
I would be interested in knowing what the status is on getting
the support for that backplain integrated into the stock kernels.

When that occurs, that will be yet another reason to treat all
new style PCI drivers as potentially hot pluggable, even if those cards
are not currently available in a CardBus or CompactPCI form, and in
particular to change all of the xxx_pci_tbl declarations in PCI
drivers that are currently marked as __initdata back to __devinitdata.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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] vm_enough_memory() & i/d cache

[Rik van Riel]

Hi Linus, Alan,

the attached patch makes vm_enough_memory() take the inode
and dentry cache memory into account so people will again
be able to start 300MB processes on their 384MB machine,
even after slocate has eaten up 100MB in inode and dentry
caches...

It doesn't even try to get the statistics absolutely right,
but in most cases it should be close enough. Please apply
this patch for your next pre-release.


This patch closes the following Linux-MM bugreport:
  http://distro.conectiva.com/bugzilla/show_bug.cgi?id=1174

  (http://www.linux-mm.org/bugzilla.shtml)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/



--- linux-2.4.2-pre1/fs/dcache.c.orig   Wed Feb  7 02:21:20 2001
+++ linux-2.4.2-pre1/fs/dcache.cWed Feb  7 03:24:54 2001
@@ -52,13 +52,8 @@
 static struct list_head *dentry_hashtable;
 static LIST_HEAD(dentry_unused);
 
-struct {
-   int nr_dentry;
-   int nr_unused;
-   int age_limit;  /* age in seconds */
-   int want_pages; /* pages requested by system */
-   int dummy[2];
-} dentry_stat = {0, 0, 45, 0,};
+/* Statistics gathering. */
+struct dentry_stat_t dentry_stat = {0, 0, 45, 0,};
 
 /* no dcache_lock, please */
 static inline void d_free(struct dentry *dentry)
--- linux-2.4.2-pre1/fs/inode.c.origWed Feb  7 02:21:26 2001
+++ linux-2.4.2-pre1/fs/inode.c Wed Feb  7 03:17:42 2001
@@ -67,11 +67,7 @@
 /*
  * Statistics gathering..
  */
-struct {
-   int nr_inodes;
-   int nr_unused;
-   int dummy[5];
-} inodes_stat;
+struct inodes_stat_t inodes_stat;
 
 static kmem_cache_t * inode_cachep;
 
--- linux-2.4.2-pre1/kernel/sysctl.c.orig   Wed Feb  7 03:20:00 2001
+++ linux-2.4.2-pre1/kernel/sysctl.cWed Feb  7 03:20:56 2001
@@ -130,9 +130,6 @@
 static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
 #endif
 
-extern int inodes_stat[];
-extern int dentry_stat[];
-
 /* The default sysctl tables: */
 
 static ctl_table root_table[] = {
--- linux-2.4.2-pre1/mm/mmap.c.orig Tue Feb  6 19:20:27 2001
+++ linux-2.4.2-pre1/mm/mmap.c  Wed Feb  7 03:34:13 2001
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -63,6 +64,15 @@
free += atomic_read(_cache_size);
free += nr_free_pages();
free += nr_swap_pages;
+   /*
+* The code below doesn't account for free space in the inode
+* and dentry slab cache, slab cache fragmentation, inodes and
+* dentries which will become freeable under VM load, etc.
+* Lets just hope all these (complex) factors balance out...
+*/
+   free += (dentry_stat.nr_unused * sizeof(struct dentry)) >> PAGE_SHIFT;
+   free += (inodes_stat.nr_unused * sizeof(struct inode)) >> PAGE_SHIFT;
+
return free > pages;
 }
 
--- linux-2.4.2-pre1/include/linux/fs.h.origWed Feb  7 03:08:11 2001
+++ linux-2.4.2-pre1/include/linux/fs.h Wed Feb  7 03:24:16 2001
@@ -53,6 +53,14 @@
int max_files;  /* tunable */
 };
 extern struct files_stat_struct files_stat;
+
+struct inodes_stat_t {
+   int nr_inodes;
+   int nr_unused;
+   int dummy[5];
+};
+extern struct inodes_stat_t inodes_stat;
+
 extern int max_super_blocks, nr_super_blocks;
 extern int leases_enable, dir_notify_enable, lease_break_time;
 
--- linux-2.4.2-pre1/include/linux/dcache.h.origWed Feb  7 03:08:19 2001
+++ linux-2.4.2-pre1/include/linux/dcache.h Wed Feb  7 03:23:12 2001
@@ -27,6 +27,15 @@
unsigned int hash;
 };
 
+struct dentry_stat_t {
+   int nr_dentry;
+   int nr_unused;
+   int age_limit;  /* age in seconds */
+   int want_pages; /* pages requested by system */
+   int dummy[2];
+};
+extern struct dentry_stat_t dentry_stat;
+
 /* Name hashing routines. Initial hash value */
 #define init_name_hash()   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/

Re: RedHat kernel RPM 2.2.16

[Jim Roland]

I appreciate your comments, but the SOURCE is exactly what I am needing in
order to compile in PCTel modem support.  FYI, I'm not a newbie, so I do
not uninstall a kernel from a running system (no offense on your
assumption :-P).  Besides if I did, I would just simply spend 5 minutes
creating a rescue floppy and away I go.  No problem.  Anyway, I have
already installed the binary form of the 2.2.16 kernel, I am needing the
sources so I can kludge together a module for the PCTel support.

FWIW, the rpm -i did unpack the kernel to the /usr/src/redhat/SOURCES
directory, however, I had to manually untar the sources to /usr/src to get
my kernel, move over the appropriate .config file, and manually run the
patches to patch the sources.  Forcing RPM to be very talkative (via -vv)
gave me a bunch of "action unknown" errors, and the rpm's install scripts
did not execute.  This occurs on an RH7 system as well.  Seems to be
something wrong with RH's kernel rpm?

JR



On Tue, 6 Feb 2001, J. Dow wrote:

> RTFM - it is writ large on the RedHat site. You have probably rendered your
> machine unbootable at this point if you tried first with the regular kernel
> RPM. Recovery is awkward. You *NEVER* *EVER* -U a kernel RPM. You *ALWAYS* -i
> it instead. Then your old kernel is still present in case the new one shows
> problems, like 2.2.16 will.
> 
> Furthermore installing the source RPMs does not install a new kernel. You have
> to proceed from there with building the kernel. That means you have to have
> kgcc installed and all the other proper materials.
> 
> I saw your email on the RedHat list but it was at the beginning of 80 some
> messages so I didn't reply figuring someone else would have. I guess nobody
> felt like typing "RTFM". As I say, RedHat has kernel compilation and kernel
> installation information on their website in a fairly easy to find place.
> A little digging would be good for your soul and education. There is other
> stuff there associated with the kernel compile and install instructions
> that can be a great help.
> 
> {^_^}
> 
> - Original Message - 
> From: "Jim Roland" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 06, 2001 21:03
> Subject: RedHat kernel RPM 2.2.16
> 
> 
> > I am trying to get RedHat's Kernel RPM 2.2.16 installed, however, the rpm
> > program does unpack the files, but does not run any script to install them
> > into the source tree (kernel-2.2.16-3.i386.src.rpm).  Is there a trick to
> > making it work?
> > 
> > 
> > 
> > -
> > 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: Software Mestizo Manifesto

[Roberto Diaz]

> Quoted from the GPL:
> ---
>   6. Each time you redistribute the Program (or any work based on the
> Program), the recipient automatically receives a license from the
> original licensor to copy, distribute or modify the Program subject to
> these terms and conditions.  You may not impose any further
> restrictions on the recipients' exercise of the rights granted herein.
> You are not responsible for enforcing compliance by third parties to
> this License.
> ---
> 
> Your "ethical" statement is incompatible with the GPL.

Thank you very much.. do you find incompatibilities here:

/**  Software Mestizo Manifesto  *
 * This code is **Software Mestizo** meaning it has been developed with
 * the help of many diverse individuals worldwide; no matter their 
 * racial or cultural origin, they all work together in peace and harmony 
 * in the belief of humankind fraternity.  Using this software with the 
 * purpose of harming these principles is to harm the software itself,
 * We advice to use it only in the context of these principles or refrain 
 * from its use if you don't agree with the spirit in which it was 
 * written.
 */ 

Please let the people to decide wether they want to attach this to their
source code.. I am only trying to do a manifesto which I think is valuable

Please send a CC: to Guido Socher <[EMAIL PROTECTED]> he is the
Editor-in-Chief of www.linuxfocus.org maybe he could help (or kill me
still dont know.. anyway).


Regards

Roberto


Roberto Diaz <[EMAIL PROTECTED]>
http://vivaldi.dtts.net 
Powered by ddt dynamic DNS
Powered by GNU running on a Linux kernel.
Powered by Debian (The real wonder)

Concerto Grosso Op. 3/8 A minor
Antonio Vivaldi (so... do you need beautiful words?)


-
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.x and oops on 'mount -t smbfs'

[JShaw]

Howdy,

I'm running RedHat 7.0 on a Compaq Proliant 5500, 4x Xeon 550MHz, 4GB 50Ns
EDO RAM.  Under kernel 2.2.16-22 I'm able to use

'mount -t smbfs //ntserver/share /net -o
username=me,password=mine,workgroup=yours'

... without a problem.  NT files become available under '/net', as expected.
I've compiled a number of 2.4.1 and 2.4.0 kernels (actually supports the 4GB
RAM!!!  Yay), and I have only one more problem to sort out.  Under
2.4.x, the mount completes successfully, but 'ls /net' causes an OOPS: .

I've compiled Samba support into the kernel, and the version of Samba utils
is 2.0.7-21ssl

Any clues or similar experiences???

Thanx,

Jim Shaw.
  JBWere Limited
DISCLAIMER

JBWere Limited and its related entities distributing this document and 
each of their respective directors, officers and agents ("the Were Group") 
believe that the information contained in this document is correct and that
any estimates, opinions, conclusions or recommendations contained in this 
document are reasonably held or made as at the time of compilation. However, 
no warranty is made as to the accuracy or reliability of any estimates, 
opinions, conclusions, recommendations (which may change without notice) or 
other information contained in this document and, to the maximum extent 
permitted by law, the Were Group disclaims all liability and responsibility 
for any direct or indirect loss or damage which may be suffered by any recipient 
through relying on anything contained in or omitted from this document.
-
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/

Software Mestizo Manifesto

[Roberto Diaz]

Hi this is off-topic sorry.

I am trying to make a manifesto in order to attach it to all my gpl'd
developments.. due to limitations in my english I would like to ask for
your help... and maybe you can have a couple of new ideas to improve it.

I am doing this because gpl'd developments usually involves people all
around the world and more times this is its main feature.. and being aware
that a lot of gpl'd / GNU resources are used by fascist, terrorist and
that kind of "people" everyday.. well maybe  is a begginig.

Please help the way you can.

for now is just this:

/**  Software Mestizo Manifesto  *
 * This code is **Software Mestizo** meaning it has been developed with 
 * the help of a lot of individuals no matter their racial or cultural 
 * origin, they all work together in peace and harmony in the belief of 
 * humankind fraternity, using this software with the purpose to harm 
 * this principles is to harm this software itself, uncivilizated and
 * completely unethical. Please use it only in the context of this 
 * principles or dont use it if you dont agree the spirit of the Authors.
 */


Regards

Roberto


Roberto Diaz <[EMAIL PROTECTED]>
http://vivaldi.dtts.net 
Powered by ddt dynamic DNS
Powered by GNU running on a Linux kernel.
Powered by Debian (The real wonder)

Concerto Grosso Op. 3/8 A minor
Antonio Vivaldi (so... do you need beautiful words?)








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

RedHat kernel RPM 2.2.16

[Jim Roland]

I am trying to get RedHat's Kernel RPM 2.2.16 installed, however, the rpm
program does unpack the files, but does not run any script to install them
into the source tree (kernel-2.2.16-3.i386.src.rpm).  Is there a trick to
making it work?



-
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: Software Mestizo Manifesto

[Rik van Riel]

On Wed, 7 Feb 2001, Roberto Diaz wrote:

> I am trying to make a manifesto in order to attach it to all my
> gpl'd developments..

> I am doing this because gpl'd developments usually involves
> people all around the world.. and being aware that a lot of
> gpl'd / GNU resources are used by fascist, terrorist and that
> kind of "people" everyday.. well maybe is a begginig.

Quoted from the GPL:
---
  6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
---

Your "ethical" statement is incompatible with the GPL.

(And, IMHO, unethical since it restricts the freedom of
use on free software, but lets not start about that since
we're off-topic for linux-kernel anyway...)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.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/

Software Mestizo Manifesto

[Roberto Diaz]

Hi this is off-topic sorry.

I am trying to make a manifesto in order to attach it to all my gpl'd
developments.. due to limitations in my english I would like to ask for
your help... and maybe you can have a couple of new ideas to improve it.

I am doing this because gpl'd developments usually involves people all
around the world.. and being aware that a lot of gpl'd / GNU resources are
used by fascist, terrorist and that kind of "people" everyday.. well maybe 
is a begginig.

Please help the way you can.

for now is just this:

/**  Software Mestizo Manifesto  *
 * This code is **Software Mestizo** meaning it has been developed with 
 * the help of a lot of individuals no matter their racial or cultural 
 * origin, they all work together in peace and harmony in the belief of 
 * humankind fraternity, using this software with the purpose to harm 
 * this principles is to harm this software itself, uncivilizated and
 * completely unethical. Please use it only in the context of this 
 * principles or dont use it if you dont agree the spirit of the Authors.
 */


Regards

Roberto


Roberto Diaz <[EMAIL PROTECTED]>
http://vivaldi.dtts.net 
Powered by ddt dynamic DNS
Powered by GNU running on a Linux kernel.
Powered by Debian (The real wonder)

Concerto Grosso Op. 3/8 A minor
Antonio Vivaldi (so... do you need beautiful words?)







-
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.1-ac3 oops decoded with ksymoops

[Dax Kelson]

Here is an oops I got on one of my computers.  It came about 5 mins after
I forcibly ejected a PCMCIA card (A Spectrum24t 802.11b card), I don't
know if it is related.

The oops:
==
kernel BUG at sched.c:714!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax:  001b  ebx:  c1167de0  ecx:  c3602000  edx:  c0227c08
esi:  c1167d70  edi:  c1166000  ebp:  c1167d5c  esp:  c1167d2c
ds:  0018   es:  0018   ss:  0018
Process kapmd-idled (pid: 3, stackpage=c1167000)
Stack:  c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80
c3dbb380
c0231a80 c0228b40  c1167de0 c1167de0 c010792d
c1167dcc c1167db8
c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78
c1167de0 
Call Trace: [] [] [] []
[] []
[]
[] [] [] [] []
[] []
[]
[] [] [] [] []
[] []
[]
[] [] [] [] []
[]

Code:  0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56
Kernel panic:  Aiee, killing interrupt handler!
In interrupt handler - not syncing


ksymoops output:

===
ksymoops 2.3.4 on i586 2.4.1-ac3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1-ac3/ (default)
 -m /usr/src/linux/System.map (specified)

invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax:  001b  ebx:  c1167de0  ecx:  c3602000  edx:  c0227c08
esi:  c1167d70  edi:  c1166000  ebp:  c1167d5c  esp:  c1167d2c
ds:  0018   es:  0018   ss:  0018
Process kapmd-idled (pid: 3, stackpage=c1167000)
Stack:  c01eaee5 c01eb036 02ca c1167de0 c1167d70 c1166000 c3a16c80
c3dbb380
c0231a80 c0228b40  c1167de0 c1167de0 c010792d
c1167dcc c1167db8
c1167dcc 0001 c1166000 c1167dec c1167dec c0107a78
c1167de0 
Call Trace: [] [] [] []
[] []
[]
[] [] [] [] []
[] []
[]
[] [] [] [] []
[] []
[]
[] [] [] [] []
[]
Code:  0f 0b 8d 65 dc 5b 5e 5f 89 ec 5d c3 55 89 e5 83 ec 10 57 56

>>EIP; c0111634<=
Trace; c010792d <__down+55/9c>
Trace; c0107a78 <__down_failed+8/c>
Trace; c01e41c5 
Trace; c011d4e0 <__call_usermodehelper+0/2c>
Trace; c011d4e0 <__call_usermodehelper+0/2c>
Trace; c01a574d 
Trace; c0181f66 
Trace; c01853b1 
Trace; c01a55bd 
Trace; c018ca48 
Trace; c48cd52e <[spectrum24t_cs]adapter_release+c6/188>
Trace; c48d31c4 <[spectrum24t_cs]__FUNC__.1131+10/60>
Trace; c48cd468 <[spectrum24t_cs]adapter_release+0/188>
Trace; c01199bd 
Trace; c0119897 
Trace; c0119ca2 
Trace; c010ccd6 
Trace; c0117123 
Trace; c0117058 
Trace; c0116f60 
Trace; c010a161 
Trace; c0108e60 
Trace; c010f26a 
Trace; c0100018 
Trace; c010f340 
Trace; c010faad 
Trace; c01103e7 
Trace; c0107423 
Trace; c010742c 
Code;  c0111634 
 <_EIP>:
Code;  c0111634<=
   0:   0f 0b ud2a  <=
Code;  c0111636 
   2:   8d 65 dc  lea0xffdc(%ebp),%esp
Code;  c0111639 
   5:   5bpop%ebx
Code;  c011163a 
   6:   5epop%esi
Code;  c011163b 
   7:   5fpop%edi
Code;  c011163c 
   8:   89 ec mov%ebp,%esp
Code;  c011163e 
   a:   5dpop%ebp
Code;  c011163f 
   b:   c3ret
Code;  c0111640 <__wake_up+0/98>
   c:   55push   %ebp
Code;  c0111641 <__wake_up+1/98>
   d:   89 e5 mov%esp,%ebp
Code;  c0111643 <__wake_up+3/98>
   f:   83 ec 10  sub$0x10,%esp
Code;  c0111646 <__wake_up+6/98>
  12:   57push   %edi
Code;  c0111647 <__wake_up+7/98>
  13:   56push   %esi

Kernel panic:  Aiee, killing interrupt handler!

Dax Kelson

-
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: CPU error codes

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Carlos Carvalho <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Really? I thought it could be because of RAM. Here's the story:
> 
> The kernel is 2.2.18pre24.
> 
> I'm having VERY frequent of this (sometimes once a day, sometimes once
> a week, sometimes twice a day, on a much used machine)
> 
> CPU 1: Machine Check Exception: 0004
> Bank 4: b2040151<0>Kernel panic: CPU context corrupt
> 
> CPU 0: Machine Check Exception: 0004
> Bank 4: b2040151<0>Kernel panic: CPU context corrupt
> 
> CPU 0: Machine Check Exception: 0004
> Bank 4: b2040151<0>Kernel panic: CPU context corrupt
> 
> This is on an ASUS P2B-DS with two PIII 700MHz and 100MHz FSB, 1GB of
> RAM. The mce happens with both processors (the above is just part of
> it).
> 
> I've already changed the motherboard and processors, and it continued.
> Then I changed the memory, and it continues. I also changed the
> power supply just in case, to no avail...
> 
> It happens with PC100 and PC133 memory. I increased the memory latency
> (the SPD says it's cl2, I put it 3T and 10T DRAM) but the problem
> persists.
> 
> Since I changed the main board and processor, I think the most likely
> cause is ram. It seems the x86 can access ram directly, so if there's
> a NMI there what will happen?
> 

Much more likely is that your CPU is bad, or overclocked.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: freshmeat editorial on journaling filesystems

[Ray Strode]

>We'd like to run an editorial this coming Saturday about the
>journaling filesystems available for Linux.  We'd like an author who
>isn't a developer on any of them so he/she can give an object analysis
>of the pros and cons of each and share thoughts on his/her opinions
>about which should be eventually be supported by the kernel.
I disagree.  I think you should ask someone who works on more than 
one of the filesystems.  That person will know the pros and cons of all
of them, and surely will be objective.

--Ray Strode

-
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: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister

[Thomas Hood]

I have a bit more information about this bug now.
The message "assertion(yadda) failed ..." occurs only
if the eth0 interface has been configured using pump
or dhclient.  If the card isn't connected to the network
the message never occurs.  If eth0 is merely brought up
and down using ifconfig the message doesn't occur.  Only
if pump or dhclient has configured eth0 does the message
occur.  Sometimes it occurs on "ifdown eth0", sometimes
on "cardctl eject" and sometimes during the shutdown
sequence.

Thomas

> Dear l-k. 
> 
> I'm still having this problem with kernel 2.4.0: 
> 
> Conditions: 
> Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II) 
> laptop with PCMCIA support. Same behavior with integral kernel 
> PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System 
> is Progeny Debian beta II. 
> 
> I have a Xircom modem/ethernet card which works correctly using 
> the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules; 
> however when I try to "cardctl eject" or "reboot" I get first, 
>"KERNEL: assertion(dev->ip_ptr==NULL)failed at 
> dev.c(2422):netdev_finish_unregister" 
> (not exact since I had to copy it down on paper ... doesn't 
> show up in the logs) then a perpetual series of: 
>"unregister_netdevice: waiting for eth0 to become free. 
> Usage count = -1" 
> messages every five seconds or so. "ps -A" reveals that 
> modprobe is running; it can't be killed even with "kill -9". 
> The "ifconfig" command locks up. Shutdown won't complete 
> so I end up having to use SysRq-S-U-B to reboot. 
> 
> This problem only occurs if the Xircom card is connected to 
> the Ethernet (in which case it is configured using DHCP). 
> If the card is left unconnected to the network, the problem 
> does not occur---the card can be ejected. 
> 
> Thomas Hood 
> Please cc: your replies to me at jdthood_AT_yahoo.co.uk
-
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] Modify scripts/ver_linux to display reiserfsprogs version

[Steven Cole]

Here is a patch to the linux/scripts/ver_linux script which adds
the reiserfsprogs utils to the items checked.  If the reiserfsprogs
have not been installed, the modified script outputs nothing for
the Reiserfsprogs line (output looks the same as now).

The current version of reiserfsck does not have a "-V" or "--version"
option, but the version number is printed on the same line as "reiserfsprogs",
like this:

[root@localhost scripts]# reiserfsck --somethingbogus

<-reiserfsck, 2000->
reiserfsprogs 3.x.0b
reiserfsck: unrecognized option `--somethingbogus'
[the rest of the response snipped]

If reiserfsprogs reiserfsck is modified someday to respond to a
version option, then these two new lines in ver_linux can be simplified.

I'm sure that someone else can code something more elegantly, but
the following output was provided with the patched ver_linux script:

[root@localhost scripts]# ./ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux localhost.localdomain 2.4.1-ac4 #1 Tue Feb 6 17:16:08 MST 2001 i686 unknown
Kernel modules 2.4.2
Gnu C  2.95.3
Gnu Make   3.79.1
Binutils   2.10.0.24
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.7
Mount  2.10o
Net-tools  1.57
Console-tools  0.2.3
Reiserfsprogs  3.x.0b
Sh-utils   2.0
Modules Loaded 

Here is the patch, against 2.4.1-ac4.

Steven

--- linux/scripts/ver_linux.origTue Feb  6 14:28:34 2001
+++ linux/scripts/ver_linux Tue Feb  6 14:34:24 2001
@@ -29,6 +29,8 @@
 # while console-tools needs 'loadkeys -V'.
 loadkeys -V 2>&1 | awk \
 '(NR==1 && ($2 ~ /console-tools/)) {print "Console-tools ", $3}'
+reiserfsck --bogusarg 2>&1 | grep reiserfsprogs | awk \
+'NR==1{print "Reiserfsprogs ", $NF}'
 expr --v 2>&1 | awk 'NR==1{print "Sh-utils  ", $NF}'
 X=`cat /proc/modules | sed -e "s/ .*$//"`
 echo "Modules Loaded "$X

-
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: ipfwadm IP accounting (2.4.1)

[Rusty Russell]

In message  you write:
> Using ipfwadm on a 2.4.1 kernel, some ip accouting rules for outgoing
> packets have theirs packet and byte counter stuck to 0 value. There is no
> such problem with incoming packets.

Hi Eric!

You're exactly right: it was a typo.  Thanks.

Linus, please apply.

Rusty.
--- linux-2.4.1/net/ipv4/netfilter/ip_fw_compat.c   Tue Feb  6 11:10:01 2001
+++ linux/net/ipv4/netfilter/ip_fw_compat.c Tue Feb  6 09:03:17 2001
@@ -132,7 +132,7 @@
if (ret == FW_ACCEPT || ret == FW_SKIP) {
if (fwops->fw_acct_out)
fwops->fw_acct_out(fwops, PF_INET,
-  (struct net_device *)in,
+  (struct net_device *)out,
   (*pskb)->nh.raw, ,
   pskb);
confirm_connection(*pskb);

--
Premature optmztion is rt of all evl. --DK
-
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: Hard system freeze in 2.2.17, 2.2.18, 2.4.1-AC3 VIA Athlon

[Jonathan Abbey]

Mark Hahn wrote me and convinced me that the problem I described is a
hardware problem, probably related to heat.  

Testing bears this out.

I am still mystified as to why xemacs in particular should stress the
system more than everything else, but I've got the sanity check I was
looking for, and will treat it as a hardware problem from here on
out.

| I am having terribly frustrating system stability problems, and I
| can't figure out whether I should suspect hardware or the kernel.

---
Jonathan Abbey[EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX http://www.arlut.utexas.edu/gash2
-
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: Problems with Linux 2.4.1

[Brad Douglas]

On 07 Feb 2001 02:27:57 +, Alexander Zvyagin wrote:

> 2) Frame-buffer mode does not work with my video card SiS630.
>But ok, frame-buffer mode is EXPERIMENTAL in linux.
>Computer boots, but screen is blank. All messages are fine.

> 01:00:0 VGA compatible controller: Silicon Integrated Systems [SiS]:
Unknown device 6300
> (rev 11)

Your particular chipset (actually, a 6300, which is different than the
630) is not supported by the SIS frame buffer.  If this chipset is a
VESA 2.0+ compatible controller, then you will be able to use the VESA
frame buffer.

Brad Douglas
[EMAIL PROTECTED]
http://www.linux-fbdev.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/

freshmeat editorial on journaling filesystems

[jeff covey]

We'd like to run an editorial this coming Saturday about the
journaling filesystems available for Linux.  We'd like an author who
isn't a developer on any of them so he/she can give an object analysis
of the pros and cons of each and share thoughts on his/her opinions
about which should be eventually be supported by the kernel.

If you would like to do this or have a recommendation of someone who
would be good for it, please let me know privately.

Thanks,
Jeff

 PGP signature

Re: [reiserfs-list] NFS and reiserfs

[Paul Jakma]

On Wed, 7 Feb 2001, Neil Brown wrote:

>   http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.2-pre1/patch-D-nfsirix
> not yet submitted to Linus.
>

ahh. didn't know. I have the first patch you sent me for the weird
IRIX device file permissions checking - but i didn't notice this
second pipe patch.

will give it whirl. thanks neil.

> NeilBrown
>
>
regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Overflow on /dev/null, please empty the bit bucket.

(how does my random fortunesig picker always seem to /know/ how to
pick an appropriate one? :) )

-
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: [reiserfs-list] NFS and reiserfs

[Neil Brown]

On Tuesday February 6, [EMAIL PROTECTED] wrote:
> On Mon, 5 Feb 2001, Samuel Flory wrote:
> 
> > someone (you?) talking about v3 issues with SGI boxes under 2.4 on the
> > nfs list.  I didn't much pay much attention as it wasn't an issue I
> > could help with.
> 
> that might have been me...
> 
> the issues were related to how IRIX nfs client expects server to
> behave wrt to device files and other special files. First problemo
> was fixed, second one (FIFOs) is apparently undefined for NFS.

Just FYI, these should be completely fixed by 
  http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2/2.2.19-pre8/patch-F-nfsirix
already submitted to Alan and
  http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.2-pre1/patch-D-nfsirix
not yet submitted to Linus.

NeilBrown
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
>
> > "struct buffer_head" can deal with pretty much any size: the only thing it
> > cares about is bh->b_size.
> 
> Right now, anything larger than a page is physically non-contiguous,
> and sorry if I didn't make that explicit, but I thought that was
> obvious enough that I didn't need to.  We were talking about raw IO,
> and as long as we're doing IO out of user anonymous data allocated
> from individual pages, buffer_heads are limited to that page size in
> this context.

Sure. That's obviously also one of the reasons why the IO layer has never
seen bigger requests anyway - the data _does_ tend to be fundamentally
broken up into page-size entities, if for no other reason that that is how
user-space sees memory.

However, I really _do_ want to have the page cache have a bigger
granularity than the smallest memory mapping size, and there are always
special cases that might be able to generate IO in bigger chunks (ie
in-kernel services etc)

> Yes.  We still have this fundamental property: if a user sends in a
> 128kB IO, we end up having to split it up into buffer_heads and doing
> a separate submit_bh() on each single one.  Given our VM, PAGE_SIZE
> (*not* PAGE_CACHE_SIZE) is the best granularity we can hope for in
> this case.

Absolutely. And this is independent of what kind of interface we end up
using, whether it be kiobuf of just plain "struct buffer_head". In that
respect they are equivalent.

> THAT is the overhead that I'm talking about: having to split a large
> IO into small chunks, each of which just ends up having to be merged
> back again into a single struct request by the *make_request code.

You could easily just generate the bh then and there, if you wanted to.

Your overhead comes from the fact that you want to gather the IO together. 

And I'm saying that you _shouldn't_ gather the IO. There's no point. The
gathering is sufficiently done by the low-level code anyway, and I've
tried to explain why the low-level code _has_ to do that work regardless
of what upper layers do.

You need to generate a separate sg entry for each page anyway. So why not
just use the existing one? The "struct buffer_head". Which already
_handles_ all the issues that you have complained are hard to handle.

Linus

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

[OT] Re: PCI-SCI Drivers v1.1-7 released

[Gregory Maxwell]

On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote:
> More to add on the gcc 2.96 problems.  After compiling a Linux 2.4.1 
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat 
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1 
> source tree. 
[snip]

Come on Jeff, don't let your annoyance make you a fudder..

The Linux kernel relies on certain undefined behaviors of the compiler to
achieve locality of various types. The optimizer in the GCC 3.0 code tree
is much smarter and is not laying out code the way GCC 2.x did. 

So it's very likely that this lossage is caused by poorer cache locality.
After GCC 3 is finalized, it's likely that kernel developers will begin
moving to it, and rethinking how they express such things as branch
probability and code alignment to the compiler. Until then, GCC 3.0
snapshots are NOT the recommended compiler for the linux-kernel and not even
RedHat compilers their kernel's with it.  User beware.

It should also be noted that this compiler almost always produces faster user
space code then the older compilers, because almost nothing includes the
type of hand-tweaked C that the kernel uses so often on critical paths, most
of that software uses assembly in such situations.

So.. It's likely that calling your performance issues 'gcc bugs' is about
the same as saying that SGI cc is buggy because it can't compile the kernel.

At least you managed to avoid calling RedHat names. :)
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Linus Torvalds wrote:
> > > [...] so I would be _really_ nervous about just turning it on
> > > silently. This is all very much a 2.5.x-kind of thing ;)
> > 
> > Then you might want to apply this :-)
> > 
> > --- drivers/block/ll_rw_blk.c~  Wed Feb  7 02:38:31 2001
> > +++ drivers/block/ll_rw_blk.c   Wed Feb  7 02:38:42 2001
> > @@ -1048,7 +1048,7 @@
> > /* Verify requested block sizes. */
> > for (i = 0; i < nr; i++) {
> > struct buffer_head *bh = bhs[i];
> > -   if (bh->b_size % correct_size) {
> > +   if (bh->b_size != correct_size) {
> > printk(KERN_NOTICE "ll_rw_block: device %s: "
> >"only %d-char blocks implemented (%u)\n",
> >kdevname(bhs[0]->b_dev),
> 
> Actually, I'd rather leave it in, but speed it up with the saner and
> faster
> 
>   if (bh->b_size & (correct_size-1)) {
>   ...
> 
> That way people who _want_ to test the odd-size thing can do so. And
> normal code (that never generates requests on any other size than the
> "native" size) won't ever notice either way.

Fine, as I said I didn't spot anything bad so that's why it was changed.

> (Oh, we'll eventually need to move to "correct_size == hardware
> blocksize", not the "virtual blocksize" that it is now. As it it a tester
> needs to set the soft-blk size by hand now).

Exactly, wrt earlier mail about submitting < hw block size requests to
the lower levels.

-- 
Jens Axboe

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Stephen C. Tweedie]

Hi,

On Tue, Feb 06, 2001 at 04:50:19PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> > 
> > That gets us from 512-byte blocks to 4k, but no more (ll_rw_block
> > enforces a single blocksize on all requests but that relaxing that
> > requirement is no big deal).  Buffer_heads can't deal with data which
> > spans more than a page right now.
> 
> "struct buffer_head" can deal with pretty much any size: the only thing it
> cares about is bh->b_size.

Right now, anything larger than a page is physically non-contiguous,
and sorry if I didn't make that explicit, but I thought that was
obvious enough that I didn't need to.  We were talking about raw IO,
and as long as we're doing IO out of user anonymous data allocated
from individual pages, buffer_heads are limited to that page size in
this context.

> Have you ever spent even just 5 minutes actually _looking_ at the block
> device layer, before you decided that you think it needs to be completely
> re-done some other way? It appears that you never bothered to.

Yes.  We still have this fundamental property: if a user sends in a
128kB IO, we end up having to split it up into buffer_heads and doing
a separate submit_bh() on each single one.  Given our VM, PAGE_SIZE
(*not* PAGE_CACHE_SIZE) is the best granularity we can hope for in
this case.

THAT is the overhead that I'm talking about: having to split a large
IO into small chunks, each of which just ends up having to be merged
back again into a single struct request by the *make_request code.

A constructed IO request basically doesn't care about anything in the
buffer_head except for the data pointer and size, and the completion
status info and callback.  All of the physical IO description is in
the struct request by this point.  The chain of buffer_heads is
carrying around a huge amount of information which isn't used by the
IO, and if the caller is something like the raw IO driver which isn't
using the buffer cache, that extra buffer_head data is just overhead. 

--Stephen
-
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: FA-311 / Natsemi problems with 2.4.1

[Ben Pharr]

At 05:28 PM 2/6/01 , you wrote:
>Jocelyn Mayer wrote:
> >
> > I found something from OpenBSD:
> > the natsemi chip (in fact DP83815)
> > is quite the same as SiS900 one.
>
>If that is true, maybe you can hack drivers/net/sis900.c to get it to
>work with the FA-311?
>
> Jeff


My FA311 works fine with the natsemi driver.

Ben Pharr
[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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Jens Axboe wrote:
> 
> > [...] so I would be _really_ nervous about just turning it on
> > silently. This is all very much a 2.5.x-kind of thing ;)
> 
> Then you might want to apply this :-)
> 
> --- drivers/block/ll_rw_blk.c~Wed Feb  7 02:38:31 2001
> +++ drivers/block/ll_rw_blk.c Wed Feb  7 02:38:42 2001
> @@ -1048,7 +1048,7 @@
>   /* Verify requested block sizes. */
>   for (i = 0; i < nr; i++) {
>   struct buffer_head *bh = bhs[i];
> - if (bh->b_size % correct_size) {
> + if (bh->b_size != correct_size) {
>   printk(KERN_NOTICE "ll_rw_block: device %s: "
>  "only %d-char blocks implemented (%u)\n",
>  kdevname(bhs[0]->b_dev),

Actually, I'd rather leave it in, but speed it up with the saner and
faster

if (bh->b_size & (correct_size-1)) {
...

That way people who _want_ to test the odd-size thing can do so. And
normal code (that never generates requests on any other size than the
"native" size) won't ever notice either way.

(Oh, we'll eventually need to move to "correct_size == hardware
blocksize", not the "virtual blocksize" that it is now. As it it a tester
needs to set the soft-blk size by hand now).

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> > 
> > The fact is, if you have problems like the above, then you don't
> > understand the interfaces. And it sounds like you designed kiobuf support
> > around the wrong set of interfaces.
> 
> They used the only interfaces available at the time...

Ehh.. "generic_make_request()" goes back a _loong_ time. It used to be
called just "make_request()", but all my points still stand.

It's even exported to modules. As far as I know, the raid code has always
used this interface exactly because raid needed to feed back the remapped
stuff and get around the blocksizing in ll_rw_block().

This really isn't anything new. I _know_ it's there in 2.2.x, and I
would not be surprised if it was there even in 2.0.x.

> > If you want to get at the _sector_ level, then you do
> ...
> > which doesn't look all that complicated to me. What's the problem?
> 
> Doesn't this break nastily as soon as the IO hits an LVM or soft raid
> device?  I don't think we are safe if we create a larger-sized
> buffer_head which spans a raid stripe: the raid mapping is only
> applied once per buffer_head.

Absolutely. This is exactly what I mean by saying that low-level drivers
may not actually be able to handle new cases that they've never been asked
to do before - they just never saw anything like a 64kB request before or
something that crossed its own alignment.

But the _higher_ levels are there. And there's absolutely nothing in the
design that is a real problem. But there's no question that you might need
to fix up more than one or two low-level drivers.

(The only drivers I know better are the IDE ones, and as far as I can tell
they'd have no trouble at all with any of this. Most other normal drivers
are likely to be in this same situation. But because I've not had a reason
to test, I certainly won't guarantee even that).

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Linus Torvalds wrote:
> > I don't see anything that would break doing this, in fact you can
> > do this as long as the buffers are all at least a multiple of the
> > block size. All the drivers I've inspected handle this fine, noone
> > assumes that rq->bh->b_size is the same in all the buffers attached
> > to the request.
> 
> It's really easy to get this wrong when going forward in the request list:
> you need to make sure that you update "request->current_nr_sectors" each
> time you move on to the next bh.
> 
> I would not be surprised if some of them have been seriously buggered. 

Maybe have been, but it looks good at least with the general drivers
that I mentioned.

> [...] so I would be _really_ nervous about just turning it on
> silently. This is all very much a 2.5.x-kind of thing ;)

Then you might want to apply this :-)

--- drivers/block/ll_rw_blk.c~  Wed Feb  7 02:38:31 2001
+++ drivers/block/ll_rw_blk.c   Wed Feb  7 02:38:42 2001
@@ -1048,7 +1048,7 @@
/* Verify requested block sizes. */
for (i = 0; i < nr; i++) {
struct buffer_head *bh = bhs[i];
-   if (bh->b_size % correct_size) {
+   if (bh->b_size != correct_size) {
printk(KERN_NOTICE "ll_rw_block: device %s: "
   "only %d-char blocks implemented (%u)\n",
   kdevname(bhs[0]->b_dev),

-- 
Jens Axboe

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

Oopses in 2.4.1 (lots of them)

[Arthur Pedyczak]

Hi all,
I have a misfortune of reporting yet another Oops in 2.4.1  (my previous
report got ignored). After running for 4 days I got many, many oopses.
They were trigerred by xscreensaver, and some other X-related apps.
After dopping to runlevel 3, the system seemed O.K. Nothing unusual in
process table, no zombies etc. I could restart the X server itself, bu any
attemp to start gdm would generate yet another Oops. Had to reboot.

Ideas/suggestions/Help appreciated

Arthur

==
My hardware:
PIII 450
motherboard: Asus P2B
384 MB RAM (no swap)
ide: PIIX4
ide0  hda: WDC AC313000R, ATA DISK drive
  hdb: MATSHITA CR-589, ATAPI CDROM drive
ide1  hdc: WDC WD200BB-00AUA1, ATA DISK drive
  hdd: MITSBICDRW4420a, ATAPI CDROM drive (ide-scsi)
graphics: Riva TNT2
sound: es1370
eth0  eepro100
eth1  3c59x
===
ksymoops output:
===
ksymoops 2.3.4 on i686 2.4.1.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.1/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Feb  6 16:41:46 cs865114-a kernel: Unable to handle kernel paging request at virtual 
address 0909093e
Feb  6 16:41:46 cs865114-a kernel: c0131ce1
Feb  6 16:41:46 cs865114-a kernel: *pde = 
Feb  6 16:41:46 cs865114-a kernel: Oops: 0002
Feb  6 16:41:46 cs865114-a kernel: CPU:0
Feb  6 16:41:46 cs865114-a kernel: EIP:0010:[file_move+25/44]
Feb  6 16:41:46 cs865114-a kernel: EFLAGS: 00210282
Feb  6 16:41:46 cs865114-a kernel: eax: 0909093a   ebx: d7937440   ecx: cb456600   
edx: c6c35a20
Feb  6 16:41:46 cs865114-a kernel: esi: d5d16600   edi: ffe9   ebp: d7a1c320   
esp: c3a65f48
Feb  6 16:41:46 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Feb  6 16:41:46 cs865114-a kernel: Process xroger (pid: 1066, stackpage=c3a65000)
Feb  6 16:41:46 cs865114-a kernel: Stack: cb456600 c0130a6e cb456600 d7937440 400134a0 
c3aa4000  c3aa4000
Feb  6 16:41:46 cs865114-a kernel:c01309ba d79d01c0 d7a1c320  c3a64000 
0003 08048984 d79d01c0
Feb  6 16:41:46 cs865114-a kernel:d7a1c320 08048984 c3aa4000 0003 0001 
0001 c0130cac c3aa4000
Feb  6 16:41:46 cs865114-a kernel: Call Trace: [dentry_open+170/328] [filp_open+82/92] 
[sys_open+56/180] [system_call+51/56]
Feb  6 16:41:46 cs865114-a kernel: Code: 89 48 04 89 01 89 59 04 89 0b 90 8d 74 26 00 
5b c3 89 f6 53
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 48 04  mov%ecx,0x4(%eax)
Code;  0003 Before first symbol
   3:   89 01 mov%eax,(%ecx)
Code;  0005 Before first symbol
   5:   89 59 04  mov%ebx,0x4(%ecx)
Code;  0008 Before first symbol
   8:   89 0b mov%ecx,(%ebx)
Code;  000a Before first symbol
   a:   90nop
Code;  000b Before first symbol
   b:   8d 74 26 00   lea0x0(%esi,1),%esi
Code;  000f Before first symbol
   f:   5bpop%ebx
Code;  0010 Before first symbol
  10:   c3ret
Code;  0011 Before first symbol
  11:   89 f6 mov%esi,%esi
Code;  0013 Before first symbol
  13:   53push   %ebx

Feb  6 16:51:46 cs865114-a kernel: Unable to handle kernel paging request at virtual 
address 0909093e
Feb  6 16:51:46 cs865114-a kernel: c0131ce1
Feb  6 16:51:46 cs865114-a kernel: *pde = 
Feb  6 16:51:46 cs865114-a kernel: Oops: 0002
Feb  6 16:51:46 cs865114-a kernel: CPU:0
Feb  6 16:51:46 cs865114-a kernel: EIP:0010:[file_move+25/44]
Feb  6 16:51:46 cs865114-a kernel: EFLAGS: 00210282
Feb  6 16:51:46 cs865114-a kernel: eax: 0909093a   ebx: d7937440   ecx: c961a5a0   
edx: c6c35d80
Feb  6 16:51:46 cs865114-a kernel: esi: d5d16600   edi: ffe9   ebp: d7a1c320   
esp: d1de7f48
Feb  6 16:51:46 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Feb  6 16:51:46 cs865114-a kernel: Process xroger (pid: 1080, stackpage=d1de7000)
Feb  6 16:51:46 cs865114-a kernel: Stack: c961a5a0 c0130a6e c961a5a0 d7937440 400134a0 
d714  d714
Feb  6 16:51:46 cs865114-a kernel:c01309ba d79d01c0 d7a1c320  d1de6000 
0003 08048984 d79d01c0
Feb  6 16:51:46 cs865114-a kernel:d7a1c320 08048984 d714 0003 0001 
0001 c0130cac d714
Feb  6 16:51:46 cs865114-a 

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Stephen C. Tweedie]

Hi,

On Tue, Feb 06, 2001 at 04:41:21PM -0800, Linus Torvalds wrote:
> 
> On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> > No, it is a problem of the ll_rw_block interface: buffer_heads need to
> > be aligned on disk at a multiple of their buffer size.
> 
> Ehh.. True of ll_rw_block() and submit_bh(), which are meant for the
> traditional block device setup, where "b_blocknr" is the "virtual
> blocknumber" and that indeed is tied in to the block size.
> 
> The fact is, if you have problems like the above, then you don't
> understand the interfaces. And it sounds like you designed kiobuf support
> around the wrong set of interfaces.

They used the only interfaces available at the time...

> If you want to get at the _sector_ level, then you do
...
> which doesn't look all that complicated to me. What's the problem?

Doesn't this break nastily as soon as the IO hits an LVM or soft raid
device?  I don't think we are safe if we create a larger-sized
buffer_head which spans a raid stripe: the raid mapping is only
applied once per buffer_head.

--Stephen
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Ingo Molnar wrote:
> 
> most likely some coding error on your side. buffer-size mismatches should
> show up as filesystem corruption or random DMA scribble, not in-driver
> oopses.

I'm not sure. If I was a driver writer (and I'm happy those days are
mostly behind me ;), I would not be totally dis-inclined to check for
various limits and things.

There can be hardware out there that simply has trouble with non-native
alignment, ie be unhappy about getting a 1kB request that is aligned in
memory at a 512-byte boundary. So there are real reasons why drivers might
need updating. Don't dismiss the concerns out-of-hand.

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Jens Axboe wrote:
> 
> I don't see anything that would break doing this, in fact you can
> do this as long as the buffers are all at least a multiple of the
> block size. All the drivers I've inspected handle this fine, noone
> assumes that rq->bh->b_size is the same in all the buffers attached
> to the request.

It's really easy to get this wrong when going forward in the request list:
you need to make sure that you update "request->current_nr_sectors" each
time you move on to the next bh.

I would not be surprised if some of them have been seriously buggered. 

On the other hand, I would _also_ not be surprised if we've actually fixed
a lot of them: one of the things that the RAID code and loopback test is
exactly getting these kinds of issues right (not this exact one, but
similar ones).

And let's remember things like the old ultrastor driver that was totally
unable to handle anything but 1kB devices etc. I would not be _totally_
surprised if it turns out that there are still drivers out there that
remember the time when Linux only ever had 1kB buffers. Even if it is 7
years ago or so ;)

(Also, there might be drivers that are "optimized" - they set the IO
length once per request, and just never set it again as they do partial
end_io() calls. None of those kinds of issues would ever be found under
normal load, so I would be _really_ nervous about just turning it on
silently. This is all very much a 2.5.x-kind of thing ;)

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Wed, Feb 07, 2001 at 02:06:27AM +0100, Ingo Molnar wrote:
> 
> On Tue, 6 Feb 2001, Jeff V. Merkey wrote:
> 
> > > I don't see anything that would break doing this, in fact you can
> > > do this as long as the buffers are all at least a multiple of the
> > > block size. All the drivers I've inspected handle this fine, noone
> > > assumes that rq->bh->b_size is the same in all the buffers attached
> > > to the request. This includes SCSI (scsi_lib.c builds sg tables),
> > > IDE, and the Compaq array + Mylex driver. This mostly leaves the
> > > "old-style" drivers using CURRENT etc, the kernel helpers for these
> > > handle it as well.
> > >
> > > So I would appreciate pointers to these devices that break so we
> > > can inspect them.
> > >
> > > --
> > > Jens Axboe
> >
> > Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.
> 
> most likely some coding error on your side. buffer-size mismatches should
> show up as filesystem corruption or random DMA scribble, not in-driver
> oopses.
> 
>   Ingo

Oops was in my code, but was caused by these drivers.  The Adaptec 
driver did have an oops that was it's own code address, AIC7XXX 
crashed in my code.

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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Ingo Molnar]

On Wed, 7 Feb 2001, Jens Axboe wrote:

> > > Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.
> >
> > most likely some coding error on your side. buffer-size mismatches should
> > show up as filesystem corruption or random DMA scribble, not in-driver
> > oopses.
>
> I would suspect so, aic7xxx shouldn't care about anything except the
> sg entries and I would seriously doubt that it makes any such
> assumptions on them :-)

yep - and not a single reference to b_size in aic7xxx.c.

Ingo

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Wed, Feb 07, 2001 at 02:08:53AM +0100, Jens Axboe wrote:
> On Tue, Feb 06 2001, Jeff V. Merkey wrote:
> > Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.
> 
> Do you still have this oops?
> 

I can recreate.  Will work on it tommorrow.  SCI testing today.

Jeff

> -- 
> Jens Axboe
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Jeff V. Merkey wrote:
> Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.

Do you still have this oops?

-- 
Jens Axboe

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Wed, Feb 07 2001, Ingo Molnar wrote:
> > > So I would appreciate pointers to these devices that break so we
> > > can inspect them.
> > >
> > > --
> > > Jens Axboe
> >
> > Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.
> 
> most likely some coding error on your side. buffer-size mismatches should
> show up as filesystem corruption or random DMA scribble, not in-driver
> oopses.

I would suspect so, aic7xxx shouldn't care about anything except the
sg entries and I would seriously doubt that it makes any such
assumptions on them :-)

-- 
Jens Axboe

-
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: PCI-SCI Drivers v1.1-7 released

[Jeff V. Merkey]

On Tue, Feb 06, 2001 at 06:25:01PM -0700, Jeff V. Merkey wrote:
> 
> Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly 
> broken, and does not support #ident lines in the source code, 
> which also means that RedHat 7.1 will not work properly with 
> CVS (Code Versioning System) projects that use the #ident 
> keyword to identify and comment files.  It generates 
> an "unknown keyword" error message.  This version of the 
> sources disables some CVS enablement in order to build properly 
> on a RedHat 7.1 system with gcc 2.96.


More to add on the gcc 2.96 problems.  After compiling a Linux 2.4.1 
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat 
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1 
source tree. 

I think RedHat should jetison gcc 2.96 as soon as possible...

Tests run on a PIII system limited to 90 MB/S PCI throughput.

gcc 2.91 on a PIII system in sci_copy mode   85 MB/S
gcc 2.96 in RedHat 7.1 (Fischer) in sci_copy mode63 MB/S

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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Ingo Molnar]

On Tue, 6 Feb 2001, Jeff V. Merkey wrote:

> > I don't see anything that would break doing this, in fact you can
> > do this as long as the buffers are all at least a multiple of the
> > block size. All the drivers I've inspected handle this fine, noone
> > assumes that rq->bh->b_size is the same in all the buffers attached
> > to the request. This includes SCSI (scsi_lib.c builds sg tables),
> > IDE, and the Compaq array + Mylex driver. This mostly leaves the
> > "old-style" drivers using CURRENT etc, the kernel helpers for these
> > handle it as well.
> >
> > So I would appreciate pointers to these devices that break so we
> > can inspect them.
> >
> > --
> > Jens Axboe
>
> Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.

most likely some coding error on your side. buffer-size mismatches should
show up as filesystem corruption or random DMA scribble, not in-driver
oopses.

Ingo

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

Hard system freeze in 2.2.17, 2.2.18, 2.4.1-AC3 VIA Athlon

[Jonathan Abbey]

I am having terribly frustrating system stability problems, and I
can't figure out whether I should suspect hardware or the kernel.

Software:

Any of Linux 2.2.17, 2.2.18, 2.4.1-AC3

Hardware:

Athlon Thunderbird 750mhz, running at rated speed
EPoX 8KTA2 VIA Athlon motherboard with VT82C686B Southbridge, VT8363 Northbridge

My system boots fine, and once it gets past the mandatory fsck, it
proceeds up to X just fine.  I can pretty much log in, do web
browsing, play Unreal Tournament with accelerated OpenGL, burn cd's,
play music, whatever.

What I can't do is run XEmacs, either in X Windows or on a command
line window over ssh or mingetty.  9 times out of 10, as soon as I run
'xemacs', the system locks tight.  No responsiveness to any keyboard
activity, no alt-SysRq, nothing.  One time the system locked when I
was playing an mp3 with XMMS and after it locked the sound card kept
looping the same quarter-second of sound it had been playing when the
system locked.  I have also seen what looks like this system hang
occur often when compiling a new kernel, and it has happened when my
housemate was running Netscape once, both of those under 2.2.17.

About a week ago, I decided to see about a BIOS update, and while I
went about getting my BIOS flashed, I also installed an IDE CD-RW
drive and updated my kernel to 2.2.18.  All of this gave my system a
couple of hours of rest with the power off.

After I got everything back together and got the BIOS flashed,
everything seemed to work great.  I built myself a 2.2.18 kernel with
the IDE-SCSI driver to support cdrecord on my new CDRW drive.  For 5
days my system ran with excellent stability.  I took to running
'xemacs' frequently, just to enjoy the thrill of not having to fsck my
drives.

Until a couple of nights ago.  My friend the hard system freeze has
returned, with all of the old symptoms.  I run xemacs, I lock, nearly
every time.

I have tried to check certain things.  I set my system's BIOS up so
that it does the full POST check, including three passes over the RAM.
No problems reported at any time.  I have tried running my PC133 RAM
clocked at 100mhz.  I have commented out my hdparm lines in my boot
scripts.  No effect.

I am really confused by this one.  The fact that running xemacs can
reliably lock the system makes me think it is a kernel problem.
There's nothing about running xemacs that I would expect to be
particularly stressfull on the system.  Running Unreal Tournament with
heavy 3d acceleration and sound I would expect to be much more
stressful on my system's power supply and RAM, but that's pretty safe
to do.  XEmacs does do a funky unexec() thing to create its exec
image, and I imagine it does some things with pty's and the like that
many pieces of software does not.. plenty of opportunities to tickle
different parts of the kernel.

On the other hand, having the problem go away after a couple of hours
of down time for my system's components, and to have the problem come
back after five days usage and to then stay across several system
hangs and reboots makes me think it is a hardware problem.

So.. how in the world do I go about isolating this?  When it hangs, it
hangs tight enough that alt-SysRq is of no use, so I can't get any
kind of kernel oops message or anything like that.  The memory test
that the BIOS does seems to work fine.  The video, ethernet, and sound
cards shouldn't be connected to this since I can run xemacs from
single user mode on the console and get this lock-up.

I have tried doing an strace on xemacs from the console, but the
system freeze and the resulting file system corruption and fsck on
reboot makes any snapshot of the strace output unreliable.

I have tried futzing with various BIOS settings in the hope of making
the system more stable, to no effect.

I'm wondering if there is a problem with how the kernel is interacting
with the VIA chipset, but that five day grace period really makes me
think of hardware.

-- 
---
Jonathan Abbey[EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX http://www.arlut.utexas.edu/gash2


-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Wed, Feb 07, 2001 at 02:02:21AM +0100, Jens Axboe wrote:
> On Tue, Feb 06 2001, Jeff V. Merkey wrote:
> > I remember Linus asking to try this variable buffer head chaining 
> > thing 512-1024-512 kind of stuff several months back, and mixing them to 
> > see what would happen -- result.  About half the drivers break with it.  
> > The interface allows you to do it, I've tried it, (works on Andre's 
> > drivers, but a lot of SCSI drivers break) but a lot of drivers seem to 
> > have assumptions about these things all being the same size in a 
> > buffer head chain. 
> 
> I don't see anything that would break doing this, in fact you can
> do this as long as the buffers are all at least a multiple of the
> block size. All the drivers I've inspected handle this fine, noone
> assumes that rq->bh->b_size is the same in all the buffers attached
> to the request. This includes SCSI (scsi_lib.c builds sg tables),
> IDE, and the Compaq array + Mylex driver. This mostly leaves the
> "old-style" drivers using CURRENT etc, the kernel helpers for these
> handle it as well.
> 
> So I would appreciate pointers to these devices that break so we
> can inspect them.
> 
> -- 
> Jens Axboe

Adaptec drivers had an oops.  Also, AIC7XXX also had some oops with it.

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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Wed, Feb 07, 2001 at 02:01:54AM +0100, Ingo Molnar wrote:
> 
> On Tue, 6 Feb 2001, Jeff V. Merkey wrote:
> 
> > I remember Linus asking to try this variable buffer head chaining
> > thing 512-1024-512 kind of stuff several months back, and mixing them
> > to see what would happen -- result. About half the drivers break with
> > it. [...]
> 
> time to fix them then - instead of rewriting the rest of the kernel ;-)
> 
>   Ingo

I agree.  

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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Ingo Molnar]

On Tue, 6 Feb 2001, Jeff V. Merkey wrote:

> I remember Linus asking to try this variable buffer head chaining
> thing 512-1024-512 kind of stuff several months back, and mixing them
> to see what would happen -- result. About half the drivers break with
> it. [...]

time to fix them then - instead of rewriting the rest of the kernel ;-)

Ingo

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Jeff V. Merkey wrote:
> I remember Linus asking to try this variable buffer head chaining 
> thing 512-1024-512 kind of stuff several months back, and mixing them to 
> see what would happen -- result.  About half the drivers break with it.  
> The interface allows you to do it, I've tried it, (works on Andre's 
> drivers, but a lot of SCSI drivers break) but a lot of drivers seem to 
> have assumptions about these things all being the same size in a 
> buffer head chain. 

I don't see anything that would break doing this, in fact you can
do this as long as the buffers are all at least a multiple of the
block size. All the drivers I've inspected handle this fine, noone
assumes that rq->bh->b_size is the same in all the buffers attached
to the request. This includes SCSI (scsi_lib.c builds sg tables),
IDE, and the Compaq array + Mylex driver. This mostly leaves the
"old-style" drivers using CURRENT etc, the kernel helpers for these
handle it as well.

So I would appreciate pointers to these devices that break so we
can inspect them.

-- 
Jens Axboe

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Tue, Feb 06, 2001 at 04:50:19PM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> > 
> > That gets us from 512-byte blocks to 4k, but no more (ll_rw_block
> > enforces a single blocksize on all requests but that relaxing that
> > requirement is no big deal).  Buffer_heads can't deal with data which
> > spans more than a page right now.
> 
> Stephen, you're so full of shit lately that it's unbelievable. You're
> batting a clear 0.000 so far.
> 
> "struct buffer_head" can deal with pretty much any size: the only thing it
> cares about is bh->b_size.
> 
> It so happens that if you have highmem support, then "create_bounce()"
> will work on a per-page thing, but that just means that you'd better have
> done your bouncing into low memory before you call generic_make_request().
> 
> Have you ever spent even just 5 minutes actually _looking_ at the block
> device layer, before you decided that you think it needs to be completely
> re-done some other way? It appears that you never bothered to.
> 
> Sure, I would not be surprised if some device driver ends up being
> surpised if you start passing it different request sizes than it is used
> to. But that's a driver and testing issue, nothing more.
> 
> (Which is not to say that "driver and testing" issues aren't important as
> hell: it's one of the more scary things in fact, and it can take a long
> time to get right if you start doing somehting that historically has never
> been done and thus has historically never gotten any testing. So I'm not
> saying that it should work out-of-the-box. But I _am_ saying that there's
> no point in trying to re-design upper layers that already do ALL of this
> with no problems at all).
> 
>   Linus
> 

I remember Linus asking to try this variable buffer head chaining 
thing 512-1024-512 kind of stuff several months back, and mixing them to 
see what would happen -- result.  About half the drivers break with it.  
The interface allows you to do it, I've tried it, (works on Andre's 
drivers, but a lot of SCSI drivers break) but a lot of drivers seem to 
have assumptions about these things all being the same size in a 
buffer head chain. 

:-)

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/
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> 
> That gets us from 512-byte blocks to 4k, but no more (ll_rw_block
> enforces a single blocksize on all requests but that relaxing that
> requirement is no big deal).  Buffer_heads can't deal with data which
> spans more than a page right now.

Stephen, you're so full of shit lately that it's unbelievable. You're
batting a clear 0.000 so far.

"struct buffer_head" can deal with pretty much any size: the only thing it
cares about is bh->b_size.

It so happens that if you have highmem support, then "create_bounce()"
will work on a per-page thing, but that just means that you'd better have
done your bouncing into low memory before you call generic_make_request().

Have you ever spent even just 5 minutes actually _looking_ at the block
device layer, before you decided that you think it needs to be completely
re-done some other way? It appears that you never bothered to.

Sure, I would not be surprised if some device driver ends up being
surpised if you start passing it different request sizes than it is used
to. But that's a driver and testing issue, nothing more.

(Which is not to say that "driver and testing" issues aren't important as
hell: it's one of the more scary things in fact, and it can take a long
time to get right if you start doing somehting that historically has never
been done and thus has historically never gotten any testing. So I'm not
saying that it should work out-of-the-box. But I _am_ saying that there's
no point in trying to re-design upper layers that already do ALL of this
with no problems at all).

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jeff V. Merkey]

On Wed, Feb 07, 2001 at 12:36:29AM +, Stephen C. Tweedie wrote:
> Hi,
> 
> On Tue, Feb 06, 2001 at 07:25:19PM -0500, Ingo Molnar wrote:
> > 
> > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> > 
> > > No, it is a problem of the ll_rw_block interface: buffer_heads need to
> > > be aligned on disk at a multiple of their buffer size.  Under the Unix
> > > raw IO interface it is perfectly legal to begin a 128kB IO at offset
> > > 512 bytes into a device.
> > 
> > then we should either fix this limitation, or the raw IO code should split
> > the request up into several, variable-size bhs, so that the range is
> > filled out optimally with aligned bhs.
> 
> That gets us from 512-byte blocks to 4k, but no more (ll_rw_block
> enforces a single blocksize on all requests but that relaxing that
> requirement is no big deal).  Buffer_heads can't deal with data which
> spans more than a page right now.


I can handle requests larger than a page (64K) but I am not using 
the buffer cache in Linux.  We really need an NT/NetWare like model 
to support the non-Unix FS's properly.

i.e.   

a disk request should be 

and get rid of this fixed block 
stuff with buffer heads. :-)

I understand that the way the elevator is implemented in Linux makes
this very hard at this point to support, since it's very troublesome 
to handling requests that overlap sector boundries.

Jeff


> 
> --Stephen
> -
> 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: sync & asyck i/o

[Andre Hedrick]

On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:

> The ll_rw_block interface is perfectly clear: it expects the data to
> be written to persistent storage once the buffer_head end_io is
> called.  If that's not the case, somebody needs to fix the lower
> layers.

Sure in 2.5 when I have a cleaner method of setting up hooks to allow
testing and changing of the mode but you can not assume that this stuff is
off by default and will stay that way.

At this time I am working to clean up an IBM mess of drives that do random
dumping of the drive cache to the platters when power is pulled.  This is
a nice dirty errata that I have heard about but have never seen, but can
believe that it is real.  The painful part is now that drives have these
huge buffers of upto 4MB, we have only a second or two to hit the platters
before the head float and spindle sync for writing depart from the
allowable range and it does not get to diskOOPS!

I suspect that with all of the new NVRAM HOSTS coming to market soon we
will see more fs death in the future until things settle.

Cheers,

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.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/

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Ingo Molnar wrote:
> 
> On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> 
> > No, it is a problem of the ll_rw_block interface: buffer_heads need to
> > be aligned on disk at a multiple of their buffer size.  Under the Unix
> > raw IO interface it is perfectly legal to begin a 128kB IO at offset
> > 512 bytes into a device.
> 
> then we should either fix this limitation, or the raw IO code should split
> the request up into several, variable-size bhs, so that the range is
> filled out optimally with aligned bhs.

As mentioned, no such limitation exists if you just use the right
interfaces.

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> 
> On Tue, Feb 06, 2001 at 08:57:13PM +0100, Ingo Molnar wrote:
> > 
> > [overhead of 512-byte bhs in the raw IO code is an artificial problem of
> > the raw IO code.]
> 
> No, it is a problem of the ll_rw_block interface: buffer_heads need to
> be aligned on disk at a multiple of their buffer size.

Ehh.. True of ll_rw_block() and submit_bh(), which are meant for the
traditional block device setup, where "b_blocknr" is the "virtual
blocknumber" and that indeed is tied in to the block size.

That's the whole _point_ of ll_rw_block() and friends - they show the
device at a different "virtual blocking" level than the low-level physical
accesses necessarily are. Which very much means that if you have a 4kB
"view", of the device, you get a stream of 4kB blocks. Not 4kB sized
blocks at 512-byte offsets (or whatebver the hardware blocking size is).

This way the interfaces are independent of the hardware blocksize. Which
is logical and what you'd expect. You need to go to a lower level to see
those kinds of blocking issues.

But it is _not_ true of "generic_make_request()" and the block IO layer in
general. It obviously _cannot_ be true, because the block I/O layer has
always had the notion of merging consecutive blocks together - regardless
of whether the end result is even a power of two or antyhing like that in
size. You can make an IO request for pretty much any size, as long as it's
a multiple of the hardare blocksize (normally 512 bytes, but there are
certainly devices out there with other blocksizes).

The fact is, if you have problems like the above, then you don't
understand the interfaces. And it sounds like you designed kiobuf support
around the wrong set of interfaces.

If you want to get at the _sector_ level, then you do

lock_bh();
bh->b_rdev = device;
bh->b_rsector = sector-number (where linux defines "sector" to be 512 bytes)
bh->b_size = size in bytes (must be a multiple of 512);
bh->b_data = pointer;
bh->b_end_io = callback;
generic_make_request(rw, bh);

which doesn't look all that complicated to me. What's the problem?

Linus

-
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] 2.4.[01] lockups

[Ivan Borissov Ganev]

Hello,

I am experiencing a problem with both 2.4.0 and 2.4.1. The problem is that
at seemingly random times the console locks up. After the lockup I can no
longer type and the mouse is frozen. As far as I can tell, other systems
services are not affected, i.e. programs continue to run, music is being
played, I/O is fine. It looks like _only_ the console devices are locked
up.

I work under X most of the time, but this has happened on a bare VC once
also. The frequency of occurrence varies from 0 to a few times a day, with
an average about 1 time/day.

When it happens I use my UPS to power the machine down gracefully and then
reboot, however, it is a nuisance. After reboot the system log does not
have anything out of the ordinary in it. I think this might be related to
the other reports of lockups with 2.4.1 (by Ed Tomlinson and Alexander
Zvyagin).

The system specs are the following:

motherboard: ABIT BH6 rev 1.0
the BH6 is based on Intel's 440BX chipset
(chipset BIOS updated to the latest available one)

CPU: Pentium II (Deschutes) stepping 02 @ 400MHz

RAM: 256MB SDRAM

HDD: 3 hard drives:
hda: QUANTUM BIGFOOT TS8.4A, ATA DISK drive ( 8GB)
hdb: WDC WD205AA, ATA DISK drive(30GB)
hdc: WDC AC21200H, ATA DISK drive   ( 1GB)

CD-ROM:
hdd: CR-801NP, ATAPI CD/DVD-ROM drive

FDC:
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077

ttyS:
two serial ports on the motherboard

video:
Matrox Millenium G200 (8MB SDRAM)

eth:
Intel EtherExpressPro 10/100 (connected to DSL)

sound:
Creative SB AWE64 (ISA device)

modem:
USR3030/2729371324[0]{U.S. Robotics 56K FAX INT}

I also have a Hauppauge bt848-based TV tuner card but the driver for it
is compiled as a module and not loaded or used.

All hard drives use DMA by default but the kernel usually switches to PIO
for the CD-ROM after I start using it.

Any ideas as to the cause for the lockups would be greatly appreciated. I
am also willing to experiment/troubleshoot/test possible solutions, except
that I have no idea where to start from.

Cheers,
--Ivan


--
Ivan Ganev   327236 Georgia Tech Station
   College of Computing   Atlanta,  GA 30332
Georgia Institute of Technology1-(404)-365-8694
[EMAIL PROTECTED] http://www.cc.gatech.edu/~ganev 
--
 Learning is not compulsory. Neither is survival.
-- W. Edwards Deming




-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Stephen C. Tweedie]

Hi,

On Tue, Feb 06, 2001 at 07:25:19PM -0500, Ingo Molnar wrote:
> 
> On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:
> 
> > No, it is a problem of the ll_rw_block interface: buffer_heads need to
> > be aligned on disk at a multiple of their buffer size.  Under the Unix
> > raw IO interface it is perfectly legal to begin a 128kB IO at offset
> > 512 bytes into a device.
> 
> then we should either fix this limitation, or the raw IO code should split
> the request up into several, variable-size bhs, so that the range is
> filled out optimally with aligned bhs.

That gets us from 512-byte blocks to 4k, but no more (ll_rw_block
enforces a single blocksize on all requests but that relaxing that
requirement is no big deal).  Buffer_heads can't deal with data which
spans more than a page right now.

--Stephen
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Wed, Feb 07 2001, Stephen C. Tweedie wrote:
> > [overhead of 512-byte bhs in the raw IO code is an artificial problem of
> > the raw IO code.]
> 
> No, it is a problem of the ll_rw_block interface: buffer_heads need to
> be aligned on disk at a multiple of their buffer size.  Under the Unix
> raw IO interface it is perfectly legal to begin a 128kB IO at offset
> 512 bytes into a device.

Submitting buffers to lower layers that are not hw sector aligned
can't be supported below ll_rw_blk anyway (they can, but look at the
problems this has always created), and I would much rather see stuff
like this handled outside of there.

-- 
Jens Axboe

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

PCI-SCI Drivers v1.1-7 released

[Jeff V. Merkey]

The PCI-SCI v1.1-7 Drivers for Dolphin's Scalable Coherent 
Interface Adapters have been posted and are available for download 
at vger.timpanogas.org:\sci\pci-sci-1.1-7 in tar.gz and RPM 
(RedHat Package Manager Formats).  This version supports Linux kernels 
2.2.X up through 2.4.1.  These drivers are released under the 
GPL and are freely redistributible. 

NOTES:

This release corrects modversion build problems related 
to Red Hat's 7.1 Fischer Release.  This release also corrects
build problems with the #ident keyword in the SCI source 
tree with CVS.  Please note that the sci sources will 
always assume a stock kernel layout and will point to 
/usr/src/linux/include for modversioned includes and files.  
For whatever reason, RedHat 7.1 now points to a /usr/src/linux-2.4 
tree which breaks drivers built against stock kernel trees.

Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly 
broken, and does not support #ident lines in the source code, 
which also means that RedHat 7.1 will not work properly with 
CVS (Code Versioning System) projects that use the #ident 
keyword to identify and comment files.  It generates 
an "unknown keyword" error message.  This version of the 
sources disables some CVS enablement in order to build properly 
on a RedHat 7.1 system with gcc 2.96.

Please also note that the RedHat 7.1 Fischer release with 
the Linux 2.4.0 kernel will report bogus .modinfo relocation
warnings generated by the assembler while building some .c files 
against the kernel source tree.  These messages are a due to 
severe bugs previously reported in the gcc 2.96 compiler and 
assembler on RedHat versions 7.0 and above (the list for gcc 2.96 
keeps growing).  

Please direct any comments or bug reports to [EMAIL PROTECTED]
or [EMAIL PROTECTED]


Jeff Merkey
Chief Engineer, TRG

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Stephen C. Tweedie]

Hi,

On Tue, Feb 06, 2001 at 08:57:13PM +0100, Ingo Molnar wrote:
> 
> [overhead of 512-byte bhs in the raw IO code is an artificial problem of
> the raw IO code.]

No, it is a problem of the ll_rw_block interface: buffer_heads need to
be aligned on disk at a multiple of their buffer size.  Under the Unix
raw IO interface it is perfectly legal to begin a 128kB IO at offset
512 bytes into a device.

--Stephen
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Ingo Molnar]

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote:

> No, it is a problem of the ll_rw_block interface: buffer_heads need to
> be aligned on disk at a multiple of their buffer size.  Under the Unix
> raw IO interface it is perfectly legal to begin a 128kB IO at offset
> 512 bytes into a device.

then we should either fix this limitation, or the raw IO code should split
the request up into several, variable-size bhs, so that the range is
filled out optimally with aligned bhs.

Ingo

-
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: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

[Juraj Bednar]

Hello,


 sorry, too stupid not to look on the web first, but this should really _NOT_ appear
in the kernel source tree. I found that apm=power_off and make mrproper before
build helps. 





 Juraj.


-
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: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

[J . A . Magallon]

On 02.07 Juraj Bednar wrote:
> Hello,
> 
> 
>   the same for vanilla 2.4.1 and 2.4.1ac3. Everything works ok until I turn
> off SMP
> support (which is required to make it possible to turn off the machine using
> APM, since
> ACPI is completely broken in 2.4.1 for me).
> 

You do not need to do that. Enable both SMP and APM (just APM support, no
ACPI nor any other apm option). And add to your lilo.conf file a line:
append="apm=power-off".

At boot you will see a log message like:

apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
apm: disabled - APM is not SMP safe (power off active).

So kernel diables APM but lets the power-off feature active.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac4 #1 SMP Tue Feb 6 22:06:38 CET 2001 i686

-
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: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

[Juraj Bednar]

Hello,


  the same for vanilla 2.4.1 and 2.4.1ac3. Everything works ok until I turn off SMP
support (which is required to make it possible to turn off the machine using APM, since
ACPI is completely broken in 2.4.1 for me).


 Juraj.

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Marcelo Tosatti wrote:
> 
> Its arguing against making a smart application block on the disk while its
> able to use the CPU for other work.

There are currently no other alternatives in user space. You'd have to
create whole new interfaces for aio_read/write, and ways for the kernel to
inform user space that "now you can re-try submitting your IO".

Could be done. But that's a big thing.

> An application which sets non blocking behavior and busy waits for a
> request (which seems to be your argument) is just stupid, of course.

Tell me what else it could do at some point? You need something like
select() to wait on it. There are no such interfaces right now...

(besides, latency would suck. I bet you're better off waiting for the
requests if they are all used up. It takes too long to get deep into the
kernel from user space, and you cannot use the exclusive waiters with its
anti-herd behaviour etc).

Simple rule: if you want to optimize concurrency and avoid waiting - use
several processes or threads instead. At which point you can get real work
done on multiple CPU's, instead of worrying about what happens when you
have to wait on the disk.

Linus

-
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: FA-311 / Natsemi problems with 2.4.1

[Jeff Garzik]

Jocelyn Mayer wrote:
> 
> I found something from OpenBSD:
> the natsemi chip (in fact DP83815)
> is quite the same as SiS900 one.

If that is true, maybe you can hack drivers/net/sis900.c to get it to
work with the FA-311?

Jeff



-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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/

Problems with Linux 2.4.1

[Alexander Zvyagin]

Hello,

I have several problems with my computer (running RedHat 6.2) under Linux
2.4.1 kernel. (See attached files for more information).

Here is a short summary:

1) Audio card (based on SiS chipset) does not work due to incorrect
   initialization of PCI resources. It seems that this is not a problem of
   audio driver, but may be I am wrong.
   The kernel prints this message:

PCI: Cannot allocate resource region 0 of device 00:01.4
  got res[1000:10ff] for resource 0 of Silicon Integrated Systems [SiS]
SiS PCI Audio Accelerator

2) Frame-buffer mode does not work with my video card SiS630.
   But ok, frame-buffer mode is EXPERIMENTAL in linux.
   Computer boots, but screen is blank. All messages are fine. 

3) Kernel prints (working with DVD-ROM)
   hdc: packet command error: status=0x51 { DriveReady SeekComplete Error}
   I tried CONFIG_IDEDISK_MULTI_MODE to set NO and YES
   but nothing helped. Well, this is a minor problem, because the device
   works regardless of that message.

4) Sometimes computer hangs up. It does not happen too often
   (it happend 2 times), but I am curious why? There is no OOPS, and log
   files do not have any error messages... And I can not reproduce this
   bug.

I spend already several days in attempts to configure all my hardware
(mainly audio card) under linux properly. Any help is greatly appreciated.

P.S. Please CC your answer to me because I am not member of your mail
list.

Thank you,
Alexander.


Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 Sat Feb 3 15:42:40 MSK 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0002 @ 000e (reserved)
 BIOS-e820: 036f @ 0010 (usable)
 BIOS-e820: ffc0 @ 037f (ACPI data)
 BIOS-e820: 0040 @ 037fffc0 (ACPI NVS)
 BIOS-e820: 0004 @ fffc (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 14320
zone(0): 4096 pages.
zone(1): 10224 pages.
zone(2): 0 pages.
mapped APIC to e000 (010ef000)
Kernel command line: BOOT_IMAGE=l ro root=303 pci=biosirq
Initializing CPU#0
Detected 797.467 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 1592.52 BogoMIPS
Memory: 54068k/57280k available (1056k kernel code, 2824k reserved, 377k data, 204k 
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 0383f9ff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff   
CPU: After generic, caps: 0383f9ff   
CPU: Common caps: 0383f9ff   
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xeb440, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: Cannot allocate resource region 0 of device 00:01.4
  got res[1000:10ff] for resource 0 of Silicon Integrated Systems [SiS] SiS PCI Audio 
Accelerator
  got res[1000:1fff] for resource 0 of Texas Instruments PCI1420
  got res[10001000:10001fff] for resource 0 of Texas Instruments PCI1420 (#2)
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.3 present.
46 structures occupying 1508 bytes.
DMI table at 0x000ED932.
BIOS Vendor: Insydesw
BIOS Version: Version 5.08
BIOS Release: 10/28/2000
System Vendor: CLEVO Co.   .
Product Name: LP200.
Version  .
Serial Number   .
Board Vendor: CLEVO Co.   .
Board Name: LP200.
Board Version:  .
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
parport0: PC-style at 0x378 [PCSPP(,...)]
pty: 256 Unix98 ptys configured
lp0: using parport0 (polling).
block: queued sectors max/low 35832kB/11944kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 01

Re: sync & asyck i/o

[Stephen C. Tweedie]

Hi,

On Tue, Feb 06, 2001 at 11:25:00AM -0800, Andre Hedrick wrote:
> On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:

> > No, we simply omit to instruct them to enable write-back caching.
> > Linux assumes that the WCE (write cache enable) bit in a disk's
> > caching mode page is zero.
> 
> You can not be so blind to omit the command.

Linux has traditionally ignored the issue.  Don't ask me to defend it
--- the last advice I got from anybody who knew SCSI well was that
SCSI disks were defaulting to WCE-disabled.  

Note that disabling SCSI WCE doesn't disable the cache, it just
enforces synchronous completion.  With tagged command queuing,
writeback caching doesn't necessarily mean a huge performance
increase.  But if WCE is being enabled by default on modern SCSI
drives, then that's something which the scsi stack really does need to
fix --- the upper block layers will most definitely break if we have
WCE enabled and we don't set force-unit-access on the scsi commands.

The ll_rw_block interface is perfectly clear: it expects the data to
be written to persistent storage once the buffer_head end_io is
called.  If that's not the case, somebody needs to fix the lower
layers.

Cheers, 
  Stephen
-
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] Spelling fixes for commonly misspelled words

[André Dahlqvist]

I did some grepping for words that are often misspelled, and the below
patch is the result of that. The patch fixes a large number of spelling
errors (64 in total.) The changes that have been made (in many places)
are these:

adress --> address
adressed --> addressed
adressing --> addressing
adresses --> addresses
subadress --> subaddress
aquire --> acquire
garantee --> guarantee
existant --> existent
existance --> existence
frist --> first
desiderable --> desirable

The patch is against 2.4.1-ac4.

diff -ur linux-2.4.1-ac4/Documentation/isdn/INTERFACE 
linux/Documentation/isdn/INTERFACE
--- linux-2.4.1-ac4/Documentation/isdn/INTERFACEThu Aug 26 00:18:07 1999
+++ linux/Documentation/isdn/INTERFACE  Wed Feb  7 00:00:06 2001
@@ -480,7 +480,7 @@
 Parameter:
   driver  = driver-Id
   command = ISDN_CMD_PROT_IO
-  arg = The lower 8 Bits define the adressed protocol as defined
+  arg = The lower 8 Bits define the addressed protocol as defined
 in ISDN_PTYPE..., the upper bits are used to differenciate
 the protocol specific CMD.  
   
@@ -734,7 +734,7 @@
 Parameter:
   driver  = driver-Id
   command = ISDN_STAT_PROT
-  arg = The lower 8 Bits define the adressed protocol as defined
+  arg = The lower 8 Bits define the addressed protocol as defined
 in ISDN_PTYPE..., the upper bits are used to differenciate
 the protocol specific STAT.  
   
diff -ur linux-2.4.1-ac4/Documentation/s390/cds.txt linux/Documentation/s390/cds.txt
--- linux-2.4.1-ac4/Documentation/s390/cds.txt  Thu Oct 12 23:19:31 2000
+++ linux/Documentation/s390/cds.txtWed Feb  7 00:00:06 2001
@@ -549,7 +549,7 @@
 
 typedef struct {
charcmd_code; /* command code */
-   charflags;/* flags, like IDA adressing, etc. */
+   charflags;/* flags, like IDA addressing, etc. */
unsigned short  count;/* byte count */
void   *cda;  /* data address */
 } ccw1_t __attribute__ ((aligned(8)));
diff -ur linux-2.4.1-ac4/arch/alpha/kernel/smp.c linux/arch/alpha/kernel/smp.c
--- linux-2.4.1-ac4/arch/alpha/kernel/smp.c Wed Jan  3 01:45:37 2001
+++ linux/arch/alpha/kernel/smp.c   Wed Feb  7 00:00:06 2001
@@ -837,7 +837,7 @@
atomic_set(_count, smp_num_cpus - 1);
atomic_set(_count, smp_num_cpus - 1);
 
-   /* Aquire the smp_call_function_data mutex.  */
+   /* Acquire the smp_call_function_data mutex.  */
if (pointer_lock(_call_function_data, , retry))
return -EBUSY;
 
diff -ur linux-2.4.1-ac4/arch/cris/boot/compressed/misc.c 
linux/arch/cris/boot/compressed/misc.c
--- linux-2.4.1-ac4/arch/cris/boot/compressed/misc.cWed Feb  7 00:02:53 2001
+++ linux/arch/cris/boot/compressed/misc.c  Wed Feb  7 00:00:06 2001
@@ -13,7 +13,7 @@
  */
 
 /* where the piggybacked kernel image expects itself to live.
- * it is the same adress we use when we network load an uncompressed
+ * it is the same address we use when we network load an uncompressed
  * image into DRAM, and it is the address the kernel is linked to live
  * at by etrax100.ld.
  */
diff -ur linux-2.4.1-ac4/arch/cris/cris.ld linux/arch/cris/cris.ld
--- linux-2.4.1-ac4/arch/cris/cris.ld   Wed Feb  7 00:02:53 2001
+++ linux/arch/cris/cris.ld Wed Feb  7 00:00:06 2001
@@ -55,7 +55,7 @@
___initcall_start = .;
.initcall.init : { *(.initcall.init) }
___initcall_end = .;
-   __vmlinux_end = .;/* last adress of the physical file */
+   __vmlinux_end = .;/* last address of the physical file */
. = ALIGN(8192);
___init_end = .;
 
diff -ur linux-2.4.1-ac4/arch/cris/drivers/ethernet.c 
linux/arch/cris/drivers/ethernet.c
--- linux-2.4.1-ac4/arch/cris/drivers/ethernet.cWed Feb  7 00:02:53 2001
+++ linux/arch/cris/drivers/ethernet.c  Wed Feb  7 00:00:06 2001
@@ -273,7 +273,7 @@
return 0;
 }
 
-/* set MAC adress of the interface. called from the core after a
+/* set MAC address of the interface. called from the core after a
  * SIOCSIFADDR ioctl, and from the bootup above.
  */
 
@@ -288,7 +288,7 @@
 memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
 
/* Write it to the hardware.
-* Note the way the adress is wrapped:
+* Note the way the address is wrapped:
 * *R_NETWORK_SA_0 = a0_0 | (a0_1 << 8) | (a0_2 << 16) | (a0_3 << 24);
 * *R_NETWORK_SA_1 = a0_4 | (a0_5 << 8);
 */
diff -ur linux-2.4.1-ac4/arch/i386/mm/fault.c linux/arch/i386/mm/fault.c
--- linux-2.4.1-ac4/arch/i386/mm/fault.cSun Nov 12 04:01:11 2000
+++ linux/arch/i386/mm/fault.c  Wed Feb  7 00:00:06 2001
@@ -81,7 +81,7 @@
 
 /*
  * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
+ * message out (timerlist_lock is acquired through the
  * 

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Ed Schulz]

My previous note was probably in error.  W. Michael Petullo probably is
really using a PCI internal Venus DSP1673 modem.  I read too quickly and
assumed that we were talking about the "Linmodem" topic.

I will pass the note around here, and will summarize any replies I get. 
Clearly we should try it under Linux 2.4.

Since Venus modems include the controller function along with RAM and
flash, they're generally more expensive than Mars host-contoller modems. 
Here are some models:
- Zoom 2920
- MultiTech MultiModem ZPX MT5634ZPX-PCI
- Actiontec Call Waiting PCI56012-01CW
-- 
Ed Schulz
Agere Systems
+1 732 949 2066 voice
+1 732 949 5025 fax
[EMAIL PROTECTED]

Theodore Ts'o wrote:
> 
> On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > > In serial.c, you seem to perform a check by writing to a possible
> > > modem's interrupt enable register and reading the result.  This seems to
> > > be one of the points at which the auto-configuration process occasionally
> > > fails.  If I make the following change to this code my modem seems to
> > > be auto-detected correctly all of the time:
> >
> > >scratch = serial_inp(info, UART_IER);
> > > serial_outp(info, UART_IER, 0);
> > > #ifdef __i386__
> > > outb(0xff, 0x080);
> > > #endif
> > > scratch2 = serial_inp(info, UART_IER);
> > > serial_outp(info, UART_IER, 0x0F);
> > > #ifdef __i386__
> > > outb(0, 0x080);
> > > #endif
> > > - scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > > + scratch3 = 0x0f/* ADD */
> > > serial_outp(info, UART_IER, scratch);
> 
> The problem is that if this doesn't work, there are some serious
> questions about the correctness of the Lucent Microelectronic Venus
> modem.  I've forwarded this to someone in the Lucent Modem group, who
> can hopefully look at this (and maybe can ship me a sample hardware so
> I can play with it, although I'd much rather that he tell me how to
> work around the hardware bug, or tell me that all you need is a
> firmware upgrade to fix the bug in the modem).
> 
> - Ted
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Marcelo Tosatti]

On Tue, 6 Feb 2001, Linus Torvalds wrote:

> Remember: in the end you HAVE to wait somewhere. You're always going to be
> able to generate data faster than the disk can take it. SOMETHING has to
> throttle - if you don't allow generic_make_request() to throttle, you have
> to do it on your own at some point. It is stupid and counter-productive to
> argue against throttling. The only argument can be _where_ that throttling
> is done, and READA/WRITEA leaves the possibility open of doing it
> somewhere else (or just delaying it and letting a future call with
> READ/WRITE do the throttling).

Its not "arguing against throttling". 

Its arguing against making a smart application block on the disk while its
able to use the CPU for other work.
 
An application which sets non blocking behavior and busy waits for a
request (which seems to be your argument) is just stupid, of course.



-
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: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Theodore Ts'o]

   Date: Tue, 06 Feb 2001 17:37:12 -0500
   From: Ed Schulz <[EMAIL PROTECTED]>

   One editorial correction: Our PCI host-controller modem is based on the
   Mars DSP1646 or 1648, not the Venus DSP1673.  Venus modems include the
   controller function, so require no special Linux code to work.

Well, I've received reports that the UART in the Venus chipset may not
be behaving as a standard UART (i.e., it's not acting as a fully
16550-compatible UART should) which is causing the Linux serial code to
fail the "is-there-a-real-UART-here-or-should-I-refuse-to-touch-unknown-
I/O-ports-which-might-format-hard-drives-or-do-other-nasty-things" test.

   I'll forward these notes along to our developers, and let you know the
   result.

If your developers can tell try testing one of these modems under Linux
2.4, that would be great.  Although I don't have one of these boards,
the symptoms that people are sending me sure make it sound like a
hardware bug (or a UART emulation failure, in any case)

Note that all the test code is doing is writing 0x0f to the UART's IER
register, and trying to read it back.  If the UART is failing this test,
it's pretty buggy.

- Ted
-
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] linux 2.4.1 to 2.4.1-ac3 hangs

[Ed Tomlinson]

Hi,

I have been see quite a few hangs on 2.4.1 thru 2.4.1-ac3.  By hang I mean 
that the box stops Shift scroll-lock etc have no effect.  I use a screen 
switch to share a monitor with a box setup as a serial console.  Even switch 
this freezes leading me to suspect the video signal is dieing.  Until it 
happen today I had no clue as to what was happening.  This time the following 
appeared on the serial console.

Starting periodic command scheduler: cron.
eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x7 length 0 
sta!eth1: Oversized Ethernet frame c6f96070 vs c6f96070.
eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x8 length 0 
sta!eth1: Oversized Ethernet frame c6f96080 vs c6f96080.
eth1: Oversized Ethernet frame spanned multiple buffers, entry 0x9 length 
1518 !eth1: Oversized Ethernet frame c6f96090 vs c6f96090.
Scheduling in interrupt

After this its dead.  

Here is some info on the boot and other stuff that might help.

PCI: PCI BIOS revision 2.10 entry at 0xfb520, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0586] at 00:07.0
Activating ISA DMA hang workarounds.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
matroxfb: Matrox Millennium G400 MAX (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26208)
matroxfb: framebuffer at 0xE800, mapped to 0xc8805000, size 33554432
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device

and a bit later (note: the this is how it appears on the serial console...)

alculating module dependencies... done.
Loading modules: tulip Note: /etc/modulLinux Tulip driver version 0.9.13b 
(Janu)es.conf is more PCI: Found IRQ 12 for device 00:09.0
:C0ent than /libeth0: Digital DS21140 Tulip rev 34 at 0xe800,/modules/2.4.1-a 
0p   :F0:32:30:70, IRQ 12.
eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
eth0:  MII transceiver #1 config 3000 status 7829 advertising 01e1.
via-rhine Note: /etc/modulvia-rhine.c:v1.08b-LK1.1.6  8/9/2000  Written by 
Donares.conf is more   http://www.scyld.com/network/via-rhine.html
recent than /libPCI: Found IRQ 11 for device 00:0a.0
/modules/2.4.1-aIRQ routing conflict in pirq table for device 00:0a.0
eth1: VIA VT3043 Rhine at 0xec00,
  00:80:c8:f9:ee:ba, IRQ 9.
eth1: MII PHY found at address 8, status 0x782d advertising 05e1 Link .
linear Note: /etc/modulmd driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
es.conf is more md.c: sizeof(mdp_super_t) = 4096
recent than /lib/modules/2.4.1-alinear personality registered
c3+/modules.dep

NOTE the message about a routing conflict of device 00:0a.0 

eth1 is used to run pppoeoscar# 

ifconfig eth1
eth1  Link encap:Ethernet  HWaddr 00:80:C8:F9:EE:BA
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:2057 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2007 errors:0 dropped:0 overruns:0 carrier:0
  collisions:2 txqueuelen:100
  Interrupt:9 Base address:0xec00

oscar# ifconfig ppp0
ppp0  Link encap:Point-to-Point Protocol
  inet addr:64.229.192.179  P-t-P:64.229.192.1  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
  RX packets:2116 errors:0 dropped:0 overruns:0 frame:0
  TX packets:2063 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:3

oscar% cat interrupts
   CPU0
  0: 116087  XT-PIC  timer
  1:   1910  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  4:835  XT-PIC  serial
  5:  34255  XT-PIC  Sound Blaster 16
  7:  0  XT-PIC  serial
  9:   3554  XT-PIC  eth1
 10:  10857  XT-PIC  usb-uhci
 11:  0  XT-PIC  mga@PCI:1:0:0
 12:   2339  XT-PIC  eth0
 14:  12146  XT-PIC  ide0
 15:  2  XT-PIC  ide1
NMI:  0
ERR:  0

lspci -vvxxx
00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B-
00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 d0 d0 00 00
20: 00 e4 f0 e7 00 e8 f0 e9 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
40: e0 ec 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Ed Schulz]

One editorial correction: Our PCI host-controller modem is based on the
Mars DSP1646 or 1648, not the Venus DSP1673.  Venus modems include the
controller function, so require no special Linux code to work.

I'll forward these notes along to our developers, and let you know the
result.

The "sample hardware" is available quite cheaply from many sources,
although it can be hard to tell what really has Mars inside.  Here are some
brand name PCI modems containing Mars:
- Zoom 3025 (with early Windows V.92 code)
- Zoom 2925L for under $50.
- ActionTec DeskLink Pro PCI for $33.
-- 
Ed Schulz
Agere Systems
[EMAIL PROTECTED]

Theodore Ts'o wrote:
> 
> On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > > In serial.c, you seem to perform a check by writing to a possible
> > > modem's interrupt enable register and reading the result.  This seems to
> > > be one of the points at which the auto-configuration process occasionally
> > > fails.  If I make the following change to this code my modem seems to
> > > be auto-detected correctly all of the time:
> >
> > >scratch = serial_inp(info, UART_IER);
> > > serial_outp(info, UART_IER, 0);
> > > #ifdef __i386__
> > > outb(0xff, 0x080);
> > > #endif
> > > scratch2 = serial_inp(info, UART_IER);
> > > serial_outp(info, UART_IER, 0x0F);
> > > #ifdef __i386__
> > > outb(0, 0x080);
> > > #endif
> > > - scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > > + scratch3 = 0x0f/* ADD */
> > > serial_outp(info, UART_IER, scratch);
> 
> The problem is that if this doesn't work, there are some serious
> questions about the correctness of the Lucent Microelectronic Venus
> modem.  I've forwarded this to someone in the Lucent Modem group, who
> can hopefully look at this (and maybe can ship me a sample hardware so
> I can play with it, although I'd much rather that he tell me how to
> work around the hardware bug, or tell me that all you need is a
> firmware upgrade to fix the bug in the modem).
> 
> - Ted
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Andre Hedrick]

On Tue, 6 Feb 2001, Linus Torvalds wrote:

> 
> 
> On Tue, 6 Feb 2001, Manfred Spraul wrote:
> > > 
> > > The aio functions should NOT use READA/WRITEA. They should just use the
> > > normal operations, waiting for requests.
> > 
> > But then you end with lots of threads blocking in get_request()
> 
> So?
> 
> What the HELL do you expect to happen if somebody writes faster than the
> disk can take?
> 
> You don't lik ebusy-waiting. Fair enough.
> 
> So maybe blocking on a wait-queue is the right thing? Just MAYBE?

Did I miss a portion of the thread?
Is the block layer ignoring the status of a device?

--Andre

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Jens Axboe wrote:

> On Tue, Feb 06 2001, Marcelo Tosatti wrote:
> > 
> > Reading write(2): 
> > 
> >EAGAIN Non-blocking  I/O has been selected using O_NONBLOCK and there was
> >   no room in the pipe or socket connected to fd to  write  the data
> >   immediately.
> > 
> > I see no reason why "aio function have to block waiting for requests". 
> 
> That was my reasoning too with READA etc, but Linus seems to want that we
> can block while submitting the I/O (as throttling, Linus?) just not
> until completion.

Note the "in the pipe or socket" part.
 ^^

EAGAIN is _not_ a valid return value for block devices or for regular
files. And in fact it _cannot_ be, because select() is defined to always
return 1 on them - so if a write() were to return EAGAIN, user space would
have nothing to wait on. Busy waiting is evil.

So READA/WRITEA are only useful inside the kernel, and when the caller has
some data structures of its own that it can use to gracefully handle the
case of a failure - it will try to do the IO later for some reasons, maybe
deciding to do it with blocking because it has nothing better to do at the
later date, or because it decides that it can have only so many
outstanding requests.

Remember: in the end you HAVE to wait somewhere. You're always going to be
able to generate data faster than the disk can take it. SOMETHING has to
throttle - if you don't allow generic_make_request() to throttle, you have
to do it on your own at some point. It is stupid and counter-productive to
argue against throttling. The only argument can be _where_ that throttling
is done, and READA/WRITEA leaves the possibility open of doing it
somewhere else (or just delaying it and letting a future call with
READ/WRITE do the throttling).

Linus

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

ibmtr.o does not like 2.4 [Was: IBM Model 350 does not like 2.4]

[J Sloan]

Hi,

Just to follow up on my own post, the problem is
way down in the network driver layer, specifically
in the ibmtr driver - it seems to be happy with 2.2,
and barfs with 2.4 - for now I replaced it with an
IBM pci card (olympic driver) and 2.4 is now solid
on the machine that had serious problems using
the isa token ring card.

I'l have a look at ibmtr if nobody beats me to it.

jjs

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Manfred Spraul wrote:
> > 
> > The aio functions should NOT use READA/WRITEA. They should just use the
> > normal operations, waiting for requests.
> 
> But then you end with lots of threads blocking in get_request()

So?

What the HELL do you expect to happen if somebody writes faster than the
disk can take?

You don't lik ebusy-waiting. Fair enough.

So maybe blocking on a wait-queue is the right thing? Just MAYBE?

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Marcelo Tosatti wrote:
> > > > We don't even need that, non-blocking is implicitly applied with READA.
> > > >
> > > READA just returns - I doubt that the aio functions should poll until
> > > there are free entries in the request queue.
> > 
> > The aio functions should NOT use READA/WRITEA. They should just use the
> > normal operations, waiting for requests. The things that makes them
> > asycnhronous is not waiting for the requests to _complete_. Which you can
> > already do, trivially enough.
> 
> Reading write(2): 
> 
>EAGAIN Non-blocking  I/O has been selected using O_NONBLOCK and there was
>   no room in the pipe or socket connected to fd to  write  the data
>   immediately.
> 
> I see no reason why "aio function have to block waiting for requests". 

That was my reasoning too with READA etc, but Linus seems to want that we
can block while submitting the I/O (as throttling, Linus?) just not
until completion.

-- 
Jens Axboe

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Marcelo Tosatti]

On Tue, 6 Feb 2001, Linus Torvalds wrote:

> 
> 
> On Tue, 6 Feb 2001, Manfred Spraul wrote:
> > Jens Axboe wrote:
> > > 
> > > > Several kernel functions need a "dontblock" parameter (or a callback, or
> > > > a waitqueue address, or a tq_struct pointer).
> > > 
> > > We don't even need that, non-blocking is implicitly applied with READA.
> > >
> > READA just returns - I doubt that the aio functions should poll until
> > there are free entries in the request queue.
> 
> The aio functions should NOT use READA/WRITEA. They should just use the
> normal operations, waiting for requests. The things that makes them
> asycnhronous is not waiting for the requests to _complete_. Which you can
> already do, trivially enough.

Reading write(2): 

   EAGAIN Non-blocking  I/O has been selected using O_NONBLOCK and there was
  no room in the pipe or socket connected to fd to  write  the data
  immediately.

I see no reason why "aio function have to block waiting for requests". 

_Why_ they do ? 

-
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: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

[Theodore Ts'o]

On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
> > In serial.c, you seem to perform a check by writing to a possible
> > modem's interrupt enable register and reading the result.  This seems to
> > be one of the points at which the auto-configuration process occasionally
> > fails.  If I make the following change to this code my modem seems to
> > be auto-detected correctly all of the time:
> 
> >scratch = serial_inp(info, UART_IER);
> > serial_outp(info, UART_IER, 0);
> > #ifdef __i386__
> > outb(0xff, 0x080);
> > #endif
> > scratch2 = serial_inp(info, UART_IER);
> > serial_outp(info, UART_IER, 0x0F);
> > #ifdef __i386__
> > outb(0, 0x080);
> > #endif
> > - scratch3 = serial_inp(info, UART_IER); /* REMOVE */
> > + scratch3 = 0x0f/* ADD */
> > serial_outp(info, UART_IER, scratch);

The problem is that if this doesn't work, there are some serious
questions about the correctness of the Lucent Microelectronic Venus
modem.  I've forwarded this to someone in the Lucent Modem group, who
can hopefully look at this (and maybe can ship me a sample hardware so
I can play with it, although I'd much rather that he tell me how to
work around the hardware bug, or tell me that all you need is a
firmware upgrade to fix the bug in the modem).

- Ted

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Manfred Spraul]

Linus Torvalds wrote:
> 
> On Tue, 6 Feb 2001, Manfred Spraul wrote:
> > Jens Axboe wrote:
> > >
> > > > Several kernel functions need a "dontblock" parameter (or a callback, or
> > > > a waitqueue address, or a tq_struct pointer).
> > >
> > > We don't even need that, non-blocking is implicitly applied with READA.
> > >
> > READA just returns - I doubt that the aio functions should poll until
> > there are free entries in the request queue.
> 
> The aio functions should NOT use READA/WRITEA. They should just use the
> normal operations, waiting for requests.

But then you end with lots of threads blocking in get_request()

Quoting Ben's mail:
<
> 
> =)  This is what I'm seeing: lots of processes waiting with wchan ==
> __get_request_wait.  With async io and a database flushing lots of io
> asynchronously spread out across the disk, the NR_REQUESTS limit is hit
> very quickly.
> 
>

On an io bound server the request queue is always full - waiting for the
next request might take longer than the actual io.

--
Manfred
-
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 for 2.4.1 disable printk and panic messages

[Stefani Seibold]

Hi,

this is an updated release of my patch for disabling all kernel
messages. It is usefull on deep embedded systems with no human interactions
and for rescue discs where the diskspace is always to less.

To Linus: What must i do, to get this patch in the offical kernel?

To Zack Brown: Not all kernel hackers are boys. I am by definition a girl ;-)
 
Greetings,
Stefani

-patch for 2.4.1disable printk and panic -

diff -u --recursive --new-file linux/CREDITS linux.noprintk/CREDITS
--- linux/CREDITS   Sun Dec 31 18:27:57 2000
+++ linux.noprintk/CREDITS  Fri Jan 26 10:51:19 2001
@@ -2396,6 +2396,14 @@
 S: Oldenburg
 S: Germany
 
+N: Stefani Seibold
+E: [EMAIL PROTECTED]
+D: Option to disable all kernel messages by overload printk with a
+D: dummy macro (saves a lot of disk- and ramspace for embedded systems
+D: and rescue disks).
+S: Munich
+S: Germany
+
 N: Darren Senn
 E: [EMAIL PROTECTED]
 D: Whatever I notice needs doing (so far: itimers, /proc)
diff -u --recursive --new-file linux/Documentation/Configure.help 
linux.noprintk/Documentation/Configure.help
--- linux/Documentation/Configure.help  Thu Jan  4 22:00:55 2001
+++ linux.noprintk/Documentation/Configure.help Sun Jan 28 10:57:29 2001
@@ -12224,6 +12224,14 @@
   If unsure, say Y, or else you won't be able to do much with your new
   shiny Linux system :-)
 
+Disable kernel messages
+CONFIG_NOPRINTK
+  This option allows you to disable all kernel messages by overriding
+  the printk function a dummy macro.
+  On small embedded systems, this save a lot of rom and ram space. On
+  server or desktop systems you want human readable outputs, so it is
+  normally the best choice to say N to this option.
+
 Support for console on virtual terminal
 CONFIG_VT_CONSOLE
   The system console is the device which receives all kernel messages
diff -u --recursive --new-file linux/arch/alpha/config.in 
linux.noprintk/arch/alpha/config.in
--- linux/arch/alpha/config.in  Fri Dec 29 23:07:19 2000
+++ linux.noprintk/arch/alpha/config.in Sun Jan 28 10:56:21 2001
@@ -359,6 +359,7 @@
 fi
 
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 
 bool 'Legacy kernel start address' CONFIG_ALPHA_LEGACY_START_ADDRESS
 
diff -u --recursive --new-file linux/arch/arm/config.in 
linux.noprintk/arch/arm/config.in
--- linux/arch/arm/config.inThu Nov 16 21:51:28 2000
+++ linux.noprintk/arch/arm/config.in   Sun Jan 28 10:55:58 2001
@@ -414,6 +414,7 @@
 bool 'Verbose user fault messages' CONFIG_DEBUG_USER
 bool 'Include debugging information in kernel binary' CONFIG_DEBUG_INFO
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 if [ "$CONFIG_CPU_26" = "y" ]; then
bool 'Disable pgtable cache' CONFIG_NO_PGT_CACHE
 fi
diff -u --recursive --new-file linux/arch/i386/config.in 
linux.noprintk/arch/i386/config.in
--- linux/arch/i386/config.in   Fri Dec 29 23:35:47 2000
+++ linux.noprintk/arch/i386/config.in  Sun Jan 28 10:56:04 2001
@@ -366,4 +366,5 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file linux/arch/ia64/config.in 
linux.noprintk/arch/ia64/config.in
--- linux/arch/ia64/config.in   Thu Jan  4 21:50:17 2001
+++ linux.noprintk/arch/ia64/config.in  Sun Jan 28 10:56:07 2001
@@ -249,6 +249,7 @@
 fi
 
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 bool 'Early printk support (requires VGA!)' CONFIG_IA64_EARLY_PRINTK
 bool 'Turn on compare-and-exchange bug checking (slow!)' 
CONFIG_IA64_DEBUG_CMPXCHG
 bool 'Turn on irq debug checks (slow!)' CONFIG_IA64_DEBUG_IRQ
diff -u --recursive --new-file linux/arch/m68k/config.in 
linux.noprintk/arch/m68k/config.in
--- linux/arch/m68k/config.in   Thu Jan  4 22:00:55 2001
+++ linux.noprintk/arch/m68k/config.in  Sun Jan 28 10:56:09 2001
@@ -538,4 +538,5 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file linux/arch/mips/config.in 
linux.noprintk/arch/mips/config.in
--- linux/arch/mips/config.in   Thu Nov 16 21:51:28 2000
+++ linux.noprintk/arch/mips/config.in  Sun Jan 28 10:56:12 2001
@@ -397,4 +397,5 @@
   bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
 fi
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file linux/arch/mips64/config.in 
linux.noprintk/arch/mips64/config.in
--- linux/arch/mips64/config.in Wed Nov 29 06:42:04 2000
+++ linux.noprintk/arch/mips64/config.inSun Jan 28 10:56:31 2001
@@ -266,4 +266,5 @@
 fi
 bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Disable kernel messages' CONFIG_NOPRINTK
 endmenu
diff -u --recursive --new-file linux/arch/parisc/config.in 

[PATCH] drivers/media/radio/radio-maxiradio.c - 2.4.1-ac4

[Francois romieu]

Changes:
- pci_enable_device return value wasn't checked,
- unbalanced video_register_device if late failure in radio_install,
- request_region is now done on the whole resource size (if it's wrong, the
magic value "4" deserves a small comment imho),
- new pci interface beautification (may help the multi-devices case).
Test:
- it compiles great (TM)

Diff output is rather weird

--- linux-2.4.1-ac4.orig/drivers/media/radio/radio-maxiradio.c  Tue Feb  6 21:48:07 
2001
+++ linux-2.4.1-ac4/drivers/media/radio/radio-maxiradio.c   Tue Feb  6 22:31:02 
+2001
@@ -308,80 +308,77 @@
 {
 }
 
-
-inline static __u16 radio_install(struct pci_dev *pcidev);
-
 MODULE_AUTHOR("Dimitromanolakis Apostolos, [EMAIL PROTECTED]");
 MODULE_DESCRIPTION("Radio driver for the Guillemot Maxi Radio FM2000 radio.");
 
 EXPORT_NO_SYMBOLS;
 
-void __exit maxiradio_radio_exit(void)
+static int __devinit maxiradio_init_one(struct pci_dev *pdev, struct pci_device_id 
+*ent)
 {
-   video_unregister_device(_radio);
+   if(!request_region(pci_resource_start(pdev, 0),
+  pci_resource_len(pdev, 0), "Maxi Radio FM 2000")) {
+   printk(KERN_ERR "radio-maxiradio: can't reserve I/O ports\n");
+   goto err_out;
+   }
+   if (pci_enable_device(pdev))
+   goto err_out_free_region;
 
-   release_region(radio_unit.io,4);
-}
+   radio_unit.io = pci_resource_start(pdev, 0);
+   init_MUTEX(_unit.lock);
+   maxiradio_radio.priv = _unit;
 
-int __init maxiradio_radio_init(void)
-{
-   struct pci_dev *pcidev = NULL;
-   int found;
-   
-   if(!pci_present())
-   return -ENODEV;
-   
-   found = 0;
-
-   pcidev = pci_find_device(PCI_VENDOR_ID_GUILLEMOT, 
-   
PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO,
- pcidev);
-   
-   found += radio_install(pcidev);
-   
-   if(found == 0) {
-   printk(KERN_INFO "radio-maxiradio: no devices found.\n");
-   return -ENODEV;
+   if(video_register_device(_radio, VFL_TYPE_RADIO)==-1) {
+   printk("radio-maxiradio: can't register device!");
+   goto err_out_free_region;
}
 
+
+   printk(KERN_INFO "radio-maxiradio: version "
+  DRIVER_VERSION
+  " time "
+  __TIME__ "  "
+  __DATE__
+  "\n");
+
+   printk(KERN_INFO "radio-maxiradio: found Guillemot MAXI Radio device (io = 
+0x%x)\n",
+  radio_unit.io);
return 0;
-}
 
-module_init(maxiradio_radio_init);
-module_exit(maxiradio_radio_exit);
+err_out_free_region:
+   release_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
+err_out:
+   return -ENODEV;
+}
 
-inline static __u16 radio_install(struct pci_dev *pcidev)
+static void __devexit maxiradio_remove_one(struct pci_dev *pdev)
 {
-   radio_unit.io = pcidev->resource[0].start;
+   video_unregister_device(_radio);
+   release_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
+}
 
-   pci_enable_device(pcidev);
-   maxiradio_radio.priv = _unit;
-   init_MUTEX(_unit.lock);
-   
-   if(video_register_device(_radio, VFL_TYPE_RADIO)==-1) {
-   printk("radio-maxiradio: can't register device!");
-   return 0;
-   }
-   
-   
-   printk(KERN_INFO "radio-maxiradio: version "
-  DRIVER_VERSION 
-  "\n");
-
-   printk(KERN_INFO 
-   "radio-maxiradio: found Guillemot MAXI Radio device (io = 0x%x)\n",
-   radio_unit.io
-   );
-
-
-   if(!request_region(radio_unit.io, 4, "Maxi Radio FM 2000"))
-   {
-   printk(KERN_ERR "radio-maxiradio: port 0x%x already in use\n",
-   radio_unit.io);
-   
-   return 0;
-   }
+static struct pci_device_id maxiradio_pci_tbl[] __devinitdata = {
+   { PCI_VENDOR_ID_GUILLEMOT, PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO,
+   PCI_ANY_ID, PCI_ANY_ID, },
+   { 0,}
+};
+MODULE_DEVICE_TABLE(pci, maxiradio_pci_tbl);
+
+static struct pci_driver maxiradio_driver = {
+   name:   "rqdio-maxiradio",
+   id_table:   maxiradio_pci_tbl,
+   probe:  maxiradio_init_one,
+   remove: maxiradio_remove_one,
+};
+
+int __init maxiradio_radio_init(pdev)
+{
+   return pci_register_driver(_driver);
+}
 
-   return 1;
+void __exit maxiradio_radio_exit(void)
+{
+   pci_unregister_driver(_driver);
 }
 
+module_init(maxiradio_radio_init);
+module_exit(maxiradio_radio_exit);

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL 

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Manfred Spraul wrote:
> Jens Axboe wrote:
> > 
> > > Several kernel functions need a "dontblock" parameter (or a callback, or
> > > a waitqueue address, or a tq_struct pointer).
> > 
> > We don't even need that, non-blocking is implicitly applied with READA.
> >
> READA just returns - I doubt that the aio functions should poll until
> there are free entries in the request queue.

The aio functions should NOT use READA/WRITEA. They should just use the
normal operations, waiting for requests. The things that makes them
asycnhronous is not waiting for the requests to _complete_. Which you can
already do, trivially enough.

The case for using READA/WRITEA is not that you want to do asynchronous
IO (all Linux IO is asynchronous unless you do extra work), but because
you have a case where you _might_ want to start IO, but if you don't have
a free request slot (ie there's already tons of pending IO happening), you
want the option of doing something else. This is not about aio - with aio
you _need_ to start the IO, you're just not willing to wait for it. 

An example of READA/WRITEA is if you want to do opportunistic dirty page
cleaning - you might not _have_ to clean it up, but you say

 "Hmm.. if you can do this simply without having to wait for other
  requests, start doing the writeout in the background. If notm I'll come
  back to you later after I've done more real work.."

And the Linux block device layer supports both of these kinds of "delayed
IO" already. It's all there. Today.

Linus

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

[RFC][PATCH] block ioctl to read/write last sector

[Michael E Brown]

Problem Summary:
  There is no function exported to userspace to read or write the last
512-byte sector of an odd-size disk.

  The block device uses 1K blocksize, and will prevent userspace from
seeing the odd-block at the end of the disk, if the disk is odd-size.

  IA-64 architecture defines a new partitioning scheme where there is a
backup of the partition table header in the last sector of the disk. While
we can read and write to this sector in the kernel partition code, we have
no way for userspace to update this partition block.

Solution:
  As an interim solution, I propose the following IOCTLs for the block
device layer: BLKGETLASTSECT and BLKSETLASTSECT.  These ioctls will take a
userspace pointer to a char[512] and read/write the last sector. Below is
a patch to do this.

I have attached the patch as well, because I've heard that Pine will eat
patches. :-(

--
Michael Brown
Linux System Group
Dell Computer Corp


diff -ruP linux/drivers/block/blkpg.c linux-meb-clean/drivers/block/blkpg.c
--- linux/drivers/block/blkpg.c Fri Oct 27 01:35:47 2000
+++ linux-meb-clean/drivers/block/blkpg.c   Mon Jan 22 10:00:04 2001
@@ -39,6 +39,9 @@

 #include 

+static int set_last_sector( kdev_t dev, char *sect );
+static int get_last_sector( kdev_t dev, char *sect );
+
 /*
  * What is the data describing a partition?
  *
@@ -208,8 +211,19 @@
 int blk_ioctl(kdev_t dev, unsigned int cmd, unsigned long arg)
 {
int intval;
+unsigned long longval;

switch (cmd) {
+   case BLKGETLASTSECT:
+   return get_last_sector(dev, (char *)(arg));
+
+   case BLKSETLASTSECT:
+   if( is_read_only(dev) )
+   return -EACCES;
+   if (!capable(CAP_SYS_ADMIN))
+   return -EACCES;
+   return set_last_sector(dev, (char *)(arg));
+
case BLKROSET:
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -281,3 +295,140 @@
 }

 EXPORT_SYMBOL(blk_ioctl);
+
+ /*
+  * get_last_sector()
+  *
+  * Description: This function will return the first 512 bytes of the last sector of
+  *a block device.
+  * Why: Normal read/write calls through the block layer will not read the last sector
+  *of an odd-size disk.
+  * parameters:
+  *dev: a kdev_t that represents the device for which we want the last sector
+  *sect: a userspace pointer, should be at least char[512] to hold the last 
+sector contents
+  * return:
+  *0 on success
+  *   -ERRVAL on error.
+  */
+int get_last_sector( kdev_t dev, char *sect )
+{
+struct buffer_head *bh;
+struct gendisk *g;
+int m, rc = 0;
+unsigned int lba;
+int orig_blksize = BLOCK_SIZE;
+int hardblocksize;
+
+if( !dev ) return -EINVAL;
+
+m = MAJOR(dev);
+for (g = gendisk_head; g; g = g->next)
+if (g->major == m)
+break;
+
+if( !g ) return -EINVAL;
+
+lba = g->part[MINOR(dev)].nr_sects - 1;
+
+if( !lba ) return -EINVAL;
+
+hardblocksize = get_hardblocksize(dev);
+if( ! hardblocksize ) hardblocksize = 512;
+
+ /* Need to change the block size that the block layer uses */
+if (blksize_size[MAJOR(dev)]){
+orig_blksize = blksize_size[MAJOR(dev)][MINOR(dev)];
+}
+if (orig_blksize != hardblocksize)
+   set_blocksize(dev, hardblocksize);
+
+bh =  bread(dev, lba, hardblocksize);
+if (!bh) {
+   /* We hit the end of the disk */
+   printk(KERN_WARNING
+  "get_last_sector ioctl: bread returned NULL.\n");
+   return -1;
+}
+
+rc = copy_to_user(sect, bh->b_data, (bh->b_size > 512) ? 512 : bh->b_size );
+
+brelse(bh);
+
+/* change block size back */
+if (orig_blksize != hardblocksize)
+   set_blocksize(dev, orig_blksize);
+
+return rc;
+}
+
+
+ /*
+  * set_last_sector()
+  *
+  * Description: This function will write the first 512 bytes of the last sector of
+  *a block device.
+  * Why: Normal read/write calls through the block layer will not read the last sector
+  *of an odd-size disk.
+  * parameters:
+  *dev: a kdev_t that represents the device for which we want the last sector
+  *sect: a userspace pointer, should be at least char[512] to hold the last 
+sector contents
+  * return:
+  *0 on success
+  *   -ERRVAL on error.
+  */
+int set_last_sector( kdev_t dev, char *sect )
+{
+struct buffer_head *bh;
+struct gendisk *g;
+int m, rc = 0;
+unsigned int lba;
+int orig_blksize = BLOCK_SIZE;
+int hardblocksize;
+
+if( !dev ) return 

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Manfred Spraul]

Jens Axboe wrote:
> 
> > Several kernel functions need a "dontblock" parameter (or a callback, or
> > a waitqueue address, or a tq_struct pointer).
> 
> We don't even need that, non-blocking is implicitly applied with READA.
>
READA just returns - I doubt that the aio functions should poll until
there are free entries in the request queue.

The pending aio requests should be "included" into the wait_for_requests
waitqueue (ok, they don't have a process context, thus a wait queue
entry doesn't help, but these requests belong into that wait queue)

--
Manfred
-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Steve Lord]

> 
> On Tue, 6 Feb 2001, Marcelo Tosatti wrote:
> 
> > Think about a given number of pages which are physically contiguous on
> > disk -- you dont need to cache the block number for each page, you
> > just need to cache the physical block number of the first page of the
> > "cluster".
> 
> ranges are a hell of a lot more trouble to get right than page or
> block-sized objects - and typical access patterns are rarely 'ranged'. As
> long as the basic unit is not 'too small' (ie. not 512 byte, but something
> more sane, like 4096 bytes), i dont think ranging done in higher levels
> buys us anything valuable. And we do ranging at the request layer already
> ... Guess why most CPUs ended up having pages, and not "memory ranges"?
> It's simpler, thus faster in the common case and easier to debug.
> 
> > Usually we need to cache only block information (for clustering), and
> > not all the other stuff which buffer_head holds.
> 
> well, the other issue is that buffer_heads hold buffer-cache details as
> well. But i think it's too small right now to justify any splitup - and
> those issues are related enough to have significant allocation-merging
> effects.
> 
>   Ingo

Think about it from the point of view of being able to reduce the number of
times you need to talk to the allocator in a filesystem. You can talk to
the allocator about all of your readahead pages in one go, or you can do
things like allocate on flush rather than allocating page at a time (that is
a bit more complex, but not too much).

Having to talk to the allocator on a page by page basis is my pet peeve about
the current mechanisms.

Steve



-
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: FA-311 / Natsemi problems with 2.4.1

[Jocelyn Mayer]

I found something from OpenBSD:
the natsemi chip (in fact DP83815)
is quite the same as SiS900 one.
You'll find as attachement the driver code
from OpenBSD.
If someone wo knows something about OpenBSD driver
could merge the driver drivers into Linux,
I think it would be a real great deal !

Jocelyn Mayer



 openBSD-national.tgz

Re: d-link dfe-530 tx (bug-report)

[Jonathan Morton]

I just installed Urban's most recent patch, and I still get much the same
problems when I reboot from Windows.  The main difference appears to be
that there's a few seconds' pause during the via-rhine driver
initialisation (presumably while it tries to find PHY devices), and there
aren't quite so many "transmit timed out" messages in the system log after
booting.  They do still appear though, and the network is not accessible.
This happens when I reboot from Windows, and when I subsequently soft-power
the machine and turn it back on.  If also happens if I soft-power the
machine from Windows and switch on straight into Linux.

In short, the card still needs a hard power-off for Linux to get it working
after Windows.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-END GEEK CODE BLOCK-


-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Linus Torvalds]

On Tue, 6 Feb 2001, Christoph Hellwig wrote:
> 
> The second is that bh's are two things:
> 
>  - a cacheing object
>  - an io buffer

Actually, they really aren't.

They kind of _used_ to be, but more and more they've moved away from that
historical use. Check in particular the page cache, and as a really
extreme case the swap cache version of the page cache.

It certainly _used_ to be true that "bh"s were actually first-class memory
management citizens, and actually had a data buffer and a cache associated
with them. And because of that historical baggage, that's how many people
still think of them.

These days, it's really not true any more. A "bh" doesn't really have an
IO buffer intrisically associated with it any more - all memory management
is done on a _page_ level, and it really works the other way around, ie a
page can have one or more bh's associated with it as the IO entity.

This _does_ show up in the bh itself: you find that bh's end up having the
bh->b_page pointer in it, which is really a layering violation these days,
but you'll notice that it's actually not used very much, and it could
probably be largely removed.

The most fundamental use of it (from an IO standpoint) is actually to
handle high memory issues, because high-memory handling is very
fundamentally based on "struct page", and in order to be able to have
high-memory IO buffers you absolutely have to have the "struct page" the
way things are done now.

(all the other uses tend to not be IO-related at all: they are stuff like
the callbacks that want to find the page that should be free'd up)

The other part of "struct bh" is that it _does_ have support for fast
lookups, and the bh hashing. Again, from a pure IO standpoint you can
easily choose to just ignore this. It's often not used at all (in fact,
_most_ bh's aren't hashed, because the only way to find them are through
the page cache).

> This is not really an clean appropeach, and I would really like to
> get away from it.

Trust me, you really _can_ get away from it. It's not designed into the
bh's at all. You can already just allocate a single (or multiple) "struct
buffer_head" and just use them as IO objects, and give them your _own_
pointers to the IO buffer etc.

In fact, if you look at how the page cache is organized, this is what the
page cache already does. The page cache has it's own IO buffer (the page
itself), and it just uses "struct buffer_head" to allocate temporary IO
entities. It _also_ uses the "struct buffer_head" to cache the meta-data
in the sense of having the buffer head also contain the physical address
on disk so that the page cache doesn't have to ask the low-level
filesystem all the time, so in that sense it actually has a double use for
it.

But you can (and _should_) think of that as a "we got the meta-data
address caching for free, and it fit with our historical use, so why not
use it?".

So you can easily do the equivalent of

 - maintain your own buffers (possibly by looking up pages directly from
   user space, if you want to do zero-copy kind of things)

 - allocate a private buffer head ("get_unused_buffer_head()")

 - make that buffer head point into your buffer

 - submit the IO by just calling "submit_bh()", using the b_end_io()
   callback as your way to maintain _your_ IO buffer ownership.

In particular, think of the things that you do NOT have to do:

 - you do NOT have to allocate a bh-private buffer. Just point the bh at
   your own buffer.
 - you do NOT have to "give" your buffer to the bh. You do, of course,

   want to know when the bh is done with _your_ buffer, but that's what
   the b_end_io callback is all about.

 - you do NOT have to hash the bh you allocated and thus expose it to
   anybody else. It is YOUR private bh, and it does not show up on ANY
   other lists. There are various helper functions to insert the bh on
   various global lists ("mark_bh_dirty()" to put it on the dirty list,
   "buffer_insert_inode_queue()" to put it on the inode lists etc, but
   there is nothing in the thing that _forces_ you to expose your bh.

So don't think of "bh->b_data" as being something that the bh owns. It's
just a pointer. Think of "bh->b_data" and "bh->b_size" as _nothing_ more
than a data range in memory. 

In short, you can, and often should, think of "struct buffer_head" as
nothing but an IO entity. It has some support for being more than that,
but that's secondary. That can validly be seen as another layer, that is
just so common that there is little point in splitting it up (and a lot of
purely historical reasons for not splitting it).

Linus

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Ingo Molnar]

On Tue, 6 Feb 2001, Marcelo Tosatti wrote:

> Think about a given number of pages which are physically contiguous on
> disk -- you dont need to cache the block number for each page, you
> just need to cache the physical block number of the first page of the
> "cluster".

ranges are a hell of a lot more trouble to get right than page or
block-sized objects - and typical access patterns are rarely 'ranged'. As
long as the basic unit is not 'too small' (ie. not 512 byte, but something
more sane, like 4096 bytes), i dont think ranging done in higher levels
buys us anything valuable. And we do ranging at the request layer already
... Guess why most CPUs ended up having pages, and not "memory ranges"?
It's simpler, thus faster in the common case and easier to debug.

> Usually we need to cache only block information (for clustering), and
> not all the other stuff which buffer_head holds.

well, the other issue is that buffer_heads hold buffer-cache details as
well. But i think it's too small right now to justify any splitup - and
those issues are related enough to have significant allocation-merging
effects.

Ingo

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Marcelo Tosatti]

On Tue, 6 Feb 2001, Ingo Molnar wrote:

> 
> On Tue, 6 Feb 2001, Christoph Hellwig wrote:
> 
> > The second is that bh's are two things:
> >
> >  - a cacheing object
> >  - an io buffer
> >
> > This is not really an clean appropeach, and I would really like to get
> > away from it.
> 
> caching bmap() blocks was a recent addition around 2.3.20, and i suggested
> some time ago to cache pagecache blocks via explicit entries in struct
> page. That would be one solution - but it creates overhead.

Think about a given number of pages which are physically contiguous on
disk -- you dont need to cache the block number for each page, you just
need to cache the physical block number of the first page of the
"cluster".

SGI's pagebuf do that, and it would be great if we had something similar
in 2.5. 

It allows us to have fast IO clustering. 

> but there isnt anything wrong with having the bhs around to cache blocks -
> think of it as a 'cached and recycled IO buffer entry, with the block
> information cached'.

Usually we need to cache only block information (for clustering), and not
all the other stuff which buffer_head holds.

> frankly, my quick (and limited) hack to abuse bhs to cache blocks just
> cannot be a reason to replace bhs ...


-
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: [OT] Re: Matrox G450 problems with 2.4.0 and xfree

[David Woodhouse]

On Tue, 6 Feb 2001, Mike A. Harris wrote:

> If anyone has open source g450 patches against stock 4.0.2 that
> get the thing to work at all, _please_ send me unified diffs, and
> I will put them into my next build.  I've yet to have my g450 do
> anything but turn off my monitor, although a handful of people
> claim they get it working to various degrees...  I don't have
> g450 specs either so..

We're getting significantly off-topic for linux-kernel. But the patch
below worked for me in my limited testing - starting the X server twice in
different modes on a colleague's G450.

It's almost, but not quite, identical to the changes in the RH7.1 beta 
RPM. It's against (and was tested with) the current CVS, but applies 
cleanly to 4.0.2 as well. Almost _functionally_ identical, that is - some 
of their original offended me so much it just had to be cleaned up.

diff -uNr mga-preg450/Imakefile mga/Imakefile
--- mga-preg450/Imakefile   Sat Feb  3 23:53:49 2001
+++ mga/Imakefile   Sun Feb  4 00:05:36 2001
@@ -57,10 +57,10 @@
 
 MGASRCS = mga_driver.c mga_hwcurs.c /* mga_cmap.c */ mga_dac3026.c mga_dacG.c \
mga_storm8.c mga_storm16.c mga_storm24.c mga_storm32.c mga_arc.c \
-   mga_dga.c mga_shadow.c mga_video.c  $(DRISRCS)
+   mga_dga.c mga_shadow.c mga_video.c mga_g450pll.c  $(DRISRCS)
 MGAOBJS = mga_driver.o mga_hwcurs.o /* mga_cmap.o */ mga_dac3026.o mga_dacG.o \
mga_storm8.o mga_storm16.o mga_storm24.o mga_storm32.o mga_arc.o \
-   mga_dga.o mga_shadow.o mga_video.o  $(DRIOBJS)
+   mga_dga.o mga_shadow.o mga_video.o mga_g450pll.o  $(DRIOBJS)
 
 SRCS = $(MGASRCS) $(MGAHALSRCS)
 OBJS = $(MGAOBJS) $(MGAHALOBJS)
diff -uNr mga-preg450/mga.h mga/mga.h
--- mga-preg450/mga.h   Sat Feb  3 23:53:50 2001
+++ mga/mga.h   Sun Feb  4 00:06:02 2001
@@ -414,4 +414,5 @@
 void MGAInitVideo(ScreenPtr pScreen);
 void MGAResetVideo(ScrnInfoPtr pScrn); 
 
+double G450SetPLLFreq(ScrnInfoPtr pScrn, long f_out);
 #endif
diff -uNr mga-preg450/mga_dacG.c mga/mga_dacG.c
--- mga-preg450/mga_dacG.c  Sat Feb  3 23:53:53 2001
+++ mga/mga_dacG.c  Sun Feb  4 00:29:12 2001
@@ -237,6 +237,11 @@
/* The actual frequency output by the clock */
double f_pll;
 
+   if(MGAISG450(pMga)) {
+   G450SetPLLFreq(pScrn, f_out);
+   return;
+   }
+
/* Do the calculations for m, n, p and s */
f_pll = MGAGCalcClock( pScrn, f_out, , , ,  );
 
@@ -338,6 +343,9 @@
 #ifdef USEMGAHAL
   MGA_HAL(break;);
 #endif
+  if (MGAISG450(pMga))
+  break;
+
   if(pMga->Dac.maxPixelClock == 36) {  /* G400 MAX */
   if(pMga->OverclockMem) {
/* 150/200  */
@@ -528,6 +536,10 @@
if (mode->Flags & V_DBLSCAN)
pVga->CRTC[9] |= 0x80;
 
+   if(MGAISG450(pMga)) {
+   OUTREG(MGAREG_ZORG, 0);
+   }
+
MGAGSetPCLK(pScrn, mode->Clock);
);  /* MGA_NOT_HAL */
 
@@ -656,7 +668,10 @@
(i == 0x1b) ||
(i == 0x1c) ||
   ((i >= 0x1f) && (i <= 0x29)) ||
-  ((i >= 0x30) && (i <= 0x37)) )
+  ((i >= 0x30) && (i <= 0x37)) ||
+   (MGAISG450(pMga) &&
+((i == 0x2c) || (i == 0x2d) || (i == 0x2e) ||
+ (i == 0x4c) || (i == 0x4d) || (i == 0x4e
continue; 
outMGAdac(i, mgaReg->DacRegs[i]);
}
@@ -665,15 +680,17 @@
   should be correct already */
optionMask = (pMga->Primary) ? OPTION1_MASK_PRIMARY : OPTION1_MASK; 
 
-   /* restore pci_option register */
-   pciSetBitsLong(pMga->PciTag, PCI_OPTION_REG, optionMask,
-  mgaReg->Option);
-   if (pMga->Chipset != PCI_CHIP_MGA1064)
-   pciSetBitsLong(pMga->PciTag, PCI_MGA_OPTION2, OPTION2_MASK,
-  mgaReg->Option2);
-   if (pMga->Chipset == PCI_CHIP_MGAG400)
-   pciSetBitsLong(pMga->PciTag, PCI_MGA_OPTION3, OPTION3_MASK,
-  mgaReg->Option3);
+   if (!MGAISG450(pMga)) {
+   /* restore pci_option register */
+   pciSetBitsLong(pMga->PciTag, PCI_OPTION_REG, optionMask,
+  mgaReg->Option);
+   if (pMga->Chipset != PCI_CHIP_MGA1064)
+   pciSetBitsLong(pMga->PciTag, PCI_MGA_OPTION2, OPTION2_MASK,
+  mgaReg->Option2);
+   if (pMga->Chipset == PCI_CHIP_MGAG400)
+   pciSetBitsLong(pMga->PciTag, PCI_MGA_OPTION3, OPTION3_MASK,
+  mgaReg->Option3);
+   }
);  /* MGA_NOT_HAL */
 
/* restore CRTCEXT regs */
diff -uNr mga-preg450/mga_g450pll.c mga/mga_g450pll.c
--- mga-preg450/mga_g450pll.c   Thu Jan  1 01:00:00 1970
+++ mga/mga_g450pll.c   Sun Feb  4 00:00:04 2001
@@ -0,0 +1,444 @@
+/* All drivers 

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Ben LaHaise wrote:
> =)  This is what I'm seeing: lots of processes waiting with wchan ==
> __get_request_wait.  With async io and a database flushing lots of io
> asynchronously spread out across the disk, the NR_REQUESTS limit is hit
> very quickly.

You can't do async I/O this way! In going what Linus said, make submit_bh
return an int telling you if it failed to queue the buffer and use
READA/WRITEA to submit it.

-- 
Jens Axboe

-
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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

[Jens Axboe]

On Tue, Feb 06 2001, Manfred Spraul wrote:
> > =)  This is what I'm seeing: lots of processes waiting with wchan ==
> > __get_request_wait.  With async io and a database flushing lots of io
> > asynchronously spread out across the disk, the NR_REQUESTS limit is hit
> > very quickly.
> >
> Has that anything to do with kiobuf or buffer head?

Nothing

> Several kernel functions need a "dontblock" parameter (or a callback, or
> a waitqueue address, or a tq_struct pointer). 

We don't even need that, non-blocking is implicitly applied with READA.

-- 
Jens Axboe

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