Re: [Libusbx-devel] [libusbx] fails to include needed symbols; not suitable replacement for libusb
Am 03.07.2012 08:49, schrieb Ludovic Rousseau: > Why is the lib called libusb.a and not libusb-1.0.a? > > My hypothesis is that libusb.a comes from libusb-compat and is not > (statically) linked with libusb (or libusbx). So of course all the > libusb-1.0 symbols are missing. > Can you check that? Correct, does that mean i need to rebuild libusb-compat against libusbx? > > Another good idea is to NOT distribute a static lib. Only the dynamic > .so should be provided. But that is not the problem. I already disabled static lib in libusbx. Thanks for your help, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] fails to include needed symbols; not suitable replacement for libusb
2012/7/3 Tobias Powalowski : > Am 03.07.2012 08:49, schrieb Ludovic Rousseau: >> Why is the lib called libusb.a and not libusb-1.0.a? >> >> My hypothesis is that libusb.a comes from libusb-compat and is not >> (statically) linked with libusb (or libusbx). So of course all the >> libusb-1.0 symbols are missing. >> Can you check that? > Correct, does that mean i need to rebuild libusb-compat against libusbx? Your dynamic libusb-compat lib (libusb.so) should be linked with libusb-1.0. Check with ldd(1). Is that the case? And the libusb.so lib should not have any missing symbol. Check with "ldd -r" Is that also the case? >> Another good idea is to NOT distribute a static lib. Only the dynamic >> .so should be provided. But that is not the problem. > I already disabled static lib in libusbx. So you can't build a libusb-compat static lib without a libusb(x) 1.0 static version. Disable static lib for libusb-compat as well. Bye -- Dr. Ludovic Rousseau -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
Hi,
On 07/03/2012 12:43 AM, Pete Batard wrote:
> As per the roadmap. This is something I realized right after 1.0.12, as
> LOG_LEVEL_XYZ is lilely to be generic enoug to conflict with other apps and
> headers that may define those as well.
>
> This is also in part the source of Trac #31, which is an issue with
> libusb-compat, as libusb-compat's core.c does redefine the LOG_LEVEL_XYZ
> enums.
Next time please send patches inline, that makes replying to them for a review
a lot easier.
###
- * - LOG_LEVEL_DEBUG (4) : debug and informational messages are printed to
stdout,
+ * - LIBUSB_LOG_LEVEL_DEBUG (4) : debug and informational messages are
printed to stdout,
*warnings and errors to stderr
*/
enum usbi_log_level {
- LOG_LEVEL_NONE = 0,
- LOG_LEVEL_ERROR,
- LOG_LEVEL_WARNING,
- LOG_LEVEL_INFO,
- LOG_LEVEL_DEBUG,
+ LIBUSB_LOG_LEVEL_NONE = 0,
+ LIBUSB_LOG_LEVEL_ERROR,
+ LIBUSB_LOG_LEVEL_WARNING,
+ LIBUSB_LOG_LEVEL_INFO,
+ LIBUSB_LOG_LEVEL_DEBUG,
};
int LIBUSB_CALL libusb_init(libusb_context **ctx);
###
Please also rename the enum type name, usbi indicates it is a libusb internal
thing,
I suggest using libusb_log_level instead.
Regards,
Hans
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [libusbx] fails to include needed symbols; not suitable replacement for libusb
Am 03.07.2012 09:26, schrieb Ludovic Rousseau: > 2012/7/3 Tobias Powalowski : >> Am 03.07.2012 08:49, schrieb Ludovic Rousseau: >>> Why is the lib called libusb.a and not libusb-1.0.a? >>> >>> My hypothesis is that libusb.a comes from libusb-compat and is not >>> (statically) linked with libusb (or libusbx). So of course all the >>> libusb-1.0 symbols are missing. >>> Can you check that? >> Correct, does that mean i need to rebuild libusb-compat against libusbx? > Your dynamic libusb-compat lib (libusb.so) should be linked with > libusb-1.0. Check with ldd(1). > Is that the case? linux-vdso.so.1 => (0x7fff38ad2000) libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x7f3a82161000) libc.so.6 => /lib/libc.so.6 (0x7f3a81dc) librt.so.1 => /lib/librt.so.1 (0x7f3a81bb7000) libpthread.so.0 => /lib/libpthread.so.0 (0x7f3a8199b000) /lib/ld-linux-x86-64.so.2 (0x7f3a825a2000) > And the libusb.so lib should not have any missing symbol. Check with "ldd -r" > Is that also the case? ldd -r /usr/lib/libusb.so linux-vdso.so.1 => (0x7fff3a1ff000) libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x7f549794e000) libc.so.6 => /lib/libc.so.6 (0x7f54975ad000) librt.so.1 => /lib/librt.so.1 (0x7f54973a4000) libpthread.so.0 => /lib/libpthread.so.0 (0x7f5497188000) /lib/ld-linux-x86-64.so.2 (0x7f5497d8f000) >>> Another good idea is to NOT distribute a static lib. Only the dynamic >>> .so should be provided. But that is not the problem. >> I already disabled static lib in libusbx. > So you can't build a libusb-compat static lib without a libusb(x) 1.0 > static version. > Disable static lib for libusb-compat as well. > Thanks will also disable it. Looks like all is ok and i only need to remove the static libusb-compat file. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
Now libusb-compat errors with this during compile: core.c:35:6: error: nested redefinition of 'enum usbi_log_level' core.c:35:6: error: redeclaration of 'enum usbi_log_level' In file included from core.c:27:0: /usr/include/libusb-1.0/libusb.h:962:6: note: originally defined here make[2]: *** [libusb_la-core.lo] Fehler 1 make[2]: Leaving directory `/home/tobias/Arch/svn/svn-packages/libusb-compat/trunk/src/libusb-compat-0.1.4/libusb' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/tobias/Arch/svn/svn-packages/libusb-compat/trunk/src/libusb-compat-0.1.4' make: *** [all] Fehler 2 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On 2012.07.03 09:27, Tobias Powalowski wrote: > Now libusb-compat errors with this during compile: > core.c:35:6: error: nested redefinition of 'enum usbi_log_level' > core.c:35:6: error: redeclaration of 'enum usbi_log_level' > In file included from core.c:27:0: This is a known issue. Please apply the patch from: http://libusb.org/ticket/138. Note that the patch is very simple, as per http://libusb.org/attachment/ticket/138/libusb-0.1-libusbx.patch, so you can also just edit libusb-compat's core.c and remove the enum usbi_log_level manually. Alternatively, once we have applied the other patch that is referenced in this thread to libusbx, you should be able to use it with libusb-compat without having to patch libusb-compat. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On 2012.07.03 08:33, Hans de Goede wrote: > Next time please send patches inline, that makes replying to them for a > review a lot easier. This is getting old. The thing is, Segher complained once, so I went inline, then Xiaofan complained about the extra '>' character, so I reverted back to non inline. Note that I also recently had to reinstall Thunderbird (along with Windows...), so it's possible some of the defaults for patch attachments have been reset. Were you OK with the patches I sent a week ago and earlier? Also, since we're talking about attachments and inline, I find that the git e-mail patch format, which is what you sent your RFC patches into, makes it harder to identify patches as far as I'm concerned. I would very much prefer patches to be sent as actual attachments (preferably attached-inline, if that's what people prefer) as it makes it a lot easier, as a maintainer, to try to make sure one of them isn't falling through. For now I guess I'll revert back to attached inline, even though this'll probably inconvenience Xiaofan again... > Please also rename the enum type name, usbi indicates it is a libusb > internal thing, > I suggest using libusb_log_level instead. Good point, will do just that. Also, I just noticed that libusb-compat uses a log level ordering that is the reverse of libusb/libusbx (their _DEBUG is 0, libusb(x)'s is 4) which kind of vindicates the idea that you really want your log levels as enums/defines in the public API: even the same project can't manage consistency there. Now, unless libusb-compat uses naked log level numbers, which as far as I can see it does not, this shouldn't be a problem. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
v2, that applies Hans' suggestion.
NB: This patch should be attached as inline
Regards,
/Pete
>From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Mon, 2 Jul 2012 23:39:19 +0100
Subject: [PATCH] Core: Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
* The LOG_LEVEL_ enums, that were moved to the public API
in 933a319469b962031c989e39d9d1f44f2885 may conflict
with applications/headers that also define their own
LOG_LEVEL_ values internally.
* As a matter of fact, as per Trac #31, this produces a
conflict with libusb-compat, as it defines its own levels.
---
examples/xusb.c | 2 +-
libusb/core.c | 28 ++--
libusb/libusb.h | 22 +++---
libusb/libusbi.h | 20 ++--
4 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/examples/xusb.c b/examples/xusb.c
index 0eafd8c..3e8d262 100644
--- a/examples/xusb.c
+++ b/examples/xusb.c
@@ -1021,7 +1021,7 @@ int main(int argc, char** argv)
if (r < 0)
return r;
- libusb_set_debug(NULL, debug_mode?LOG_LEVEL_DEBUG:LOG_LEVEL_INFO);
+ libusb_set_debug(NULL,
debug_mode?LIBUSB_LOG_LEVEL_DEBUG:LIBUSB_LOG_LEVEL_INFO);
test_device(VID, PID);
diff --git a/libusb/core.c b/libusb/core.c
index 8845909..e10d808 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -1567,11 +1567,11 @@ int API_EXPORTED
libusb_attach_kernel_driver(libusb_device_handle *dev,
/** \ingroup lib
* Set log message verbosity.
*
- * The default level is \ref LOG_LEVEL_NONE, which means no messages are ever
+ * The default level is LIBUSB_LOG_LEVEL_NONE, which means no messages are ever
* printed. If you choose to increase the message verbosity level, ensure
* that your application does not close the stdout/stderr file descriptors.
*
- * You are advised to use level \ref LOG_LEVEL_WARNING. libusbx is conservative
+ * You are advised to use level LIBUSB_LOG_LEVEL_WARNING. libusbx is
conservative
* with its message logging and most of the time, will only log messages that
* explain error conditions and other oddities. This will help you debug
* your software.
@@ -1636,7 +1636,7 @@ int API_EXPORTED libusb_init(libusb_context **context)
memset(ctx, 0, sizeof(*ctx));
#ifdef ENABLE_DEBUG_LOGGING
- ctx->debug = LOG_LEVEL_DEBUG;
+ ctx->debug = LIBUSB_LOG_LEVEL_DEBUG;
#endif
dbg = getenv("LIBUSB_DEBUG");
@@ -1793,7 +1793,7 @@ int usbi_gettimeofday(struct timeval *tp, void *tzp)
}
#endif
-void usbi_log_v(struct libusb_context *ctx, enum usbi_log_level level,
+void usbi_log_v(struct libusb_context *ctx, enum libusb_log_level level,
const char *function, const char *format, va_list args)
{
const char *prefix = "";
@@ -1807,14 +1807,14 @@ void usbi_log_v(struct libusb_context *ctx, enum
usbi_log_level level,
USBI_GET_CONTEXT(ctx);
if (ctx == NULL)
return;
- global_debug = (ctx->debug == LOG_LEVEL_DEBUG);
+ global_debug = (ctx->debug == LIBUSB_LOG_LEVEL_DEBUG);
if (!ctx->debug)
return;
- if (level == LOG_LEVEL_WARNING && ctx->debug < LOG_LEVEL_WARNING)
+ if (level == LIBUSB_LOG_LEVEL_WARNING && ctx->debug <
LIBUSB_LOG_LEVEL_WARNING)
return;
- if (level == LOG_LEVEL_INFO && ctx->debug < LOG_LEVEL_INFO)
+ if (level == LIBUSB_LOG_LEVEL_INFO && ctx->debug <
LIBUSB_LOG_LEVEL_INFO)
return;
- if (level == LOG_LEVEL_DEBUG && ctx->debug < LOG_LEVEL_DEBUG)
+ if (level == LIBUSB_LOG_LEVEL_DEBUG && ctx->debug <
LIBUSB_LOG_LEVEL_DEBUG)
return;
#endif
@@ -1832,19 +1832,19 @@ void usbi_log_v(struct libusb_context *ctx, enum
usbi_log_level level,
now.tv_usec -= timestamp_origin.tv_usec;
switch (level) {
- case LOG_LEVEL_INFO:
+ case LIBUSB_LOG_LEVEL_INFO:
prefix = "info";
break;
- case LOG_LEVEL_WARNING:
+ case LIBUSB_LOG_LEVEL_WARNING:
prefix = "warning";
break;
- case LOG_LEVEL_ERROR:
+ case LIBUSB_LOG_LEVEL_ERROR:
prefix = "error";
break;
- case LOG_LEVEL_DEBUG:
+ case LIBUSB_LOG_LEVEL_DEBUG:
prefix = "debug";
break;
- case LOG_LEVEL_NONE:
+ case LIBUSB_LOG_LEVEL_NONE:
break;
default:
prefix = "unknown";
@@ -1863,7 +1863,7 @@ void usbi_log_v(struct libusb_context *ctx, enum
usbi_log_level level,
fprintf(stderr, "\n");
}
-void usbi_log(struct libusb_context *ctx, enum usbi_log_level level,
+void usbi_log(struct libusb_context *ctx, enum libusb_log_level level,
const char *function, const char *format, ...)
{
va_list args;
diff --git a/libusb/libusb.h b/libusb/libusb.h
index fd231ea..1dc12f8 100644
--- a/libusb/libusb.h
+++ b/libusb/libusb.h
@@
Re: [Libusbx-devel] xhci driver fails and corrupt memory
On Mon, 2 Jul 2012 12:28:15 -0700 Sarah Sharp wrote: > On Tue, Jun 26, 2012 at 01:16:46PM +0400, Igor Kuzmin wrote: > > OK, so, with for-usb-linus kernel current results with different > > controllers are: > > NEC - works > > Fresco Logic - fails with "ERROR Transfer event TRB DMA ptr not part of > > current TD" > > Doesn't surprise me. Fresco Logic host controllers are very "quirky". > That message means either there's something wrong with the xHCI ring > structure or the host controller is feeding SW bad data. I'll take a > look at your dmesg and see if I can spot the error. > > > Ivy Bridge - works, but there's another issue: > > usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd > > usb 4-2: skipped 1 descriptor after endpoint > > usb 4-2: skipped 1 descriptor after endpoint > > usb 4-2: skipped 1 descriptor after endpoint > > usb 4-2: skipped 1 descriptor after endpoint > > usb 4-2: default language 0x0409 > > usb 4-2: udev 3, busnum 4, minor = 386 > > usb 4-2: New USB device found, idVendor=20f7, idProduct=3001 > > usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 4-2: Product: XIMEA > > usb 4-2: Manufacturer: XIMEA > > usb 4-2: usb_probe_device > > usb 4-2: configuration #1 chosen from 1 choice > > usb 4-2: Successful Endpoint Configure command > > usb 4-2: Successful evaluate context command > > usb 4-2: Set SEL for device-initiated U1 failed. > > Have you watched with your bus analyzer to see if the Set SEL request > completes? Your USB 3.0 device needs to handle that request, even if it > always NAKs the LGO_U1 and LGO_U2 link commands. > > If you have a Lecroy USB 3.0 analyzer, I also have one, so I could > decode your bus dumps. Sadly I don't have access to USB3 analyzer anymore, but I will try to get bus dump later. > > > usb 4-2: Successful evaluate context command > > usb 4-2: adding 4-2:1.0 (config #1, interface 0) > > hub 4-0:1.0: state 7 ports 4 chg evt 0004 > > hub 4-0:1.0: warm reset change on port 2 > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: xiSample timed out on ep0out len=0/0 > > usb 4-2: Enable of device-initiated U1 failed. > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: Successful evaluate context command > > usb 4-2: xiSample timed out on ep0out len=0/0 > > usb 4-2: Enable of device-initiated U1 failed. > > usb 4-2: Successful evaluate context command > > xhci_hcd :00:14.0: WARN Event TRB for slot 2 ep 2 with no TDs > > queued? > > > > The problem represents itself as hangs for a second or two during > > certain operations. I haven't seen it before, with other kernels. > > The 3.5 kernel added USB 3.0 Link Power Management. It's turned for all > USB 3.0 devices. > > What do you mean by "hang"? As in userspace hangs? khubd hangs? I'm not sure how to spot khubd hangs. It looked like pauses in program execution, most likely spent in synchronous libusb calls. "xiSample timed out on ep0out" message is probably the one describing this "hang". > > Sarah Sharp -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On Tue, Jul 3, 2012 at 5:23 PM, Pete Batard wrote: > On 2012.07.03 08:33, Hans de Goede wrote: >> Next time please send patches inline, that makes replying to them for a >> review a lot easier. > > This is getting old. > > The thing is, Segher complained once, so I went inline, then Xiaofan > complained about the extra '>' character, so I reverted back to non > inline. Note that I also recently had to reinstall Thunderbird (along > with Windows...), so it's possible some of the defaults for patch > attachments have been reset. Were you OK with the patches I sent a week > ago and earlier? > > Also, since we're talking about attachments and inline, I find that the > git e-mail patch format, which is what you sent your RFC patches into, > makes it harder to identify patches as far as I'm concerned. I would > very much prefer patches to be sent as actual attachments (preferably > attached-inline, if that's what people prefer) as it makes it a lot > easier, as a maintainer, to try to make sure one of them isn't falling > through. > > For now I guess I'll revert back to attached inline, even though this'll > probably inconvenience Xiaofan again... Actually what I complained is this one (extra ">" before "From" which is probably caused by the mailing list software. >From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001 The strange thing is that no matter you go inline or with attachment, the extra ">" is still there. I can understand the extra ">" when going inline, but I feel it is very strange that it is still there when you send the patch as an attachment. So it does not help me much since I still need to get rid of the extra ">". The norm of the mailing lists (at least Linux related) seem to be using inline. So probably just stick to that. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On Tue, Jul 3, 2012 at 6:04 PM, Pete Batard wrote: > v2, that applies Hans' suggestion. > > NB: This patch should be attached as inline > Actually it comes to me as both inline and attachment and both are with the extra ">". Kind of strange, either something is wrong with Gmail or something is wrong with your mail client. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On 2012.07.03 13:59, Xiaofan Chen wrote:
>> NB: This patch should be attached as inline
>
> Actually it comes to me as both inline and attachment
Which is exactly what I want.
"Pure" inline is a PITA to work with, because everything's just text and
you never know if there's something of value in there. In case someone
forgot to add "[PATCH]" on the subject line, or used a variation of it
("[FIX]", "Diff:", etc.), there's an increased risk it'll fall through
if not picked up early, which *will* happen. Now, having an identified
attachment makes it a lot easier to avoid that, except for those people
insisting on attaching a .asc for their signatures...
On the other hand, "pure" attachments only seems to be a problem for
people with dumb e-mail clients. For what is worth, at least on Windows,
Thunderbird doesn't have an issue problem displaying and quoting parts
of a text attachment, whether pure attachment or hybrid, as if it was
inline...
> Kind of strange, either something is wrong
> with Gmail or something is wrong with your mail client.
Didn't you send a patch over to libusb-devel recently (the .def
"libusb-1.0.dll" one)? Have you checked whether you had the same issue?
Regards,
/Pete
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On Tue, Jul 3, 2012 at 9:26 PM, Pete Batard wrote:
> On 2012.07.03 13:59, Xiaofan Chen wrote:
>>> NB: This patch should be attached as inline
>>
>> Actually it comes to me as both inline and attachment
>
> Which is exactly what I want.
I see. In that case, no problem.
> "Pure" inline is a PITA to work with, because everything's just text and
> you never know if there's something of value in there. In case someone
> forgot to add "[PATCH]" on the subject line, or used a variation of it
> ("[FIX]", "Diff:", etc.), there's an increased risk it'll fall through
> if not picked up early, which *will* happen. Now, having an identified
> attachment makes it a lot easier to avoid that, except for those people
> insisting on attaching a .asc for their signatures...
>
> On the other hand, "pure" attachments only seems to be a problem for
> people with dumb e-mail clients. For what is worth, at least on Windows,
> Thunderbird doesn't have an issue problem displaying and quoting parts
> of a text attachment, whether pure attachment or hybrid, as if it was
> inline...
>
>> Kind of strange, either something is wrong
>> with Gmail or something is wrong with your mail client.
>
> Didn't you send a patch over to libusb-devel recently (the .def
> "libusb-1.0.dll" one)? Have you checked whether you had the same issue?
I sent the patch both inline and as an attachment using Gmail.
Both are okay from what I see, no extra ">". But maybe you
will see the ">" for the inline version. Did you see the ">" for
my attachment?
--
Xiaofan
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On Tue, 3 Jul 2012, Xiaofan Chen wrote: > Actually what I complained is this one (extra ">" before "From" > which is probably caused by the mailing list software. > >From 7ec94a45ed8155e7a1d4d5d75575099b09c78834 Mon Sep 17 00:00:00 2001 Xiaofan, have you read "The UNIX-HATERS Handbook" by Garfinkel, Weise, and Strassmann? It has a section on the ">From" problem on p.79. The book is very funny and a lot of fun to read. And it's freely available online (search for: unix haters handbook download). Alan Stern -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] libusb segfaults - causes pcscd to crash
Dear maintainer, I encountered an issue using pcsc-lite and libusb on Ubuntu 10.04 LTS. Now and then libusb segfaults and causes pcscd to crash. The error occurred with libusb-1.0-0 (1.0.8), so I updated libusb-1.0-0 and libusb-1.0-0-dev to 1.0.11 (libusbx) a few days ago, hoping the issue was fixed meanwhile. Unfortunately it happened again. I tried to reproduce the failure on my testing environment while pcscd was running in gdb, but I was not able to trigger it. The only output I'm able to provide: [syslog – libusb 1.0.8] kernel: [358812.500109] show_signal_msg: 18 callbacks suppressed kernel: [358812.500124] pcscd[907]: segfault at 8 ip 00fd12f8 sp b6f2b030 error 4 in libusb-1.0.so.0.0.0[fcd000+d000] [syslog – libusbx 1.0.11] kernel: [144649.500131] show_signal_msg: 9 callbacks suppressed kernel: [144649.500144] pcscd[898]: segfault at 8 ip 00fbfac8 sp b6f02030 error 4 in libusb-1.0.so.0.1.0[fbb000+e000] The pcsc-daemon loads at startup by executing the start script /etc/init.d/pcscd. Any help or advice will be appreciated. Thank you very much in advance. - Regards Sebastian = Ubuntu 10.04 LTS Linux 3.0.0-17-generic #30~lucid1-Ubuntu SMP Fri Mar 9 15:10:54 UTC 2012 i686 GNU/Linux pcsc-lite version 1.8.3. Copyright (C) 1999-2002 by David Corcoran . Copyright (C) 2001-2011 by Ludovic Rousseau . Copyright (C) 2003-2004 by Damien Sauveron . Report bugs to . Enabled features: Linux i686-pc-linux-gnu serial usb libusb usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd configdir=/usr/etc/reader.conf.d Package: libusb-1.0-0 Status: install ok installed Section: libs Architecture: i386 Source: libusbx Version: 2:1.0.11-1 Package: libusb-1.0-0-dev Status: install ok installed Architecture: i386 Source: libusbx Version: 2:1.0.11-1 Omnikey 5321 PC/SC driver for OMNIKEY 5x21 and 5x25 (V2.10.0.1 - Release: 02/17/2012 - 301KB - Linux 32Bit) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
Hi Sebastian, On 2012.07.03 15:35, sebasti...@gmx-topmail.de wrote: > I encountered an issue using pcsc-lite and libusb on Ubuntu 10.04 LTS. > Now and then libusb segfaults and causes pcscd to crash. > > The error occurred with libusb-1.0-0 (1.0.8), so I updated libusb-1.0-0 and > libusb-1.0-0-dev to 1.0.11 (libusbx) a few days ago For the record, libusbx 1.0.12 is the latest, and was released a few weeks ago. However, I don't think any of the fixes we applied between 1.0.11 and 1.0.12 should have much impact on your issue, though 1.0.12 does improve the logging facility. Of course, if you are using the standard package distribution media, there will always be some delay between a new libusbx release, and the time it becomes available as a distro package. If needed, you can download the 1.0.12 source tarball from https://sourceforge.net/projects/libusbx/files/latest/download?source=files > hoping the issue was fixed meanwhile. Unfortunately it happened again. > > I tried to reproduce the failure on my testing environment while pcscd was > running in gdb, but I was not able to trigger it. > > The only output I'm able to provide: > [syslog – libusb 1.0.8] > kernel: [358812.500109] show_signal_msg: 18 callbacks suppressed > kernel: [358812.500124] pcscd[907]: segfault at 8 ip 00fd12f8 sp b6f2b030 > error 4 in libusb-1.0.so.0.0.0[fcd000+d000] > > [syslog – libusbx 1.0.11] > kernel: [144649.500131] show_signal_msg: 9 callbacks suppressed > kernel: [144649.500144] pcscd[898]: segfault at 8 ip 00fbfac8 sp b6f02030 > error 4 in libusb-1.0.so.0.1.0[fbb000+e000] > > The pcsc-daemon loads at startup by executing the start script > /etc/init.d/pcscd. This is going to be tough to troubleshoot without data on what is occurring at the time of the crash. One way or another, we're going to need some logging output from libusbx, but of course, depending on how much USB traffic pcscd and how long it needs to run before observing the crash, the volume of logging output might be prohibitive. Provided pcscd will log stderr output from libusbx, that the volume of USB traffic is not too prohibitive, and that you can be alerted and act on a crash in a matter of hours, here's what I would do: * using the 1.0.12 libusbx source tarball, configure libusbx with --enable-debug-log, then compile and install it on your system * provided you use an advanced syslog facility, such as rsyslog rather than the old and limited syslogd, set up a filter to send all the output of pcscd to /var/log/pcscd.log or something. With rsyslog, you would add the following near the top of your rsyslog.conf: :msg, startswith, "pcscd"/var/log/pcscd.log & ~ * setup log rotation of pcscd.log to one hour (have a look at the content of your /etc/logrotate.d for inspiration on how to create an entry for /var/log/pcscd.log). * As soon as you are aware of another crash, hopefully within 4 hours, make sure you create a backup copy of all the rotated pcscd logs for analysis. Then try to locate and send us the part that occurs right before the crash. Now it is possible that even 4 hours worth of debug logs may be too voluminous (there should be a lot of data in there - if you don't see any, then pcscd may be dropping stderr output), or that the result of all this logging has a noticeable impact on performance/access speeds, or that the issue does not occur at all with debug logging turned on. If that's the case, you can try reducing the log level to INFO rather than DEBUG, as it may still help us get some data as to what occurs around the time of the crash. For that, you should remove the --enable-debug-log when compiling libusbx and then, in /etc/init.d/pcscd, set the environmental variable LIBUSB_DEBUG to 3 (by adding "export LIBUSB_DEBUG=3" at the top of your file). Note that we could probably also use this approach to turn debug logging on without having to recompile with --enable-debug-log (provided you are using libusbx 1.0.12 - this won't work with 1.0.11), by setting LIBUSB_DEBUG to 4. However I'm not sure how much a daemon would read into environment variables, which is why using --enable-debug-log is the safer bet. Is that a troubleshooting approach you think you can go with? Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
2012/7/3 : > Dear maintainer, Hello, > I encountered an issue using pcsc-lite and libusb on Ubuntu 10.04 LTS. > Now and then libusb segfaults and causes pcscd to crash. > > The error occurred with libusb-1.0-0 (1.0.8), so I updated libusb-1.0-0 and > libusb-1.0-0-dev to 1.0.11 (libusbx) a few days ago, hoping the issue was > fixed meanwhile. Unfortunately it happened again. > > I tried to reproduce the failure on my testing environment while pcscd was > running in gdb, but I was not able to trigger it. Without a gdb backtrace I can't do much. Do you know how you triggered the crash? > The only output I'm able to provide: > [syslog – libusb 1.0.8] > kernel: [358812.500109] show_signal_msg: 18 callbacks suppressed > kernel: [358812.500124] pcscd[907]: segfault at 8 ip 00fd12f8 sp b6f2b030 > error 4 in libusb-1.0.so.0.0.0[fcd000+d000] > > [syslog – libusbx 1.0.11] > kernel: [144649.500131] show_signal_msg: 9 callbacks suppressed > kernel: [144649.500144] pcscd[898]: segfault at 8 ip 00fbfac8 sp b6f02030 > error 4 in libusb-1.0.so.0.1.0[fbb000+e000] > > The pcsc-daemon loads at startup by executing the start script > /etc/init.d/pcscd. > > > Any help or advice will be appreciated. > > Thank you very much in advance. > > - > Regards > > Sebastian > = > > > Ubuntu 10.04 LTS > Linux 3.0.0-17-generic #30~lucid1-Ubuntu SMP Fri Mar 9 15:10:54 UTC 2012 i686 > GNU/Linux > > pcsc-lite version 1.8.3. > Copyright (C) 1999-2002 by David Corcoran . > Copyright (C) 2001-2011 by Ludovic Rousseau . > Copyright (C) 2003-2004 by Damien Sauveron . > Report bugs to . > Enabled features: Linux i686-pc-linux-gnu serial usb libusb > usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd > configdir=/usr/etc/reader.conf.d > > Package: libusb-1.0-0 > Status: install ok installed > Section: libs > Architecture: i386 > Source: libusbx > Version: 2:1.0.11-1 > > Package: libusb-1.0-0-dev > Status: install ok installed > Architecture: i386 > Source: libusbx > Version: 2:1.0.11-1 > > Omnikey 5321 > PC/SC driver for OMNIKEY 5x21 and 5x25 (V2.10.0.1 - Release: 02/17/2012 - > 301KB - Linux 32Bit) What driver are your using? A (proprietary) driver from Omnikey? Have you tried my CCID driver [1]? Note that you wont be able to use the reader contactless interface. Bye [1] http://pcsclite.alioth.debian.org/ccid.html -- Dr. Ludovic Rousseau -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
2012/7/3 Pete Batard : > Provided pcscd will log stderr output from libusbx, that the volume of > USB traffic is not too prohibitive, and that you can be alerted and act > on a crash in a matter of hours, here's what I would do: > * using the 1.0.12 libusbx source tarball, configure libusbx with > --enable-debug-log, then compile and install it on your system Or run pcscd in debug mode as documented at [1]. Since libusbx is sending to stderr the "| tee log.txt" part will not work as expected. Then use: sudo pcscd --foreground --debug --apdu Note: I am the author of pcsc-lite providing pcscd. [1] http://pcsclite.alioth.debian.org/pcsclite.html#support -- Dr. Ludovic Rousseau -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Prefix LOG_LEVEL_ with LIBUSB_ to avoid conflicts
On 2012.07.03 14:38, Xiaofan Chen wrote: > I sent the patch both inline and as an attachment using Gmail. > Both are okay from what I see, no extra ">". But maybe you > will see the ">" for the inline version. Did you see the ">" for > my attachment? Yup. This is how Thunderbird displays the inline version of your patch on my platform: Here it is. >From 38d5776f728b121ebc0bf9db8da8d745317f55fd Mon Sep 17 00:00:00 2001 From: Xiaofan Chen Date: Sun, 17 Jun 2012 20:46:40 +0800 Subject: [PATCH] Some versions of dlltool may require a library name for libusb-1.0.def even though the library name is optional as specified by Microsoft. This patch adds the library name to libusb-1.0.def. Reference thread in MinGW-w64 mailing list. http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/5141 --- libusb/libusb-1.0.def |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Still, the non inline version (clicking "save as" on the attachment) produces a file that doesn't have the > though, so I don't see it as that much of a problem. Did you also get the > prefix when saving the attachment? And it seems you're also attaching patches in what I would call hybrid mode: with both inline and attachment. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
First of all, I’d like to thank you both very much for your fast response. I use pcsc in a productive environment (24/7), where contactless smardcards are used to grant access to an application. Because there are more than 25 pc-terminals involved, I’d appreciate a non disturbing and simple way to get a tracelog. All terminals are equal regarding hardware and software. Original-Nachricht > Datum: Tue, 03 Jul 2012 17:07:41 +0100 > Von: Pete Batard > For the record, libusbx 1.0.12 is the latest, and was released a few > weeks ago. I know and I’m sorry, but I was not able to compile it with the right path values matching the Ubuntu directory scheme. I’ll try it again! > Now it is possible that even 4 hours worth of debug logs may be too > voluminous […] The issue seems to happen totally random (regarding time of occurrence and affected pc-terminal). Sometimes it occurs some minutes after a user logs in with a smartcard, sometimes there are several hours between the last user action and the crash. > For that, you should remove the --enable-debug-log when compiling > libusbx and then, in /etc/init.d/pcscd, set the environmental variable > LIBUSB_DEBUG to 3 (by adding "export LIBUSB_DEBUG=3" at the top of your > file). > […] > Is that a troubleshooting approach you think you can go with? I’ll try to modify the /etc/init.d/pcscd in the first place. > Datum: Tue, 3 Jul 2012 18:08:18 +0200 > Von: Ludovic Rousseau > What driver are your using? A (proprietary) driver from Omnikey? Yes, it is the pc/sc-driver from Omnikey for the Omnikey 5321 CR (latest version, 32 bit). http://www.hidglobal.de/driverDownloads.php?techCat=19&prod_id=368 > Have you tried my CCID driver [1]? Note that you wont be able to use > the reader contactless interface. Yes, I tried, but I need the contactless interface. - Regards Sebastian = -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
