date:20010106

Re: [PATCH] new bug report script

2001-01-06 Thread Matthias Juchem

On 6 Jan 2001, Ulrich Drepper wrote:

> This is wrong.  You cannot execute libc.so.5.  This only works with
> glibc.

I already thought of something like that (I was not able to test it...).
Can you tell me a reliable way to get the version other than just looking
for the version appended to the file name?
Or is the file name scheme reliable (/lib/libc.so.5.x.y)?

Regards,
 Matthias

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

Re: [PATCH] new bug report script

2001-01-06 Thread Ulrich Drepper


Matthias Juchem <[EMAIL PROTECTED]> writes:

> +# c library 5
> +if ( -e "/lib/libc.so.5" ) {
> + ( $v_libc5 = `/lib/libc.so.5`) =~ m/GNU C Library .+ version (\S+),/;
> + $v_libc5 = $1;
> +} else {
> + $v_libc5 = "not found";
> +}

This is wrong.  You cannot execute libc.so.5.  This only works with
glibc.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] new bug report script

2001-01-06 Thread Matthias Juchem


Hi Alan,

could you please consider this patch for inclusion in your tree?

This is a patch against 2.4.0. It introduces a new bug reporting script
(scripts/bugreport.pl) that tries to simplify bug reporting for users. I
have also added a small hint to this script to REPORTING-BUGS.

To all: Please have a look at the script and give me your feedback so that
I can fix the errors and improve the script.

Kind regards,
 Matthias


diff -urN linux-2.4.0-vanilla/REPORTING-BUGS linux-2.4.0-mod/REPORTING-BUGS
--- linux-2.4.0-vanilla/REPORTING-BUGS  Mon Aug 21 17:57:35 2000
+++ linux-2.4.0-mod/REPORTING-BUGS  Sun Jan  7 08:20:21 2001
@@ -25,7 +25,16 @@
 overlook things, and easier for the developers to find the pieces of
 information they're really interested in. Don't feel you have to follow it.

-   First run the ver_linux script included as scripts/ver_linux or
+There are two possibilities:
+ a) use the new problem reporting script
+ b) collect the information and write the report by hand
+
+a)  The problem reporting script resides under scripts/bugreport.pl
+Use it like this: "perl bugreport.pl filename", where filename is where the
+report is written to. This results (hopefully) in a usable problem report that
+you can add additional info to.
+
+b)  First run the ver_linux script included as scripts/ver_linux or
 at ftp://ftp.sai.msu.su/pub/Linux/ver_linux> It checks out
 the version of some important subsystems.  Run it with the command
 "sh scripts/ver_linux"
diff -urN linux-2.4.0-vanilla/scripts/bugreport.pl linux-2.4.0-mod/scripts/bugreport.pl
--- linux-2.4.0-vanilla/scripts/bugreport.plThu Jan  1 01:00:00 1970
+++ linux-2.4.0-mod/scripts/bugreport.plSun Jan  7 08:23:13 2001
@@ -0,0 +1,401 @@
+#!/usr/bin/perl -w
+
+# bugreport.pl
+# created by Matthias Juchem <[EMAIL PROTECTED]> Januar 2001
+#
+# collects system information and tries to help with generating bug
+# reports for linux-kernel
+# - prompts for general information about the problem
+# - acquires system information from various programs and from /proc
+# - runs the oops through ksymoops
+#
+# For notes view bottom of file
+
+use strict;
+use FileHandle;
+use IPC::Open2;
+
+# variables ##
+
+# bug report
+my $summary; my $description;  my $keywords;
+my $oops;my $other_notes;  my $example;
+
+# program versions
+my $v_kernel;my $v_gcc;my $v_modules;
+my $v_make;  my $v_binutils;   my $v_libc5;
+my $v_libc6; my $v_libcpp; my $v_ldd;
+my $v_procps;my $v_procinfo;   my $v_psmisc;
+my $v_mount; my $v_nettools;   my $v_pppd;
+my $v_kbd;   my $v_shutils;my $v_utillinux;
+my $v_e2fsprogs; my $v_bash;
+
+# other sys info
+my $loaded_modules;  my $cpuinfo;  my $iomem;
+my $ioports; my $scsi; my $pci;
+
+# forward declarations ###
+
+sub init();  # get system info to initialize variables with
+sub enter_report();  # gather information about bug
+sub print_report($); # parameter: filename for output
+sub getline($$); # read a line from STDIN, params: prompt, default value
+sub gettext($);  # read multiple lines from STDIN, param: prompt
+sub readfile($); # returna content of file one line, param: filename
+sub exists_prog($);  # returns full path of programm or empty string
+
+# main ###
+
+{
+print "\nbugreport.pl - Linux Kernel Problem Report Generator v0.1\n";
+print "=\n";
+print "   written by Matthias Juchem \n\n";
+
+# check euid
+if ( $> != 0 ) {
+   print "\nThis script should be run as root.\n\n";
+   exit 1;
+}
+
+# check output filename
+my $filename;
+if ( not ( $filename = shift )) {
+   print "\nPlease specify a file for output.\n\n";
+   exit 2;
+}
+
+init();
+enter_report();
+print_report($filename);
+
+print <<"EOF";
+Please spend a few minutes on reading the generated problem report, check the
+version string that look strange and include further information as you like.
+
+If you think the report is good, send it to the maintainer (see MAINTAINERS)
+of the corresponding subsystem and a copy to .
+
+Any bug reports and comments _for_this_script_ go to .
+Thank you.
+
+EOF
+
+}
+
+# subroutines 
+
+sub print_report($) {
+my $fn = shift;
+
+print( "\nPlease wait while the report is being generated and written to",
+  " the specified\nfile (",$fn,")...\n" );
+# run the oops through ksymoops
+if ( exists_prog("ksymoops") ) {
+#open2( \*READER, \*WRITER, "ksymoops -V -k /proc/ksyms -l /proc/modules -o 
+/lib/modules/2.4.0/ -m /usr/src/linux/System.map" );
+   open2( \*READER, \*WRITER, "ksymoo

Re: ramfs problem... (unlink of sparse file in "D" state)

2001-01-06 Thread Eric W. Biederman

Chris Wedgwood <[EMAIL PROTECTED]> writes:

> On Sat, Jan 06, 2001 at 03:58:20PM +, Alan Cox wrote:
> 
> Ext2 handles large files almost properly. (properly on 2.2 +
> patches) NFSv3 handles large files but might be missing the
> O_LARGEFILE check.  I believe reiserfs went to at least 4Gig.
> 
> reiserfs 3.6.x under 2.4.x should go much higher unless i am reading
> something wrong
> 
> 
> 
> yup, it does.
> 
> 
> as for NFS, I'm not sure how to pass O_LARGEFILE via the protocol and
> since NFS isn't really POSIX like anyhow decided we might as well
> just ingore it and have all sys_open calls for NFS look like
> O_LARGEFILE was specified

Umm.  No.  The object of LFS stuff is so that programs that can't
handle large files don't shoot themselves in the foot.  You don't
need to pass O_LARGEFILE over the protocol and knfsd doesn't need
to handle it.  But with out specifying O_LARGEFILE you should
be limited to 2GB on 32bit systems.

Moving some of the LFS checks into the VFS does sound good.  

When I looked at one of the BSD's a while ago, they had
a max file size in (the superblock?) and the VFS did basic
max file size checking.  And I think it handled all of the LFS
API at the VFS layer as well.  Alan these are two seperate
but related issues.

Putting the LFS checks, & max filesize checks into the VFS sounds
right for 2.4.x because it fixes lots of filesystems, with just a
couple of lines of code. 

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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!) (Benchmarks)

2001-01-06 Thread Andi Kleen


On Sun, Jan 07, 2001 at 01:11:11AM -0700, Ben Greear wrote:
> > Packet socket binding or SO_BINDTODEVICE will search the list, but it is unlikely
> > that these paths are worth optimizing for.
> 
> The patch has been written, so even if it helps just a little more than it
> hurts, it might be worth including.  Of course, it may actually hurt more
> than help.
> 
> I'd be very interested in lucid arguments as to why adding the patch would
> actually be worse than not adding it, not just why I'm lame for considering
> it *grin* :)

It's like David said: it's not a very good idea to tune things that are not
commonly used. If some user really realistically has some workload where the
linear search is a bottleneck it can be considered. Currently it doesn't look
like it.




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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!) (Benchmarks)

2001-01-06 Thread Ben Greear

Andi Kleen wrote:

> > I'm willing to run such benchmarks, but what would make a good benchmark,
> > other than ifconfig -a?
> 
> ifconfig -a is fine IMHO. Everything else I know is just a single pass through
> the lists (which even at 4000 is not very significant)

Hardware:  Celeron 500, mostly idle (ie not too scientific!!)
ifconfig:
  [root@candle bin]# /sbin/ifconfig --version
  net-tools 1.57
  ifconfig 1.40 (2000-05-21)
(vlan_test.pl is attached)

My conclusion:  The patch definately helps in this instance, but
  this instance may not be realistic.

***
This is with the hash patch enabled: (2.4.prerelease + VLAN patch) (run 2)
***

[root@candle bin]# time vlan_test.pl 
Adding VLAN interfaces 1 through 4000
Done adding 4000 VLAN interfaces in 76 seconds.
Doing ifconfig -a
10.47user 6.33system 0:16.80elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (116major+421minor)pagefaults 0swaps
Removing VLAN interfaces 1 through 4000
Done deleting 4000 VLAN interfaces in 58 seconds.

Going to add and remove 2 interfaces 1000 times.
Done adding/removing 2 VLAN interfaces 1000 times in 46 seconds.
74.12user 115.26system 3:22.81elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2821121major+677780minor)pagefaults 0swaps

***
This is with the patch disabled: (2.4.0 + VLAN patch) (run 1)
***

[root@candle /root]# time vlan_test.pl
Adding VLAN interfaces 1 through 4000
Done adding 4000 VLAN interfaces in 132 seconds.
Doing ifconfig -a
10.72user 96.31system 1:55.31elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (117major+423minor)pagefaults 0swaps
Removing VLAN interfaces 1 through 4000
Done deleting 4000 VLAN interfaces in 65 seconds.

Going to add and remove 2 interfaces 1000 times.
Done adding/removing 2 VLAN interfaces 1000 times in 47 seconds.
74.20user 257.83system 6:04.46elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2821122major+677782minor)pagefaults 0swaps

***
This is with the patch enabled: (2.4.0 + VLAN patch) (run 1)
***

[root@candle /root]# time vlan_test.pl
Adding VLAN interfaces 1 through 4000
Done adding 4000 VLAN interfaces in 83 seconds.
Doing ifconfig -a
10.61user 10.22system 0:23.43elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (117major+423minor)pagefaults 0swaps
Removing VLAN interfaces 1 through 4000
Done deleting 4000 VLAN interfaces in 64 seconds.

Going to add and remove 2 interfaces 1000 times.
Done adding/removing 2 VLAN interfaces 1000 times in 47 seconds.
73.69user 120.69system 3:44.10elapsed 86%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2821122major+677782minor)pagefaults 0swaps

***
This is with the patch enabled: (2.4.0 + VLAN patch) (run 2)
***

[root@candle /root]# time vlan_test.pl
Adding VLAN interfaces 1 through 4000
Done adding 4000 VLAN interfaces in 80 seconds.
Doing ifconfig -a
10.62user 6.31system 0:18.63elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (117major+423minor)pagefaults 0swaps
Removing VLAN interfaces 1 through 4000
Done deleting 4000 VLAN interfaces in 61 seconds.

Going to add and remove 2 interfaces 1000 times.
Done adding/removing 2 VLAN interfaces 4000 times in 47 seconds.
74.05user 114.93system 3:33.00elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2821122major+677782minor)pagefaults 0swaps

> 
> > Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
> > before that one!!).  Currently, that means a linear search on all devices,
> > right?  In that extreme example, I would expect the hash to be very
> > useful.
> 
> Nope, it doesn't. Raw binding works via IP addresses, and the IP address resolution
> works via the routing table, which is extensively hashed.

Ahh, I meant raw, like raw Ethernet.  True, not used very often,
but I happen to have been using it lately :)

The original idea for the hashing came after I was severly chastised by a few
for even considering allowing 4000 VLAN Interfaces into the kernel.  The
complaint was that somehow having lots of devices was going to hurt performance.

The eventual conclusion (by me at least), was that there were no linear
lookups in any critical path I could think of.  However, things like
binding to interfaces, and searching for them (ifconfig -i vlan3999),
were doing (at least) linear searching, so hashing it might make the
user happier.

> 
> Packet socket binding or SO_BINDTODEVICE will search the list, but it is

2.2.18: your CPUs had inconsistent variable MTRR setting

2001-01-06 Thread Haavard Lygre



During boot of 2.2.18 I get the following messages:

mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs

Is this something I should worry about?


This is an MSI 694D Pro AI mainboard, with dual P-III 800EB processors
and 320Mb RAM, stock 2.2.18 kernel.

More info available upon request.


-- 
Håvard Lygre, [EMAIL PROTECTED]
Bergen IT-Teknikk ANS, Conrad Mohrsvei 11, 5068 Bergen
Tlf: 55 360773  Fax: 55 360774
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ftruncate returning EPERM on vfat filesystem

2001-01-06 Thread Dave



Hi everyone,

I experienced a strange problem after upgrading from 2.4.0-test12 to the
2.4.0 kernel.  My samba configuration stopped working.  Reverting back to
2.4.0-test12, it magically starts working again.

(2.4.0 also hard-locked my machine before I noticed this problem, but
I'll report that later when I work out why.)

I share a local vfat filesystem to a windows machine.  With 2.4.0, the
client kept randomly reporting "...Access is denied.. Make sure the disk
is not full or write-protected..." when transferring files to this
machine.  After much cursing and hair-pulling, I straced samba under both
kernels, and found out that ftruncate was returning EPERM under 2.4.0.

After diffing between 2.4.0-test12 and 2.4.0, i found this little chunk
in fat_notify_change() which may explain the problem:

diff -u --new-file --recursive linux-2.4.0-test12/fs/fat/inode.c 
linux-2.4.0/fs/fat/inode.c
--- linux-2.4.0-test12/fs/fat/inode.c   Tue Dec  5 13:00:44 2000
+++ linux-2.4.0/fs/fat/inode.c  Mon Jan  1 05:02:21 2001
@@ -903,6 +903,12 @@
struct super_block *sb = dentry->d_sb;
struct inode *inode = dentry->d_inode;
int error;
+
+   /* FAT cannot truncate to a longer file */
+   if (attr->ia_valid & ATTR_SIZE) {
+   if (attr->ia_size > inode->i_size)
+   return -EPERM;
+   }

error = inode_change_ok(inode, attr);
if (error)

Can someone tell me if this is the cause of my samba problems, and if
so, why this was added and if this is safe to revert?

TIA.

David.

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

Patch (repost): cramfs memory corruption fix

2001-01-06 Thread Adam J. Richter


>From: "David L. Parsley" <[EMAIL PROTECTED]>
>
>Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it
>tries to boot.  Even more bizarre, if cramfs is compiled in the kernel
>when I use a romfs root, it says 'wrong magic' then mounts the romfs but
>can't find init.  If I take cramfs out of the kernel, the romfs mounts &
>init runs fine.  I just saw this with ac3.
>
>ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a
>file in ac2 and ac3.  Works fine in 2.4.0 vanilla.  Should be quite
>repeatable...

This sounds like a bug that I posted a fix for a long time ago.
cramfs calls bforget on the superblock area, destroying that block of
the ramdisk, even when the ramdisk does not contain a cramfs file system.
Normally, bforget is called on block that really can be trashed,
such as blocks release by truncate or unlink.  If it worked for
you before, you were just getting lucky.  Here is the patch.

Linus, please consider applying this.  Thank you.

By the way, the other approach to fixing this problem would
be to change bforget not to trash blocks marked with BH_Protected
(I think that is just ramdisk blocks), but that would waste memory,
because we really can release blocks from things like truncating
or unlinking files.

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


--- /tmp/adam/linux-2.4.0/fs/cramfs/inode.c Fri Dec 29 14:07:57 2000
+++ linux/fs/cramfs/inode.c Sat Dec 30 02:12:06 2000
@@ -138,7 +138,7 @@
struct buffer_head * bh = bh_array[i];
if (bh) {
memcpy(data, bh->b_data, PAGE_CACHE_SIZE);
-   bforget(bh);
+   brelse(bh);
} else
memset(data, 0, PAGE_CACHE_SIZE);
data += PAGE_CACHE_SIZE;

new kernel mm

2001-01-06 Thread david


hi all

can i rewrite the mm system in kernel's 2.2.18 to add new and needed
functions
or may be it can be a compile option old (mm system or new mm system)
?

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

Re: devfs breakage in 2.4.0 release

2001-01-06 Thread Adam J. Richter


On my Sony PictureBook PCG-C1VN, 2.4.0 hangs in the boot
process while 2.4.0-prerelease boots just fine.  At first I thought
the problem was devfs-related, but skipping devfsd just caused the
hang to occur a little later, this time in ifconfig.  The kernel
call trace looked something like this:

neigh_ifdown
sys_ioctl
sock_ioctl
[some addresses in modules]
stext_lock
__down_failed
__down

What surprised me more was that attempting to remount the
root filesystem for writing just before this (to record the module
kernel symbols) caused a kenel BUG() in slab.c:1542 becuase kmalloc
was being called with a huge negative number.

I know I could run ksymoops to get this trace, but I now
think the cause of the problem probably happens much earlier than
the symptoms.  So, I trying backing out different 2.4.0 changes.
So far, I can tell you that reverting the linux/mm subdirectory to
its 2.4.0-prerelease contents had no effect.  I will let you know
if I diagnose or fix the problem, as I think you may be experiencing
the same problem.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: uClinux 2.4.0.0pre0 released.

2001-01-06 Thread Aaron Lehmann


On Sat, Jan 06, 2001 at 12:25:36AM -0500, D. Jeff Dionne wrote:
> uClinux 2.4.0.0pre0 is out.  It is on www.uclinux.org and cvs.uclinux.org

I don't think this matters much, but I noticed that several of the
features available in the kernel configuration aren't relevent to 68k.
For example, in arch/m68knommu/config.in:

bool 'SGI Visual Workstation support' CONFIG_VISWS
bool 'PCI support' CONFIG_PCI
bool 'MCA support' CONFIG_MCA
bool 'Power Management support' CONFIG_PM


 PGP signature

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)

2001-01-06 Thread David S. Miller

   Date:   Sat, 6 Jan 2001 23:00:10 -0500 (EST)
   From: jamal <[EMAIL PROTECTED]>

   I think someone should just flush ifconfig down some toilet. a wrapper
   around "ip" to to give the same look and feel as ifconfig would be a good
   thing so that some stupid program that depends on ifconfig look and feel
   would be a good start.

I could not agree more.  This reminds me to do something I could not
justify before, making netlink be enabled in the kernel and
non-configurable.

I could almost, but not quite, justify it right now just because "ip"
is becomming standard and needs it.

   Not to stray from the subject, Ben's effort is still needed. I think real
   numbers are useful instead of claims like it "displayed faster"

See my previous email, if it's just slow because of some poorly coded
version of ifconfig, it does not justify the patch.  If only a
forcefully created "benchmark" can show some performance problem, that
is not an acceptable reason to champion this patch.  Ok?

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread David S. Miller



   On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:

   I'm hoping that I can get a few comments on this code.  It was
   added to (significantly) speed up things like 'ifconfig -a' when
   running with 4000 or so VLAN devices.  It should also help other
   instances with lots of (virtual) devices, like FrameRelay, ATM,
   and possibly virtual IP interfaces.  It probably won't help
   'normal' users much, and in it's final form, should probably be a
   selectable option in the config process.

Ben, if ifconfig uses /proc/net/dev to list devices, how can your
changes speed up ifconfig?  Andi mentioned in another email how he has
fixed the quadratic behavior in ifconfig, you should check if it fixes
your problem.  Jamal has suggested dumping ifconfig and making a dummy
"ifconfig" which just wrappers around "ip".  I like this idea the most.

Really, what I'm concerned about is what calls dev_get_by_{name,index}
so often and in such critical places that optimizing it makes any
sense?

I don't mind optimizing stuff like this where needed, in fact I'm the
most guilty of this, check out the complex TCP hash tables we have :-)
But if it's only a problem because of poorly implemented user
applications, let's fix the apps instead of adding the complexity to
the kernel.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

file ops in kernel

2001-01-06 Thread david


hi all

i now need to read a file from in the kernel 2.2.x
dose any one know how to this ?

thank you

David Rundle <[EMAIL PROTECTED]>

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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread David S. Miller

   Date: Sat, 06 Jan 2001 21:06:54 -0700
   From: Ben Greear <[EMAIL PROTECTED]>

   "David S. Miller" wrote:
   > 
   > Unified diffs only please... Thanks.

   Hrm, here's one with a -u option, this what you're looking for?

Yes, thanks a lot.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP

2001-01-06 Thread Hans Grobler


On Sat, 6 Jan 2001, mull wrote:
> On Sat, Jan 06, 2001 at 09:26:55PM -, Craig Freeze wrote:
> > [1.] One line summary of the problem:
> > SCSI hangs with aic7xxx in 2.4.0 SMP
> >
> > [2.] Full description of the problem/report:
> > SCSI device errors and bus resets observed in 2.4.0 that do not occur in
> > 2.2.13.  Sysrq keys have no effect (ie hard reset required to recover)
> >
> I've noticed pretty much the same situation on my uniproc box, aic7xxx driver,
> adaptec 2940uw card since going to 2.4.0-prerelease. haven't had to hard
> reset, but have seen a LOT of scsi timeout errors. i did not notice this
> on 2.4.0-test12 or test13pre2. when i'm at home i'll see if i can find
> any pattern or more info, and also test with 2.4.0 final.
> mullein

I have not seen any such problems, even under very high loads. Would
you please submit a detailed bug report (such as the previous poster)
using the guidelines in REPORTING-BUGS.

Thanks,
-- Hans


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

Re: What test suites can you tell me about?

2001-01-06 Thread Dan Kegel


Michael D. Crawford ([EMAIL PROTECTED]) asked:
> Can you tell me about any ready-to-use test suites, 
> for any software package that should run under Linux, 
> that I can build and run to test the new kernel? 

The LSB has a set of test suites it has gathered for Linux itself;
see http://www.linuxbase.org/test/

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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)

2001-01-06 Thread Andi Kleen


On Sat, Jan 06, 2001 at 11:24:41PM -0700, Ben Greear wrote:
> jamal wrote:
> > 
> 
> > Not to stray from the subject, Ben's effort is still needed. I think real
> > numbers are useful instead of claims like it "displayed faster"
> 
> A single #define near the top of the patch will turn it on/off, so
> benchmarking should be fairly easy.  Please suggest benchmarks you
> consider valid.

The only issue I know was the long delay in ifconfig.
If that's fixed I see nothing else that would be worth benchmarking. 


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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Andi Kleen


On Sat, Jan 06, 2001 at 11:22:41PM -0700, Ben Greear wrote:
> At the time I was doing this, I downloaded the latest nettools version.
> The hashing made a very noticable difference on 4000 interfaces, but
> I haven't run any real solid benchmarkings at other levels.  Can
> you tell me some distinguishing mark (version?) on ifconfig that I
> can look for?

Just get the latest release.

> 
> I'm willing to run such benchmarks, but what would make a good benchmark,
> other than ifconfig -a?

ifconfig -a is fine IMHO. Everything else I know is just a single pass through
the lists (which even at 4000 is not very significant) 

> Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
> before that one!!).  Currently, that means a linear search on all devices,
> right?  In that extreme example, I would expect the hash to be very
> useful.

Nope, it doesn't. Raw binding works via IP addresses, and the IP address resolution
works via the routing table, which is extensively hashed.

Packet socket binding or SO_BINDTODEVICE will search the list, but it is unlikely
that these paths are worth optimizing for.


> Binding to IP addresses have the same issue??

No, uses the fib.

> Also, though hashing by name is not horribly exact, hashing on the device
> index should be nearly perfect, so finding device 666 might take a search
> through only 5 or so devices (find the hash-bucket, walk down the list in
> that bucket).

Just why? It is not in any critical path I can see at all. 


-Andi

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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)

2001-01-06 Thread Ben Greear


jamal wrote:
> 

> Not to stray from the subject, Ben's effort is still needed. I think real
> numbers are useful instead of claims like it "displayed faster"

A single #define near the top of the patch will turn it on/off, so
benchmarking should be fairly easy.  Please suggest benchmarks you
consider valid.

Thanks,
Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Ben Greear

Andi Kleen wrote:
> 
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> > I'm hoping that I can get a few comments on this code.  It was added
> > to (significantly) speed up things like 'ifconfig -a' when running with
> > 4000 or so VLAN devices.  It should also help other instances with lots
> > of (virtual) devices, like FrameRelay, ATM, and possibly virtual IP
> > interfaces.  It probably won't help 'normal' users much, and in it's final
> > form, should probably be a selectable option in the config process.
> >
> > Anyway, let me know what you think!
> 
> Does it make any significant different with the ifconfig from newest nettools? I
> removed a quadratic algorithm from ifconfig's device parsing, and with that I was
> able to display a few thousand alias devices on a unpatched kernel in reasonable 
>time.
> 
> -Andi

At the time I was doing this, I downloaded the latest nettools version.
The hashing made a very noticable difference on 4000 interfaces, but
I haven't run any real solid benchmarkings at other levels.  Can
you tell me some distinguishing mark (version?) on ifconfig that I
can look for?

I'm willing to run such benchmarks, but what would make a good benchmark,
other than ifconfig -a?

And a question for the socket gurus:

Suppose I bind a raw socket to device vlan4001 (ie I have 4k in the list
before that one!!).  Currently, that means a linear search on all devices,
right?  In that extreme example, I would expect the hash to be very
useful.

Binding to IP addresses have the same issue??

Also, though hashing by name is not horribly exact, hashing on the device
index should be nearly perfect, so finding device 666 might take a search
through only 5 or so devices (find the hash-bucket, walk down the list in
that bucket).

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Ben Greear


Chris Wedgwood wrote:
> 
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> 
> I'm hoping that I can get a few comments on this code.  It was
> added to (significantly) speed up things like 'ifconfig -a' when
> running with 4000 or so VLAN devices.  It should also help other
> instances with lots of (virtual) devices, like FrameRelay, ATM,
> and possibly virtual IP interfaces.  It probably won't help
> 'normal' users much, and in it's final form, should probably be a
> selectable option in the config process.
> 
> Virtual IP interfaces in the form of ifname: (e.g. eth:1) IMO
> should be deprecated and removed completely in 2.5.x. It's an ugly
> external wart that should be removed.

I don't know enough to have any serious opinion about virtual IP
interfaces, but I am very certain that VLANs should appear as
an interface to external code/user-land, just as eth0 does.

This hashing helps with VLANs, and since I aim to get VLANs into
the kernel proper sooner or later, having this piece in there
makes my patch a little smaller :)

However, if folks look at the patch and hate it, then it can
be left out, or changed appropriately.

Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel compile trouble

2001-01-06 Thread Tom Leete


Johan Groth wrote:
> 
> Hi,
> I wonder if anyone can help me with compilation of kernel 2.4.0. I've
> run make mrproper; make menuconfig; make dep and then I try to build the
> kernel with make bzImage but that fails utterly. I get the following
> message:
[...]
> /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d':
> /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use
> in this function)
> /usr/src/linux/include/asm/string.h: In function `__memcpy3d':
> /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use
> in this function)
> make: *** [init/main.o] Error 1
> 

Hello,

You don't show your .config, but I'll make a wild guess you're compiling for
SMP+3DNow (probably by selecting Athlon processor). If so pick one of:
a) Deselect SMP, make clean make dep, etc.
b) Downgrade processor selection to i686 or k6
c) See the patch I posted here Tuesday.

Petr Vandrovec also posted a patch which takes a quite different approach.

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

[PATCH] Mostly documentation fixes

2001-01-06 Thread Dag Wieers


--- drivers/net/eepro.c.origSun Jan  7 04:34:40 2001
+++ drivers/net/eepro.c Sun Jan  7 04:35:22 2001
@@ -323,7 +323,7 @@
 allowing up to 8K worth of packets to be queued.

 The sizes of the receive and transmit buffers can now be changed via lilo
-or insmod.  Lilo uses the appended line "ether=io,irq,debug,rx-buffer,eth0"
+or insmod.  Lilo uses the appended line "ether=irq,io,debug,rx-buffer,eth0"
 where rx-buffer is in KB unit.  Modules uses the parameter mem which is
 also in KB unit, for example "insmod io=io-address irq=0 mem=rx-buffer."
 The receive buffer has to be more than 3K or less than 29K.  Otherwise,
--- Documentation/kernel-parameters.txt.origSun Jan  7 04:34:46 2001
+++ Documentation/kernel-parameters.txt Sun Jan  7 04:35:38 2001
@@ -188,7 +188,7 @@

es1371= [HW,SOUND]

-   ether=  [HW,NET] Ethernet cards parameters (iomem, irq,
+   ether=  [HW,NET] Ethernet cards parameters (irq, iomem,
dev_name).

fd_mcs= [HW,SCSI]
--- MAINTAINERS.origSun Jan  7 05:08:30 2001
+++ MAINTAINERS Sun Jan  7 05:10:18 2001
@@ -906,8 +906,8 @@
 S: Maintained

 OLYMPIC NETWORK DRIVER
-P: Peter De Shrijver
-M: [EMAIL PROTECTED]
+P: Peter De Schrijver
+M: [EMAIL PROTECTED]
 P: Mike Phillips
 M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
--- Documentation/Configure.help.orig   Sun Jan  7 03:30:14 2001
+++ Documentation/Configure.helpSun Jan  7 05:00:51 2001
@@ -1655,12 +1655,12 @@
 CONFIG_SGI_SN0_N_MODE
   The nodes of Origin 200, Origin 2000 and Onyx 2 systems can be
   configured in either N-Modes which allows for more nodes or M-Mode
-  which allows for more more memory.  Your system is most probably
+  which allows for more memory.  Your system is most probably
   running in M-Mode, so you should say N here.

 MIPS JAZZ onboard SONIC Ethernet support
 CONFIG_MIPS_JAZZ_SONIC
-  This is the driver for the onboard card of of MIPS Magnum 4000,
+  This is the driver for the onboard card of MIPS Magnum 4000,
   Acer PICA, Olivetti M700-10 and a few other identical OEM systems.

 MIPS JAZZ FAS216 SCSI support
@@ -2011,7 +2011,7 @@
 CONFIG_IP_NF_TARGET_MARK
   This option adds a `MARK' target, which allows you to create rules
   in the `mangle' table which alter the netfilter mark (nfmark) field
-  associated with the packet packet prior to routing. This can change
+  associated with the packet prior to routing. This can change
   the routing method (see `IP: use netfilter MARK value as routing
   key') and can also be used by other subsystems to change their
   behavior.
@@ -9529,7 +9529,7 @@

   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called olympic.o. If you want to compile it
+  The module will be called olympic.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

   Also read the file Documentation/networking/olympic.txt or check the
@@ -9569,7 +9569,7 @@

   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called tms380tr.o. If you want to compile it
+  The module will be called tms380tr.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

 Generic TMS380 PCI support
@@ -9584,7 +9584,7 @@

   This driver is available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called tmspci.o. If you want to compile it
+  The module will be called tmspci.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

 Madge Smart 16/4 PCI Mk2 support
@@ -9594,7 +9594,7 @@

   This driver is available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called abyss.o. If you want to compile it
+  The module will be called abyss.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

 Madge Smart 16/4 Ringode MicroChannel
@@ -9604,7 +9604,7 @@

   This driver is available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called madgemc.o. If you want to compile it
+  The module will be called madgemc.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

 SMC ISA TokenRing adapter support
@@ -9620,7 +9620,7 @@

   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
-  The module will will be called smctr.o. If you want to compile it
+  The module will be called smctr.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.

 Sun Happy

Re: posix_types.h error

2001-01-06 Thread Mike Galbraith


On Sat, 6 Jan 2001, Richard B. Johnson wrote:

Hi Richard,

> There is an error at line 80 in linux-2.4.0/include/asm/posix_types.h
> which prevents source-code from being compiled using the new C compiler
> that I was forced to install in order to build the new kernel.

Hmm.. line 80 is the last line in the file, an #endif.

What do you mean by 'forced to install..'?  gcc-2.95.2, gcc-2.95.2.1
and gcc-2.97 snapshots will build 2.4.0 (minus netfilter empty struct
initialzer glitchies).

>   gcc 2.95.3

(Only exists at mdk afaik.. RedHat didn't get enough flak?;)

> Script started on Sat Jan  6 22:16:30 2001
> # cat xxx.c
> 
> 
> #include 
> #include 
> 
> 
> main()
> {
> fd_set x;
> 
> FD_ZERO(&x);
> }
> 
> # gcc -c -o xxx.o xxx.c
> xxx.c: In function `main':
> xxx.c:11: Invalid `asm' statement:
> xxx.c:11: fixed or forbidden register 2 (cx) was spilled for class CREG.
> # vi /usr/include/asm/posix_types.h
> #ifndef __ARCH_I386_POSIX_TYPES_H
> #define __ARCH_I386_POSIX_TYPES_H
> 
> 
> 
> 
> 
> 
> 
> 
> [Snipped...]
> 
> #define __FD_ZERO(fdsetp) \
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> exit
> Script done on Sat Jan  6 22:19:03 2001
> 
> Since these inline asm statements no longer use register names, I
> don't know how to fix them. One of life's little mystries is how
> previously readable code got into this shape.

  Agreed!  That code is terribly unreadable.. down right invisible.

Seriously though, the constraints look fine to me (and the register
name is there in the output constraint).  I'd say you have a busted
compiler.  None of the named compilers gripe.

#include 

main()
{
fd_set x;

__FD_ZERO(&x);
}

.file   "xxx.c"
.version"01.01"
gcc2_compiled.:
.text
.align 16
.globl main
.type   main,@function
main:
pushl   %ebp
xorl%eax, %eax
movl%esp, %ebp
pushl   %edi
subl$132, %esp
movl$32, %ecx
leal-136(%ebp), %edi
#APP
cld ; rep ; stosl
#NO_APP
addl$132, %esp
popl%edi
popl%ebp
ret
.Lfe1:
.size   main,.Lfe1-main
.ident  "GCC: (GNU) gcc-2.97 20001225 (experimental)"

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

Re: [Newbie]Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

2001-01-06 Thread dep


On Saturday 06 January 2001 10:30 pm, Alan Olsen wrote:

| AGPGART doe *not* work if compiled statically.  Compile it as a
| module. You will be much happier. (i.e. It might actually work.)  I
| would also compile DRM and the r128 drivers as modules as well.

it's worked fine compiled into the kernel here, along with the dri 
and mga stuff since test4.

-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Andi Kleen

On Sat, Jan 06, 2001 at 11:00:10PM -0500, jamal wrote:
> Not to stray from the subject, Ben's effort is still needed. I think real
> numbers are useful instead of claims like it "displayed faster"

The problem with old ifconfig was really visible, old ifconfig needed several
minutes to setup. It was slow enough that "visual benchmarking" worked very well.
With the fixed ifconfig it scrolls without too annoying delays.

The ifconfig could be tuned even more by adding a hash table, but it didn't look
necessary (and frankly nobody wants to invest too much work into it, given
that ip is far superior) 

Note that the alias case is different from thousands of devices -- alias works
via SIOCGIFCONF while devices work via /proc/net/dev. 

-Andi

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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)

2001-01-06 Thread jamal

On Sun, 7 Jan 2001, Andi Kleen wrote:

> Does it make any significant different with the ifconfig from newest nettools? I
> removed a quadratic algorithm from ifconfig's device parsing, and with that I was
> able to display a few thousand alias devices on a unpatched kernel in reasonable 
>time.

I think someone should just flush ifconfig down some toilet. a wrapper
around "ip" to to give the same look and feel as ifconfig would be a good
thing so that some stupid program that depends on ifconfig look and feel
would be a good start.

Not to stray from the subject, Ben's effort is still needed. I think real
numbers are useful instead of claims like it "displayed faster"

cheers,
jamal

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

cramfs & ramfs problems in 2.4.0 up to ac3

2001-01-06 Thread David L. Parsley


Hi,

Using root=/dev/ram0 and a cramfs initrd gives me 'wrong magic' when it
tries to boot.  Even more bizarre, if cramfs is compiled in the kernel
when I use a romfs root, it says 'wrong magic' then mounts the romfs but
can't find init.  If I take cramfs out of the kernel, the romfs mounts &
init runs fine.  I just saw this with ac3.

ramfs croaks with 'kernel BUG in filemap.c line 2559' anytime I make a
file in ac2 and ac3.  Works fine in 2.4.0 vanilla.  Should be quite
repeatable...

BTW, nice work on 2.4 everyone.

regards,
David
--
David L. Parsley
Network Administrator
Roanoke College
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: New features in Linux 2.4 - Wonderful World of Linux 2.4

2001-01-06 Thread Andi Kleen


On Sat, Jan 06, 2001 at 09:41:19PM +0100, Jean-Christian de Rivaz wrote:
> Joe Pranevich wrote:
> >
> > Networking and Protocols
> >
> > ... It should also be mentioned at
> >this point that Linux is still the only operating system completely
> >compatible with the letter of the IPv4 specification ...
> 
> I am very interesting about the proof of this. I work on a project witch
> need to be certified. Any informations about the compliance of Linux to
> some specification is very welcome.

It's very dubious at least. AFAIK no RFC1122/RFC1812 evulation has been done recently
(since 2.0 or so). Also part of these RFCs have been superseeded by later RFCs
that have not reached Internet standard status yet, so it would not be very useful
anyways (today's internet looks very different from 1989's when 1122 was written) 

The mechanism the comment refers to (asynchronous error notification for UDP, which
is not in traditional BSD) is not used by 99.9% of all apps BTW ;) 


-Andi

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

posix_types.h error

2001-01-06 Thread Richard B. Johnson



There is an error at line 80 in linux-2.4.0/include/asm/posix_types.h
which prevents source-code from being compiled using the new C compiler
that I was forced to install in order to build the new kernel.

gcc 2.95.3

Script started on Sat Jan  6 22:16:30 2001
# cat xxx.c


#include 
#include 


main()
{
fd_set x;

FD_ZERO(&x);
}

# gcc -c -o xxx.o xxx.c
xxx.c: In function `main':
xxx.c:11: Invalid `asm' statement:
xxx.c:11: fixed or forbidden register 2 (cx) was spilled for class CREG.
# vi /usr/include/asm/posix_types.h
#ifndef __ARCH_I386_POSIX_TYPES_H
#define __ARCH_I386_POSIX_TYPES_H

[K

[K/*

[K * This file is generally used by user-level software, so you need to

[K * be a little careful about namespace pollution etc.  Also, we cannot

[K * assume GCC is being used.

[K */

[K

[Ktypedef unsigned short  __kernel_dev_t;
[Snipped...]

#define __FD_ZERO(fdsetp) \

[Kdo { \

[Kint __d0, __d1; \

[K__asm__ __volatile__("cld ; rep ; stosl" \

[K:"=m" (*(__kernel_fd_set *) (fdsetp)), \

[K  "=&c" (__d0), "=&D" (__d1) \

[K:"a" (0), "1" (__FDSET_LONGS), \

[K"2" ((__kernel_fd_set *) (fdsetp)) : "memory"); \

[K} while (0)

[K

[K#endif /* defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) */

[K

exit
Script done on Sat Jan  6 22:19:03 2001

Since these inline asm statements no longer use register names, I
don't know how to fix them. One of life's little mystries is how
previously readable code got into this shape.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Andi Kleen


On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> I'm hoping that I can get a few comments on this code.  It was added
> to (significantly) speed up things like 'ifconfig -a' when running with
> 4000 or so VLAN devices.  It should also help other instances with lots
> of (virtual) devices, like FrameRelay, ATM, and possibly virtual IP
> interfaces.  It probably won't help 'normal' users much, and in it's final
> form, should probably be a selectable option in the config process.
> 
> Anyway, let me know what you think!

Does it make any significant different with the ifconfig from newest nettools? I 
removed a quadratic algorithm from ifconfig's device parsing, and with that I was 
able to display a few thousand alias devices on a unpatched kernel in reasonable time.



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

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

2001-01-06 Thread Alan Olsen

On Sat, 6 Jan 2001, Michael D. Crawford wrote:

> AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
> as modules.

AGPGART doe *not* work if compiled statically.  Compile it as a module.
You will be much happier. (i.e. It might actually work.)  I would also
compile DRM and the r128 drivers as modules as well.

[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply
Alan Olsen| to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

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

[PATCH] mptctl.c memory leak on failure

2001-01-06 Thread Arnaldo Carvalho de Melo


Hi,

Please consider applying this patch. And I got confused by the
kmalloc and the comment: the buffer is used for DMA but the kmalloc doesn't
has GFP_DMA, maybe I'm missing something here, its about time for me to
sleep 8) but if it doesn't needs DMA you should consider using vmalloc and
you'll get rid of the 32 pages limitation, like I did for wanrouter that
used kmalloc but didn't needed DMA, so I've changed it to vmalloc as per
Alan's cluebating^Wsuggestion at the time 8)

- Arnaldo

--- linux-2.4.0-ac3/drivers/message/fusion/mptctl.c Sat Jan  6 23:13:11 2001
+++ linux-2.4.0-ac3.acme/drivers/message/fusion/mptctl.cSun Jan  7 01:02:52 
+2001
@@ -290,6 +290,7 @@
dma_addr_t   fwbuf_dma;
FWDownloadTCSGE_t   *fwVoodoo;
SGEAllUnion_t   *fwSgl;
+   int ret;
 
dprintk((KERN_INFO "mptctl_do_fwdl called. mptctl_id = %xh.\n", mptctl_id)); 
//tc
 
@@ -309,20 +310,22 @@
}
 //dprintk((KERN_INFO "DbG: fwbuf   = %p\n", fwbuf));
 
+   ret = -EFAULT;
if (copy_from_user(fwbuf, ufwbuf, fwlen) < 0) {
printk(KERN_ERR "%s@%d::_ioctl_fwdl - "
"Unable to copy f/w buffer @ %p\n",
__FILE__, __LINE__, (void*)ufwbuf);
-   return -EFAULT;
+   goto out;
}
 
/* Perform Firmware download.
 */
 
+   ret = -ENXIO; /* (-6) No such device or address */
if ((ioc = mpt_verify_adapter(ioc, &iocp)) < 0) {
printk("%s@%d::_ioctl_fwdl - ioc%d not found!\n",
__FILE__, __LINE__, ioc);
-   return -ENXIO;/* (-6) No such device or address */
+   goto out;
}
 
mf = MptGetMsgFrame(mptctl_id, ioc);
@@ -373,8 +376,9 @@
   "In ReplyMsg loop - iteration %d\n",
   foo)); //tc
}
+   ret = -ETIME;
if (++foo > 6000)
-   return -ETIME;
+   goto out;
mb();
schedule();
barrier();
@@ -402,6 +406,9 @@
printk(KERN_WARNING MYNAM ": (bad VooDoo):\n");
return -ENOMSG;
}
+   return 0;
+out:   kfree(fwbuf);
+   return ret;
 }
 
 /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Typo in drivers/video/vesafb.c for 2.4.0-ac3

2001-01-06 Thread Dag Wieers


Hi,

Due to a typo in vesafb_init, compiling failes.

Here's more information:

--- drivers/video/vesafb.c.orig Sun Jan  7 03:59:45 2001
+++ drivers/video/vesafb.c  Sun Jan  7 03:59:52 2001
@@ -637,7 +637,7 @@
int temp_size = video_size;
/* Find the largest power-of-two */
while (temp_size & (temp_size - 1))
-   temp_sze &= (temp_size - 1);
+   temp_size &= (temp_size - 1);

 /* Try and find a power of two to add */
while (temp_size && mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB, 
1)==-EINVAL) {

--  dag wieers, <[EMAIL PROTECTED]>, http://mind.be/  --
Out of swap, out of luck.

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

Re: Oops in 2.4.0-ac2

2001-01-06 Thread Chris Mason




On Sunday, January 07, 2001 03:48:41 AM +0100 Daniel Phillips
<[EMAIL PROTECTED]> wrote:

> A null buffer was passed by kupdate_one_transaction (looks like a
> Reiserfs function) to __refile_buffer.  Chris?
> 

Known bug, there should be another reiserfs release soon that includes the
fix.  The problem is that another transaction can set cn->bh to null while it
is being waited on.  The fix is to let someone else refile it later.

-chris

--- linux/fs/reiserfs/journal.c.1   Fri Jan  5 15:37:12 2001
+++ linux/fs/reiserfs/journal.c Fri Jan  5 15:37:15 2001
@@ -1146,7 +1146,6 @@
 clear_bit(BLOCK_NEEDS_FLUSH, &cn->state) ;
 if (!pjl && cn->bh) {
 wait_on_buffer(cn->bh) ;
-   refile_buffer(cn->bh) ;
 }
 /* check again, someone could have logged while we scheduled */
 pjl = find_newer_jl_for_cn(cn) ;



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

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Ben Greear


"David S. Miller" wrote:
> 
> Unified diffs only please... Thanks.

Hrm, here's one with a -u option, this what you're looking for?


--- ../../../linux/net/core/dev.c   Mon Dec 11 14:29:35 2000
+++ dev.c   Sat Jan  6 14:14:10 2001
@@ -1,4 +1,4 @@
-/*
+/* -*- linux-c -*-
  * NET3Protocol independent device support routines.
  *
  * This program is free software; you can redistribute it and/or
@@ -131,9 +132,17 @@
  * and the routines to invoke.
  *
  * Why 16. Because with 16 the only overlap we get on a hash of the
- * low nibble of the protocol value is RARP/SNAP/X.25. 
+ * low nibble of the protocol value is RARP/SNAP/X.25.
+ *
+ *  NOTE:  That is no longer true with the addition of VLAN tags.  Not
+ * sure which should go first, but I bet it won't make much
+ * difference if we are running VLANs.  The good news is that
+ * this protocol won't be in the list unless compiled in, so
+ * the average user (w/out VLANs) will not be adversly affected.
+ * --BLG
  *
  * 0800IP
+ * 8100802.1Q VLAN
  * 0001802.3
  * 0002AX.25
  * 0004802.2
@@ -178,6 +187,250 @@
 #endif
 
 
+#define BENS_FAST_DEV_LOOKUP
+#ifdef BENS_FAST_DEV_LOOKUP
+/* Fash Device Lookup code.  Should give much better than
+ * linear speed when looking for devices by idx or name.
+ * --Ben ([EMAIL PROTECTED])
+ */
+#define FDL_HASH_LEN 256
+
+/* #define FDL_DEBUG */
+
+struct dev_hash_node {
+struct net_device* dev;
+struct dev_hash_node* next;
+};
+
+struct dev_hash_node* fdl_name_base[FDL_HASH_LEN];/* hashed by name */
+struct dev_hash_node* fdl_idx_base[FDL_HASH_LEN]; /* hashed by index */
+int fdl_initialized_yet = 0;
+
+/* TODO:  Make these inline methods */
+/* Nice cheesy little hash method to be used on device-names (eth0, ppp0, etc) */
+int fdl_calc_name_idx(const char* dev_name) {
+int tmp = 0;
+int i;
+#ifdef FDL_DEBUG
+printk(KERN_ERR "fdl_calc_name_idx, name: %s\n", dev_name);
+#endif
+for (i = 0; dev_name[i]; i++) {
+tmp += (int)(dev_name[i]);
+}
+if (i > 3) {
+tmp += (dev_name[i-2] * 10); /* might add a little spread to the hash 
+*/
+tmp += (dev_name[i-3] * 100); /* might add a little spread to the 
+hash */
+}
+#ifdef FDL_DEBUG
+printk(KERN_ERR "fdl_calc_name_idx, rslt: %i\n", (int)(tmp % FDL_HASH_LEN));
+#endif
+return (tmp % FDL_HASH_LEN);
+}
+
+int fdl_calc_index_idx(const int ifindex) {
+return (ifindex % FDL_HASH_LEN);
+}
+
+
+/* Better have a lock on the dev_base before calling this... */
+int __fdl_ensure_init(void) {
+#ifdef FDL_DEBUG
+printk(KERN_ERR "__fdl_ensure_init, enter\n");
+#endif
+if (! fdl_initialized_yet) {
+/* only do this once.. */
+int i;
+int idx = 0; /* into the hash table */
+struct net_device* dev = dev_base;
+struct dev_hash_node* dhn;
+
+#ifdef FDL_DEBUG
+printk(KERN_ERR "__fdl_ensure_init, doing real work...");
+#endif
+
+fdl_initialized_yet = 1; /* it has been attempted at least... */
+
+for (i = 0; iname, idx);
+#endif
+/* first, take care of the hash-by-name */
+idx = fdl_calc_name_idx(dev->name);
+dhn = kmalloc(sizeof(struct dev_hash_node), GFP_ATOMIC);
+if (dhn) {
+dhn->dev = dev;
+dhn->next = fdl_name_base[idx];
+fdl_name_base[idx] = dhn;
+}
+else {
+/* Nasty..couldn't get memory... */
+return -ENOMEM;
+}
+
+/* now, do the hash-by-idx */
+idx = fdl_calc_index_idx(dev->ifindex);
+dhn = kmalloc(sizeof(struct dev_hash_node), GFP_ATOMIC);
+if (dhn) {
+dhn->dev = dev;
+dhn->next = fdl_idx_base[idx];
+fdl_idx_base[idx] = dhn;
+}
+else {
+/* Nasty..couldn't get memory... */
+return -ENOMEM;
+}
+ 
+dev = dev->next;
+}
+fdl_initialized_yet = 2; /* initialization actually worked */
+}
+#ifdef FDL_DEBUG
+printk(KERN_ERR "__fdl_ensure_init, end, fdl_initialized_yet: %i\n", 
+fdl_initialized_yet);
+#endif
+if (fdl_initialized_yet == 2) {
+return 0;
+}
+else {
+re

Re: Oops in 2.4.0-ac2

2001-01-06 Thread Daniel Phillips


Hans-Joachim Baader wrote:
> I got an oops with 2.4.0-ac2. It said "Kernel Panic: Attempt to kill init"
> or similar. The oops didn't make it into the log but I photographed it
> and reconstructed it from the photos (USB digital cams are a great thing
> :-). After the oops, the machine was still responsive to SysRq and ping
> but nothing else.
> 
> I have Reiserfs latest version on one partition (/var).
> 
> Before the oops there were some APIC messages:
> APIC error on CPU0: 00(04)
> APIC error on CPU1: 08(08)
> and so on. Do they have anything to do with it?
> 
> Since I had high ISDN activity at this time, ISDN is a main suspect.

A null buffer was passed by kupdate_one_transaction (looks like a
Reiserfs function) to __refile_buffer.  Chris?

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

What test suites can you tell me about?

2001-01-06 Thread Michael D. Crawford


Can you tell me about any ready-to-use test suites, for any software package
that should run under Linux, that I can build and run to test the new kernel?

Besides running all these tests myself on my machine, I'm going to document them
in an article at:

http://linuxquality.sunsite.dk/articles/

(there are no articles there yet but I'm composing a couple that will be posted
soon)

For example, if you build Python (http://www.python.org) and say "make check",
it will run a bunch of python programs that test the correctness of the
programming language.

This is of interest in part because lots of the Python tests make system calls,
but also because it tests that the compilers generate correct code under the new
kernel (another test I do is, after I boot off a new kernel, I do "make clean",
build it again and boot off _that_).

"make exec" under the Mesa 3.4 library builds a bunch of graphics demos, a few
of which are kind of whizzy but most of which exercise a few basic functions in
OpenGL.  So one can watch that they don't crash, that the images look correctly
drawn and so on.  This enabled me to realize that DRI wasn't working under 2.4.0
but it was under 2.4.0-prerelease-ac5, which I've detailed in a separate
message.

Another test suite I know about comes with Kaffe (http://www.kaffe.org) and
verifies that Kaffe's implementation of Java is running correctly on your
system.

One I read about somewhere but have no clue where to get it is this memory
stress-testing tool that does lots of DMA and stuff off of the disks.

There must be a lot of these tools available, if only we had them listed all in
one place.

If you maintain such a test tool, it would be helpful if you provided the option
to run the whole suite completely unattended.  Mesa provides a good test for
lots of functions of the kernel, but one problem is that one has to quit the
tests after each one runs, usually by pressing the ESC key.  Unattended testing
also allows one to run lots of tests simultaneously to test a heavily loaded
system. 

In some cases, the tests really do need to have some user input, like navigating
around a 3D world or turning various rendering options on and off, but it's
possible the tests could be extended to allow this input from a script (Python
provides a nice way to bolt a script interpreter to any application).

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

DRI doesn't work on 2.4.0 but does on prerelease-ac5

2001-01-06 Thread Michael D. Crawford


I was testing the 2.4.0 kernel by running "make exec" in the Mesa-3.4 sources,
which builds and runs a bunch of demos, and was suprised to see one of the tests
emit a message that said DRI wasn't available.  It had been working before.

Just to make sure I then booted off of 2.4.0-prerelease-ac5 and it was working
again.

This is with XFree86 4.0.1 on Slackware 7.1.  I have an ATI Rage Millenium card
on a machine with a 667 MHz Pentium III and 128 MB of 133 MHz RAM.  The
motherboard is an ASUS P3V4X.  It has an ACPI bios but ACPI is disabled in the
config.

Could XFree86 4.0.2 fix this?  I had been waiting until the binary packages were
available from ftp.slackware.com because Patrick Volkerding lays out the
directories in a slightly different manner that he argues pretty convincingly is
preferable, but it would be a drag for me to reproduce by building it myself.
 
AGP, VIA support, DRM, and r128 DRM are all compiled in statically rather than
as modules.

In the /var/log/XFree86.0.log file I see the following under 2.4.0 final
release:

(EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x). 
Disabling DRI.
(0): [drm] failed to remove DRM signal handler
(0): failed to destroy server context
(0): [drm] removed 1 reserved context for kernel
(0): [drm] unmapping 4096 bytes of SAREA 0xc5bb3000 at 0x40014000

in the corresponding point of the same file under 2.4.0-prerelease-ac5 I have:

(II) r128(0): [agp] Mode 0x1f000203 [AGP 0x1106/0x0691; Card 0x1002/0x5246]
(II) r128(0): [agp] 8192 kB allocated with handle 0xcc82b000
(II) r128(0): [agp] ring handle = 0xe400
(II) r128(0): [agp] Ring mapped at 0x421d9000
(II) r128(0): [agp] ring read ptr handle = 0xe4101000
(II) r128(0): [agp] Ring read ptr mapped at 0x40015000
(II) r128(0): [agp] vertex buffers handle = 0xe4102000
(II) r128(0): [agp] Vertex buffers mapped at 0x422da000
(II) r128(0): [agp] indirect buffers handle = 0xe4202000
(II) r128(0): [agp] Indirect buffers mapped at 0x423da000
(II) r128(0): [agp] AGP texture map handle = 0xe4302000
(II) r128(0): [agp] AGP Texture map mapped at 0x424da000
(II) r128(0): [drm] register handle = 0xdd00
(II) r128(0): [drm] Added 64 16384 byte vertex buffers
(II) r128(0): [drm] Mapped 64 vertex buffers

The relevant parts of my .config file are as follows (and are identical between
the two kernel versions, I used "make oldconfig" and didn't change any options):

CONFIG_AGP=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_I810 is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_GAMMA is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_MGA is not set

If you want my whole .config file I could mail it in or post it on my website.

Mike

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

low-latency scheduling patch for 2.4.0

2001-01-06 Thread Andrew Morton



A patch against kernel 2.4.0 final which provides low-latency
scheduling is at

http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads

Some notes:

- Worst-case scheduling latency with *very* intense workloads is now
  0.8 milliseconds on a 500MHz uniprocessor.

  For normal workloads you can expect to achieve better than 0.5
  milliseconds for ever.  For example, worst-case latency between entry
  to an interrupt routine and activation of a usermode process during a
  `make clean && make bzImage' is 0.35 milliseconds.  This is one to
  three orders of magnitude better than BeOS, MacOS and the Windowses.

- Low latency is enabled from the `Processor type and features'
  kernel configuration menu for all architectures.  It would be nice to
  hear from non-x86 users.

- The SMP problem hasn't been addressed.  Enabling low-latency for
  SMP works well under normal workloads but comes unstuck under very
  heavy workloads.  I'll be taking a further look at this.

- The supporting tools `rtc_debug' and `amlat' have been updated. 
  These are quite useful tools for providing accurate measurement of
  latencies.  They may also be used to identify the causes of poor
  latency in the kernel.

- Remaining problem areas (the Don't Do That list) is pretty small:

  - Scrolling the fb console.
  - Running hdparm.
  - Using LILO
  - Starting the X server

- Low latency will probably only be achieved when using the ext2 and
  NFS filesystems.

- If you care about latency, be *very* cautious about upgrading to
  XFree86 4.x.  I'll cover this issue in a separate email, copied
  to the XFree team.

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

[PATCH] More compile warning fixes for 2.4.0

2001-01-06 Thread Rich Baum


Here's a patch that fixes more of the compile warnings with gcc 
2.97.

diff -urN -X dontdiff linux/drivers/atm/fore200e.c 
rb/drivers/atm/fore200e.c
--- linux/drivers/atm/fore200e.cFri Dec 29 17:35:47 2000
+++ rb/drivers/atm/fore200e.c   Sat Jan  6 14:33:42 2001
@@ -437,7 +437,7 @@
/* XXX shouldn't we *start* by deregistering the device? */
atm_dev_deregister(fore200e->atm_dev);
 
-case FORE200E_STATE_BLANK:
+case FORE200E_STATE_BLANK:;
/* nothing to do for that state */
 }
 }
diff -urN -X dontdiff linux/drivers/atm/iphase.c rb/drivers/atm/iphase.c
--- linux/drivers/atm/iphase.c  Fri Dec 29 17:35:47 2000
+++ rb/drivers/atm/iphase.c Sat Jan  6 14:33:25 2001
@@ -951,7 +951,7 @@
   SUNI_PM7345_PLB);
 #ifdef __SNMP__
suni_pm7345->suni_rxcp_intr_en_sts |= SUNI_OOCDE;
-#endif __SNMP__
+#endif /* __SNMP__ */
return;
 }
 
diff -urN -X dontdiff linux/drivers/cdrom/sbpcd.c rb/drivers/cdrom/sbpcd.c
--- linux/drivers/cdrom/sbpcd.c Fri Oct 27 01:35:48 2000
+++ rb/drivers/cdrom/sbpcd.cSat Jan  6 15:05:46 2001
@@ -338,7 +338,7 @@
 
 #ifndef SBPCD_ISSUE
 #define SBPCD_ISSUE 1
-#endif SBPCD_ISSUE
+#endif /* SBPCD_ISSUE */
 
 #include 
 
@@ -408,7 +408,7 @@
 #else
 #define SBPCD_CLI
 #define SBPCD_STI
-#endif SBPCD_DIS_IRQ
+#endif /* SBPCD_DIS_IRQ */
 /*==*/
 /*
  * auto-probing address list
@@ -466,9 +466,9 @@
0x370, 0, /* Lasermate, CI-101P */
0x290, 1, /* Soundblaster 16 */
0x310, 0, /* Lasermate, CI-101P, WDH-7001C */
-#endif MODULE
+#endif /* MODULE */
 #endif
-#endif DISTRIBUTION
+#endif /* DISTRIBUTION */
 };
 #else
 static int sbpcd[] = {CDROM_PORT, SBPRO}; /* probe with user's setup only */
@@ -557,7 +557,7 @@
  (1<0) msg(DBG_INF,"ResponseInfo: got %d trailing bytes.\n",j);
-#endif 000
+#endif /* 000 */
for (j=0;j>16)&0xFF;
drvcmd[2]=(block>>8)&0xFF;
drvcmd[3]=block&0xFF;
-#endif TEST_UPC
+#endif /* TEST_UPC */
response_count=8;
flags_cmd_out=f_putcmd|f_ResponseStatus|f_obey_p_check;
}
@@ -3011,7 +3011,7 @@
drvcmd[2]=(block>>16)&0xFF;
drvcmd[3]=(block>>8)&0xFF;
drvcmd[4]=block&0xFF;
-#endif TEST_UPC
+#endif /* TEST_UPC */
response_count=0;

flags_cmd_out=f_putcmd|f_lopsta|f_getsta|f_ResponseStatus|f_obey_p_check|f_bit1;
}
@@ -3042,12 +3042,12 @@
}
 #if TEST_UPC
checksum=0;
-#endif TEST_UPC
+#endif /* TEST_UPC */
for (i=0;i<(fam1_drive?8:16);i++)
{
 #if TEST_UPC
checksum |= infobuf[i];
-#endif TEST_UPC
+#endif /* TEST_UPC */
sprintf(&msgbuf[i*3], " %02X", infobuf[i]);
}
msgbuf[i*3]=0;
@@ -3055,7 +3055,7 @@
 #if TEST_UPC
if ((checksum&0x7F)!=0) break;
}
-#endif TEST_UPC
+#endif /* TEST_UPC */
D_S[d].UPC_ctl_adr=0;
if (fam1_drive) i=0;
else i=2;
diff -urN -X dontdiff linux/drivers/net/pcmcia/wavelan_cs.c 
rb/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wavelan_cs.c   Thu Jan  4 15:50:12 2001
+++ rb/drivers/net/pcmcia/wavelan_cs.c  Sat Jan  6 15:10:02 2001
@@ -1774,7 +1774,7 @@
 #if WIRELESS_EXT > 7
   const intBAND_NUM = 10;  /* Number of bands */
   int  c = 0;  /* Channel number */
-#endif WIRELESS_EXT
+#endif /* WIRELESS_EXT */
 
   /* Read the frequency table */
   fee_read(base, 0x71 /* frequency table */,
@@ -1792,7 +1792,7 @@
  (c < BAND_NUM))
  c++;
list[i].i = c;  /* Set the list index */
-#endif WIRELESS_EXT
+#endif /* WIRELESS_EXT */
 
/* put in the list */
list[i].m = (((freq + 24) * 5) + 24000L) * 1;
diff -urN -X dontdiff linux/drivers/net/pcmcia/xircom_tulip_cb.c 
rb/drivers/net/pcmcia/xircom_tulip
_cb.c
--- linux/drivers/net/pcmcia/xircom_tulip_cb.c  Tue Nov  7 14:09:19 2000
+++ rb/drivers/net/pcmcia/xircom_tulip_cb.c Sat Jan  6 15:10:26 2001
@@ -2388,7 +2388,7 @@
 #ifdef CARDBUS
if (tp->chip_id == X3201_3)
tp->tx_aligned_skbuff[i] = dev_alloc_skb(PKT_BUF_SZ);
-#endif CARDBUS
+#endif /* CARDBUS */
}
tp->tx_ring[i-1].buffer2 = virt_to_bus(&tp->tx_ring[0]);
 }
diff -urN -X dontdiff linux/drivers/net/pppoe.c rb/drivers/net/pppoe.c
--- linux/drivers/net/pppoe.c   Mon Dec 11 15:37:03 2000
+++ rb/drivers/net/pppoe.c  Sat Jan  6 15:07:53 2001
@@ -737,7 +737,7 @@
err = 0;
break;
 
-   default:
+   default:;
};
 
return err;
diff -urN -X dontdiff linux/drivers/net/tokenring/ibmtr.c 
rb/drivers/net/tokenring/ibmtr.c
--- linux/drivers/net/tokenring/ibmtr.c Mon

Re: Little question about modules...

2001-01-06 Thread David Weinehall


On Sun, Jan 14, 2001 at 03:20:52AM +0100, Nicolas Noble wrote:
> 
> Just a question:
> 
> Why do I have used by -1 for the module ipv6 onto my system?
> 
> extract of the /proc/modules:
> 
> ip6table_filter 1988   0 (unused)
> ip6t_mark688   0 (unused)
> ip6t_limit  1016   0 (unused)
> ip6_tables 13044   3 [ip6table_filter ip6t_mark ip6t_limit]
> ipv6  117992  -1

To make sure ipv6 can't get unloaded. If I remember correctly, the
ipv6 code will oops nicely if unloaded.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Oops in 2.4.0-ac2

2001-01-06 Thread Hans-Joachim Baader


Hi,

I got an oops with 2.4.0-ac2. It said "Kernel Panic: Attempt to kill init"
or similar. The oops didn't make it into the log but I photographed it
and reconstructed it from the photos (USB digital cams are a great thing
:-). After the oops, the machine was still responsive to SysRq and ping
but nothing else.

I have Reiserfs latest version on one partition (/var).

Before the oops there were some APIC messages:
APIC error on CPU0: 00(04)
APIC error on CPU1: 08(08)
and so on. Do they have anything to do with it?

Since I had high ISDN activity at this time, ISDN is a main suspect.
BTW I have a similar problem in kernel 2.2.x. I don't know if it is
the same but the condition to trigger it is identical. It only needs
the script LinkChecker which is written in Python AFAIK.

I have isdn4k-utils 3.1pre1, the Changes file recommends 3.1beta7.
Which is newer? Can anyone give a hint? All other tools are up to
date. I used gcc 2.95.2 for the kernel compile.

Hardware: Dual Celeron-466, Abit BP6 board, 128 MB RAM, 1 IDE disk,
Teles 16.3 ISDN card.

ksymoops 2.3.7 on i686 2.4.0-ac2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-ac2/ (default)
 -m /boot/System.map-2.4.0-ac2 (specified)

c01349b9
*pde = 
Oops: 
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax:    ebx:    ecx: c63705ac   edx: 0001
esi:    edi:    ebp: c8821744   esp: c1235ef4
ds: 0018   es: 0018   ss: 0018
Process init (pid: 1, stackpage=c1235000)
Stack: c885261c c5c7a980 c0134a2f  c017c567  c8821744 0016
    001d c8821784 0002  0001 c017c6bb c12d8200
   c8821744 c1235f6c c123432b c020d44f c12d8200 c017e678 c1248200 c1234000
Call Trace: [] [] [] [] [] [] []
   [] [] [] [] [] [>EIP; c01349b9 <__refile_buffer+d/6c>   <=
Trace; c885261c <_end+85a4cac/86216f0>
Trace; c0134a2f 
Trace; c017c567 
Trace; c8821744 <_end+8573dd4/86216f0>
Trace; c8821784 <_end+8573e14/86216f0>
Code;  c01349b9 <__refile_buffer+d/6c>
 <_EIP>:
Code;  c01349b9 <__refile_buffer+d/6c>   <=
   0:   8b 4e 18  mov0x18(%esi),%ecx   <=
Code;  c01349bc <__refile_buffer+10/6c>
   3:   89 c8 mov%ecx,%eax
Code;  c01349be <__refile_buffer+12/6c>
   5:   83 e0 04  and$0x4,%eax
Code;  c01349c1 <__refile_buffer+15/6c>
   8:   0f 45 da  cmovne %edx,%ebx
Code;  c01349c4 <__refile_buffer+18/6c>
   b:   89 c8 mov%ecx,%eax
Code;  c01349c6 <__refile_buffer+1a/6c>
   d:   83 e0 02  and$0x2,%eax
Code;  c01349c9 <__refile_buffer+1d/6c>
  10:   ba 02 00 00 00mov$0x2,%edx

Kernel panic: Attempted to kill init!

Mem-info:
Free pages:  1996kB (0 kB HighMem)
( Active: 16636, inactive_dirty: 7172, inactive_clean: 793, free: 499 (352 704 1
056) )
37*4kB 3*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB =68
4kB)
152*4kB 0*8kB 0*16kB 0*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB =1
312kB)
= 0kB)
swap Cache: add 2617, delete 2370, find 513/2414
Free swap:   250620kB
32768 pages of RAM
0 pages of HIGHMEM
1035 reserved pages
10817 pages shared
247 pages swap cached
0 pages in pages table cache
Buffer memory: 82836kB

