public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jorge Nerin <comandante@zaralinux.com>
To: Paul Gortmaker <p_gortmaker@yahoo.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux SMP Mailing List <linux-smp@vger.kernel.org>
Subject: Re: [patch] NE2000
Date: Fri, 03 Nov 2000 18:45:14 +0100	[thread overview]
Message-ID: <3A02F9AA.AFB2DB1B@zaralinux.com> (raw)
In-Reply-To: <E13pz9c-0006Jh-00@the-village.bc.nu> <39FD5433.587FF7C6@zaralinux.com> <39FFE612.2688A5AD@yahoo.com>

Paul Gortmaker wrote:
> 
> Jorge Nerin wrote:
> 
> >
> > Ok, I reported it several times, but it gets ignored. I have a Realtek
> > 8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
> > it stuck by doing a ping -f to a host in the local net, and sometimes it
> > happens doing copies to/from nfs shared resources.
> >
> > rmmod & insmod don't cure the problem, it seems that no interrupts are
> > delivered from the card, and there are no log messages, so a reboot is
> > needed to restore net access.
> >
> > System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
> > as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
> > this problem.
> 
> Any messages from the driver whatsoever?   Does running a non-SMP
> kernel make the problem go away?
> 
> Paul.
> 

Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the
result is a little confusing.

Under SMP a ping -s 50000 -f other_host takes down the network access
with no messages (ne2k-pci), and no possibility of being restored
without a reboot.

Under UP the same command works ok, but after a while the dots stop for
30sec, then ping prints an 'E' and the dots continue. strace revealed
this:

sendmsg(4, {msg_name(16)={sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.20")}},
msg_iov(1)=[{"\10\0\305~|\23\231\0\v\317\2:\177\236\r\0\10\t\n\v\f\r"...,
50008}], msg_controllen=0, msg_flags=0}, 0x800) = 50008 <30.016855>

ping has been waiting for sendmsg to end for 30 seconds! I don't know if
this could be caused by filling the network buffers, and then waiting a
while while the nic sends it out. As the packet size increases (the -s
option) the stops are more frequent, there is still activity on the
network, but I don't know if they are my packets or the replies.

When ping is stopped it's stuck in sock_wait_for_wmem, and when it's
running it's (usually) in wait_for_packet.

So I think that it could be a little window near sock_wait_for_wmem that
could be SMP insecure wich is affecting me.

The code of sock_wait_for_wmem in 2.4.0-test10 is this:

static long sock_wait_for_wmem(struct sock * sk, long timeo)
{
	DECLARE_WAITQUEUE(wait, current);

	clear_bit(SOCK_ASYNC_NOSPACE, &sk->socket->flags);
	add_wait_queue(sk->sleep, &wait);
	for (;;) {
		if (signal_pending(current))
			break;
		set_bit(SOCK_NOSPACE, &sk->socket->flags);
		set_current_state(TASK_INTERRUPTIBLE);
		if (atomic_read(&sk->wmem_alloc) < sk->sndbuf)
			break;
		if (sk->shutdown & SEND_SHUTDOWN)
			break;
		if (sk->err)
			break;
		timeo = schedule_timeout(timeo);
	}
	__set_current_state(TASK_RUNNING);
	remove_wait_queue(sk->sleep, &wait);
	return timeo;
}

Does someone see something SMP insecure? Perhaps I'm totally wrong, this
could also be somewhere in the interrupt handling, don't know.

-- 
Jorge Nerin
<comandante@zaralinux.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-11-03 20:39 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz>
2000-10-29 20:08 ` [patch] NE2000 Jeff Garzik
2000-10-29 20:34   ` Alan Cox
2000-10-30 10:57     ` Jorge Nerin
2000-10-31 13:54       ` changed section attributes Petko Manolov
2000-10-31 14:15         ` Keith Owens
2000-10-31 14:29           ` Petko Manolov
2000-10-31 14:34             ` Keith Owens
2000-10-31 14:41               ` Petko Manolov
     [not found]       ` <39FFE612.2688A5AD@yahoo.com>
2000-11-03 17:45         ` Jorge Nerin [this message]
2000-11-04  5:28           ` [patch] NE2000 Andrew Morton
2000-11-06 11:34             ` Jorge Nerin
2000-11-06 18:40               ` kuznet
2000-11-06 18:46             ` kuznet
2000-11-06 22:32               ` Andrew Morton
2000-11-08 16:45                 ` kuznet
2000-11-07  2:40               ` Andrew Morton
2000-11-08 20:31                 ` kuznet
2000-11-09  1:18                   ` David S. Miller
2000-11-09  1:27                   ` David S. Miller
     [not found]                     ` <3A0A8236.2166E00@uow.edu.au>
2000-11-09 11:20                       ` David S. Miller
2000-11-10  1:45                         ` Tom Leete
2000-11-09 18:03                     ` kuznet
2000-11-09 18:01                       ` Steve Whitehouse
2000-11-06  7:06           ` ping -f kills ne2k (was:[patch] NE2000) Paul Gortmaker
2000-11-06 20:08             ` Jorge Nerin
2000-11-09 15:11               ` Jorge Nerin
2000-10-30  9:17   ` [patch] NE2000 Paul Gortmaker
2000-10-30 14:58     ` pavel rabel
2000-10-30 19:29     ` Jeff Garzik
2000-11-01  5:31       ` Paul Gortmaker
2000-11-01  8:23         ` Donald Becker
2000-11-01 13:27         ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A02F9AA.AFB2DB1B@zaralinux.com \
    --to=comandante@zaralinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-smp@vger.kernel.org \
    --cc=p_gortmaker@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox