[PATCH] eepro100 and IFF_RUNNING under 2.4

[alex]

Hiho..  While working on some code which tries to monitor physical link status
for ethernet interfaces, I noticed that apparently under the 2.4 kernel, the
eepro100 driver does not reflect link status with the IFF_RUNNING flag as it
used to under 2.2.x.

It looks like a bit of the code in eepro100.c didn't get updated to reflect
some interface changes that happened somewhere in 2.3, so here is a patch which
should fix things (It also adds a bit of code to set things properly on startup as 
well, patch is against kernel 2.4.6).

(I'm not quite sure who to send this to, so I'm sending it to the list)

-alex


--- drivers/net/eepro100.c.orig Mon Jul  2 14:03:04 2001
+++ drivers/net/eepro100.c  Fri Jul 20 13:28:20 2001
@@ -976,6 +976,11 @@
if ((sp->phy[0] & 0x8000) == 0)
sp->advertising = mdio_read(ioaddr, sp->phy[0] & 0x1f, 4);
 
+   if (mdio_read(ioaddr, sp->phy[0], 1) & 0x0004)
+   netif_carrier_on(dev);
+   else
+   netif_carrier_off(dev);
+
if (speedo_debug > 2) {
printk(KERN_DEBUG "%s: Done speedo_open(), status %8.8x.\n",
   dev->name, inw(ioaddr + SCBStatus));
@@ -1088,9 +1093,9 @@
mdio_read(ioaddr, phy_num, 1);
/* If link beat has returned... */
if (mdio_read(ioaddr, phy_num, 1) & 0x0004)
-   dev->flags |= IFF_RUNNING;
+   netif_carrier_on(dev);
else
-   dev->flags &= ~IFF_RUNNING;
+   netif_carrier_off(dev);
}
}
if (speedo_debug > 3) {

Re: SCSI Tape corruption - update

[Gérard Roudier]

On Fri, 20 Jul 2001, Geert Uytterhoeven wrote:

> On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> > New findings:
> >   - The problem doesn't happen with kernels <= 2.2.17. It does happen with all
> > kernels starting with 2.2.18-pre1.
> >   - The only related stuff that changed in 2.2.18-pre1 seems to be the
> > Sym53c8xx driver itself. I'll do some more tests soon to isolate the
> > problem.
> >   - The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
> > individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
> > somewhere?

Not completely. The reason is that I used manual diffing/patching against
various kernel versions and it would be a PITA to resurrect all
intermediate driver versions using these patches. If we consider patches
that went directly to kernel main stream without changing the driver
version, a double PITA it would be. Btw, for sym-2.1.x series, I now use a
CVS tree and each driver release is tagged independently. For those ones,
it will be much more easy to isolate broken changes.

> The problem is indeed introduced by the changes to the Sym53c8xx in 2.2.18-pre1.
> I managed to find some intermediate versions in the 2.3.x series, and here are the
> results:
>   - sym53c8xx-1.3g (from BK linuxppc_2_2): OK
>   - sym53c8xx-1.5e: crash in SCSI interrupt during driver init
>   - sym53c8xx-1.5f: lock up during driver init
>   - sym53c8xx-1.5g: random 32-byte error bursts when writing to tape

That's an interesting result. But 1.5g - 1.3g diffs are probably very
large. Patches available from ftp.tux.org should allow to resurrect
driver versions 1.4, 1.5, 1.5a, 1.5b, 1.5c, 1.5d.

ftp://ftp.tux.org/pub/roudier/drivers/linux/sym53c8xx/README

You may, for example, apply incremental patches that address kernel 2.2.5
to a fresh kernel 2.2.5 tree and extract driver files accordingly.

> Perhaps I can get 1.5e and 1.5g to work using some PPC-specific fixes from the
> 1.3.g driver in the linuxppc_2_2 tree (it differed a bit from the 1.3g in
> Alan's 2.2.17). But even then the changes in 1.5f and 1.5g are rather small,
> compared to the changes between 1.3g and 1.5f.

Some PPC specific changes are very probably not present in my driver
sources. I am unable to help on that point.

> So I'd be very happy if I could get my hand on more intermediate versions.
> Thanks for your help! I _really_ want to nail this one down!
>
> Gr{oetje,eeting}s,

Regards,
  Gérard.



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

2.4.7-pre9 oops

[Paul Larson]

I got this oops message with 2.4.7-pre9 on SuSE 7.2 today.  It happened 
during bootup, from the boot.omsg log, it looks like maybe right after the 
swapspace was added.  Ksymoops parsed oops message is attached below.  Please 
let me know if any other information would help.  I'm not a subscriber, so 
please email me directly.

Thanks,
Paul Larson

ksymoops 2.4.1 on i686 2.4.4-64GB-SMP.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.4-64GB-SMP/ (default)
 -m /boot/System.map (specified)

No modules in ksyms, skipping objects
<4> WARNING: unexpected IO-APIC, please mail
<4>cpu: 0, clocks: 1329068, slice: 664534
<5>ds: no socket drivers loaded!
<1>Unable to handle kernel NULL pointer dereference at virtual address 
007c
<4>c01458f2
<1>*pde = 
<4>Oops: 
<4>CPU:0
<4>EIP:0010:[proc_pid_make_inode+130/176]
<4>EFLAGS: 00010206
<4>eax:    ebx: c145   ecx: cf9ca400   edx: c1056564
<4>esi: cfedc000   edi: 000b   ebp: cf9f0760   esp: cf9f7eb4
<4>ds: 0018   es: 0018   ss: 0018
<4>Process ps (pid: 59, stackpage=cf9f7000)
<4>Stack: c02a52c0 cf9f07c0 c0247b0f c0145b1a cfedc000 c145 000b 
fff4
<4>   cf9ca220 cf9f0760 cf9f06e0 ffea c0136e6b cf9ca220 cf9f0760 
cf9f7f2c
<4>    cf9ca220 cf9f7f84 c0137511 cf9f06e0 cf9f7f2c  
c149c000
<4>Call Trace: [proc_base_lookup+134/536] [real_lookup+83/196] 
[path_walk+1321/1880] [open_namei+134/1404] [filp_open+59/92] 
[sys_open+56/184] [system_call+51/56]
<4>Code: f6 40 7c 01 74 12 8b 83 24 01 00 00 89 41 30 8b 83 34 01 00
Using defaults from ksymoops -t elf32-i386 -a i386
 
Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   f6 40 7c 01   testb  $0x1,0x7c(%eax)
Code;  0004 Before first symbol
   4:   74 12 je 18 <_EIP+0x18> 0018 Before first 
symbol
Code;  0006 Before first symbol
   6:   8b 83 24 01 00 00 mov0x124(%ebx),%eax
Code;  000c Before first symbol
   c:   89 41 30  mov%eax,0x30(%ecx)
Code;  000f Before first symbol
   f:   8b 83 34 01 00 00 mov0x134(%ebx),%eax
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.6-ac5: Filesize limit exceeded

[Ronald Jeninga]

Hi,

might be a limit problem, try 

ulimit -f


Ronald


Gregoire Favre wrote:
> 
> Hello,
> 
> I have just turned to 2.4.6-ac5, and I can't create tar bigger than
> 40Mb, I got Filesize limit exceeded...
> 
> Both on ext2 and reiserfs partitions.
> 
> Any idea why?
> 
> Thanks,
> 
> Greg
> 
> http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]
> 
>   
>Part 1.2Type: application/pgp-signature
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Simple LKM & copy_from_user question (followup)

[David CM Weber]

God(Allah, Ganesh, or whom/whatever) bless you all.  Turns out I am a
dumba** and forgot to define __KERNEL__

Thanks to all for your help.  It's a valuable lesson that I'm sure
newbies make lots of..

Thanks,


Dave Weber
(Feeling somewhat idiotic)

Backbone Security, Inc.
570-422-7900





> -Original Message-
> From: Randy.Dunlap [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 20, 2001 4:39 PM
> To: David CM Weber
> Cc: [EMAIL PROTECTED]
> Subject: Re: Simple LKM & copy_from_user question (followup)
> 
> 
> Hi-
> 
> I'll suggest a few things for you.
> 
> cd to your linux tree and 'make modules'
> Look at the gcc compile string there.
> Try to copy it closely.
> 
> I added -I/path/to/linux/include and -D__KERNEL__
> and compiled your module with no problem.
> 
> If you had included the complete messages, we could have
> seen that it was using /usr/include/linux for header files
> instead of header files from linux/include/* .
> (at least that's what it did on my system)
> 
> ~Randy
> 
> 
> David CM Weber wrote:
> > 
> > Attached is the file I"m having problems with.  I'm compiling it w/
> > 
> > gcc -O3 -c main.c
> > 
> > Thanks in advance,
> > 
> > Dave Weber
> > Backbone Security, Inc.
> > 570-422-7900
> > 
> > > -Original Message-
> > > From: David CM Weber
> > > Sent: Friday, July 20, 2001 12:45 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Simple LKM & copy_from_user question
> > >
> > >
> > > Hello all.  I've been lurking for a while, and I have a quick
> > > question.
> > > I'm in the process of writing my first LKM to mess with the
> > > sys_socketcall function.  I'm looking at the original one for
> > > guidance,
> > > and it makes a call to copy_from_user() to get some
> > > socket-related data.
> > >
> > > So, to use copy_from_user(), I've gathered that I need to #include
> > > , so I do so.
> > >
> > > After including this file, I'm getting the following errors:
> > >
> > >
> > > .../linux/timer.h:21: field 'vec' has incomplete type
> > >
> > > .../asm/uaccess.h::63: dereferencing pointer to incomplete type
> > >
> > >
> > > (This is not a full list of the error message that it's reporting)
> > >
> > > Am I not setting a define correctly?
> > >
> > > I'm using Redhat 7.1, on an Intel P3 system.  It's the 
> latest stable
> > > release (2.4.x ??) of the kernel.
> > >
> > > If you need more information, please let me know.  This has been
> > > troubling me for several days now..
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Simple LKM & copy_from_user question (followup)

[Randy.Dunlap]

Hi-

I'll suggest a few things for you.

cd to your linux tree and 'make modules'
Look at the gcc compile string there.
Try to copy it closely.

I added -I/path/to/linux/include and -D__KERNEL__
and compiled your module with no problem.

If you had included the complete messages, we could have
seen that it was using /usr/include/linux for header files
instead of header files from linux/include/* .
(at least that's what it did on my system)

~Randy


David CM Weber wrote:
> 
> Attached is the file I"m having problems with.  I'm compiling it w/
> 
> gcc -O3 -c main.c
> 
> Thanks in advance,
> 
> Dave Weber
> Backbone Security, Inc.
> 570-422-7900
> 
> > -Original Message-
> > From: David CM Weber
> > Sent: Friday, July 20, 2001 12:45 PM
> > To: [EMAIL PROTECTED]
> > Subject: Simple LKM & copy_from_user question
> >
> >
> > Hello all.  I've been lurking for a while, and I have a quick
> > question.
> > I'm in the process of writing my first LKM to mess with the
> > sys_socketcall function.  I'm looking at the original one for
> > guidance,
> > and it makes a call to copy_from_user() to get some
> > socket-related data.
> >
> > So, to use copy_from_user(), I've gathered that I need to #include
> > , so I do so.
> >
> > After including this file, I'm getting the following errors:
> >
> >
> > .../linux/timer.h:21: field 'vec' has incomplete type
> >
> > .../asm/uaccess.h::63: dereferencing pointer to incomplete type
> >
> >
> > (This is not a full list of the error message that it's reporting)
> >
> > Am I not setting a define correctly?
> >
> > I'm using Redhat 7.1, on an Intel P3 system.  It's the latest stable
> > release (2.4.x ??) of the kernel.
> >
> > If you need more information, please let me know.  This has been
> > troubling me for several days now..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Simple LKM & copy_from_user question (followup)

[Richard B. Johnson]

On Fri, 20 Jul 2001, David CM Weber wrote:

> Attached is the file I"m having problems with.  I'm compiling it w/ 
> 
> gcc -O3 -c main.c
> 
> Thanks in advance,
> 
> 
> Dave Weber
> Backbone Security, Inc.
> 570-422-7900
> 

Top line:

#define __KERNEL__

... compiles without any errors, one warning about an unused variable.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.


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

Re: Loop broken again (2.4.6-ac4)

[Jens Axboe]

On Thu, Jul 19 2001, Adam Schrotenboer wrote:
> Jens,
> 
> Remember several weeks ago when I mentioned a problem w/ ridicyulous 
> mod-use counts w/ loop.o???
> Well, it's back again 2.4.5-ac19 (IIRC) worked fine.
> 
> Basically, the result of attempting sudo losetup -d /dev/loop0 is the 
> following
> 
> ioctl LOOP_CLR_FD Device or resource busy
> 
> strace shows EBUSY
> 
> lsmod shows a use count of 563.

I've had no time to look at this, so feel free to dig in and find out
why the usage count is getting screwed... It's probably just a silly
little bug somewhere, I'm guessing a one-liner fix :-)

-- 
Jens Axboe

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

Re: Simple LKM & copy_from_user question (followup)

[John Polyakov]

On Fri, 20 Jul 2001 16:26:43 -0400
"David CM Weber" <[EMAIL PROTECTED]> wrote:

DCW> Attached is the file I"m having problems with.  I'm compiling it w/ 

DCW> gcc -O3 -c main.c

DCW> Thanks in advance,

There is a Makefile for you in attachment.

Here is lsmod output:
It's work :)

[root@Sombre lkm]# lsmod
Module  Size  Used by
main 836   0  (unused)
NVdriver  660144  15  (autoclean)
[root@Sombre lkm]#


DCW> Dave Weber
DCW> Backbone Security, Inc.
DCW> 570-422-7900

---
WBR. //s0mbre


CC=gcc
MODCFLAGS := -Wall -Wwrite-strings -Wredundant-decls -O2 -DMODULE -D__KERNEL__ -DLINUX 
-I/usr/src/linux/include
MODCFLAGS1:= -O1 -D__KERNEL__ -DMODULE -Wall -DLINUX -I/usr/src/linux/include
main.o:  main.c
$(CC) $(MODCFLAGS1) -c main.c

RE: Simple LKM & copy_from_user question (followup)

[David CM Weber]

Attached is the file I"m having problems with.  I'm compiling it w/ 

gcc -O3 -c main.c

Thanks in advance,


Dave Weber
Backbone Security, Inc.
570-422-7900





> -Original Message-
> From: David CM Weber 
> Sent: Friday, July 20, 2001 12:45 PM
> To: [EMAIL PROTECTED]
> Subject: Simple LKM & copy_from_user question
> 
> 
> Hello all.  I've been lurking for a while, and I have a quick 
> question.
> I'm in the process of writing my first LKM to mess with the
> sys_socketcall function.  I'm looking at the original one for 
> guidance,
> and it makes a call to copy_from_user() to get some 
> socket-related data.
> 
> So, to use copy_from_user(), I've gathered that I need to #include
> , so I do so.  
> 
> After including this file, I'm getting the following errors:
> 
> 
> .../linux/timer.h:21: field 'vec' has incomplete type
> 
> .../asm/uaccess.h::63: dereferencing pointer to incomplete type
> 
> 
> (This is not a full list of the error message that it's reporting)
> 
> Am I not setting a define correctly? 
> 
> I'm using Redhat 7.1, on an Intel P3 system.  It's the latest stable
> release (2.4.x ??) of the kernel.
> 
> 
> 
> If you need more information, please let me know.  This has been
> troubling me for several days now..
> 
> 
> Thanks,
> 
> 
> Dave Weber
> Backbone Security, Inc.
> 570-422-7900
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

 main.c

Linux 2.5

[Thiago Vinhas de Moraes]

Hello all!

I just would like to know what's missing to the start of the development of 
the kernel 2.5, and the mantaince of the 2.4 to go to Alan Cox ?

I'm asking this because I see a very good stability of the 2.4 tree, and the 
need of the start of the development of 2.5.

Currently, 2.4 is just getting small fixes, that could be easily managed by 
Alan.

Does Linus have any schedule to pass the control of 2.4 management to someone 
else, and start developing the great 2.5 kernel?


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

Re: Please suggest me

[Matti Aarnio]

On Fri, Jul 20, 2001 at 02:13:00PM -0400, Dipak Biswas wrote:
> Hi All,
> I'm quite new to linux world. I've a very awkard question for you.
> That is: I'm writting an user process, where I need all outgoing
> IP packets to be blocked and captured. First, is it really possible? If
> yes, how? I don't want to make any kernel source code changes. A wild
> guess: by configuration changes, is it possible to make IP process write
> on to a particular FD which I can read when I require?

Look at how tools like  tcpdump  and  etherreal  do it.
It has been done over and over again -- in userspace tool.

> Thanks,
> dipak

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

Re: Please suggest me

[Richard B. Johnson]

On Fri, 20 Jul 2001, Dipak Biswas wrote:

> Hi All,
> I'm quite new to linux world. I've a very awkard question for you.
> That is: I'm writting an user process, where I need all outgoing
> IP packets to be blocked and captured. First, is it really possible? If
> yes, how? I don't want to make any kernel source code changes. A wild
> guess: by configuration changes, is it possible to make IP process write
> on to a particular FD which I can read when I require?
> 
> Thanks,
> dipak
> 

Get the source-code of `tcpdump` and see how packet capturing is done.
You can also look at `ipchains` to see how to block packets.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.


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

Please suggest me

[Dipak Biswas]

Hi All,
I'm quite new to linux world. I've a very awkard question for you.
That is: I'm writting an user process, where I need all outgoing
IP packets to be blocked and captured. First, is it really possible? If
yes, how? I don't want to make any kernel source code changes. A wild
guess: by configuration changes, is it possible to make IP process write
on to a particular FD which I can read when I require?

Thanks,
dipak

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

Re: 2.4.7-pre9..

[Jens Axboe]

On Fri, Jul 20 2001, Linus Torvalds wrote:
> 
> 
> On Fri, 20 Jul 2001, Jens Axboe wrote:
> >
> > > The paging stuff doesn't use any of this. The paging stuff use the page
> > > cache lock bit, and always has.
> >
> > Paging still hits a request, I assumed that's what the (really really)
> > old comment meant to say.
> 
> No. Tha paging stuff (and _all_ regular IO) uses a regular request, with a
> NULL waiter. That's the normal path. That normal path depends on the
> buffer heads associated with the requests and their "bh->b_end_io()"
> function marking other state up-to-date, and then waits on the page being
> locked.

This is perfectly clear. I'm saying 'paging uses a request just like any
other I/O', and you seem to disagree and restate the same thing?! In
fact the lower layers have no way of knowing what is what, paging or
not.

> The req->sem (and now req->completion) thing is a very different thing: it
> is a "we are waiting for this particular request", and is used when it's
> not really IO and doesn't have a bh, but something that has side effects.
> Like an ioctl that causes a special command to the disk to change some
> parameters, or query the size of the disk or something.

Ditto! Are you reading what I write?

> So the comment has just always been wrong, I think. It may be that the
> original swapping code was doing raw requests instead of real IO, so maybe
> the comment was actually correct back in 1992 or something. My memory
> isn't good enough..

Good, so now you agree that the corrected comment (as per pre9) is crap,
and the patch I sent that changes the wording to:

"Ok, this is an expanded form so that we can use the same
request for paging requests."

is so much better than _you_ mixing ->waiting and ->sem into this paging
or non-paging pool?

But in fact the whole comment block should just be removed. It gives no
useful or additional information.

-- 
Jens Axboe

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

Re: [PATCH] swap usage of high memory (fwd)

[Dirk Wetter]

Hey Marcelo,

thx for your great work! our 4gb system are working way better
now. i am running ac5 (without your inactive_plenty() patch
on top of that) on allmost all (see below) of our big boxes.

also, it looks like the CPU affinity thing bought us also a little
something as far as i was told, which is surprising to me, since we
run normally 2 jobs on the big 4GB SMP machines.

typically top is now like on an ac5 kernel:

18:55pm  up 1 day, 12:34,  3 users,  load average: 2.08, 2.04, 2.00
64 processes: 60 sleeping, 3 running, 1 zombie, 0 stopped
CPU0 states: 87.0% user, 12.0% system, 87.1% nice,  0.0% idle
CPU1 states: 88.0% user, 11.2% system, 88.0% nice,  0.0% idle
Mem:  4057200K av, 3983816K used,   73384K free,   0K shrd,2524K buff
Swap: 14337736K av, 1230256K used, 13107480K free  270296K cached

  PID USER PRI  NI  SIZE SWAP  RSS SHARE   D STAT %CPU %MEM   TIME COMMAND
19038 usersid   15   4 2328M 470M 1.8G  214M  0M R N  89.4 46.8 463:07 ceqsim
19048 usersid   15   4 2328M 469M 1.8G  214M  0M R N  88.5 46.9 462:45 ceqsim
17925 usersid9   0   824   40  784   592  49 S11.9  0.0  30:31 top
24257 dirkw 14   0  10560 1056   828  57 R11.9  0.0   0:01 top
1 root   8   076   12   6464   4 S 0.0  0.0   0:22 init
2 root   8   0 000 0   0 SW0.0  0.0   0:00 keventd
3 root  19  19 000 0   0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
4 root  19  19 000 0   0 SWN   0.0  0.0   0:00 ksoftirqd_CPU1
5 root   9   0 000 0   0 SW0.0  0.0  59:12 kswapd
6 root   9   0 000 0   0 SW0.0  0.0  14:10 kreclaimd
7 root   9   0 000 0   0 SW0.0  0.0   0:12 bdflush
8 root   9   0 000 0   0 SW0.0  0.0   1:16 kupdated

sar reports the system time - with some exceptions- to be better than top
does:

08:00:01  CPU %user %nice   %system %idle
[..]
12:40:02  all  0.05 95.56  3.22  1.17
13:00:01  all  0.05 83.96 14.66  1.32
13:20:01  all  0.07 97.22  1.44  1.27
13:40:01  all  0.34 45.45 10.11 44.10
14:01:34  all  0.12  2.07 90.87  6.94
14:21:34  all  0.10  0.00 94.67  5.23
14:41:34  all  0.37 13.97  8.11 77.55
15:00:00  all  0.13 73.42  7.48 18.97
15:20:00  all  0.14 92.57  4.84  2.44
15:40:00  all  0.15 94.93  4.26  0.65
16:00:02  all  0.14 93.31  4.44  2.12
16:20:02  all  0.14 93.74  4.18  1.94
16:40:02  all  0.15 94.26  4.28  1.31
17:00:04  all  0.13 94.68  4.27  0.92
17:20:04  all  0.14 92.51  4.50  2.85
17:40:04  all  0.14 93.75  4.42  1.69
18:00:07  all  0.13 90.18  4.59  5.11
18:20:07  all  0.14 93.77  4.19  1.90
18:40:07  all  0.12 91.83  3.99  4.06

also i added the swap_state/GFP_HIGHUSER fix from Dave McCracken.
according to the poor statistics i have - two overnight jobs
only - my impression is that this helped, too (i think that were
the exactly same jobs as above):

[..]
03:20:01  all  0.05 93.49  2.22  4.23
03:40:01  all  0.06 96.98  1.72  1.24
04:00:01  all  0.06 95.08  1.79  3.07
04:20:01  all  0.05 96.95  1.22  1.78
04:40:01  all  0.06 94.59  1.56  3.79
05:00:01  all  0.06 94.37  1.86  3.71
05:20:01  all  0.06 96.32  1.32  2.30
05:40:01  all  0.06 94.62  1.84  3.48
06:00:02  all  0.07 96.17  1.42  2.34
06:20:02  all  0.06 94.17  1.61  4.15
06:40:02  all  0.06 96.46  1.92  1.56
07:00:01  all  0.05 92.75  1.53  5.67
07:20:01  all  0.05 95.25  1.67  3.03
07:40:01  all  0.05 94.34  1.97  3.65
08:00:00  all  0.05 94.93  1.20  3.81

08:00:00  CPU %user %nice   %system %idle
08:20:00  all  0.06 93.97  1.83  4.14
08:40:00  all  0.16 96.57  1.67  1.60
09:00:01  all  0.06 94.15  1.49  4.30
09:20:01  all  0.06 95.71  1.67  2.56
09:40:01  all  0.07 95.04  1.89  3.00


i haven't got your patched vmstat running yet. i guess i'll do that
later and send in the logs. also the rsync/[di]cache issue i saw
previously needs some attention and log collection on my side.

forget about the pm i sent you yesterday, i found out myself ;) th

Re: [PATCH] Re: MTD compiling error

[Eric W. Biederman]

David Woodhouse <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] said:
> > /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared
> (first use in this function)

Dave this isn't a sufficient fix.  In particular amd_flash.c has problems,
if you only patch cfi.h.  The problem is local_bh_enable by way of
do_unlock_bh.  Or in particular the changes to asm-i386/softirq.h 

The following should fix every case the changes to softirq.h broke.  I would
love to include linux/interrupt.h but that isn't currently possible.

Eric

--- linux-2.4.6/include/asm-i386/softirq.h  Thu Jul 19 15:33:26 2001
+++ linux-2.4.6.eb1.1/include/asm-i386/softirq.hThu Jul 19 17:19:04 2001
@@ -4,6 +4,12 @@
 #include 
 #include 
 
+/* FIXME getting the declaraion for do_softirq from interrupt.h is an
+ * include nightmare, this needs to be fixed instead of declaring
+ * do_softirq directly.
+ */
+extern asmlinkage void do_softirq(void);
+
 #define __cpu_bh_enable(cpu) \
do { barrier(); local_bh_count(cpu)--; } while (0)
 #define cpu_bh_disable(cpu) \

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

oops on boot 2.4.7-pre9

[Garst R. Reese]

Somebody else reported this. I can't catch the oops to decode,

gcc-3.0
UDP
pre7 works.
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 8
model name  : Mobile Pentium MMX
stepping: 1
cpu MHz : 232.106
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 mmx
bogomips: 463.66

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

two seperate 2.4.x problems...

[PinkFreud]

I am not subscribed to this list, so please CC me in any replies.  Thank 
you.


Hey, all.  I have two entirely seperate problems with 2.4.x kernels, on
two seperate systems.

The first occurs on a UDB (Digital Multia, model VX-51, Intel Pentium
100).  I recently installed Slackware 8.0, which includes 2.4.5.  Within a
day of installing, the kernel paniced.  I did not get a chance to save the
text of the oops.  The second time this happened was early this morning,
within a couple hours after a reboot (under 2.4.6).  Text of the oops and
panic are included below (note that this seems similar to the first one -
I noted, at least, that klogd seems to be listed as the culprit in both
cases).

Unable to handle kernel paging request at virtual address 0119c3c1
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010006
eax: c119a7d8   ebx: 0119c3a4   ecx: 0119c2cc   edx: 004f
esi: 0010   edi: c119e000   ebp: 0119c2c4   esp: c4633e9c
ds: 0018   es: 0018   ss: 0018
Process klogd (pid: 88, stackpage=c4633000)
Stack: c119e000 c119e000 000b c4633f2c c01ac897 c119e000 c119e000 0246
   000b c4633f2c c4633ee8 0286 c4666300 c01ae8ae c119e000 c11e7460
   0401 000b c0107c8f 000b c119e000 c4633f2c 0160 c029fa60
Call Trace: [] [] [] [] [] 
[] []
   [] []

Code: 8a 43 1d 84 c0 7d 09 53 57 e8 5f f9 ff ff eb 0e a9 20 00 00
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

I had to copy this from the screen, so I *may* have typoed some of the
addresses - but I think I got them right.

I previously ran Slackware 7.1 on this system (2.2.16 followed by 2.2.19,
I believe) with no adverse effects.  The problems only started to happen
when I installed Slackware 8.0, and, by extension, the 2.4.x kernels.  I
have not tried 2.2.19 under Slackware 8.0 yet.


The other problem I've been experiencing has to do with SMP and XFree86
4.x.x.  I believe this to be an XFree86 problem, but as they have yet to
respond after several requests for help, and due to the nature of the
problem, it may very well be kernel related.

On a SMP system (dual PIII/1 ghz, VIA chipset) running 2.4.x
(anything up to 2.4.6) kernels and XFree86 4.x.x (I've tried 4.0.1 up to
the current 4.1.0), I can pretty reliably cause the system to lock up.  I
simply start X, switch to a text console, and back to X.  The box locks
up, no keyboard, mouse, or network, and the display is blank.  Only thing
I can do is hit the reset button.  Obviously in such a situation, there
aren't any visible errors, nor are any able to be logged, as nothing is
actually written to disk by the time of the crash.  Under a uniprocessor
kernel, the lockup does *NOT* occur.

Again, I don't know if this is necessarily a kernel problem - trying the
same thing with svgalib doesn't seem to have any adverse effects.


Any help would be *greatly* appreciated.

Thanks!


Mike Edwards

Brainbench certified Master Linux Administrator
http://www.brainbench.com/transcript.jsp?pid=158188
---
Unsolicited advertisments to this address are not welcome.

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

Re: SCSI Tape corruption - update

[Geert Uytterhoeven]

On Sun, 8 Jul 2001, Geert Uytterhoeven wrote:
> New findings:
>   - The problem doesn't happen with kernels <= 2.2.17. It does happen with all
> kernels starting with 2.2.18-pre1.
>   - The only related stuff that changed in 2.2.18-pre1 seems to be the
> Sym53c8xx driver itself. I'll do some more tests soon to isolate the
> problem.
>   - The changes to the Sym53c8xx driver in 2.2.18-pre1 are _huge_. Are the
> individual changes between sym53c8xx-1.3g and sym53c8xx-1.7.0 available
> somewhere?

The problem is indeed introduced by the changes to the Sym53c8xx in 2.2.18-pre1.
I managed to find some intermediate versions in the 2.3.x series, and here are the
results:
  - sym53c8xx-1.3g (from BK linuxppc_2_2): OK
  - sym53c8xx-1.5e: crash in SCSI interrupt during driver init
  - sym53c8xx-1.5f: lock up during driver init
  - sym53c8xx-1.5g: random 32-byte error bursts when writing to tape

Perhaps I can get 1.5e and 1.5g to work using some PPC-specific fixes from the
1.3.g driver in the linuxppc_2_2 tree (it differed a bit from the 1.3g in
Alan's 2.2.17). But even then the changes in 1.5f and 1.5g are rather small,
compared to the changes between 1.3g and 1.5f.

So I'd be very happy if I could get my hand on more intermediate versions.
Thanks for your help! I _really_ want to nail this one down!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

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

qlogicfc driver

[Roland Fehrenbacher]

Hi,

I am testing a SAN setup with a Fibre Channel RAID Controller (GMR) connected
to a QLA2200/QLA2100 via Gadzoox Cappelix Switches. The RAID controller
supports 32 LUNs on configurable SCSI target Ids. In the present case I have 3
RAID sets with pairs (SCSI Id, LUN) (0, 0) (0, 1) (1, 0), i.e. two drives with
LUN 0 and one with LUN 1. While the controller itself sees all the 3 drives
when booting up, under Linux I am only able to see the LUN 0 drives.

Kernel is stock 2.4.6 using the qlogicfc driver. I also tried to set
max_scsi_luns=32, even though the default of 8 should be enough. No success.
Of course, support for multiple LUNs is enabled in the kernel. By the way,
using the beta driver on the qlogic site (qla2x00src-v4.27Beta.tgz) also
doesn't help. So the issue might not even be driver related.

Any ideas anyone?

Thanks.

Cheers,

Roland


Roland Fehrenbacher
transtec AG
Waldhörnlestrasse 18
D-72072 Tübingen
Tel.: +49(0)7071/703-320
Fax: +49(0)7071/703-90320
EMail: [EMAIL PROTECTED]
http://www.transtec.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.7-pre9..

[Linus Torvalds]

On Fri, 20 Jul 2001, Jens Axboe wrote:
>
> > The paging stuff doesn't use any of this. The paging stuff use the page
> > cache lock bit, and always has.
>
> Paging still hits a request, I assumed that's what the (really really)
> old comment meant to say.

No. Tha paging stuff (and _all_ regular IO) uses a regular request, with a
NULL waiter. That's the normal path. That normal path depends on the
buffer heads associated with the requests and their "bh->b_end_io()"
function marking other state up-to-date, and then waits on the page being
locked.

The req->sem (and now req->completion) thing is a very different thing: it
is a "we are waiting for this particular request", and is used when it's
not really IO and doesn't have a bh, but something that has side effects.
Like an ioctl that causes a special command to the disk to change some
parameters, or query the size of the disk or something.

So the comment has just always been wrong, I think. It may be that the
original swapping code was doing raw requests instead of real IO, so maybe
the comment was actually correct back in 1992 or something. My memory
isn't good enough..

Linus

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

Simple LKM & copy_from_user question

[David CM Weber]

Hello all.  I've been lurking for a while, and I have a quick question.
I'm in the process of writing my first LKM to mess with the
sys_socketcall function.  I'm looking at the original one for guidance,
and it makes a call to copy_from_user() to get some socket-related data.

So, to use copy_from_user(), I've gathered that I need to #include
, so I do so.  

After including this file, I'm getting the following errors:


.../linux/timer.h:21: field 'vec' has incomplete type

.../asm/uaccess.h::63: dereferencing pointer to incomplete type


(This is not a full list of the error message that it's reporting)

Am I not setting a define correctly? 

I'm using Redhat 7.1, on an Intel P3 system.  It's the latest stable
release (2.4.x ??) of the kernel.



If you need more information, please let me know.  This has been
troubling me for several days now..


Thanks,


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

RE: Too much memory causes crash when reading/writing to disk

[Matt_Domsch]

> grub stable <= 0.90.0 does not work on Dell 8450s.
> 
> I really like the feature set of grub, but I guess the simplicity of
> lilo should not be undervalued.

grub-0.5.97-3.20010625.src.rpm from Red Hat rawhide works fine on Dell
PowerEdge 8450s.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions
www.dell.com/linux
#2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)!
#3 Unix provider with 18% in the US (Dataquest)!



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

Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))

[Rainer Clasen]

On Fri, Jul 20, 2001 at 12:28:35AM -0700, David S. Miller wrote:
> 
> Rainer Clasen writes:
>  > I am using tulip, dummy, Ben Grear's dot1q VLAN devices and some ISDN
>  > syncppp and ISDN rawip devices are configured (but not actively used),
>  > too.
> 
> Can you test without dummy and VLAN?  Man, I now have to audit that
> friggin' code too :-(

As first step I've removed dummy. Eliminating Vlan is difficult and will take
me some more time. 

I could easily reproduce the oops with several nmap -sS through this router.

# ksymoops -K -L -o /lib/modules/2.4.6/ -m /boot/System.map-2.4.6-obs.1.1  < blurb 
ksymoops 2.4.1 on i586 2.4.1.  Options used
 -V (default)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.6/ (specified)
 -m /boot/System.map-2.4.6-obs.1.1 (specified)

No modules in ksyms, skipping objects
Unable to handle kernel paging request at virtual address 67720a25 printing eip:
c012612a
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 67720a0d   ebx:    ecx: 67720a0d   edx: 
esi: c165d800   edi: c12d2680   ebp: 0060   esp: c0209dd8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0209000)
Stack: c0181e4d f800 c165d800 c0182443 c165d800 c165d800 c12f3000 c12c10a0
   c12f3000 ffee c01853bd c165d800 0020 c165d800  c12c10a0
   c0188935 c165d800 c165d800  0004 c01961cc c019625d c165d800
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] []
   [] [] [] [] [] [] 
