On Thu, Oct 25, 2018 at 07:59:36AM +, Emmanuel Dreyfus wrote:
> 3) Use USB timeout in usbd_transfer()
> https://ftp.espci.fr/shadow/manu/usb_sync_xfer.patch
>
> Make sure the USB timeout is used when doing synchronous USB transfers.
> Here again the goal is to avoid getting stuck in the
On Thu, Oct 25, 2018 at 12:27:22PM +, Emmanuel Dreyfus wrote:
> On Thu, Oct 25, 2018 at 08:01:47AM -0400, Mouse wrote:
> > Shouldn't you do that always for that , since the
> > descriptors could get overwritten by garbage which happens to contain
> > reasonable-looking type and size values?
>
On Thu, Oct 25, 2018 at 08:01:47AM -0400, Mouse wrote:
> Shouldn't you do that always for that , since the
> descriptors could get overwritten by garbage which happens to contain
> reasonable-looking type and size values?
I can do that. It will be even faster.
--
Emmanuel Dreyfus
> [T]he pn533 chip from NXP [...] has at least two bugs in its USB
> implementation:
> - Large transfer can overwrite the chip USB configuration descriptors
> - In some situation the chip fails to update the toggle bit in USB
> frame.
> [...]
> I found three situations where the NetBSD kernel
Hello
I made some progress on this issue. The problem is common to NFC readers
powered by the pn533 chip from NXP, which is quite common. It has at
least two bugs in its USB implementation:
- Large transfer can overwrite the chip USB configuration descriptors
- In some situation the chip fails to
Christos Zoulas wrote:
> Isn't there a way to reset it?
I tried various way to reset it without a reboot and never got it to a
working state.
The test is to get it stuck, then detach/reattach:
drvctl -u ugen0
drvctl -r -a usbdevif uhub1
On vanilla kernel, usbd_probe_and_attach() fails on
On Wed, Oct 17, 2018 at 06:03:16AM +0100, Nick Hudson wrote:
> Can you make the trace available somewhere, please?
The traces are what happen with my fake descriptors patch.
Trying nfc-list -t 1 but the device stopped responding:
https://ftp.espci.fr:shadow/manu/timeout.trace
Reboot trace:
On 11/10/2018 15:11, Emmanuel Dreyfus wrote:
Hello
On both netbsd-8 and -current, I have a problem with USB devices that
get stuck in a non-functionning state even after a reboot.
This happens after interrupting transfer with different NFC readers
from different vendors, and the only way to
Emmanuel Dreyfus wrote:
> I did not post the whole patch for the sake of clarity, but it seems it
was a
> mistake. Please find it below.
>
> The substituted values are chosen based on vendorId/producId obtained
earlier
> from the device descriptor (which fortunately does not get corrupted). If
one
Terry Moore wrote:
> Your code looks like a change to the core USB stack. You're using a
> get-descriptor failure to trigger a stuff. If I'm right about where the
> change is located, at that layer, the code has no idea if that failure might
> be expected. You're just substituting a value. You
: tech-kern-ow...@netbsd.org On Behalf Of
Emmanuel Dreyfus
Sent: Tuesday, October 16, 2018 19:19
To: Terry Moore
Cc: tech-kern@netbsd.org
Subject: Re: Reboot resistant USB bug
Terry Moore wrote:
> Also, some descriptor-gets will normally fail, and it's important to pass
> the f
Terry Moore wrote:
> Also, some descriptor-gets will normally fail, and it's important to pass
> the failure to the caller. So I believe that your fix will have unforeseen
> side-effects.
Well, here the chip documentation states the USB descriptors are
immutable. I used the values from that
: Reboot resistant USB bug
On Thu, Oct 11, 2018 at 02:11:22PM +, Emmanuel Dreyfus wrote:
> On both netbsd-8 and -current, I have a problem with USB devices that
> get stuck in a non-functionning state even after a reboot.
I investigated a lot: in my example, the pn533 chip seems to corrupts
i
Nick Hudson wrote:
> Doesn't the hub power the port down? The bug is probably in uhub.c
If I understand correctly, not all hubs are able to power down a port.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On 16/10/18 16:00, Christos Zoulas wrote:
In article <20181016122719.gi16...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
On Thu, Oct 11, 2018 at 02:11:22PM +, Emmanuel Dreyfus wrote:
On both netbsd-8 and -current, I have a problem with USB devices that
get stuck in a non-functionning
In article <20181016122719.gi16...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
>On Thu, Oct 11, 2018 at 02:11:22PM +, Emmanuel Dreyfus wrote:
>> On both netbsd-8 and -current, I have a problem with USB devices that
>> get stuck in a non-functionning state even after a reboot.
>
>I
On Thu, Oct 11, 2018 at 02:11:22PM +, Emmanuel Dreyfus wrote:
> On both netbsd-8 and -current, I have a problem with USB devices that
> get stuck in a non-functionning state even after a reboot.
I investigated a lot: in my example, the pn533 chip seems to corrupts
its USB config, interface
Hello,
On Sat, Oct 13, 2018 at 08:31:43AM +0100, Iain Hibbert wrote:
> On Thu, 11 Oct 2018, Emmanuel Dreyfus wrote:
>
> > Hello
> >
> > On both netbsd-8 and -current, I have a problem with USB devices that
> > get stuck in a non-functionning state even after a reboot.
> >
> > This happens
On Thu, 11 Oct 2018, Emmanuel Dreyfus wrote:
> Hello
>
> On both netbsd-8 and -current, I have a problem with USB devices that
> get stuck in a non-functionning state even after a reboot.
>
> This happens after interrupting transfer with different NFC readers
> from different vendors, and the
Hello
On both netbsd-8 and -current, I have a problem with USB devices that
get stuck in a non-functionning state even after a reboot.
This happens after interrupting transfer with different NFC readers
from different vendors, and the only way to recover the device is
to power-cycle it. I
20 matches
Mail list logo
