RE: semaphores and noatomic flag

[Anil Kumar]

Will it not be a very specialized case rather than being general call type?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise
Sent: Monday, June 04, 2001 11:05 PM
To: [EMAIL PROTECTED]
Subject: semaphores and noatomic flag


I write this to discuss the reasons why the semop system call should
have an IPC_NOATOMIC flag.

Suppose we have two processes, called client and server, which
communicate through a shared memory segment and two semaphores, and need
to synchonize their activities so that they don't operate simultaneously
except at startup.

The server would do,

down(smephore 0)

to wait for a message from the client. When the client needs the server
to execute, it would,

up(semaphore 0) /* wake up server */
down(semaphore 1)   /* put itself to sleep */

after the server has completed its portion of the task, it would,

up(semaphore 1) /* wake up client */
down(semaphore 0)   /* put iself to sleep */

The problem is that the two system calls make the whole process twice as
slow as it needs to be, and they are both needed because the semop
system call is implemented in an atomic manner. If the semop system call
had an IPC_NOATOMIC flag, then the each process would only have to do
one call,

semop(up semaphore 0 & down semaphore 1, IPC_NOATOMIC)

which would be interpreted in the kernel as the sequence of two system
calls I have written previously.

I want to know what other people think about this idea.

Mihai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/devfs/base.c

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Bill Pringlemeir <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> There was a discussion on comp.arch.embedded about bounded stack use.
> It is fairly easy to calculate the stack usage for call trees, but
> much more difficult for `DAGs'.  Ie, a recursive functions etc.
> 

It's trivial to calculate for DAGs -- directed acyclic graphs.  It's
when the "acyclic" constraint is violated that you have problems!

-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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] devfs v179 available

[Richard Gooch]

  Hi, all. Version 179 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.

Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz

AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz

This is against 2.4.5. Highlights of this release:

- Adjusted  to account for  fix

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Speed to please all......

[Andre Hedrick]

beetle:/src/DiskPerf-1.0.5 # ./DiskPerf.rw /dev/hdb
Device: Maxtor 5T020H2 Serial Number: T2J0HC0C
LBA 0 DMA Read Test  = 68.82 MB/Sec (3.63 Seconds)
Outer Diameter Sequential DMA Read Test  = 36.68 MB/Sec (6.81 Seconds)
Inner Diameter Sequential DMA Read Test  = 21.36 MB/Sec (11.70 Seconds)
LBA 1 DMA Write Test = 65.57 MB/Sec (3.81 Seconds)
Outer Diameter Sequential DMA Write Test = 36.89 MB/Sec (6.78 Seconds)
Inner Diameter Sequential DMA Write Test = 21.42 MB/Sec (11.67 Seconds)

The new driver for 2.5 can read and write at near the same speeds.

Andre Hedrick
ASL Kernel Development
Linux ATA 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Where can find document of RPC program in kernel.

[hugang]

Hello:

I try to write a kernel modules with RPC (SUN Remote Procedure Call)
,Someone know where can find documents for it. 

thanks 

-- 
Best Regard!
Àñ£¡
--
mail from: hugang [ºú¸Õ]
mail : [EMAIL PROTECTED] [EMAIL PROTECTED]
China Beijing Soul  [±±¾©ÖÚÖ¾ºÏ´ï]
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing cache flush.

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Chris Wedgwood  <[EMAIL PROTECTED]> wrote:
>On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote:
>
>The x86 doesn't have dumb caches, therefore it really doesn't
>need to flush anything.  Maybe a mb(), but that is it.
>
>What if the memory is erased underneath the CPU being aware of this?
>In such a way ig generates to bus traffic...

Doing bank switching etc is outside the scope of the current DMA cache
flush macros - they are there only for "sane" cache coherency issues,
not to be used as generic "we have to flush the cache because we went
behind the back of the CPU and switched a bank of memory around". 

You will have to come up with some new primitive for this. 

The x86 has the "wbinval" instruction, although it should be noted that

 - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION.
   Intel set a special field in the MP table for whether wbinval is
   usable or not, and you can probably find their errata on which CPU's
   it doesn't work on (I think it was some early PPro steppings).

   When wbinval doesn't work, there's another strategy to flush the
   cache, but I forget what it was. It was something ridiculous like
   reading in a few megabytes of memory from consecutive physical
   addresses to make sure that the cache has been replaced.

 - even when it works, it is necessarily very very very slow. Not to be
   used lightly. As you can imagine, the work-around is even slower.

On the whole, I would suggest avoiding this like the plague, and just
marking such memory to be non-cacheable, regardless of whether there is
a performance impact or not. If you mark it write-combining and
speculative, it's going to perform a bit better.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reg mkdir syscall

[H. Peter Anvin]

Followup to:  
By author:"SATHISH.J" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Actually I had written a small file system(on 2.2.14 kernel) similar  to
> RAMFS on 2.4 kernel. I am able to mount it but when I try to create
> directory under it, it gives EEXIST error saying" file already exists" but
> when I check the directory again that file gets created. But the link
> count of the parent remains the same. I do not know how this directory
> gets created but with an error message. Please also tell me what all
> functions mkdir passes thro' while creating a directory. One more thing is
> when I took an strace of mkdir command the syscall mkdir fails with
> EEXIST error.
> Please help me with your thoughts.
> 

Your code is broken.

-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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: (lkml)2.4.5-ac7 usb-uhci appears twice in /proc/interrupts

[thunder7]

On Mon, Jun 04, 2001 at 03:07:56AM -0400, Pavel Roskin wrote:
> Hello!
> 
> I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed
> twice on the same IRQ 9.
> 
My Abit VP6 (VIA694) says in dmesg:

usb.c: registered new driver hub
uhci.c: USB UHCI at I/O 0xa000, IRQ 19
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: USB UHCI at I/O 0xa400, IRQ 19
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c:  Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, 
Thomas Sailer, Roman Weissgaerber
uhci.c: USB Universal Host Controller Interface driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.

And more, if I read the handbook I get an adapter to get another two usb
plugs at the backside. So yes, this motherboard has 2 usb controllers.

I think it is okay - you may want to check your own manual.

Good luck,
Jurriaan
-- 
BOFH excuse #131:

telnet: Unable to connect to remote host: Connection refused
GNU/Linux 2.4.5-ac7 SMP/ReiserFS 2x1402 bogomips load av: 0.00 0.00 0.00
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Inconsistent "#ifdef __KERNEL__" on different architectures

[Paul Mackerras]

Adrian Bunk writes:

> (my main concern wasn't whether the "#ifdef __KERNEL__" is correct or not
> but I was wondering whether there's a reason why it's different on
> different architectures)

The only valid reason for userspace programs to be including kernel
headers is to get definitions that are part of the kernel API.  (And
in fact others here will go further and assert that there are *no*
valid reasons for userspace programs to include kernel headers.)

If you want some atomic functions or whatever for your userspace
program and the ones in the kernel look like they would be useful,
then take a copy of the relevant kernel code if you like, but don't
include the kernel headers directly.  If you do, you will get bitten
at some point in the future when we decide to change some internal
implementation detail in the kernel, and your program suddenly won't
compile any more.

This is why I added #ifdef __KERNEL__ around most of the contents
of include/asm-ppc/*.h.  It was done deliberately to flush out those
programs which are depending on kernel headers when they shouldn't.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: TCP Connection lockup between 2.4.0 and 2.4.5

[David S. Miller]

Darryl Miles writes:
 > It appears the .218 end stops ACKing, even though it is obviously seeing
 > the data come in, since the TCPDUMP is from the .218 host.  I've been
 > running 2.4.0 on 10.0.0.218 since 9th Jan and can't believe that this
 > problem is a bug in 2.4.0, since it was speaking with the .219 box all
 > this time until I recently updated the .219 end from 2.0.32 to 2.4.5
 > over last weekend.

Believe it or not, it is likely a bug in 2.4.0 :-)  2.4.0 has several
major TCP failures, not fixed until 2.4.4/2.4.5.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

TCP Connection lockup between 2.4.0 and 2.4.5

[Darryl Miles]

Hi,


10.0.0.218 = Linux 2.4.0 SMP (tcp_timestamps, tcp_window_scaling and
tcp_sack all turned off, this doesn't appear to be relevant, since the
problem is just the same when they are turned on).
10.0.0.219 = Linux 2.4.5 UP

It appears the .218 end stops ACKing, even though it is obviously seeing
the data come in, since the TCPDUMP is from the .218 host.  I've been
running 2.4.0 on 10.0.0.218 since 9th Jan and can't believe that this
problem is a bug in 2.4.0, since it was speaking with the .219 box all
this time until I recently updated the .219 end from 2.0.32 to 2.4.5
over last weekend.

These are the only two linux boxes on the LAN, so this is the first time
two 2.4.x boxes have been talking to each other at LAN speeds, both
boxes have had full access to the Internet at dialup speeds all though
this year (using a non NAT connection, the 10.x.x.x addrs aren't what
they really operate as).


I did get an inconsistant tcpdump when taken from the .219 end, in that
the entries marked with '*' (which I have added a blank line around
below) are actually reported like the following (note this is from a
DIFFERENT session, NOT the same one as the larger dump below):

02:38:37.162128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1514:
10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792
 (DF)
02:38:37.172128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1514:
10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792
 (DF)
02:38:37.172128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1266:
10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792
 (DF)

Notice the difference in ethernet frame length and TCP segment length. 
>From the other end everything looks normal, as in the 1st packet is
"217:1665(1448)", 2nd packet is "1665:3113(1448)" and last is
"3113:4313(1200)". It is like tcpdump got a hold of the last packet and
repeated it 3 times, and somehow missed being able to sniff the first
two.  So what tcpdump reports from the .219 end isn't what .218 actually
sees on the wire.



This dump from the .218 end:

02:50:42.549261 10.0.0.218.2296 > 10.0.0.219.119: S
1468859836:1468859836(0) win 5840  (DF)
02:50:42.551250 10.0.0.219.119 > 10.0.0.218.2296: S
1410961156:1410961156(0) ack 1468859837 win 5840  (DF
02:50:42.551462 10.0.0.218.2296 > 10.0.0.219.119: . ack 1 win 5840 (DF)
02:50:42.741803 10.0.0.219.119 > 10.0.0.218.2296: P 1:108(107) ack 1 win
5840 (DF)
02:50:42.741925 10.0.0.218.2296 > 10.0.0.219.119: . ack 108 win 5840
(DF)
02:50:42.742347 10.0.0.218.2296 > 10.0.0.219.119: P 1:14(13) ack 108 win
5840 (DF)
02:50:42.744136 10.0.0.219.119 > 10.0.0.218.2296: . ack 14 win 5840 (DF)
02:50:42.761240 10.0.0.219.119 > 10.0.0.218.2296: P 108:117(9) ack 14
win 5840 (DF)
02:50:42.772263 10.0.0.218.2296 > 10.0.0.219.119: P 14:21(7) ack 117 win
5840 (DF)
02:50:42.77 10.0.0.219.119 > 10.0.0.218.2296: P 117:160(43) ack 21
win 5840 (DF)
02:50:42.784379 10.0.0.218.2296 > 10.0.0.219.119: P 21:40(19) ack 160
win 5840 (DF)
02:50:42.795936 10.0.0.219.119 > 10.0.0.218.2296: P 160:217(57) ack 40
win 5840 (DF)
02:50:42.799369 10.0.0.218.2296 > 10.0.0.219.119: P 40:46(6) ack 217 win
5840 (DF)
02:50:42.832749 10.0.0.219.119 > 10.0.0.218.2296: . ack 46 win 5840 (DF)

* 02:50:42.846780 10.0.0.219.119 > 10.0.0.218.2296: . 217:1677(1460) ack
46 win 5840 (DF)

02:50:42.846975 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760
(DF)

* 02:50:42.849085 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460)
ack 46 win 5840 (DF)
* 02:50:42.851092 10.0.0.219.119 > 10.0.0.218.2296: P 3137:4313(1176)
ack 46 win 5840 (DF)

02:50:42.851279 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760
(DF)
02:50:42.858301 10.0.0.219.119 > 10.0.0.218.2296: . 4313:5773(1460) ack
46 win 5840 (DF)
02:50:42.859679 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760
(DF)
02:50:42.860612 10.0.0.219.119 > 10.0.0.218.2296: . 5773:7233(1460) ack
46 win 5840 (DF)
02:50:42.867351 10.0.0.219.119 > 10.0.0.218.2296: . 7233:8693(1460) ack
46 win 5840 (DF)
02:50:42.867523 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760
(DF)
02:50:42.871097 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)
02:50:43.074807 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)
02:50:43.494738 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)
02:50:44.334641 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)
02:50:46.014434 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)
02:50:49.374022 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack
46 win 5840 (DF)


-- 
Darryl Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: gdb/ptrace problem

[Mike Coleman]

Stanislav Malyshev <[EMAIL PROTECTED]> writes:
> Since installing 2.2.19, I have the following problem: each time I try to
> attach to a running program with gdb, the result is:
> 
> ptrace: Operation not permitted.
> 
> and attaching fails. No problem with 2.2.18. Have I missed something? Any
> advice on how this can be fixed?
> 
> gdb version:
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.

I did a cursory look throught the 18->19 patch and didn't see anything obvious
that could be causing this.  Are you talking about an i386 box?  Are you
running any other special patches on it?

You could try running gdb itself under strace.  Perhaps this will show some
info on exactly how this ptrace call is failing.

The EPERM would suggest that gdb doesn't have permission to attach.  You can't
attach to setuid/setgid processes unless you're root.  Otherwise, you can
generally attach to processes you're allowed to send signals to (unless
something has changed).  So you could try running gdb as root as see if you
can attach then.  Or, you could try doing a 'kill -STOP' on the process
instead of attaching to it.  Does it work?

Also, check for operator error.  :-)

--Mike

-- 
Mike Coleman, [EMAIL PROTECTED]
  http://www.mathdogs.com -- problem solving, expert software development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unit attention in USB storage

[Andries . Brouwer]

>> [things work better when "Unit Attention: not ready to ready transition"
>> is not regarded as an error]

> I suggest trying this with 2.4.5 -- several people report that kernel
> works much better than previous ones with usb-storage.

The details of the behaviour are a bit different, but the essence
is unchanged: with the same .config as the 2.4.3 I reported on,
2.4.5 failed. (With a different one it was successful. It is a
matter of timing.) Again adding the patch:

diff -r -u ../linux-2.4.5/linux/drivers/usb/storage/debug.c 
linux/drivers/usb/storage/debug.c
--- ../linux-2.4.5/linux/drivers/usb/storage/debug.cSat Sep  9 01:39:12 2000
+++ linux/drivers/usb/storage/debug.c   Tue Jun  5 05:23:46 2001
@@ -302,6 +302,8 @@
case 0x1C00: what="defect list not found"; break;
case 0x2400: what="invalid field in CDB"; break;
case 0x2703: what="associated write protect"; break;
+   case 0x2800: what="not ready to ready transtion (media change?)";
+   break;
case 0x2903: what="bus device reset function occurred"; break;
case 0x2904: what="device internal reset"; break;
case 0x2B00: what="copy can't execute since host can't disconnect"; 
diff -r -u ../linux-2.4.5/linux/drivers/usb/storage/transport.c 
linux/drivers/usb/storage/transport.c
--- ../linux-2.4.5/linux/drivers/usb/storage/transport.cWed Apr 18 20:49:12 
2001
+++ linux/drivers/usb/storage/transport.c   Tue Jun  5 05:23:13 2001
@@ -793,6 +793,15 @@
/* If things are really okay, then let's show that */
if ((srb->sense_buffer[2] & 0xf) == 0x0)
srb->result = GOOD << 1;
+
+   /* A transition from non-ready to ready sounds OK. */
+   if ((srb->sense_buffer[2] & 0xf) == 0x6 /* unit attention */
+   && srb->sense_buffer[12] == 0x28
+   && srb->sense_buffer[13] == 0 /* not ready -> ready */) {
+   srb->result = GOOD << 1;
+   srb->sense_buffer[0] = 0;
+   }
+
} else /* if (need_auto_sense) */
srb->result = GOOD << 1;
 
makes things work.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Starfire driver updates

[Ion Badulescu]

Hi Jeff,

The patch below updates the starfire driver to support zerocopy operations
and adds full ethtool support. It also adds a small perl utility (already
present in the -ac tree) people can use to generate the firmware header
file from Adaptec's own Netware drivers.

Please apply..

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
---
--- /src/vanilla/linux-2.4-jg/drivers/net/starfire.cThu May 31 23:38:19 2001
+++ linux-2.4/drivers/net/starfire.cMon Jun  4 19:12:05 2001
@@ -2,6 +2,10 @@
 /*
Written 1998-2000 by Donald Becker.
 
+   Current maintainer is Ion Badulescu <[EMAIL PROTECTED]>. Please
+   send all bug reports to me, and not to Donald Becker, as this code
+   has been modified quite a bit from Donald's original version.
+
This software may be used and distributed according to the terms of
the GNU General Public License (GPL), incorporated herein by reference.
Drivers based on or derived from this code fall under the GPL and must
@@ -70,15 +74,20 @@
LK1.2.9a (Ion Badulescu)
- More updates from Jeff Garzik
 
+   LK1.3.0 (Ion Badulescu)
+   - Merged zerocopy support
+
+   LK1.3.1 (Ion Badulescu)
+   - Added ethtool support
+   - Added GPIO (media change) interrupt support
+
 TODO:
- implement tx_timeout() properly
-   - support ethtool
 */
 
 #define DRV_NAME   "starfire"
-#define DRV_VERSION"1.03+LK1.2.9"
-#define DRV_RELDATE"April 19, 2001"
-
+#define DRV_VERSION"1.03+LK1.3.1"
+#define DRV_RELDATE"June 04, 2001"
 
 /*
  * Adaptec's license for their Novell drivers (which is where I got the
@@ -87,7 +96,7 @@
  *
  * However, an end-user is allowed to download and use it, after
  * converting it to C header files using starfire_firmware.pl.
- * Once that's done, the #undef must be changed into a #define
+ * Once that's done, the #undef below must be changed into a #define
  * for this driver to really use the firmware. Note that Rx/Tx
  * hardware TCP checksumming is not possible without the firmware.
  *
@@ -100,6 +109,12 @@
  * of length 1. If and when this is fixed, the #define below can be removed.
  */
 #define HAS_BROKEN_FIRMWARE
+/*
+ * Define this if using the driver with the zero-copy patch
+ */
+#if defined(HAS_FIRMWARE) && defined(MAX_SKB_FRAGS)
+#define ZEROCOPY
+#endif
 
 /* The user-configurable values.
These may be modified when a driver module is loaded.*/
@@ -138,8 +153,8 @@
The media type is usually passed in 'options[]'.
 */
 #define MAX_UNITS 8/* More are supported, limit only on options */
-static int options[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
-static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1};
+static int options[MAX_UNITS] = {0, };
+static int full_duplex[MAX_UNITS] = {0, };
 
 /* Operational parameters that are set at compile time. */
 
@@ -155,9 +170,23 @@
 
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
-#define TX_TIMEOUT (2*HZ)
+#define TX_TIMEOUT (2 * HZ)
 
+#ifdef ZEROCOPY
+#if MAX_SKB_FRAGS <= 6
+#define MAX_STARFIRE_FRAGS 6
+#else  /* MAX_STARFIRE_FRAGS > 6 */
+#warning This driver will not work with more than 6 skb fragments.
+#warning Turning off zerocopy support.
+#undef ZEROCOPY
+#endif /* MAX_STARFIRE_FRAGS > 6 */
+#endif /* ZEROCOPY */
+
+#ifdef ZEROCOPY
+#define skb_first_frag_len(skb)skb_headlen(skb)
+#else  /* not ZEROCOPY */
 #define skb_first_frag_len(skb)(skb->len)
+#endif /* not ZEROCOPY */
 
 #if !defined(__OPTIMIZE__)
 #warning  You must compile this file with the correct options!
@@ -180,22 +209,25 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
+#include 
 
-/* These identify the driver base version and may not be removed. */
-static char version[] __devinitdata =
-KERN_INFO DRV_NAME ".c:v1.03 7/26/2000  Written by Donald Becker <[EMAIL PROTECTED]>\n"
-KERN_INFO " Updates and info at http://www.scyld.com/network/starfire.html\n;
-KERN_INFO " (unofficial 2.4.x kernel port, version " DRV_VERSION ", " DRV_RELDATE 
")\n";
+#ifdef SIOCETHTOOL
+#include 
+#endif
 
 #ifdef HAS_FIRMWARE
 #include "starfire_firmware.h"
 #endif /* HAS_FIRMWARE */
 
+/* These identify the driver base version and may not be removed. */
+static char version[] __devinitdata =
+KERN_INFO "starfire.c:v1.03 7/26/2000  Written by Donald Becker <[EMAIL PROTECTED]>\n"
+KERN_INFO " Updates and info at http://www.scyld.com/network/starfire.html\n;
+KERN_INFO " (unofficial 2.4.x kernel port, version " DRV_VERSION ", " DRV_RELDATE 
+")\n";
+
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Adaptec Starfire Ethernet driver");
 MODULE_PARM(max_interrupt_work, "i");
@@ -242,7 +274,7 @@
 each structure. 

Comment on patch to remove nr_async_pages limit

[Marcelo Tosatti]

Zlatko, 

I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
correctly to me...)

Quoting your message: 

"That artificial limit hurts both swap out and swap in path as it
introduces synchronization points (and/or weakens swapin readahead),
which I think are not necessary."

If we are under low memory, we cannot simply writeout a whole bunch of
swap data. Remember the writeout operations will potentially allocate
buffer_head's for the swapcache pages before doing real IO, which takes
_more memory_: OOM deadlock. 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Tulip 0.9.15-pre3 - still no dice

[Michal Jaegermann]

A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not
work for me and I have to replace it with 0.9.14d (April 3, 2001) to
get a functional network.

Trying it with 'tulip_debug=3' option I see this:


Linux Tulip driver version 0.9.15-pre3 (June 1, 2001)
00:0b.0: MWI config mwi=0, cacheline=16, csr0=00a0d000
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip0:  Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip0:  Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
tulip0:  Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11.
eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: tulip_up(), irq==11.
eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: Done tulip_open(), CSR0 f8a0d000, CSR5 f016 CSR6 b2422202.
eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb.
eth0: Autonegotiation failed, using 10baseT, link beat status 50ca.
eth0: 21143 non-MII 10baseT transceiver control 08af/0005.
eth0:  Setting CSR15 to 08af0008/00050008.
eth0: Using media type 10baseT, CSR12 is c6.
eth0:  Setting CSR6 8242/b2422002 CSR12 10c6.
eth0: 21143 negotiation status 10c6, 10baseT.
eth0: 21143 negotiation failed, status 10c6.
eth0: Testing new 21143 media 100baseTx.
eth0: The transmitter stopped.  CSR5 is f0008102, CSR6 b242, new CSR6 8386.
eth0: 21143 link status interrupt 02ca, CSR5 f0668010, fffbff7f.
eth0: 21143 100baseTx link beat failed.
eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: 21143 link status interrupt 50ca, CSR5 f0008010, fffb.
eth0: Autonegotiation failed, using 10baseT, link beat status 50ca.
.
(and a loop with at "Autonegotiation failed" until 'ifdown eth0')
.
eth0: Shutting down ethercard, status was f102.

There was a variation once. A status changed to this:

eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: 21143 link status interrupt 52ca, CSR5 f0008010, fffb.
eth0: Autonegotiation failed, using 10baseT, link beat status 52ca.

but it went back to the same loop:

This is, for a comparison, the same level of debug with 0.9.14d working 
driver.  Note different values for CSR0 and CSR5 on tulip_open().

Linux Tulip driver version 0.9.14d (April 3, 2001)
eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11.
eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
eth0:  Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
eth0:  Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block.
eth0:  Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block.
eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: tulip_up(), irq==11.
eth0: Restarting 21143 autonegotiation, csr14=0003.
eth0: Done tulip_open(), CSR0 f8a0e000, CSR5 f072 CSR6 b2422202.
eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb.
eth0: Autonegotiation failed, using 10baseT, link beat status 50ca.
eth0: 21143 non-MII 10baseT transceiver control 08af/0005.
eth0:  Setting CSR15 to 08af0008/00050008.
eth0: Using media type 10baseT, CSR12 is ca.
eth0:  Setting CSR6 8242/b2422002 CSR12 50ca.
eth0: 21143 negotiation status 50ca, 10baseT.

Here is an output of tulip-diag, as much as I can get, in a non-working
state:

tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Digital DS21143 Tulip adapter at 0x8800.
Digital DS21143 Tulip chip registers at 0x8800:
 0x00: f8a0d000   0efb 0efb0200 f000 b2420200 fbfffbff
 0x40: e000 cbf8   10ce 0001 fffb 8ff5
 Port selection is 10mpbs-serial, full-duplex.
 Transmit stopped, Receive stopped, full-duplex.
  The Rx process state is 'Stopped'.
  The Tx process state is 'Stopped'.
  The transmit threshold is 72.
  The NWay status register is 10ce.
EEPROM 64 words, 6 address bits.
PCI Subsystem IDs, vendor 1011, device 500b.
CardBus Information Structure at offset .
Ethernet MAC Station Address 00:00:F0:51:00:72.
EEPROM transceiver/media description table.
Leaf node at offset 65, default media type 0800 (Autosense).
 4 transceiver description blocks:
  Media 10baseT, block type 2, length 6.
   Serial transceiver for 10baseT (media type 0).
GP pin direction 08af  GP pin data 0005.
  Media 10baseT-Full Duplex, block type 2, length 6.
   Serial transceiver for 10baseT-Full Duplex (media type 4).
GP pin direction 08af  GP pin data 0005.
  Media 100baseTx, block type 4, length 8.
   SYM transceiver for 100baseTx (media type 3).
GP pin direction 08af  GP pin data 0005.
No media detection indication (command 80 61).
  Media 

Re: symlink_prefix

[Ton Hospel]

In article <[EMAIL PROTECTED]>,
Hank Leininger <[EMAIL PROTECTED]> writes:
> On 2001-06-03, [EMAIL PROTECTED] wrote:
> 
>> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
>> /, /usr and /usr/spool filesystems for FOO OS. Now
>> mount /dev/a /mnt -o symlink_prefix=/mnt
>> mount /dev/b /mnt/usr -o symlink_prefix=/mnt
>> mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt
> 
> Cool.
> 
> What happens when someone creates new absolute symlinks under /mnt ?
> Will/should the magic /mnt/ header be stripped from any symlink created
> under such a path-translated volume?  The answer is probably 'yes', but
> either one violates POLA :(
> 
I think the semantics should be these that are used in the old usespace
nfsd for the "link_relative" option. That one had very intuitive semantics
and behaved sanely even if you had insane recursive machine crossmounts
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lowlatency 2.2.19

[William Montgomery]

On Mon, 4 Jun 2001, safemode wrote:

> this is just a general question about low latency patches on 2.2,   I 
> remember hearing about low latency patches for 2.4 not playing well with X 
> 4.x, is this true for 2.2 low latency patches as well?   
> 
Not sure.  My testing uses XFree86 3.3.6.

Wm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

forcibly unmap pages in driver?

[Dan Maas]

I am writing a device driver that, like many others, exposes a shared memory
region to user-space via mmap(). The region is allocated with vmalloc(), the
pages are marked reserved, and the user-space mapping is implemented with
remap_page_range().

In my driver, I may have to free the underlying vmalloc() region while the
user-space program is still running. I need to remove the user-space
mapping -- otherwise the user process would still have access to the
now-freed pages. I need an inverse of remap_page_range().

Is zap_page_range() the function I am looking for? Unfortunately it's not
exported to modules =(. As a quick fix, I was thinking I could just remap
all of the user pages to point to a zeroed page or something...

Another question- in the mm.c sources, I see that many of the memory-mapping
functions are surrounded by calls to flush_cache_range() and
flush_tlb_range(). But I don't see these calls in many drivers. Is it
necessary to make them when my driver maps or unmaps the shared memory
region?

Regards,
Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops while unmounting a reiserfs partition

[Hans Reiser]

get patch from www.namesys.com, bug was added and fixed by viro, we just put the
patch up while waiting for 2.4.6 to come out.

Hans

Mathieu Chouquet-Stringer wrote:
> 
> Hello!
> 
> I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know
> this is just a testing machine), mounted it, and then unmounted it, and
> OOPS! My kernel version is plain 2.4.5...
> If you need more information, let me know.
> 
> Jun  4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) 
>...
> Jun  4 17:25:07 nynetops03 kernel: Using r5 hash to sort names
> Jun  4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25
> Jun  4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held
> Jun  4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423!
> Jun  4 17:26:11 nynetops03 kernel: invalid operand: 
> Jun  4 17:26:11 nynetops03 kernel: CPU:1
> Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64]
> Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[]
> Jun  4 17:26:11 nynetops03 kernel: EFLAGS: 00010282
> Jun  4 17:26:11 nynetops03 kernel: eax: 001d   ebx: d8e15f24   ecx: 0001   
>edx: 0001
> Jun  4 17:26:11 nynetops03 kernel: esi: df9c5400   edi:    ebp: 3b1bfcf3   
>esp: d8e15eac
> Jun  4 17:26:11 nynetops03 kernel: ds: 0018   es: 0018   ss: 0018
> Jun  4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000)
> Jun  4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf 
>c0268a61  d7e75250 00e8
> Jun  4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60  
>0018 d8e15f24 df9c5400 c02a8620
> Jun  4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 
>000a  c017ffdc d8e15f24
> Jun  4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] 
>[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] 
>[kill_super+162/288] [path_release+41/48]
> Jun  4 17:26:11 nynetops03 kernel: Call Trace: [] [] 
>[] [] [] [] []
> Jun  4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] 
>[sys_oldumount+12/16] [system_call+51/56]
> Jun  4 17:26:11 nynetops03 kernel:[] [] [] 
>[]
> Jun  4 17:26:11 nynetops03 kernel:
> Jun  4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 
>00 00 00 8d bc 27
> 
> And the decoded output:
> ksymoops 2.4.0 on i686 2.4.5.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.5/ (default)
>  -m /boot/System.map-2.4.5 (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.
> 
> Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
>found in System.map.  Ignoring ksyms_base entry
> Warning (compare_maps): ksyms_base symbol 
>machine_real_restart_R__ver_machine_real_restart not found in System.map.  Ignoring 
>ksyms_base entry
> Jun  4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423!
> Jun  4 17:26:11 nynetops03 kernel: invalid operand: 
> Jun  4 17:26:11 nynetops03 kernel: CPU:1
> Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64]
> Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[]
> Using defaults from ksymoops -t elf32-i386 -a i386
> Jun  4 17:26:11 nynetops03 kernel: EFLAGS: 00010282
> Jun  4 17:26:11 nynetops03 kernel: eax: 001d   ebx: d8e15f24   ecx: 0001   
>edx: 0001
> Jun  4 17:26:11 nynetops03 kernel: esi: df9c5400   edi:    ebp: 3b1bfcf3   
>esp: d8e15eac
> Jun  4 17:26:11 nynetops03 kernel: ds: 0018   es: 0018   ss: 0018
> Jun  4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000)
> Jun  4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf 
>c0268a61  d7e75250 00e8
> Jun  4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60  
>0018 d8e15f24 df9c5400 c02a8620
> Jun  4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 
>000a  c017ffdc d8e15f24
> Jun  4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] 
>[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] 
>[kill_super+162/288] [path_release+41/48]
> Jun  4 17:26:11 nynetops03 kernel: Call Trace: [] [] 
>[] [] [] [] []
> Jun  4 17:26:11 nynetops03 kernel:[] [] [] 
>[]
> Jun  4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 
>00 00 00 8d bc 27
> 
> >>EIP; c018bb98<=
> Trace; c018e2cf 
> 

Re: Missing cache flush.

[David S. Miller]

David Woodhouse writes:
 > > What should it do on i386?  mb()? 
 > 
 > For it to have any use in the situation I described, it would need to 
 > writeback and invalidate the dcache for the affected range. It doesn't seem 
 > to do so, so it seems that it isn't what I require.

It only needs to do that on cpus where the cache is not consistent
with the rest of the system.  x86 caches are fully consistent with the
rest of the system, thus no flushing necessary.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing cache flush.

[David S. Miller]

Jeff Garzik writes:
 > David Woodhouse wrote:
 > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very
 > > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on
 > > i386 shows that it doesn't do what's required anyway.
 > 
 > What should it do on i386?  mb()?

The x86 doesn't have dumb caches, therefore it really doesn't need to
flush anything.  Maybe a mb(), but that is it.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel oops when burning CDs

[Tachino Nobuhiro]

Hello,

At Mon, 4 Jun 2001 22:43:30 +0100 (BST),
Alan Cox wrote:
> 
> > I get an ooops and immediate kernel panic when I break (CTRL-C) cdrecord. I 
> > can reproduce it anytime. I use 2.4.5-ac series. Obviously, Linus' 2.4.5 is 
> > fine.
> > I know, I know. I was supposed to make a serios oops report, BUT I wasn't 
> 
> Write down the EIP and the call trace then look them up in System.map. Also
> include the hardware details. The -ac tree has a newer version of the scsi
> generic code. It fixes some oopses but in your case it apparently added a new
> failure case

  Oops occures in SG driver. This patch fixes the problem.



diff -r -u linux.org/drivers/scsi/sg.c linux/drivers/scsi/sg.c
--- linux.org/drivers/scsi/sg.c Fri Jun  1 10:10:22 2001
+++ linux/drivers/scsi/sg.c Fri Jun  1 17:08:00 2001
@@ -1114,7 +1114,8 @@
 sg_remove_sfp(sdp, sfp);
sfp = NULL;
 }
-   __MOD_DEC_USE_COUNT(sg_template.module);
+   if (sg_template.module)
+   __MOD_DEC_USE_COUNT(sg_template.module);
if (sdp->device->host->hostt->module)
__MOD_DEC_USE_COUNT(sdp->device->host->hostt->module);
 }
@@ -1311,7 +1312,8 @@
sg_finish_rem_req(srp);
}
if (sfp->closed) {
-   __MOD_DEC_USE_COUNT(sg_template.module);
+   if (sg_template.module)
+   __MOD_DEC_USE_COUNT(sg_template.module);
if (sdp->device->host->hostt->module)
__MOD_DEC_USE_COUNT(sdp->device->host->hostt->module);
__sg_remove_sfp(sdp, sfp);
@@ -2207,7 +2209,8 @@
 else {
 sfp->closed = 1; /* flag dirty state on this fd */
/* MOD_INC's to inhibit unloading sg and associated adapter driver */
-   __MOD_INC_USE_COUNT(sg_template.module);
+   if (sg_template.module)
+   __MOD_INC_USE_COUNT(sg_template.module);
 if (sdp->device->host->hostt->module)
__MOD_INC_USE_COUNT(sdp->device->host->hostt->module);
 SCSI_LOG_TIMEOUT(1, printk(


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lowlatency 2.2.19

[Andrew Morton]

safemode wrote:
> 
> this is just a general question about low latency patches on 2.2,   I
> remember hearing about low latency patches for 2.4 not playing well with X
> 4.x, is this true for 2.2 low latency patches as well?

Yes, it would be the case.

Some video cards have a PCI cheat-mode in which they keep
the PCI bus busy until they are ready to accept new
commands, rather forcing a retry.  Figures of up to
twenty milliseconds have been mentioned.  Your X server
*may* support the `PCIRetry' config option which will
defeat this.

