OSX critical bug

[Vitali Lovich-2]

I think this should be a release blocker.  libusb has a tendency to
kill the builtin mouse & keyboard on Macbook Pros.  I'm pretty sure
that it has to do with the suspend/resume descriptor reading logic
when a device is plugged in.  I don't think it's necessarily a libusb
bug, but I think it's triggering an issue on Apple's end.  That
behaviour should be made configurable & disabled by default.  I don't
know enough autoconf to do it properly.  In my version of the code I
just #if 0'd out that section of code.

-Vitali

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Vitali Lovich wrote:
> I don't think it's necessarily a libusb bug, but I think it's
> triggering an issue on Apple's end.  That behaviour should be made
> configurable & disabled by default.  I don't know enough autoconf
> to do it properly.  In my version of the code I just #if 0'd out
> that section of code.

Are more details available? Is there already a ticket? If not then
please show what code you #if 0 out?


//Peter

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Nathan Hjelm-2]

I don't think it is a suspend/unsuspend problem or else Apple's own USB Prober (which is where I got the logic) would cause the mouse/keyboard to drop.

Do you have a reproducer I can try?

-Nathan

On Jul 11, 2011, at 02:36 PM, Vitali Lovich <[hidden email]> wrote:

I think this should be a release blocker. libusb has a tendency to
kill the builtin mouse & keyboard on Macbook Pros. I'm pretty sure
that it has to do with the suspend/resume descriptor reading logic
when a device is plugged in. I don't think it's necessarily a libusb
bug, but I think it's triggering an issue on Apple's end. That
behaviour should be made configurable & disabled by default. I don't
know enough autoconf to do it properly. In my version of the code I
just #if 0'd out that section of code.

-Vitali

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

It's not always 100%.  There appear to be some set of operations that cause it.  We're seeing particularly during USB DFU of our device but not exclusively.  Personally, I've seen it particularly with an external cinema display attached.

Also remember that the USB prober by default doesn't probe suspended devices.  Furthermore, I believe it has to do with the built-in mouse & keyboard being suspended, which is difficult to do if you're using the mouse.

Maybe a repro test case would be to have a loop of libusb_enum_devices & plug/unplug devices, but I don't know if that will do it.  I know I have a friend at Apple who has seen this too & he uses libusb for some test cases.

@ line 555

 555 #if 0

 556     if (ret != kIOReturnSuccess) {

 557       int try_unsuspend = 1;

 558 #if DeviceVersion >= 320

 559       UInt32 info;

 ...

 579         (*device)->USBDeviceClose (device);

 580       }

 581     }

 582 #endif

 583 

I also have a patch that filters out all devices that aren't ours from being read, but I want to extend the API to make that generic.

-Vitali

On Jul 11, 2011, at 2:02 PM, Nathan Hjelm wrote:

I don't think it is a suspend/unsuspend problem or else Apple's own USB Prober (which is where I got the logic) would cause the mouse/keyboard to drop.

Do you have a reproducer I can try?

-Nathan

On Jul 11, 2011, at 02:36 PM, Vitali Lovich <[hidden email]> wrote:

I think this should be a release blocker. libusb has a tendency to
kill the builtin mouse & keyboard on Macbook Pros. I'm pretty sure
that it has to do with the suspend/resume descriptor reading logic
when a device is plugged in. I don't think it's necessarily a libusb
bug, but I think it's triggering an issue on Apple's end. That
behaviour should be made configurable & disabled by default. I don't
know enough autoconf to do it properly. In my version of the code I
just #if 0'd out that section of code.

-Vitali

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Tue, Jul 12, 2011 at 6:29 AM, Vitali Lovich <[hidden email]> wrote:
> I also have a patch that filters out all devices that aren't ours from being
> read, but I want to extend the API to make that generic.

What do you mean by  "filters out all devices that aren't ours"?

Recently there was a similar discussion for Windows. The implementation
under Linux will make libusb to be able to enumerate all USB device.
So Pete follows this under Windows. So the example "lsusb" program
can list all USB device under Linux, Windows and Mac OS X.

However, under Linux, all the device can be used by libusb to do further
actions (I/O like Read/Write) once the kernel driver (other than usbfs)
is detached. It is actually the same for Windows and Mac OS X
if the unsupported driver is "detached" by some means (switch to
WinUSB driver or write a codeless kext to prevent the kernel driver
from attaching). So they kind of behave all the same in this aspect.

The issue is that there is no such detaching function under Windows
and Mac OS X. So sometimes users got confused. For examples,
users will see USB HID device or USB mass storage device with "lsusb"
example but when they try to "open" the device, it will fail.

And there are also consequences of trying to enumerate all USB
device under Windows (IOCTL to hubs). Now it seems there are
issues of doing similar things under Mac OS X.

Are you proposing an API that limits libusb enumerating certain
class of device only? That might not be easy to be implemented
across different platform.

--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

On Jul 11, 2011, at 6:41 PM, Xiaofan Chen wrote:

> On Tue, Jul 12, 2011 at 6:29 AM, Vitali Lovich <[hidden email]> wrote:
>> I also have a patch that filters out all devices that aren't ours from being
>> read, but I want to extend the API to make that generic.
>
> What do you mean by  "filters out all devices that aren't ours"?
If the VID isn't my companies VID, then we skip the entire descriptor reading code path that happens in the darwin backend.  The generic interface I want is to pass this information to a callback (i.e. the vid/pid & have it return whether or not this is a valid device - the difficulty is that this may happen on a different thread since on darwin this happens in a separate thread that manages the hotplug events).  Alternatively, it may be possible to just restrict this filtering at the moment for VID/PID & thus it could just be a libusb_filter_vid_pid type API.  Additionally could expose it as an environment variables too which takes priority in case the user on the command line wants a different set of devices filtered.

>
> Recently there was a similar discussion for Windows. The implementation
> under Linux will make libusb to be able to enumerate all USB device.
> So Pete follows this under Windows. So the example "lsusb" program
> can list all USB device under Linux, Windows and Mac OS X.
>
> However, under Linux, all the device can be used by libusb to do further
> actions (I/O like Read/Write) once the kernel driver (other than usbfs)
> is detached. It is actually the same for Windows and Mac OS X
> if the unsupported driver is "detached" by some means (switch to
> WinUSB driver or write a codeless kext to prevent the kernel driver
> from attaching). So they kind of behave all the same in this aspect.
>
> The issue is that there is no such detaching function under Windows
> and Mac OS X. So sometimes users got confused. For examples,
> users will see USB HID device or USB mass storage device with "lsusb"
> example but when they try to "open" the device, it will fail.
>
> And there are also consequences of trying to enumerate all USB
> device under Windows (IOCTL to hubs). Now it seems there are
> issues of doing similar things under Mac OS X.
>
> Are you proposing an API that limits libusb enumerating certain
> class of device only? That might not be easy to be implemented
> across different platform.

Not necessarily certain classes of devices.  That would be trickier since you have to read the descriptor in the first place which is potentially what's causing the problem.  First pass would be to enable vid/pid filtering which would get most developers 90% of what is needed.

More complex filtering based on the device class within the descriptor could be done outside libusb (although filtering it at the libusb level could be useful since fewer resources would created, it would prevent the device from propagating out to higher levels, etc).  That remaining 10% can be accomplished elsewhere and isn't integral to the libusb core (whereas right now the lack of vid/pid filtering means we can have serious side-effects on OSX).

-Vitali


>
> --
> Xiaofan


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Tue, Jul 12, 2011 at 10:33 AM, Vitali Lovich <[hidden email]> wrote:

>
> On Jul 11, 2011, at 6:41 PM, Xiaofan Chen wrote:
>
>> On Tue, Jul 12, 2011 at 6:29 AM, Vitali Lovich <[hidden email]> wrote:
>>> I also have a patch that filters out all devices that aren't ours from being
>>> read, but I want to extend the API to make that generic.
>>
>> What do you mean by  "filters out all devices that aren't ours"?
>
> If the VID isn't my companies VID, then we skip the entire descriptor
> reading code path that happens in the darwin backend.  The generic
> interface I want is to pass this information to a callback (i.e. the vid/pid &
> have it return whether or not this is a valid device - the difficulty is that this
> may happen on a different thread since on darwin this happens in a
> separate thread that manages the hotplug events).  Alternatively, it may
> be possible to just restrict this filtering at the moment for VID/PID & thus
> it could just be a libusb_filter_vid_pid type API.  Additionally could expose
> it as an environment variables too which takes priority in case the user on
> the command line wants a different set of devices filtered.

