that might not be a good idea. Pls apply o/w.
Thanx,
Tomar
--- Nagendra Tomar <[EMAIL PROTECTED]> wrote:
> Hello James,
> My understanding is that the scsi_device in SDEV_DEL state
> is there in the scsi_host->devices/scsi_target->devices queue, just
> because t
that might not be a good idea. Pls apply o/w.
Thanx,
Tomar
--- Nagendra Tomar [EMAIL PROTECTED] wrote:
Hello James,
My understanding is that the scsi_device in SDEV_DEL state
is there in the scsi_host-devices/scsi_target-devices queue, just
because there is some outstanding command
tch. What should
> be considered is where did the resurrection of the sdev go wrong. I
> remember that Hannes did some updates
> http://marc.info/?l=linux-scsi=118215727101887=2
> but I don't believe these ever got merged upstream. Perhaps that's a good
> place to star
__scsi_device_lookup and __scsi_device_lookup_by_target do not
check for the sdev_state and hence return scsi_devices with
sdev_state set to SDEV_DEL also. It has the following side effects.
We can have two scsi_devices with the same HBTL queued in
the
__scsi_device_lookup and __scsi_device_lookup_by_target do not
check for the sdev_state and hence return scsi_devices with
sdev_state set to SDEV_DEL also. It has the following side effects.
We can have two scsi_devices with the same HBTL queued in
the scsi_host-__devices/scsi_target-devices
://marc.info/?l=linux-scsim=118215727101887w=2
but I don't believe these ever got merged upstream. Perhaps that's a good
place to start.
-- james s
Nagendra Tomar wrote:
__scsi_device_lookup and __scsi_device_lookup_by_target do not
check for the sdev_state and hence return scsi_devices
--- Davide Libenzi <[EMAIL PROTECTED]> wrote:
> That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the
> ability to write, and it is not meant as to signal every time a packet
> (skb) is sent on the wire (and the buffer released).
Aren't they both the same ? Everytime an
--- Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> Unfortunately f_op->poll() does not let the caller to specify the events
> it's interested in, that would allow to split send/recevie wait queues and
> better detect read/write cases.
> The detection of a waitqueue_active(->sk_wr_sleep) would
--- Davide Libenzi <[EMAIL PROTECTED]> wrote:
> Looking back at it, I think the current TCP code is right, once you look
> at the "event" to be a output buffer full->with_space transition.
> If you drop an fd inside epoll with EPOLLOUT|EPOLLET and you get an event
> (free space on the output
--- Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Nagendra Tomar a écrit :
> > --- Davide Libenzi <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 19 Sep 2007, David Miller wrote:
> >>
> >>> From: Nagendra Tomar <[EMAIL
--- Eric Dumazet [EMAIL PROTECTED] wrote:
Nagendra Tomar a écrit :
--- Davide Libenzi [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007, David Miller wrote:
From: Nagendra Tomar [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
With the SOCK_NOSPACE check
--- Davide Libenzi [EMAIL PROTECTED] wrote:
Looking back at it, I think the current TCP code is right, once you look
at the event to be a output buffer full-with_space transition.
If you drop an fd inside epoll with EPOLLOUT|EPOLLET and you get an event
(free space on the output buffer),
--- Davide Libenzi [EMAIL PROTECTED] wrote:
Unfortunately f_op-poll() does not let the caller to specify the events
it's interested in, that would allow to split send/recevie wait queues and
better detect read/write cases.
The detection of a waitqueue_active(-sk_wr_sleep) would work fine
--- Davide Libenzi [EMAIL PROTECTED] wrote:
That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the
ability to write, and it is not meant as to signal every time a packet
(skb) is sent on the wire (and the buffer released).
Aren't they both the same ? Everytime an
--- Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Sep 2007, David Miller wrote:
>
> > From: Nagendra Tomar <[EMAIL PROTECTED]>
> > Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
> >
> > > With the SOCK_NOSPACE check in tcp_check_space(), this
--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Nagendra Tomar <[EMAIL PROTECTED]>
> Date: Wed, 19 Sep 2007 15:55:58 -0700 (PDT)
>
> > I agree that setting SOCK_NOSPACE would have been a more elegant
> > fix. Infact I thought a lot about that before d
--- David Miller <[EMAIL PROTECTED]> wrote:
> From: Nagendra Tomar <[EMAIL PROTECTED]>
> Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
>
> > With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call will
> > not return, even when the incoming acks f
The tcp_check_space() function calls tcp_new_space() only if the
SOCK_NOSPACE bit is set in the socket flags. This is causing Edge Triggered
EPOLLOUT events to be missed for TCP sockets, as the ep_poll_callback()
is not called from the wakeup routine.
The SOCK_NOSPACE bit indicates the
The tcp_check_space() function calls tcp_new_space() only if the
SOCK_NOSPACE bit is set in the socket flags. This is causing Edge Triggered
EPOLLOUT events to be missed for TCP sockets, as the ep_poll_callback()
is not called from the wakeup routine.
The SOCK_NOSPACE bit indicates the
--- David Miller [EMAIL PROTECTED] wrote:
From: Nagendra Tomar [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call will
not return, even when the incoming acks free the buffers.
Note
--- David Miller [EMAIL PROTECTED] wrote:
From: Nagendra Tomar [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:55:58 -0700 (PDT)
I agree that setting SOCK_NOSPACE would have been a more elegant
fix. Infact I thought a lot about that before deciding on this fix.
I guess this means you
--- Davide Libenzi [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007, David Miller wrote:
From: Nagendra Tomar [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT)
With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call
will
not return, even when
22 matches
Mail list logo