Info:

http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1566.html
http://www.zefiro.com/vgakills.txt
http://www.zdnet.com/pcmag/news/trends/t980619a.htm
http://www.research.microsoft.com/~mbj/papers/tr-98-29.html

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lowlatency 2.2.19

[safemode]

this is just a general question about low latency patches on 2.2,   I 
remember hearing about low latency patches for 2.4 not playing well with X 
4.x, is this true for 2.2 low latency patches as well?   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

TRG vger.timpanogas.org hacked

[Jeff V. Merkey]

Our master server (vger.timpanogas.org) running 2.2.19 was hacked and 
completely obliterated by someone using a Novell Proxy Cache via a kernel
level exploit in [sys_wait+4].  They somehow created a segmentation fault 
down inside the kernel, then gained access to the /lib directory and 
relinked the libraries to a set of bogus libs, which gave them 
access to the server.  Only public code and email is processed on 
this server.  

For those interested in reviewing this attack, I have the entire previous
hard disk available and can mount it under the public ftp area if anyone 
is curious as to how these folks did this.  They exploited BIND 8.2.3
to get in and logs indicated that someone was using a "back door" in 
Novell's NetWare proxy caches to perform the attack (since several 
different servers were used as "blinds" to get in).  

We are unable to determine just how they got in exactly, but they 
kept trying and created an oops in the affected code which allowed 
the attack to proceed.  

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