My .config:

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_M686FXSR is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG

Little question about modules...

2001-01-06 Thread Nicolas Noble



Just a question:

Why do I have used by -1 for the module ipv6 onto my system?

extract of the /proc/modules:

ip6table_filter 1988   0 (unused)
ip6t_mark688   0 (unused)
ip6t_limit  1016   0 (unused)
ip6_tables 13044   3 [ip6table_filter ip6t_mark ip6t_limit]
ipv6  117992  -1


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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

2001-01-06 Thread David C. Davies

All,

Please reply to [EMAIL PROTECTED] rather than this email account.

Regards,

Dave


Jeff Garzik wrote:
[EMAIL PROTECTED]">Andi Kleen wrote:
  de4x5 is stable, but tends to perform badly under load, mostly becauseit doesn't use rx_copybreak and overflows standard socket buffers with itsalways MTU sized skbuffs.
One of the reasons that de4x5 isn't gone already is that I get reportsthat de4x5 performs better than the tulip driver for their card.	Jeff

Re: How to make VFAT work right in 2.4.0-prereleaseu

2001-01-06 Thread Eelco Dolstra


Hi,

On Sat, 6 Jan 2001, Alan Cox wrote:

> > - edit file fs/fat/inode.c, look in the function named
> > "fat_notify_change" (at about line 901), where it says:"
> > /* FAT cannot truncate to a longer file */
> > if (attr->ia_valid & ATTR_SIZE) {
> > if (attr->ia_size > inode->i_size)
> > return -EPERM;
> > }
> > ", just delete all of it (or comment it out). This change wich has been
> > made in the -prerelease versión, makes Netscape Messenger not to work
> 
> If you do that you will corrupt your FAT fs.

But only on SMP, right?  The only other FAT change I see in -ac (apart
from my patch) is the spinlock around fat_cache.

Regards,

Eelco.




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

Kernel compile trouble

2001-01-06 Thread Johan Groth


Hi,
I wonder if anyone can help me with compilation of kernel 2.4.0. I've
run make mrproper; make menuconfig; make dep and then I try to build the
kernel with make bzImage but that fails utterly. I get the following
message:

tiger:/usr/src/linux# make bzImage
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -malign-functions=4-c -o
init/main.o init/main.c
In file included from /usr/src/linux/include/linux/irq.h:57,
 from /usr/src/linux/include/asm/hardirq.h:6,
 from /usr/src/linux/include/linux/interrupt.h:45,
 from /usr/src/linux/include/asm/string.h:296,
 from /usr/src/linux/include/linux/string.h:21,
 from /usr/src/linux/include/linux/fs.h:23,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from /usr/src/linux/include/linux/mm.h:4,
 from /usr/src/linux/include/linux/slab.h:14,
 from /usr/src/linux/include/linux/malloc.h:4,
 from /usr/src/linux/include/linux/proc_fs.h:5,
 from init/main.c:15:
/usr/src/linux/include/asm/hw_irq.h: In function `x86_do_profile':
/usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use
in this function)
/usr/src/linux/include/asm/hw_irq.h:198: (Each undeclared identifier is
reported only once
/usr/src/linux/include/asm/hw_irq.h:198: for each function it appears
in.)
In file included from /usr/src/linux/include/asm/string.h:296,
 from /usr/src/linux/include/linux/string.h:21,
 from /usr/src/linux/include/linux/fs.h:23,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from /usr/src/linux/include/linux/mm.h:4,
 from /usr/src/linux/include/linux/slab.h:14,
 from /usr/src/linux/include/linux/malloc.h:4,
 from /usr/src/linux/include/linux/proc_fs.h:5,
 from init/main.c:15:
/usr/src/linux/include/linux/interrupt.h: In function `raise_softirq':
/usr/src/linux/include/linux/interrupt.h:89: `current' undeclared (first
use in this function)
/usr/src/linux/include/linux/interrupt.h: In function
`tasklet_schedule':
/usr/src/linux/include/linux/interrupt.h:160: `current' undeclared
(first use in this function)
/usr/src/linux/include/linux/interrupt.h: In function
`tasklet_hi_schedule':
/usr/src/linux/include/linux/interrupt.h:174: `current' undeclared
(first use in this function)
In file included from /usr/src/linux/include/linux/string.h:21,
 from /usr/src/linux/include/linux/fs.h:23,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from /usr/src/linux/include/linux/mm.h:4,
 from /usr/src/linux/include/linux/slab.h:14,
 from /usr/src/linux/include/linux/malloc.h:4,
 from /usr/src/linux/include/linux/proc_fs.h:5,
 from init/main.c:15:
/usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d':
/usr/src/linux/include/asm/string.h:305: `current' undeclared (first use
in this function)
/usr/src/linux/include/asm/string.h: In function `__memcpy3d':
/usr/src/linux/include/asm/string.h:312: `current' undeclared (first use
in this function)
make: *** [init/main.o] Error 1

I using Storm Linux 2000 Deluxe (based on Debian 2.2r2) if that has
anything to with it. I could compile the kernel under Red Hat but not
now.

TIA,
Johan

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   "Better to ask questions and seem stupid
than not to ask questions and remain stupid" -Unknown
   Johan Groth <[EMAIL PROTECTED]> Kupolen Data
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

2001-01-06 Thread David C. Davies


All,

As you can see, I get little time to attend to maintenance chores on the 
de4x5 driver. If there are particular problems that you want sorted out 
please let me know and I'll see what I can do.

Regards,

Dave

--

Jeff Garzik wrote:

> Andi Kleen wrote:
> 
>> de4x5 is stable, but tends to perform badly under load, mostly because
>> it doesn't use rx_copybreak and overflows standard socket buffers with its
>> always MTU sized skbuffs.
> 
> 
> One of the reasons that de4x5 isn't gone already is that I get reports
> that de4x5 performs better than the tulip driver for their card.
> 
>   Jeff
> 
> 

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

Speed of the network card

2001-01-06 Thread Sourav Ghosh


Hello,

I was wondering how I can determine the speed of a network device inside
the kernel.

In case of ethernet, the "name" field  of device structure will only
give eth0 or something. But the speed could be either 10Mbps or 100Mbps.

Thanks,

--
Sourav


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

Re: Bug reporting script?

2001-01-06 Thread Matthias Juchem


On Sat, 6 Jan 2001, Augusto César Radtke wrote:

> About bug reports, isn't a good thing introduce the sgi's lkcd
> (linux kernel crash dump) into the main stream of 2.5? The main problem
> of lkcd in 2.2 was the lack of kiobufs.

(see http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0700.html).