[] []
   [] [] [] [] []
Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8

>>EIP; c012612a <__free_pages+2/1c>   <=
Trace; c0181e4d 
Trace; c0182443 
Trace; c01853bd 
Trace; c0188935 
Trace; c01961cc 
Trace; c019625d 
Trace; c018aa56 
Trace; c01938b0 
Trace; c01961b2 
Trace; c01961cc 
Trace; c01938fa 
Trace; c018aa56 
Trace; c019385b 
Trace; c01938b0 
Trace; c0192c69 
Trace; c0192aa8 
Trace; c018aa56 
Trace; c01928f6 
Trace; c0192aa8 
Trace; c0185a8d 
Trace; c0113aff 
Trace; c0107e5d 
Trace; c0105120 
Trace; c0106b60 
Trace; c0105120 
Trace; c0105143 
Trace; c01051a7 
Trace; c0105000 <_stext+0/0>
Code;  c012612a <__free_pages+2/1c>
 <_EIP>:
Code;  c012612a <__free_pages+2/1c>   <=
   0:   8b 41 18  mov0x18(%ecx),%eax   <=
Code;  c012612d <__free_pages+5/1c>
   3:   85 c0 test   %eax,%eax
Code;  c012612f <__free_pages+7/1c>
   5:   7c 11 jl 18 <_EIP+0x18> c0126142 <__free_pages+1a/1c>