re: disk-based fds in select/poll

[Dan Kegel]

Pierre Phaneuf <[EMAIL PROTECTED]> wrote:
> It's fairly widely-known that select/poll returns immediately when
> testing a filesystem-based file descriptor for writability or
> readability.
> 
> On top of this, even when in non-blocking mode, read() could block if
> the pages needed aren't in core. sendfile() behaves in a similar way.
> 
> What would be needed to alleviate this?
> ...
> I remember seeing a suggestion by Linus for an event-based I/O
> interface, similar to kqueue on FreeBSD but much simpler. I'd just say
> "I want it too!", ok? :-)
>
> SGI's AIO might be a solution here, does it use threads? I'm trying to
> avoid context switching as much as possible, to keep the CPU cache as
> warm as possible.

IMHO, you want AIO.  SGI's is fine for now.  I hear rumors that there will be
something even better coming in 2.5, though I have no details.

Or you could use explicit userspace threads... say, divide up your
network connections among 8 or so threads.  Then if one thread blocks,
the others are there to usefully soak up the CPU time.

Readiness events for readahead completion on disk files used to 
seem like a neat idea to me, but now AIO seems more appealing
in the long run, since they handle random access properly.

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reschedule_idle changes in ac kernels

[Nigel Gamble]

On Mon, 4 Jun 2001, Mike Kravetz wrote:
> I just noticed the changes to reschedule_idle() in the 2.4.5-ac
> kernel.  I suspect these are the changes made for:
> 
> o   Fix off by one on real time pre-emption in scheduler
> 
> I'm curious if anyone has ran any benchmarks before and after
> applying this fix.

I was running realtime benchmarks, which was how I found the bug.

> The reason I ask is that during the development of my multi-queue
> scheduler, I 'accidently' changed reschedule_idle code to trigger
> a preemption if preemption_goodness() was greater than 0, as
> opposed to greater than 1.  I believe this is the same change made
> to the ac kernel.  After this change, we saw a noticeable drop in
> performance for some benchmarks.
> 
> The drop in performance I saw could have been the result of a
> combination of the change, and my multi-queue scheduler.  However,
> in any case aren't we now going to trigger more preemptions?
> 
> I understand that we need to make the fig to get the realtime
> semantics correct,  but we also need to be aware of performance in
> the non-realtime case.

The realtime bug was caused by whoever decided, sometime in 2.4, that
the result of preemption_goodness() should be compared to 1 instead of 0
(without changing the comment above that function).

An alternative fix for the realtime bug would be 

weight = 1000 + (p->rt_priority * 2);

in goodness(), so that two realtime tasks with priorities that differ by
1 would have goodness values that differ by more than one.

However, before anyone rushes to implement this, I'd like to suggest
that any performance problems that may be found with the SCHED_OTHER
goodness calculation should be fixed in goodness(), if at all possible,
and not leak out as an undocumented magic number into reschedule_idle().

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Oh Bother

[David Flynn]

Morning Guys, (or whatever time you call this ungodly hour)
A couple of things to bring up:

1) I was just rebuilding gcc (for an i586 on my faster PII) everything was
going fine and suddenly silence, all my ssh sessions have locked up, the
serial console is dead, the system is not responding to ping's on any of its
interfaces and when connecting a monitor / keyboard up, they are dead too
 the monitor is in "blank mode" (HaHa -- the most irritating thing i
find with linux) mode.  My conclusion: the system has completely died / hung
with no warning of anykind (any panic issued would not be noticed as the
damn monitor has been put in blank mode by the system).

Anyone got any suggestions (more so with point 2) ?

2) How do you stop the stupid system blanking / power saving the monitor
 sure, it can be done with a setterm command, but, i dont use the
monitor for a terminal, the box is remote access only... its only for
looking at error messages that apear at the console

3) upon looking at the log files, where nothing about todays incident is
mentioned, but i did notice some from a previous day :

Jun  2 21:38:52 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window
1109891031:1:1109891568. Bad, what else can I say?
Jun  2 21:38:53 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window
1109891032:1:1109891568. Bad, what else can I say?
Jun  2 21:38:58 kernel: NET: 1 messages suppressed.
Jun  2 21:38:58 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window
1109891034:1:1109891568. Bad, what else can I say?
Jun  2 21:39:03 kernel: TCP: peer 216.41.36.109:80/2880 shrinks window
1068438541:1:1068439073. Bad, what else can I say?
Jun  2 21:39:13 kernel: NET: 2 messages suppressed.
Jun  2 21:39:13 kernel: TCP: peer 216.41.36.109:80/2876 shrinks window
1066801908:1:1066802376. Bad, what else can I say?
Jun  2 21:39:17 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window
1109891036:1:1109891568. Bad, what else can I say?
Jun  2 21:39:44 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window
1109891037:1:1109891568. Bad, what else can I say?
Jun  2 21:40:58 kernel: TCP: peer 216.41.36.109:80/2906 shrinks window
125703:1:1257011569. Bad, what else can I say?
Jun  2 21:40:58 kernel: TCP: peer 216.41.36.109:80/2907 shrinks window
1250316486:1:1250316939. Bad, what else can I say?

what on earth is all that about ?

the systems running 2.4.5 on a PII


Anyway, i had better get back to sorting out this box, it seems the crash
has done some nast stuff to the file system ... it seems that part of gcc is
now crosslinked with a hell of alot of other files, i can only hope that all
the devel and research work on that box is unharmed!

Thanks,

Dave

---
The information in this e-mail and any files sent with it is confidential to
the ordinary user of the e-mail address to which it was addressed and may
also be legally privileged. It is not to be relied upon by any person other
than the addressee except with the sender's prior written approval. If no
such approval is given, the sender will not accept liability (in negligence
or otherwise) arising from any third party acting, or refraining from
acting, on such information. If you are not the intended recipient of this
e-mail you may not copy, forward, disclose or otherwise use it or any part
of it in any form whatsoever. If you have received this e-mail in error
please notify the sender immediately, destroy any copies and delete it from
your computer system. Have a nice Day !
-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.2 <-> 2.4.5-ac5 tcp too slow

[Tom Vier]

i tracked it down to the 8139 driver in 2.4.

On Mon, Jun 04, 2001 at 06:28:34PM -0400, Tom Vier wrote:
> has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow
> and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed.

-- 
Tom Vier <[EMAIL PROTECTED]>
DSA Key id 0x27371A2C
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing cache flush.

[David Woodhouse]

[EMAIL PROTECTED] said:
> > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem
> > very helpful - it's very PCI-specific, and a quick perusal of
> > pci_dma_sync() on i386 shows that it doesn't do what's required anyway.

> What should it do on i386?  mb()? 

For it to have any use in the situation I described, it would need to 
writeback and invalidate the dcache for the affected range. It doesn't seem 
to do so, so it seems that it isn't what I require.

The situation is simple - I have a paged RAM setup and I need it cached. 
All I want to do is flush and invalidate the cache when I'm about to waggle 
whatever I/O ports I waggle to change pages. 

There are other situations in which I need the cache flushed, but the above 
is one of the simplest.

Even flush_page_to_ram() doesn't seem to do what its name implies, on most 
architectures.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Missing cache flush.

[Jeff Garzik]

David Woodhouse wrote:
> I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very
> helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on
> i386 shows that it doesn't do what's required anyway.

What should it do on i386?  mb()?

-- 
Jeff Garzik  | Echelon words of the day, from The Register:
Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 
MandrakeSoft | Steak Knife Kill the President anarchy echelon
 | nuclear assassinate Roswell Waco World Trade Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: disk-based fds in select/poll

[Alan Cox]

> Ok, so while knowing about select "lying" about readability of a file
> fd, if I would stick a file fd in my select-based loop anyway, but would

You could fix select to return when the page was cachied and return EWOULDBLOCK
on reads if the page was not present to be honest. I don't think that would
actually break any apps, and the specs seem to allow it

> only try to read a bit at a time (say, 4K or 8K) would trigger
> readahead, yet finish quickly enough that I can get back to processing
> other fds in my select loop?

Probably

> Wouldn't that cause too many syscalls to be done? Or if this is actually
> the way to go without an actual thread, how should I go determining an
> optimal block size?

fs block size I suspect or small multiple thereof

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Missing cache flush.

[David Woodhouse]

The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached
mapping of the flash chips for bulk reads, but obviously an uncached mapping
for sending commands and reading status when we're actually writing to or
erasing parts of the chip.

However, it fails to flush the dcache for the range used when the flash is 
accessed through the uncached mapping. So after an erase or write, we may 
read old data from the cache for the changed area.

All the mapping driver needs to do is invalidate the dcache for the affected
area before the next copy_from() operation. No need to worry about writeback
in this case, because we never write to flash chips through the cached
mapping.

However, I can't see a cache operation which performs this function.
flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most
architectures. On other architectures, there's dma_cache_wback_inv(), but
that also seems to be a NOP on i386, to pick a random example.

I'm aware that some architectures can't handle having both cached and
uncached mappings of the same physical range - so to prevent dismissal of
the question out of hand by people assuming all the world's a PeeCee -
consider the alternative situation where we have ROM or RAM chips in a paged
mapping such that only a 64K 'page' is visible by the CPU at a time
(remember XMS?). Using an uncached mapping is extremely suboptimal - all we
want to do is invalidate the cache when we change the page, or writeback 
and invalidate in the case of RAM.

I would have thought that's the function that dma_cache_wback_inv() is
supposed to perform - but it seems not to do so.

So how is this _supposed_ to be done?

I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very
helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on
i386 shows that it doesn't do what's required anyway.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

reschedule_idle changes in ac kernels

[Mike Kravetz]

I just noticed the changes to reschedule_idle() in the 2.4.5-ac
kernel.  I suspect these are the changes made for:

o   Fix off by one on real time pre-emption in scheduler

I'm curious if anyone has ran any benchmarks before and after
applying this fix.

The reason I ask is that during the development of my multi-queue
scheduler, I 'accidently' changed reschedule_idle code to trigger
a preemption if preemption_goodness() was greater than 0, as
opposed to greater than 1.  I believe this is the same change made
to the ac kernel.  After this change, we saw a noticeable drop in
performance for some benchmarks.

The drop in performance I saw could have been the result of a
combination of the change, and my multi-queue scheduler.  However,
in any case aren't we now going to trigger more preemptions?

I understand that we need to make the fig to get the realtime
semantics correct,  but we also need to be aware of performance in
the non-realtime case.

-- 
Mike Kravetz [EMAIL PROTECTED]
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: disk-based fds in select/poll

[Pierre Phaneuf]

Alan Cox wrote:

> > I am thinking that a read() (or sendfile()) that would block because the
> > pages aren't in core should instead post a request for the pages to be
> > loaded (some kind of readahead mecanism?) and return immediately (maybe
> > having given some data that *was* in core). A subsequent read() could
> 
> reads posts a readahead anyway so streaming reads tend not to block much

Ok, so while knowing about select "lying" about readability of a file
fd, if I would stick a file fd in my select-based loop anyway, but would
only try to read a bit at a time (say, 4K or 8K) would trigger
readahead, yet finish quickly enough that I can get back to processing
other fds in my select loop?

Wouldn't that cause too many syscalls to be done? Or if this is actually
the way to go without an actual thread, how should I go determining an
optimal block size?

Was there anything new on the bind_event/get_events API idea that Linus
proposed a while ago? That one had got me foaming at the mouth... :-)

-- 
Pierre Phaneuf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

vmstat help

[Radhakrishnan Manga]

Hi,
  I am using the vmstat that came along with the SuSE 7.0 distribution.
I have problem interpretting the data reported by vmstat. The vmstat
document reads that the block information reported is always in terms of
1K blocks. Just to findout the validity of  the data reported by vmstat,
I carried out the a small copy test.  Here is the configuration I have

1) I have two file systems which are created with 4096 block size
2) These two file systems are on two different disks. (but both are
sitting on same scsi controller)
3) I am trying to copy a 4GB file from one disk to another using the
simple "cp" command.
4) I am capturing vmstat with 30 sec interval. I stop the vmstat after
cp is done
5) The copy takes anywhere between 7 to 10 minutes.