IDE dumps are finally supported (http://oss.sgi.com/projects/lkcd/news.html)

Matthias

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

Re: Linux 2.4.0-ac2

2001-01-06 Thread Bill Crawford


Many thanks, but I just cleaned it up ... the real credit belongs to
Ian Hastie <[EMAIL PROTECTED]>.

 o Fix mac address setting in 8139too (Ben Greear)
-o AGP oops fix/ALi cleanup (Bill Crawford)
+o AGP oops fix/ALi cleanup (Ian Hastie)
 o Further DECnet cleanups (Hans Grobler)

-- 
/* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */
#include "stddiscl.h"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0-ac3 (check again)

2001-01-06 Thread Evan Thompson


Check again, Alan...seems as though you've forgotten to change it so
that is reads -ac3 (or my download messed up, but that can't happen)
instead of -ac2.  Just FYI.  ;-)
-- 
+--+---+
| Evan Thompson|POWERED BY:|
| [EMAIL PROTECTED]   | Linux cd168990-a 2.4.0-ac2 #1 Sat |
| Freelance Computer Nerd  |  Jan 6 11:20:04 CST 2001 i686 |
| http://evaner.penguinpowered.com |   unknown |
+--+---+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0-ac3

2001-01-06 Thread Eyal Lebedinsky


Alan Cox wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
> 2.4.0-ac3

Makefile EXTRAVERSION not updated to -ac3.

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

Re: 3com mini pci card 3cn3ac556

2001-01-06 Thread Andrew Morton


Philipp Schmid wrote:
> 
> hi,
> 
> are there any drivers for  "3Com mini pci card 3cn3ac556", shipped with my
> dell latitude c600 ?

Yep.  Support for the 3c556 was added in kernel 2.2.17-pre14, so
you need 2.2.17 or later.

The latest driver, which is compatible with 2.2.14 and later
is at

http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.19pre2.gz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] single copy pipe rewrite

2001-01-06 Thread David S. Miller


   Date: Sun, 07 Jan 2001 01:36:22 +0100
   From: Manfred <[EMAIL PROTECTED]>

   Do you still have that patch?

I think so, see below.

   Was it posted to linux-kernel?

Yes, it was.

I just found a copy, enjoy:

diff -ur ../vger3-001101/linux/fs/pipe.c linux/fs/pipe.c
--- ../vger3-001101/linux/fs/pipe.c Sat Oct 14 18:38:24 2000
+++ linux/fs/pipe.c Wed Nov  1 21:39:53 2000
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -22,6 +24,18 @@
  * -- Julian Bradfield 1999-06-07.
  */
 
+#define PIPE_UMAP(inode)   ((inode).i_pipe->umap)
+#define PIPE_UMAPOFF(inode)((inode).i_pipe->umap_offset)
+#define PIPE_UMAPLEN(inode)((inode).i_pipe->umap_length)
+
+#define PIPE_UMAP_EMPTY(inode) \
+   ((PIPE_UMAP(inode) == NULL) || \
+(PIPE_UMAPOFF(inode) >= PIPE_UMAPLEN(inode)))
+
+#define PIPE_EMPTY(inode)  \
+   ((PIPE_LEN(inode) == 0) && PIPE_UMAP_EMPTY(inode))
+
+
 /* Drop the inode semaphore and wait for a pipe event, atomically */
 void pipe_wait(struct inode * inode)
 {
@@ -36,6 +50,65 @@
 }
 
 static ssize_t
+pipe_copy_from_kiobuf(char *buf, size_t count, struct kiobuf *kio, int kio_offset)
+{
+   struct page **cur_page;
+   unsigned long cur_offset, remains_this_page;
+   char *cur_buf;
+   int kio_remains;
+
+   kio_remains = kio->length;
+   cur_page = kio->maplist;
+   cur_offset = kio->offset;
+   while (kio_offset > 0 && kio_remains > 0) {
+   remains_this_page = PAGE_SIZE - cur_offset;
+   if (kio_offset < remains_this_page) {
+   cur_offset += kio_offset;
+   kio_remains -= kio_offset;
+   break;
+   }
+   kio_offset -= remains_this_page;
+   kio_remains -= remains_this_page;
+   cur_offset = 0;
+   cur_page++;
+   }
+
+   cur_buf = buf;
+   while (kio_remains > 0) {
+   unsigned long kvaddr;
+   int err;
+
+   remains_this_page = PAGE_SIZE - cur_offset;
+   if (remains_this_page > count)
+   remains_this_page = count;
+   if (remains_this_page > kio_remains)
+   remains_this_page = kio_remains;
+
+   kvaddr = kmap(*cur_page);
+   err = copy_to_user(cur_buf, (void *)(kvaddr + cur_offset),
+  remains_this_page);
+   kunmap(*cur_page);
+
+   if (err)
+   return -EFAULT;
+
+   cur_buf += remains_this_page;
+   count -= remains_this_page;
+   if (count <= 0)
+   break;
+
+   kio_remains -= remains_this_page;
+   if (kio_remains <= 0)
+   break;
+
+   cur_offset = 0;
+   cur_page++;
+   }
+
+   return cur_buf - buf;
+}
+
+static ssize_t
 pipe_read(struct file *filp, char *buf, size_t count, loff_t *ppos)
 {
struct inode *inode = filp->f_dentry->d_inode;
@@ -84,29 +157,44 @@
 
/* Read what data is available.  */
ret = -EFAULT;
-   while (count > 0 && (size = PIPE_LEN(*inode))) {
-   char *pipebuf = PIPE_BASE(*inode) + PIPE_START(*inode);
-   ssize_t chars = PIPE_MAX_RCHUNK(*inode);
-
-   if (chars > count)
-   chars = count;
-   if (chars > size)
-   chars = size;
+   if (PIPE_UMAP(*inode)) {
+   ssize_t chars;
 
-   if (copy_to_user(buf, pipebuf, chars))
+   chars = pipe_copy_from_kiobuf(buf, count,
+ PIPE_UMAP(*inode),
+ PIPE_UMAPOFF(*inode));
+   if (chars < 0)
goto out;
 
read += chars;
-   PIPE_START(*inode) += chars;
-   PIPE_START(*inode) &= (PIPE_SIZE - 1);
-   PIPE_LEN(*inode) -= chars;
count -= chars;
buf += chars;
-   }
+   PIPE_UMAPOFF(*inode) += chars;
+   } else {
+   while (count > 0 && (size = PIPE_LEN(*inode))) {
+   char *pipebuf = PIPE_BASE(*inode) + PIPE_START(*inode);
+   ssize_t chars = PIPE_MAX_RCHUNK(*inode);
 
-   /* Cache behaviour optimization */
-   if (!PIPE_LEN(*inode))
-   PIPE_START(*inode) = 0;
+   if (chars > count)
+   chars = count;
+   if (chars > size)
+   chars = size;
+
+   if (copy_to_user(buf, pipebuf, chars))
+   goto out;
+
+   read += chars;
+   PIPE_START(*inode) += chars;
+   PIPE_START(*inode) &= (PIPE_SIZE - 1);
+

Linux 2.4.0-ac3

2001-01-06 Thread Alan Cox



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

2.4.0-ac3
o   Add support for the newer 3c905 cards   (Andrew Morton)
o   Drop unused field from scc.h(Hans Grobler)
o   Remove dead sysctl stuff from econet(Hans Grobler)
o   Fix documentation indexes   (Paul Gortmaker)
o   Fix post free reference of an skb in lance  (Paul Gortmaker)
o   Tidy appletalk code (Hans Grobler)
o   Fix bootup vesafb hang  (David Wragg)
o   TCP 'reset_xmit_timer' fix  (Dave Miller)
o   Tidy up cursor positioning on menuconfig(Kirk Reiser)
o   Add missing wait.h includes to some asm/semaphore
(Hans Grobler)
o   AF_UNIX socket cleanup  (Hans Grobler)
o   Update sd locking fixes (Oliver Neukum)
o   Add module locking to audio coprocessor calls   (Chris Rankin)
o   Minor further X.25 tidy (Hans Grobler)
o   Fix scsi ioctl/scan crash on out of memory  (Douglas Gilbert)
o   Soundscape patches  (Chris Rankin)
o   M68K fixes for mem stats and stram  (Geert Uytterhoeven)
o   Set MSG_TRUNC correctly on atm sockets  (Matti Aarnio)
o   Add infrastructure for parport autoloading  (Adam J Richter)
o   Make lp driver use capable not old suser()  (Tim Waugh)
o   Fix thread/unload race on i2o block (me)
o   Fix drivers that use asm/delay not linux/delay  (Geert Uytterhoeven)
o   Further warning fixes   (Rich Baum)
o   Netfilter config/Makefile fixes (Dave Miller)
o   Merge updated cs4281 driver and tidy it (Tom Woller)
| some cleanups by me, possibly broken it ;)
o   Fix bagetlance reference of freed buffer (Arnaldo Carvalho de Melo)
o   ISDN small fixes(Andrea Baldoni,
 Daniel Stodden)
o   ESS Maestro 3 driver(Zach Brown)

2.4.0-ac2
o   Clean up strip driver   (Hans Grobler)
o   Fix fore atm makefile   (Jan Rekorajski)
o   Fix m68k lance mismerge (Geert Uytterhoeven)
o   Fix tty documentation typos (Hans Grobler)
o   Fix ohci1394 build  (Arjan van de Ven)
o   Remove dead lapbether inits (Hans Grobler)
o   Workaround the acpi recursive variable name (Bill Wendling)
Makefile problem
o   Further minor S/390 merge   (Ulrich Weigand)
o   Fix DRM build problem on ATI Rage 120/no AGP(Gareth Hughes)
o   Fix mac address setting in 8139too  (Ben Greear)
o   AGP oops fix/ALi cleanup(Bill Crawford)
o   Further DECnet cleanups (Hans Grobler)
o   S/390 last fixes(Ulrich Weigand)
o   Fix missing arlan symbol(Hans Grobler)
o   Do basic IPX/SPX cleanups   (Hans Grobler)

2.4.0-ac1
o   Resync with Linus
o   Fix serial compile bug  (Bill Notthingham)
o   Clean up lapbether  (Hans Grobler)
o   Fix endian handling in ne.c (Geert Uytterhoeven)
o   Fix root umount handling(Chris Mason &
 Al Viro)
o   Bring wan drivers up to scratch for 2.4 (Krzysztof Halasa)
o   SD module locking fix   (Oliver Neukum)
o   Merge S/390 32/64bit ports  (IBM)
| some rough edges to tidy up yet - guys can
| you change the DMA ifdefs to match 2.2 style..

2.4.0prerelease-ac6
o   Cleanup econet  (Hans Grobler)
o   Further amateur radio cleanups  (Hans Grobler)
o   Fix irda/SMP deadlocks  (Marc Zyngier)
o   Further YAM fixes   (Hans Grobler)
o   Fix rio500 locking bug  (Greg Kroah-Hartmann)
o   Fix isdn net leak on error  (Arnaldo Carvalho de Melo)
o   Fix proc_get_inode export (for comx)(Hans Grobler)
o   Fix locking error on get_swap_page  (Marcelo Tosatti)
o   Fix further warnings, and other stuff new gcc   (Arjan van de Ven)
shows up
o   Add isapnp module device tables to drivers  (Bill Nottingham)
[Added to ns558, serial, ide-pnp, cadet,
 3c509,3c515, aironet4500,ne,sb1000, aha1542,
 NCR5380, ad1816, awe_wave, sb,

Re: PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP

2001-01-06 Thread mull


On Sat, Jan 06, 2001 at 09:26:55PM -, Craig Freeze wrote:
> [1.] One line summary of the problem:
> SCSI hangs with aic7xxx in 2.4.0 SMP
> 
> [2.] Full description of the problem/report:
> SCSI device errors and bus resets observed in 2.4.0 that do not occur in 
> 2.2.13.  Sysrq keys have no effect (ie hard reset required to recover)
> 
I've noticed pretty much the same situation on my uniproc box, aic7xxx driver, adaptec 
2940uw card since going to 2.4.0-prerelease. haven't had to hard reset, but have seen 
a LOT of scsi timeout errors. i did not notice this on 2.4.0-test12 or test13pre2. 
when i'm at home i'll see if i can find any pattern or more info, and also test with 
2.4.0 final.
mullein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] atarilance using freed skb

2001-01-06 Thread Arnaldo Carvalho de Melo


Em Sat, Jan 06, 2001 at 09:35:08PM -0200, Arnaldo Carvalho de Melo escreveu:
> Alan,
> 
>   Paul Gortmaker found a similar one for lance, so I'm looking at
> some other drivers to see if this happens, bagetlance has it as well,
> here is the patch.

Another one:

--- linux-2.4.0-ac2/drivers/net/atarilance.cMon Jan  1 14:42:28 2001
+++ linux-2.4.0-ac2.acme/drivers/net/atarilance.c   Sat Jan  6 22:36:23 2001
@@ -820,9 +820,9 @@
head->misc = 0;
lp->memcpy_f( PKTBUF_ADDR(head), (void *)skb->data, skb->len );
head->flag = TMD1_OWN_CHIP | TMD1_ENP | TMD1_STP;
+   lp->stats.tx_bytes += skb->len;
dev_kfree_skb( skb );
lp->cur_tx++;
-   lp->stats.tx_bytes += skb->len;
while( lp->cur_tx >= TX_RING_SIZE && lp->dirty_tx >= TX_RING_SIZE ) {
lp->cur_tx -= TX_RING_SIZE;
lp->dirty_tx -= TX_RING_SIZE;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] single copy pipe rewrite

2001-01-06 Thread Manfred

"David S. Miller" wrote:
> 
> A couple months ago David posted a revised version of his patch which
> fixed both these and some other problems.  Most of the fixes were done
> by Alexey Kuznetsov.
> 

Do you still have that patch?

Stephen Tweedie included the original, unrevied version in his
kiobuf.2.3.99.pre9-2.tar.gz from May, and I couldn't find a newer
version.

Was it posted to linux-kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 Module compile error

2001-01-06 Thread Keith Owens

On Sat, 06 Jan 2001 10:51:53 -0600, 
George R. Kasica <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>>You have a broken modules.conf that tells depmod to scan _all_ of
>>/lib/modules or you have an old version of modules or you have some
>>weird symlinks in /lib/modules.  It looks like you have some dangling
>>symlinks, although I cannot be certain about that.
>
>Here it iswhat do I need to fix on it:
>>path[usb]=/lib/modules/`uname -r`/`uname -v`
>>path[usb]=/lib/modules/`uname -r`
>>path[usb]=/lib/modules/
>>path[usb]=/lib/modules/default

path[usb]=/lib/modules/ is the real killer, you scan all of
/lib/modules and pick up modules for every kernel.  Modutils 2.4 scans
all of /lib/modules/`uname -r` and its subdirectories by default.  You
do not need any path statements unless you have modules that are not
stored in the default path or its subdirectories.  IOW, remove all path
statements unless you are doing something really unusual.

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

Re: [PATCH] up to 50% faster sys_poll()

2001-01-06 Thread Dan Kegel

Manfred wrote:
> The improvement with large number of pipes probably comes from replacing
> __get_free_page() with kmalloc() - kmalloc is faster, especially on SMP.
> ...
> I expected 2 improvements:
> * poll with < 24 descriptors: around 800 cpu ticks faster, but that's
> just one or two microseconds.
> * if one of the first 8 descriptors has new data: add another ~200 cpu
> ticks.

OK, I reran with different numbers of fd's, again on a 650 MHz dual PIII SMP.

Times in microseconds to find 1 active pipe out of N total pipes:

number of pipes
kernel1  8  1   3
-
2.4.0 7 10  14600   45843
2.4.0-pp  5  8  14321   44903

For small N, your patch makes poll() 2 microseconds faster uniformly.
That's a 20-30% speedup, not bad.
Anyone know if this would actually help real-life programs?

BTW, your change makes poll() slightly faster than select().

For large N, your patch speeds poll() up by 2-5%.  
(Increasing /proc/sys/fs/file-max to 7 appears to reduce the speedup.)
I doubt that will have much effect on real-life programs.
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PROBLEM: 2.4.0 Kernel Fails to compile when CONFIG_IP_NF_FTP is selected

2001-01-06 Thread David S. Miller

   From: Rusty Russell <[EMAIL PROTECTED]>
   Date: Sat, 06 Jan 2001 13:40:35 +1100

   CONFIG_IP_NF_FTP controls BOTH the ftp connection tracking and NAT
   code.  The correct fix is below (untested, but you get the idea).

I've applied this, it seems fine.  (I've also adapted it to the
pending IRC stuff, so you don't need to send me a fix for that
under seperate cover).

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

SCSI scanner problem with all kernels since 2.3.42

2001-01-06 Thread Tim Waugh


I'm having problems with using xsane to acquire a preview from an HP
ScanJet 5P connected to an AHA-2940.  2.3.42 is the last kernel that
works right for me.

The symptom is that the scanner starts to make scanning sounds, then
stops, and xsane says 'Error during read: Error during device I/O'.

Any ideas?

Tim.
*/

 PGP signature

Re: ip_conntrack locks up hard on 2.4.0 after about 10 hours

2001-01-06 Thread David S. Miller


   Date:Sat, 06 Jan 2001 10:37:54 -0500
   From: safemode <[EMAIL PROTECTED]>

   Jan  6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1
   when=0x5d9e, caller=c01a6bf1

I posted a fix for this on Linux-kernel yesterday, had you tested it
you would have seen at least this part of your problem report go away.
I'm reposting the fix for your convenience:

--- net/ipv4/tcp_input.c.~1~Wed Dec 13 10:31:48 2000
+++ net/ipv4/tcp_input.cFri Jan  5 17:01:53 2001
@@ -1705,7 +1705,7 @@
 
if ((__s32)when < (__s32)tp->rttvar)
when = tp->rttvar;
-   tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, when);
+   tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, min(when, TCP_RTO_MAX));
}
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] single copy pipe rewrite

2001-01-06 Thread David S. Miller

   Date: Sun, 07 Jan 2001 00:25:16 +0100
   From: Manfred <[EMAIL PROTECTED]>

   Last march David Miller proposed using kiobuf for these data
   transfers, I've written a new patch for 2.4.

   (David's original patch contained 2 bugs: it doesn't protect
   properly against multiple writers and it causes a BUG() in
   pipe_read() when data is stored in both the kiobuf and the normal
   buffer)

A couple months ago David posted a revised version of his patch which
fixed both these and some other problems.  Most of the fixes were done
by Alexey Kuznetsov.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] bagetlance using freed skb

2001-01-06 Thread Arnaldo Carvalho de Melo


Alan,

Paul Gortmaker found a similar one for lance, so I'm looking at
some other drivers to see if this happens, bagetlance has it as well,
here is the patch.

- Arnaldo

--- linux-2.4.0-ac2/drivers/net/bagetlance.cTue Dec 19 11:25:40 2000
+++ linux-2.4.0-ac2.acme/drivers/net/bagetlance.c   Sat Jan  6 21:27:50 2001
@@ -930,9 +930,9 @@
 #else
 SET_FLAG(head,(TMD1_OWN_CHIP | TMD1_ENP | TMD1_STP));
 #endif
