Jorge Nerin wrote:
>
> Paul Gortmaker wrote:
> >
> > >
> > > 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 5 -f other_host takes down the network access
> > > with no messages (ne2k-pci), and no
Hi,
I have to own up and say that it was me :-) you'll see that DECnet is the
only protocol to use these macros at the moment. I'm sure though that I
only copied what IPv4 was doing at the time, along with the hints I had
from yourself and Dave,
Steve.
>
> Hello!
>
> > Alexey! Even someone
Hello!
> Alexey! Even someone understood all this already, look
> to include/net/sock.h SOCK_SLEEP_{PRE,POST} macros :-)
>
> I will compose a patch to fix all this.
O! But who was this wiseman? 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hello!
Alexey! Even someone understood all this already, look
to include/net/sock.h SOCK_SLEEP_{PRE,POST} macros :-)
I will compose a patch to fix all this.
O! But who was this wiseman? 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi,
I have to own up and say that it was me :-) you'll see that DECnet is the
only protocol to use these macros at the moment. I'm sure though that I
only copied what IPv4 was doing at the time, along with the hints I had
from yourself and Dave,
Steve.
Hello!
Alexey! Even someone
Jorge Nerin wrote:
Paul Gortmaker wrote:
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 5 -f other_host takes down the network access
with no messages (ne2k-pci), and no possibility of being
Hello!
> > In any case, Andrew, where is the race, when we enter in sleeping state?
> > Wakeup is not lost, it is just not required when we are not going
> > to schedule and force task to running state.
>
> set_current_state(TASK_INTERRUPTIBLE);
> add_wait_queue(...);
> /*
Hello!
In any case, Andrew, where is the race, when we enter in sleeping state?
Wakeup is not lost, it is just not required when we are not going
to schedule and force task to running state.
set_current_state(TASK_INTERRUPTIBLE);
add_wait_queue(...);
/* window here
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > No, that code is correct, provided (current->state == TASK_RUNNING)
> > on entry. If it isn't, there's a race window which can cause
> > lost wakeups. As a check you could add:
> >
> > if ((current->state &
Paul Gortmaker wrote:
>
> >
> > 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 5 -f other_host takes down the network access
> > with no messages (ne2k-pci), and no possibility of being restored
> > without
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > No, that code is correct, provided (current->state == TASK_RUNNING)
> > on entry. If it isn't, there's a race window which can cause
> > lost wakeups. As a check you could add:
> >
> > if ((current->state &
Hello!
> No, that code is correct, provided (current->state == TASK_RUNNING)
> on entry. If it isn't, there's a race window which can cause
> lost wakeups. As a check you could add:
>
> if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
> BUG();
Hello!
> if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE))
> == 0)
> BUG();
The Puzzle... 8) It is truly impossible.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
Andrew Morton wrote:
>
> Jorge Nerin wrote:
> >
> > ...
> > 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
>
> 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 5 -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
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 5 -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
Hello!
if ((current-state (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE))
== 0)
BUG();
The Puzzle... 8) It is truly impossible.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
Hello!
No, that code is correct, provided (current-state == TASK_RUNNING)
on entry. If it isn't, there's a race window which can cause
lost wakeups. As a check you could add:
if ((current-state (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
BUG();
Though it
[EMAIL PROTECTED] wrote:
Hello!
No, that code is correct, provided (current-state == TASK_RUNNING)
on entry. If it isn't, there's a race window which can cause
lost wakeups. As a check you could add:
if ((current-state (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
[EMAIL PROTECTED] wrote:
Hello!
No, that code is correct, provided (current-state == TASK_RUNNING)
on entry. If it isn't, there's a race window which can cause
lost wakeups. As a check you could add:
if ((current-state (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
Jorge Nerin wrote:
>
> ...
> 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)
> {
>
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
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
Jorge Nerin wrote:
...
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)
{
Paul,
Ok, here's what I have. Included are your changes, as well as
drivers/net/ne.c:
* use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)
* request_region first thing in ne_probe1, before any hardware
interaction takes place. Eliminates any potential resource races. Also
On Wed, 1 Nov 2000, Paul Gortmaker wrote:
> Jeff Garzik wrote:
> > Paul Gortmaker wrote:
> > > There is no urgency in trying to squeeze a patch like this in the back
> > > door of a 2.4.0 release. For example, there are people out there now
> > > who are using the ne.c driver to run both ISA
On Wed, 1 Nov 2000, Paul Gortmaker wrote:
Jeff Garzik wrote:
Paul Gortmaker wrote:
There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release. For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards
Paul,
Ok, here's what I have. Included are your changes, as well as
drivers/net/ne.c:
* use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)
* request_region first thing in ne_probe1, before any hardware
interaction takes place. Eliminates any potential resource races. Also
Jeff Garzik wrote:
>
> Paul Gortmaker wrote:
> > There is no urgency in trying to squeeze a patch like this in the back
> > door of a 2.4.0 release. For example, there are people out there now
> > who are using the ne.c driver to run both ISA and PCI cards in the same
> > box without having to
Jeff Garzik wrote:
Paul Gortmaker wrote:
There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release. For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards in the same
box without having to use 2
Alan Cox wrote:
>
> > This change sounds ok to me, if noone else objects. (I added to the CC
> > a bit) I saw that code, and was thinking about doing the same thing
> > myself. ne2k-pci.c definitely has changes which are not included in
> > ne.c, and it seems silly to duplicate ne2000 PCI
Paul Gortmaker wrote:
> There is no urgency in trying to squeeze a patch like this in the back
> door of a 2.4.0 release. For example, there are people out there now
> who are using the ne.c driver to run both ISA and PCI cards in the same
> box without having to use 2 different drivers. We can
On Mon, 30 Oct 2000, Paul Gortmaker wrote:
> There is no urgency in trying to squeeze a patch like this in the back
> door of a 2.4.0 release. For example, there are people out there now
> who are using the ne.c driver to run both ISA and PCI cards in the same
> box without having to use 2
Jeff Garzik wrote:
>
> pavel rabel wrote:
> > help. So I removed PCI code from ne.c to have ISA only driver. It
>
> This change sounds ok to me, if noone else objects. (I added to the CC
> a bit) I saw that code, and was thinking about doing the same thing
> myself. ne2k-pci.c definitely has
Jeff Garzik wrote:
pavel rabel wrote:
help. So I removed PCI code from ne.c to have ISA only driver. It
This change sounds ok to me, if noone else objects. (I added to the CC
a bit) I saw that code, and was thinking about doing the same thing
myself. ne2k-pci.c definitely has changes
On Mon, 30 Oct 2000, Paul Gortmaker wrote:
There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release. For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards in the same
box without having to use 2
Alan Cox wrote:
This change sounds ok to me, if noone else objects. (I added to the CC
a bit) I saw that code, and was thinking about doing the same thing
myself. ne2k-pci.c definitely has changes which are not included in
ne.c, and it seems silly to duplicate ne2000 PCI support.
Paul Gortmaker wrote:
There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release. For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards in the same
box without having to use 2 different drivers. We can
> This change sounds ok to me, if noone else objects. (I added to the CC
> a bit) I saw that code, and was thinking about doing the same thing
> myself. ne2k-pci.c definitely has changes which are not included in
> ne.c, and it seems silly to duplicate ne2000 PCI support.
Unless there are any
pavel rabel wrote:
> There are three drivers for n2k cards. One is MCA only, one is PCI only,
> and the then the third one (ne.c) is both ISA and PCI. I think the ISA
> driver should be ISA only, as is described in Documentation and in config
> help. So I removed PCI code from ne.c to have ISA
pavel rabel wrote:
There are three drivers for n2k cards. One is MCA only, one is PCI only,
and the then the third one (ne.c) is both ISA and PCI. I think the ISA
driver should be ISA only, as is described in Documentation and in config
help. So I removed PCI code from ne.c to have ISA only
This change sounds ok to me, if noone else objects. (I added to the CC
a bit) I saw that code, and was thinking about doing the same thing
myself. ne2k-pci.c definitely has changes which are not included in
ne.c, and it seems silly to duplicate ne2000 PCI support.
Unless there are any
42 matches
Mail list logo