On vmstat report has bi and bo's ranging form 700 to 4000.

Just to get the total blocks read, I multiple the value reported in bi
column with 30 (as 30 sec was my sampling interval) and sum them all. To
my surprise, they add up only to around (1 GB).

  What is wrong here, the documentation or my intepretation of vmstat
output.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.2 <-> 2.4.5-ac5 tcp too slow

[Tom Vier]

i seem to remember this being mentioned before, but couldn't find any
reference in the list archives. i have an x86 laptop running 2.2.17 (2.2.19
has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow
and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed.
it doesn't matter which side starts the connection. has anyone else
experienced this? any suggestions?

-- 
Tom Vier <[EMAIL PROTECTED]>
DSA Key id 0x27371A2C
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Question on Partial Checksum in TCP/IP

[Bharath Madhavan]

Hello all,
I am trying to understand a little bit about the TCP path in the
Linux kernel.
I saw that while we were even copying the user data into kernel space, we
were doing
the partial checksum of the data portion alone (as the TCP header is not yet
filled up) and storing 
it in skb->csum. 
Later on when we fill the header portion, we do the checksum of the header
and "add" it to the
already calculated checksum of the data. Here we check if the HW performs
the checksum 
or not (skb->ip_summed == CHECKSUM_HW). I am looking into kernel ver 2.4
My question is, why is this check not performed when the data is copied
initially. Instead of
calling csum_and_copy_from_user, if we did a memcpy in the case when HW does
the checksum,
would'nt that be more efficient? Or have I overlooked something...

Thanks a lot

PS. Please CC responses to me also as I am not subscribed to the mailing
list. Thanks

Bharath


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO-APIC, beaten with stick, routes USB

[Rico Tudor]

> Any chance you can try Alan Cox's patch against 2.4.5?  It has a number
> of IO-APIC fixes.
> 

patch-2.4.5-ac7.bz2 behaves the same as 2.4.4.  Whatever is happening in
IO-APIC setup, USB interrupts actually arrive on IRQ 12.  I can include
the usual pile of config info and boot messages, but they look the same
as previous l-k postings.

Since IRQ 12 is a popular destination for USB, the following patch may
work for people with this problem:

--- usb-ohci.c  Sun May  6 08:42:51 2001
+++ usb-ohci.c.rico Mon Jun  4 20:49:56 2001
@@ -2524,3 +2524,3 @@
 
-   return hc_found_ohci (dev, dev->irq, mem_base, id);
+   return hc_found_ohci (dev, 12, mem_base, id);
 } 

If 12 fails, they can look for the stray interrupt in /proc/stat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Albert D. Cahalan]

Alexander Viro writes:

> leaves ncp with its ioctls ugliness.

Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole box as trusted.

The /fs/ext2 stuff is one of the nastiest hacks I've seen in
a long time, and it doesn't solve the authentication problem.

GUI users might like to see a dialog box pop up whenever they
hit restricted filesystem space. (example: an authentication tool
blocked on /dev/auth-notify or getting signals with info)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.5-ac8

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

 Intermediate diffs are available from
http://www.bzimage.org

In terms of going through the code audit almost all the sound drivers still 
need fixing to lock against format changes during a read/write. Poll creating 
and starting a buffer as write does and also mmap during write, write during
an mmap.

2.4.5-ac8
o   Fix sign handling bug in random sysctl  (me)
| From Stanford tools
o   Add more idents to the NS558 driver (Vojtech Pavlik)
o   Fix oops on some HID descriptor sets(Vojtech Pavlik)
o   Fix reuse bug in UML net code + clean up(Jeff Dike)
o   ES1370 driver locking   (Frank Davis)
o   Update init/main.c patch for umask  (Andrew Tridgell)
o   Fix uml fault race, and looping fault on(Jeff Dike)
protection error
o   Update devices.txt  (H Peter Anvin)
o   Update the airo driver (fix pci pm oops.(Jeff Garzik)
spinlock abuse, delete after kfree, unchecked
copies)
o   Remove old UML umn driver   (Jeff Dike)
o   Fix resource leaks and printk levels in isapnp  (Mike Borrelli)
o   Add new procfs programming documentation(Erik Mouw)
o   Fix usb xconfig breakage(Andrzej Krzysztofowicz)
o   Replace accidentaly lost UP_APIC help   (Mikael Pettersson)
o   Olypmic driver update   (Mike Phillips)
o   Clean up LVM spelling, debug macros (Andreas Dilger)
o   Make various bits of LVM static (Andreas Dilger)
o   Make lvm_snapshot_use_rate its own function (Andreas Dilger)
o   Make lvm_do_lv_create loop the right amount
o   Fix lvm stamping on a semaphore causing an oops
o   Fix lvm hardware block size handling(Andrea Arcangeli)

2.4.5-ac7
o   UML cleanups(Jeff Dike)
o   Trap invalid addresses in UML ethernet driver   (Jeff Dike)
o   Reimplment UML user space access(Jeff Dike)
o   Add device node support to hostfs   (Jorgen Cederlof)
o   Fix hang if the UML net helper fails to run (Jeff Dike)
o   Support setting time in UML kernels (Livio Baldini Soares)
o   Move more non portable code out of UML core (Jeff Dike)
o   Merge most of remaining UML ppc changes (Chris Emerson)
o   Printk cleanups, remove one non portable(James Stevenson)
o   Add speaker mixer support to the cmpci mixer(Carlos Gorges)
o   Fix inittdata ordering in i2c docs   (Andrzej Krzysztofowicz)
o   Add usb skeleton driver (Greg Kroah-Hartmann)
o   Fix ns558 unload(Marcus Meissner)
o   Further cs46xx fixing   (Frank Davies)
o   S/390 updates from the IBM folks(Martin Schwidefsky)
o   CS46xx pop/crackle fixes on IBM T20 (Thomas Woller)
o   Make USB require PCI(me)
o   Tulip driver update (Jeff Garzik)
o   Fix slip/slhc missing symbols problem   (Michael Guntsche)
o   IRDA updates(Dag Brattli)
o   Add cs4232 isapnp probing   (Marcus Meissner)
o   Merge airo_cs driver(Benjamin Reed, Javier Achirica,
Jean Tourrilhes)
o   VIA workarounds for APIC IRQ routing(Jeff Garzik)
o   Fix bootmem.c comment cut accident(Richard Urena)
o   Update LVM with new VG_CREATE ioctl (and(Joe Thornber)
VG_CREATE_OLD for back compatibility)
o   Fix pv_t/lv_t confusion in lv_status_bydev_req  (Joe Thornber)
o   Lots of update/fixes for _lv_status_by* code(Joe Thornber)
o   Add support for I2O IOP's requiring private (me)
resource spaces
o   Hopefully fix hid jerkiness (Michael)

2.4.5-ac6
o   Fix the cs46xx right this time  (me)
o   Further FATfs cleanup   (OGAWA Hirofumi)
o   ISDN PPP code cleanup, cvs tag update   (Kai Germaschewski)
o   Large amount of UFS file system cleanup (Al Viro)
o   Fix endianness problems in FATfs(Petr Vandrovec)
o   Fix -ac quota crashes   (Jan Kara)
o   Fix bluetooth out of memory handling(Greg Kroah-Hartmann)
o   Fix freevxfs readdir(Christoph Hellwig)
o   Fix freevxfs sign/unsigned issues   (Christoph Hellwig)
o   Fix doctypos, other freevxfs cleanup(Christoph Hellwig)
o   Fix flush_dirty_buffers warning  

Re: I/O tracing

[richardj_moore]

You can use either dprobes to set up a tracepoint dynamically anywhere you
please see:
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes

Or, you can use gkhi to define a hook anywhere in the kernel you please.
You can write a hook exit as a kmod to do whatever you fancy and have it
activate at a tome of your choosing. See,
http://oss.software.ibm.com/developerworks/opensource/linux/projects/gkhi

Or, you can investigate some of the standard tracepoint Linux Trace Toolkit
creates, see: http://www.opersys.com/

And that's only three of many


Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


"YU,SAMMY (HP-Roseville,ex1)" <[EMAIL PROTECTED]> on 04/06/2001 19:37:23

Please respond to "YU,SAMMY (HP-Roseville,ex1)" <[EMAIL PROTECTED]>

To:   [EMAIL PROTECTED]
cc:
Subject:  I/O tracing




Hi,
 Please CC me as I'm not subscribed on the list, thanks.  Not sure if
this is appropriate forum, is there an existing tool/module for capturing
all the I/O requests such as:

Unique Identifier
Start Time
End Time
Device Identifier
Operation Type (Read Or Write)
Offset
Length (Number Of Bytes)

I am aware of existing /proc/disks and partitions, but these aren't real
time.  If not, are there any facilities in the kernel I can put a hook in
to
keep track of the I/O?


Thanks in advance,
Sammy Yu
Hewlett-Packard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: disk-based fds in select/poll

[Alan Cox]

> I am thinking that a read() (or sendfile()) that would block because the
> pages aren't in core should instead post a request for the pages to be
> loaded (some kind of readahead mecanism?) and return immediately (maybe
> having given some data that *was* in core). A subsequent read() could

reads posts a readahead anyway so streaming reads tend not to block much

> SGI's AIO might be a solution here, does it use threads? I'm trying to
> avoid context switching as much as possible, to keep the CPU cache as
> warm as possible.

glibc 2.2 does thread based aio_ and it will tend to avoid cache damage as
the thread share the mm but on SMP its quite possible the read wil occur on
the other CPU. Of course kernel based I/O might do the same too..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Oops while unmounting a reiserfs partition

[Mathieu Chouquet-Stringer]

Hello!

I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know
this is just a testing machine), mounted it, and then unmounted it, and
OOPS! My kernel version is plain 2.4.5...
If you need more information, let me know.

Jun  4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) 
...
Jun  4 17:25:07 nynetops03 kernel: Using r5 hash to sort names
Jun  4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25
Jun  4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held
Jun  4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423!
Jun  4 17:26:11 nynetops03 kernel: invalid operand: 
Jun  4 17:26:11 nynetops03 kernel: CPU:1
Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64]
Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[]
Jun  4 17:26:11 nynetops03 kernel: EFLAGS: 00010282
Jun  4 17:26:11 nynetops03 kernel: eax: 001d   ebx: d8e15f24   ecx: 0001   
edx: 0001
Jun  4 17:26:11 nynetops03 kernel: esi: df9c5400   edi:    ebp: 3b1bfcf3   
esp: d8e15eac
Jun  4 17:26:11 nynetops03 kernel: ds: 0018   es: 0018   ss: 0018
Jun  4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000)
Jun  4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 
 d7e75250 00e8 
Jun  4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60  0018 
d8e15f24 df9c5400 c02a8620 
Jun  4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a 
 c017ffdc d8e15f24 
Jun  4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] 
[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] 
[kill_super+162/288] [path_release+41/48] 
Jun  4 17:26:11 nynetops03 kernel: Call Trace: [] [] [] 
[] [] [] [] 
Jun  4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] 
[sys_oldumount+12/16] [system_call+51/56] 
Jun  4 17:26:11 nynetops03 kernel:[] [] [] 
[] 
Jun  4 17:26:11 nynetops03 kernel: 
Jun  4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 00 
00 00 8d bc 27 

And the decoded output:
ksymoops 2.4.0 on i686 2.4.5.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5/ (default)
 -m /boot/System.map-2.4.5 (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.

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
machine_real_restart_R__ver_machine_real_restart not found in System.map.  Ignoring 
ksyms_base entry
Jun  4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423!
Jun  4 17:26:11 nynetops03 kernel: invalid operand: 
Jun  4 17:26:11 nynetops03 kernel: CPU:1
Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64]
Jun  4 17:26:11 nynetops03 kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Jun  4 17:26:11 nynetops03 kernel: EFLAGS: 00010282
Jun  4 17:26:11 nynetops03 kernel: eax: 001d   ebx: d8e15f24   ecx: 0001   
edx: 0001
Jun  4 17:26:11 nynetops03 kernel: esi: df9c5400   edi:    ebp: 3b1bfcf3   
esp: d8e15eac
Jun  4 17:26:11 nynetops03 kernel: ds: 0018   es: 0018   ss: 0018
Jun  4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000)
Jun  4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 
 d7e75250 00e8 
Jun  4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60  0018 
d8e15f24 df9c5400 c02a8620 
Jun  4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a 
 c017ffdc d8e15f24 
Jun  4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] 
[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] 
[kill_super+162/288] [path_release+41/48] 
Jun  4 17:26:11 nynetops03 kernel: Call Trace: [] [] [] 
[] [] [] [] 
Jun  4 17:26:11 nynetops03 kernel:[] [] [] 
[] 
Jun  4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 00 
00 00 8d bc 27 

>>EIP; c018bb98<=
Trace; c018e2cf 
Trace; c018e516 
Trace; c017ffdc 
Trace; c014bf3f 
Trace; c0137494 
Trace; c013bd72 
Trace; c0140e79 
Trace; c013c22d 
Trace; c0126ec3 
Trace; c013c26c 
Trace; c0106e0b 
Code;  c018bb98 
 <_EIP>:
Code;  c018bb98<=
   0:   0f 0b ud2a  <=
Code;  c018bb9a 
   2:   83 c4 0c   

Re: ide retry on 2.4.5-ac7

[PROFETA Mickael]

On Mon, Jun 04, 2001 at 11:09:33PM +0200, Jens Axboe wrote:
> 
> This is not the case that is attempted solve. The above could be a cable
> error (it looks like it). These are usually genuine and indicate a real
> hw problem.

I know about that, but I tried with other cable and the trouble leaves the
same. On the other hand, before kernel 2.4.2 I think, (not sure of the number)
the kernel does not want to activate UDMA on startup even with the option
activated, and this on via mb. At that time, I used to force the DMA with
hdparm, and I had no troubles in dma mode 3 with that hard disk, and I can
remeber that udma mode 4 was even not indicate when I try hdparm -I /dev/hdc,
so I don't know why it detects dma 4, and I did not manage to change that at
boot time. 
Another example is the hda, which is an ibm DTLA hard drive. In 2.4.2 a 2.4.3
he made the same error in udma mode4, and since 2.4.4 no troubles anymore... I
find it difficult to believe that it is hardware trouble!
Furthemore, I began this thread because I heard someone else on this mailing
list with the same crc error and I thought the patch in ac4 was in a way to
solve the dma detect fails.

thanks for your help

Mike

> 
> -- 
> Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide retry on 2.4.5-ac7

[Jens Axboe]

On Mon, Jun 04 2001, PROFETA Mickael wrote:
> On Mon, Jun 04, 2001 at 10:14:04PM +0200, Jens Axboe wrote:
> > 
> > It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see
> > any changes to the patch, so more details on the nature of the problem
> > would be helpful.
> 
> Ok, this is the results of a hdparm -tT on my second hard disk:
> 
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
> ide1: reset: success
> 64 MB in  7.03 seconds =  9.10 MB/sec
> 
> and then the kernel has shifted to udma3 and I have no more error in this
> session with that hard disk
> 
> I tried the same thing on -ac7 and I always have the errors, the kernel does
> not reset ide... Looking at the different change on ac patches, I can not see 
> why...

This is not the case that is attempted solve. The above could be a cable
error (it looks like it). These are usually genuine and indicate a real
hw problem.

-- 
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide retry on 2.4.5-ac7

[PROFETA Mickael]

On Mon, Jun 04, 2001 at 10:14:04PM +0200, Jens Axboe wrote:
> 
> It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see
> any changes to the patch, so more details on the nature of the problem
> would be helpful.

Ok, this is the results of a hdparm -tT on my second hard disk:

hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide1: reset: success
64 MB in  7.03 seconds =  9.10 MB/sec

and then the kernel has shifted to udma3 and I have no more error in this
session with that hard disk

I tried the same thing on -ac7 and I always have the errors, the kernel does
not reset ide... Looking at the different change on ac patches, I can not see 
why...

Mike
> 
> -- 
> Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

disk-based fds in select/poll

[Pierre Phaneuf]

Pardon me if some parts of this seem clueless. While I'm no newbie in
userland, kernelspace I don't play in very often...

It's fairly widely-known that select/poll returns immediately when
testing a filesystem-based file descriptor for writability or
readability.

