Hi all,
I am trying to understand how FreeBSD's USB subsystem works and appear to be
running into a kernel panic due to a failed assertion that I do not understand.
the assertion in question is /usr/src/sys/dev/usb/usb_transfer.c:1954.
My understanding is that you first configure usbd_transfer_
On Wed, 2022-03-09 at 20:26 +1030, Daniel O'Connor wrote:
>
> This one?
>
> USB_XFER_LOCK_ASSERT(xfer, MA_OWNED);
>
>
> I think that assertion is saying you have to have acquired the USB
> transfer lock USB_XFER_LOCK() et al, although I am not entirely sure
> how you do that 'bare'. I h
On Wednesday 09 March 2022 16:42:58 PM (-05:00), Farhan Khan wrote:
> -
> error = usbd_transfer_setup(uaa->device, &iface_index, usc->usc_xfer,
> athn_config_common, ATHN_N_TRANSFERS, usc, &sc->sc_mtx);
> ATHN_LOCK(sc);
> usbd_transfer_start
mp -w file.pcap) and I see that every USB packet has a response from the
device. Is this response packet handled by one of the RX callbacks? Or is this
the same as TX's USB_ST_TRANSFERRED?
Thank you and pardon the multiple questions!
--
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C
`usb_config`?
I wonder if it has anything to do with the endpoint address being a specific
address rather than `UE_ADDR_ANY`? Curious why that value even exists rather
than the exact address?
Questions glore! :)
--
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE
on the issue. I have both set and disabled pipe_bof on the Rx Interrupt with
the same result.
I borrowed the above code from the otus(4) driver.
Please assist. Thanks!
--
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE
.
The OpenBSD equivalent of the firmware loader is this:
https://github.com/openbsd/src/blob/master/sys/dev/usb/if_athn_usb.c#L642
The interrupt handler is also athn_usb_intr online 1874.
Any assistance would be great, been stuck for a few weeks :/
--
Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2
On 4/18/22 14:57, Hans Petter Selasky wrote:
Hi,
error = tsleep(&usc->wait_msg_id, 0, "athnfw", 5);
This means wait 5 ticks which is typically 5ms before timing out,
which is probably too short!
This code is wrong for FreeBSD.
The lock should cover the whole section and you should use msl
On Tue, 2022-04-19 at 09:01 +0200, Hans Petter Selasky wrote:
> On 4/19/22 05:51, Farhan Khan wrote:
> > Thank you! I made the changes, but the problem remains, namely the
> > athn_usb_intr INTR RX callback is never called.
>
> Did you start/reststart this USB transfer?
&g
On Wed, 2022-04-20 at 20:37 +0200, Hans Petter Selasky wrote:
>
> Hi,
>
> It appears you've programmed the interrupt endpoint to only receive
> one
> USB packet, because there is no /* FALLTHROUGH */, but a "break;"
> statement instead!
>
> > break;
> > case USB_ST_SETU
On Thu, 2022-04-21 at 00:18 -0400, Farhan Khan wrote:
>
> Hi!
>
> I removed that break and the issue remains.
I forgot to include a link to my code:
https://github.com/khanzf/freebsd/blob/9cbac59093ea8a530d3f39fc139ae2a0c6d321a6/sys/dev/athn/usb/if_athn_usb.c#L2411
On Thu, 2022-04-21 at 07:57 +0200, Hans Petter Selasky wrote:
> Hi,
>
> 8) usbdump will answer this question.
>
> I see some more bugs:
>
> [ATHN_RX_INTR] = {
> .type = UE_INTERRUPT,
> .endpoint = 0x83, // AR_PIPE_RX_INTR,
> .direction = UE
On Thu, 2022-04-21 at 20:19 +0200, Hans Petter Selasky wrote:
> On 4/21/22 19:51, Farhan Khan wrote:
> > The usb_config is listed below. I got the bufsize's by running
> > `lsusb`
> > on Linux, but it should be the same basic output from FreeBSD
> > tools. A
>
On Fri, 2022-04-22 at 08:43 +0200, Hans Petter Selasky wrote:
> If your device is ugenX.Y, usbdump is:
>
> usbdump -i usbusX -f Y -s 256 -vvv
>
> --HPS
Based on the FRAME[1] size, it seems that the length is 1024 bytes.
That seems low, but it might not be for bulk transfers.
The long-form outpu
On Sunday, April 24, 2022 5:48:52 AM EDT Hans Petter Selasky wrote:
> Could you also provide:
>
> usbconfig -d ugenX.Y dump_curr_config_desc
>
> --HPS
Please find the config dump below:
-
$ sudo usbconfig -d ugen3.2 dump_curr_config_desc
ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps
I mistakenly emailed Hans directly rather than copying the email list. Sorry,
switched email clients :/ Keeping the full exchange below for one email round.
On Tuesday, April 26, 2022 3:01:44 AM EDT you wrote:
> On 4/26/22 07:42, Farhan Khan wrote:
> > On Monday, April 25, 2022 4:21:
On Wednesday, April 27, 2022 3:41:27 AM EDT Hans Petter Selasky wrote:
> Somewhere in the code you are asking for a read of 1024 bytes on the
> interrupt endpoint. That is what usbdump says. That means multiple
> packets will have to be received for it to complete. I'm not sure
Making progress: I
On Thursday, April 28, 2022 2:06:57 AM EDT Hans Petter Selasky wrote:
> On 4/28/22 07:53, Farhan Khan wrote:
> >> printf("FRAME LENGTH = %d\n", usbd_xfer_max_len(xfer));
> >
> > 64 bytes, sounds correct.
>
> And do you get a completion on that USB transfe
Hi all,
My understanding is that you have to manually start a USB Rx interrupt
transfer for each read rather than when data is available to read. That makes
sense, but I am trying to understand where in the code that reading mechanism
is done. I looked up otus(4) and urtw(4), but those drivers
On May 6, 2022 5:34:54 AM EDT, Hans Petter Selasky wrote:
>Hi Farhan,
>
>On 5/6/22 05:52, Farhan Khan wrote:
>> So, how is the polling of an Rx interrupt done?
>
>The software side typically queues a DMA job for the hardware. Every 125us the
>hardware wakes up and send
Hi all,
I am trying to understand why a USB Rx interrupt callback is not triggering. I
am sending a USB Tx interrupt packet. The immediate next step is that the
function will msleep(). The corresponding wakeup() occurs after an Rx
interrupt.
There is no explicit usbd_transfer_start() on the Rx
On Monday, May 16, 2022 9:52:14 AM EDT Hans Petter Selasky wrote:
> On 5/15/22 04:41, Farhan Khan wrote:
> > Hi all,
> >
> > I am trying to understand why a USB Rx interrupt callback is not
> > triggering. I am sending a USB Tx interrupt packet. The immediate next
&g
22 matches
Mail list logo
