[quoted lines by Alan Stern on 2015/02/12 at 10:44 -0500]
>Doesn't your program mask those signals before submitting URBs? It
>must; otherwise the completion signals would be delivered to the
>program in the normal way via a signal handler instead of being
>reported via signalfd.
Once the last m
On Thu, 12 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/12 at 10:10 -0500]
>
> >Not to me. The purpose of signalfd is to report pending signals.
> >Closing or opening a file descriptor shouldn't change the set of
> >pending signals.
>
> Once the last signalfd file de
[quoted lines by Alan Stern on 2015/02/12 at 10:10 -0500]
>Not to me. The purpose of signalfd is to report pending signals.
>Closing or opening a file descriptor shouldn't change the set of
>pending signals.
Once the last signalfd file descriptor for a given signal is closed - in our
case, t
On Thu, 12 Feb 2015, David Laight wrote:
> From: Dave Mielke
> > Okay. Found it. Yes, I was indeed making an assumption. When a signalfd file
> > descriptor is closed, it doesn't remove any of the signals that were in its
> > queue. The next time a signalfd file descriptor is opened for the same
From: Dave Mielke
> Okay. Found it. Yes, I was indeed making an assumption. When a signalfd file
> descriptor is closed, it doesn't remove any of the signals that were in its
> queue. The next time a signalfd file descriptor is opened for the same signal,
> therefore, the signal from the closing of
Okay. Found it. Yes, I was indeed making an assumption. When a signalfd file
descriptor is closed, it doesn't remove any of the signals that were in its
queue. The next time a signalfd file descriptor is opened for the same signal,
therefore, the signal from the closing of the urb on the previou
On Wed, 11 Feb 2015, Dave Mielke wrote:
> Just like the siginfo data has fields that must be left over from somewhere
> else, might it be that the user urb is copied, without clearing the signr
> field, to initialize an underlying system-provided urb?
No, the signr field is always copied from t
[quoted lines by Alan Stern on 2015/02/11 at 16:22 -0500]
>usbfs has only user-generated URBs. It doesn't submit any URBs on its
>own.
I see in tghe code:
devio.c:507: sinfo.si_addr = as->userurb;
So, if ssi_addr is NULL wouldn't that mean that as->userurb is NULL? What
could cause that?
On Wed, 11 Feb 2015, Dave Mielke wrote:
> What might it mean that ssi_addr is NULL? Is a non-user urb ever submitted
> underneath that might be causing the notification?
usbfs has only user-generated URBs. It doesn't submit any URBs on its
own.
Of course, other parts of the kernel can submit
Just like the siginfo data has fields that must be left over from somewhere
else, might it be that the user urb is copied, without clearing the signr
field, to initialize an underlying system-provided urb?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone:
What might it mean that ssi_addr is NULL? Is a non-user urb ever submitted
underneath that might be causing the notification?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: d...@mielke.c
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 15:22 -0500]
>
> >Well, it's a mystery. There are exactly two places in the usbfs code
> >where a signal is sent: async_completed() and usbdev_remove(). As you
> >can tell from the usbfs_snoop output, async
[quoted lines by Alan Stern on 2015/02/11 at 15:22 -0500]
>Well, it's a mystery. There are exactly two places in the usbfs code
>where a signal is sent: async_completed() and usbdev_remove(). As you
>can tell from the usbfs_snoop output, async_completed() doesn't get
>called until the URB com
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 14:45 -0500]
>
> >Does the poll return immediately after the URB is submitted, or is
> >there a delay? What if you try calling poll _before_ the URB is
> >submitted?
>
> poll() is used for the underlying even
[quoted lines by Alan Stern on 2015/02/11 at 14:45 -0500]
>Does the poll return immediately after the URB is submitted, or is
>there a delay? What if you try calling poll _before_ the URB is
>submitted?
poll() is used for the underlying event mechanism, so it's always being caled.
The entire ap
On Wed, 11 Feb 2015, Dave Mielke wrote:
> Thanks. We do take care to block the signal for all other threads just in
> case.
>
> Regarding the possibility of signalfd delivering the signal too early:
> Wouldn't
> it still be true that something within the usbfs code would still need to be
> do
Some information that may be helpful:
There's a significant difference in the way a signal handler is used versus the
way signalfd notifications are used. That difference is that the signal is
unblocked when a signal handler is used (so that the handler can catch it) but
is blocked when signalf
Thanks. We do take care to block the signal for all other threads just in case.
Regarding the possibility of signalfd delivering the signal too early: Wouldn't
it still be true that something within the usbfs code would still need to be
doing something to trigger that behaviour? If usbfs really
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 12:11 -0500]
>
> >That probably is the explanation. I don't know anything about
> >signalfd; you should ask somebody who does.
>
> Okay, I shall. Perhaps you could answer another question that I've been
> w
[quoted lines by Alan Stern on 2015/02/11 at 12:11 -0500]
>That probably is the explanation. I don't know anything about
>signalfd; you should ask somebody who does.
Okay, I shall. Perhaps you could answer another question that I've been
wondering about. Does usbfs send the completion signal t
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 11:13 -0500]
>
> >Hmmm. In addition to usbmon, you can try writing 1 to
> >/sys/module/usbcore/parameters/usbfs_snoop and then seeing what shows
> >up in the dmesg log.
>
> Looking at the snoop logs is hint
[quoted lines by Alan Stern on 2015/02/11 at 11:13 -0500]
>Hmmm. In addition to usbmon, you can try writing 1 to
>/sys/module/usbcore/parameters/usbfs_snoop and then seeing what shows
>up in the dmesg log.
Looking at the snoop logs is hinting that I may need to add another piece to
this puzzl
[quoted lines by Peter Stuge on 2015/02/11 at 16:40 +0100]
>But I don't believe you should have to discard the URB when the
>device disappears.
I can see, from Alan's questions, that I wasn't clear enough. By "was turned
off", I meant that the device's power switch was in its off position. It wa
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 10:54 -0500]
>
> >> I just reverified. It's definitely returning -1 with EAGAIN.
> >
> >That indicates the device is connected and the URB is still in
> >progress. You can't reap it because it hasn't complete
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2015/02/11 at 10:13 -0500]
>
> >What do you mean by "turned off"? When the device is turned off, does
> >it appear to the host controller that the device has disconnected from
> >the USB bus?
>
> No. This also occurs after
[quoted lines by Alan Stern on 2015/02/11 at 10:54 -0500]
>> I just reverified. It's definitely returning -1 with EAGAIN.
>
>That indicates the device is connected and the URB is still in
>progress. You can't reap it because it hasn't completed. The signal
>you received must have referred to a
On Wed, 11 Feb 2015, Peter Stuge wrote:
> Dave Mielke wrote:
> > [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
> >
> > >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> > >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
> >
> > I just
On Wed, 11 Feb 2015, Dave Mielke wrote:
> [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>
> >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
>
> I just reverified. It's definitely retu
[quoted lines by Alan Stern on 2015/02/11 at 10:13 -0500]
>What do you mean by "turned off"? When the device is turned off, does
>it appear to the host controller that the device has disconnected from
>the USB bus?
No. This also occurs after connecting the device while it's turned off. In this
Dave Mielke wrote:
> [quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>
> >I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
> >return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
>
> I just reverified. It's definitely returning -1 with EAGAIN.
[quoted lines by Peter Stuge on 2015/02/11 at 15:57 +0100]
>I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
>return -1 with errno = ENODEV, or to return 0 with urb->status = ESHUTDOWN.
I just reverified. It's definitely returning -1 with EAGAIN.
>What happens if you ioctl(fd,
On Wed, 11 Feb 2015, Dave Mielke wrote:
> I'd appreciate some advice from anyone here who's familiar with using
> signal-based notification (setting urb->signr) when using usbfs. It's working
> correctly when this particular device is on, as well as when it's
> disconnected,
> but I'm seeing w
Dave Mielke wrote:
> Under what circumstances should usbfs code, after having received a signal,
> expect to not be able to reap a URB, and how should it interpret this
> situation?
I would expect ioctl(fd, IOCTL_USBFS_REAPURBNDELAY, &urb) to either
return -1 with errno = ENODEV, or to return 0
33 matches
Mail list logo