On top of this, even when in non-blocking mode, read() could block if
the pages needed aren't in core. sendfile() behaves in a similar way.

What would be needed to alleviate this?

I am thinking that a read() (or sendfile()) that would block because the
pages aren't in core should instead post a request for the pages to be
loaded (some kind of readahead mecanism?) and return immediately (maybe
having given some data that *was* in core). A subsequent read() could
have the data available, but not necessarily (again, it should give
whatever it has in core, but return immediately).

sendfile() would be a lot more tricky to fix in that way I guess, but
could still be possible (the destination fd would be unwritable for a
while, until the transfer is finished). Also, the complexity would be
higher (instead of simply causing readahead to happen (which might
anyway), it would have to trigger the readahead, then get notification
of when the pages are in core to send over, all the while preventing
data from being written to the destination fd in some way).

In the mean time, I was also wondering if issuing smaller read()
requests in a row might give me a better chance of success. I *know*
read() will block, but if I only ask for, say, a page of data (rather
than asking for the full data and relying on the non-blocking to return
EAGAIN (like it should, IMHO!)), it shouldn't take too long, and could
possibly trigger some readahead to be done by the kernel, right?

Or will the readahead be done "on my own time", read() only returning
after the whole thing (my request + readahead) has been done?

I remember seeing a suggestion by Linus for an event-based I/O
interface, similar to kqueue on FreeBSD but much simpler. I'd just say
"I want it too!", ok? :-)

I know about the mincore() trick with mmap()'d files, but with small
files, mmap()ing might not make sense (could be very often).

SGI's AIO might be a solution here, does it use threads? I'm trying to
avoid context switching as much as possible, to keep the CPU cache as
warm as possible.

Well, I might not have the choice to use threads, after all...

(sorry if this message got in twice, I used an NNTP gateway the previous
time, I don't think it got through)

-- 
Pierre Phaneuf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lowlatency 2.2.19

[William Montgomery]

On Mon, 4 Jun 2001, Andrea Arcangeli wrote:

> On Sun, Jun 03, 2001 at 10:38:34AM -0400, William Montgomery wrote:
> > Anyone have any ideas?  
> 
> Which options did you enabled? In theory the ikd patch could only make
> the latency worse ;), there are no performance improvements in it but
> only runtime debugging stuff.
> 
I am including a snippet from my .config:
#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y
# CONFIG_KMSGDUMP is not set
CONFIG_KERNEL_DEBUGGING=y
# CONFIG_SEMAPHORE_DEADLOCK is not set
# CONFIG_DEBUG_KSTACK is not set
# CONFIG_KSTACK_METER is not set
# CONFIG_DEBUG_SOFTLOCKUP is not set
# CONFIG_PROFILE_GCC is not set
CONFIG_TRACE=y
CONFIG_TRACE_SIZE=16384
CONFIG_TRACE_TIMESTAMP=y
# CONFIG_TRACE_TRUNCTIME is not set
CONFIG_TRACE_PID=y
CONFIG_TRACE_CPU=y
CONFIG_DEBUG_MCOUNT=y
# CONFIG_PRINT_EIP is not set
# CONFIG_MEMLEAK is not set
# CONFIG_KDB is not set

---
I cant see anything that could make latency better either but
I can induce 1 to 2.5msec jitter in a 2.2.19 kernel with only 
lowlatency patch after a few minutes stress testing.  

The kernel with both ikd and lowlatency patches tests fine
after 24 hrs of stress testing - jitter always under 1msec.

Wm

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kernel oops when burning CDs

[Rudo Thomas]

Hello everybody!

I get an ooops and immediate kernel panic when I break (CTRL-C) cdrecord. I 
can reproduce it anytime. I use 2.4.5-ac series. Obviously, Linus' 2.4.5 is 
fine.

I know, I know. I was supposed to make a serios oops report, BUT I wasn't 
able to get the serial console running. (I've read some people couldn't get 
it to run either.)

Can anyone help me with any of the problems?

Rudo Thomas.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5-ac7 SMP crash (hotplug race?)

[Pete Zaitcev]

>I told device to go to sleep, it reported (over serial console that I
>looked at with minicom), that it turned off internal devices
>(including USB client), reported it is going to sleep, and turned
>serial and itself off.

What does it mean "I told device to go to sleep"?
What device? How (what command line)?

> wait_on_irq, CPU 1
> irq: 1 [1 0]
> bh:  1 [0 1]
> CPU 0: 
> CPU 1: c167fe68 c01d805d ... (not recorded full stack)
> Call Trace: [] [] [] [] [] 
>[] [] [] [] [] [] 
>[] [] [] [] []
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> Trace; c0108522 <__global_cli+e2/170>
> Trace; c0170f97 
> Trace; c0170f60 
> Trace; c011d706 
> Trace; c011a56c 
> Trace; c011a423 
> Trace; c011a2ab 
> Trace; c0108935 
> Trace; c0108525 <__global_cli+e5/170>
> Trace; c01617e8 
> Trace; c011a67d <__run_task_queue+5d/70>
> Trace; c0121c35 
> Trace; c0121670 
> Trace; c0105000 
> Trace; c0105556 
> Trace; c0121670 

Curious. What host controller driver do you use?

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide retry on 2.4.5-ac7

[Jens Axboe]

On Mon, Jun 04 2001, PROFETA Mickael wrote:
> Hi
> 
>   Since my first try on 2.4 kernel, I had trouble with DMA when I
>   select activate on boot time because it selects udma4, whereas
>   my HD is only able to do udma2. I correct that with hdparm, but
>   I was quite happy of the patch in ac4 whixh detect ide lost
>   interrupt and retry with a value lower of dma.  But it seems
>   that this patch does not work anymore in ac7?? I can not see in
>   the changelog that you come back or made other change in ide??
>   Should it work in the same way or not?
> 
>   My hardware: via 686a of course, with Athlon 500 on a k7m MB

It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see
any changes to the patch, so more details on the nature of the problem
would be helpful.

-- 
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac7

[Alan Cox]

> 2.4.5-ac7 fixes the cs46xx problems I had with my ThinkPad 600X in
> 2.4.5-ac[456].  It works great now.  Many thanks to Frank Davis and Alan Cox!

And also to Tom Woller and Crystal themselves who have been fixing a lot of the
cs46xx real problems while we broke and fixed the locking
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Error Compiling Driver code:

[Khachaturov, Vassilii]

1) Check the FAQ - http://www.tux.org/lkml/#s8
2) RH6.2 as it is doesn't come with all the newest tools versions needed for
the 2.4.x kernels. See Documentation/versions.

HTH,
Vassilii
> -Original Message-
> Hi ,
> I am trying to compile a driver code in Red Hat 6.2
> which is already a working code, but I get the
> following errors when i compile. 
> 
> /usr/src/linux/include/asm/smp.h:206: arguments given
> to macro `hard_smp_processor_id'
> 
[snip]
> 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Error Compiling Driver code:

[jalaja devi]

Hi ,
I am trying to compile a driver code in Red Hat 6.2
which is already a working code, but I get the
following errors when i compile. 

/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'

Any clue or hint will be helpful.

Thanks
jalaja


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel Stack usage [was: [PATCH] fs/devfs/base.c]

[Bill Pringlemeir]

> Bill Pringlemeir <[EMAIL PROTECTED]> writes:

  > There was a discussion on comp.arch.embedded about bounded stack
  > use.  It is fairly easy to calculate the stack usage for call
  > trees, but much more difficult for `DAGs'.  Ie, a recursive
  > functions etc.  I don't know about the policy on recursion in the
  > kernel, but I think it would be bad.

  > Perhaps the checker could be modified to keep track of the call
  > tree and find the largest value used in the tree.  Each function
  > will have a maximum, to which you should add the interrupt
  > handling overhead, which would be calculated in a similar way.
  > This will work if you do not allow re-entrant interrupts and you
  > do not have any `cycles' in the function call hierarchies.

Sorry, I neglected the important case of `alloca', and other variable
length stack allocation functions/constructs.  Maybe this becomes too
restrictive to be useful.

regards,
Bill Pringlemeir

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.5-ac7 usb-uhci appears twice in /proc/interrupts

[Meelis Roos]

PR> I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed
PR> twice on the same IRQ 9.
[...]
PR>   9:  0  XT-PIC  usb-uhci, usb-uhci
[...]
PR> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
PR> 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)

This is normal, you do have two of these.

But a there's a little copy-paste error(?) on uhci.c:
both usb-uhci.c and uhci.c register themselves as usb-uhci.
(in request_region and request_irq and uhci_pci_driver).

--
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs/devfs/base.c

[Bill Pringlemeir]

> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes:
[snip]
 > I guess we should ask the question as to what's an
 > acceptable usage.  Theoretically, any amount could pose a
 > problem, but that's hardly a useful position to work

There was a discussion on comp.arch.embedded about bounded stack use.
It is fairly easy to calculate the stack usage for call trees, but
much more difficult for `DAGs'.  Ie, a recursive functions etc.  I
don't know about the policy on recursion in the kernel, but I think it
would be bad.

Perhaps the checker could be modified to keep track of the call tree
and find the largest value used in the tree.  Each function will have
a maximum, to which you should add the interrupt handling overhead,
which would be calculated in a similar way.  This will work if you do
not allow re-entrant interrupts and you do not have any `cycles' in the
function call hierarchies.

hth,
Bill Pringlemeir.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.5(-ac*] still broken NFS/Reiserfs

[Kevin P. Fleming]

I've got two machines here running 2.4.5-ac6 with Chris Mason's posted 2.4.5
Reiserfs/knfsd patch, plus the small 2.4.5 NFS client patch posted last week
as well. Even with all of this, I still have NFS weirdness.

>From the client, I can mount and read pretty much anything I like from the
server. I can create files in existing directories on the server. I can
create new directories on the server. I _cannot_, however, create anything
in a directory I created from the client (I get "file/directory does not
exist" errors). I have also seen one case where the client's directory
listing for a directory at the root of an export point did not match the
server's listing until I unmounted and remounted the NFS  mount.

Most of the time, this problem does not occur. It's very intermittent. I can
boot up my client, and it will work fine for 24 hours, or it will fail in
five minutes. Once it fails, an unmount/remount seems to cure it.

There is still major weirdness going on here, and I'm hesitant to try unfsd
unless someone can say that it works reliably... I do need to find a
solution to this though, and am willing to help in whatever way I can.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB-storage and 2.4.2

[Matthew Dharm]

Try 2.4.5, which has some assorted fixes that should solve this problem.

Matt

On Sun, Jun 03, 2001 at 08:08:25PM -0500, Jerry Frana wrote:
> Hi, i've been having a problem with my usb zip drive (older 100mb model)
> 
> it's 100% repeateble: 
> 
> copy a large file to anywhere, and within a minute or so: 
> copy stops dead.
> and the following appears in the syslog:
> 
> Jun  3 21:10:56 int-21h kernel: uhci: host controller process error. something bad 
>happened
> Jun  3 21:10:56 int-21h kernel: uhci: host controller halted. very bad
> 
> my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset
> 
> if you need any more info, please let me know,
> 
> Thanks
> David F.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Senior Software Designer, Momentum Computer

C:  Why are you upgrading to NT?
AJ: It must be the sick, sadistic streak that runs through me.
-- Chief and A.J.
User Friendly, 5/12/1998

 PGP signature

Re: keyboard hook?

[James Simmons]

> Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a 
> hook for my qoder stuff, and a loadable module for the meat of the
> driver. 

Okay. 

> Then I'll port up to the input API. 

Just send me the code and I will place it into CVS.

>I have a Sparc here; does it have drivers you wish to have ported?

Alot of work has to be done their :-/ If you are up to it I would be happy
to work with you.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I/O tracing

[YU,SAMMY (HP-Roseville,ex1)]

Hi,
Please CC me as I'm not subscribed on the list, thanks.  Not sure if
this is appropriate forum, is there an existing tool/module for capturing
all the I/O requests such as:

Unique Identifier
Start Time
End Time
Device Identifier
Operation Type (Read Or Write)
Offset
Length (Number Of Bytes)

I am aware of existing /proc/disks and partitions, but these aren't real
time.  If not, are there any facilities in the kernel I can put a hook in to
keep track of the I/O?


Thanks in advance,
Sammy Yu
Hewlett-Packard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

iptables port remapping problem (was: [newbie] NFS client:port-unreachable)

[Roland Kuhn]

On Sun, 3 Jun 2001, Trond Myklebust wrote:

> Are /home and /compass on the same mount point on the client though?
> If not, then they won't share the same port.
>
> IOW: they will only share the same port if you have '/' as the NFS
> mountpoint.

When I mount via nfs each mount gets its own local port to communicate
with the server. Looking at /proc/net/ip_conntrack I see that one such
port (797) got remapped to 772, so I see packets emerging from 772 and
getting back from the server, but the mapping is not done upon receive, so
that it does not reach port 797 (where it originally came from) but port
772 which has no process attached. This results in an ICMP_PORT_UNREACH to
the server and an nfs client not getting an answer. This problem can be
cured by 'rmmod ip_conntrack' and restarting the firewall, which is not a
good solution.

My conclusion: Either iptables has a problem when remapping ports under
moderate load (several RPCs masqueraded per second) or the nfs-client does
not properly reserve the local port when mounting.

BTW: I use util-linux-2.11d but still get 'nfs warning: mount version
older than kernel'.

DETAILS: I have a DECstation being nis domain server and nfs server for
/home, /compass, /usr/local and some other things (all different
directories on the server, I have given the mount points for the clients).
There are a dozen clients being served without problems, mostly running
2.2.14 (RedHat 6.2), some 2.4.2 (SuSE 7.1). Besides I have another server
(RedHat 7.1, kernel 2.4.4 with knfsd-reiserfs-patch from namesys.com),
which also mounts /home and /compass from the DEC and serves some internal
disk space to a linux cluster (RedHat 6.2). This server has IP 217, but
masquerades (via iptables -j SNAT) the cluster as having IPs 218 or 219
(roughly half of the 32 machines on each address), since the cluster
machines have no other connection to the internet because we ran out of
IPs.

Ciao,
Roland

+-+
|Tel.:089/326493320561/873744 |
|in   Radeberger Weg 8Am Fasanenhof 16|
| 85748 Garching  34125 Kassel|
+---+-+
|Physik-Department E18  |  Raum3558   |
|James-Franck-Str.  |  Telefon 089/289-12592  |
|85747 Garching | |
+---+-+
| May the Source be with you! |
+-+



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Remi Turk]

On Sun, Jun 03, 2001 at 07:25:25AM -0400, Alexander Viro wrote:
> BTW, bind and friends are also easy - it's
>   what = open(old, 0);
>   where = open(mountpoint, 0);
>   new_mount(where, MNT_BIND, what);
> 
> Comments?

What if `what' and or `where' aren't directories but e.g. sockets?
(IOW, would this allow binding sockets into the filesystem,
or am I being too perverse here?)

Happy Hacking

-- 
Linux 2.4.5-ac6 #2 Sun Jun 3 15:45:27 CEST 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Andries . Brouwer]

> Current interface had grown an impressive collection of warts.
> Worse yet, you _can't_ put parsing into generic code.
> There are filesystems that have a binary object as 'data'.

Yes, that was a very unfortunate decision, back in the good old times
when nfs was implemented. And smb, ncp, coda followed nfs.

Nevertheless, there is no problem adding vfs_parse_mount_options().
For example, one can have a flag FS_HAS_BINARY_MOUNT_DATA in
the fs_flags field of the struct file_system_type that describes
the filesystem type, and refrain from trying to parse the mount data
when this bit is set.


Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Hank Leininger]

On 2001-06-03, [EMAIL PROTECTED] wrote:

> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the
> /, /usr and /usr/spool filesystems for FOO OS. Now
> mount /dev/a /mnt -o symlink_prefix=/mnt
> mount /dev/b /mnt/usr -o symlink_prefix=/mnt
> mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt

Cool.