Code;  c0126131 <__free_pages+9/1c>
   7:   ff 49 14  decl   0x14(%ecx)
Code;  c0126134 <__free_pages+c/1c>
   a:   0f 94 c0  sete   %al
Code;  c0126137 <__free_pages+f/1c>
   d:   84 c0 test   %al,%al
Code;  c0126139 <__free_pages+11/1c>
   f:   74 07 je 18 <_EIP+0x18> c0126142 <__free_pages+1a/1c>
Code;  c012613b <__free_pages+13/1c>
  11:   89 c8 mov%ecx,%eax
Code;  c012613d <__free_pages+15/1c>
  13:   e8 00 00 00 00call   18 <_EIP+0x18> c0126142 <__free_pages+1a/1c>

Kernel panic: Aiee, killing interrupt handler!

Rainer

-- 
KeyID=759975BD fingerprint=887A 4BE3 6AB7 EE3C 4AE0  B0E1 0556 E25A 7599 75BD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: [MINOR PROBLEM] RTL8139C: transmit timed out

[Masaru Kawashima]

Hi, Rasmus!

On Fri, 20 Jul 2001 11:03:38 +0200 (CEST)
Rasmus Hansen <[EMAIL PROTECTED]> wrote:

> Now the box has been running for nearly a week without any trace of 
> problems, so the patch seems to be fine.

Thank you for your reporting.
The patch has been included in linux-2.4.6-ac3 and above, and also
in linux-2.4.7-pre7 and above.

# Thank you Alan Cox, you've been included my patch for 8139too.c
# in your -ac series.

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

Re: 2.4.6: chattr / lsattr does not work on directories anymore!

[Andreas Dilger]

You write:
> Since kernel 2.4.6, the commands 'lsattr' and 'chattr' do not work
> anymore when applied to directories:
> 
> As root:
> 
> # mkdir x
> # chattr +i x
> chattr: Inappropriate ioctl for device while reading flags on x
> # lsattr -d x
> lsattr: Inappropriate ioctl for device While reading flags on x

This is fixed in the most recent Linus and -ac kernels.  The fix is below.

Cheers, Andreas
==
--- linux-2.4.6.orig/fs/ext2/dir.c  Thu Jun 28 14:28:24 2001
+++ linux-2.4.6-aed/fs/ext2/dir.c   Tue Jul 10 22:59:12 2001
@@ -576,5 +576,6 @@
 struct file_operations ext2_dir_operations = {
read:   generic_read_dir,
readdir:ext2_readdir,
+   ioctl:  ext2_ioctl,
fsync:  ext2_sync_file,
 };
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.6-ac5: Filesize limit exceeded

[Gregoire Favre]

Hello,

I have just turned to 2.4.6-ac5, and I can't create tar bigger than
40Mb, I got Filesize limit exceeded...

Both on ext2 and reiserfs partitions.

Any idea why?

Thanks,

Greg

http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]

 PGP signature

Re: 2.4.6-ac5 and VIA Athlon chipsets

[Disconnect]

Will this fix (or get closer to fixing) the K7-optimization crashes? (I'm
still hoping its something that isn't getting initialized correctly,
rather than just a bug.  BurnK7/BurnMMX work fine, memtest86 and the MMX
memtest work, windows seems to be using the full memory bandwidth, etc.)

On Thu, 19 Jul 2001, Alan Cox did have cause to say:

> Excellent. I hope soon to push the official via fix to Linus. The other good
> news is that I now have some official VIA contacts, so where there is a real 
> need information should flow to the right places.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: realiable crashing with AIC7xxxx driver and vanilla 2.4.6 kernel on KT133(A)

[Justin T. Gibbs]

>** Summary ** 
>aic7xxx driver reliably crashes to(/in?) ahc_handle_seqint() function.

If you are using the stock driver in 2.4.6, you might try upgrading
to version 6.2.0 of the aic7xxx driver from here:

http://people.FreeBSD.org/~gibbs/linux

In the mean time, it would be interesting to know what code is at
0x2c9 in your compiled version of aic7xxx.c.  Just turn on the
EXTRA_FLAGS=-g bit in the aic7xxx Makefile, rebuild your kernel or
module, and do:

gdb aic7xxx.o
(gdb) l *(ahc_handle_seqint+0x2c9)

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

kernel panic with 2.4.3

[Manoj Sharma]

Hi,

I am using 2.4.3 kernel and I am getting kernel panic.
It doesn't happen very regularly so may be difficult to simulate.
I connected my system to serial port and captured the log.
Please suggest a way so that I can track down the problem.
Will KGDB be of any help ?  
Please reply to me directly as I am not on the linux-kernel mailing
list.

Thanks,
Manoj

([EMAIL PROTECTED])



NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax:    ebx: cdfe4000   ecx: cdfe8db8   edx: c0101db8
esi: cdfe4000   edi: c0111654   ebp: cdfe5ba0   esp: cdfe5b90
ds: 0018   es: 0018   ss: 0018
Process test_hal (pid: 217, stackpage=cdfe5000)
Stack: cdfe4000 cdfe4000 c0111654 0046 cdfe5c58 c011192c c0111e54
cdfe4000
    c0111654 c01072a4 cdfe5bc4 0002 0a78 cdfe4000
029e
   db937034 40014588 cdfe5c08  ce280018 0018 
c0214c0f
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] []

Code: 80 3d b0 56 27 c0 00 f3 90 7e f5 e9 2c a5 ef ff 80 3d 00 24
console shuts up ...

Program received signal SIGSEGV, Segmentation fault.
0xc0217900 in stext_lock () at af_packet.c:1864
1864 af_packet.c: No such file or directory.





begin 666 Wipro_Disclaimer.txt
M5&AE($EN9F]R;6%T:6]N(&-O;G1A:6YE9"!A;F0@=')A;G-M:71T960@8GD@
M=&AI6]U(&%R92!N;W1I9FEE9"!T:&%T(&%N
M>2!U2!W87D@;W(@:6X@86YY(&UA;FYE6]U(&AA=F4@http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

realiable crashing with AIC7xxxx driver and vanilla 2.4.6 kernel onKT133(A)

[Janne Pänkälä]

** Summary ** 
aic7xxx driver reliably crashes to(/in?) ahc_handle_seqint() function.

** Explanations **
I updated my motherboard from MVP3 chipset to KT133A (Asus KT7A) board and
now I'm getting Oopses like no tomorrow.

when ever I do something that uses scsi disk more than just a bit it will
crash.

lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:09.0 SCSI storage controller: Adaptec AHA-294x / AIC-7871 (rev 03)

--- /proc/interrupts ---
   CPU0   
  0: 150666  XT-PIC  timer
  1:   4645  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3:224  XT-PIC  serial
  5:  12736  XT-PIC  usb-uhci, usb-uhci
  7:  33581  XT-PIC  aic7xxx
  9:  0  XT-PIC  acpi
 10:  20848  XT-PIC  eth0
 12:  0  XT-PIC  EMU10K1
 14:  6  XT-PIC  ide0
 15: 54  XT-PIC  ide1
NMI:  0 
ERR: 23
MIS:  0
---

what I always seem to get is following (I have kdb patch)

--- CRASH 1 ---
Recovery SCB completes
Recovery code awake
aic7xxx_abort returns 8194
Unable to handle kernel NULL pointer dereference at virtual address 0173
 printing eip:
c01cb819
*pde = 

Entering kdb (current=0xc031c000, pid 0) Oops: Oops
due to oops @ 0xc01cb819
eax = 0xc1355c00 ebx = 0xc1254000 ecx = 0xc1254000 edx = 0x0173
esi = 0xc1258210 edi = 0xc127de00 esp = 0xc031dee0 eip = 0xc01cb819
ebp = 0xc031df2c xss = 0x0018 xcs = 0x0010 eflags = 0x00010006
xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc031deac
kdb> bt
EBP   EIP Function(args)
0xc031df2c 0xc01cb819 ahc_handle_seqint+0x2c9 (0xc127de00, 0x71)
   kernel .text 0xc010 0xc01cb550 0xc01cc4b0
0xc031df54 0xc01c835f ahc_linux_isr+0x17f (0xb, 0xc127de00, 0xc031dfa0, 0x2c0)
   kernel .text 0xc010 0xc01c81e0 0xc01c8440
0xc031df74 0xc01084a0 handle_IRQ_event+0x30 (0xb, 0xc031dfa0, 0xc125d380, 0xc0105190, 
0xc031c000)
   kernel .text 0xc010 0xc0108470 0xc01084d0
0xc031df98 0xc0108632 do_IRQ+0x72
   kernel .text 0xc010 0xc01085c0 0xc0108670
0xc031dfe8 0xc0105232 cpu_idle+0x42
   kernel .text 0xc010 0xc01051f0 0xc0105250
kdb>

--- CRASH 2 ---
(scsi0:A:0:0): Unexpected busfree in Message-out phase
SEQADDR == 0x159
Unable to handle kernel NULL pointer dereference at virtual address 0173
 printing eip:
c01cb819
*pde = 

Entering kdb (current=0xc031c000, pid 0) Oops: Oops
due to oops @ 0xc01cb819
eax = 0xc125c000 ebx = 0xc1254000 ecx = 0xc1254000 edx = 0x0173
esi = 0xc1258000 edi = 0xc127de00 esp = 0xc031dee0 eip = 0xc01cb819
ebp = 0xc031df2c xss = 0x0018 xcs = 0x0010 eflags = 0x00010006
xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc031deac
kdb> bt
EBP   EIP Function(args)
0xc031df2c 0xc01cb819 ahc_handle_seqint+0x2c9 (0xc127de00, 0x71)
   kernel .text 0xc010 0xc01cb550 0xc01cc4b0
0xc031df54 0xc01c835f ahc_linux_isr+0x17f (0x7, 0xc127de00, 0xc031dfa0, 0x1c0)
   kernel .text 0xc010 0xc01c81e0 0xc01c8440
0xc031df74 0xc01084a0 handle_IRQ_event+0x30 (0x7, 0xc031dfa0, 0xc125d380, 0xc0105190, 
0xc031c000)
   kernel .text 0xc010 0xc0108470 0xc01084d0
0xc031df98 0xc0108632 do_IRQ+0x72
   kernel .text 0xc010 0xc01085c0 0xc0108670
0xc031dfe8 0xc0105232 cpu_idle+0x42
   kernel .text 0xc010 0xc01051f0 0xc0105250
kdb>
-

--- /usr/src/linux/.config ---
CONFIG_MK7=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=8
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
CONFIG_AIC7XXX_BUILD_FIRMWARE=y
---

>From linux-kernel mailing list I saw that ppl have had problems with
AIC7xxx on KT chipset. However seems that others have gotten it solved.

Any suggestions are more than welcome and I'll gladly provide any help I
can.

-- 
Janne
echo [EMAIL PROTECTED] | tr acefhiklnptu utpnlkihfeca

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

Re: NFS Client patch

[Chris Mason]

On Friday, July 20, 2001 10:50:57 AM +0200 Trond Myklebust 
<[EMAIL PROTECTED]> wrote:

>> " " == Hans Reiser <[EMAIL PROTECTED]> writes:
> 
>  > The current code does rely on hidden knowledge of the filesytem
>  > on the server, and refuses to operate with any FS that does not
>  > describe a position in a directory as an offset or hash that
>  > fits into 32 or 64 bits.
> 
> I'm not saying that ReiserFS is wrong to question the correctness of
> this. I'm just saying that NFSv2 and v3 are fixed protocols, and that
> it's too late to do anything about them. I read Chris mail as a
> suggestion of creating yet another NQNFS, and this would IMHO be a
> mistake. Better to concentrate on NFSv4 which is meant to be
> extendible.

Ah, then I was unclear...I think that while we certainly could
make linux (or reiserfs) specific changes to NFSvOld, it would be
a really bad idea.  In my mind, the biggest strength behind NFS
is its cross platform support, and maintaining some extension
would only be slightly more fun than daily visits to the dentist ;-)

I also think it is easy to call NFSv4 poorly designed, but much
harder to design it to exploit the strengths of every FS on every
unix flavor.  Shrug, there are tradeoffs everywhere.  

I don't plan on supporting NFSv4 because it is the best network 
filesystem ever made, but because it is in our best interest to 
be compatible with those kinds of industry standards.

-chris

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

OOPS on boot 2.4.7-pre9

[Info]

2.4.7-pre9 oops boot time when trying to activate swap. So, 
here are manually writed parameters from screen, may be 
mistakes.

System works on ReiserFS volumes; kernel .config file is in 
attach.

OOPS: 
CPU: 0
EIP: 0010 []
EFLAGS: 00010296
exx:  ebx: c129 ecx:  edx: c6a1b7c0
esi: 0002 edi: 000b ebp: c0247140 esp: c8af9e68
ds: 0018 es: 0018 ss: 0018

Process pidof (pid:190, stackpage=c8af9000)
Stack
c0214dc0 c6a6e6c0 c0214dc4 c045210 c126c000 c129 000b 
c129
ffea  c013d628 c126fe08 00f0 c6a6e6660 fff4 
c6a1b5e0
c6a6e5e0 c013556f c6a1b5e0 c6a6e660 c8af9f00  c6a1b5e0 
c8f8200c

Call Trace: {"[<" and ">]" omitted when manually typed}
c0145210 c013d628 c013556f c0135c84 c0136445 c013917a c012adc2 
c013529e c012b0c3 c0106dd3

Code: f6 40 7c 01 74 12 8b 83 24 01 00 00 89 42 30 8b 83 34 01 
00

#
# Automatically generated make config: 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 is not set

#
# 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 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# 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_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# 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 is not set

#
# 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 is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_PM is not set
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

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

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# 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=y

#
# Plug and Play configuration
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# 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 is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set

#
#  
#
CONFIG_IPX=y
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#

Re: patch to fs/proc/base.c

[Matti Aarnio]

On Fri, Jul 20, 2001 at 05:59:51PM +0400, Nikita Danilov wrote:
> Date: Fri, 20 Jul 2001 17:59:51 +0400
> From: Nikita Danilov <[EMAIL PROTECTED]>
> To:   [EMAIL PROTECTED]
> Subject: patch to fs/proc/base.c
> 
> Hello, 
> 
> following patch cures oopses in 2.4.7-pre9 when 
> proc_pid_make_inode() is called on task with task->mm == NULL.
> 
> Linus, please apply, if you haven't got a bunch of equivalent patches
> already, which is doubtful.

   He won't.  For two reasons:
- There is better fix which Linus himself posted some hours ago
- Linus does not read (directly)  linux-kernel  list.

> Nikita.

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

newbie creating scatter/gather list

[Oliver Ryan]

Hi all,

I want to create a scatter/gather list for dma from a pci device. I've read 
DMA-mapping.txt and a host of other stuff, but most of it assumes I know 
the 'basics' already, which I don't and can't find.  Kernelnewbies sent me 
here.

I want to use the pci_map_sg() function detailed in DMA-mapping .txt, but 
have to pass an already created scatter list to it.  Can anyone tell me how 
to do it, or where to find details on it (an example program?).

Thanks, the help is needed and appreciated.

Oliver.


Dept. of Physics,
National University of Ireland, Galway,
Galway,
Ireland.

Tel: +353 (0)91 524411 ext. 2716
Fax: +353 (0)91 750584
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

patch to fs/proc/base.c

[Nikita Danilov]

Hello, 

following patch cures oopses in 2.4.7-pre9 when 
proc_pid_make_inode() is called on task with task->mm == NULL.

Linus, please apply, if you haven't got a bunch of equivalent patches
already, which is doubtful.

Nikita.

--- linux-2.4.7-pre9/fs/proc/base.cFri Jul 20 14:57:55 2001
+++ linux-2.4.7-pre9.patched/fs/proc/base.c Fri Jul 20 17:03:23 2001
@@ -670,7 +670,7 @@ static struct inode *proc_pid_make_inode
inode->u.proc_i.task = task;
inode->i_uid = 0;
inode->i_gid = 0;
-   if (ino == PROC_PID_INO || task->mm->dumpable) {
+   if (ino == PROC_PID_INO || (task->mm && task->mm->dumpable)) {
inode->i_uid = task->euid;
inode->i_gid = task->egid;
}

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

Re: Linux Kernel 2.2.19 Available Memory Bug

[Doug McNaught]

"John L. Males" <[EMAIL PROTECTED]> writes:

> The bug I am reporting is that when one sets the amount of memory,
> i.e. 128M, 256M; at the time of booting the 2.2.19 kernel the "Total
> Memory" as reported by KDE, "free", etc is short by a important
> amount.  To be more specific I will detail the results of "free"
> below against the "mem" value passed to the kernel.  Please note for
> the purposes of this test I always had 256MB or ram (2x128MB)
> installed in my system.  The BIOS reports total system memory as
> 262144K.

Not really a bug--the "free" report leaves out the memory devoted to
the kernel, which is unpageable and therefore unavailable to user
apps. 

-Doug
-- 
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time...  --Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: irda smc patch... oops

[Stefani Seibold]

Sorry,

but i had a look on the irda homepage and it seems that there is nothing happening
since more than a year.

I will sent a copy of my patch to [EMAIL PROTECTED] and [EMAIL PROTECTED]

Greetings,
Stefani

Am Freitag, 20. Juli 2001 14:58 schrieben Sie:
> On Fri, Jul 20, 2001 at 12:36:24PM +0100, Stefani Seibold wrote:
> > Hi folks,
> >
> > sorry about the previous patch, it was my test code, which will not
> > work
>
> You should also notify the IRDA maintainer as listed in the MAINTAINERS
> file:  [EMAIL PROTECTED]
>
> Linus and Alan will ignore patches that bypass the subsystem maintainers
> in most cases.
>
> Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.6: chattr / lsattr does not work on directories anymore!

[Marc-Jano Knopp]

Since kernel 2.4.6, the commands 'lsattr' and 'chattr' do not work
anymore when applied to directories:

As root:

# mkdir x
# chattr +i x
chattr: Inappropriate ioctl for device while reading flags on x
# lsattr -d x
lsattr: Inappropriate ioctl for device While reading flags on x
#

The error message also appears when I try to get or set any of the
other ext2 flags. I need the ext2 immutable flag to protect some
of the directories on my system against accidental deletion (be it
my fault or a buggy program).

Kernels < 2.2.6 and 2.2.18 work fine.


Best regards,

  Marc-Jano
  

-- 
http://mjk.c64.org/

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

Re: NFS Client patch

[Hans Reiser]

Trond Myklebust wrote:
> 
> > " " == Hans Reiser <[EMAIL PROTECTED]> writes:
> 
>  > The current code does rely on hidden knowledge of the filesytem
>  > on the server, and refuses to operate with any FS that does not
>  > describe a position in a directory as an offset or hash that
>  > fits into 32 or 64 bits.
> 
> I'm not saying that ReiserFS is wrong to question the correctness of
> this. I'm just saying that NFSv2 and v3 are fixed protocols, and that
> it's too late to do anything about them. I read Chris mail as a
> suggestion of creating yet another NQNFS, and this would IMHO be a
> mistake. Better to concentrate on NFSv4 which is meant to be
> extendible.
> 
>  > But be calm, I am not planning on fixing this myself anytime in
>  > the next year, we have an ugly and hideous hack deployed in
>  > ReiserFS that works, for now I am just saying the folks who
>  > designed NFS did a bad job and resolutely continue doing a bad
>  > job, and if someone wanted to fix it, they could fix cookies to
>  > use filenames instead of byte offsets for those filesytems able
>  > to better use filenames than byte offsets to describe a
>  > position within a directory, and for those clients and servers
>  > who are both smart enough to understand filenames instead of
>  > cookies (able to understand the cookie monster protocol).
> 
> This is something which I believe you raised in the NFSv4 group, and
> which could indeed be a candidate for an NFSv4 extension. After all,
> this is in essence a recognition of the method most NFS clients
> implement for recovering from an EBADCOOKIE error. Why was the idea
> dropped?

Lack of desire to do anything, near as I could tell.

> 
> (Note: As I said, under Linux we're currently hampered when
> considering the above alternatives by the fact that glibc requires the
> ability to lseek() on directories. This is a bug that they could
> easily fix, and it affects not only your suggestion, but also all the
> other suggestions in which one implements non-permanent cookies)

I would be quite happy if you (or anyone) could fix it, sometime in the next 3 years.  

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

Re: bzImage, root device Q

[Jesse Pollard]

On Fri, 20 Jul 2001, D. Stimits wrote:
>When booting to a bzImage kernel, bytes 508 and 509 can be used to name
>the minor and major number of the intended root device (although it can
>be overridden with a command line parameter). Other characteristics are
>also available this way, through bytes in the kernel. rdev makes a
>convenient way to hex edit those bytes.
>
>What I'm more curious about is how does the kernel know what filesystem
>_type_ the root is? Are there similar bytes in the bzImage, and can rdev
>change this? And is there a command line syntax to allow specifying
>filesystem type (e.g., something like "vmlinuz root=/dev/scd0,iso9660"
>or "vmlinuz root=/dev/scd0,xfs")? Or is this limited in some way,
>requiring mount on one or a few known filesystem types ("linux native"
>subset comes to mind), followed by a chroot or pivot_root style command
>(which in turn means no direct root mount of some filesystem types)?

Take a look at fs/super.c - function mount_root().

It reads the file system superblock (from the major/minor specified root
device) and determines the filesystem from that. There is a loop that
cycles through all known (ie built in) file systems until one works.

If none do, then it panics.

-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

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

Re: modules/ksyms/filenames

[Stephen C. Tweedie]

Hi,

On Thu, Jul 19, 2001 at 03:54:00PM -0600, Peter J. Braam wrote:
> I'm trying to export a symbol (journal_begin/end) from
> fs/reiserfs/journal.c. To export the symbols I added to the Makefile:
> export-objs := journal.o
> 
> There is also a file fs/jbd/journal.c which exports symbols. 
> 
> It seems that the two journal.ver files in include/modules/*.ver get
> clobbered.
> 
> Short of renaming files, is there a good solution for this? 

Yes, you can add the EXPORT_SYMBOL to a different source file --- you
don't have to do the export from the same file which defines the
symbol.  linux/kernel/ksyms.c contains exports from all over the rest
of the kernel, for example.  If you pick a reiserfs source file which
already exports symbols and add your exports there, I _think_ it
should work OK.

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

Re: 2.4.7-pre9..

[David Woodhouse]

[EMAIL PROTECTED] said:
> I'm getting ready to do a 2.4.7, but one of the fixes in 2.4.7 is a
> nasty SMP race that was found and made it clear that using an old
> trick of having a semaphore on the stack and doing "down()" on it to
> wait for some event (that would do the "up()") was a really bad idea. 

We need s/up_and_exit/complete_and_exit/ then.

Index: drivers/i2o/i2o_block.c
===
RCS file: /inst/cvs/linux/drivers/i2o/i2o_block.c,v
retrieving revision 1.3.2.25
diff -u -r1.3.2.25 i2o_block.c
--- drivers/i2o/i2o_block.c 2001/07/20 08:52:40 1.3.2.25
+++ drivers/i2o/i2o_block.c 2001/07/20 09:18:16
@@ -61,6 +61,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -187,7 +188,7 @@
  * evt_msg contains the last event.
  */
 static DECLARE_MUTEX_LOCKED(i2ob_evt_sem);
-static DECLARE_MUTEX_LOCKED(i2ob_thread_dead);
+static DECLARE_COMPLETION(i2ob_thread_dead);
 static spinlock_t i2ob_evt_lock = SPIN_LOCK_UNLOCKED;
 static u32 evt_msg[MSG_FRAME_SIZE>>2];
 
@@ -859,7 +860,7 @@
}
};
 
-   up_and_exit(&i2ob_thread_dead,0);
+   complete_and_exit(&i2ob_thread_dead,0);
return 0;
 }
 