Seems to be a good idea.

>> Are you proposing an API that limits libusb enumerating certain
>> class of device only? That might not be easy to be implemented
>> across different platform.
>
> Not necessarily certain classes of devices.  That would be trickier
> since you have to read the descriptor in the first place which is
> potentially what's causing the problem.  First pass would be to enable
> vid/pid filtering which would get most developers 90% of what is needed.

vid/pid filter is one possibility. What I have in my mind is to have the
filter option based on driver support. For Mac OS X, maybe only
device without driver detached will be listed with this filter.
For Windows, maybe only device with winusb driver (or in
the future libusb0.sys and libusbk.sys) are searched.

> More complex filtering based on the device class within the descriptor
> could be done outside libusb (although filtering it at the libusb level
> could be useful since fewer resources would created, it would prevent
>  the device from propagating out to higher levels, etc).  That remaining
> 10% can be accomplished elsewhere and isn't integral to the libusb
> core (whereas right now the lack of vid/pid filtering means we can have
> serious side-effects on OSX).
>




--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Graeme Gill]

Xiaofan Chen wrote:
> vid/pid filter is one possibility. What I have in my mind is to have the
> filter option based on driver support. For Mac OS X, maybe only
> device without driver detached will be listed with this filter.

Sounds like a workaround to a bug. Wouldn't it be better to
figure out if the bug can be fixed, before resorting to a workaround ?

Graeme Gill.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Tue, Jul 12, 2011 at 11:18 AM, Graeme Gill <[hidden email]> wrote:
> Xiaofan Chen wrote:
>> vid/pid filter is one possibility. What I have in my mind is to have the
>> filter option based on driver support. For Mac OS X, maybe only
>> device without driver detached will be listed with this filter.
>
> Sounds like a workaround to a bug. Wouldn't it be better to
> figure out if the bug can be fixed, before resorting to a workaround ?

In the OP's case, maybe this is the case.

What I have in mind is more generic. In mose cases you really do not
care about other USB device in the system. This is especially
true for the Windows backend. With this filter option, the USB
hubs will be disturbed less.



--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

On Mon, Jul 11, 2011 at 8:22 PM, Xiaofan Chen <[hidden email]> wrote:
> On Tue, Jul 12, 2011 at 11:18 AM, Graeme Gill <[hidden email]> wrote:
>> Xiaofan Chen wrote:
>>> vid/pid filter is one possibility. What I have in my mind is to have the
>>> filter option based on driver support. For Mac OS X, maybe only
>>> device without driver detached will be listed with this filter.
>>
>> Sounds like a workaround to a bug. Wouldn't it be better to
>> figure out if the bug can be fixed, before resorting to a workaround ?

The bug is the unsuspending of the trackpad device.  I suspect it's
either in the actual driver or a HW bug.  In either case, nothing that
can be solved generically by libusb other than not unsuspending the
device in the first place (which is what I recommended to do).

The vid/pid filtering is a side-track issue that seems to have
hijacked this thread.

>
> In the OP's case, maybe this is the case.
>
> What I have in mind is more generic. In mose cases you really do not
> care about other USB device in the system. This is especially
> true for the Windows backend. With this filter option, the USB
> hubs will be disturbed less.
>
>
>

On Windows, libusb already will only list devices that have a
libusb-compatible driver installed anyways, so that's not a problem.
On OSX I'm not sure if you can generically detect whether or not a
device has a codeless kext for it (how do you even detect that that
codeless kext implies it should be used with libusb?).  In either
case, filtering by this assumes that you'll only ever have 1
libusb-based program which is a bad assumption IMO.  vid/pid filtering
is really the only way to do this in a way that gets along between
programs.

-Vitali

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Nathan Hjelm-2]

On Jul 11, 2011, at 9:30 PM, Vitali Lovich wrote:

> On Mon, Jul 11, 2011 at 8:22 PM, Xiaofan Chen <[hidden email]> wrote:
>> On Tue, Jul 12, 2011 at 11:18 AM, Graeme Gill <[hidden email]> wrote:
>>> Xiaofan Chen wrote:
>>>> vid/pid filter is one possibility. What I have in my mind is to have the
>>>> filter option based on driver support. For Mac OS X, maybe only
>>>> device without driver detached will be listed with this filter.
>>>
>>> Sounds like a workaround to a bug. Wouldn't it be better to
>>> figure out if the bug can be fixed, before resorting to a workaround ?
>
> The bug is the unsuspending of the trackpad device.  I suspect it's
> either in the actual driver or a HW bug.  In either case, nothing that
> can be solved generically by libusb other than not unsuspending the
> device in the first place (which is what I recommended to do).

I just double checked on my Macbook Pro and I see two things:

1. The trackpad/keyboard is not suspended by default (the only devices that are suspended right now are the card reader, a brcm270 hub, and the ir receiver), and
2. USB Prober will always try to un-suspend the device (there is no option-- take a look at the code IOUSBFamily).

Does USB Prober really show the trackpad as suspended on your Macbook Pro? That doesn't make any sense to me.

Also, what version of IOUSBFamily are you using?

-Nathan


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Vitali Lovich-2]

Trackpad/keyboard auto-suspend on inactivity to save power.  For
instance, attach an external keyboard & mouse & look at Apple Internal
Keyboard / Trackpad (make sure you have Refresh Automatically
selected).  USB prober has an option in the UI: "Probe suspended
devices" - by default it is unselected.  Are you saying that the
source code for this tool is available & you see that it ignores this
option?

com.apple.iokit.IOUSBFamily      4.2.4

-Vitali

On Mon, Jul 11, 2011 at 10:01 PM, Nathan Hjelm <[hidden email]> wrote:

>
> On Jul 11, 2011, at 9:30 PM, Vitali Lovich wrote:
>
>> On Mon, Jul 11, 2011 at 8:22 PM, Xiaofan Chen <[hidden email]> wrote:
>>> On Tue, Jul 12, 2011 at 11:18 AM, Graeme Gill <[hidden email]> wrote:
>>>> Xiaofan Chen wrote:
>>>>> vid/pid filter is one possibility. What I have in my mind is to have the
>>>>> filter option based on driver support. For Mac OS X, maybe only
>>>>> device without driver detached will be listed with this filter.
>>>>
>>>> Sounds like a workaround to a bug. Wouldn't it be better to
>>>> figure out if the bug can be fixed, before resorting to a workaround ?
>>
>> The bug is the unsuspending of the trackpad device.  I suspect it's
>> either in the actual driver or a HW bug.  In either case, nothing that
>> can be solved generically by libusb other than not unsuspending the
>> device in the first place (which is what I recommended to do).
>
> I just double checked on my Macbook Pro and I see two things:
>
> 1. The trackpad/keyboard is not suspended by default (the only devices that are suspended right now are the card reader, a brcm270 hub, and the ir receiver), and
> 2. USB Prober will always try to un-suspend the device (there is no option-- take a look at the code IOUSBFamily).
>
> Does USB Prober really show the trackpad as suspended on your Macbook Pro? That doesn't make any sense to me.
>
> Also, what version of IOUSBFamily are you using?
>
> -Nathan
>
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Nathan Hjelm-2]

On Jul 11, 2011, at 11:05 PM, Vitali Lovich wrote:

> Trackpad/keyboard auto-suspend on inactivity to save power.  For
> instance, attach an external keyboard & mouse & look at Apple Internal
> Keyboard / Trackpad (make sure you have Refresh Automatically
> selected).  USB prober has an option in the UI: "Probe suspended
> devices" - by default it is unselected.  Are you saying that the
> source code for this tool is available & you see that it ignores this
> option?


Newer versions of USB Prober (IOUSBFamily > 315.4.1)  do indeed have/honor the probe suspended devices option.

Current version (10.6.8)
http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-424.4.1/USBProberV2/BusProber.m

Older version (10.5.6) -- this was the reference I used when adding the ability to unsuspend a device (this feature was not present in libusb 0.1):
http://www.opensource.apple.com/source/IOUSBFamily/IOUSBFamily-315.4.1/USBProberV2/BusProber.m

On Lion, I have noticed when probe suspended devices is selected the trackpad and keyboard can become unresponsive for several seconds. I hadn't seen this behavior before with USB Prober (and never seen it with libusb). I might be able to reproduce the problem and find an appropriate workaround (like not un-suspending certain classes of devices with vendor ID 0x05ac -- Apple).

-Nathan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel