RE: How to optimize routing performance

[Martin Josefsson]

On Fri, 16 Mar 2001, Mårten Wikström wrote:

[much text] 
> Thanks! I'll try that out. How can I tell if the driver supports
> CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are
> tulip-based, can I then use Robert & Jamal's optimised drivers?
> It'll probably take some time before I can do further testing. (My employer
> thinks I've spent too much time on it already...).

I don't really know how to tell except
'grep CONFIG_NET_HW_FLOWCONTROL driverfiles'

You said that the cards where 100Mbit DEC cards, I assumed that by that
you meant that the cards use DECchip 21143 or similar chips.
If that's true you can use Robert & Jamal's optimised drivers.

Sorry to hear that your employer doesn't see the importance in such a test
:)

> FYI, Linux had _much_ better delay variation characteristics than FreeBSD.
> Typically no packet was delayed more than 100usec, whereas FreeBSD had some
> packets delayed about 2-3 msec.

This sounds promising. So Linux had nice variations until it broke down
completely and stopped routing because of all the interrupts. I can almost
guarantee that with the optimised driver and CONFIG_NET_HW_FLOWCONTROL
you'll see a _big_ improvement in routingperformance.

/Martin

-
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(2.4.2): serial.c timedia oneliner (Resend)

[Theodore Tso]

On Fri, Mar 16, 2001 at 09:47:14AM +0100, Gunther Mayer wrote:
> I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
> and even submitted to serial.sourceforge.net but never got a reaction.
> Anybody knows if Ted is still active?

Sorry, life's been a bit busy lately, what with the kernel workshop
organization and other things chewing up huge amounts of my time.
I'll try to get an updated serial driver with the various patches that
I've received integrated together soon.

- Ted
-
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(2.4.2): serial.c timedia oneliner (Resend)

[Gunther Mayer]

Hi,
please apply this oneliner to fix the Timedia/Sunix series PCI cards.

Regards, Gunther


P.S.
I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
and even submitted to serial.sourceforge.net but never got a reaction.
Anybody knows if Ted is still active?


--- linux/drivers/char/serial.c-242-origFri Mar 16 09:32:22 2001
+++ linux/drivers/char/serial.c Fri Mar 16 09:34:32 2001
@@ -4175,7 +4175,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
 gmdiff-lx242-serialc-timedia-oneliner

Patch(2.4.2): isapnp detect fix (wrong checksum)

[Gunther Mayer]

Hi,
this fix lets linux detect cards which don't
have a correct checksum.

These are probably common, it seems isapnptools _silently_
fixes this up !

Please apply if you like, comments welcome.

Regards, Gunther

--- linux/drivers/pnp/isapnp.c-2.4.2-orig   Fri Mar 16 09:08:47 2001
+++ linux/drivers/pnp/isapnp.c  Fri Mar 16 09:21:45 2001
@@ -993,10 +993,15 @@
header[4], header[5], header[6], header[7], header[8]);
printk("checksum = 0x%x\n", checksum);
 #endif
-   if (checksum == 0x00 || checksum != header[8])  /* not valid CSN */
+   /* Don't be strict on the checksum, here !
+   e.g. 'SCM SwapBox Plug and Play' has header[8]==0 (should be: b7)*/
+   if (header[8] == 0)
+   ;
+   else if (checksum == 0x00 || checksum != header[8]) /* not valid 
+CSN */
continue;
if ((card = isapnp_alloc(sizeof(struct pci_bus))) == NULL)
continue;
+
card->number = csn;
card->vendor = (header[1] << 8) | header[0];
card->device = (header[3] << 8) | header[2];
 gmdiff-242-isapnp-checksum-swapbox

Re: [CHECKER] 9 potential copy_*_user bugs in 2.4.1

[Dawson Engler]

> Looks like you've missed at least one place. Have you marked pointer
> arguments of syscalls as tainted? Path in question looks so:

In the exokernel param checker we do, but not for the one in linux ---
most of the pointers seemed to be devices, so I never added it.  Afer
your for bug example, I'll go hack the checker ;-)

>   * if method's argument is ever tainted - all instances of that
> method have that argument tainted.
> 
> Is it possible to implement? The last rule may be tricky - we need to
> remember that field foo of structure bar has tainted nth argument and
> keep track of all functions assigned to foo, either by initialization
> or by direct assignment. Could that be done?

It should be.  We're using a trick similar to this one to build up
equivalence classes of interrupt handlers tracking which functions are
assigned to struct fields, or passed as the same parameter to a
function (request_irq being the prime example).  You'd expect that if 
any function passed/assigned to a given function/field is an 
interrupt handler then the rest are too.

The big win will be when checkers can get at global data structure
initializers.  From an outsiders view, it seems like most device
methods are registered that way.

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

Re: 2.2 and AMD-760MP I/O APIC

[Gregory Maxwell]

On Thu, Mar 15, 2001 at 05:34:18PM -0800, Johannes Erdfelt wrote:
> The I/O APIC code for 2.2 contains a little trick which sets the destination
> to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
> on AMD-760MP systems causing a lockup during boot.
[snip]

I'd love you test your patch! What does it take to become equipt with such a
motherboard? 
-
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: another Cyrix/mtrr problem?

[Joerg Diederich]

Hi David,

David Wragg writes:

+> [EMAIL PROTECTED] (Bob_Tracy) writes:
+>> Unfortunately, when I execute
+>> 
+>> echo "base=0xd800 size=0x10 type=write-combining" >|
+>> /proc/mtrr
+>> 
+>> I get a 2MB region instead of the 1MB region I expected...

+> Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX.
+> The patch below should fix it.

+> Joerg, I think this might well fix your Cyrix mtrr problem also.

Indeed, it does. XFree 4 does create a region with the right size and
even setting the mtrr manually works perfectly. Although only tested
one evening, there were no 'no mtrr found for...' messages in the
syslog anymore.


Thankx a lot,

/J"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: How to optimize routing performance

[Mårten Wikström]

> 
> You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the
> kernel gets _alot_ of interrupts from the NIC and dosn't have 
> any cycles
> left to do anything. So you want to turn this on!
> 
> > At the NordU/USENIX conference in Stockholm (this february) I
> > saw a nice presentation on the flow control code in the Linux
> > networking code and how it improved networking performance.
> > I'm pretty convinced that flow control _should_ be saving your
> > system in this case.
> 
> That was probably Jamal Hadi and Robert Olsson. They have 
> been optimizing
> the tulip driver. These optimizations havn't been integrated with the
> "vanilla" driver yet, but I hope the can integrate it soon.
> 
> They have one version that is very optimized and then they have one
> version that have even more optimizations, ie. it uses polling at high
> interruptload.
> 
> you will find these drivers here:
> ftp://robur.slu.se/pub/Linux/net-development/
> The latest versions are:
> tulip-ss010111.tar.gz
> and
> tulip-ss010116-poll.tar.gz
> 
> > OTOH, if they _are_ enabled, the networking people seem to have
> > a new item for their TODO list. ;)
> 
> Yup.
> 
> You can take a look here too:
> 
> http://robur.slu.se/Linux/net-development/jamal/FF-html/
> 
> This is the presentation they gave at OLS (IIRC)
> 
> And this is the final result:
> 
> http://robur.slu.se/Linux/net-development/jamal/FF-html/img26.htm
> 
> As you can see the throughput is a _lot_ higher with this driver.
> 
> One final note: The makefile in at least 
> tulip-ss010111.tar.gz is in the
> old format (not the new as 2.4.0-testX introduced), but you 
> can copy the
> makefile from the "vanilla" driver and It'lll work like a charm.
> 
> Please redo your tests with this driver and report the 
> results to me and
> this list. I really want to know how it compares against FreeBSD.
> 
> /Martin

Thanks! I'll try that out. How can I tell if the driver supports
CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are
tulip-based, can I then use Robert & Jamal's optimised drivers?
It'll probably take some time before I can do further testing. (My employer
thinks I've spent too much time on it already...).

FYI, Linux had _much_ better delay variation characteristics than FreeBSD.
Typically no packet was delayed more than 100usec, whereas FreeBSD had some
packets delayed about 2-3 msec.

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

Re: [CHECKER] big stack variables

[Dawson Engler]

> [EMAIL PROTECTED] said:
> > As usual, please report any false positives so we can fix our
> > checkers.
> 
> Not a false positive, but a false negative:
> 
> the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and 
> tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c.

Turns out we didn't have CONFIG_DEVFS_FS defined.  Big time fun when it is:

/u2/engler/mc/2.4.1/drivers/char/tty_io.c:1996:tty_register_devfs: 
ERROR:VAR:1996:1996: suspicious var 'tty' = 3112 bytes
/u2/engler/mc/2.4.1/drivers/char/tty_io.c:2007:tty_register_devfs: ERROR:FN:2007:2007: 
function stack consumes = 3146 bytes
/u2/engler/mc/2.4.1/drivers/char/tty_io.c:2031:tty_unregister_devfs: 
ERROR:VAR:2031:2031: suspicious var 'tty' = 3112 bytes
/u2/engler/mc/2.4.1/drivers/char/tty_io.c:2042:tty_unregister_devfs: 
ERROR:FN:2042:2042: function stack consumes = 3148 bytes

Right now we've just gone in and put =y for all options in .config --- is
there a more principled approach that will get more coverage?

> Nice work, BTW.

Thanks!  If you have any other ideas of things to check for, do let us
know.  We're mainly just going after things we've found in comments and
code.  We have about another 600 potential bugs to report, but are
going over them to try to make sure they are reasonable.

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

Re: [CHECKER] 9 potential copy_*_user bugs in 2.4.1

[David S. Miller]

Dawson Engler writes:
 > -
 > [UNKNOWN]  I'm not sure about this: "csum_partial_*" calls the generic
 > cksum routine which does guard against user pointers ---
 > is this redundant paranoia in this case?
 > 
 > /u2/engler/mc/oses/linux/2.4.1/net/ipv4/tcp_output.c:643:tcp_retrans_try_collapse: 
 >ERROR:PARAM:651:643: tainted var 'skb_put' (from line 651) used as arg 0 to 
 >'__constant_memcpy'

csum_partial_copy_nocheck works on kernel pointers.

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

Re: 2.4.2 sparc64 patch for LVM

[David S. Miller]

Patrick Caulfield writes:
 > The patch below fixes the ioctl32.c file so that LVM 0.9 will work
 > on UltraSPARC machines.

I've added this patch to my tree, 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OOPS] report

[Chris Mason]

On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:

>> Ok, I was more talking about the ugliness that is reiserfs_panic (how
>> many times do we need a commented out for(;;)?).  For panic() calling
>> sys_sync, I think there non-filesystem related panics where we do want
>> to sync.
> 
> panic doesn't sync if called from interrupt (thanks $DEITY).
> It is pointless to sync during boot.
> sync from driver panic is not better than one from fs.
> 
> What does it leave? I hadn't checked each panic(), but it seems that
> if we ever want syncing upon panic() it's safer to do sys_sync() by
> hands before calling panic(). If it is actually ever needed, that is.
> 
> 

A quick grep -r shows over 700 panic callers (outside reiserfs).  Most look
like init messages, or things that generally happen during interrupts.
But, I think there are too many to assume that nobody could benefit from a
sync.

Does that mean they _need_ the sync?  Probably not.

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

Re: [OOPS] report

[Alexander Viro]

On Fri, 16 Mar 2001, Chris Mason wrote:

> > I suspect that the right fix is to drop the ->s_lock bogosity along with
> > sys_sync() call in panic()...
> 
> Ok, I was more talking about the ugliness that is reiserfs_panic (how many
> times do we need a commented out for(;;)?).  For panic() calling sys_sync,
> I think there non-filesystem related panics where we do want to sync.

panic doesn't sync if called from interrupt (thanks $DEITY).
It is pointless to sync during boot.
sync from driver panic is not better than one from fs.

What does it leave? I hadn't checked each panic(), but it seems that
if we ever want syncing upon panic() it's safer to do sys_sync() by
hands before calling panic(). If it is actually ever needed, that is.

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

Re: [CHECKER] 9 potential copy_*_user bugs in 2.4.1

[Greg KH]

On Thu, Mar 15, 2001 at 06:24:51PM -0800, Dawson Engler wrote:
> Hi,
> 
> I wrote an extension to gcc that does global analysis to determine
> which pointers in 2.4.1 are ever treated as user space pointers (i.e,
> passed to copy_*_user, verify_area, etc) and then makes sure they are
> always treated that way.
> 
> It found what looks to be 9 errors, and  3 cases I'm not sure about.
> I've tried to eliminate false positives, but if any remain, please let
> me know.



> -
> [BUG] Looks like a bug where the memcpy forgets to use the user_buf pointer.
> 
> /u2/engler/mc/oses/linux/2.4.1/drivers/usb/serial/digi_acceleport.c:1288:digi_write: 
>ERROR:PARAM:1271:1288: tainted var 'buf' (from line 1271) used as arg 1 to 
>'__constant_memcpy'
> 
>   /* copy user data (which can sleep) before getting spin lock */
>   count = MIN( 64, MIN( count, port->bulk_out_size-2 ) );
> Start --->
>   if( from_user && copy_from_user( user_buf, buf, count ) ) {
>   return( -EFAULT );
>   }
> 
>   /* be sure only one write proceeds at a time */
>   /* there are races on the port private buffer */
>   /* and races to check write_urb->status */
> 
>   /* wait for urb status clear to submit another urb */
>   if( port->write_urb->status == -EINPROGRESS
>   || priv->dp_write_urb_in_use ) {
> 
>   /* buffer data if count is 1 (probably put_char) if possible */
>   if( count == 1 ) {
>   new_len = MIN( count,
>   DIGI_OUT_BUF_SIZE-priv->dp_out_buf_len );
> Error --->
>   memcpy( priv->dp_out_buf+priv->dp_out_buf_len, buf,
>   new_len );
>   priv->dp_out_buf_len += new_len;
>   } else {
>   new_len = 0;
> 
> -

Al, Pete, does this patch look good to fix this problem?

(I'll send a separate patch for the other usb-serial problems.)

thanks,

greg k-h

-- 
greg@(kroah|wirex).com


--- digi_acceleport.c.original  Thu Mar 15 21:38:10 2001
+++ digi_acceleport.c   Thu Mar 15 21:38:46 2001
@@ -1285,8 +1285,8 @@
if( count == 1 ) {
new_len = MIN( count,
DIGI_OUT_BUF_SIZE-priv->dp_out_buf_len );
-   memcpy( priv->dp_out_buf+priv->dp_out_buf_len, buf,
-   new_len );
+   memcpy( priv->dp_out_buf+priv->dp_out_buf_len, 
+   from_user ? user_buf : buf, new_len );
priv->dp_out_buf_len += new_len;
} else {
new_len = 0;

Re: [OOPS] report

[Chris Mason]

On Friday, March 16, 2001 12:32:56 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:

> 
> 
> On Fri, 16 Mar 2001, Chris Mason wrote:
> 
>> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
>> > _never_ tries to do any block IO. It looks like a rudiment of something
>> > that hadn't been there for 5 years, if not longer. The same goes for
>> > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here.
>> 
>> Ugh, that should have been dragged out and shot...patch will come in the
>> AM.
>> 
> Unfortunately it's nastier than I thought. panic() does sys_sync(). And
> IMO it really shouldn't. Notice that ->s_lock doesn't prevent
> ->write_inode() and friends from being called.
> 
> I suspect that the right fix is to drop the ->s_lock bogosity along with
> sys_sync() call in panic()...

Ok, I was more talking about the ugliness that is reiserfs_panic (how many
times do we need a commented out for(;;)?).  For panic() calling sys_sync,
I think there non-filesystem related panics where we do want to sync.

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

Re: [OOPS] report

[Chris Mason]

On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:

> 
> 
> On Thu, 15 Mar 2001, David wrote:
> 
>> 2.4.2-ac4
>> 
>> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev 
>> 16:41 (hdd), sector 9512
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00
>> { } Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for
>> command Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer
>> write failed Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at
>> prints.c:332!
> 
> Umm... Chris, I really don't think that panic() (or BUG(), for that
> matter) is an appropriate reaction to IO errors. They are expected
> events, after all...
> 

Nods.  It needs to force a readonly mount instead.

> ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
> _never_ tries to do any block IO. It looks like a rudiment of something
> that hadn't been there for 5 years, if not longer. The same goes for
> ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here.

Ugh, that should have been dragged out and shot...patch will come in the AM.

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

Re: [OOPS] report

[Alexander Viro]

On Fri, 16 Mar 2001, Chris Mason wrote:

> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
> > _never_ tries to do any block IO. It looks like a rudiment of something
> > that hadn't been there for 5 years, if not longer. The same goes for
> > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here.
> 
> Ugh, that should have been dragged out and shot...patch will come in the AM.
> 
Unfortunately it's nastier than I thought. panic() does sys_sync(). And
IMO it really shouldn't. Notice that ->s_lock doesn't prevent ->write_inode()
and friends from being called.

I suspect that the right fix is to drop the ->s_lock bogosity along with
sys_sync() call in panic()...


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

Re: kernel paging oops on massive vfs activity

[Marcelo Tosatti]

On Wed, 14 Mar 2001, Donald J. Barry wrote:

> Hey kernel developers,
> 
> I'm getting repeated oopses and occasional freezes on a server I've
> set up to host a giant (180G) reiserfs system atop lvm, served by nfs(v2).
> (I've applied the reiserfs and nfs patches to the vanilla kernel,
> which is otherwise pretty minimally compiled). They seem to be
> correlated by massive disk activity.  Because this file system has
> many huge directories (2+ files in some) and also many long names
> (some of those giant directories are filled with 40+ character
> filenames) I'm beginning to wonder whether the vfs layer is at fault.
> I got some of the same behavior with an earlier ext2 instance atop
> lvm.  In this case I triggered the result by doing a find atop the 
> tree.  Generally things that access many directory entries trigger it.
> 
> Of course, it could be a remaining hardware glitch on this new tbird
> 1100 system on GA59X motherboard (latest firmware, but it has the 
> troublesome VIA kt133 chipset).
> 
> What use is a server when it oopses when trying to serve?
>
> Any thoughts?

Seems to be inode hash list corruption.

Maybe bad memory. 
  
Can you use the "memtest86" utility to check if your memory is OK? (you
can find it at www.freshmeat.net)


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

Re: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Marcelo Tosatti]

On Thu, 15 Mar 2001, Shane Y. Gibson wrote:

> Marcelo Tosatti wrote:
> >
> > Did'nt you get a message similar to
> > 
> > "kernel BUG at page_alloc.c line xxx!"
> 
> Marcelo,
> 
> Yes there was.  I'm pasting the total sum of the /var/log/messages
> output.  Note that I'm only able to locate details for the first
> crash, the second didn't seem to log a whole lot.  Originally, 
> just pasted the output of what "ksymops" regurgitated, which seems
> to have pulled out that "kernel BUG" reference.  Here goes...

Can you please try to reproduce it with the following patch against 2.4.2? 

With the patch applied it gets easier to find the problem.

Thanks 

--- linux/include/linux/swap.h.orig Fri Mar 16 06:31:51 2001
+++ linux/include/linux/swap.h  Fri Mar 16 06:33:41 2001
@@ -201,7 +201,15 @@
  */
 #define DEBUG_ADD_PAGE \
if (PageActive(page) || PageInactiveDirty(page) || \
-   PageInactiveClean(page)) BUG();
+   PageInactiveClean(page)) { \
+   if (PageActive(page)) \
+   printk (KERN_ERR "Active page on free list!\n"); \
+   if (PageInactiveDirty(page)) \
+   printk (KERN_ERR "Inactive dirty page on free list!\n"); \
+   if (PageInactiveClean(page)) \
+   printk (KERN_ERR "Inactive clean page on free list!\n"); \
+   BUG(); \
+   }
 
 #define ZERO_PAGE_BUG \
if (page_count(page) == 0) BUG();


-
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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Andrew Morton]

"Shane Y. Gibson" wrote:
> 
> 2.4.2
...
> dual PIII 750s
...
> panicing, and freezing up.


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

Re: [CHECKER] 9 potential copy_*_user bugs in 2.4.1

[Alexander Viro]

On Thu, 15 Mar 2001, Dawson Engler wrote:

> Hi,
> 
> I wrote an extension to gcc that does global analysis to determine
> which pointers in 2.4.1 are ever treated as user space pointers (i.e,
> passed to copy_*_user, verify_area, etc) and then makes sure they are
> always treated that way.
> 
> It found what looks to be 9 errors, and  3 cases I'm not sure about.
> I've tried to eliminate false positives, but if any remain, please let
> me know.

Looks like you've missed at least one place. Have you marked pointer
arguments of syscalls as tainted? Path in question looks so:

* 2nd argument of sys_write() (buf) is tainted  [SYSCALL]
* sys_write() passes buf  as 2nd argument to file_operations::write()
  (fs/read_write.c:159-160)
* proc_file_write() is an instance of the above (buffer is the 2nd argument)
  (fs/proc/generic.c:36--40)
* proc_file_write() passes buffer as 2nd argument to
proc_dir_entry::write_proc() (fs/proc/generic.c:136)
* proc_write_register() is an instance of the above (buffer is the 2nd
argument) (fs/binfmt_misc.c:494)
* proc_write_register() directly dereferences buffer. (fs/binfmt_misc.c:298)
(line numbers as per 2.4.2, 2.4.1 is essentially the same)

And yes, that's an oopsable bug (fixed in more or less recent -ac).
Since a lot of code is only accessed as methods... If you could add support
for that kind of checks you'd probably find much more.

Relevant rules:
* all arguments of syscalls are tainted. Casting can't change that.
* verify_area() cleans the value, but you'll be better off
considering these as dangerous - it only checks that range is OK and if
pointer arithmetics moves you out of that range or you access piece longer
than range in question...
* if method's argument is ever tainted - all instances of that
method have that argument tainted.

Is it possible to implement? The last rule may be tricky - we need to
remember that field foo of structure bar has tainted nth argument and
keep track of all functions assigned to foo, either by initialization
or by direct assignment. Could that be done?
Cheers,
Al

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

Re: [CHECKER] big stack variables

[Andrew Morton]

Jeff Dike wrote:
> 
> [EMAIL PROTECTED] said:
> > As usual, please report any false positives so we can fix our
> > checkers.
> 
> Not a false positive, but a false negative:
> 
> the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and
> tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c.

and sanitize_e820_map()

> Nice work, BTW.

Yep.

-
-
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: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20

[Michail Brzitwa]

In article <[EMAIL PROTECTED]> you wrote:
> The real problem is that our disks usually do not have a volume label.
> Outside of all file systems.
> The "signatures" that we rely on today are located in different places,
> so that a filesystem can have several valid signatures at the same time.
> And we first know where to look when we know the type already.
>
> Design a Linux partition table format, where a partition descriptor
> has fields start, end, fstype, fslabel, and the whole disk has a vollabel.
> Put it in sector 0-N for an all-Linux disk, and in sectors pointed at
> by a classical DOS-type partition table entry when the disk is shared.

I don't understand that. Do you propose something like *BSD or Solaris
disklabels? In that case a whole new set of user utilities would be
needed to create your new tables as well as maintaining the old style
partition tables.

The process of copying or moving fs around disks seems to be quite common
as tools like partition magic or parted suggest. Your idea would make
that process more difficult and less user-friendly. It should imho always
be simple to backup an fs to tape from a dying disk and restore it to
a new one without losing the label etc.

Perhaps putting this kind of information into a generalized start sector
for all Linux fs would be a better idea (is that what you meant?). Copying
an fs would again be as easy as using dd or cp. Of course this means
that most Linux fs types including swap partitions should leave this
start sector alone. A common mkfs would create that leading block after
the mkfs. successfully created the fs meta-contents.

It would be optimal imho if the partition table entry contains the start
sector and size only, and all other information like type, uuid, label
etc. is within the fs disk space. No out-of-band fs information anymore.

The disk volume label should be located outside all fs as you mentioned
but separated from the actual fs labels.
-- 
Michail Brzitwa   <[EMAIL PROTECTED]>+49-511-343215
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] big stack variables

[Jeff Dike]

[EMAIL PROTECTED] said:
> As usual, please report any false positives so we can fix our
> checkers.

Not a false positive, but a false negative:

the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and 
tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c.

Nice work, BTW.

Jeff


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

kernel benchmark

[gis88530]

Hi,

I use kernprof+gprof to measure the 2.2.16 kernel,
but the scale is mini-second. 
So I use do_gettimeofday( ) kernel function call to measure 
the latency. (This function support micro-second scale.)

Moreover, I use SmartBits packet generator to generate
the specific network traffic load. The environment is
as follows. However, the result are very funny. I think 
that latency should increase progressively when load
increase, but the result are unable explaining.
Could you give me some hint? Thanks a lot.

1518byte packet
loadlatency(us)
1%13.1284
10%14.1629
20%12.6558
30%11.1056
40%10.7510
50%10.4148
60%10.3337
70%10.1038
80%10.1103
90%10.3634
100%11.2367

64byte packet
loadlatency(us)
1%3.6767
10%2.7696
20%4.3926
30%2.8135
40%8.2552
50%5.3088
60%9.3744
70%23.6247
80%8.5351
90%9.7217
100%13.065

Benchmark Environment:
+---smartbits<---+
| |
+>Linux-+


* The do_gettimeofday function call is as follows:
--
do_gettimeofday(&begin);
...
(kernel do something)
...
do_gettimeofday(&end);
if (end.tv_usec < begin.tv_usec) {
end.tv_usec += 100; end.tv_sec--;
}
end.tv_sedc -= begin.tv_sec;
end.tv_usec -= begin.tv_usec;
return ((end.tv_sec*100) + end.tv_usec);


-
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: Performance is weird (fwd) -> results

[Sampsa Ranta]

On Thu, 15 Mar 2001, Manfred Spraul wrote:

> I've attached a patch.
> I tried to trigger the problem with my 10 MBit ne2k-pci connection, but
> without success.
>
> Could you try it?
> I've tested it with -ac17, and it applies to 2.4.2 cleanly.

On 2.4.2:

Before:
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 3.829257 real seconds = 4278.636822 KB/sec
(35.050593 Mb/sec)

After either of your patches, the result was the same, sorry.

I tried to apply the patch to 2.4.3 and still got the better result with
it, altought compiling kernel still improved the performance.

First:

[root@ropogw test]# ./ttcp_atm -t -a -s 0.90
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.994121 real seconds = 8216.151377 KB/sec
(67.306712 Mb/sec)
[root@ropogw test]# ./ttcp_atm -t -a -s 0.90
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.995773 real seconds = 8209.350462 KB/sec
(67.250999 Mb/sec)
[root@ropogw test]# ./ttcp_atm -t -a -s 0.90
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.989680 real seconds = 8234.489968 KB/sec
(67.456942 Mb/sec)

(start to compile kernel on other console)

[root@ropogw test]# ./ttcp_atm -t -a -s 0.90
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.072744 real seconds = 15272.982184 KB/sec
(125.116270 Mb/sec)
[root@ropogw test]# ./ttcp_atm -t -a -s 0.90
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  atm  -> 0.90
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.140261 real seconds = 14368.640162 KB/sec
(117.70790

I also applied it the test to the 3com card:

Before kernel compiling, patch applied or not:

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  udp  ->
not.for.your.eyes
ttcp-t: socket
ttcp-t: 16777216 bytes in 2.218013 real seconds = 7386.791691 KB/sec
(60.512598 Mb/sec)

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013  udp  ->
not.for.your.eyes
ttcp-t: socket
ttcp-t: 16777216 bytes in 1.428264 real seconds = 11471.268617 KB/sec
(93.972633 Mb/sec)

Thanks,

  Sampsa Ranta
  [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] report

[Alexander Viro]

On Thu, 15 Mar 2001, David wrote:

> 2.4.2-ac4
> 
> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev 
> 16:41 (hdd), sector 9512
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00 { }
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer write failed
> Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at prints.c:332!

Umm... Chris, I really don't think that panic() (or BUG(), for that matter)
is an appropriate reaction to IO errors. They are expected events, after
all...

ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() _never_
tries to do any block IO. It looks like a rudiment of something that hadn't
been there for 5 years, if not longer. The same goes for ext2_panic() and
ufs_panic(), BTW... I would suggest crapectomey here.
Cheers,
Al

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

Reserved memory for highmem bouncing (fwd)

[Marcelo Tosatti]

Ingo, 

Any comments? 

-- Forwarded message --
Date: Wed, 28 Feb 2001 02:02:16 -0300 (BRT)
From: Marcelo Tosatti <[EMAIL PROTECTED]>
To: Ingo Molnar <[EMAIL PROTECTED]>
Cc: lkml <[EMAIL PROTECTED]>
Subject: Reserved memory for highmem bouncing  


Hi Ingo,

I have a question about the highmem page IO deadlock fix which is in
2.4.2-ac. (the emergency memory thing)

The old create_bounce code used to set PF_MEMALLOC on the task flags and
call wakeup_bdflush(1) in case GFP_BUFFER page allocation failed. That was
broken because flush_dirty_buffers() could try to flush a buffer pointing
to highmem page, which would end up in create_bounce again, but with
PF_MEMALLOC.

Have you tried to make flush_dirty_buffers() only flush buffers pointing
to lowmem pages in case the caller wants it to do so?

This way you can call flush_dirty_buffers() with the guarantee you're
going to free useful (lowmem) memory. This also throttles high mem writes
giving priority to low mem ones.



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

[CHECKER] big stack variables

[Dawson Engler]

Hi,

enclosed are 22 functions in 2.4.1 that appear to allocate stack
variables >= 1024 bytes.  As usual, please report any false positives
so we can fix our checkers.

Dawson
---
/u2/engler/mc/2.4.1/drivers/isdn/sc/message.c:52:dump_messages: ERROR:VAR: suspicious 
sized variable: 'dpm' = 4112 bytes
/u2/engler/mc/2.4.1/drivers/sound/emu10k1/audio.c:906:emu10k1_audio_ioctl: ERROR:VAR: 
suspicious sized variable: 'buf' = 4016 bytes
/u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:955:i2o_proc_read_drivers_stored: 
ERROR:VAR: suspicious sized variable: 'result' = 3596 bytes
/u2/engler/mc/2.4.1/drivers/scsi/qlogicfc.c:861:isp2x00_make_portdb: ERROR:VAR: 
suspicious sized variable: 'temp' = 3072 bytes
/u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:840:i2o_proc_read_ddm_table: ERROR:VAR: 
suspicious sized variable: 'result' = 2828 bytes
/u2/engler/mc/2.4.1/drivers/cdrom/optcd.c:1625:cdromread: ERROR:VAR: suspicious sized 
variable: 'buf' = 2646 bytes
/u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:2261:i2o_proc_read_lan_mcast_addr: 
ERROR:VAR: suspicious sized variable: 'result' = 2060 bytes
/u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:2492:i2o_proc_read_lan_alt_addr: ERROR:VAR: 
suspicious sized variable: 'result' = 2060 bytes
/u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:1044:i2o_proc_read_groups: ERROR:VAR: 
suspicious sized variable: 'result' = 2060 bytes
/u2/engler/mc/2.4.1/fs/ntfs/super.c:335:ntfs_get_free_cluster_count: ERROR:VAR: 
suspicious sized variable: 'bits' = 2048 bytes
/u2/engler/mc/2.4.1/drivers/atm/iphase.c:2760:ia_ioctl: ERROR:VAR: suspicious sized 
variable: 'regs_local' = 2048 bytes
/u2/engler/mc/2.4.1/drivers/block/cpqarray.c:1156:ida_ioctl: ERROR:VAR: suspicious 
sized variable: 'my_io' = 1296 bytes
/u2/engler/mc/2.4.1/net/wanrouter/wanmain.c:578:device_new_if: ERROR:VAR: suspicious 
sized variable: 'conf' = 1220 bytes
/u2/engler/mc/2.4.1/drivers/net/zlib.c:4216:huft_build: ERROR:VAR: suspicious sized 
variable: 'v' = 1152 bytes
/u2/engler/mc/2.4.1/drivers/net/zlib.c:4501:inflate_trees_fixed: ERROR:VAR: suspicious 
sized variable: 'c' = 1152 bytes
/u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:734:cdrom_slot_status: ERROR:VAR: suspicious 
sized variable: 'info' = 1032 bytes
/u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:800:cdrom_select_disc: ERROR:VAR: suspicious 
sized variable: 'info' = 1032 bytes
/u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:758:cdrom_number_of_slots: ERROR:VAR: 
suspicious sized variable: 'info' = 1032 bytes
/u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:1538:cdrom_ioctl: ERROR:VAR: suspicious 
sized variable: 'info' = 1032 bytes
/u2/engler/mc/2.4.1/fs/nfs/nfsroot.c:238:root_nfs_name: ERROR:VAR: suspicious sized 
variable: 'buf' = 1024 bytes
/u2/engler/mc/2.4.1/net/bridge/br_ioctl.c:86:br_ioctl_device: ERROR:VAR: suspicious 
sized variable: 'indices' = 1024 bytes
/u2/engler/mc/2.4.1/drivers/isdn/pcbit/drv.c:444:pcbit_writecmd: ERROR:VAR: suspicious 
sized variable: 'cbuf' = 1024 bytes
-
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/

[CHECKER] 9 potential copy_*_user bugs in 2.4.1

[Dawson Engler]

Hi,

I wrote an extension to gcc that does global analysis to determine
which pointers in 2.4.1 are ever treated as user space pointers (i.e,
passed to copy_*_user, verify_area, etc) and then makes sure they are
always treated that way.

It found what looks to be 9 errors, and  3 cases I'm not sure about.
I've tried to eliminate false positives, but if any remain, please let
me know.

Two questions: 
1. if a verify_area is done to a pointer, can the pointer then
be manipulated raw?  E.g., is this ok?
if(!verify_area(VERIFY_READ, p, sizeof *p)))
tmp = *p;

2.  And, unrelated:  given the current locking discipline, is
it bad to hold any type of lock (not just a spin lock) when you
call a potentially blocking function?  (It at least seems bad
for performance, since you'll hold the lock for milliseconds.)

Dawson
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
  derferences it directly.

ipddp_find derefs this struct.
struct at_addr
{
__u16   s_net;
__u8s_node;
};

/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:274:ipddp_ioctl: 
ERROR:PARAM:277:274: tainted var 'rt' (from line 277) used as arg 0 to 'ipddp_create'

{
case SIOCADDIPDDPRT:
Error --->
return (ipddp_create(rt));

case SIOCFINDIPDDPRT:
Start --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct 
ipddp_route)))
return -EFAULT;
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
  derferences it directly.

/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:277:ipddp_ioctl: 
ERROR:PARAM:277:277: tainted var 'rt' (from line 277) used as arg 0 to 
'ipddp_find_route'


case SIOCFINDIPDDPRT:
Start --->
Error --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct 
ipddp_route)))
return -EFAULT;
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
  derferences it directly.

/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:282:ipddp_ioctl: 
ERROR:PARAM:277:282: tainted var 'rt' (from line 277) used as arg 0 to 'ipddp_delete'


case SIOCFINDIPDDPRT:
Start --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct 
ipddp_route)))
return -EFAULT;
return 0;

case SIOCDELIPDDPRT:
Error --->
return (ipddp_delete(rt));

-
[BUG] copy_to_user taints "arg" on one switch branch, but
  capabilities check derefs it w/o checks on another

/u2/engler/mc/oses/linux/2.4.1/drivers/telephony/ixj.c:5046:ixj_ioctl: 
ERROR:PARAM:4687:5046: tainted var 'arg' (from line 4687) used as arg 1 to 
'capabilities_check'

break;
case IXJCTL_VERSION:
Start --->
if (copy_to_user((char *) arg, ixj_c_revision, strlen(ixj_c_revision)))
return -EFAULT;
break;
case PHONE_RING_CADENCE:
j->ring_cadence = arg;
break;
case IXJCTL_CIDCW:

... DELETED 345 lines ...

case PHONE_CAPABILITIES:
retval = j->caps;
break;
case PHONE_CAPABILITIES_LIST:
if (copy_to_user((char *) arg, j->caplist, sizeof(struct 
phone_capability) * j->caps))
 return -EFAULT;
break;
case PHONE_CAPABILITIES_CHECK:
Error --->
retval = capabilities_check(board, (struct phone_capability *) arg);
break;
case PHONE_PSTN_SET_STATE:
daa_set_mode(board, arg);
break;


static int capabilities_check(int board, struct phone_capability *pcreq)
{
int cnt;
IXJ *j = &ixj[board];
int retval = 0;
for (cnt = 0; cnt < j->caps; cnt++) {
if (pcreq->captype == j->caplist[cnt].captype
&& pcreq->cap == j->caplist[cnt].cap) {
retval = 1;
break;
}
}
return retval;
}


-
[BUG] Looks like a bug where the memcpy forgets to use the user_buf pointer.

/u2/engler/mc/oses/linux/2.4.1/drivers/usb/serial/digi_acceleport.c:1288:digi_write: 
ERROR:PARAM:1271:1288: tainted var 'buf' (from line 1271) used as arg 1 to 
'__constant_memcpy'

/* copy user data (which can sleep) before getting spin lock */

[OOPS] report

[David]

2.4.2-ac4

Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev 
16:41 (hdd), sector 9512
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00 { }
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer write failed
Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at prints.c:332!
Mar 15 18:02:49 Huntington-Beach kernel: invalid operand: 
Mar 15 18:02:49 Huntington-Beach kernel: CPU:0
Mar 15 18:02:49 Huntington-Beach kernel: EIP:
0010:[reiserfs_panic+357/440]
Mar 15 18:02:49 Huntington-Beach kernel: EFLAGS: 00010282
Mar 15 18:02:49 Huntington-Beach kernel: eax: 001c   ebx: c0420e40   
ecx: cf19   edx: c03a4008
Mar 15 18:02:49 Huntington-Beach kernel: esi: c39a5ecc   edi: c39a5ebc   
ebp:    esp: c39a5e90
Mar 15 18:02:49 Huntington-Beach kernel: ds: 0018   es: 0018   ss: 0018
Mar 15 18:02:49 Huntington-Beach kernel: Process sync (pid: 30559, 
stackpage=c39a5000)
Mar 15 18:02:49 Huntington-Beach kernel: Stack: c031a785 c031aa74 
014c d1526154 0002  cfeb0c00 c0421240
Mar 15 18:02:49 Huntington-Beach kernel:c39a5ebc c39a5eb8 
c39a4000  c0193a6f cfeb0c00 c031cd20 0002
Mar 15 18:02:49 Huntington-Beach kernel:0012 0010 
 d1526188 d152617c 0003  0003
Mar 15 18:02:49 Huntington-Beach kernel: Call Trace: [] 
[flush_commit_list+659/908] [] [] 
[do_journal_end+1935/2652] [] []
Mar 15 18:02:50 Huntington-Beach kernel:
[flush_old_commits+391/420] [reiserfs_write_super+21/32] 
[sync_supers+118/172] [fsync_dev+23/48] [sys_sync+7/16] [system_call+51/56]
Mar 15 18:02:50 Huntington-Beach kernel:
Mar 15 18:02:50 Huntington-Beach kernel: Code: 0f 0b 83 c4 0c 83 7c 24 
28 00 74 17 8b 7c 24 28 80 7f 11 00

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

Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20

[Andreas Dilger]

Andries writes:
> > I've implemented a patch for util-linux-2.11a
> > which adds LABEL support to mkswap(8) and swapon/swapoff(8).
> 
> But I would prefer a somewhat more ambitious approach.
> 
> My first thought was: why label individual swap partitions?
> I almost never want to distinguish swap partitions, and just do
> "swapon -a". In case one wants to guard against changing device names,
> why not add an option -A so that "swapon -A" does swapon on each
> partition with a swap signature?
> 
> However, that would greatly increase the risk that exists already
> today: someone has a swap partition, and does mkfs.foo, and
> it so happens that foofs does not use the sector with the swapsignature.
> Now this foofs partition has a swap signature, but we would be very
> unhappy if it were used as swap space.

I think the LABEL is a good intermediate step for people not using LVM.
It basically allows your /etc/fstab to not have _any_ device names in it.
I'm not sure I would be happy with auto-mounting swap partitions,
especially because this would overwrite any data in the partition.  Bad.

> The real problem is that our disks usually do not have a volume label.
> Outside of all file systems.
> The "signatures" that we rely on today are located in different places,
> so that a filesystem can have several valid signatures at the same time.
> And we first know where to look when we know the type already.
> 
> Design a Linux partition table format, where a partition descriptor
> has fields start, end, fstype, fslabel, and the whole disk has a vollabel.
> Put it in sector 0-N for an all-Linux disk, and in sectors pointed at
> by a classical DOS-type partition table entry when the disk is shared.
> 
> (Maybe I already did that once - it sounds so familiar now that I write
> this. Then why was it not pursued? Maybe LVM already does these things?)

LVM will handle the disk and "partition" naming and size issues.

It does NOT currently handle the fstype names, but this _could_ be
determined via magic numbers, as now.  In the "(struct dentry *)->vfsmnt"
thread, I was trying to work out a way to get mountpoint information
for LVM.  In the end, I think I will store most of the /etc/fstab line
into a field in the LV header, so it is easily retrievable.  This would
also include the fstype, and mount/dump/fsck options.  It would _not_
store the device name.

The proposed solution would be to have mount(8) write the mount info to
the disk (for logical volumes only, of course) at mount time.  I suppose
the fs type, options, mountpoint could come from either /etc/fstab or
from the command-line, since mount(8) is already parsing all of this info.

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

2.2 and AMD-760MP I/O APIC

[Johannes Erdfelt]

The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.

This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.

This patch is relative to 2.2.18, but should apply cleanly to 2.2.19-pre
since -pre17 doesn't touch this code at all.

JE

--- linux-2.2.18.orig/arch/i386/kernel/io_apic.cMon Sep  4 13:39:16 2000
+++ linux-2.2.18/arch/i386/kernel/io_apic.c Thu Mar 15 17:23:46 2001
@@ -200,8 +200,6 @@
  * We disable IO-APIC IRQs by setting their 'destination CPU mask' to
  * zero. Trick by Ramesh Nalluri.
  */
-DO_ACTION( disable, 1, &= 0x00ff, io_apic_sync(entry->apic))/* destination = 0x00 
*/
-DO_ACTION( enable,  1, |= 0xff00, )/* destination 
= 0xff */
 DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
 DO_ACTION( unmask,  0, &= 0xfffe, )/* mask = 0 */
 
@@ -612,7 +610,7 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
entry.mask = 0; /* enable IRQ */
-   entry.dest.logical.logical_dest = 0;/* but no route */
+   entry.dest.logical.logical_dest = 0xff; /* but no route */
 
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -1017,13 +1015,10 @@
 static void enable_edge_ioapic_irq(unsigned int irq)
 {
self_IPI(irq);
-   enable_IO_APIC_irq(irq);
+   unmask_IO_APIC_irq(irq);
 }
 
-static void disable_edge_ioapic_irq(unsigned int irq)
-{
-   disable_IO_APIC_irq(irq);
-}
+static void disable_edge_ioapic_irq(unsigned int irq) { /* nothing */ }
 
 /*
  * Starting up a edge-triggered IO-APIC interrupt is
@@ -1239,7 +1234,7 @@
 
pin1 = find_timer_pin(mp_INT);
pin2 = find_timer_pin(mp_ExtINT);
-   enable_IO_APIC_irq(0);
+   unmask_IO_APIC_irq(0);
if (!timer_irq_works()) {
 
if (pin1 != -1)
-
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.3-pre3 and further ate PCMCIA serial cardbus support

[Alessandro Suardi]

In fact this -pre4 works only after reverting the changes to Config.in,
 Makefile and serial_cb.c in drivers/char/pcmcia, otherwise my Xircom
 modem wouldn't be seen (tulip Ethernet is okay). -pre2 is fine.

So - was there any announcement about something like serial_cs engulfing
 serial_cb or is it just a bad patch that slipped in ?


Thanks & ciao,
 
--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p16/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.10.91.0.4
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
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: [util-linux] Re: magic device renumbering was -- Re: Linux2.4.2ac20

[Alexander Viro]

On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote:

> Design a Linux partition table format, where a partition descriptor
> has fields start, end, fstype, fslabel, and the whole disk has a vollabel.
> Put it in sector 0-N for an all-Linux disk, and in sectors pointed at
> by a classical DOS-type partition table entry when the disk is shared.

Yes, but for $DEITY sake, let's make it text. Something along the lines of
Linux partition table\n(START,LENGTH,TYPE(,LABEL)?n)*End\0
START: NUMBER
LENGTH: NUMBER
TYPE: [^,\n\0]+
LABEL: [^\n\0]+
NUMBER: 

Will make life much simpler when one needs to recover the bloody thing...

-
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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Shane Y. Gibson]

Marcelo Tosatti wrote:
>
> Did'nt you get a message similar to
> 
> "kernel BUG at page_alloc.c line xxx!"

Marcelo,

Yes there was.  I'm pasting the total sum of the /var/log/messages
output.  Note that I'm only able to locate details for the first
crash, the second didn't seem to log a whole lot.  Originally, 
just pasted the output of what "ksymops" regurgitated, which seems
to have pulled out that "kernel BUG" reference.  Here goes...

v/r
Shane

Mar 14 22:05:12 walker kernel: kernel BUG at page_alloc.c:203!
Mar 14 22:05:12 walker kernel: invalid operand: 
Mar 14 22:05:12 walker kernel: CPU:0
Mar 14 22:05:12 walker kernel: EIP:0010:[rmqueue+581/640]
Mar 14 22:05:12 walker kernel: EFLAGS: 00010286
Mar 14 22:05:12 walker kernel: eax: 0020   ebx: c1537448   ecx:
0002   edx: 0200
Mar 14 22:05:12 walker kernel: esi: 0001efe0   edi: c110   ebp:
0001efe0   esp: c28e3e2c
Mar 14 22:05:12 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 14 22:05:12 walker kernel: Process indexmaker (pid: 24392,
stackpage=c28e3000)
Mar 14 22:05:12 walker kernel: Stack: c024deeb c024e099 00cb
00012a2e 0282  c029dff8 c029dff8 
Mar 14 22:05:12 walker kernel:c029e1d0  c029e1cc
c012e664 0005 0001 cc187220 c19cde40 
Mar 14 22:05:12 walker kernel:0025 c7c85bac c0123a32
cc187220 c19cde40 0001 c0123ab0 c19cde40 
Mar 14 22:05:12 walker kernel: Call Trace: [__alloc_pages+228/720]
[do_anonymous_page+50/128] [do_no_page+48/160] [handle_mm_fault+276/400]
[do_page_fault+349/1088] [file_read_actor+0/96] [do_brk+186/368] 
Mar 14 22:05:12 walker kernel:[sys_brk+181/224]
[do_page_fault+0/1088] [error_code+52/60] 
Mar 14 22:05:12 walker kernel: 
Mar 14 22:05:12 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47
83 c6 0c 83 ff 09 0f 86 
Mar 14 22:05:25 walker kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0051
Mar 14 22:05:25 walker kernel:  printing eip:
Mar 14 22:05:25 walker kernel: c013f010
Mar 14 22:05:25 walker kernel: *pde = 
Mar 14 22:05:25 walker kernel: Oops: 
Mar 14 22:05:25 walker kernel: CPU:1
Mar 14 22:05:25 walker kernel: EIP:0010:[path_walk+2032/2400]
Mar 14 22:05:25 walker kernel: EFLAGS: 00010202
Mar 14 22:05:25 walker kernel: eax: 0029   ebx: d6474240   ecx:
d9080ee0   edx: c1c8bf10
Mar 14 22:05:25 walker kernel: esi: c1c8bf10   edi: d3a2f060   ebp:
c54e3013   esp: c1c8bef4
Mar 14 22:05:25 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 14 22:05:25 walker kernel: Process rateup (pid: 24715,
stackpage=c1c8b000)
Mar 14 22:05:25 walker kernel: Stack: dff005a0 0001 d6474240
40174700 dbda2ea0 c011481d dbda2ea0 c54e3000 
Mar 14 22:05:25 walker kernel:0013 d45ced21 c1c8bf50
c54e3000  c1c8bf7c 0001 c013f832 
Mar 14 22:05:25 walker kernel:c54e3000 c1c8bf7c 
0004 c0146b1c db1123a0 c1c8a000 d05596e0 
Mar 14 22:05:25 walker kernel: Call Trace: [do_page_fault+349/1088]
[open_namei+130/1472] [dput+28/368] [filp_open+54/96] [getname+91/160]
[sys_open+58/224] [system_call+51/56] 
Mar 14 22:05:25 walker kernel: 
Mar 14 22:05:25 walker kernel: Code: 8b 40 28 85 c0 74 79 be 00 e0 ff ff
21 e6 8b 86 3c 03 00 00 
Mar 14 22:05:29 walker kdm[789]: Server for display :0 terminated
unexpectedly: 2816 
Mar 14 22:05:29 walker kernel: kernel BUG at page_alloc.c:203!
Mar 14 22:05:29 walker kernel: invalid operand: 
Mar 14 22:05:29 walker kernel: CPU:1
Mar 14 22:05:29 walker kernel: EIP:0010:[rmqueue+581/640]
Mar 14 22:05:29 walker kernel: EFLAGS: 00013286
Mar 14 22:05:29 walker kernel: eax: 0020   ebx: c154ec24   ecx:
   edx: 0002
Mar 14 22:05:29 walker kernel: esi: 0001efe0   edi: c110   ebp:
0001efe0   esp: d886be8c
Mar 14 22:05:29 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 14 22:05:29 walker kernel: Process X (pid: 13530,
stackpage=d886b000)
Mar 14 22:05:29 walker kernel: Stack: c024deeb c024e099 00cb
00012fb5 3282  c029dff8 c029dff8 
Mar 14 22:05:29 walker kernel:c029e1f8  c029e1f4
c012e664 0007 0001  d886bf5c 
Mar 14 22:05:29 walker kernel:cc23a1a0 d4f6aca0 c012e868
c0143123 cfbc5cc0 cc23a1a0 cfbc5d90  
Mar 14 22:05:29 walker kernel: Call Trace: [__alloc_pages+228/720]
[__get_free_pages+24/48] [__pollwait+51/144] [tcp_poll+46/352]
[do_readv_writev+396/608] [sock_poll+33/48] [do_select+295/576] 
Mar 14 22:05:29 walker kernel:[sys_select+809/1136]
[system_call+51/56] 
Mar 14 22:05:29 walker kernel: 
Mar 14 22:05:29 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47
83 c6 0c 83 ff 09 0f 86 
Mar 14 22:05:30 walker PAM_unix[13534]: (kde) session closed for user
sgibson
Mar 14 22:05:31 walker kdm[789]: server unexpectedly died 
Mar 14 22:05:31 walker mysqld: Starting MySQL:  succeeded
Mar 14 22:05:31 walker linuxconf: Running Linuxconf hooks: succeeded
Mar 14 22:05:32 walker kernel: kernel BUG at page_alloc.c:203!
Mar 14 22:05:32 walker kernel:

Re[4]: VIA686A chipset crash under 2.4.2-ac20

[kozkir-8]

-BEGIN PGP SIGNED MESSAGE-
Hash: MD5


>> >> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>
>> MH> this can only be caused by bad cable/config.  is it 18", with both ends
>> MH> plugged in?
>>
>>
>> Do you mean 40-pin E-IDE cable?

MH> 40-conductor cables are only valid to use up to udma33, but 80c cables
MH> will *always* help, and can be used in any mode.  but equally important
MH> is that the cable must never be longer than 18", with both ends plugged in
MH> (no stub).


Forgot one think!
When I recompiled the kernel with DMA support I got speed on HDD only
16Mb/sec according to hdparm.

-BEGIN PGP SIGNATURE-
Version: 2.6

iQCVAwUAOrFgcD5SQymVx3NvAQFz8gP/XRXrfuFLdds2neck7RiNPPFjcrunEmnL
KAXQBPCr+IT4E8hKZ+IxYjMZooBO68jnNMM4NqzuxDs0bcS4pWwVjln4X2ZQC/vu
iKUWLaeOzGcR7oM9a53h8xFkZTgLYJuChPFxdTyug7ZjPKMbKoOzln/5ShI1Cepn
VdyMwLGb56M=
=nome
-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/

Re: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Brian Gerst]

"Shane Y. Gibson" wrote:
> 
> All,
> 
> I just compiled 2.4.2 and installed it on a otherwise stock
> Redhat 7.0 platform.  The system is a SuperMicro PIIISME,
> running dual PIII 750s, with 256 cache.  It appears that about
> every 10 to 18 hours, the system is panicing, and freezing
> up.  The first time, I got an oops , the second time an
> oops 0002.  Both crashes have occured only when the systems is
> at 100% cpu utlization; processing several hundred MRTG
> indexmaker operations.
> 
> I ran ksymoops on both outputs, and the results are pasted
> below.  Note, I compiled the kernel without loadable module
> support.  Please let me know if there is anything else I can
> do/provide to help.  Unfortunately, the second didn't output
> enough for ksymoops to extract anything usefull.
> 
> v/r
> Shane
> 
> Code;   Before first symbol
>0:   0f 0b ud2a

There should be a line just before the oops saying "kernel BUG at..."

--
Brian Gerst
-
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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Marcelo Tosatti]

On Thu, 15 Mar 2001, Shane Y. Gibson wrote:

> 
> All,
> 
> I just compiled 2.4.2 and installed it on a otherwise stock
> Redhat 7.0 platform.  The system is a SuperMicro PIIISME, 
> running dual PIII 750s, with 256 cache.  It appears that about
> every 10 to 18 hours, the system is panicing, and freezing
> up.  The first time, I got an oops , the second time an
> oops 0002.  Both crashes have occured only when the systems is
> at 100% cpu utlization; processing several hundred MRTG 
> indexmaker operations.
> 
> I ran ksymoops on both outputs, and the results are pasted
> below.  Note, I compiled the kernel without loadable module
> support.  Please let me know if there is anything else I can
> do/provide to help.  Unfortunately, the second didn't output
> enough for ksymoops to extract anything usefull.
> 
> v/r
> Shane
> 
> --- first ksymoops output --- 
> 
> ksymoops 2.3.4 on i686 2.4.2.  Options used
>  -V (default)
>  -K (specified)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.2/ (default)
>  -m /boot/System.map (specified)
> 
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> Mar 14 22:05:12 walker kernel: invalid operand: 
> Mar 14 22:05:12 walker kernel: CPU:0

Hi Shane, 

Did'nt you get a message similar to 

"kernel BUG at page_alloc.c line xxx!"

Before the first oops ? 

It looks like this oops was triggered by a "BUG()" call, and in this case
this message should be printed before the oops.

Thanks 

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

Write throttling problem in 2.4.2?

[Donald J. Barry]

Dear Developers:

More on my 2.4.2 oopses concerning the "Unable to handle kernel paging
request"

These only take place during ENORMOUS write pressure, and I'm curious
as to whether write throttling is an issue here.  Since this is on 
a reiserfs atop lvm, some of the previously conceived solutions 
may not apply.  

It's not a major problem, as it only occurs I can start a tars transferring 
tens of gigabytes.  But if I also then launch a task doing enormous activity 
on the vfs, such as a simultaneous "du -s ." on the directories in 
question, I can pretty reliably create the kernel paging fault.

Cheers,

Don Barry
Cornell Astronomy

-- 2.4.2 vanilla kernel + Brown's NFS patches, pretty minimal otherwise
-- problem first seen on 256M ram, still persists at 392M ram
-- LVM atop hda/hdb (60g) (motherboard via kt133 chipset) plus promise ultra66
   controller driving 80 gig drive on hde





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

About DC-315U SCSI driver

[³¯¤ý®i]

Hi all,

 At last night, I changed my scsi card from a pci slot to another,to avoided the IRQ
sharing between on-board USB and SCSI.

 And burned a cdr to test. It's so magic. The burned files which are not the same
with origin ones is much less than before. Why? Can not use IRQ sharing between 
SCSI&USB?  I used Win98 & kernel 2.2.x,and no errors.

 I burned two cdr with kernel insmoded dc395x_trm.o and another scsi driver 
integrated kernel. CDR burned with the former has two different files with origin
ones. And the latter has six ones. I have no idea about the difference.
Maybe I can burn more cdr to test.

  When I have time, I would like to testing with lowered syncspeed. I hope it will
be a temp solution.

Best Regards,cwz
-
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[4]: VIA686A chipset crash under 2.4.2-ac20

[kozkir-8]

-BEGIN PGP SIGNED MESSAGE-
Hash: MD5



>> >> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>
>> MH> this can only be caused by bad cable/config.  is it 18", with both ends
>> MH> plugged in?
>>
>>
>> Do you mean 40-pin E-IDE cable?

MH> 40-conductor cables are only valid to use up to udma33, but 80c cables
MH> will *always* help, and can be used in any mode.  but equally important
MH> is that the cable must never be longer than 18", with both ends plugged in
MH> (no stub).

I measured the cable and it is aprox. 45cm (18") and it is 80c.
It has also 3 connectors, two of them are in use (on the ends), and
one is free (in the middle). I also checked the connections on
motherboard and on disk, they are both ok.

-BEGIN PGP SIGNATURE-
Version: 2.6

iQCVAwUAOrFfcT5SQymVx3NvAQEmwQP/bMQYXekwlUDKPdQ80khqfkv45TCY8lVd
r6lXb82s60vvbEpCTyF16E4TwQkwirsPf5virJ0jZO+EBFRVwOhDFitbaF9PdHhG
MdSFtST6JrhwozsoU3LgkdMZb3Mnnw7YsV9ctOZij+4WN5SDd5IO5YNXgeWgrdLb
c+jZzBpmLK8=
=PvVG
-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/

Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform

[Shane Y. Gibson]

All,

I just compiled 2.4.2 and installed it on a otherwise stock
Redhat 7.0 platform.  The system is a SuperMicro PIIISME, 
running dual PIII 750s, with 256 cache.  It appears that about
every 10 to 18 hours, the system is panicing, and freezing
up.  The first time, I got an oops , the second time an
oops 0002.  Both crashes have occured only when the systems is
at 100% cpu utlization; processing several hundred MRTG 
indexmaker operations.

I ran ksymoops on both outputs, and the results are pasted
below.  Note, I compiled the kernel without loadable module
support.  Please let me know if there is anything else I can
do/provide to help.  Unfortunately, the second didn't output
enough for ksymoops to extract anything usefull.

v/r
Shane

--- first ksymoops output --- 

ksymoops 2.3.4 on i686 2.4.2.  Options used
 -V (default)
 -K (specified)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2/ (default)
 -m /boot/System.map (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Mar 14 22:05:12 walker kernel: invalid operand: 
Mar 14 22:05:12 walker kernel: CPU:0
Mar 14 22:05:12 walker kernel: EIP:0010:[rmqueue+581/640]
Mar 14 22:05:12 walker kernel: EFLAGS: 00010286
Mar 14 22:05:12 walker kernel: eax: 0020   ebx: c1537448   ecx:
0002   edx: 0200
Mar 14 22:05:12 walker kernel: esi: 0001efe0   edi: c110   ebp:
0001efe0   esp: c28e3e2c
Mar 14 22:05:12 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 14 22:05:12 walker kernel: Process indexmaker (pid: 24392,
stackpage=c28e3000)
Mar 14 22:05:12 walker kernel: Stack: c024deeb c024e099 00cb
00012a2e 0282  c029dff8 c029dff8 
Mar 14 22:05:12 walker kernel:c029e1d0  c029e1cc
c012e664 0005 0001 cc187220 c19cde40 
Mar 14 22:05:12 walker kernel:0025 c7c85bac c0123a32
cc187220 c19cde40 0001 c0123ab0 c19cde40 
Mar 14 22:05:12 walker kernel: Call Trace: [__alloc_pages+228/720]
[do_anonymous_page+50/128] [do_no_page+48/160] [handle_mm_fault+276/400]
[do_page_fault+349/1088] [file_read_actor+0/96] [do_brk+186/368] 
Mar 14 22:05:12 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47
83 c6 0c 83 ff 09 0f 86 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   89 d8 mov%ebx,%eax
Code;  0007 Before first symbol
   7:   eb 1d jmp26 <_EIP+0x26> 0026 Before
first symbol
Code;  0009 Before first symbol
   9:   89 f6 mov%esi,%esi
Code;  000b Before first symbol
   b:   47inc%edi
Code;  000c Before first symbol
   c:   83 c6 0c  add$0xc,%esi
Code;  000f Before first symbol
   f:   83 ff 09  cmp$0x9,%edi
Code;  0012 Before first symbol
  12:   0f 86 00 00 00 00 jbe18 <_EIP+0x18> 0018 Before
first symbol

Mar 14 22:05:25 walker kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0051
Mar 14 22:05:25 walker kernel: c013f010
Mar 14 22:05:25 walker kernel: *pde = 
Mar 14 22:05:25 walker kernel: Oops: 
Mar 14 22:05:25 walker kernel: CPU:1
Mar 14 22:05:25 walker kernel: EIP:0010:[path_walk+2032/2400]
Mar 14 22:05:25 walker kernel: EFLAGS: 00010202
Mar 14 22:05:25 walker kernel: eax: 0029   ebx: d6474240   ecx:
d9080ee0   edx: c1c8bf10
Mar 14 22:05:25 walker kernel: esi: c1c8bf10   edi: d3a2f060   ebp:
c54e3013   esp: c1c8bef4
Mar 14 22:05:25 walker kernel: ds: 0018   es: 0018   ss: 0018
Mar 14 22:05:25 walker kernel: Process rateup (pid: 24715,
stackpage=c1c8b000)
Mar 14 22:05:25 walker kernel: Stack: dff005a0 0001 d6474240
40174700 dbda2ea0 c011481d dbda2ea0 c54e3000 
Mar 14 22:05:25 walker kernel:0013 d45ced21 c1c8bf50
c54e3000  c1c8bf7c 0001 c013f832 
Mar 14 22:05:25 walker kernel:c54e3000 c1c8bf7c 
0004 c0146b1c db1123a0 c1c8a000 d05596e0 
Mar 14 22:05:25 walker kernel: Call Trace: [do_page_fault+349/1088]
[open_namei+130/1472] [dput+28/368] [filp_open+54/96] [getname+91/160]
[sys_open+58/224] [system_call+51/56] 
Mar 14 22:05:25 walker kernel: Code: 8b 40 28 85 c0 74 79 be 00 e0 ff ff
21 e6 8b 86 3c 03 00 00 

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 40 28  mov0x28(%eax),%eax
Code;  0003 Before first symbol
   3:   85 c0 test   %eax,%eax
Code;  0005 Before first symbol
   5:   74 79 je 80 <_EIP+0x80> 0080 Before
first symbol
Code;  0007 Before first symbol
   7:   be 00 e0 ff ffmov$0xe000,%esi
Code;  000c Before first symbol

Re: Kernel 2.4.2and 8139too

[Brian May]

> "Ted" == Ted Gervais <[EMAIL PROTECTED]> writes:

Ted> A simple question for you guru's..  I just installed kernel
Ted> 2.4.2 on a slackware system and have a problem with loading a
Ted> module. It is the 8139too.o module previously the rtl8139.o.
Ted> It seems that this new driver is not being loaded with this
Ted> new kernel. Obviously something has changed but I can't seem
Ted> to see where that is.  I noticed though that the directories
Ted> in /lib/modules for this kernel is different than 2.2.18.

Sorry, this is not related to your problem...

However, I have just put a 8139 based card into my Linux 2.4.2
system. At one stage, these lines were logged:

Mar 15 09:42:56 snoopy kernel: eth0: Abnormal interrupt, status 0020.
Mar 15 09:43:04 snoopy kernel: eth0: Abnormal interrupt, status 2020.
Mar 15 10:06:52 snoopy kernel: eth0: Abnormal interrupt, status 0020.
Mar 15 10:06:58 snoopy kernel: eth0: Abnormal interrupt, status 2020.

The card seems to be reliable apart from these messages. It could be
that I was playing around with the network cable or something at the
time... However, any messages "Abnormal interrupt" make me slightly
nervous.

Anyway, further information:

Mar 14 16:10:22 snoopy kernel: 8139too Fast Ethernet driver 0.9.13 loaded
Mar 14 16:10:22 snoopy kernel: PCI: Found IRQ 12 for device 00:0a.0
Mar 14 16:10:22 snoopy kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 
00:48:54:1d:b2:85, IRQ 12
Mar 14 16:10:22 snoopy kernel: eth0:  Identified 8139 chip type 'RTL-8139C'

[...]

Mar 14 16:10:23 snoopy kernel: eth0: Setting full-duplex based on MII #32 link partner 
ability of 45e1.

(sorry if this problem has already been reported...)
-- 
Brian May <[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.2.19 pre13 doesn't like retransmitted SYN ACK packets

[Zack Weinberg]

On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 15 Mar 2001, Zack Weinberg wrote:
> > 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
> > arrives after we've sent out the final ACK of the handshake.  For
> > example:
> 
> Ah, that would explain the extremely crappy network conectivity I observed
> with 2.2.19preX, X < 17 (15 and 16 were better, but not as good as 17 or
> 2.2.18).  Please try 2.2.19pre17, it is handling itself just as well as
> 2.2.18 here.

2.2.19pre17 works.  Thank you.

zw
-
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: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20

[Andries . Brouwer]

> I've implemented a patch for util-linux-2.11a
> which adds LABEL support to mkswap(8) and swapon/swapoff(8).

Yes, maybe a reasonable idea.

But I would prefer a somewhat more ambitious approach.

My first thought was: why label individual swap partitions?
I almost never want to distinguish swap partitions, and just do
"swapon -a". In case one wants to guard against changing device names,
why not add an option -A so that "swapon -A" does swapon on each
partition with a swap signature?

However, that would greatly increase the risk that exists already
today: someone has a swap partition, and does mkfs.foo, and
it so happens that foofs does not use the sector with the swapsignature.
Now this foofs partition has a swap signature, but we would be very
unhappy if it were used as swap space.

The real problem is that our disks usually do not have a volume label.
Outside of all file systems.
The "signatures" that we rely on today are located in different places,
so that a filesystem can have several valid signatures at the same time.
And we first know where to look when we know the type already.

Design a Linux partition table format, where a partition descriptor
has fields start, end, fstype, fslabel, and the whole disk has a vollabel.
Put it in sector 0-N for an all-Linux disk, and in sectors pointed at
by a classical DOS-type partition table entry when the disk is shared.

(Maybe I already did that once - it sounds so familiar now that I write
this. Then why was it not pursued? Maybe LVM already does these things?)

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

Re: pivot_root & linuxrc problem

[Russell King]

On Thu, Mar 15, 2001 at 10:11:55PM +0100, Mike Galbraith wrote:
> On Thu, 15 Mar 2001, Art Boulatov wrote:
> 
> > How can I "exec /sbin/init" from "/linuxrc", whatever it is,
> > if "linuxrc" does not get PID=1?
> >
> > Actually, why does NOT "linuxrc" get PID=1?
> 
> That's the question.. the first task started gets pid=1, and when
> that is true, exec /sbin/init has no problem.  What else is your
> system starting?.. it must be starting something.

Linux always forks from PID1 before executing /linuxrc automagically.
Check init/main.c.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: Drvie Corruption CONSTANTLY with Linux and KT7-RAID

[Russell King]

On Thu, Mar 15, 2001 at 06:20:24AM -0800, Peter DeVries wrote:
> Please help.. I'm at the end of my rope with this now.
>  I have rebuilt this system and corupted my drive at
> least 30 times now.  I have a ABIT KT7-RAID and no
> matter what I do with any kernel 2.2.16 - 2.4.2-ac19
> as soon as I turn on DMA mode the drive starts to
> corrupt and becomes useless.  The corruption happens
> alot faster in 2.4xxx than the 2.2.xxx kernels.  

Do you notice any programs getting SEGVs?  If they do, it could be bad
RAM.

Personally, when I come across a machine which behaves oddly, the first
thing I'd try is checking the memory.  You can get a copy of memtest86
for doing this.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: magic device renumbering was -- Re: Linux 2.4.2ac20

[Mikael Pettersson]

On Wed, 14 Mar 2001 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML:

>Lars writes:
>> > Put LABEL= in you fstab in place of the device name.
>> 
>> Which is great, for filesystems that support labels.  Unfortunately,
>> this isn't universally available -- for instance, you cannot mount
>> a swap partition by label or uuid, so it is not possible to completely
>> isolate yourself from the problems of disk device renumbering.
>
>There is room for a LABEL and/or UUID in the swap superblock, if you
>would want to implement support for this.

Despair no more! I've implemented a patch for util-linux-2.11a
which adds LABEL support to mkswap(8) and swapon/swapoff(8).

- I shrunk the padding field in the new-style swap_header to make
  room for 16 bytes worth of volume label (same as ext2)
- mkswap -L label also sets the volume label
- swapon -L label looks for a swap partition with the given label
  (using a clone of mount(8)'s LABEL/UUID= support code)
- swapon/swapoff -a also handles swap fstab entries where the
  device is specified as LABEL=

The patch is available at http://www.csd.uu.se/~mikpe/linux/swap-label/

/Mikael
-
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: Is swap == 2 * RAM a permanent thing?

[Rik van Riel]

On Thu, 15 Mar 2001, Andrzej Krzysztofowicz wrote:
> "Rik van Riel wrote:"
> >   total usage == maximum(swap, ram)
>
> Does it mean that having swaphttp://linux-mm.org/bugzilla.shtml

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

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

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

Re: Is swap == 2 * RAM a permanent thing?

[Andrzej Krzysztofowicz]

"Rik van Riel wrote:"
>   total usage == maximum(swap, ram)

Does it mean that having  swaphttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to optimize routing performance

[Robert Olsson]

Manfred Spraul writes:
 > >
 > > http://Linux/net-development/experiments/010313
 > >
 > The link is broken, and I couldn't find it at www.linux.com. Did you
 > forget the host?

 Yes Sir!

 The profile data from the Linux production router is at:
 
 http://robur.slu.se/Linux/net-development/experiments/010313

 Cheers.

--ro

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

Re: Kernel 2.4.2

[Guennadi Liakhovetski]

I do have the latest version of modutils (at least, the one required by
Documentation/Changes - 2.4.2), but I still have to all the line add
path=/lib/modules/`uname -r`/kernel/* to /etc/modules.conf. 
ONLY then it works. At least it worked until yesterday... Yesterday I
found out that I can't use CD-ROM on one of the machines, and, in
particular, when I am trying to access it - together with ide.o,
iso9660.o, also get loaded lp.o, parport.o and parport-pc.o... with no
visible reason... But I am not sure if this should be associated with
modutils or whatever... Why did I need that line?

Thanks
Guennadi

On Thu, 15 Mar 2001, John Jasen wrote:

> On Thu, 15 Mar 2001, Ted Gervais wrote:
> 
> > Anyways - to get things to work, I have put added this statement to the
> > top of my /etc/rc.d/rc.inet1 file:
> >
> > insmod /usr/src/linux/drivers/net/8139too.o.
> 
> install a later version of modutils, as the /lib/modules directory tree
> has changed between 2.2.x and 2.4.x
> 
> 
> 
> -
> 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/
> 

___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [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: pivot_root & linuxrc problem

[Mike Galbraith]

On Thu, 15 Mar 2001, Art Boulatov wrote:

> How can I "exec /sbin/init" from "/linuxrc", whatever it is,
> if "linuxrc" does not get PID=1?
>
> Actually, why does NOT "linuxrc" get PID=1?

That's the question.. the first task started gets pid=1, and when
that is true, exec /sbin/init has no problem.  What else is your
system starting?.. it must be starting something.

-Mike

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

Linux Patch 2.4.2 for AVM A1 PCMCIA

[Jochen Friedrich]

Hello,

this patch includes the ISDN driver for AVM A1 PCMCIA from Carsten Paeth
into the linux kernel sources. Without the patch, it might be confusing
for a user to be able to select AVM A1 PCMCIA support for the kernel, but
it still doesn't work (because the PCMCIA part is missing).

Cheers,
Jochen


diff -u -r -N linux/drivers/isdn/Makefile linux-2.4.2/drivers/isdn/Makefile
--- linux/drivers/isdn/Makefile Fri Dec 29 23:40:54 2000
+++ linux-2.4.2/drivers/isdn/Makefile   Sat Mar 10 15:55:59 2001
@@ -45,6 +45,15 @@
 subdir-$(CONFIG_ISDN_DRV_EICON)+= eicon
 subdir-$(CONFIG_HYSDN) += hysdn
 
+ifeq ($(CONFIG_PCMCIA),y)
+  subdir-y += pcmcia
+  subdir-m += pcmcia
+else
+  ifeq ($(CONFIG_PCMCIA),m)
+subdir-m += pcmcia
+  endif
+endif
+
 obj-y += $(addsuffix /vmlinux-obj.o, $(subdir-y))
 
 # The global Rules.make.
diff -u -r -N linux/drivers/isdn/pcmcia/Makefile 
linux-2.4.2/drivers/isdn/pcmcia/Makefile
--- linux/drivers/isdn/pcmcia/Makefile  Thu Jan  1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/MakefileSat Mar 10 15:55:30 2001
@@ -0,0 +1,20 @@
+#
+# Makefile for drivers/isdn/pcmcia
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+
+obj-y   :=
+obj-n   :=
+obj-m   :=
+obj-:=
+
+ifeq ($(CONFIG_ISDN_DRV_HISAX),m)
+  ifeq ($(CONFIG_HISAX_AVM_A1_PCMCIA),y)
+obj-m += avma1_cs.o
+  endif
+endif
+
+include $(TOPDIR)/Rules.make
diff -u -r -N linux/drivers/isdn/pcmcia/avma1_cs.c 
linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c
--- linux/drivers/isdn/pcmcia/avma1_cs.cThu Jan  1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c  Sat Mar 10 15:55:30 2001
@@ -0,0 +1,541 @@
+/*==
+
+A PCMCIA client driver for AVM B1/M1/M2
+
+Written by Carsten Paeth, [EMAIL PROTECTED]
+
+==*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int avm_a1_init_pcmcia(void *pcm_iob, int pcm_irq, int *busy_flag, int prot);
+void HiSax_closecard(int cardnr);
+
+
+/*
+   All the PCMCIA modules use PCMCIA_DEBUG to control debugging.  If
+   you do not define PCMCIA_DEBUG at all, all the debug code will be
+   left out.  If you compile with PCMCIA_DEBUG=0, the debug code will
+   be present but disabled -- but it can then be enabled for specific
+   modules at load time with a 'pc_debug=#' option to insmod.
+*/
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+MODULE_PARM(pc_debug, "i");
+#define DEBUG(n, args...) if (pc_debug>(n)) printk(KERN_DEBUG args);
+static char *version =
+"avma1_cs.c 1.00 1998/01/23 10:00:00 (Carsten Paeth)";
+#else
+#define DEBUG(n, args...)
+#endif
+
+/**/
+
+/* Parameters that can be set with 'insmod' */
+
+static int default_irq_list[11] = { 15, 13, 12, 11, 10, 9, 7, 5, 4, 3, -1 };
+static int irq_list[11] = { -1 };
+static int isdnprot = 2;
+
+MODULE_PARM(irq_list, "1-11i");
+MODULE_PARM(isdnprot, "1-4");
+
+/**/
+
+/*
+   The event() function is this driver's Card Services event handler.
+   It will be called by Card Services when an appropriate card status
+   event is received.  The config() and release() entry points are
+   used to configure or release a socket, in response to card insertion
+   and ejection events.  They are invoked from the skeleton event
+   handler.
+*/
+
+static void avma1cs_config(dev_link_t *link);
+static void avma1cs_release(u_long arg);
+static int avma1cs_event(event_t event, int priority,
+ event_callback_args_t *args);
+
+/*
+   The attach() and detach() entry points are used to create and destroy
+   "instances" of the driver, where each instance represents everything
+   needed to manage one actual PCMCIA card.
+*/
+
+static dev_link_t *avma1cs_attach(void);
+static void avma1cs_detach(dev_link_t *);
+
+/*
+   The dev_info variable is the "key" that is used to match up this
+   device driver with appropriate cards, through the card configuration
+   database.
+*/
+
+static dev_info_t dev_info = "avma1_cs";
+
+/*
+   A linked list of "instances" of the skeleton device.  Each actual
+   PCMCIA card corresponds to one device instance, and is described
+   by one dev_link_t structure (defined in ds.h).
+
+   You may not want to use a linked list for this -- for example, the
+   memory card driver uses an array of dev_link_t pointers, where minor
+   device numbers are used to derive the corresponding array ind

Re: State of RAID (and the infamous FastTrak100 card)

[Thomas Dodd]

Wilfried Weissmann wrote:
> 
> Jakob Østergaard wrote:
> > > So... am I just begging for pain if I try to install, say, a stock RH7
> > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing?
> > > If it requires this machine to always boot from a floppy because the driver
> > > cannot be linked into the kernel, well, I'm okay with that.
> >
> > I don't know about the state of the FastTrak100 IDE drivers - but if you can
> > get that running, putting software RAID on top of that should be a simple
> > matter.
> 
> I do not think that would work. These IDE RAID use a slightly different layout that 
>someone would
> expect. This means that you cannot map it 1:1 to any RAID personality, therefore you 
>cannot boot
> from it.
> 
> (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you 
>want to check it
> out.

Jakob ment the kernel software-RAID, md.0, raid0.o, raid1.o, raid5.o,
and linear.o
Not the Promise RAID software.

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

Re: How to optimize routing performance

[jamal]

On Thu, 15 Mar 2001, Robert Olsson wrote:

>
>
> Jonathan Morton writes:
>
>  > Nice.  Any chance of similar functionality finding its' way outside the
>  > Tulip driver, eg. to 3c509 or via-rhine?  I'd find those useful, since one
>  > or two of my Macs appear to be capable of generating pseudo-DoS levels of
>  > traffic under certain circumstances which totally lock a 486 (for the
>  > duration) and heavily load a P166 - even though said Macs "only" have
>  > 10baseT Ethernet.
>
>  I'm not the one to tell. :-)
>
>  First its kind of experimental. Jamal has talked about putting together
>  a proposal for enhancing RX-process for inclusion in the 2.5 kernels.
>  There is meeting soon for this.
>
>
>  But why not experiment a bit?

I think one of the immediate things usable to drivers is to check the
netif_rx() return value and yield the CPU if the system is congested.
This is hardware independent. For the Tulip, since it knows how to do
mitigation, it infact reduces it's interupt rate. An even simpler thing is
to use HW_FLOW_CONTROL where you shutdown rx_interupt based on system
congestion (and get worken up later when things get better).

For 2.5 the plan is to work around any hardware dependencies.

cheers,
jamal

-
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: State of RAID (and the infamous FastTrak100 card)

[Wilfried Weissmann]

Jakob Østergaard wrote:
> > So... am I just begging for pain if I try to install, say, a stock RH7
> > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing?
> > If it requires this machine to always boot from a floppy because the driver
> > cannot be linked into the kernel, well, I'm okay with that.
> 
> I don't know about the state of the FastTrak100 IDE drivers - but if you can
> get that running, putting software RAID on top of that should be a simple
> matter.

I do not think that would work. These IDE RAID use a slightly different layout that 
someone would
expect. This means that you cannot map it 1:1 to any RAID personality, therefore you 
cannot boot
from it.

(Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you 
want to check it
out.
I want to write a kernel module for 2.4 which supports the HPT370 RAID. You can be 
sure that I will
peek at the FreeBSD code. In fact that is the only documentation I have.

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

ANNOUNCE: Journalling Flash File System, v2.

[David Woodhouse]

Well, it's been almost a week since the latest stupid bug was found in the 
JFFS2 code, so I suppose it's time to admit to the world that it exists.

JFFS2, developed by Red Hat, is a complete reimplementation of a 
journalling filesystem for FLASH devices, based on the original JFFS 
from Axis Communications AB. 

Improvements of JFFS2 over the original JFFS include:

- Improved wear levelling and garbage collection performance.
- Compression
- Improved RAM footprint and response to system memory pressure.
- Improved concurrency and support for suspending flash erases
- Support for hard links.


You can get it from anonymous CVS:

cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs login (password: anoncvs)
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co mtd

The only platform currently supported is Linux 2.4. A port to eCos is 
likely to happen quite soon.

JFFS2 filesystem images of the current 'Familiar' distribution for the
Compaq iPAQ, along with appropriate kernels, are available at 
ftp://ftp.uk.linux.org/pub/people/dwmw2/familiar-0.3/

--
dwmw2


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

Re: Is swap == 2 * RAM a permanent thing?

[Rik van Riel]

On Thu, 15 Mar 2001, LA Walsh wrote:

> The not reclaiming swap space is flawed in more than once
> instance.

I want it fixed, but don't have much time for it now.

Patches are welcome, though.

regards,

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

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

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

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

RE: How to optimize routing performance

[Jonathan Earle]

> > Or are you saying that the bottleneck is somewhere
> > else completely,
> 
> Indeed. The bottleneck is with processing the incoming network
> packets, at the interrupt level.

Where is the counter for these dropped packets?  If we run a few mbit of
traffic through the box, we see noticeble percentages of lost packets (via
stats from the Ixia traffic generator).  But where in Linux are these counts
stored?  ifconfig does not appear to have the #.

Cheers!
Jon
-
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: Is swap == 2 * RAM a permanent thing?

[LA Walsh]

The not reclaiming swap space is flawed in more than once instance.
Suppose my P1 and P2 have their swap reserved -- now both grow.
P3 is idle but can't fit in swap.  This is going to result in fragmentation
no?  How is this fragmentation less worse than just freeing swap.

Ever since Ram sizes got to about 256M, I've tended toward using swap spaces 
about half my RAM size -- thinking of swap as an 'overflow' place that
really shouldn't get used much if at all.  As you mention, not reclaiming
swap space, but having 'double-reservations' for previously swapped
programs becomes a problem fast in this situation.  Makes the swap
much less flexible.

-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.2.19 pre13 doesn't like retransmitted SYN ACK packets

[Henrique de Moraes Holschuh]

On Thu, 15 Mar 2001, Zack Weinberg wrote:
> 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
> arrives after we've sent out the final ACK of the handshake.  For
> example:

Ah, that would explain the extremely crappy network conectivity I observed
with 2.2.19preX, X < 17 (15 and 16 were better, but not as good as 17 or
2.2.18).  Please try 2.2.19pre17, it is handling itself just as well as
2.2.18 here.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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: How to optimize routing performance

[Robert Olsson]

Jonathan Morton writes:

 > Nice.  Any chance of similar functionality finding its' way outside the
 > Tulip driver, eg. to 3c509 or via-rhine?  I'd find those useful, since one
 > or two of my Macs appear to be capable of generating pseudo-DoS levels of
 > traffic under certain circumstances which totally lock a 486 (for the
 > duration) and heavily load a P166 - even though said Macs "only" have
 > 10baseT Ethernet.

 I'm not the one to tell. :-) 

 First its kind of experimental. Jamal has talked about putting together 
 a proposal for enhancing RX-process for inclusion in the 2.5 kernels. 
 There is meeting soon for this.


 But why not experiment a bit?

 Cheers.

--ro
-
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: Performance is weird (fwd)

[Manfred Spraul]

I've attached a patch.
I tried to trigger the problem with my 10 MBit ne2k-pci connection, but
without success.

Could you try it?
I've tested it with -ac17, and it applies to 2.4.2 cleanly.

--
Manfred

--- 2.4/arch/i386/kernel/process.c  Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cThu Mar 15 20:35:12 2001
@@ -81,6 +81,11 @@
 {
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
+   if (softirq_active(smp_processor_id()) & 
+softirq_mask(smp_processor_id())) {
+   __sti();
+   do_softirq();
+   return;
+   }
if (!current->need_resched)
safe_halt();
else

Re: Kernel 2.4.2

[John Jasen]

On Thu, 15 Mar 2001, Ted Gervais wrote:

> Anyways - to get things to work, I have put added this statement to the
> top of my /etc/rc.d/rc.inet1 file:
>
> insmod /usr/src/linux/drivers/net/8139too.o.

install a later version of modutils, as the /lib/modules directory tree
has changed between 2.2.x and 2.4.x



-
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: How to optimize routing performance

[J Sloan]

Gregory Maxwell wrote:

> The scheduler schedules tasks not interrupts. Unless it manages to thrash the
> cache, the scheduler can not affect routing performance.

OK, thanks for the clarification - I need to get into the source.

cu

Jup

-
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: How to optimize routing performance

[Mike Kravetz]

On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
> Rik van Riel wrote:
> 
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > There are some scheduler patches that are not part of the
> > > main kernel tree at this point (mostly since they have yet to
> > > be optimized for the common case) which make quite a big
> > > difference under heavy load - you might want to check out:
> > >
> > > http://lse.sourceforge.net/scheduling/
> >
> > Unrelated.   Fun, but unrelated to networking...
> 
> Fun, yes, and perhaps not directly related, however
> under high load, where the sheer numbet of interrupts
> per second begins to overwhelm the kernel, might it
> not be relevant? After all, the benchmarks do point to
> tangible improvements in the performance of network
> server apps.

I'm not sure if these patches would be of any use here.

One benefit of the multi-queue scheduling patches is that
they allow multiple 'wakeups' to run in parallel instead
of being serialized by the global runqueue lock.  Now if
you are getting lots of interrupts which result in task
wakeups that could potentially be run in parallel (on
separate CPUS with no other serialization in the way)
then you 'might' see some benefit.  Those are some big IFs.

I know little about the networking stack or this workload.
Just wanted to explain how this scheduling work 'could'
be related to interrupt load.

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

RE: Is swap == 2 * RAM a permanent thing?

[William T Wilson]

On Thu, 15 Mar 2001, Torrey Hoffman wrote:

> IIRC, when this discussion of swap size first came up, the general
> conclusion was NOT that you should have swap = 2 * RAM, but that you
> should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap
> as you did under 2.2.x.

it seems to me that in 2.2.x it looks like this:

total usage == swap + RAM
under 2.4.x it looks like:
total usage == swap

> So if you never swapped at all under 2.2.x, you should not need any 
> swap space in 2.4.x either. 

Right.

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

[Ted Gervais]

A simple question for you guru's..

I just installed kernel 2.4.2 on a slackware system and have a problem 
with loading a module. It is the 8139too.o module previously the
rtl8139.o.   It seems that this new driver is not being loaded with
this new kernel. Obviously something has changed but I can't seem to see 
where that is.  I noticed though that the directories in /lib/modules for
this kernel is different than 2.2.18.  

Anyways - to get things to work, I have put added this statement to the
top of my /etc/rc.d/rc.inet1 file:

insmod /usr/src/linux/drivers/net/8139too.o.

That seems to get things working but why should I do that.

By the way - I do have  'alias eth0 8139too.o'  in my /etc/modules.conf
file.

Any thoughts on where I might be going wrong. And I do have
'CONFIG_KMOD=y' in my kernel configuration..

---
Earth is a beta site. 

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.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: How to optimize routing performance

[Gregory Maxwell]

On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote:
> Rik van Riel wrote:
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > There are some scheduler patches that are not part of the
> > > main kernel tree at this point (mostly since they have yet to
> > > be optimized for the common case) which make quite a big
> > > difference under heavy load - you might want to check out:
> > >
> > > http://lse.sourceforge.net/scheduling/
> >
> > Unrelated.   Fun, but unrelated to networking...
> 
> under high load, where the sheer numbet of interrupts
> per second begins to overwhelm the kernel, might it
[snip]
> Or are you saying that the bottleneck is somewhere
> else completely, or that there wouldn't be a bottleneck
> in this case if certain kernel parameters were correctly
> set?

The scheduler schedules tasks not interrupts. Unless it manages to thrash the
cache, the scheduler can not affect routing performance.

-
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: Is swap == 2 * RAM a permanent thing?

[Rik van Riel]

On Thu, 15 Mar 2001, William T Wilson wrote:

> it seems to me that in 2.2.x it looks like this:
>
> total usage == swap + RAM
> under 2.4.x it looks like:
> total usage == swap

  total usage == maximum(swap, ram)

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

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

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

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

Re: Need help with allocating a 2M buffer size

[Kai Makisara]

On Thu, 15 Mar 2001, Byron Stanoszek wrote:

> I have a real picky tape drive (DLT series) that likes to be fed large chunks
> of data at once, otherwise after every 2-4KB of data it halts and rewinds
> itself because its cache for writing to the tape is empty.
>
> My best solution to this problem was to use 'tar -b 4096', which sends 4096 x
> 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for
> several weeks, until 2 days ago I got this message (and the backup fails):
>
> st: failed to enlarge buffer to 2097152 bytes.
>
The default maximum number of scatter/gather segments in the tape driver
is 16. This means that big chunks of memory are needed to allocate a 2 MB
buffer. You can increase the number of segments up to, e.g., 128. This
means that only 16 kB chunks are needed to make up a 2 MB buffer. The
number of scatter/gather segments is also limited by your SCSI adapter
driver. Note that even with 16 kB segments you may find problems at
some time because multi-page allocations are needed.

You can increase the number of scatter/gather segments at system
startup/module loading or when compiling the driver. See the file
linux/drivers/scsi/README.st for the syntax and st_options.h for the
compile-time definition.

Kai


-
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: How to optimize routing performance

[Jonathan Morton]

> And we have done experiments with controlling interrupts and running
> the RX at "lower" priority. The idea is take RX-interrupt and immediately
> postponing the RX process to tasklet. The tasklet opens for new RX-ints.
> when its done.  This way dropping now occurs outside the box since and
> dropping becomes very undramatically.



> A bit of explanation. Above is output from tulip driver. We are forwarding
> 44079 and we are dropping  49913 packets per second!  This box has
> full BGP. The DoS attack was going on for about 30 minutes BGP survived
> and the box was manageable. Under a heavy attack it still performs well.

Nice.  Any chance of similar functionality finding its' way outside the
Tulip driver, eg. to 3c509 or via-rhine?  I'd find those useful, since one
or two of my Macs appear to be capable of generating pseudo-DoS levels of
traffic under certain circumstances which totally lock a 486 (for the
duration) and heavily load a P166 - even though said Macs "only" have
10baseT Ethernet.

OTOH, proper management of the circumstances under which this flooding
occurs (it's an interaction bug which occurs when the Linux machine ends up
with a zero-sized TCP receive window) would also be rather helpful.

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

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

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

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


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

Re: How to optimize routing performance

[J Sloan]

Rik van Riel wrote:

> On Thu, 15 Mar 2001, J Sloan wrote:
>
> > Fun, yes, and perhaps not directly related, however
> > under high load, where the sheer numbet of interrupts
> > per second begins to overwhelm the kernel, might it
> > not be relevant?
>
> No.
>
> > Or are you saying that the bottleneck is somewhere
> > else completely,
>
> Indeed. The bottleneck is with processing the incoming network
> packets, at the interrupt level.

OK, I'll take this to kernel newbies!

:-)

Jup

-
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: How to optimize routing performance

[J Sloan]

Rik van Riel wrote:

> On Thu, 15 Mar 2001, J Sloan wrote:
>
> > There are some scheduler patches that are not part of the
> > main kernel tree at this point (mostly since they have yet to
> > be optimized for the common case) which make quite a big
> > difference under heavy load - you might want to check out:
> >
> > http://lse.sourceforge.net/scheduling/
>
> Unrelated.   Fun, but unrelated to networking...

Fun, yes, and perhaps not directly related, however
under high load, where the sheer numbet of interrupts
per second begins to overwhelm the kernel, might it
not be relevant? After all, the benchmarks do point to
tangible improvements in the performance of network
server apps.

Or are you saying that the bottleneck is somewhere
else completely, or that there wouldn't be a bottleneck
in this case if certain kernel parameters were correctly
set?

Just curious,

Jup


-
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: __lock_page calls run_task_queue(&tq_disk) unecessarily? (fwd)

[Marcelo Tosatti]

Linus, 

I never got I answer from you, so I'm going to ask again.

Do you want this patches for 2.4 or not ? 

Yes, I tested them.  

-- Forwarded message --
Date: Mon, 19 Feb 2001 23:05:23 -0200 (BRST)
From: Marcelo Tosatti <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: lkml <[EMAIL PROTECTED]>
Subject: Re: __lock_page calls run_task_queue(&tq_disk) unecessarily?


Btw ___wait_on_page() does something similar.

Here goes the patch for both __lock_page() and ___wait_on_page().


--- linux/mm/filemap.c.orig Mon Feb 19 23:51:02 2001
+++ linux/mm/filemap.c  Mon Feb 19 23:51:33 2001
@@ -611,11 +611,11 @@
 
add_wait_queue(&page->wait, &wait);
do {
-   sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (!PageLocked(page))
break;
-   run_task_queue(&tq_disk);
+
+   sync_page(page);
schedule();
} while (PageLocked(page));
tsk->state = TASK_RUNNING;
@@ -633,10 +633,9 @@
 
add_wait_queue_exclusive(&page->wait, &wait);
for (;;) {
-   sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (PageLocked(page)) {
-   run_task_queue(&tq_disk);
+   sync_page(page);
schedule();
continue;
}


On Mon, 19 Feb 2001, Marcelo Tosatti wrote:

> 
> Hi Linus,
> 
> Take a look at __lock_page:
> 
> static void __lock_page(struct page *page)
> {
> struct task_struct *tsk = current;
> DECLARE_WAITQUEUE(wait, tsk);
> 
> add_wait_queue_exclusive(&page->wait, &wait);
~> for (;;) {
> sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> if (PageLocked(page)) {
> run_task_queue(&tq_disk);
> schedule();
> continue;
> }
> if (!TryLockPage(page))
> break;
> }
> tsk->state = TASK_RUNNING;
> remove_wait_queue(&page->wait, &wait);
> }
> 
> 
> Af a process sleeps in __lock_page, sync_page() will be called even if the
> page is already unlocked. (block_sync_page(), the sync_page routine for
> generic block based filesystem calls run_task_queue(&tq_disk)).
> 
> I don't see any problem if we remove the run_task_queue(&tq_disk) and put
> sync_page(page) there instead, removing the other sync_page(page) at the
> beginning of the loop.
> 
> Comments?
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-
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: How to optimize routing performance

[Rik van Riel]

On Thu, 15 Mar 2001, J Sloan wrote:
> Rik van Riel wrote:
> > On Thu, 15 Mar 2001, J Sloan wrote:
> >
> > > http://lse.sourceforge.net/scheduling/
> >
> > Unrelated.   Fun, but unrelated to networking...
>
> Fun, yes, and perhaps not directly related, however
> under high load, where the sheer numbet of interrupts
> per second begins to overwhelm the kernel, might it
> not be relevant?

No.

> Or are you saying that the bottleneck is somewhere
> else completely,

Indeed. The bottleneck is with processing the incoming network
packets, at the interrupt level.

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

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

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

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

Re: Remote Management (was Re: Alert on LAN)

[Chip Salzenberg]

According to Terje Malmedal:
> I am aware of some motherboards where you can configure the BIOS via
> RS232.  What I want is some way to actually reset a machine that is
> hung.

That's possible with VACM-style management.  It's not just for BIOS.
-- 
Chip Salzenberg  - a.k.a. - <[EMAIL PROTECTED]>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech
-
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: How to optimize routing performance

[Rik van Riel]

On Thu, 15 Mar 2001, J Sloan wrote:

> There are some scheduler patches that are not part of the
> main kernel tree at this point (mostly since they have yet to
> be optimized for the common case) which make quite a big
> difference under heavy load - you might want to check out:
>
> http://lse.sourceforge.net/scheduling/

Unrelated.   Fun, but unrelated to networking...

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

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

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

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

Re: How to optimize routing performance

[Robert Olsson]

[Sorry for the length]

Rik van Riel writes:
 > On Thu, 15 Mar 2001, Robert Olsson wrote:
 > 
 > >  CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
 > >  drivers has to have support for it. But unfortunely very few drivers
 > >  has support for it.
 > 
 > Isn't it possible to put something like this in the layer just
 > above the driver ?

 There is a dropping point in netif_rx. The problem is that knowledge
 of congestion has to be pushed back to the devices that is causing this.

 Alexey added netdev_dropping for drivers to check. And via netdev_wakeup()
 the drivers xon_metod can be called when the backlog below a certain 
 threshold. 

 So from here the driver has do the work. Not investing any resources and
 interrupts in packets we still have to drop. This what happens at very
 high load a kind of livelock. For routers routing protocols will time
 out and we loose conetivity. But I would say its important for all apps.
 
 In 2.4.0-test10 Jamal added sampling of the backlog queue so device
 drivers get the current congestion level. This opens new possiblities.
 

 > It probably won't work as well as putting it directly in the
 > driver, but it'll at least keep Linux from collapsing under
 > really heavy loads ...

 
 And we have done experiments with controlling interrupts and running
 the RX at "lower" priority. The idea is take RX-interrupt and immediately
 postponing the RX process to tasklet. The tasklet opens for new RX-ints.
 when its done.  This way dropping now occurs outside the box since and
 dropping becomes very undramatically.


 As little example of this. I monitored a DoS attack on Linux router
 equipped with this RX-tasklet driver.


Admin up6 day(s) 13 hour(s) 37 min 54 sec 
Last input  NOW
Last output NOW
5min RX bit/s   22.4 M  
5min TX bit/s   1.3 M
5min RX pkts/s  44079< 
5min TX pkts/s  877  
5min TX errors  0
5min RX errors  0
5min RX dropped 49913< 
  
Fb: no 3127894088 low 154133938 mod 6 high 0 drp 0 < Congestion levels

Polling:  ON starts/pkts/tasklet_count 96545881/2768574948/1850259980
HW_flowcontrol xon's 0   



 A bit of explanation. Above is output from tulip driver. We are forwarding
 44079 and we are dropping  49913 packets per second!  This box has 
 full BGP. The DoS attack was going on for about 30 minutes BGP survived 
 and the box was manageable. Under a heavy attack it still performs well.


 Cheers.

--ro

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

VIA audio and parport in 2.4.2

[Will Newton]

I have a Asus K7V motherboard and a SB 128 PCI soundcard.
The motherboard is vt82c686a based.
The SB is a ES1371/AC97 card, seemingly identical to the onboard sound on
this type of motherboard.
However, the sound rarely works, and there are problems with the parport
too.

Sound does not work (usually, I have had it work, but I can't reproduce
it). The parport behaves strangely.

Here is dmesg output:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq= dma=
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: possible IRQ conflict!
0x378: ECP port cfgA=0x10 cfgB=0x00
0x378: ECP settings irq= dma=
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport0: cpp_mux: aa55f00f52ad51(80)
parport0: cpp_daisy: aa5500ff(80)
parport0: assign_addrs: aa5500ff(80)
parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3
lp0: using parport0 (interrupt-driven).

I don't know why it prints it twice.

When printing errors are printed (buffer overrun or something like that,
it seems RedHat only logs these damn things to console).

Also if I try to disbale interrupt driven printing I get an error:

[root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0
tunelp: ioctl: Invalid argument
/dev/printers/0 using IRQ 7


With sound, I get:

es1371: version v0.27 time 00:47:56 Mar  7 2001
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
PCI: Found IRQ 10 for device 00:0b.0
es1371: found es1371 rev 8 at io 0xa400 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97  codec, id: 0x:0x (Unknown)

Where the id field obviously should not be zero.

The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but
in Linux the sound doesn't work and the printer keeps hanging.

I also get spurios interrupts on 7 when the parport is not loaded.

I know other people are seeing similar effects with sinilar hardware, but
to my knowledge there have been no solutions put forward.

If anyone has any ideas I can try to diagnose this problem more clearly
or wants any specific information, please ask.


-
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: Remote Management (was Re: Alert on LAN)

[Terje Malmedal]

[Chip Salzenberg]
> IBM says, as quoted by Terje Malmedal:
>> With the latest release, Alert on LAN 2 now extends IT
>> capabilities to remotely manage and control their
>> networked PCs:
>> 
>> Remote system reboot upon report of a critical failure 
>> Repair Operating System 
>> Update BIOS image 
>> Perform other diagnostic procedures 

> OK, fine... but: Where are the authentication and authorization?!
> Surely I'm not the only person to see in this "Alert On LAN 2" the
> potential for a security disaster.  I know I will never buy anything
> that supports AOL2 until its security features are openly documented
> and testable.

Definitely scary possibilites there. I think the best we can
realistically hope for is that you can require a password to be sent
with each packet.

>> The feature I really need is to be able to reset the machine
>> remotely when Linux is hung.

> Some current PC motherboards support remote management via a serial
> line.  Of course, you'll need software: The VA Cluster Manager (GPL'd
> - http://sourceforge.net/projects/vacm) can monitor and control any
> number of clients, limited only by the number of serial ports you can
> give it.  VACM also includes optional client support for enhanced
> monitoring, e.g. of temperatures.  I'm not sure which motherboards it
> supports, but I'm sure you can find current documentation.  :-)

I am aware of some motherboards where you can configure the BIOS via
RS232. What I want is some way to actually reset a machine that is
hung. Currently we are using power-strips where we can switch on and
off individual plugs by telneting to the strip.

We also use Netra T1's from SUN. They have a small microprosessor
listening on the serial port. If you send the escape sequence #. it
will take over and allow you to reset or power-cycle the real
computer. Very cool stuff: 
lom>version
LOM version: 2.1
LOM checksum: 7CA3
LOM firmware build Aug  6 1999 09:46:27
lom>help
The following commands are supported:

alarmon
alarmoff
check
console
environment
faulton
faultoff
help
poweron
poweroff
reset
show
version
lom>environment
LEDs:
faultled OFF
Alarm1 = OFF
Alarm2 = OFF
Alarm3 = OFF

Fans:
1 = OK speed = 74%
2 = OK speed = 74%
3 = OK speed = 74%

PSUs:
1 = OK

This functionality is what I hope Alert on LAN2 can give me.

-- 
 - Terje
[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: Bug in 2.2 update_vm_cache_conditional?

[Andrea Arcangeli]

On Wed, Mar 14, 2001 at 06:49:33PM +0100, [EMAIL PROTECTED] wrote:
> that manifests itself only on S/390:

I guess it could trigger also on sparc.

> Do you agree that this is a bug?  What do you think of this fix:

That's a severe bug, fix is obviously right.

Andrea
-
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: Performance is weird (fwd)

[Manfred Spraul]

One difference between idle and a running user space app is that the
kernel->user space return path checks for pending softirqs, but the ide
thread doesn't.

Perhaps cpu_idle() should also check for pending softirq's before
hlt'ing?

idle thread is running.
* hw interrupt
* * hw interrupt handler
* * * packet arrives
* * * softirq marked
* * hw interrupt handler returns
* do_softirq
* * net_rx called
* * * an hw interrupt interrupts net_rx
* * * * a second packet arrives, softirq marked again.
* * * hw interrupt returns
* * net_rx returns
* do_softirq notices that net_rx is queued again, but doesn't process
it immediately (otherwise it would cause an endless loop)
* hw interrupt returns
idle thread sleeps again.
!! one packet is waiting unprocessed

What about adding if(softirq_active...) do_softirq() into default_idle?
--
Manfred


-
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: How to optimize routing performance

[J Sloan]

Just my .02 -

There are some scheduler patches that are not part of the
main kernel tree at this point (mostly since they have yet to
be optimized for the common case) which make quite a big
difference under heavy load - you might want to check out:

http://lse.sourceforge.net/scheduling/

cu

Jup


Mårten Wikström wrote:

> I've performed a test on the routing capacity of a Linux 2.4.2 box versus a
> FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with 64Mb memory,
> and two DEC 100Mbit ethernet cards. I used a Smartbits test-tool to measure
> the packet throughput and the packet size was set to 64 bytes. Linux dropped
> no packets up to about 27000 packets/s, but then it started to drop packets
> at higher rates. Worse yet, the output rate actually decreased, so at the
> input rate of 4 packets/s almost no packets got through. The behaviour
> of FreeBSD was different, it showed a steadily increased output rate up to
> about 7 packets/s before the output rate decreased. (Then the output
> rate was apprx. 4 packets/s).
> I have not made any special optimizations, aside from not having any
> background processes running.
>
> So, my question is: are these figures true, or is it possible to optimize
> the kernel somehow? The only changes I have made to the kernel config was to
> disable advanced routing.
>
> Thanks,
>
> Mårten
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: Is swap == 2 * RAM a permanent thing?

[Rik van Riel]

On Thu, 15 Mar 2001, James Lewis Nance wrote:
> On Thu, Mar 15, 2001 at 08:26:35PM -0300, Rik van Riel wrote:
> > When we swap something in from swap, it is in effect "duplicated"
> > in memory and swap. Freeing the swap space of these duplicates
> > will mean we have, effectively, more swap space.
>
> Thanks for the explanation.  It brings another question to
> mind.  Lets assume that I have two 16M processes and 32M of swap
> space.  Both the processes have been swapped out at some point
> in time so the swap space is full.  A third process is running
> and tries to allocate some memory, and the kernel has no free
> pages.  Since swap is full, will the kernel kill my process, or
> will it try and page out one of the processes that does have
> space on swap?

It will end up swapping out the two processes which already have
space in swap ... even if the 3rd process is idle.

In that situation you could argue for 2 things:

1) the kernel should reclaim space when swap is full
2) you need more swap

I guess we'll want a bit of both, possibly with 1) being an
optional thing (since swap fragmentation could well be as
bad for performance as swapping out the wrong thing).

regards,

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

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

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

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

2.2.19 pre13 doesn't like retransmitted SYN ACK packets

[Zack Weinberg]

2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which
arrives after we've sent out the final ACK of the handshake.  For
example:

tcpdump: listening on eth0
15:15:15.075670 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
S 1057306555:1057306555(0) win 32120
 (DF) [tos 0x10] 
15:15:15.156320 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341:
S 1042976132:1042976132(0) ack 1057306556 win 1460 
15:15:15.156364 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
. ack 1 win 32120 (DF) [tos 0x10] 
15:15:15.204186 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341:
S 1042976132:1042976132(0) ack 1057306556 win 1460 
15:15:15.204232 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www:
R 1057306556:1057306556(0) win 0

I do not know if this behavior is correct or not from the TCP spec.
It seems unlikely to me, given that duplicate packets are expected 
and ignored just about everywhere else.  As a practical matter, this
behavior makes it close to impossible to communicate with a host that
commonly sends duplicate SYN ACKs.  plan9.bell-labs.com is just such;
I estimate I get past the initial handshake one connection in twenty.

This kernel does not have SYN cookies compiled in.  rp_filter is 1,
all other TCP and IP tunables are at their defaults.

zw
-
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: Network init script causes 2.2.18 kernel oops (tulip driver)

[Jeremy Jackson]

Matthew Callaway wrote:

> Greetings,
>
> This is a reproducible oops, and my guess is that it's related to
> the tulip driver included in the 2.2.18 source tree.  We're using
> a D-Link 4 port NIC, and it appears that it doesn't work well with
> IPV6 interfaces.

I have had problems with this NIC as well... Redhat's installer/kudzu
tries to use de4x5 (sp?) module ... bad news.  But it works fine using
old_tulip module with only IPv4.  Same with 2.2 series and 2.4 series
kernels. FYI

>
>
> Keywords:  linux kernel-2.2.18 tulip D-Link 4-port NIC DFE-570 TX

-
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: Is swap == 2 * RAM a permanent thing?

[Rik van Riel]

On Thu, 15 Mar 2001, Mike Harrold wrote:

> 1) If a process uses swap space and then later (after being paged
>into memory -- or even not) it completes, is killed, etc., is
>the swap space reclaimed then?
>
> 2) If a process uses swap, is paged into memory, and is then swapped
>out again, does it re-use the same swap as before?

Yes and yes.

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

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

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

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

Re: Is swap == 2 * RAM a permanent thing?

[James Lewis Nance]

On Thu, Mar 15, 2001 at 08:26:35PM -0300, Rik van Riel wrote:
> When we swap something in from swap, it is in effect "duplicated"
> in memory and swap. Freeing the swap space of these duplicates
> will mean we have, effectively, more swap space.

Hi Rik,
Thanks for the explanation.  It brings another question to mind.  Lets
assume that I have two 16M processes and 32M of swap space.  Both the
processes have been swapped out at some point in time so the swap space is
full.  A third process is running and tries to allocate some memory, and
the kernel has no free pages.  Since swap is full, will the kernel kill my
process, or will it try and page out one of the processes that does have
space on swap?

Thanks,

Jim
-
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: poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)

[kuznet]

Hello!

> Sure, workarounds exist, but they just complicates
> things.

Working around --- what?

An example of application hitting the case is enough to make
me completely agreed.

But genarally we are not going to match any os and even yourselves
yesterday or tomorrow in the cases when behaviour is truly undefined
and the answer is meaningless. For me any solution from retunring 0
or returning POLLHUO to killing offending application or generating
an answer using random number generator look equally good, acceptable
and 100% compatible in this case. 8)

Alexey
-
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: Is swap == 2 * RAM a permanent thing?

[Torrey Hoffman]

IIRC, when this discussion of swap size first came up, the general 
conclusion was NOT that you should have swap = 2 * RAM, but that you 
should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap 
as you did under 2.2.x.

So if you never swapped at all under 2.2.x, you should not need any 
swap space in 2.4.x either. 

Is this correct?  

Also, what would be the consequences of not having "enough" swap?  
Just OOM faster?  Or more serious than that?

I have 512MB of RAM and rarely swap, so normally have just a 256MB
swap partition.  Is this bad?  It seems to work fine...

Thanks!

Torrey Hoffman
-
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: How to optimize routing performance

[Rik van Riel]

On Thu, 15 Mar 2001, Robert Olsson wrote:

>  CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device
>  drivers has to have support for it. But unfortunely very few drivers
>  has support for it.

Isn't it possible to put something like this in the layer just
above the driver ?

It probably won't work as well as putting it directly in the
driver, but it'll at least keep Linux from collapsing under
really heavy loads ...

regards,

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

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

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

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

Re: Hardware problem detection? Linux 2.4.3-pre4 lockups.

[Chris Meadors]

On Thu, 15 Mar 2001, Nathan Black wrote:

> I am at a total loss, But I have found some interesting anomalies with my
> hardware.

That is about how I was feeling when I had similar problems.

> My Current Setup:
> Supermicro S370DE6 (Serverworks Chipset)
> Dual PIII 866
> 2 x 256 MB PC133 ECC SDRAM
> onboard AIC 7899 SCSI Controller.
> 36G,73GB Seagate Cheetah Drive.
> Voodoo4 4500 AGP video,
> Fore PCA 200e ATM

My setup was (is):
Tyan Thunder 2500 (Serverworks)
Dual PIII 667s
2 x 512 MB PC133 ECC SDRAM
Onboard dual SYM53C896 controller
5 18.2 GB Seagate Cheetahs
nVideo Vanta
Onboard Intel 10/100

> Problem, I have a program the can read a file(large, or small) it will then
> transmit the data over atm, ethernet, localhost,or write to a file.

I could move a lot of network traffic as long as I wasn't hitting the disk
too hard.

> I have noticed that the machine will consistently crash(hard lockup) when I
> do a read loop of the File. It never locks up at the same place, and I have
> changed it so that it never actually does anything with the data after it
> reads. Still, same result.

Any time I pushed the disk subsystem hard I would get a lockup.  Sometimes
the kernel would oops, the program writing to the disk would segfault, but
always the machine locked hard.

> Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will
> allow me to run forever.
> Also, Setting the L1 Cache to Write-through instead of write back will allow
> me to run forever at 133, but the performance hit is worse than setting the
> FSB to 100.

If I forced things to run slower I could run longer, like changing the
cache setting, never tried the FSB setting.  But even with the machine
slowed down I could eventually lock it up if I pushed the disks hard
enough (12 bonnies at the same time would always do it).

> Another note. When I have attempted to compile the kernel for Uni processor.
> I started getting segmentation faults with gcc.
> Now this tells me it might be the processor. But I have nothing overclocked,
> so I would think that it might be some kind of timing issue in the kernel.

I saw so much strange stuff I couldn't pin it down to one thing, except
perhaps the processor.

> I have two machines set up this way. One is much more stable. But I do
> observe the occasional crash.(hard lockup)

I too had two identical machines.  I was doing all my work on one, and was
planning on copying the finished product over to the second when I was
done.  After I started suspecting the hardware, I started up the other
machine.  It ran perfectly.  I could push it as hard as I wanted with no
trouble at all.

> I have also seen fsck crash as well. when the system was not shut down
> correctly. ( as a hard lockup happens very frequently.)
>
> Here are some things that I have tried, but Have not fixed it.
> 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic)
> 2) Uni Kernel w/ & w/out apic
>
> I am at a total loss.
> Is there anything I can do(other than run at 100 FSB)?
>
> Nathan
>
> P.S. I have enclosed the dmesg output for my Uniprocessor kernel
>  <>

In the end I started swapping processors between the two machines.  I
found the problem followed 1 of my processors.  I called Intel and after 2
days of convincing they RMAed my old processor and sent me a replacement.
Both machines have been running perfectly since then.  If you have any
more processors I'd try swapping them around.  But since you are seeing
problems with 2 similar machines, I wouldn't get my hopes up as to this
being the solution.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..." --David Lynch, Twin Peaks


-
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: Is swap == 2 * RAM a permanent thing?

[christophe barbe]

Ok I understand better now.
So when we swap in, the place is still reserved in swap for the next time we swap off 
the same memory part.
The swap is freed only when the owner terminates.
Then when we need more memory, we need to swap off but we don't use the duplicated 
part.
I understand that it is to avoid fragmentation but this can lead to false OOM 
situation (false because we have free memory in swap but it's reserved to avoid 
fragmentation).

Christophe

On ven, 16 mar 2001 00:26:35 Rik van Riel wrote:
> On Thu, 15 Mar 2001, christophe barbe wrote:
> 
> > Please Rik, could you explain what you mean with "reclaim swap
> > space when we run out". In my (limited) understanding, when
> > there's no more free memory (ram and swap space), the kernel
> > starts to kill process (and the choice is a difficult point).
> > Are you proposing to add an API to reclaim swap instead of
> > killing process ?
> 
> When we swap something in from swap, it is in effect "duplicated"
> in memory and swap. Freeing the swap space of these duplicates
> will mean we have, effectively, more swap space.
> 
> Rik
> --
> Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
> 
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
>   http://www.surriel.com/
> http://www.conectiva.com/ http://distro.conectiva.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Network init script causes 2.2.18 kernel oops (tulip driver)

[Matthew Callaway]

Greetings,

This is a reproducible oops, and my guess is that it's related to
the tulip driver included in the 2.2.18 source tree.  We're using
a D-Link 4 port NIC, and it appears that it doesn't work well with
IPV6 interfaces.

Keywords:  linux kernel-2.2.18 tulip D-Link 4-port NIC DFE-570 TX

Relevant Software
-
kernel 2.2.18 i686
modutils-2.3.21
glibc-2.1.3-22
ipv6 enabled
net-tools 1.54
ifconfig 1.39 (1999-03-18)
tulip module (static const char version[] = "tulip.c:v0.91g-ppc 7/16/99 
[EMAIL PROTECTED]\n";) from the kernel src.rpm.
initscripts-5.00-1.i386.rpm (with the addition below)

Relevant Hardware
-
NIC: D-Link DFE-570 TX 4-port

Cause of the Oops
-
I had included IPV6 support into the kernel without really wanting
it, so my intention was to turn off the IPV6 interfaces until I could
replace the kernel.  I created the following script to be called by
ifup-post.  The inclusion of the script cause the oops every time.
Note that simply issuing the "ifconfig" command line would not always
cause the oops.  It seemed to happen 100% of the time only if it
was immediately called by ifup-post, as if timing had something to
do with the problem.

It is also odd to me that the IPV6 interfaces came up automatically,
even though the init scripts do not specify an IP address for them,
or bring them up specifically.  /sbin/ifconfig just makes a guess and
does it.

/etc/sysconfig/network-scripts/ifup-local:
#! /bin/sh

DEVICE=$1

# turn off inet6 IFs
if [ ! -z "${DEVICE}" ]; then
  INET6ADDR=$( ifconfig ${DEVICE} |grep inet6 |awk '{print $3}' )
  if [ ! -z "${INET6ADDR}" ]; then
ifconfig ${DEVICE} del ${INET6ADDR}
  fi
fi


Oops Info (copied by hand, klogd didn't catch it)
-
Call Trace: [] [] []
[] [] []
[] [] []
[] [] []
Code: 8b 40 34 89 42 04 8b 86 88 00 00 00 2b 86 84 00 00 00 83 f8

ksymoops output
---
ksymoops -m /boot/System.map -v vmlinux oops.txt
ksymoops 0.7c on i686 2.2.18.  Options used
 -v vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.18/ (default)
 -m /boot/System.map-spc-2.2.18-6 (specified)

Call Trace: [] [] []
[] [] []
[] [] []
[] [] []
Code: 8b 40 34 89 42 04 8b 86 88 00 00 00 2b 86 84 00 00 00 83 f8
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; c0109f4d 
Trace; c0117ca1 
Trace; c010a2a3 
Trace; c0109f70 
Trace; c010796d 
Trace; c0106000 
Trace; c0107990 
Trace; c01090ec 
Trace; c0106000 
Trace; c010607b 
Trace; c0106000 
Trace; c0100175 
Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 40 34  mov0x34(%eax),%eax
Code;  0003 Before first symbol
   3:   89 42 04  mov%eax,0x4(%edx)
Code;  0006 Before first symbol
   6:   8b 86 88 00 00 00 mov0x88(%esi),%eax
Code;  000c Before first symbol
   c:   2b 86 84 00 00 00 sub0x84(%esi),%eax
Code;  0012 Before first symbol
  12:   83 f8 00  cmp$0x0,%eax


I hope this is enough to find the problem.  I can reproduce it at will,
so if you need more information, contact me and I will be glad to help.


Matthew Callaway

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

Hardware problem detection? Linux 2.4.3-pre4 lockups.

[Nathan Black]

I am at a total loss, But I have found some interesting anomalies with my
hardware. 

My Current Setup:
Supermicro S370DE6 (Serverworks Chipset)
Dual PIII 866
2 x 256 MB PC133 ECC SDRAM
onboard AIC 7899 SCSI Controller.
36G,73GB Seagate Cheetah Drive.
Voodoo4 4500 AGP video,
Fore PCA 200e ATM 


Problem, I have a program the can read a file(large, or small) it will then
transmit the data over atm, ethernet, localhost,or write to a file.

I have noticed that the machine will consistently crash(hard lockup) when I
do a read loop of the File. It never locks up at the same place, and I have
changed it so that it never actually does anything with the data after it
reads. Still, same result.

Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will
allow me to run forever.
Also, Setting the L1 Cache to Write-through instead of write back will allow
me to run forever at 133, but the performance hit is worse than setting the
FSB to 100. 

Another note. When I have attempted to compile the kernel for Uni processor.
I started getting segmentation faults with gcc.
Now this tells me it might be the processor. But I have nothing overclocked,
so I would think that it might be some kind of timing issue in the kernel.

I have two machines set up this way. One is much more stable. But I do
observe the occasional crash.(hard lockup) 

I have also seen fsck crash as well. when the system was not shut down
correctly. ( as a hard lockup happens very frequently.)

Here are some things that I have tried, but Have not fixed it.
1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic)
2) Uni Kernel w/ & w/out apic

I am at a total loss. 
Is there anything I can do(other than run at 100 FSB)?

Nathan

P.S. I have enclosed the dmesg output for my Uniprocessor kernel
 <> 



 dmesg.out.uni

pivot_root & linuxrc problem

[Art Boulatov]

Hi,

may be thats a bug, or I'm doing something really wrong :)

from Documentation/initrd.txt:

"# cd /new-root
   # mkdir initrd
   # pivot_root . initrd

Now, the linuxrc process may still access the old root via its
executable, shared libraries, standard input/output/error, and its
current root directory. All these references are dropped by the
following command:

# exec chroot . what-follows dev/console 2>&1

Where what-follows is a program under the new root, e.g. /sbin/init"



How can I "exec /sbin/init" from "/linuxrc", whatever it is,
if "linuxrc" does not get PID=1?

Actually, why does NOT "linuxrc" get PID=1?

A task list after booting with "root=/dev/rd/0" and "init=/linuxurc",
where "linuxrc" is simply "bash", shows that:
"swapper" got PID=1,
next come other kernel threads with a parent PID=1,
and "linuxrc" got PID=7 and a parent PID=1.

"init" sees it does not have PID=1 and simply bails out, next happens this:

"Note: if linuxrc or any program exec'ed from it terminates for some
reason, the old change_root mechanism is invoked (see section "Obsolete
root change mechanism")."


I probably misunderstand something here,
but could you please help?

In summary:

What is "swapper" and why does it get PID=1 and "linuxrc" does not?
If it is supposed to be that way, how do I "exec /sbin/init" from
"linuxrc" then?
Also why "/linuxrc" is hardcoded in init/main.c,
so telling kernel "root=/dev/rd/0 init=/sbin/whatever" does still invoke
"/linuxrc"?

Thanks a lot,
Art.

-
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: How to optimize routing performance

[Martin Josefsson]

On Thu, 15 Mar 2001, Rik van Riel wrote:

> On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote:
> 
> > I've performed a test on the routing capacity of a Linux 2.4.2 box
> > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with
> > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits
> > test-tool to measure the packet throughput and the packet size was set
> > to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but
> > then it started to drop packets at higher rates. Worse yet, the output
> > rate actually decreased, so at the input rate of 4 packets/s
> > almost no packets got through. The behaviour of FreeBSD was different,
> > it showed a steadily increased output rate up to about 7 packets/s
> > before the output rate decreased. (Then the output rate was apprx.
> > 4 packets/s).
> 
> > So, my question is: are these figures true, or is it possible to
> > optimize the kernel somehow? The only changes I have made to the
> > kernel config was to disable advanced routing.
> 
> There are some flow control options in the kernel which should
> help. From your description, it looks like they aren't enabled
> by default ...

You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the
kernel gets _alot_ of interrupts from the NIC and dosn't have any cycles
left to do anything. So you want to turn this on!

> At the NordU/USENIX conference in Stockholm (this february) I
> saw a nice presentation on the flow control code in the Linux
> networking code and how it improved networking performance.
> I'm pretty convinced that flow control _should_ be saving your
> system in this case.

That was probably Jamal Hadi and Robert Olsson. They have been optimizing
the tulip driver. These optimizations havn't been integrated with the
"vanilla" driver yet, but I hope the can integrate it soon.

They have one version that is very optimized and then they have one
version that have even more optimizations, ie. it uses polling at high
interruptload.

you will find these drivers here:
ftp://robur.slu.se/pub/Linux/net-development/
The latest versions are:
tulip-ss010111.tar.gz
and
tulip-ss010116-poll.tar.gz

> OTOH, if they _are_ enabled, the networking people seem to have
> a new item for their TODO list. ;)

Yup.

You can take a look here too:

http://robur.slu.se/Linux/net-development/jamal/FF-html/

This is the presentation they gave at OLS (IIRC)

And this is the final result:

http://robur.slu.se/Linux/net-development/jamal/FF-html/img26.htm

As you can see the throughput is a _lot_ higher with this driver.

One final note: The makefile in at least tulip-ss010111.tar.gz is in the
old format (not the new as 2.4.0-testX introduced), but you can copy the
makefile from the "vanilla" driver and It'lll work like a charm.

Please redo your tests with this driver and report the results to me and
this list. I really want to know how it compares against FreeBSD.

/Martin

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