Hi All,
I'm happy to announce the libusb-1.0.19 final release.
The big feature of this release is support for bulk-streams on
Mac OS X and Linux (using the new usbfs API for this from 3.15).
Changelog:
* Add support for USB bulk streams on Linux and Mac OS X (#11)
* Windows: Add AMD and Intel US
Hi All,
I'm happy to announce the libusb-1.0.19-rc2 release.
The big feature of this release is support for bulk-streams on
Mac OS X and Linux (using the new usbfs API for this from 3.15).
Changelog:
* Add support for USB bulk streams on Linux and Mac OS X (#11)
* Windows: Add AMD and Intel USB-
Hi All,
I'm happy to announce the libusb-1.0.19-rc1 release.
The big feature of this release is support for bulk-streams on
Mac OS X and Linux (using the new usbfs API for this from 3.15).
Changelog:
* Add support for USB bulk streams on Linux and Mac OS X (#11)
* Windows: Add AMD and Intel USB-
Hi,
Thanks for the translation, and sorry for being slow to apply it.
It has been added to our git tree now and will be available in the
upcoming libusb-1.0.19-rc1 release.
Regards,
Hans
--
"Accelerate Dev Cycles with
This is fixed in the libusb v1.0.19-rc1 tag, closing.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/144#issuecomment-43475617--
"Accelerate Dev Cycles with Automated Cross
Closed #144.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/144#event-122357503--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your
path will detect and
report this.
Signed-off-by: Hans de Goede
---
libusb/os/linux_usbfs.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index d654741..2110539 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb
rom 18d6da51580f8910223833815c3f8b1bef8d32bf Mon Sep 17 00:00:00 2001
From: Hans de Goede
Date: Tue, 11 Mar 2014 18:43:13 +0100
Subject: [PATCH] linux_usbfs: Treat EINVAL as ENOTTY in cases where we may get
ENOTTY
Older 64 bit kernels will return EINVAL to 32 bits userspace for unknown
ioctls. So in
Hi Chris,
Thanks for the detailed bug report, and sorry for the slow reply.
On 12/01/2013 08:56 AM, Chris Dickens wrote:
> Hi,
>
> I recently had the need to compile a 32-bit version of the libusbx library
> (v1.0.17) on a 64-bit RHEL 6.5 system (Linux Kernel v2.6.32). What I found
> was that li
Hi Erik,
On 01/21/2014 10:42 AM, Erik Rull wrote:
> Hi all,
>
> getting a tpriv->urbs NULL pointer causes negative urb_idx and successively an
> undefined behavior! This happens when removing a USB device during a transfer
> with a chance of ~ 20%.
Thanks for looking into this, the big question
Closed #167.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/167--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLi
as discussed to dead in issue #76 the problem you're seeing and trying
to fix is caused by a bad pointer *somewhere* as the EFAULT clearly indicated.
Strong NACK from me. For the last time stop trying to propagate the EFAULT, do
your homework and debug the cause of the EFAULT and fix that, than
Closed #76.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/76--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLi
An EFAULT error indicates we've have bad pointers and are writing / reading
random memory at that point all bets are off. If you can show me a real-world
example where we get another error then EFAULT and go into an infinite loop,
then I'm interested in fixing that. For the EFAULT problem you ne
miguelfreitas, please stop trying to somehow propagate the EFAULT and recover
from it. Something is causing bad pointers and/or memory corruption, once that
happens any predictable behavior is off the table.
I will only accept a patch for this if it turns out the bad pointers are caused
by a li
urb->actual_length is guaranteed by the kernel usb-core and hcd code to never
be longer then urb->transfer_buffer_length.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/76#issuecomment-31744650-
. listen the EFAULT error is being thrown by this bit of code inside
libusb:
static int reap_for_handle(struct libusb_device_handle *handle)
{
struct usbfs_urb *urb;
int r = ioctl(hpriv->fd, IOCTL_USBFS_REAPURBNDELAY, &urb);
if (r < 0) {
Notice how the only address we'r
errno == 14 means EFAULT, which means an invalid memory address was passed to
the kernel for the return buffer for the REAP ioctl. I'm not surprised that you
can induce this error with enough EMI noise, but this is not a libusb bug, this
simply means you're flipping bits in your host memory and/
Hi,
On 12/19/2013 10:51 AM, Erik Rull wrote:
> Hi all,
>
> I read already some threads here in the list about the "hot disconnect" and
> the issues that happen.
>
> I'm using the libusbx 1.0.17 and encounter the following stacktrace when
> removing a usb device during a transfer - the timeout is s
"the isoc endpoint is only created when changing to alt setting 1"
Ah, that is what saves your bacon then, most devices have the isoc eps in
altsetting 0 too, with a maxpacketsize of 0.
Besides me no one else seems to be complaining, I guess most people don't use
isoc with libusb.
Anyways as s
Josh, you're correct in that this is a long standing issue. Although I would
not call it architectural, it is simply an API issue (the user should be able
to specify the altsetting he wants the max-packet-size for).
As for this blocking this patch, no the patch can go in as is, but I was hoping
Thanks for working on this. However in my experience the whole
libusb_get_max_iso_packet_size API is rather useless as it takes the endpoint
descriptor from the first altsetting of an interface rather then the current
alt setting.
We could fix things to make it use the current altsetting, but w
Closed #150 via 15ee9598454f0c3b6221f45d36c38fb474af74df.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/150--
Shape the Mobile Experience: Free Subscription
Software exper
s have been reviewed by the Mac OS X port maintainer, and
he also has patches ready to add bulk-stream support for Mac OS X.
> On Wed, Oct 09, 2013 at 05:19:31PM +0200, Hans de Goede wrote:
>> Signed-off-by: Hans de Goede
>
> You need a commit message here, so we can tell usbfs users
Thanks for the bug report. I've just posted 2 patches to the list which fix
this leak:
http://www.mail-archive.com/libusbx-devel@lists.sourceforge.net/msg03403.html
http://www.mail-archive.com/libusbx-devel@lists.sourceforge.net/msg03401.html
---
Reply to this email directly or view it on GitHu
Before this patch if ie multiple hot-plug events were pending, multiple
handle_events calls would be necessary to handle them all, this patch
changes handle_events so that the poll is re-done to check for more events
if there was activity on any of the special fds.
Signed-off-by: Hans de Goede
Closes #150
Signed-off-by: Hans de Goede
---
libusb/core.c | 14 ++
libusb/version_nano.h | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/libusb/core.c b/libusb/core.c
index ea6adcb..b472e89 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -1969,6
libusb_exit sets usbi_default_context to NULL, modify usbi_log_v so that
it still honors the LIBUSB_DEBUG environment variable in this case.
Signed-off-by: Hans de Goede
---
libusb/core.c | 21 ++---
libusb/version_nano.h | 2 +-
2 files changed, 15 insertions(+), 8
Hi all,
Ignore please (v2 coming up).
Note to self: First test, then do git send-email, not the other way around.
Regards,
Hans
On 10/15/2013 03:34 PM, Hans de Goede wrote:
> Before this patch if ie multiple hot-plug events were pending, multiple
> handle_events calls would be necess
Before this patch if ie multiple hot-plug events were pending, multiple
handle_events calls would be necessary to handle them all, this patch
changes handle_events so that the poll is re-done to check for more events
if there was activity on any of the special fds.
Signed-off-by: Hans de Goede
Closes #150
Signed-off-by: Hans de Goede
---
libusb/core.c | 14 ++
libusb/version_nano.h | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/libusb/core.c b/libusb/core.c
index ea6adcb..b472e89 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -1969,6
Signed-off-by: Hans de Goede
---
libusb/core.c | 62 +
libusb/libusb.h | 5
libusb/libusbi.h| 8 +++
libusb/os/linux_usbfs.c | 53 ++
libusb/os/linux_usbfs.h | 8
Hi All,
After a lot of work on this, in the end mostly on the Linux kernel to iron
out some xhci controller driver bugs wrt to streams (*), I'm happy to report
that I now have streams working reliable. So I intend to push these 2 patches
to master as soon as the relevant kernel bits land upstream.
()
though, and will never know the difference.
Signed-off-by: Hans de Goede
---
libusb/io.c | 37 +
libusb/libusb.h | 39 +--
libusb/libusbi.h| 1 +
libusb/os/linux_usbfs.c | 25
Hi,
On 09/22/2013 09:17 PM, Igor Furlan wrote:
> On Sun, Sep 22, 2013 at 2:37 AM, Hans de Goede wrote:
>> Not really a trick or a workaround, you just need to make sure
>> that your application properly closes any devices it has opened
>> before exiting.
>>
>> R
Hi,
On 09/22/2013 10:14 AM, Igor Furlan wrote:
> Hi
>
> Recently I've ordered (and received) two USB based I2C/SPI interfaces
> from NANO River Technology http://nanorivertech.com/viperboard.html.
> This board is very useful for the LAB work during the evaluation and
> debugging of the, so called
Hi,
On 09/13/2013 09:04 PM, Nathan Hjelm wrote:
> One more thing about the API. It might be good to change:
>
> uint32_t API_EXPORTED libusb_transfer_get_stream_id (struct libusb_transfer
> *transfer);
>
> to:
>
> int API_EXPORTED libusb_transfer_get_stream_id (struct libusb_transfer
> *transfer
Hi,
On 09/15/2013 04:27 AM, Xiaofan Chen wrote:
> On Fri, Sep 6, 2013 at 10:52 PM, Hans de Goede wrote:
>> Signed-off-by: Hans de Goede
>> ---
>> libusb/core.c | 2 +-
>> libusb/libusbi.h| 4 ++--
>> libusb/os/darwin_usb.c | 6 +-
Hi,
On 09/13/2013 02:35 PM, Nathan Hjelm wrote:
>
> On Sep 13, 2013, at 3:18 AM, Hans de Goede wrote:
>> 2) The alloc_streams backend op should not fail when the user requests more
>> streams
>> then available, instead it should simply allocate the number
Hi,
On 09/12/2013 11:12 PM, Nathan Hjelm wrote:
>
> On Sep 12, 2013, at 6:35 AM, Hans de Goede wrote:
>
>> Hi,
>>
>> On 09/11/2013 11:04 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 09/11/2013 04:10 PM, Nathan Hjelm wrote:
>>>>
>
Hi,
On 09/11/2013 11:04 PM, Hans de Goede wrote:
> Hi,
>
> On 09/11/2013 04:10 PM, Nathan Hjelm wrote:
>>
>> On Sep 11, 2013, at 7:15 AM, Nathan Hjelm wrote:
>>
>>> One question. Would it make sense to add an additional transfer type for
>>> stream t
Hi,
On 09/11/2013 04:10 PM, Nathan Hjelm wrote:
>
> On Sep 11, 2013, at 7:15 AM, Nathan Hjelm wrote:
>
>> One question. Would it make sense to add an additional transfer type for
>> stream transfers? The stream_id field is not set to 0 by
>> libusb_fill_bulk_transfer so I can not reliably tell
ld
be, so having it implemented on another platform would be very good.
Regards,
Hans
>
> -Nathan
>
> On Sep 11, 2013, at 5:53 AM, Hans de Goede wrote:
>
>> Hi All,
>>
>> These 2 patches add support to the libusb API and Linux backend for USB-3
>> bulk stre
Signed-off-by: Hans de Goede
---
libusb/core.c | 62 +
libusb/libusb.h | 5
libusb/libusbi.h| 8 +++
libusb/os/linux_usbfs.c | 47 +
libusb/os/linux_usbfs.h | 8
Hi All,
These 2 patches add support to the libusb API and Linux backend for USB-3
bulk streams. The Linux backend code uses a new usbfs API for this which
I've proposed upstream, and which has received favorable review upstream.
Like the Linux kernel patches, these patches are only RFC for now, s
for stream ids without breaking ABI. So this is another
item to fix when we do break ABI in libusb-2.0.
Most users will likely use the new libusb_fill_bulk_stream_transfer()
though, and will never know the difference.
Signed-off-by: Hans de Goede
---
libusb/io.c | 37
Hi,
On 09/06/2013 04:58 PM, Nathan Hjelm wrote:
>
> On Sep 6, 2013, at 4:58 AM, Hans de Goede wrote:
>
>> Hi,
>>
>> On 09/05/2013 03:14 AM, Xiaofan Chen wrote:
>>> On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede wrote:
>>>> Hi,
>&g
discovered_devs_append takes a reference to the past in dev, so we must
release our own reference.
Signed-off-by: Hans de Goede
---
libusb/os/openbsd_usb.c | 5 -
libusb/version_nano.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libusb/os/openbsd_usb.c b/libusb
Hi All,
As discussed here is a patch making usbi_get_device_by_session_id return a ref
to the found device, which considering the usb_devs locking seems to be the
sane thing to do. For some backends this also leads to simpler code.
Most of the changes are pretty straight forward, only the windows
If usbi_sanitize_device fails we need to continue from the beginning of
the loop, rather then going on with the device we've just free-ed.
Signed-off-by: Hans de Goede
---
libusb/os/openbsd_usb.c | 4 +++-
libusb/version_nano.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
Signed-off-by: Hans de Goede
---
libusb/core.c | 2 +-
libusb/libusbi.h| 4 ++--
libusb/os/darwin_usb.c | 6 +-
libusb/os/linux_usbfs.c | 5 -
libusb/os/netbsd_usb.c | 4 +---
libusb/os/openbsd_usb.c | 4 +---
libusb/os/wince_usb.c | 1 -
libusb/os
Hi,
On 09/05/2013 03:14 AM, Xiaofan Chen wrote:
> On Thu, Sep 5, 2013 at 3:26 AM, Hans de Goede wrote:
>> Hi,
>>
>> As discussed in much detail here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1003193
>>
>> Calling libusb_exit from atexit from libusb-co
Hi All,
I'm very happy to announce libusbx-1.0.17.
2013-09-06: v1.0.17
* Hotplug callbacks now always get passed a libusb_context, even if it is
the default context. Previously NULL would be passed for the default context,
but since the first context created is the default context, and most
1.0.17 has been tagged and uploaded, the release announcement will go out
shortly, closing.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/126#issuecomment-23931026
--
Lea
Closed #126.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/126
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master cu
Hi,
As discussed in much detail here:
https://bugzilla.redhat.com/show_bug.cgi?id=1003193
Calling libusb_exit from atexit from libusb-compat-0.1.5 causes
some apps to break.
The app in question is the scanimage app from sane-backends, which
uses atexit for cleanup itself.
So what happens is the
Hi All,
Currently we have 4 patches on top of 1.0.17-rc1 in master,
2 documentation updates, and 2 additions to EXTRA_DIST in
Makefile.am. Since there patches are all quite safe, I plan
to release 1.0.17 *final* coming Thursday.
If you see any reasons not to do so, please let me know
ASAP, and pl
Hi,
On 08/30/2013 03:35 PM, Xiaofan Chen wrote:
> On Fri, Aug 30, 2013 at 8:47 PM, Xiaofan Chen wrote:
>> On Fri, Aug 30, 2013 at 4:14 PM, Xiaofan Chen wrote:
>>> On Wed, Aug 28, 2013 at 5:35 PM, Hans de Goede wrote:
>>>> I'm very happy to announce li
Hi,
On 08/30/2013 04:31 PM, Sean McBride wrote:
> On Wed, 28 Aug 2013 11:35:33 +0200, Hans de Goede said:
>
>> You can download the 1.0.17-rc1 tarbal here:
>> http://downloads.sourceforge.net/libusbx/libusbx-1.0.17-rc1.tar.bz2
>>
>> Please give it a thorough test
Hi,
On 08/30/2013 02:30 PM, Toby Gray wrote:
> On 28/08/13 10:35, Hans de Goede wrote:
>> Hi All,
>>
>> I'm very happy to announce libusbx-1.0.17-rc1.
>>
>> 2013-08-28: v1.0.17-rc1
>> * Hotplug callbacks now always get passed a libusb_context, even if
Hi All,
I'm very happy to announce libusbx-1.0.17-rc1.
2013-08-28: v1.0.17-rc1
* Hotplug callbacks now always get passed a libusb_context, even if it is
the default context. Previously NULL would be passed for the default context,
but since the first context created is the default context,
Closed #122.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/122
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master curr
fingolfin, I think you misunderstand how ELF shared library versioning works
under at least Linux, you can either bump the LIBTOOL version macros claiming
to be backward compatible, at which point the filename would change from the
current libusb-1.0.so.0.1.0 to ie libusb-1.0.so.0.2.0, but the s
Closed #127.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/127
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master cu
IMHO we should not be making our configure script more complicated to handle
corner cases like this. Fedora used to have libusb in /lib with the headers in
/usr/include without needing special configure support for this. Packagers
which want this can simply move some files around after make inst
Hi,
On 08/26/2013 01:32 PM, Martin Pieuchot wrote:
> On 24/08/13(Sat) 12:01, Hans de Goede wrote:
>> After adding your openbsd backend improvements patch, libusb
>> no longer builds on released openbsd versions, see below,
>
> Indeed these ioctls were added just after 5.3
Hi,
On 08/25/2013 04:13 AM, Xiaofan Chen wrote:
> On Fri, Aug 23, 2013 at 9:36 PM, Xiaofan Chen wrote:
>>> As per OpenBSD changelog, USB_DEVICE_GET_DDESC,
>>> USB_DEVICE_GET_FDESC and USB_DEVICE_GET_FDESC
>>> are new IOCTLs added to OpenBSD-Current beyong the current
>>> stable 5.3 release.
>>
>>
en wrote:
>>> On Thu, Aug 22, 2013 at 10:50 PM, Hans de Goede wrote:
>>>> On 08/22/2013 03:30 AM, Xiaofan Chen wrote:
>>>>> For OpenBSD and NetBSD, I can carry out some simple tests
>>>>> over the weekend (basic building, stress test and xusb exa
Hi,
On 08/22/2013 03:30 AM, Xiaofan Chen wrote:
> On Wed, Aug 21, 2013 at 10:48 PM, Hans de Goede wrote:
>>> then I'll give people
>>> until Thursday evening to test things from git-master and I'll
>>> release 1.0.17-rc1 on Friday.
>>
>> Gi
Hi All,
While looking at various locking things in libusb I noticed that
usbi_get_device_by_session_id iterates over usb_devs while holding
the usb_devs_lock and then if it finds a device returns that device,
without taking a reference. This means that potentially the device
could get free-ed befo
Hi,
On 08/19/2013 02:23 PM, Toby Gray wrote:
> On 12/08/13 13:20, Xiaofan Chen wrote:
>> On Mon, Aug 12, 2013 at 8:08 PM, Toby Gray wrote:
>>> I assume it'd be helpful for others to have this information recorded
>>> somewhere. Would a wiki page or an update to the README be
>>> more appropriate?
Hi,
On 07/01/2013 07:07 PM, Paul Fertser wrote:
>> Since you're actually getting the warnings can you provide a patch to silence
>> them ?
>
> Follows (against the current libusbx HEAD, but should be applicable to
> libusb as well), TIA
Thanks, I've just merged this patch and pushed it to mast
Hi,
On 06/27/2013 06:22 PM, Chris Dickens wrote:
> Hi,
>
>
> On Thu, Jun 27, 2013 at 3:31 AM, Hans de Goede <mailto:hdego...@redhat.com>> wrote:
>
> Hi,
>
> +/* device will still be marked as attached if hotplug monitor thread
>
Hi all,
On 08/19/2013 05:34 PM, Hans de Goede wrote:
> Hi All,
>
> I was hoping someone else would take care of this while I was otherwise
> occupied, but alas ...
>
> It also seems we've accumulated a little bit more then I was hoping for
> when I suggested to do a qu
Hi All,
I was hoping someone else would take care of this while I was otherwise
occupied, but alas ...
It also seems we've accumulated a little bit more then I was hoping for
when I suggested to do a quick bugfix release a while back, again alas ...
Since we've accumulated quite a bit already, i
Hi,
On 08/16/2013 05:34 AM, Xiaofan Chen wrote:
> On Wed, Aug 14, 2013 at 10:05 PM, Hans de Goede wrote:
>> From: Daniel Berrange
>>
>> Since libusb-0.1 did not have any init / exit function, code using the
>> libusb-0.1 API will not call libusb_exit.
>
>
There simply is no guarantee that lsusb's output order is somehow stable. If it
was for you sofar you've been lucky. Even without the hotplug changes it may
change depending on kernel enumeration order (which is racy since the kernel
does parallel probing of different busses.
---
Reply to this
Closed #131.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/131
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed
PI of libusb.
If, however, we link libusb.so using -znodelete, we will prevent it from
ever being unloaded, despite the dlclose() calls. This is not ideal, but
better than allowing it to be unloaded which is a guaranteed crash.
Signed-off-by: Hans de Goede
---
libusb/Makefile.am | 2 +-
1 file ch
Hi,
On 08/03/2013 07:42 PM, Pete Batard wrote:
> On 2013.08.03 16:41, Hans de Goede wrote:
>> Really doing any IO at all on enumeration is a big no no.
>
> The proposal is simply about duplicating the IO we expect the OS to
> perform naturally,
I believe the discussion be
Hi,
On 08/04/2013 03:08 AM, Pete Batard wrote:
> On 2013.08.04 00:51, Alan Stern wrote:
>> Out of curiosity, what data do you need to request from the parent hub?
>
> Now that I've looked a bit through old e-mails, it seems that these are
> config descriptors, coming from a Windows
> IOCTL_USB_GET
Hi,
I know this discussion was a while ago, but I left this mail to respond
to once I have time, and I've (some) time now ...
On 05/29/2013 04:10 AM, Pete Batard wrote:
> On 2013.05.28 23:08, Tim Roberts wrote:
>> Hans de Goede wrote:
>>> I would like to give libusb u
Hi,
On 08/02/2013 10:23 AM, Martin Pieuchot wrote:
> On 02/08/13(Fri) 10:07, Hans de Goede wrote:
>> Hi Martin,
>>
>> Thanks for your reply!
>>
>> On 08/02/2013 09:28 AM, Martin Pieuchot wrote:
>>> On 02/08/13(Fri) 13:23, Xiaofan Chen wrote:
>>&g
Hi,
On 08/02/2013 10:51 AM, Ludovic Rousseau wrote:
> Hello,
>
> I have not seen a discussion about this patch.
> I think it is correct and should be applied.
>
> Comments?
I agree it is correct and should be pushed, so please go-ahead and push this
as well as Sean's patch discussed earlier today
Hi Martin,
Thanks for your reply!
On 08/02/2013 09:28 AM, Martin Pieuchot wrote:
> On 02/08/13(Fri) 13:23, Xiaofan Chen wrote:
>> On Tue, Jul 30, 2013 at 11:38 PM, Hans de Goede wrote:
>>> Hi Martin,
>>>
>>> On 07/16/2013 11:32 AM, Martin Pieu
Hi,
On 08/02/2013 07:17 AM, Xiaofan Chen wrote:
> On Wed, Jul 10, 2013 at 9:28 AM, Xiaofan Chen wrote:
>> On Thu, Jul 4, 2013 at 5:14 PM, Xiaofan Chen wrote:
>>> On Wed, Jul 3, 2013 at 3:29 AM, Sean McBride
>>> wrote:
On Tue, 2 Jul 2013 23:18:12 +0400, Paul Fertser said:
> What about
Hi,
On 07/31/2013 03:11 AM, Xiaofan Chen wrote:
> On Wed, Jul 31, 2013 at 5:25 AM, Pete Batard wrote:
>> On 2013.07.30 20:24, Nathan Hjelm wrote:
>>> I will keep this
>>> branch in sync with the master. When do we want to make the official
>>> switch? 1.0.18?
>>
>> There will be some more Windows
Hi,
I see that Nathan and I both have been working on closing various
bugs so that we can do a 1.0.17 bug-fix release. Nathan beat me
wrt pushing his changes by mere seconds, which meant I had to do
a rebase (GRMBL :)
So with the deadlock on exit fixed + Nathan's fixes, I think we
are in good sha
Hi Martin,
On 07/16/2013 11:32 AM, Martin Pieuchot wrote:
> Hello Hans and Pete,
>
> You'll find below an update for OpenBSD's libusb backend, freshly
> rebased on top of the last libusb/libusbx release.
>
> I sent it twice to Peter Stuge but it never get committed after we
> addressed all the iss
Hi,
On 07/20/2013 10:07 PM, Chris Dickens wrote:
> Hi,
>
> This patch does indeed fix the deadlock condition on libusb_exit(), but
> unfortunately it opens up another opportunity for deadlock :(
>
> If the hotplug event thread is processing a hotplug event when it is
> cancelled, there is a chan
This seems like a distro problem to me, not a libusb one. We don't support
building libusb-1.0.16 (and newer) without hotplug support on Linux. And I
don't think we should, it will make the code more complicated, and more over it
will make life much harder for app developers. App developers who
Closed #124.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/124
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with applicati
Hi,
On 07/19/2013 11:06 AM, Hans de Goede wrote:
> Hi All,
>
> I had some inspiration this morning how to fix the deadlock Chris Dickens
> found as a result of the bugreport I forwarded.
>
> So here is a fix for it. I've asked the bug-reporter to test, see:
> h
To ensure that it is stopped before we continue (and if later libusb
gets re-initialized start another thread).
Signed-off-by: Hans de Goede
---
libusb/os/linux_netlink.c | 1 +
libusb/version_nano.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/libusb/os
locks for this should fix this deadlock, which has been
reported here: https://bugzilla.redhat.com/show_bug.cgi?id=985484
Many thanks to Chris Dickens for figuring out the cause of this deadlock!
CC: Chris Dickens
Signed-off-by: Hans de Goede
---
libusb/os/linux_netlink.c | 5 -
libusb/os
Hi All,
I had some inspiration this morning how to fix the deadlock Chris Dickens
found as a result of the bugreport I forwarded.
So here is a fix for it. I've asked the bug-reporter to test, see:
https://bugzilla.redhat.com/show_bug.cgi?id=985484
While writing this, I noticed that the netlink c
Hi All,
I'll be away on vacation Jul 18 - 26 (and not reading email),
and I'll be at Guadec Jul 31 - Aug 7 (and sporadically reading
my email).
So if you're trying to reach me and I'm not responding immediately,
that is why. I'll catch up with email, bugs, etc. when I return.
Regards,
Hans
---
Hi,
On 07/17/2013 09:25 PM, Chris Dickens wrote:
> Hi,
>
> I have identified the problem. When libusb_exit() is called, the linux
> backend will acquire the linux_hotplug_lock before calling
> linux_stop_event_monitor(). In this user's particular case, it looks like the
> event monitor thread i
Hi all,
I'm going on vacation for a week starting tomorrow so I don't have time to
look into this myself atm. If anyone has any clues / ideas as to what is going
on here, you're insight is appreciated.
Regards,
Hans
Original Message
Subject: [Bug 985484] New: Deadlock in linu
Hi,
On 07/12/2013 12:15 AM, Pete Batard wrote:
> freecode has now been updated (but each new entry gets reviewed by the
> freecode people before it is published, so it may be a few hours before it
> gets publicized) along with the index page on http://libusbx.org (there is a
> link to the lates
1 - 100 of 355 matches
Mail list logo