@@ -2002,7 +2003,7 @@
printk("waiting...");
}
/* Be sure it died */
-   down(&i2ob_thread_dead);
+   wait_for_completion(&i2ob_thread_dead);
printk("done.\n");
}
 
Index: drivers/i2o/i2o_core.c
===
RCS file: /inst/cvs/linux/drivers/i2o/i2o_core.c,v
retrieving revision 1.3.2.25
diff -u -r1.3.2.25 i2o_core.c
--- drivers/i2o/i2o_core.c  2001/05/14 10:36:06 1.3.2.25
+++ drivers/i2o/i2o_core.c  2001/07/20 09:17:54
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -206,7 +207,7 @@
  */
  
 static DECLARE_MUTEX(evt_sem);
-static DECLARE_MUTEX_LOCKED(evt_dead);
+static DECLARE_COMPLETION(evt_dead);
 DECLARE_WAIT_QUEUE_HEAD(evt_wait);
 
 static struct notifier_block i2o_reboot_notifier =
@@ -905,7 +906,7 @@
dprintk(KERN_INFO "I2O event thread dead\n");
printk("exiting...");
evt_running = 0;
-   up_and_exit(&evt_dead, 0);
+   complete_and_exit(&evt_dead, 0);
}
 
/* 
@@ -3427,7 +3428,7 @@
stat = kill_proc(evt_pid, SIGTERM, 1);
if(!stat) {
printk("waiting...");
-   down(&evt_dead);
+   wait_for_completion(&evt_dead);
}
printk("done.\n");
}
Index: drivers/net/8139too.c
===
RCS file: /inst/cvs/linux/drivers/net/8139too.c,v
retrieving revision 1.1.2.28
diff -u -r1.1.2.28 8139too.c
--- drivers/net/8139too.c   2001/07/19 07:54:26 1.1.2.28
+++ drivers/net/8139too.c   2001/07/20 09:20:09
@@ -152,10 +152,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-
 #define RTL8139_DRIVER_NAME   DRV_NAME " Fast Ethernet driver " DRV_VERSION
 #define PFX DRV_NAME ": "
 
@@ -585,7 +585,7 @@
chip_t chipset;
pid_t thr_pid;
wait_queue_head_t thr_wait;
-   struct semaphore thr_exited;
+   struct completion thr_exited;
u32 rx_config;
struct rtl_extra_stats xstats;
 };
@@ -970,7 +970,7 @@
tp->mmio_addr = ioaddr;
spin_lock_init (&tp->lock);
init_waitqueue_head (&tp->thr_wait);
-   init_MUTEX_LOCKED (&tp->thr_exited);
+   init_completion (&tp->thr_exited);
 
/* dev is fully set up and ready to use now */
DPRINTK("about to register device named %s (%p)...\n", dev->name, dev);
@@ -1632,7 +1632,7 @@
rtnl_unlock ();
}
 