+   lp->stats.tx_bytes += skb->len;
dev_kfree_skb( skb );
lp->cur_tx++;
-   lp->stats.tx_bytes += skb->len;
while( lp->cur_tx >= TX_RING_SIZE && lp->dirty_tx >= TX_RING_SIZE ) {
lp->cur_tx -= TX_RING_SIZE;
lp->dirty_tx -= TX_RING_SIZE;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread David S. Miller



Unified diffs only please... Thanks.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Crypto in 2.4

2001-01-06 Thread Jon Masters

Marc Mutz wrote:

> A 2.4.0.1 should be on ftp.kernel.org/pub/linux/kernel/crypto/v2.4/.
> But it has been heavily re-worked. I haven't got my hands on that one
> and will keep quiet as to what extend that patch is produiction-ready,
> but I remember that the loop driver in 2.4.0 still can stall your box. 

Hmmm, it's magically appeared :P

As far as the stability goes, this is one of my current hang-ups - I've
heard about the loopback stuff in 2.4. I want to use 2.4 but I can't use
any of my systems without crypto (and hence loopback) since key personal
data is stored therein and I don't want to sacrifice stability.

> Since the kerneli crypto relies on loop, this would count in favor of
> "don't do that yet".

Indeed. I wish I could help improve things - I'm not really in the game
yet although I want to be and I am working towards that.

> BTW: You might want to join [EMAIL PROTECTED] (majordomo) if
> you are interested in kerneli.

Indeed I am interested - I've been using it for quite some time - I
really don't know why I overlooked that list.

jcm mails majordomo...

Jonathan.

-- 
 _ [EMAIL PROTECTED] _
| Technical, Easy Penguin.  +44 777 61 31337   GPG keys available. |
|"And am I, who lived but for my country" [quote: Robert Emmet]|
  http://www.jonmasters.org.uk 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[patch] single copy pipe rewrite

2001-01-06 Thread Manfred


(Linus, look away, I'll resubmit it for 2.5.0)

The Linux pipe implementation is extremely inefficient for long,
blocking data transfers with pipes (e.g. what gcc -pipe does):
* 2 memcopies: user space->kernel buffer->user space
* 2 context switches for each transfered page.

Last march David Miller proposed using kiobuf for these data transfers,
I've written a new patch for 2.4.

(David's original patch contained 2 bugs: it doesn't protect properly
against multiple writers and it causes a BUG() in pipe_read() when data
is stored in both the kiobuf and the normal buffer)


--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 0
//  EXTRAVERSION =
--- 2.4/fs/pipe.c   Thu Nov 16 22:18:26 2000
+++ build-2.4/fs/pipe.c Sat Jan  6 22:43:32 2001
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -35,30 +37,100 @@
down(PIPE_SEM(*inode));
 }
 
+struct pipe_pio {
+   int *pdone;
+   struct kiobuf iobuf;
+};
+
+static int
+pio_copy_to_user(struct kiobuf* iobuf, char* ubuf, int chars, int offset)
+{
+   int page_nr;
+   offset += iobuf->offset;
+   page_nr = offset/PAGE_SIZE;
+   offset %= PAGE_SIZE;
+   while(chars) {
+   int pcount = PAGE_SIZE-offset;
+   void *kaddr;
+   if (pcount > chars)
+   pcount = chars;
+   kaddr = kmap(iobuf->maplist[page_nr]);
+   if (copy_to_user(ubuf, kaddr+offset, pcount))
+   return 1;
+   kunmap(iobuf->maplist[page_nr]);
+   chars -= pcount;
+   ubuf += pcount;
+   offset = 0;
+   page_nr++;
+   }
+   return 0;
+}
+
 static ssize_t
 pipe_read(struct file *filp, char *buf, size_t count, loff_t *ppos)
 {
struct inode *inode = filp->f_dentry->d_inode;
-   ssize_t size, read, ret;
+   ssize_t read, ret;
 
/* Seeks are not allowed on pipes.  */
-   ret = -ESPIPE;
-   read = 0;
if (ppos != &filp->f_pos)
-   goto out_nolock;
+   return -ESPIPE;
 
/* Always return 0 on null read.  */
-   ret = 0;
if (count == 0)
-   goto out_nolock;
+   return 0;
 
-   /* Get the pipe semaphore */
-   ret = -ERESTARTSYS;
-   if (down_interruptible(PIPE_SEM(*inode)))
-   goto out_nolock;
+   down(PIPE_SEM(*inode));
 
-   if (PIPE_EMPTY(*inode)) {
-do_more_read:
+   read = 0;
+   for (;;) {
+   /* read what data is available */
+   int chars = PIPE_LEN(*inode);
+   if (chars) {
+   char *pipebuf = PIPE_BASE(*inode);
+   int offset = PIPE_START(*inode);
+
+   if (chars > count)
+   chars = count;
+   ret = -EFAULT;
+   if(PIPE_IS_PIO(*inode)) {
+   struct pipe_pio* pio = ((struct pipe_pio*)pipebuf);
+   if(pio_copy_to_user(&pio->iobuf, buf, chars, offset))
+   goto out;
+
+   PIPE_LEN(*inode) -= chars;
+   if(!PIPE_LEN(*inode)) {
+   unmap_kiobuf(&pio->iobuf);
+   *pio->pdone = 1;
+   PIPE_IS_PIO(*inode) = 0;
+   PIPE_START(*inode) = 0;
+   } else {
+   PIPE_START(*inode) += chars;
+   }
+   } else {
+   if (offset+chars <= PIPE_SIZE) {
+   if (copy_to_user(buf, pipebuf+offset, chars))
+   goto out;
+   } else {
+   int p1 = PIPE_SIZE-offset;
+   if (copy_to_user(buf, pipebuf+offset, p1))
+   goto out;
+   if (copy_to_user(buf+p1, pipebuf, chars-p1))
+   goto out;
+   }
+   PIPE_LEN(*inode) -= chars;
+   if (!PIPE_LEN(*inode)) {
+   /* Cache behaviour optimization */
+   PIPE_START(*inode) = 0;
+   } else {
+   PIPE_START(*inode) += chars;
+   PIPE_START(*inode) &= (PIPE_SIZE - 1);
+   }
+   }
+   read += chars;
+   count -= chars;
+   b

Re: 2.4.0 link error with modular PCMCIA

2001-01-06 Thread jochen


Hi Kai,

> This should fix it.

This did fix it :)

Thanks,
Jochen

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

Re: 2.4.0 link error with modular PCMCIA

2001-01-06 Thread Kai Germaschewski

On Sat, 6 Jan 2001, Jochen Friedrich wrote:

> Hi,
>
> problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are
> compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o...

This should fix it.

--- drivers/net/Makefile%   Fri Jan  5 15:10:11 2001
+++ drivers/net/MakefileSat Jan  6 23:48:28 2001
@@ -26,7 +26,7 @@
   obj-$(CONFIG_ISDN) += slhc.o
 endif

-subdir-$(CONFIG_PCMCIA) += pcmcia
+subdir-$(CONFIG_NET_PCMCIA) += pcmcia
 subdir-$(CONFIG_TULIP) += tulip
 subdir-$(CONFIG_IRDA) += irda
 subdir-$(CONFIG_TR) += tokenring

The problem is that CONFIG_PCMCIA is M, therefore drivers/net/pcmcia is
not entered during "make vmlinux". The patch fixes this and will produce
an (empty) pcmcia_net.o

And, yes, the directory will also be entered when doing "make modules",
because pcmcia is in $(mod-subdirs).

--Kai

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

Re: Bug reporting script? (was: removal of redundant line in documentation)

2001-01-06 Thread db


[...]

> About bug reports, isn't a good thing introduce the sgi's lkcd (linux
kernel crash dump) into the main stream of 2.5? The main problem of lkcd in
2.2 was the lack of kiobufs.
>
> I think it as a good thing, for distributions, the distribution guys have
the vmlinuz image of the distro, so when a bug happens the user only needs
to send the crash dump to the distribution kernel hacker, and he can discuss
the bug on lkml.
>
> This introduce a new kind of bug reporter, if the distribution makes
avalaible every new development kernel as a package, a user can download and
use, crash and report the bug without any knowledge about kernel. So the
marketing guys can say: 'help the development of linux without hacking,
report bugs'.



I think this would be a great idea.



Dan Browning, Cyclone Computer Systems, [EMAIL PROTECTED]



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

Re: 500 ms offset in i386 Real Time Clock setting

2001-01-06 Thread Andries . Brouwer


> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account.
> As a result, using hwclock --systohc or --adjust always leaves the
> Hardware Clock 500 ms ahead of the System Clock

By pure coincidence [EMAIL PROTECTED] sent me patches just one day ago.
I still have to look at the details, but it seems very likely
that this will be corrected in the next util-linux release.

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

re: [PATCH] up to 50% faster sys_poll()

2001-01-06 Thread Dan Kegel


Manfred ([EMAIL PROTECTED]) wrote:
> sys_poll spends around 1/2 of the execution time allocating / freeing a 
> few bytes temporary memory. 
> The attached patch tries to avoid these allocation by using the stack - 
> usually only a few bytes are needed, kmalloc is used for the rest. 
> The result: one poll of stdin is down from 1736 cpu ticks to 865 cpu 
> ticks (Pentium II/350 SMP, SMP kernel) 

Tested with poll() microbenchmark from 
http://www.kegel.com/dkftpbench/Poller_bench.html

time in microsec to find a single active pipe among N pipes
on a 650 MHz dual Pentium III using poll():

number of pipes
kernel1001000   1
-
2.4.0-t10pre4  491184   14660
2.4.0  481162   14702
2.4.0-pp   481103   14205

2.4.0-pp is with Manfred's patch.  Seems to be a 4-6% improvement 
for large numbers of pipes, no change for 100 pipes.

Hope that was an appropriate test. 

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

Re: [PATCH] svgalib error in mmap documentation

2001-01-06 Thread Alan Cox


> I hope it is reasonable to ask, how?

POSIX shared memory calls or sys5 shm

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

Re: Journaling: Surviving or allowing unclean shutdown?

2001-01-06 Thread Marc Lehmann


On Sat, Jan 06, 2001 at 03:35:02PM -0500, Chris Mason <[EMAIL PROTECTED]> wrote:
> > Nobody with working brain would read it completely into memory.

Instead everybody with a working brain would introduce another hashing
layer for every block access? I don't think the reiserfs code (e.g.) would
cope with yte another compliation in the code ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Crypto in 2.4

2001-01-06 Thread Marc Mutz

Jon Masters wrote:
> 
> Hello,
> 
> I am aware of work being done to create crypto patches for 2.4 however I
> am wondering what kind of time scale is likely to be involved before a
> patch for 2.4.0 becomes available and, more importantly, when such a
> patch will be suitable for daily use (disclaimers withstanding
> obviously).
> 
> Let's just say I'm cautious after a bad experience with one of the
> previous dud patch releases :P
> 

A 2.4.0.1 should be on ftp.kernel.org/pub/linux/kernel/crypto/v2.4/. But
it has been heavily re-worked. I haven't got my hands on that one and
will keep quiet as to what extend that patch is produiction-ready, but I
remember that the loop driver in 2.4.0 still can stall your box. Since
the kerneli crypto relies on loop, this would count in favor of "don't
do that yet".

BTW: You might want to join [EMAIL PROTECTED] (majordomo) if you
are interested in kerneli.

Marc

-- 
Marc Mutz <[EMAIL PROTECTED]> http://EncryptionHOWTO.sourceforge.net/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

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

PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP

2001-01-06 Thread Craig Freeze


[1.] One line summary of the problem:
SCSI hangs with aic7xxx in 2.4.0 SMP

[2.] Full description of the problem/report:
SCSI device errors and bus resets observed in 2.4.0 that do not occur in 
2.2.13.  Sysrq keys have no effect (ie hard reset required to recover)

[3.] Keywords (i.e., modules, networking, kernel):
aic7xxx 2.4.0 scsi SMP

[4.] Kernel version (from /proc/version):
Linux version 2.4.0 (root@bender) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 SMP Fri Jan 5 15:04:52 CST 2001

[5.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)
N/A

[6.] A small shell script or example program which triggers the
 problem (if possible)
N/A

[7.] Environment
N/A

[7.1.] Software (add the output of the ver_linux script here)
Linux bender 2.4.0 #1 SMP Fri Jan 5 15:04:52 CST 2001 i586 unknown
Kernel modules 2.3.18
Gnu C  egcs-2.91.66
Gnu Make   3.77
Binutils   2.9.1.0.25
Linux C Library2.1.2
Dynamic linker ldd: version 1.9.9
Procps 2.0.2
Mount  2.10o
Net-tools  1.57
Kbdcommand
Sh-utils   1.16
Modules Loaded iptable_filter ipt_MASQUERADE iptable_nat 
ip_conntrack ip_tables 3c509 isa-pnp 8139too

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 4
model name  : Pentium MMX
stepping: 3
cpu MHz : 232.110
fdiv_bug: no
hlt_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 apic mmx
bogomips: 462.02

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 5
model   : 4
model name  : Pentium MMX
stepping: 3
cpu MHz : 232.110
fdiv_bug: no
hlt_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 apic mmx
bogomips: 463.66

[7.3.] Module information (from /proc/modules):
iptable_filter  1856   0 (autoclean) (unused)
ipt_MASQUERADE  1472   1 (autoclean)
iptable_nat13504   0 [ipt_MASQUERADE]
ip_conntrack   14496   1 [ipt_MASQUERADE iptable_nat]
ip_tables  11008   5 [iptable_filter ipt_MASQUERADE iptable_nat]
3c509   7232   1
isa-pnp28208   0 [3c509]
8139too15488   1

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0213-0213 : isapnp read
0220-022f : 3c509 PnP
02f8-02ff : serial(auto)
03c0-03df : vga+
03e8-03ef : serial(auto)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
6400-64ff : Realtek Semiconductor Co., Ltd. RTL-8139
  6400-64ff : eth0
6800-68ff : Adaptec AHA-294x / AIC-7871
  6800-68fe : aic7xxx
f000-f00f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]

-0009fbff : System RAM
0009fc00-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000-000ca7ff : Extension ROM
000f-000f : System ROM
0010-07ff : System RAM
  0010-00209f9f : Kernel code
  00209fa0-0026395f : Kernel data
e000-e0ff : Realtek Semiconductor Co., Ltd. RTL-8139
  e000-e0ff : eth0
e0001000-e0001fff : Adaptec AHA-294x / AIC-7871
fec0-fec00fff : reserved
fee0-fee00fff : reserved
- : reserved

[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 
03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR-  [disabled] [size=32K]

[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: DEC  Model: RZ26 (C) DEC Rev: T386
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: DEC  Model: RZ26 (C) DEC Rev: T386
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
  Vendor: PLEXTOR  Model: CD-ROM PX-4XCH   Rev: 1.23
  Type:   CD-ROM   ANSI SCSI revision: 02


[7.7.] Other information that might be relevant to the problem
Jan  5 16:34:12 bender kernel: (scsi0:0:3:0) Data overrun detected in 
Data-In phase, tag 9;
Jan  5 16:34:12 bender kernel:   Have seen Data Phase. Length=53248, 
NumSGs=13.
Jan  5 16:34:12 bender kernel:  sg[

Re: Major Failure 2.4.0-test12 Alpha

2001-01-06 Thread Gregory McLean

On Thu, 14 Dec 2000, Leslie Donaldson wrote:

> Hello,
>   Just writing in to report a bug in 2.4.0-test12.
> Hardware:
>   PCI-Matrox_Mill
>   PCI-Adaptec 39160 / 160M scsi card
>   PCI-Generic TNT-2 card
>   PCI-Sound blaster -128 (es1370)
>
> CPU 21164a - Alpha

I'm also seeing this on 2.4.0 proper with almost the same hardware:
 SCSI storage controller: Adaptec AIC-7881U (rev 01) (aic71 driver)
VGA compatible controller: Matrox Graphics, Inc. MGA 1064SG [Mystique]
(rev 03)
SB Vibra16X sound card.

I swap to scsi as the ide performance on this board just blows, I get into
a heavy swap situation and *boom* deadlocked.

>
> Problem:
>   There is a race condition in the aic7 driver that causes the
> kernel to lock up.
> I don't have a kernel dump yet as the machine reported by it'self..
> This problem has been easy to reproduce. ergo about 3 crashes a day.

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

Re: [PATCH] svgalib error in mmap documentation

2001-01-06 Thread Matan Ziv-Av

On Sat, 6 Jan 2001, Alan Cox wrote:

> > +If you want svgalib programs to run with kernel 2.4.0 or newer, svgalib
> > +needs to be compiled without background support (BACKGROUND not defined in
> > +Makefile.cfg). This is relevant to any svgalib version.
> > +This is because svgalib uses mmap of/proc/mem to emulate vga's memory bank
> > +switching when in background, and kernel 2.4.0 stopped supporting this feature.
> 
> 2.4 has real support for shared mappings, so you can I suspect do it properly
> now

I hope it is reasonable to ask, how?

What I need is to allocate a big amount of memory (say 1MB, for
example), copy the video memory to it, and then have fixed 64K of
virutal address of the process point to any 64K window of the large
allocated memory. How can I do it?

-- 
Matan Ziv-Av. [EMAIL PROTECTED]

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

neither 2.2.18 nor 2.4.0 boot on my Cyrix III

2001-01-06 Thread Martin Hammerschmid


I'm not subscribed to the list but I want to report this problem:

I found this in the kernel mailing list archive :

> The cyrixIII chips by via have the centaur vendor id which causes the 
> identify_cpu call in arch/i386/kernel/setup.c to fail. It is probably 
> reasonable for it to have the centaur id as via owns centaur as well. I 
> just replaced the centaur_model call with the cyrix_model one, but I 
> know that I am using a cyrix chip. 
> 
> A test probably needs to be added in the centaur_model section to test 
> for the cyrixIII in disguise. 
> 
> The error is a general protection fault. 

I had the same problem as described above with 2.2.18 and 2.4.0 
(2.2.17 boots without any problems)
I changed setup.c as suggested in this post and was able to boot both
(2.2.18 and 2.4.0).
I don't have any kernel knowledge but I'm willing to test something on
my box if 
anyone is interested in solving this problem.

(via Cyrix III on a Aopen mx3s board (i815))

TIA

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

3com mini pci card 3cn3ac556

2001-01-06 Thread Philipp Schmid


hi,

are there any drivers for  "3Com mini pci card 3cn3ac556", shipped with my 
dell latitude c600 ?

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

Re: 2.4.0 Module compile error

2001-01-06 Thread J . A . Magallon



On 2001.01.06 George R . Kasica wrote:
> 
> Here it iswhat do I need to fix on it:
> 
> >[root@eagle 2.4.0]# cd /etc
> >[root@eagle /etc]# more modules.conf
> >keep
> >
> >path[usb]=/lib/modules/`uname -r`/`uname -v`
 ^
??
$ uname -v
#6 SMP Sat Jan 6 01:38:26 CET 2001

> >path[usb]=/lib/modules/`uname -r`
> >path[usb]=/lib/modules/
> >path[usb]=/lib/modules/default
> >

Delete all that stuff 'path[usb]' from /etc/modules.conf. It
is confusing your modutils. Paths should begin with
/lib/modules/`uname -r`/kernel, I think. But it is safer to
delete them.

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

Linux werewolf 2.4.0-ac2 #6 SMP Sat Jan 6 01:38:26 CET 2001 i686

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

Linux 2.4.0 make bzImage failure - Followup

2001-01-06 Thread George R . Kasica


Wellgot 2.2.18 to work again here but now when I try to make 2.4.0
I get 

drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/ne
t/net.o drivers/media/media.o  drivers/parport/driver.o
drivers/scsi/scsidrv.o d
rivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o \
net/network.o \
/usr/src/linux-2.4.0/arch/i386/lib/lib.a
/usr/src/linux-2.4.0/lib/lib.a
/usr/src/linux-2.4.0/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
\)\|\(\.\.ng$\)\|\(LASH[R
L]DI\)' | sort > System.map
make[1]: Entering directory `/usr/src/linux-2.4.0/arch/i386/boot'
ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect
bbootsect.o: file not recognized: File format not recognized
make[1]: *** [bbootsect] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.0/arch/i386/boot'
make: *** [bzImage] Error 2

I'm running the following:

 [root@eagle linux]# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)

[root@eagle linux]# make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <[EMAIL PROTECTED]>.

[root@eagle linux]# lilo -v
LILO version 21.6-1, Copyright (C) 1992-1998 Werner Almesberger
Linux Real Mode Interface library Copyright (C) 1998 Josh Vanderhoof
Development beyond version 21 Copyright (C) 1999-2000 John Coffman
Released 16-Dec-2000 and compiled at 12:26:34 on Jan  6 2001.

ALSO:

[root@eagle linux]# ld -v
GNU ld version 2.10.1 (with BFD 2.10.1)


===[George R. Kasica]===+1 262 513 8503
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Waukesha, WI USA 
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.4.0 make bzImage failure

2001-01-06 Thread George R . Kasica


Wellgot 2.2.18 to work again here but now when I try to make 2.4.0
I get 

drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/ne
t/net.o drivers/media/media.o  drivers/parport/driver.o
drivers/scsi/scsidrv.o d
rivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o \
net/network.o \
/usr/src/linux-2.4.0/arch/i386/lib/lib.a
/usr/src/linux-2.4.0/lib/lib.a
/usr/src/linux-2.4.0/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
\)\|\(\.\.ng$\)\|\(LASH[R
L]DI\)' | sort > System.map
make[1]: Entering directory `/usr/src/linux-2.4.0/arch/i386/boot'
ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect
bbootsect.o: file not recognized: File format not recognized
make[1]: *** [bbootsect] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.0/arch/i386/boot'
make: *** [bzImage] Error 2

I'm running the following:


[root@eagle linux]# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)

[root@eagle linux]# make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <[EMAIL PROTECTED]>.

[root@eagle linux]# lilo -v
LILO version 21.6-1, Copyright (C) 1992-1998 Werner Almesberger
Linux Real Mode Interface library Copyright (C) 1998 Josh Vanderhoof
Development beyond version 21 Copyright (C) 1999-2000 John Coffman
Released 16-Dec-2000 and compiled at 12:26:34 on Jan  6 2001.


===[George R. Kasica]===+1 262 513 8503
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Waukesha, WI USA 
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: New features in Linux 2.4 - Wonderful World of Linux 2.4

2001-01-06 Thread Jean-Christian de Rivaz

Joe Pranevich wrote:
>
> Networking and Protocols
>
> ... It should also be mentioned at
>this point that Linux is still the only operating system completely
>compatible with the letter of the IPv4 specification ...

I am very interesting about the proof of this. I work on a project witch
need to be certified. Any informations about the compliance of Linux to
some specification is very welcome.

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

Re: [PATCH] PCI device IDs for Intel i815E chipset (2.4.0)

2001-01-06 Thread Andre Hedrick



I gave it a label based on the stamp on the chips, and "Intel Secret" was
above that label.

Cheers,

On Sat, 6 Jan 2001, Peter Denison wrote:

> Description:
> Includes new PCI device IDs for the Intel i815E chipset, and corrects some
> of the names for the associated parts of the chipset. This has effects in
> the EEPro100 network driver and the PCI IDE driver.
> 
> Detail & Justification:
> The Intel ICH2 (I/O Controller Hub 2) is used in several chipsets, not
> just the 820 (Camino) chipset it is accredited to in the PCI ID database.
> Nor is the IDE portion of the ICH2 really a PIIX4 chip, though it is very
> similar and PIIX driver works on both. These changes are just
> internal macro naming and minor user interface tweaks.
> 
> According to Intel there are 3 versions of the I/O Controller hub:
> Name   Chip Number Used in "chipset"
> 
> ICH82801AA 820, 815, 810E, 810
> ICH0   82801AB 820, 810E, 810
> ICH2   82801BA 820E, 815E
> 
> The difference between the 810E and the 810 is the E version of the 82810
> GMCH Host interface. Presumably the choice between an ICH and an ICH0 is
> one for the motherboard designer to make...
> 
> 
> Patch applies to 2.4.0:
> 
> --- include/linux/pci_ids.h   Sat Jan  6 17:51:13 2001
> +++ include/linux/pci_ids.h.new   Sat Jan  6 19:22:51 2001
> @@ -1336,6 +1336,9 @@
>  #define PCI_DEVICE_ID_INTEL_824300x0486
>  #define PCI_DEVICE_ID_INTEL_824340x04a3
>  #define PCI_DEVICE_ID_INTEL_I960 0x0960
> +#define PCI_DEVICE_ID_INTEL_82815_0  0x1130
> +#define PCI_DEVICE_ID_INTEL_82815_1  0x1131
> +#define PCI_DEVICE_ID_INTEL_82815_2  0x1132
>  #define PCI_DEVICE_ID_INTEL_82559ER  0x1209
>  #define PCI_DEVICE_ID_INTEL_82092AA_00x1221
>  #define PCI_DEVICE_ID_INTEL_82092AA_10x1222
> @@ -1375,13 +1378,16 @@
>  #define PCI_DEVICE_ID_INTEL_82801AB_50x2425
>  #define PCI_DEVICE_ID_INTEL_82801AB_60x2426
>  #define PCI_DEVICE_ID_INTEL_82801AB_80x2428
> -#define PCI_DEVICE_ID_INTEL_82820FW_00x2440
> -#define PCI_DEVICE_ID_INTEL_82820FW_10x2442
> -#define PCI_DEVICE_ID_INTEL_82820FW_20x2443
> -#define PCI_DEVICE_ID_INTEL_82820FW_30x2444
> -#define PCI_DEVICE_ID_INTEL_82820FW_40x2449
> -#define PCI_DEVICE_ID_INTEL_82820FW_50x244b
> -#define PCI_DEVICE_ID_INTEL_82820FW_60x244e
> +#define PCI_DEVICE_ID_INTEL_82801BA_00x2440
> +#define PCI_DEVICE_ID_INTEL_82801BA_20x2442
> +#define PCI_DEVICE_ID_INTEL_82801BA_30x2443
> +#define PCI_DEVICE_ID_INTEL_82801BA_40x2444
> +#define PCI_DEVICE_ID_INTEL_82801BA_50x2445
> +#define PCI_DEVICE_ID_INTEL_82801BA_60x2446
> +#define PCI_DEVICE_ID_INTEL_82801BAM 0x2448
> +#define PCI_DEVICE_ID_INTEL_82801BA_90x2449
> +#define PCI_DEVICE_ID_INTEL_82801BA_10x244b
> +#define PCI_DEVICE_ID_INTEL_82801BA  0x244e
>  #define PCI_DEVICE_ID_INTEL_82810_MC10x7120
>  #define PCI_DEVICE_ID_INTEL_82810_IG10x7121
>  #define PCI_DEVICE_ID_INTEL_82810_MC30x7122
> --- drivers/net/eepro100.cThu Dec 21 21:40:27 2000
> +++ drivers/net/eepro100.c.newThu Jan  4 18:27:16 2001
> @@ -2192,7 +2192,7 @@
>   PCI_ANY_ID, PCI_ANY_ID, },
>   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID1030,
>   PCI_ANY_ID, PCI_ANY_ID, },
> - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82820FW_4,
> + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_9,
>   PCI_ANY_ID, PCI_ANY_ID, },
>   { 0,}
>  };
> --- drivers/pci/pci.ids   Sat Jan  6 17:51:10 2001
> +++ drivers/pci/pci.ids.new   Sat Jan  6 19:21:24 2001
> @@ -4484,6 +4484,9 @@
>   1014 0119  Netfinity Gigabit Ethernet SX Adapter
>   8086 1000  EtherExpress PRO/1000 Gigabit Server Adapter
>   1030  82559 InBusiness 10/100
> + 1130  82815 GMCH Host-Hub Bridge/DRAM Controller
> + 1131  82815 GMCH AGP Bridge
> + 1132  82815 GMCH Internal Graphics Controller
>   1161  82806AA PCI64 Hub Advanced Programmable Interrupt Controller
>   1209  82559ER
>   1221  82092AA_0
> @@ -4565,32 +4568,33 @@
>   1a21  82840 840 (Carmel) Chipset Host Bridge (Hub A)
>   1a23  82840 840 (Carmel) Chipset AGP Bridge
>   1a24  82840 840 (Carmel) Chipset PCI Bridge (Hub B)
> - 2410  82801AA ISA Bridge (LPC)
> - 2411  82801AA IDE
> - 2412  82801AA USB
> - 2413  82801AA SMBus
> - 2415  82801AA AC'97 Audio
> + 2410  82801AA ICH ISA Bridge (LPC)
> + 2411  82801AA ICH IDE
> + 2412  82801AA ICH USB
> + 2413  82801AA ICH SMBus
> + 2415  82801AA ICH AC'97 Audio
>   11d4 0040  SoundMAX Integrated Digital Audio
>   11d4 0048  SoundMAX Integrated Digital Audio
>   11d4 5340  SoundMAX Integrated Digital Audio
> - 2416  82801AA AC'97 Modem
> - 2418  82801AA PCI Bridge
> - 2420  82801AB ISA Bridge (LPC)
> - 2421  82801AB IDE
> - 2422  82801AB U

Re: Journaling: Surviving or allowing unclean shutdown?

2001-01-06 Thread Chris Mason




On Saturday, January 06, 2001 09:09:51 PM +0100 Stefan Traby
<[EMAIL PROTECTED]> wrote:

> On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
> 
>> reply. Sure, you can do virtual log replays, but for example the reiserfs
>> log is currently 32mb. Pinning down that much memory for a virtual log
>> reply is not possible on low-memory machines.
> 
> Nobody with working brain would read it completely into memory.
> One just put the block-# that are in the journal into a hash-table
> and read the block out of the journal when it's requested.
> Because there may be multiple copies of the same block in the
> journal, one should take the newest one that can be found in
> the last commited transaction.
> 
> IMHO Chris Mason already wrote such code, at least he talked about
> it...
> 
Talked about it, but never wrote it.  However,  I know there was code to do
this for grub, I'm not sure if it ever made it into their releases.

-chris

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

[PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)

2001-01-06 Thread Ben Greear


I'm hoping that I can get a few comments on this code.  It was added
to (significantly) speed up things like 'ifconfig -a' when running with
4000 or so VLAN devices.  It should also help other instances with lots
of (virtual) devices, like FrameRelay, ATM, and possibly virtual IP
interfaces.  It probably won't help 'normal' users much, and in it's final
form, should probably be a selectable option in the config process.

Anyway, let me know what you think!

Patch to net/core/dev.c of 2.4.0 fame:

*** ../../../linux/net/core/dev.c   Mon Dec 11 14:29:35 2000
--- dev.c   Sat Jan  6 14:14:10 2001
***
*** 1,3 
! /*
   *NET3Protocol independent device support routines.
   *
--- 1,3 
! /* -*- linux-c -*-
   *NET3Protocol independent device support routines.
   *
***
*** 132,138 
   *
   *Why 16. Because with 16 the only overlap we get on a hash of the
!  *low nibble of the protocol value is RARP/SNAP/X.25. 
   *
   *0800IP
   *0001802.3
   *0002AX.25
--- 133,147 
   *
   *Why 16. Because with 16 the only overlap we get on a hash of the
!  *low nibble of the protocol value is RARP/SNAP/X.25.
!  *
!  *  NOTE:  That is no longer true with the addition of VLAN tags.  Not
!  * sure which should go first, but I bet it won't make much
!  * difference if we are running VLANs.  The good news is that
!  * this protocol won't be in the list unless compiled in, so
!  * the average user (w/out VLANs) will not be adversly affected.
!  * --BLG
   *
   *0800IP
+  *8100802.1Q VLAN
   *0001802.3
   *0002AX.25
***
*** 179,182 
--- 188,435 
  
  
+ #define BENS_FAST_DEV_LOOKUP
+ #ifdef BENS_FAST_DEV_LOOKUP
+ /* Fash Device Lookup code.  Should give much better than
+  * linear speed when looking for devices by idx or name.
+  * --Ben ([EMAIL PROTECTED])
+  */
+ #define FDL_HASH_LEN 256
+ 
+ /* #define FDL_DEBUG */
+ 
+ struct dev_hash_node {
+ struct net_device* dev;
+ struct dev_hash_node* next;
+ };
+ 
+ struct dev_hash_node* fdl_name_base[FDL_HASH_LEN];/* hashed by name */
+ struct dev_hash_node* fdl_idx_base[FDL_HASH_LEN]; /* hashed by index */
+ int fdl_initialized_yet = 0;
+ 
+ /* TODO:  Make these inline methods */
+ /* Nice cheesy little hash method to be used on device-names (eth0, ppp0, etc) */
+ int fdl_calc_name_idx(const char* dev_name) {
+ int tmp = 0;
+ int i;
+ #ifdef FDL_DEBUG
+ printk(KERN_ERR "fdl_calc_name_idx, name: %s\n", dev_name);
+ #endif
+ for (i = 0; dev_name[i]; i++) {
+ tmp += (int)(dev_name[i]);
+ }
+ if (i > 3) {
+ tmp += (dev_name[i-2] * 10); /* might add a little spread to the 
+hash */
+ tmp += (dev_name[i-3] * 100); /* might add a little spread to the 
+hash */
+ }
+ #ifdef FDL_DEBUG
+ printk(KERN_ERR "fdl_calc_name_idx, rslt: %i\n", (int)(tmp % FDL_HASH_LEN));
+ #endif
+ return (tmp % FDL_HASH_LEN);
+ }
+ 
+ int fdl_calc_index_idx(const int ifindex) {
+ return (ifindex % FDL_HASH_LEN);
+ }
+ 
+ 
+ /* Better have a lock on the dev_base before calling this... */
+ int __fdl_ensure_init(void) {
+ #ifdef FDL_DEBUG
+ printk(KERN_ERR "__fdl_ensure_init, enter\n");
+ #endif
+ if (! fdl_initialized_yet) {
+ /* only do this once.. */
+ int i;
+ int idx = 0; /* into the hash table */
+ struct net_device* dev = dev_base;
+ struct dev_hash_node* dhn;
+ 
+ #ifdef FDL_DEBUG
+ printk(KERN_ERR "__fdl_ensure_init, doing real work...");
+ #endif
+ 
+ fdl_initialized_yet = 1; /* it has been attempted at least... */
+ 
+ for (i = 0; iname, idx);
+ #endif
+ /* first, take care of the hash-by-name */
+ idx = fdl_calc_name_idx(dev->name);
+ dhn = kmalloc(sizeof(struct dev_hash_node), GFP_ATOMIC);
+ if (dhn) {
+ dhn->dev = dev;
+ dhn->next = fdl_name_base[idx];
+ fdl_name_base[idx] = dhn;
+ }
+ else {
+ /* Nasty..couldn't get memory... */
+ return -ENOMEM;
+ }
+ 
+ /* now, do the hash-by-idx */
+ idx = fdl_calc_index_idx(dev->ifindex);
+ dhn = kmalloc(sizeof(struct dev_hash_node), GFP_ATOMIC);
+ if (dhn) {
+ dhn->dev = dev;
+ dhn->next = fdl_idx_base[idx];
+

Re: 500 ms offset in i386 Real Time Clock setting

2001-01-06 Thread Kurt Roeckx


On Sat, Jan 06, 2001 at 11:35:52AM -0800, [EMAIL PROTECTED] wrote:
> Neither hwclock nor the /dev/rtc driver takes the following comment from
> set_rtc_mmss() in arch/i386/kernel/time.c into account.  As a result, using
> hwclock --systohc or --adjust always leaves the Hardware Clock 500 ms ahead of
> the System Clock:

I mailed a patch to Andries Brouwer yesterday for exactly the
same problem if hwclock writes writes to the cmos directly, and
said to check if other places have the same problem.

I added an usleep() of 500 ms in cmos.c


Kurt

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

Re: Journaling: Surviving or allowing unclean shutdown?

2001-01-06 Thread Stefan Traby

On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:

> reply. Sure, you can do virtual log replays, but for example the reiserfs
> log is currently 32mb. Pinning down that much memory for a virtual log
> reply is not possible on low-memory machines.

Nobody with working brain would read it completely into memory.
One just put the block-# that are in the journal into a hash-table
and read the block out of the journal when it's requested.
Because there may be multiple copies of the same block in the
journal, one should take the newest one that can be found in
the last commited transaction.

IMHO Chris Mason already wrote such code, at least he talked about
it...

-- 

  ciao - 
Stefan

" ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so ) "

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe   mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0 link error with modular PCMCIA

2001-01-06 Thread Jochen Friedrich


Hi,

problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are
compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o...

Cheers,
Jochen

make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/char/drm/drm.o
drivers/net/tokenring/tr.a drivers/atm/atm.o drivers/ide/idedriver.o
drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o
drivers/net/pcmcia/pcmcia_net.o drivers/video/video.o drivers/acpi/acpi.o
drivers/md/mddev.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
ld: cannot open drivers/net/pcmcia/pcmcia_net.o: No such file or directory
make: *** [vmlinux] Error 1

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_M686FXSR is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_RTC_IS_GMT=y
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
CONFIG_PNP=m
CONFIG_ISAPNP=m

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_BLK_DEV_LVM=m
CONFIG_LVM_PROC_FS=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not

Re: Journaling: Surviving or allowing unclean shutdown?

2001-01-06 Thread Marc Lehmann

On Fri, Jan 05, 2001 at 11:58:56AM +, David Woodhouse <[EMAIL PROTECTED]> wrote:
> You mount it read-only, recover as much as possible from it, and bin it.
> 
> You _don't_ want the fs code to ignore your explicit instructions not to
> write to the medium, and to destroy whatever data were left.

The problem is: where did you give the explicit instruction? Just that you
define "read-only" as "the medium should not be written" does not mean
everybody else thinks the same.

actually, I regard "ro" mainly as a "hey kernel, I won't handle writes
now, so please don't try it", like for cd-roms or other non-writeale
media, and please filesystem stay in a clean state.

That ro means "the medium is never written" is an assumption that does not
hold for most disks anyway and is, in the case of journlaing filesystems,
often impossible to implement. You simply can't salvage data without a log
reply. Sure, you can do virtual log replays, but for example the reiserfs
log is currently 32mb. Pinning down that much memory for a virtual log
reply is not possible on low-memory machines.

So the first thing would be to precisely define the meaning of the "ro"
flag.  Before this has happened it is ansolutely senseless to argue about
what it means, as it doesn't mean anything at the moment, except (man mount):

  ro Mount the file system read-only.

Which it does even with journaling filesystems...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Framebuffer as a module

2001-01-06 Thread Bryan Mayland

-=da TRoXX=- wrote:

> and i don't get it, who accepts these parameters in the kernel then? i mean
> if i put them in lilo.conf at least SOME thing uses them to set the
> framebuffer right...

The tdfxfb code does.  When compiled into the kernel, there is a function
(tdfxfb_setup) which the kernel calls with the relevant kernel command-line
parameters.  When compiled as a module, this function is ifdef'ed out, as well
it should be, because I don't think that there is a function which is called to
pass the module parameters.  Modules use MODULE_PARM to 'import' their
parameters.  The code is incomplete, perhaps for a reason.  In theory, the
author should add the required MODULE_PARM macros to export the parameters and
then move the code which does anything besides saving the paramter values to
tdfxfb_init, which is called when the module is loaded /and/ after tdfxfb_setup
when compiled into the kernel.  I don't have the time to fix it myself, I don't
even have a machine with Linux and a Voodoo3 card.

> I know this parameter is for modules only that support modedb (modedb.c) but
> tdfxfb supports that(that's why it works in the kernel)...

It does, but only when compiled into the kernel due to the way it does its's
setup.

Bry

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

asm/ vs linux/delay.h (was: Re: 2.4.0)

2001-01-06 Thread Geert Uytterhoeven


On Sat, 6 Jan 2001, Christian T. Steigies wrote:

[ Compiling on m68k ]

> How about this one, 2.4.0 (release) with your new patch. make works fine,
> make modules fails with this:
> In file included from emd.c:20:
> /build/kernel-image/2.4.0/linux/include/asm/delay.h: In function `__const_udelay':
> /build/kernel-image/2.4.0/linux/include/asm/delay.h:33: `loops_per_jiffy' undeclared 
>(first use in this function)
> /build/kernel-image/2.4.0/linux/include/asm/delay.h:33: (Each undeclared identifier 
>is reported only once
> /build/kernel-image/2.4.0/linux/include/asm/delay.h:33: for each function it appears 
>in.)
> make[2]: *** [emd.o] Error 1
> make[2]: Leaving directory `/build/kernel-image/2.4.0/linux/fs/umsdos'
> make[1]: *** [_modsubdir_umsdos] Error 2
> make[1]: Leaving directory `/build/kernel-image/2.4.0/linux/fs'
> make: *** [_mod_fs] Error 2

Drivers should include , not .

Please try the patch below. I only tried to compile fs/umsdos/emd.c for m68k.
I didn't dare to touch the following arch-specific files:

arch/i386/lib/delay.c
arch/i386/kernel/i8259.c
arch/i386/kernel/irq.c
arch/i386/kernel/time.c
arch/i386/kernel/i386_ksyms.c
arch/i386/kernel/visws_apic.c
arch/sparc/kernel/process.c
arch/sparc/kernel/traps.c
arch/sparc/kernel/smp.c
arch/sparc/kernel/sun4d_smp.c
arch/sparc/kernel/sparc_ksyms.c
arch/sparc/kernel/sun4m_smp.c
arch/mips/jazz/reset.c
arch/sparc64/kernel/sparc64_ksyms.c
arch/sparc64/kernel/traps.c
arch/arm/mach-sa1100/hw.c
arch/sh/kernel/irq.c
arch/sh/kernel/sh_ksyms.c
arch/sh/kernel/time.c
arch/ia64/hp/hpsim_console.c
arch/ia64/hp/hpsim_setup.c
arch/ia64/kernel/irq.c
arch/ia64/kernel/irq_ia64.c
arch/ia64/kernel/process.c
arch/ia64/kernel/smp.c
arch/ia64/kernel/time.c
arch/ia64/kernel/unwind.c
arch/ia64/kernel/smpboot.c
arch/ia64/kernel/iosapic.c
arch/ia64/mm/tlb.c
arch/s390/kernel/irq.c
arch/s390/kernel/s390io.c
arch/s390/kernel/time.c

diff -urN linux-2.4.0/drivers/acpi/os.c delay-2.4.0/drivers/acpi/os.c
--- linux-2.4.0/drivers/acpi/os.c   Sun Dec 31 16:19:37 2000
+++ delay-2.4.0/drivers/acpi/os.c   Sat Jan  6 20:41:26 2001
@@ -24,8 +24,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include "acpi.h"
 #include "driver.h"
 
diff -urN linux-2.4.0/drivers/ide/osb4.c delay-2.4.0/drivers/ide/osb4.c
--- linux-2.4.0/drivers/ide/osb4.c  Sat Jan  6 17:15:20 2001
+++ delay-2.4.0/drivers/ide/osb4.c  Sat Jan  6 20:41:20 2001
@@ -46,8 +46,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 #include "ide_modes.h"
diff -urN linux-2.4.0/drivers/net/winbond-840.c delay-2.4.0/drivers/net/winbond-840.c
--- linux-2.4.0/drivers/net/winbond-840.c   Sun Dec 31 16:19:47 2000
+++ delay-2.4.0/drivers/net/winbond-840.c   Sat Jan  6 20:40:37 2001
@@ -127,10 +127,10 @@
 #include 
 #include 
 #include 
+#include 
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
-#include 
 
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Winbond W89c840 Ethernet driver");
diff -urN linux-2.4.0/drivers/sbus/audio/audio.c delay-2.4.0/drivers/sbus/audio/audio.c
--- linux-2.4.0/drivers/sbus/audio/audio.c  Tue Dec 26 15:41:05 2000
+++ delay-2.4.0/drivers/sbus/audio/audio.c  Sat Jan  6 20:41:03 2001
@@ -34,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff -urN linux-2.4.0/drivers/sbus/audio/dbri.c delay-2.4.0/drivers/sbus/audio/dbri.c
--- linux-2.4.0/drivers/sbus/audio/dbri.c   Tue Dec 26 15:41:05 2000
+++ delay-2.4.0/drivers/sbus/audio/dbri.c   Sat Jan  6 20:41:09 2001
@@ -49,12 +49,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff -urN linux-2.4.0/drivers/sbus/char/vfc_dev.c 
delay-2.4.0/drivers/sbus/char/vfc_dev.c
--- linux-2.4.0/drivers/sbus/char/vfc_dev.c Tue Dec 26 15:41:05 2000
+++ delay-2.4.0/drivers/sbus/char/vfc_dev.c Sat Jan  6 20:40:56 2001
@@ -22,13 +22,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff -urN linux-2.4.0/drivers/sbus/dvma.c delay-2.4.0/drivers/sbus/dvma.c
--- linux-2.4.0/drivers/sbus/dvma.c Tue Dec 26 15:06:11 2000
+++ delay-2.4.0/drivers/sbus/dvma.c Sat Jan  6 20:40:50 2001
@@ -8,9 +8,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff -urN linux-2.4.0/drivers/sound/via82cxxx_audio.c 
delay-2.4.0/drivers/sound/via82cxxx_audio.c
--- linux-2.4.0/drivers/sound/via82cxxx_audio.c Sun Dec 31 16:19:50 2000
+++ delay-2.4.0/drivers/sound/via82cxxx_audio.c Sat Jan  6 20:40:42 2001
@@ -34,8 +34,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff -urN linux-2.4.0/

[PATCH] Cleanup of PCI device reporting in IDE driver (2.4.0)

2001-01-06 Thread Peter Denison


Description:
Cleans up the reporting of PCI device numbers when they are printed out by
the PCI IDE driver. The dev->devfn value holds both the device number and
the function number, so it's nicer if they are split out and displayed
separately to the user.

Applies against 2.4.0

--- drivers/ide/ide-pci.c.old   Sat Jan  6 17:51:09 2001
+++ drivers/ide/ide-pci.c   Sat Jan  6 18:09:18 2001
@@ -734,7 +734,7 @@
 
switch(class_rev) {
case 4:
-   case 3: printk("%s: IDE controller on PCI bus %02x dev %02x\n", 
d->name, dev->bus->number, dev->devfn);
+   case 3: printk("%s: IDE controller on PCI bus %02x dev %02x fn 
+%02x\n", d->name, dev->bus->number, dev->devfn >> 3, dev->devfn & 7);
ide_setup_pci_device(dev, d);
return;
default:break;
@@ -757,12 +757,12 @@
break;
}
}
-   printk("%s: IDE controller on PCI bus %02x dev %02x\n", d->name, 
dev->bus->number, dev->devfn);
+   printk("%s: IDE controller on PCI bus %02x dev %02x fn %02x\n", d->name, 
+dev->bus->number, dev->devfn >> 3, dev->devfn & 7);
ide_setup_pci_device(dev, d);
if (!dev2)
return;
d2 = d;
-   printk("%s: IDE controller on PCI bus %02x dev %02x\n", d2->name, 
dev2->bus->number, dev2->devfn);
+   printk("%s: IDE controller on PCI bus %02x dev %02x fn %02x\n", d2->name, 
+dev2->bus->number, dev2->devfn >> 3, dev2->devfn & 7);
ide_setup_pci_device(dev2, d2);
 }
 
@@ -790,10 +790,10 @@
hpt366_device_order_fixup(dev, d);
else if (!IDE_PCI_DEVID_EQ(d->devid, IDE_PCI_DEVID_NULL) || (dev->class >> 8) 
== PCI_CLASS_STORAGE_IDE) {
if (IDE_PCI_DEVID_EQ(d->devid, IDE_PCI_DEVID_NULL))
-   printk("%s: unknown IDE controller on PCI bus %02x device 
%02x, VID=%04x, DID=%04x\n",
-  d->name, dev->bus->number, dev->devfn, devid.vid, 
devid.did);
+   printk("%s: unknown IDE controller on PCI bus %02x device %02x 
+fn %02x, VID=%04x, DID=%04x\n",
+  d->name, dev->bus->number, dev->devfn >> 3, dev->devfn 
+& 7, devid.vid, devid.did);
else
-   printk("%s: IDE controller on PCI bus %02x dev %02x\n", 
d->name, dev->bus->number, dev->devfn);
+   printk("%s: IDE controller on PCI bus %02x dev %02x fn 
+%02x\n", d->name, dev->bus->number, dev->devfn >> 3, dev->devfn & 7);
ide_setup_pci_device(dev, d);
}
 }

-- 
Peter Denison <[EMAIL PROTECTED]>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details

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

[PATCH] PCI device IDs for Intel i815E chipset (2.4.0)

2001-01-06 Thread Peter Denison


Description:
Includes new PCI device IDs for the Intel i815E chipset, and corrects some
of the names for the associated parts of the chipset. This has effects in
the EEPro100 network driver and the PCI IDE driver.

Detail & Justification:
The Intel ICH2 (I/O Controller Hub 2) is used in several chipsets, not
just the 820 (Camino) chipset it is accredited to in the PCI ID database.
Nor is the IDE portion of the ICH2 really a PIIX4 chip, though it is very
similar and PIIX driver works on both. These changes are just
internal macro naming and minor user interface tweaks.

According to Intel there are 3 versions of the I/O Controller hub:
Name   Chip Number Used in "chipset"

ICH82801AA 820, 815, 810E, 810
ICH0   82801AB 820, 810E, 810
ICH2   82801BA 820E, 815E

The difference between the 810E and the 810 is the E version of the 82810
GMCH Host interface. Presumably the choice between an ICH and an ICH0 is
one for the motherboard designer to make...


Patch applies to 2.4.0:

--- include/linux/pci_ids.h Sat Jan  6 17:51:13 2001
+++ include/linux/pci_ids.h.new Sat Jan  6 19:22:51 2001
@@ -1336,6 +1336,9 @@
 #define PCI_DEVICE_ID_INTEL_82430  0x0486
 #define PCI_DEVICE_ID_INTEL_82434  0x04a3
 #define PCI_DEVICE_ID_INTEL_I960   0x0960
+#define PCI_DEVICE_ID_INTEL_82815_00x1130
+#define PCI_DEVICE_ID_INTEL_82815_10x1131
+#define PCI_DEVICE_ID_INTEL_82815_20x1132
 #define PCI_DEVICE_ID_INTEL_82559ER0x1209
 #define PCI_DEVICE_ID_INTEL_82092AA_0  0x1221
 #define PCI_DEVICE_ID_INTEL_82092AA_1  0x1222
@@ -1375,13 +1378,16 @@
 #define PCI_DEVICE_ID_INTEL_82801AB_5  0x2425
 #define PCI_DEVICE_ID_INTEL_82801AB_6  0x2426
 #define PCI_DEVICE_ID_INTEL_82801AB_8  0x2428
-#define PCI_DEVICE_ID_INTEL_82820FW_0  0x2440
-#define PCI_DEVICE_ID_INTEL_82820FW_1  0x2442
-#define PCI_DEVICE_ID_INTEL_82820FW_2  0x2443
-#define PCI_DEVICE_ID_INTEL_82820FW_3  0x2444
-#define PCI_DEVICE_ID_INTEL_82820FW_4  0x2449
-#define PCI_DEVICE_ID_INTEL_82820FW_5  0x244b
-#define PCI_DEVICE_ID_INTEL_82820FW_6  0x244e
+#define PCI_DEVICE_ID_INTEL_82801BA_0  0x2440
+#define PCI_DEVICE_ID_INTEL_82801BA_2  0x2442
+#define PCI_DEVICE_ID_INTEL_82801BA_3  0x2443
+#define PCI_DEVICE_ID_INTEL_82801BA_4  0x2444
+#define PCI_DEVICE_ID_INTEL_82801BA_5  0x2445
+#define PCI_DEVICE_ID_INTEL_82801BA_6  0x2446
+#define PCI_DEVICE_ID_INTEL_82801BAM   0x2448
+#define PCI_DEVICE_ID_INTEL_82801BA_9  0x2449
+#define PCI_DEVICE_ID_INTEL_82801BA_1  0x244b
+#define PCI_DEVICE_ID_INTEL_82801BA0x244e
 #define PCI_DEVICE_ID_INTEL_82810_MC1  0x7120
 #define PCI_DEVICE_ID_INTEL_82810_IG1  0x7121
 #define PCI_DEVICE_ID_INTEL_82810_MC3  0x7122
--- drivers/net/eepro100.c  Thu Dec 21 21:40:27 2000
+++ drivers/net/eepro100.c.new  Thu Jan  4 18:27:16 2001
@@ -2192,7 +2192,7 @@
PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ID1030,
PCI_ANY_ID, PCI_ANY_ID, },
-   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82820FW_4,
+   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_9,
PCI_ANY_ID, PCI_ANY_ID, },
{ 0,}
 };
--- drivers/pci/pci.ids Sat Jan  6 17:51:10 2001
+++ drivers/pci/pci.ids.new Sat Jan  6 19:21:24 2001
@@ -4484,6 +4484,9 @@
1014 0119  Netfinity Gigabit Ethernet SX Adapter
8086 1000  EtherExpress PRO/1000 Gigabit Server Adapter
1030  82559 InBusiness 10/100
+   1130  82815 GMCH Host-Hub Bridge/DRAM Controller
+   1131  82815 GMCH AGP Bridge
+   1132  82815 GMCH Internal Graphics Controller
1161  82806AA PCI64 Hub Advanced Programmable Interrupt Controller
1209  82559ER
1221  82092AA_0
@@ -4565,32 +4568,33 @@
1a21  82840 840 (Carmel) Chipset Host Bridge (Hub A)
1a23  82840 840 (Carmel) Chipset AGP Bridge
1a24  82840 840 (Carmel) Chipset PCI Bridge (Hub B)
-   2410  82801AA ISA Bridge (LPC)
-   2411  82801AA IDE
-   2412  82801AA USB
-   2413  82801AA SMBus
-   2415  82801AA AC'97 Audio
+   2410  82801AA ICH ISA Bridge (LPC)
+   2411  82801AA ICH IDE
+   2412  82801AA ICH USB
+   2413  82801AA ICH SMBus
+   2415  82801AA ICH AC'97 Audio
11d4 0040  SoundMAX Integrated Digital Audio
11d4 0048  SoundMAX Integrated Digital Audio
11d4 5340  SoundMAX Integrated Digital Audio
-   2416  82801AA AC'97 Modem
-   2418  82801AA PCI Bridge
-   2420  82801AB ISA Bridge (LPC)
-   2421  82801AB IDE
-   2422  82801AB USB
-   2423  82801AB SMBus
-   2425  82801AB AC'97 Audio
+   2416  82801AA ICH AC'97 Modem
+   2418  82801AA ICH PCI Bridge
+   2420  82801AB ICH0 ISA Bridge (LPC)
+   2421  82801AB ICH0 IDE
+   2422  82801AB ICH0 USB
+   2423  82801AB ICH0 SMBus
+   2425  82801AB ICH0 AC'97 Audio
11d4 0040  SoundMAX Integrated Digital Audio
11d4 0048  SoundMAX In

Re: How to make VFAT work right in 2.4.0-prereleaseu

2001-01-06 Thread Alan Cox


>   - edit file fs/fat/inode.c, look in the function named
> "fat_notify_change" (at about line 901), where it says:"
>   /* FAT cannot truncate to a longer file */
>   if (attr->ia_valid & ATTR_SIZE) {
>   if (attr->ia_size > inode->i_size)
>   return -EPERM;
>   }
>   ", just delete all of it (or comment it out). This change wich has been
> made in the -prerelease versión, makes Netscape Messenger not to work

If you do that you will corrupt your FAT fs. Very bad idea

>   - apply attached patch made by Eelco Dolstra
> <[EMAIL PROTECTED]>, I am testing and using this patch since
> 13.nov.2000 (a lot of time) and with various versions of the Linux
> 2.4.0-testXX series kernels and it works flawlessly! Without it you get

2.4.0-ac has the truncate to grow stuff. It should just work out of the box.
Let me know if not


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

1 2 >

1 - 100 of 172 matches

Mail list logo