What happens when someone creates new absolute symlinks under /mnt ?
Will/should the magic /mnt/ header be stripped from any symlink created
under such a path-translated volume?  The answer is probably 'yes', but
either one violates POLA :(

--
Hank Leininger <[EMAIL PROTECTED]> 
  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Tulip and eepro100 problems

[Jasper Jans]

Hi all,

First of all.. please include [EMAIL PROTECTED] in your
replies since my regular mail account in which I get the list mails
is not functional at the moment.

I've just installed a fresh linux system.
Default Mandrake 8.0 kernel (2.4.3-20mdksmp) and the plain vanilla
2.4.5 kernel both give me this same behaviour.

LNE100TX card in my system gets initialized just fine - however no
matter what I do it will not send any data. Not if I run it via a
10 Mbit hub neither via a cross cable at 100 Mbit.
At the other side there is a LNE100TX card in a Win2k Pro system.

There is an Intel onboard card in this system as well using the
eepro100 driver. This card seems to function fine when used via
the 10 Mbit hub - however once I connect it via a cross cable and
it switches from 10 Mbit half duplex to 100 Mbit full duplex it
stops responding completely as well.

I've seen some emails in the archives about the tulip driver being
broken for some people - however the mails I saw mentioned 2.4.4
and above. I've tried both the 2.4.5 vanilla and the mandrake
2.4.3-20 (both compiled with smp support).

The log file shows:
Jun  3 18:07:50 badaboom kernel: eth0: DC21041 at 0xf480 (PCI bus 0,
device 11), h/w address 00:00:c5:0c:f1:82,
Jun  3 18:07:50 badaboom kernel:   and requires IRQ16 (provided by
PCI BIOS).
Jun  3 18:07:50 badaboom kernel: de4x5.c:V0.546 2001/02/22
[EMAIL PROTECTED]
Jun  3 18:07:50 badaboom kernel: eth0: media is TP.
Jun  3 18:07:50 badaboom kernel: eepro100.c:v1.09j-t 9/29/99 Donald
Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
Jun  3 18:07:50 badaboom kernel: eepro100.c: $Revision: 1.36 $
2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and ot
hers
Jun  3 18:07:50 badaboom kernel: eth1: Intel Corporation 82557 [Ethernet
Pro 100], 00:A0:C9:49:BC:D0, IRQ 18.
Jun  3 18:07:50 badaboom kernel:   Receiver lock-up bug exists --
enabling work-around.
Jun  3 18:07:50 badaboom kernel:   Board assembly 645520-034, Physical
connectors present: RJ45
Jun  3 18:07:50 badaboom kernel:   Primary interface chip DP83840 PHY
#1.
Jun  3 18:07:50 badaboom kernel:   DP83840 specific setup, setting
register 23 to 8462.
Jun  3 18:07:50 badaboom kernel:   General self-test: passed.
Jun  3 18:07:50 badaboom kernel:   Serial sub-system self-test: passed.
Jun  3 18:07:50 badaboom kernel:   Internal registers self-test: passed.
Jun  3 18:07:50 badaboom kernel:   ROM checksum self-test: passed
(0x49caa8d6).
Jun  3 18:07:50 badaboom kernel:   Receiver lock-up workaround
activated.
Jun  3 18:07:50 badaboom kernel: Linux Tulip driver version 0.9.15-pre2
(May 16, 2001)
Jun  3 18:07:50 badaboom kernel: PCI: Unable to reserve I/O region
#1:80@f480 for device 00:0b.0
Jun  3 18:07:50 badaboom kernel: Trying to free nonexistent resource

Jun  3 18:07:50 badaboom kernel: tulip1:  MII transceiver #1 config 3100
status 7809 advertising 01e1.
Jun  3 18:07:50 badaboom kernel: eth2: Lite-On 82c168 PNIC rev 32 at
0xf800, 00:C0:F0:3E:70:57, IRQ 19.

Anyone any ideas on how to get this to work?

Thanks,
Jasper

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Cache size calculation on Athlon/Duron

[James Slater]

Hi,

Reading through arch/i386/kernel/setup.c in 2.4.5, I noticed that the code
which sets x86_cache_size sets it to the size of the chip's L2 cache if
present.

Which is fine for everything except the Athlon/Duron, which have exclusive
L1/L2 caches, so surely they should be added together in this case to give
the total cache size? Or am I just missing something stupid?

--- arch/i386/kernel/setup.c.orig   Sun Jun  3 21:49:45 2001
+++ arch/i386/kernel/setup.cSun Jun  3 22:16:58 2001
@@ -1098,7 +1098,15 @@
if ( l2size == 0 )
return; /* Again, no L2 cache is possible */
 
-   c->x86_cache_size = l2size;
+   /*
+* Athlon/Duron have exclusive L1/L2 cache, so sum them,
+* for everyone else set cache size to be L2 only.
+*/
+   if (c->x86_vendor == X86_VENDOR_AMD && c->x86 == 6) {
+   c->x86_cache_size += l2size;
+   } else {
+   c->x86_cache_size = l2size;
+   }
 
printk(KERN_INFO "CPU: L2 Cache: %dK (%d bytes/line)\n",
   l2size, ecx & 0xFF);

-- 
James Slater
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XMM: monitor Linux MM inactive/active lists graphically

[Mark Hahn]

> XMM is heavily modified XMEM utility that shows graphically size of
> different Linux page lists: active, inactive_dirty, inactive_clean,
> code, free and swap usage. It is better suited for the monitoring of
> Linux 2.4 MM implementation than original (XMEM) utility.
> 
> Find it here:  http://linux.inet.hr/>

interesting.  I prefer to collect data separately from viewing it,
and use the following simple perl script to do so; obviously, 
it generates a bunch of separate files, one for each metric,
suitable for traditional filtering, gnuplot, etc.

#!/bin/perl
use IO::Handle;

require 'sys/syscall.ph';
sub gettimeofday {
$timeval = pack("LL", ());
syscall( _gettimeofday, $timeval, 0) != -1
or die "gettimeofday: $!";
($sec,$usec) = unpack("LL", $timeval);
return $sec + 1e-6 * $usec;
}

open(S,"pi.st");  PI->autoflush(1);
open(PO,">po.st");  PO->autoflush(1);
open(SI,">si.st");  SI->autoflush(1);
open(SO,">so.st");  SO->autoflush(1);
open(CX,">ctx.st"); CX->autoflush(1);
open(MF,">free.st");MF->autoflush(1);
open(BF,">buf.st"); BF->autoflush(1);
open(AC,">act.st"); AC->autoflush(1);
open(ID,">id.st");  ID->autoflush(1);
open(IC,">ic.st");  IC->autoflush(1);
open(IT,">it.st");  IT->autoflush(1);
open(SW,">swap.st");SW->autoflush(1);
open(BH,">bh.st");  BH->autoflush(1);
open(IN,">inode.st");   IN->autoflush(1);
open(DE,">dentry.st");  DE->autoflush(1);

$c = 0;
$first = gettimeofday();
while (1) {
  sleep(1);
  $now = gettimeofday() - $first;

  seek(S,0,SEEK_SET);
  while () {
  if (/^page\s+(\d+)\s+(\d+)$/) {
  if ($c) { print PI "$now ",4*($1 - $pi),"\n"; }
  if ($c) { print PO "$now ",4*($2 - $po),"\n"; }
  $pi = $1;
  $po = $2;
  next;
  }
  if (/^swap\s+(\d+)\s+(\d+)$/) {
  if ($c) { print SI "$now ",4*($1 - $si),"\n"; }
  if ($c) { print SO "$now ",4*($2 - $so),"\n"; }
  $si = $1;
  $so = $2;
  next;
  }
  if (/^ctxt\s+(\d+)$/) {
  if ($c) { print CX "$now ",$1 - $cx,"\n"; }
  $cx = $1;
  next;
  }
  }
  seek(M,0,SEEK_SET);
  while () {
  if (/^MemFree:\s+(\d+) kB$/) {print MF "$now ",$1,"\n"; next; }
  if (/^Buffers:\s+(\d+) kB$/) {print BF "$now ",$1,"\n"; next; }
  if (/^Active:\s+(\d+) kB$/) { print AC "$now ",$1,"\n"; next; }
  if (/^Inact_dirty:\s+(\d+) kB$/) {print ID "$now ",$1,"\n"; next; }
  if (/^Inact_clean:\s+(\d+) kB$/) {print IC "$now ",$1,"\n"; next; }
  if (/^Inact_target:\s+(\d+) kB$/) {   print IT "$now ",$1,"\n"; next; }
  if (/^Inact_target:\s+(\d+) kB$/) {   print IT "$now ",$1,"\n"; next; }
  if (/^Swap:\s+\d+\s+(\d+)/)   {   print SW "$now ",$1,"\n"; next; }
  }
  seek(B,0,SEEK_SET);
  while () {
  if (/^buffer_head\s+(\d+)\s+(\d+)\s+(\d+)/) { print BH "$now 
",$1*$3/1024,"\n"; next; }
  if (/^inode_cache\s+(\d+)\s+(\d+)\s+(\d+)/) { print IN "$now 
",$1*$3/1024,"\n"; next; }
  if (/^dentry_cache\s+(\d+)\s+(\d+)\s+(\d+)/) {print DE "$now 
",$1*$3/1024,"\n"; next; }
  }
  $c++;
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I810 Sound broke between 2.4.2 and 2.4.3

[Ben Castricum]

I use amp to play my mp3s and it seem to stop functioning since 2.4.3. I
captured the kernel messages from the module :

--- 2.4.2 ---
Intel 810 + AC97 Audio, version 0.01, 14:04:06 Jun  4 2001
PCI: Found IRQ 10 for device 00:1f.5
PCI: The same IRQ used for device 00:1f.3
PCI: The same IRQ used for device 01:09.0
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881)
i810_audio: Codec refused to allow VRA, using 48Khz only.

--- 2.4.3 ---
Intel 810 + AC97 Audio, version 0.01, 14:18:58 Jun  4 2001
PCI: Found IRQ 10 for device 00:1f.5
PCI: The same IRQ used for device 00:1f.3
PCI: The same IRQ used for device 01:09.0
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881)
i810_audio: Codec refused to allow VRA, using 48Khz only.
i810_audio: 9576 bytes in 50 milliseconds

an strace of amp seems to halt on writing to the /dev/dsp

I have an Intel Celeron on an Asus-MEW motherboard which has this soundcard
integrated.

Any ideas?

Ben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: here comes the summer...

[J . A . Magallon]

On 06.02 Pavel Machek wrote:
> Hi!
> 
> > ...again (I think I asked just the same last summer)
> > and lm_sensors is still out of the kernel (we have got 40ºC in Spain
> > this week, and I would like to know how my PIIs suffer...)
> 
> Send some summer over here. It is 15C outside...
> 
> You should try latest ACPI patches, they include thermal managment, too.
> 

I have tried the latest CVS i2c+lm_sensors2, and the patches it generates
look like much more clean. I am waiting for the announced 2.6 relase, and
then will try to send a patch to Alan (if official mantainer do not does it
himself...)

-- 
J.A. Magallon   #  Let the source be with you...
mailto:[EMAIL PROTECTED]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac6 #2 SMP Sat Jun 2 01:52:13 CEST 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

USB-storage and 2.4.2

[Jerry Frana]

Hi, i've been having a problem with my usb zip drive (older 100mb model)

it's 100% repeateble: 

copy a large file to anywhere, and within a minute or so: 
copy stops dead.
and the following appears in the syslog:

Jun  3 21:10:56 int-21h kernel: uhci: host controller process error. something bad 
happened
Jun  3 21:10:56 int-21h kernel: uhci: host controller halted. very bad

my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset

if you need any more info, please let me know,

Thanks
David F.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rtl8139too in 2.4.5

[Rogier Wolff]

[EMAIL PROTECTED] wrote:
> My RTL8139 (Identified 8139 chip type 'RTL-8139A')
> was fine in 2.4.3 and doesnt work in 2.4.5.
> Copying the 2.4.3 version of 8139too.c makes things work again.
> 
> Since lots of people complained about this, I have not tried to
> debug - maybe a fixed version already exists?

We upgraded to 2.4.5-ac2 for some test, noted that the ethernet card
was agian in 6-packets-per-second mode (i.e. very slow) and then
continued to 2.4.5-ac4 where the driver was reverted to the one in
2.4.3. That worked.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.5-ac7 usb-uhci appears twice in /proc/interrupts

[Pavel Roskin]

Hello!

I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed
twice on the same IRQ 9.

# cat /proc/interrupts
   CPU0
  0:  82287  XT-PIC  timer
  1:   2624  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  8:  1  XT-PIC  rtc
  9:  0  XT-PIC  usb-uhci, usb-uhci
 10:781  XT-PIC  eth0
 11:  0  XT-PIC  eth1
 12:900  XT-PIC  PS/2 Mouse
 14:  17434  XT-PIC  ide0
 15:  9  XT-PIC  ide1
NMI:  0
LOC:  82250
ERR: 15

.config is here: http://www.red-bean.com/~proski/linux/config

In short, all USB stuff is compiled as modules.

# CONFIG_USB_UHCI is not set
CONFIG_USB_UHCI_ALT=m
# CONFIG_USB_OHCI is not set

It's a brand new VIA motherboard, so I don't know whether the problem
existed in the earlier kernels or not (if it's a problem).

It looks like that the motherboard has two USB controllers:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 
20)
00:08.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang]
00:09.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)

-- 
Regards,
Pavel Roskin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Andries . Brouwer]

From [EMAIL PROTECTED] Sun Jun  3 13:25:31 2001

> [One could start a subdiscussion about that part.
> The mount(2) system call needs to transport vfs information
> and per-fs information. So far, the vfs information used
> flag bits only, but sooner or later we'll want to have
> strings, and need a vfs_parse_mount_options().
> Indeed, many filesystems today have uid= and gid= and
> umask= options that might be removed from the individual
> filesystems and put into vfs. After all, such options
> are also useful for (foreign) ext2 filesystems.]

_Please_, if we do anything of that kind - let's use a new syscall.
Ideally, I'd say
fs_fd = open("/fs/ext2", O_RDWR);
/* error -> no such filesystem */
write(fs_fd. "/dev/sda1", strlen("/dev/sda1"));
/* error handling */
write(fs_fd, "reserve=5", strlen());
...
dir = open("/usr/local", O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd);/* closes dir and fs_fd */
/* error handling */

Comments?

I do not think this is an improvement. Anyway, it is orthogonal
to what I discussed.

[My version: keep interface constant, reorganize kernel source
to do certain things in one place instead of in several places.
Advantage: treatment becomes uniform and some options that make sense
for all filesystem types but are available today for some only
are generalized.
Your version: invent a new interface, be silent about what happens
inside the kernel.]

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB mouse wheel breakage was Re: Linux 2.4.5-ac5

[Vojtech Pavlik]

On Fri, Jun 01, 2001 at 10:57:17AM +0100, Michael wrote:

> On Wed, May 30, 2001 at 09:30:39PM +0100, Alan Cox wrote:
> > 2.4.5-ac4
> > o   Update USB hid drivers  (Vojtech Pavlik)
> 
> I think these changes have broken my USB wheel mouse.
> 
> Events seems to be getting lost (/dev/input/mice)
> 
> It only scrolls when either the scroll direction has changed or if other
> mouse events occur (e.g. you need to wiggle mouse from side to side to
> scroll down a long page in mozilla)
> 
> problems seems to be in drivers/usb/hid-core.c hid_input_field line 772
> 
>   for (n = 0; n < count; n++) {
> 
>   if (HID_MAIN_ITEM_VARIABLE & field->flags) {
> 
>   if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
>   continue;
> The next 2 lines are dropping the scroll wheel events (which appear in the
> input code as type:2, code: 8, value -1 or 1 depending on direction)
> 
>   if (value[n] == field->value[n])
>   continue;
>   hid_process_event(hid, field, >usage[n], value[n]);
>   continue;
>   }

Thanks for the detailed report.
Here is the fix.

Alan, please apply this to -ac5.

-- 
Vojtech Pavlik
SuSE Labs


diff -urN linux-2.4.5-ac4/drivers/usb/hid-core.c linux/drivers/usb/hid-core.c
--- linux-2.4.5-ac4/drivers/usb/hid-core.c  Tue May 29 19:48:15 2001
+++ linux/drivers/usb/hid-core.cFri Jun  1 16:30:33 2001
@@ -775,7 +775,7 @@
 
if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
continue;
-   if (value[n] == field->value[n])
+   if ((~field->flags & HID_MAIN_ITEM_RELATIVE) && value[n] == 
+field->value[n])
continue;
hid_process_event(hid, field, >usage[n], value[n]);
continue;

Looking for device to write device driver for

[Kip Macy]

This may well be a question whose appropriate response is RTFM. 
However, I did look first. 

I am taking a class on writing device drivers for Linux. I am currently
looking for a device to write a driver for. I first tried to get the
engineering specification for my soundcard, but after much frustration I
gave up on dealing with the manufacturer. I then tried to get the
interface information from 3com on their new 3cr990 card to add IPsec
offload support to the linux driver. They responded by telling me that due
to IP-heavy nature of the product that they would not be releasing the
interface. It was later explained to me (in different terms) that most
cards on the market are fundamentally commodity items and as such the only
way that manufacturers can ensure their margins is by obscuring the
interface so that other manufacturers don't use the same interface and
undercut them.

This leads to my question: Is there some central resource for listing
unsupported cards that people have expressed an interest in seeing
supported. The closest I could find was Cosource, but that is fairly
limited.

-Kip

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac7

[Nicolas Pitre]

On Sun, 3 Jun 2001, Oleg Drokin wrote:

> Hello!
>
> In article <[EMAIL PROTECTED]> you wrote:
>
> AC> 2.4.5-ac7
> AC> o   Make USB require PCI(me)
> Huh?!
> How about people from StrongArm sa11x0 port, who have USB host controller (in
> sa companion chip) but do not have PCI?

If it ever gets to a stability point where it's worth including in Alan's
tree, then the dependency could easily be modified to be "USB requires PCI
or SA".  In the mean time I keep that hairball in my tree.


Nicolas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.5-ac7

[Wayne . Brown]

2.4.5-ac7 fixes the cs46xx problems I had with my ThinkPad 600X in
2.4.5-ac[456].  It works great now.  Many thanks to Frank Davis and Alan Cox!

Wayne


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:

> What I did was: add a field  `char *mnt_symlink_prefix;'  to the
> struct vfsmount, fill it in super.c:add_vfsmnt(), use it in
> namei.c:vfs_follow_link(). Pick the value up by recognizing
> in super.c:do_mount() the option "symlink_prefix=" before
> giving the options to the separate filesystems.
> 
> [One could start a subdiscussion about that part. The mount(2)
> system call needs to transport vfs information and per-fs information.
> So far, the vfs information used flag bits only, but sooner or later
> we'll want to have strings, and need a vfs_parse_mount_options().
> Indeed, many filesystems today have uid= and gid= and umask= options
> that might be removed from the individual filesystems and put into vfs.
> After all, such options are also useful for (foreign) ext2 filesystems.]

_Please_, if we do anything of that kind - let's use a new syscall.
Ideally, I'd say
fs_fd = open("/fs/ext2", O_RDWR);
/* error -> no such filesystem */
write(fs_fd. "/dev/sda1", strlen("/dev/sda1"));
/* error handling */
write(fs_fd, "reserve=5", strlen());
...
dir = open("/usr/local", O_DIRECTORY);
/* error handling */
new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
/* error handling */

First open gives you a new channel. Preferably - wit datagram semantics (i.e.
write() boundaries are preserved). Then you convince fs driver to give you
fs. Then you mount it.

Notice that all cruft with "mount ncpfs and then use ioctls to authenticate"
goes away - authentication happens before you mount. Parsers are also easier
that way. Moreover, seeing what filesystem types are available is also trivial,
etc. We need only one special case - mounting that fstypefs. Fine, let's
make new_mount(dir, MNT_TYPES) do that.

BTW, bind and friends are also easy - it's
what = open(old, 0);
where = open(mountpoint, 0);
new_mount(where, MNT_BIND, what);

Comments?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Benchmarks for Linux kernel

[Nathan Straz]

On Fri, Jun 01, 2001 at 09:12:14PM -0700, Jaswinder Singh wrote:
> Can please point me some nice benchmarks for linux kernel .

Linux Benchmark Suite
http://lbs.sf.net/

-- 
Nate Straz  [EMAIL PROTECTED]
sgi, inc   http://www.sgi.com/
Linux Test Project  http://ltp.sf.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] security rules? (and 2.4.5-ac4 security bug)

[Hank Leininger]

On 2001-06-03, Dawson Engler <[EMAIL PROTECTED]> wrote:

> Additionally, do people have suggestions for good security rules?
> We're looking to expand our security checkers.  Right now we just have
> checkers that warn when:

Do you already have checks for signed/unsigned issues?  Those often result
in security problems, although you may already be checking for them simply
for reliable-code purposes.  ...Hm, looking at the archives, I see Chris
Evans responded about signedness issues when you asked last month :-P

You may want to check out and/or subscribe to the security-audit list; most
of the discussion is about userland security issues but kernel problems (or
potential  ones) are discussed as well.  We have archives of the list at:
http://marc.theaimsgroup.com/?l=linux-security-audit=1=2
And see http://www.linuxhelp.org/lsap.shtml for more info, subscribing,
etc.

--
Hank Leininger <[EMAIL PROTECTED]> 
  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux-2.4.5 BUG

[Sasa Ostrouska]

Hi to all of you !

I have this problem with the linux-2.4.5. When I want to shutdown the
system I get this error message:

//

journal_begin called without kernel lock held
kernel BUG at journal.c:423!
invalid operand: 
CPU:1
EIP:0010:[]
EFLAGS: 00010286

eax: 001d ebx: c12b3f2c ecx: 0001 edx: 0001
esi: c7f41600 edi: c12b3f2c ebp: 000a esp: c12b3ec4
ds: 0018  es: 0018  ss: 0018

Process umount (pid: 2861, stackpage = c12b3000)

Stack: c025416c c0254304 01a7 c017791e c0255321 c12b3f2c c7f41600 
c02996a0
c7f41644 3b1a4df9 c12b3f98  3b1a4df9 0010 c025532f 
c0177b4e
c12b3f2c c7f41600 000a  c0169d7c c12b3f2c c7f41600 
000a

Call Trace: [] [] [] [] []
 [] [] [] [] 
[]

Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 56 53 31 db

Unmounting any remaining filesystems...

//

Then the machine stops and I have to switch it off ,
I use the
linux-2.4.5 kernel
with reiserfs compiled in
and glibc-2.2.2

If you can help me solve this would be very apreciated.

Thank you in advance.

Sasa Ostrouska

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

multicast hash incorrect on big endian archs

[Manfred Spraul]

I noticed that the multicast hash calculations assumed little endian
byte ordering in the winbond-840 driver, and it seems that several other
drivers are also affected:

8139too, epic100, fealnx, pci-skeleton, sis900, starfile, sundance,
via-rhine, yellowfin
perhaps drivers/net/pcmcia/xircom_tulip_cb

I've attached an untested patch.
It's possible that the nic performs another byte swap if configured for
big endian support, but I've never seen a nic that performs byte swaps
on register writes, only on memory reads.

Please cc me, I'm not subscribed to the mailing lists.
--
Manfred

diff -u 2.4/drivers/net/8139too.c build-2.4/drivers/net/8139too.c
--- 2.4/drivers/net/8139too.c   Sat Jun  2 14:19:44 2001
+++ build-2.4/drivers/net/8139too.c Sun Jun  3 19:46:05 2001
@@ -2248,6 +2248,10 @@
return crc;
 }
 
+static void set_bit_32(int offset, u32 * data)
+{
+   data[offset >> 5] |= (1 << (offset & 0x1f));
+}
 
 static void rtl8139_set_rx_mode (struct net_device *dev)
 {
@@ -2283,7 +2287,7 @@
mc_filter[1] = mc_filter[0] = 0;
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
 i++, mclist = mclist->next)
-   set_bit (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26,
+   set_bit_32(ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26,
 mc_filter);
}
 
diff -u 2.4/drivers/net/epic100.c build-2.4/drivers/net/epic100.c
--- 2.4/drivers/net/epic100.c   Sat May 26 10:06:26 2001
+++ build-2.4/drivers/net/epic100.c Sun Jun  3 19:48:44 2001
@@ -1305,11 +1305,16 @@
return crc;
 }
 
+static void set_bit_16(int offset, u16 *data)
+{
+   data[offset >> 4] |= (1<<(offset & 0xf));
+}
+
 static void set_rx_mode(struct net_device *dev)
 {
long ioaddr = dev->base_addr;
struct epic_private *ep = dev->priv;
-   unsigned char mc_filter[8];  /* Multicast hash filter */
+   u16 mc_filter[8];/* Multicast hash filter */
int i;
 
if (dev->flags & IFF_PROMISC) { /* Set promiscuous. */
@@ -1332,13 +1337,13 @@
memset(mc_filter, 0, sizeof(mc_filter));
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
 i++, mclist = mclist->next)
-   set_bit(ether_crc_le(ETH_ALEN, mclist->dmi_addr) & 0x3f,
+   set_bit_16(ether_crc_le(ETH_ALEN, mclist->dmi_addr) & 0x3f,
mc_filter);
}
/* ToDo: perhaps we need to stop the Tx and Rx process here? */
if (memcmp(mc_filter, ep->mc_filter, sizeof(mc_filter))) {
for (i = 0; i < 4; i++)
-   outw(((u16 *)mc_filter)[i], ioaddr + MC0 + i*4);
+   outw(mc_filter[i], ioaddr + MC0 + i*4);
memcpy(ep->mc_filter, mc_filter, sizeof(mc_filter));
}
return;
diff -u 2.4/drivers/net/fealnx.c build-2.4/drivers/net/fealnx.c
--- 2.4/drivers/net/fealnx.cSat May 26 10:06:26 2001
+++ build-2.4/drivers/net/fealnx.c  Sun Jun  3 19:49:45 2001
@@ -1642,6 +1642,10 @@
return crc;
 }
 
+static void set_bit_32(int offset, u32 * data)
+{
+   data[offset >> 5] |= (1 << (offset & 0x1f));
+}
 
 static void set_rx_mode(struct net_device *dev)
 {
@@ -1667,7 +1671,7 @@
memset(mc_filter, 0, sizeof(mc_filter));
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
 i++, mclist = mclist->next) {
-   set_bit((ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26) ^ 0x3F,
+   set_bit_32((ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26) ^ 
+0x3F,
mc_filter);
}
rx_mode = AB | AM;
diff -u 2.4/drivers/net/pci-skeleton.c build-2.4/drivers/net/pci-skeleton.c
--- 2.4/drivers/net/pci-skeleton.c  Fri Apr 20 20:54:23 2001
+++ build-2.4/drivers/net/pci-skeleton.cSun Jun  3 20:01:52 2001
@@ -1862,6 +1862,10 @@
return crc;
 }
 
+static void set_bit_32(int offset, u32 * data)
+{
+   data[offset >> 5] |= (1 << (offset & 0x1f));
+}
 
 static void netdrv_set_rx_mode (struct net_device *dev)
 {
@@ -1896,7 +1900,7 @@
mc_filter[1] = mc_filter[0] = 0;
for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count;
 i++, mclist = mclist->next)
-   set_bit (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26,
+   set_bit_32 (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26,
 mc_filter);
}
 
diff -u 2.4/drivers/net/sis900.c build-2.4/drivers/net/sis900.c
--- 2.4/drivers/net/sis900.cSat Jun  2 14:19:44 2001
+++ build-2.4/drivers/net/sis900.c  Sun Jun  3 19:51:38 2001
@@ -1870,6 +1870,11 @@
  * Multicast hash table changes from 128 to 256 bits for 635M/B 

Linux networking and disk IO issues

[Mark Hayden]

I recently released a clusted storage system for Linux (the software
in binary form and manual can be downloaded from
www.northforknet.com).  This software, you can create a highly
available storage cluster out of standard PC hardware.

During this work, we encountered a number of problems with the Linux
kernel.  I believe these all apply to the current kernels (though I'm
working with the 2.4.2 kernel).  If you respond, please CC me
directly, since I follow Linux kernel development through weekly
summaries in Linux Weekly News.

regards, Mark Hayden
[EMAIL PROTECTED]

* The Linux networking stack requires all skbuff buffers to be
  contiguous.  As far as I can tell, this makes it impossible to
  write high-bandwidth UDP applications on Linux.  For instance, the
  kernel will drop a fragmented 8KB message if it cannot allocate 8KB
  of contiguous memory to reassemble it into.  I have found that it
  is relatively easy to enter regimes where this can cause massive
  packet loss.

* readv()/writev().  Linux serializes scatter/gather IO operations
  into an operation for each iovec entry.  This is the relevent code
  from a 2.4-series kernel:

/* VERIFY_WRITE actually means a read, as we write to user space */
fn = (type == VERIFY_WRITE ? file->f_op->read :
  (io_fn_t) file->f_op->write);

ret = 0;
vector = iov;
while (count > 0) {
void * base;
size_t len;
ssize_t nr;

base = vector->iov_base;
len = vector->iov_len;
vector++;
count--;

nr = fn(file, base, len, >f_pos);

if (nr < 0) {
if (!ret) ret = nr;
break;
}
ret += nr;
if (nr != len)
break;
}

  This causes several problems:

  * For writes, it forces read-modify-write when the individual
iovecs are not block-aligned.

  * For reads, it prevents all the read requests from being presented
at the same time to the IO system.  This is a problem for raw IO
without read-ahead.

* There is no preadv(), pwritev().  (The pread/pwrite() system calls
  combine a llseek with a read/write system call.)  This means that
  if you want to have multiple threads in a process write random
  blocks using scatter-gather, you need to open() a device file
  multiple times and make the extra llseek() calls.

* The requirement that everything about operations to raw character
  device files (length, offset in file, *and* address in memory) has
  to be 512-byte aligned is a real hassle.

* There are several assumptions in the kernel that make it very
  difficult to write virtual block devices that convert IO operations
  into networked RPC requests.  For instance, if you run the normal
  NBD device where the server is on the same machine in the client,
  you will likely deadlock your system.  Our software distribution
  includes a patch to the 2.4.2 kernel that prevents these deadlock
  scenarios with NBD, but it is something of a hack (I want to thank
  Stephen Tweedie for his help in developing this work-around, though
  of course the hack is my responsibility.)  I don't know what could
  be done to fix these problems correctly, without a major changes to
  block IO in the kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: query

[Andreas Dilger]

Chanchal Chawla writes:
> i'm writing a file system code, i've a query regarding that, i want you
> to help me out if possible, 
>   
> is it possible to get the absolute mount point of a device at run time
> in that code ? if it is possible then how we can get it ?

It was possible in 2.2 with a minor hack.  I did it by passing mountpoint
dentry via sb->s_root to filesystem, and using d_path() to do the path
lookup inside the filesystem.  s_root is overwritten by the filesystem
to hold the new fs root dentry, so you need to get the path and store it
elsewhere before s_root is overwritten.

In 2.4 I was trying to get Al Viro to tell me the best way to do this, but
because it is _possible_ to mount a filesystem multiple times under 2.4 it
raises a question about which mountpoint you should use.  In 2.4 you need
to supply an additional vfsmnt parameter to d_path(), and I never did get
an answer out of Al as to how to get a vfsmnt inside the filesystem, even
if there is only one mount of the filesystem.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Andries . Brouwer]

> We can kludge around anything. The question being, what for?
> It still leaves ncp with its ioctls ugliness.

I show how to simplify the kernel source without changing the
interface. That is good, and there are some free benefits.

You want to design a new interface. Maybe that is good as well,
but since it is the interface of essentially a unique program
I do not regard that as very urgent.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB mouse wheel breakage was Re: Linux 2.4.5-ac5

[Vojtech Pavlik]

On Fri, Jun 01, 2001 at 05:32:26PM -0400, Robert M. Love wrote:
> USB mouse wheel has been broke since 2.4.5-ac4 (when new USB HID,
> hid-core.c, was integrated).  The mouse in general seems jerky, and
> specifically the input device does not receive events for consecutive
> wheel movements -- just the first "spin," until the mouse is moved
> again.
> 
> obviously the bug is in the new hid-core.c, but I confirmed this by
> compiling with that part of the ac6 patch removed.  I have since been
> trying to write a patch but I can not fix the problem, so I am reporting
> it to you.
> 
> I and another user thought the problem was in hid_input_field, but upon
> looking I now think not.
> 
> My mouse is fairly unusable in X, and unfortunately I can not figure out
> a fix.

It is a quite stupid bug. Here is the fix (already sent to Alan).

-- 
Vojtech Pavlik
SuSE Labs


diff -urN linux-2.4.5-ac4/drivers/usb/hid-core.c linux/drivers/usb/hid-core.c
--- linux-2.4.5-ac4/drivers/usb/hid-core.c  Tue May 29 19:48:15 2001
+++ linux/drivers/usb/hid-core.cFri Jun  1 16:30:33 2001
@@ -775,7 +775,7 @@
 
if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
continue;
-   if (value[n] == field->value[n])
+   if ((~field->flags & HID_MAIN_ITEM_RELATIVE) && value[n] == 
+field->value[n])
continue;
hid_process_event(hid, field, >usage[n], value[n]);
continue;

2.4.5-ac5 BUG in slab.c

[Matt Bernstein]

I was playing with (a romfs) initrd and modularising everything, including
ext2 and ide-*. (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81))

More info on request.

ksymoops 2.4.0 on i686 2.4.5-ac5-4.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5-ac5-4/ (default)
 -m /boot/System.map-2.4.5-ac5-4 (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.

Error (expand_objects): cannot stat(/lib/ext2.o) for ext2
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/eepro100.o) for eepro100
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/ide-disk.o) for ide-disk
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/ide-probe-mod.o) for ide-probe-mod
ksymoops: No such file or directory
Error (expand_objects): cannot stat(/lib/ide-mod.o) for ide-mod
ksymoops: No such file or directory
kernel BUG at slab.c:1200!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00210082
eax: 001b   ebx: c824e000   ecx: 0001   edx: 6518
esi:    edi: c144713c   ebp: cd14fa4c   esp: c6fd7ee8
ds: 0018   es: 0018   ss: 0018
Process netscape-commun (pid: 3901, stackpage=c6fd7000)
Stack: c01bfacb 04b0 c824e019 cd14fa4c c824f019 c824e019 c01286a5 c144713c
   cd14fa4c c824e019 0001 00200246 ce680934 ffeb c6fd7f84 cb5c0de4
   c013bafe c144713c c824e019 c6fd7f84 ce680934 0001 0002 fffb
Call Trace: [] [] [] [] []
   []

Code: 0f 0b 5a 59 8b 5d 14 83 fb ff 74 2b 8d 74 26 00 8d bc 27 00
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/net/ipv4/netfilter/netfilter.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/net/ipv6/netfilter/netfilter.o
Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/md/mddev.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/net/wireless/orinoco_drvs.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/char/drm/drm.o
Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/misc/misc.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/cdrom/driver.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/media/radio/radio.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/media/video/video.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/media/media.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/sound/sounddrivers.o
Warning (read_object): no symbols in 
/lib/modules/2.4.5-ac5-4/build/drivers/parport/driver.o
Warning (map_ksym_to_module): cannot match loaded module ext2 to a unique module 
object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module eepro100 to a unique module 
object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module ide-disk to a unique module 
object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module ide-probe-mod to a unique 
module object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module ide-mod to a unique module 
object.  Trace may not be reliable.
Reading Oops report from the terminal
kernel BUG at slab.c:1200!
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210082
eax: 001b   ebx: c824e000   ecx: 0001   edx: 6518
esi:    edi: c144713c   ebp: cd14fa4c   esp: c6fd7ee8
ds: 0018   es: 0018   ss: 0018
Process netscape-commun (pid: 3901, stackpage=c6fd7000)
Stack: c01bfacb 04b0 c824e019 cd14fa4c c824f019 c824e019 c01286a5 c144713c
   cd14fa4c c824e019 0001 00200246 ce680934 ffeb c6fd7f84 cb5c0de4
   c013bafe c144713c c824e019 c6fd7f84 ce680934 0001 0002 fffb
Call Trace: [] [] [] [] []
   []
Code: 0f 0b 5a 59 8b 5d 14 83 fb ff 74 2b 8d 74 26 00 8d bc 27 00

>>EIP; c01280d9<=
Trace; c01286a5 
Trace; c013bafe 
Trace; c013e3d8 
Trace; c0130254 
Trace; c0130543 
Trace; c0106e5b 
Code;  c01280d9 
 <_EIP>:
Code;  c01280d9<=
   0:   0f 0b ud2a  <=
Code;  c01280db 
   2:   5apop%edx
Code;  c01280dc 
   3:   59pop%ecx
Code;  c01280dd 
   4:   8b 5d 14  mov0x14(%ebp),%ebx
Code;  c01280e0 
   7:   83 fb ff  cmp$0x,%ebx
Code;  c01280e3 
   a:   74 2b

Re: SCSI-CD-Writer don't show up

[Matthias Schniedermeyer]

On Sun, Jun 03, 2001 at 06:38:27PM +0200, Gérard Roudier wrote:
> 
> On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote:
>
> > I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds
> > the first one (1 0 5 0), the other two i have to add with
> > 
> > echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi
> > echo "scsi add-single-device 2 0 6 0" > /proc/scsi/scsi
> > 
> > to make them useable.
> > 
> > Here is the complete ist of my SCSI-Devices:
> > 
> > Host: scsi0 Channel: 00 Id: 06 Lun: 00
> >   Vendor: IBM  Model: DDYS-T18350N Rev: S93E
> >   Type:   Direct-AccessANSI SCSI revision: 03
> > Host: scsi1 Channel: 00 Id: 00 Lun: 00
> >   Vendor: PLEXTOR  Model: CD-ROM PX-32TS   Rev: 1.03
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi1 Channel: 00 Id: 01 Lun: 00
> >   Vendor: PIONEER  Model: DVD-ROM DVD-303  Rev: 1.10
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi1 Channel: 00 Id: 05 Lun: 00
> >   Vendor: TEAC Model: CD-R58S  Rev: 1.0N
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi2 Channel: 00 Id: 02 Lun: 00
> >   Vendor: PIONEER  Model: DVD-ROM DVD-304  Rev: 1.03
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi2 Channel: 00 Id: 03 Lun: 00
> >   Vendor: PIONEER  Model: DVD-ROM DVD-304  Rev: 1.03
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi2 Channel: 00 Id: 04 Lun: 00
> >   Vendor: TEAC Model: CD-R58S  Rev: 1.0K
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > Host: scsi2 Channel: 00 Id: 06 Lun: 00
> >   Vendor: TEAC Model: CD-R58S  Rev: 1.0P
> >   Type:   CD-ROM   ANSI SCSI revision: 02
> > 
> > I have a "Symbios 53c1010 (Dual Channel Ultra 160)" and a "NCR 810a" The
> > two devices which are not found are connected through adapters onto the
> > second channel of the Symbios 53c1010.
> > 
> > Kernel is 2.4.4 or 2.4.5ac6. 
> > As host-adapter-driver i use the "SYM53C8XX"-driver
> > 
> > If other info is needed, no problem. :-)
> 
> You should check if your devices are enabled for SCAN in the NVRAM.



I had disabled all IDs from scanning (except those which had a drive) when
i first installed the system.

Now i enabled all IDs for scanning. :-)




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

the value of PROC_CHANGE_PENALTY

[Tsafrir Dan]

as I understand, for i386 in Linux-2.2.x the default length
of a quantum was 200ms, and in 2.4.x it had changed to 50ms
(
 according to the following 2.4.5 sched.c code:

#if HZ < 200
#define TICK_SCALE(x)   ((x) >> 2)
...
#define NICE_TO_TICKS(nice) (TICK_SCALE(20-(nice))+1)
...
/* in the `recalculate' portion of schedule(): ... */
for_each_task(p)
p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice);
)

But, 
the value of PROC_CHANGE_PENALTY was not changed accordingly, and is 
still 15. This means that the result of the following goodness() code:
if (p->processor == this_cpu)
weight += PROC_CHANGE_PENALTY;
is that any task that executed on `this_cpu' (goodness > 15) 
will always be more "desirable" then a task that executed on 
another cpu (goodness <= 6) which was not the case in 2.2.x .

am I correct ?
and if so, is this what the authors meant, or did they simply forget
to update PROC_CHANGE_PENALTY's value when moving from 2.2 to 2.4 ?

please cc me: [EMAIL PROTECTED]
thanks, dan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Dual AMD Palomino from Australia

[Dieter Nützel]

Hello Alan,

do you have an dual AMD 760MP based mobo, too?
It should be more interesting to see some multi processing workloads.

Here are the links:

http://www.overclockers.com.au/techstuff/a_tyan_thunder/
http://www.overclockers.com.au/techstuff/a_tyan_thunder/page2.shtml
http://www.overclockers.com.au/techstuff/a_tyan_thunder/boot.txt

Thanks,
Dieter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reg mkdir syscall

[SATHISH.J]

Hi,
Sorry to disturb you.

Actually I had written a small file system(on 2.2.14 kernel) similar  to
RAMFS on 2.4 kernel. I am able to mount it but when I try to create
directory under it, it gives EEXIST error saying" file already exists" but
when I check the directory again that file gets created. But the link
count of the parent remains the same. I do not know how this directory
gets created but with an error message. Please also tell me what all
functions mkdir passes thro' while creating a directory. One more thing is
when I took an strace of mkdir command the syscall mkdir fails with
EEXIST error.
Please help me with your thoughts.

Thanks in advance,

Regards,
sathish.j




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:

> > Current interface had grown an impressive collection of warts.
> > Worse yet, you _can't_ put parsing into generic code.
> > There are filesystems that have a binary object as 'data'.
> 
> Yes, that was a very unfortunate decision, back in the good old times
> when nfs was implemented. And smb, ncp, coda followed nfs.
> 
> Nevertheless, there is no problem adding vfs_parse_mount_options().
> For example, one can have a flag FS_HAS_BINARY_MOUNT_DATA in
> the fs_flags field of the struct file_system_type that describes
> the filesystem type, and refrain from trying to parse the mount data
> when this bit is set.

We can kludge around anything. The question being, what for? It still
leaves ncp with its ioctls ugliness. It still treats device name
in a special way for no good reason - it _is_ an option, just like any
other. Hell, less generic than nosuid or read-only. It still leaves us
with cruft in flags. What for? To maintain binary compatibility with
one utility? We can leave the old interface in place and freeze it.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Salvaging resource manager state

[David Gordon (LMC)]

Hi,

Could you please CC to [EMAIL PROTECTED] ? Thank you.

I built a script to startup an IPv6 web server (Jigsaw) automatically at
boot. Jigsaw requires a java-like interpreter (jipsy) to start the web
class.  However, I get the following error message:
"Salvaging resource manager state
resource store state salvaged using 1
Salvagin resource manager state
resource store state salvaged using 25"

What does this mean ?

David Gordon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: symlink_prefix

[Alexander Viro]

On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote:

> [My version: keep interface constant, reorganize kernel source
> to do certain things in one place instead of in several places.
> Advantage: treatment becomes uniform and some options that make sense
> for all filesystem types but are available today for some only
> are generalized.
> Your version: invent a new interface, be silent about what happens
> inside the kernel.]

Current interface had grown an impressive collection of warts. Worse
yet, you _can't_ put parsing into generic code. There are filesystems
that have a binary object as 'data'. And there are filesystems that
do post-mount authentication via ioctls on root directory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Pset patches

[Val Henson]

Are you the same Tim Hockin that wrote the pset patches for Linux
2.2.12?  I noticed your pset web page is gone and I'd like to mirror
it if it hasn't been already.

-VAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-2.4.[45] 8139too nfs performance

[Eduard Hasenleithner]

Hi,

Starting with kernel 2.4.4 the nfs performance with the 8139too driver
is very bad. It seems there are interrupts missing, but the 8139
interrupt is not stuck.

Look at this tcpdump:

Server side ..

19:12:42.840489 192.168.1.1.2049 > 192.168.1.2.3717744806: reply ok 1472 (frag 
29651:1480@0+)
19:12:42.840583 192.168.1.1 > 192.168.1.2: (frag 29651:1480@1480+)
19:12:42.840651 192.168.1.1 > 192.168.1.2: (frag 29651:1480@2960+)
19:12:42.840760 192.168.1.1 > 192.168.1.2: (frag 29651:1480@4440+)
19:12:42.840868 192.168.1.1 > 192.168.1.2: (frag 29651:1480@5920+)
19:12:42.840970 192.168.1.1 > 192.168.1.2: (frag 29651:928@7400)
19:12:43.525919 192.168.1.2.3717744806 > 192.168.30.1.2049: 116 read fh 
0,24/3019440128 [|nfs] (DF)
19:12:43.526761 192.168.1.1.2049 > 192.168.1.2.3717744806: reply ok 1472 (frag 
29652:1480@0+)
19:12:43.526857 192.168.1.1 > 192.168.1.2: (frag 29652:1480@1480+)

... and a similar event at the client side ...

19:20:22.665977 192.168.1.1.2049 > 192.168.1.2.1301891238: reply ok 1472 (frag 
29741:1480@0+)
19:20:22.666099 192.168.1.1 > 192.168.1.2: (frag 29741:1480@1480+)
19:20:22.666222 192.168.1.1 > 192.168.1.2: (frag 29741:1480@2960+)
19:20:22.666342 192.168.1.1 > 192.168.1.2: (frag 29741:1480@4440+)
19:20:22.666467 192.168.1.1 > 192.168.1.2: (frag 29741:1480@5920+)
19:20:23.360031 192.168.1.2.1301891238 > 192.168.30.1.2049: 116 read fh 
0,24/3019440128 [|nfs] (DF)
19:20:23.361095 192.168.1.1 > 192.168.1.2: (frag 29741:928@7400)
19:20:23.361114 192.168.1.1.2049 > 192.168.1.2.1301891238: reply ok 1472 (frag 
29742:1480@0+)
19:20:23.361224 192.168.1.1 > 192.168.1.2: (frag 29742:1480@1480+)


Please notice the huge time lag of the last nfs reply fragment (frag 29741). 
Short after the client re-asks the server, it also gets the missing packet,
which is the last fragment of the IP Packet.

Sending ping(8) over the same link improves the performance a bit. The nfs
timeout is reduced to the time of the next ICMP echo request arriving.
So this IP packet can be seen as a reanimate packet for a lost interrupt.

There was already a Message on this list
"NFS-performance drop with 2.4.4 and 8139too"
but no result was posted. I tried the recommended patch with 2.4.5, but the
patch (for sched.c) was incompatible with 2.4.5.

It is strange to me that these effects do not happen with ftp traffic.
I perceive very good performance with ftp. Maybe because ftp is not using
fragmented IP packets.

any ideas?

PS:
I have a second linux client, with almost the same configuration (8139too) and
the same kernel (identical binary). On this host, the effects are also
existent, but happen far less often as with the reported host.
Even more confusing.
-- 
Eduard Hasenleithner
student of
Salzburg University of Applied Sciences and Technologies
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[OOPS] in locks_remove_posix

[Steven Walter]

Just got this oops in 2.4.5-ac2.  Can't reproduce it as of yet; if I
find a way, I'll give notice.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell

ksymoops 2.3.4 on i586 2.4.5-ac2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5-ac2/ (default)
 -m /boot/System.map-2.4.5-ac2 (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.

Warning (compare_maps): ksyms_base symbol __io_virt_debug_R__ver___io_virt_debug not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address ff14
c013ae26
*pde = 1063
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: ff0c   ebx: c66317e0   ecx:    edx: c66317e0
esi:    edi:    ebp: b5b8   esp: c1a9ff90
ds: 0018   es: 0018   ss: 0018
Process dnetc (pid: 227, stackpage=c1a9f000)
Stack: c012ad38 c66317e0 c1930200  c66317e0  c66317e0 080ed570 
   c012ad87 c66317e0 c1930200 c1a9e000 c0106aa3 0005 4000  
   080ed570  b5b8 0006 002b 002b 0006 0809a982 
Call Trace: [] [] [] 
Code: 8b 40 08 8b 40 08 8b 74 24 10 8b 90 a0 00 00 00 85 d2 74 4e 

>>EIP; c013ae26<=
Trace; c012ad38 
Trace; c012ad87 
Trace; c0106aa3 
Code;  c013ae26 
 <_EIP>:
Code;  c013ae26<=
   0:   8b 40 08  mov0x8(%eax),%eax   <=
Code;  c013ae29 
   3:   8b 40 08  mov0x8(%eax),%eax
Code;  c013ae2c 
   6:   8b 74 24 10   mov0x10(%esp,1),%esi
Code;  c013ae30 
   a:   8b 90 a0 00 00 00 mov0xa0(%eax),%edx
Code;  c013ae36 
  10:   85 d2 test   %edx,%edx
Code;  c013ae38 
  12:   74 4e je 62 <_EIP+0x62> c013ae88 



2 warnings issued.  Results may not be reliable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/