-   up_and_exit (&tp->thr_exited, 0);
+   complete_and_exit (&tp->thr_exited, 0);
 }
 
 
@@ -2138,7 +2138,7 @@
printk (KERN_ERR "%s: unable to signal thread\n", dev->name);
return ret;
}
-   down (&tp->thr_exited);
+   wait_for_completion (&tp->thr_exited);
}
 
DPRINTK ("%s: Shutting down ethercard, status was 0x%4.4x.\n",
Index: drivers/usb/hub.c
===
RCS file: /inst/cvs/linux/drivers/usb/hub.c,v
retrieving revision 1.2.2.41
diff -u -r1.2.2.41 hub.c
--- drivers/usb/hub.c   2001/05/14 09:53:16 1.2.2.41
+++ drivers/usb/hub.c   2001/07/20 09:20:29
@@ -36,7 +36,7 @@
 
 static DECLARE_WAIT_QUEUE_HEAD(khubd_wait);
 static int khubd_pid = 0;  /* PID of khubd */
-static DECLARE_MUTEX_LOCKED(khubd_exited);
+static DECLARE_COMPLETION(khubd_exited);
 
 static int usb_get_hub_descriptor(struct usb_device *dev, void *data, int size)
 {
@

[PATCH] Re: MTD compiling error

[David Woodhouse]

[EMAIL PROTECTED] said:
> /usr/src/linux-2.4.6/include/linux/mtd/cfi.h:387: `do_softirq' undeclared  (first 
>use in this function)

Linus, please apply:

Index: include/linux/mtd/cfi.h
===
RCS file: /inst/cvs/linux/include/linux/mtd/cfi.h,v
retrieving revision 1.1.1.1.2.4
diff -u -r1.1.1.1.2.4 cfi.h
--- include/linux/mtd/cfi.h 2001/06/13 06:41:40 1.1.1.1.2.4
+++ include/linux/mtd/cfi.h 2001/07/20 09:56:41
@@ -1,7 +1,7 @@
 
 /* Common Flash Interface structures 
  * See http://support.intel.com/design/flash/technote/index.htm
- * $Id: cfi.h,v 1.21 2001/06/03 01:32:57 nico Exp $
+ * $Id: cfi.h,v 1.22 2001/07/06 09:29:07 dwmw2 Exp $
  */
 
 #ifndef __MTD_CFI_H__
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 


--
dwmw2


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

Framebuffer woes with 3dfx Voodoo5 5500

[Colin Bayer]

When I boot up my home box, a Pentium III/933MHz with an i810 onboard disabled to make 
way for a 3dfx Voodoo5 5500 PCI, two main problems occur if I boot my framebuffered 
kernel (2.4.7-pre7):

1) It won't support anything over 640x480.  I've got the buffer set up to run in 
1024x768x32, and it reverts to 640x480x32.

2) Corrupted cursors: until I start XFree86, the terminal cursors are corrupted; 
they're maybe 80x60 pixels and rendered as randomly black-and-white pixels.

I know that because 3dfx is now no longer extant, there's fairly little chance that 
this will ever be resolved, but I currently have to boot with my non-frame-buffered 
kernel, which keeps me from seeing *cute widdle Tux* at boot-up. 8-)

 -- Colin


Colin Bayer <[EMAIL PROTECTED]>
Windows emulator for Linux: #include  
int main() { int n = *(int *)NULL; }
fortytwo: Linux kernel 2.4.7-pre7 (i686; 1854.66 BogoMips)


The CompNerd Network: http://www.compnerd.com/
Where a nerd can be a nerd.  Get your free [EMAIL PROTECTED]!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ide-tape & ksyms fixes for 2.4.7-pre9

[Mikael Pettersson]

The patch below fixes two problems in 2.4.7-pre9:
1. Updates drivers/ide/ide-tape.c for the sem->completion changes.
   (It doesn't compile in -pre9 due to the changes in "struct request".)
2. Updates kernel/ksyms.c to export the new completion object functions.
   Needed for modular drivers.

/Mikael

--- linux-2.4.7-pre9/drivers/ide/ide-tape.c.~1~ Fri Jul 20 09:33:25 2001
+++ linux-2.4.7-pre9/drivers/ide/ide-tape.c Fri Jul 20 10:15:34 2001
@@ -419,6 +419,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -978,7 +979,7 @@
int logical_blk_num;/* logical block number */
__u16 wrt_pass_cntr;/* write pass counter */
__u32 update_frame_cntr;/* update frame counter */
-   struct semaphore *sem;
+   struct completion *waiting;
int onstream_write_error;   /* write error recovery active */
int header_ok;  /* header frame verified ok */
int linux_media;/* reading linux-specifc media */
@@ -1886,8 +1887,8 @@
printk("ide-tape: %s: skipping over 
config parition..\n", tape->name);
 #endif
tape->onstream_write_error = OS_PART_ERROR;
-   if (tape->sem)
-   up(tape->sem);
+   if (tape->waiting)
+   complete(tape->waiting);
}
}
remove_stage = 1;
@@ -1903,8 +1904,8 @@
tape->nr_pending_stages++;
tape->next_stage = tape->first_stage;
rq->current_nr_sectors = rq->nr_sectors;
-   if (tape->sem)
-   up(tape->sem);
+   if (tape->waiting)
+   complete(tape->waiting);
}
}
} else if (rq->cmd == IDETAPE_READ_RQ) {
@@ -3064,15 +3065,15 @@
 }
 
 /*
- * idetape_wait_for_request installs a semaphore in a pending request
+ * idetape_wait_for_request installs a completion in a pending request
  * and sleeps until it is serviced.
  *
  * The caller should ensure that the request will not be serviced
- * before we install the semaphore (usually by disabling interrupts).
+ * before we install the completion (usually by disabling interrupts).
  */
 static void idetape_wait_for_request (ide_drive_t *drive, struct request *rq)
 {
-   DECLARE_MUTEX_LOCKED(sem);
+   DECLARE_COMPLETION(wait);
idetape_tape_t *tape = drive->driver_data;
 
 #if IDETAPE_DEBUG_BUGS
@@ -3081,12 +3082,12 @@
return;
}
 #endif /* IDETAPE_DEBUG_BUGS */
-   rq->sem = &sem;
-   tape->sem = &sem;
+   rq->waiting = &wait;
+   tape->waiting = &wait;
spin_unlock(&tape->spinlock);
-   down(&sem);
-   rq->sem = NULL;
-   tape->sem = NULL;
+   wait_for_completion(&wait);
+   rq->waiting = NULL;
+   tape->waiting = NULL;
spin_lock_irq(&tape->spinlock);
 }
 
--- linux-2.4.7-pre9/kernel/ksyms.c.~1~ Fri Jul 20 09:33:29 2001
+++ linux-2.4.7-pre9/kernel/ksyms.c Fri Jul 20 10:54:06 2001
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #if defined(CONFIG_PROC_FS)
@@ -361,6 +362,10 @@
 EXPORT_SYMBOL(add_wait_queue);
 EXPORT_SYMBOL(add_wait_queue_exclusive);
 EXPORT_SYMBOL(remove_wait_queue);
+
+/* completion handling */
+EXPORT_SYMBOL(wait_for_completion);
+EXPORT_SYMBOL(complete);
 
 /* The notion of irq probe/assignment is foreign to S/390 */
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: [MINOR PROBLEM] RTL8139C: transmit timed out

[Rasmus Bøg Hansen]

On Sat, 14 Jul 2001, Masaru Kawashima wrote:

> > Jul 12 20:36:43 wiibroe kernel: NETDEV WATCHDOG: eth0: transmit timed out
> 
> I had the same problem with linux-2.4.6-ac2, and I found a bug
> in the function rtl8139_start_xmit() of 8139too.c.
> 
> Attached patch will fix this bug.

Now the box has been running for nearly a week without any trace of 
problems, so the patch seems to be fine.

Rasmus

-- 
-- [ Rasmus 'Møffe' Bøg Hansen ] ---
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
- [ moffe at amagerkollegiet dot dk ] --


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

Re: NFS Client patch

[Trond Myklebust]

> " " == Hans Reiser <[EMAIL PROTECTED]> writes:

 > The current code does rely on hidden knowledge of the filesytem
 > on the server, and refuses to operate with any FS that does not
 > describe a position in a directory as an offset or hash that
 > fits into 32 or 64 bits.

I'm not saying that ReiserFS is wrong to question the correctness of
this. I'm just saying that NFSv2 and v3 are fixed protocols, and that
it's too late to do anything about them. I read Chris mail as a
suggestion of creating yet another NQNFS, and this would IMHO be a
mistake. Better to concentrate on NFSv4 which is meant to be
extendible.

 > But be calm, I am not planning on fixing this myself anytime in
 > the next year, we have an ugly and hideous hack deployed in
 > ReiserFS that works, for now I am just saying the folks who
 > designed NFS did a bad job and resolutely continue doing a bad
 > job, and if someone wanted to fix it, they could fix cookies to
 > use filenames instead of byte offsets for those filesytems able
 > to better use filenames than byte offsets to describe a
 > position within a directory, and for those clients and servers
 > who are both smart enough to understand filenames instead of
 > cookies (able to understand the cookie monster protocol).

This is something which I believe you raised in the NFSv4 group, and
which could indeed be a candidate for an NFSv4 extension. After all,
this is in essence a recognition of the method most NFS clients
implement for recovering from an EBADCOOKIE error. Why was the idea
dropped?

(Note: As I said, under Linux we're currently hampered when
considering the above alternatives by the fact that glibc requires the
ability to lseek() on directories. This is a bug that they could
easily fix, and it affects not only your suggestion, but also all the
other suggestions in which one implements non-permanent cookies)

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

Re: 2.4.7-pre9..

[Jens Axboe]

On Fri, Jul 20 2001, Linus Torvalds wrote:
> 
> 
> On Fri, 20 Jul 2001, Jens Axboe wrote:
> >
> > Attached are two patches -- one that should fix DAC960 for this new
> > completion scheme, and one that corrects the corrected comment in
> > blkdev.h :-)
> 
> No, the correction of the correction is worse.

?

> The paging stuff doesn't use any of this. The paging stuff use the page
> cache lock bit, and always has.

Paging still hits a request, I assumed that's what the (really really)
old comment meant to say.

> The only thing that uses request completion checking are special commands,
> like the initial SCSI spin-up etc (scsi_init_one()).

Sure, and IDE ide_wait etc.

-- 
Jens Axboe

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

Re: 2.4.7-pre9..

[Linus Torvalds]

On Fri, 20 Jul 2001, Jens Axboe wrote:
>
> Attached are two patches -- one that should fix DAC960 for this new
> completion scheme, and one that corrects the corrected comment in
> blkdev.h :-)

No, the correction of the correction is worse.

The paging stuff doesn't use any of this. The paging stuff use the page
cache lock bit, and always has.

The only thing that uses request completion checking are special commands,
like the initial SCSI spin-up etc (scsi_init_one()).

Linus

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

Re: Oops in 2.4.7-pre9.

[Linus Torvalds]

On Fri, 20 Jul 2001, Andrew Morton wrote:
>
> I tested various other possible problems, such as making
> /sbin/hotplug an elf executable and it looks OK, apart from
> the /proc problem.

Actually, there's a double stupidity in the dumpable testing: it should
really test that the process has a VM, but it should also make sure to
lock that access properly.

This ends up being even more of an issue for ptrace, I think. Sorry for
the screw-up.  I think the real fix should be something along the lines of
this (actually, we should move the whole ptrace executable test into
ptrace_dumpable: right now x86 is the only one that gets the subtle and
unlikely race with a ptrace and a suid executable right with the memory
access ordering things).

Linus


diff -u --recursive --new-file pre9/linux/arch/alpha/kernel/ptrace.c 
linux/arch/alpha/kernel/ptrace.c
--- pre9/linux/arch/alpha/kernel/ptrace.c   Fri Jul 20 01:02:50 2001
+++ linux/arch/alpha/kernel/ptrace.cFri Jul 20 01:01:43 2001
@@ -267,7 +267,7 @@
ret = -EPERM;
if (child == current)
goto out;
-   if ((!child->mm->dumpable ||
+   if ((!ptrace_dumpable(child) ||
 (current->uid != child->euid) ||
 (current->uid != child->suid) ||
 (current->uid != child->uid) ||
diff -u --recursive --new-file pre9/linux/arch/arm/kernel/ptrace.c 
linux/arch/arm/kernel/ptrace.c
--- pre9/linux/arch/arm/kernel/ptrace.c Fri Jul 20 01:02:50 2001
+++ linux/arch/arm/kernel/ptrace.c  Fri Jul 20 01:01:43 2001
@@ -596,7 +596,7 @@
if (request == PTRACE_ATTACH) {
if (child == current)
goto out_tsk;
-   if ((!child->mm->dumpable ||
+   if ((!ptrace_dumpable(child) ||
(current->uid != child->euid) ||
(current->uid != child->suid) ||
(current->uid != child->uid) ||
diff -u --recursive --new-file pre9/linux/arch/cris/kernel/ptrace.c 
linux/arch/cris/kernel/ptrace.c
--- pre9/linux/arch/cris/kernel/ptrace.cFri Jul 20 01:02:51 2001
+++ linux/arch/cris/kernel/ptrace.c Fri Jul 20 01:01:43 2001
@@ -117,7 +117,7 @@
if (request == PTRACE_ATTACH) {
if (child == current)
goto out_tsk;
-   if ((!child->mm->dumpable ||
+   if ((!ptrace_dumpable(child) ||
(current->uid != child->euid) ||
(current->uid != child->suid) ||
(current->uid != child->uid) ||
diff -u --recursive --new-file pre9/linux/arch/i386/kernel/ptrace.c 
linux/arch/i386/kernel/ptrace.c
--- pre9/linux/arch/i386/kernel/ptrace.cFri Jul 20 01:02:52 2001
+++ linux/arch/i386/kernel/ptrace.c Fri Jul 20 01:01:43 2001
@@ -176,7 +176,7 @@
(current->gid != child->gid)) && !capable(CAP_SYS_PTRACE))
goto out_tsk;
rmb();
-   if (!child->mm->dumpable && !capable(CAP_SYS_PTRACE))
+   if (!ptrace_dumpable(child) && !capable(CAP_SYS_PTRACE))
goto out_tsk;
/* the same process cannot be attached many times */
if (child->ptrace & PT_PTRACED)
diff -u --recursive --new-file pre9/linux/arch/ia64/kernel/ptrace.c 
linux/arch/ia64/kernel/ptrace.c
--- pre9/linux/arch/ia64/kernel/ptrace.cFri Jul 20 01:02:52 2001
+++ linux/arch/ia64/kernel/ptrace.c Fri Jul 20 01:01:43 2001
@@ -770,7 +770,7 @@
if (request == PTRACE_ATTACH) {
if (child == current)
goto out_tsk;
-   if ((!child->mm->dumpable ||
+   if ((!ptrace_dumpable(child) ||
(current->uid != child->euid) ||
(current->uid != child->suid) ||
(current->uid != child->uid) ||
diff -u --recursive --new-file pre9/linux/arch/m68k/kernel/ptrace.c 
linux/arch/m68k/kernel/ptrace.c
--- pre9/linux/arch/m68k/kernel/ptrace.cFri Jul 20 01:02:52 2001
+++ linux/arch/m68k/kernel/ptrace.c Fri Jul 20 01:01:43 2001
@@ -120,7 +120,7 @@
if (request == PTRACE_ATTACH) {
if (child == current)
goto out_tsk;
-   if ((!child->mm->dumpable ||
+   if ((!ptrace_dumpable(child) ||
(current->uid != child->euid) ||
(current->uid != child->suid) ||
(current->uid != child->uid) ||
diff -u --recursive --new-file pre9/linux/arch/mips/kernel/ptrace.c 
linux/arch/mips/kernel/ptrace.c
--- pre9/linux/arch/mips/kernel/ptrace.cFri Jul 20 01:02:52 2001
+++ linux/arch/mips/kernel/ptrace.c Fri Jul 20 01:01:43 2001
@@ -68,7 +68,7 @@
if (request == PTRACE_ATTACH) {
if (child == current)
goto out_tsk;
-   if ((!child->mm->dumpable |

Linux Kernel 2.2.19 Available Memory Bug

[John L. Males]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Please note I am not on the Kernel Mailing List so do try to copy me
in with any reply, questions, clarifications, confirmations, et al on
this bug report.

Before I forget I am using SuSE 6.4 with most of the updates from the
base applied, most meaning I generally lag a bit behind at times.  I
am NOT using the SuSE kernel due to bugs introduced into the SuSE
kernel with the SuSE patches/enhancements.  I am using the Linus
2.2.19 Kernel with the OpenWall patches.  System is AMD K6-2 500
based system.  The version of gcc was 2.95.2 to compile the kernel.

The bug I am reporting is that when one sets the amount of memory,
i.e. 128M, 256M; at the time of booting the 2.2.19 kernel the "Total
Memory" as reported by KDE, "free", etc is short by a important
amount.  To be more specific I will detail the results of "free"
below against the "mem" value passed to the kernel.  Please note for
the purposes of this test I always had 256MB or ram (2x128MB)
installed in my system.  The BIOS reports total system memory as
262144K.

"mem=256m"
***

KDE reports 251.09 Total System memory, or 263290880 bytes.

"free -m" indicates "Total Memory" as 251
"free -k" indicates "Total Memory" as 257120
"free -k" indicates "Total Memory" as 263290880

The exact same vaules as noted above are indicated for "mem=262144k",
and "mem=268435546" (256 X 1024 x 1024).

"mem=128m"
***

"free -m" indicates "Total Memory" as 124
"free -k" indicates "Total Memory" as 127344
"free -k" indicates "Total Memory" as 130400256


Regards,

John L. Males
Software I.Q. Consulting
Toronto, Ontario
Canada
20 July 2001 03:47
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 


iQA/AwUBO1fwKPLzhJbmoDZ+EQKQowCfcqeGPdpduaFpTQO1P9XaOlJccHEAn20p
v0V59vV7rrFEvMQCLwzXyO2V
=Ezn3
-END PGP SIGNATURE-

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

bzImage, root device Q

[D. Stimits]

When booting to a bzImage kernel, bytes 508 and 509 can be used to name
the minor and major number of the intended root device (although it can
be overridden with a command line parameter). Other characteristics are
also available this way, through bytes in the kernel. rdev makes a
convenient way to hex edit those bytes.

What I'm more curious about is how does the kernel know what filesystem
_type_ the root is? Are there similar bytes in the bzImage, and can rdev
change this? And is there a command line syntax to allow specifying
filesystem type (e.g., something like "vmlinuz root=/dev/scd0,iso9660"
or "vmlinuz root=/dev/scd0,xfs")? Or is this limited in some way,
requiring mount on one or a few known filesystem types ("linux native"
subset comes to mind), followed by a chroot or pivot_root style command
(which in turn means no direct root mount of some filesystem types)?

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

Re: Oops in 2.4.7-pre9.

[Niels Kristian Bech Jensen]

On Thu, 19 Jul 2001, David S. Miller wrote:

>
> Niels Kristian Bech Jensen writes:
>  > >>EIP; c01467e3<=
>
> This should fix it:
>
It does, thanks.

-- 
Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/

--->>  Stop software piracy --- use free software!  <<---

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

Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))

[David S. Miller]

Rainer Clasen writes:
 > I am using tulip, dummy, Ben Grear's dot1q VLAN devices and some ISDN
 > syncppp and ISDN rawip devices are configured (but not actively used),
 > too.

Can you test without dummy and VLAN?  Man, I now have to audit that
friggin' code too :-(

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