From: Felipe Balbi <balbi@kernel.org> Date: 2021-07-23 11:23:55
Ferry Toth [off-list ref] writes:
Hi
Op 23-07-2021 om 08:59 schreef Felipe Balbi:
quoted
Hi,
Ferry Toth [off-list ref] writes:
quoted
quoted
quoted
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in
depth:115540359
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in
Removing uac2 from the config makes the call trace go away, but the R/W
speed does not change.
I am testing with 5.14.0-rc2 and now related error appears (not in rc1).
Disabling uac2 solves it still. Any idea what it could be?
BUG: unable to handle page fault for address: 0000000500000000
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted
5.14.0-rc2-edison-acpi-standard #1
(cool that you're running on ACPI heh)
Thanks to Andy this is Edison-Arduino board with ACPI.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: dwc3 dwc3.0.auto: request 00000000fbc71244 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: request 00000000ad1b8c18 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in
depth:115540359
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: configfs-gadget gadget: u_audio_start_playback:451 Error!
kernel: dwc3 dwc3.0.auto: request 000000003c32dcc5 was not queued to ep5in
kernel: dwc3 dwc3.0.auto: request 00000000b2512aa9 was not queued to ep5in
Removing uac2 from the config makes the call trace go away, but the R/W
speed does not change.
I am testing with 5.14.0-rc2 and now related error appears (not in rc1).
Disabling uac2 solves it still. Any idea what it could be?
BUG: unable to handle page fault for address: 0000000500000000
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 0 PID: 494 Comm: irq/14-dwc3 Not tainted
5.14.0-rc2-edison-acpi-standard #1
(cool that you're running on ACPI heh)
Thanks to Andy this is Edison-Arduino board with ACPI.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
On Edison-Arduino I have a switch to go to device mode, after which udev
triggers a script configure gadgets through configfs.
I tried to log following these instructions:
https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs <https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html#reporting-bugs>
Unfortunately the kernel crashes so badly I can not get to the ` cp
/t/trace /root/trace.txt` line (after a while the watchdog kicks).
What to do next?
BTW there is a secondary problem not related to dwc3: the console is not
working well and loosing chars. I can connect through wifi/ssh though.
Hi
Op 24-07-2021 om 23:19 schreef Andy Shevchenko:
On Sat, Jul 24, 2021 at 11:59 PM Ferry Toth[off-list ref] wrote:
quoted
BTW there is a secondary problem not related to dwc3: the console is not
working well and loosing chars. I can connect through wifi/ssh though.
You mean even on the kernel before any crash happened due to DWC3 stuff?
Exactly.
And this was working fine with rc1.
I do have patches (as you know) for improving dma for the hsu. But, for
the console afaik dma is disabled.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
But as I am using configfs (excerpt follows) and just disabling the last
2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding
the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
not a problem, we'll still be here when you're back :-)
quoted
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
Right, either there's an actual bug in uac2, or we're running out of
FIFO space.
Are you enabling the TXFIFO flag here again? If we suspect that we're
running out of FIFO space, then:
- First, making sure we're explicitly enabling the TXFIFO resize flag.
- Second, we should see the same warning we saw previously:
dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in
depth:115540359
Thanks
Wesley Cheng
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
not a problem, we'll still be here when you're back :-)
quoted
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
Right, either there's an actual bug in uac2, or we're running out of
FIFO space.
Are you enabling the TXFIFO flag here again? If we suspect that we're
running out of FIFO space, then:
- First, making sure we're explicitly enabling the TXFIFO resize flag.
- Second, we should see the same warning we saw previously:
dwc3 dwc3.0.auto: Fifosize(2154) > RAM size(2022) ep5in
depth:115540359
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
With 5.14.0-rc5 the problem seems worse (or different?), and just
disabling uac2 gadget does not prevent the crash. Even disabling gser
and mass_storage.usb0 as well there is still a crash.
Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)?
quoted
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
Right, either there's an actual bug in uac2, or we're running out of
FIFO space.
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
With 5.14.0-rc5 the problem seems worse (or different?), and just
disabling uac2 gadget does not prevent the crash. Even disabling gser
and mass_storage.usb0 as well there is still a crash.
Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)?
I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending
commit, verify if reverting that on -rc1 works, then verify if reverting
on -rc5 also works :-)
--
balbi
Do you mind enabling dwc3 traces and collecting them? Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in host mode
and then switch to device mode. If so I can enable traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
quoted
With 5.14.0-rc5 the problem seems worse (or different?), and just
disabling uac2 gadget does not prevent the crash. Even disabling gser
and mass_storage.usb0 as well there is still a crash.
Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)?
I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending
commit, verify if reverting that on -rc1 works, then verify if reverting
on -rc5 also works :-)
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in
host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will
not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until
6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
quoted
quoted
With 5.14.0-rc5 the problem seems worse (or different?), and just
disabling uac2 gadget does not prevent the crash. Even disabling gser
and mass_storage.usb0 as well there is still a crash.
Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)?
I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending
commit, verify if reverting that on -rc1 works, then verify if reverting
on -rc5 also works :-)
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in
host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will
not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until
6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
Since it's rc6 to rc7 I think the best is to send a revert series to
handle the regression.
quoted
quoted
quoted
With 5.14.0-rc5 the problem seems worse (or different?), and just
disabling uac2 gadget does not prevent the crash. Even disabling gser
and mass_storage.usb0 as well there is still a crash.
Now I'm not sure how to proceed. Bisect rc1? Or focus on rc5 (rc6?)?
I'd first bisect between 5.13 and v5.14-rc1. Once you find the offending
commit, verify if reverting that on -rc1 works, then verify if reverting
on -rc5 also works :-)
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in
host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and will
not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time until
6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB in
host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1, 5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries. That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both with
dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the last
2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding
the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all three
24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both
with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the last
2 line resolves the issue, I'm guessing uac2 is the issue. Or exceeding
the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
Unfortunately the kernel crashes so badly I can not get to
the ` cp
/t/trace /root/trace.txt` line (after a while the watchdog
kicks).
What to do next?
Pass ftrace_dump_on_oops to kernel cmdline.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all
three 24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both
with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Hi Pavel,
I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add
feedback endpoint support") that Ferry reported the issue from
bisection. I see at least a couple problems in the new UAC2 changes.
1) usb_ep_dequeue() is asynchronous. Don't free requests before the
controller driver give them back.
2) Did you test with SuperSpeed? I don't see companion descriptor.
Please fix them.
Thanks,
Thinh
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
Unfortunately the kernel crashes so badly I can not get to
the ` cp
/t/trace /root/trace.txt` line (after a while the watchdog
kicks).
What to do next?
Pass ftrace_dump_on_oops to kernel cmdline.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all
three 24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both
with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Hi Pavel,
I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add
feedback endpoint support") that Ferry reported the issue from
bisection. I see at least a couple problems in the new UAC2 changes.
1) usb_ep_dequeue() is asynchronous. Don't free requests before the
controller driver give them back.
2) Did you test with SuperSpeed? I don't see companion descriptor.
Please fix them.
Given it's late in the cycle I agree with Andy it would be best to
revert the series now.
I will be happy to test on dwc3 when a fixed series arrives.
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
Unfortunately the kernel crashes so badly I can not get to
the ` cp
/t/trace /root/trace.txt` line (after a while the watchdog
kicks).
What to do next?
Pass ftrace_dump_on_oops to kernel cmdline.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from
5.14.0-rc1.
That's great finding. We have a bisection point. There are a
total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all
three 24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both
with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Hi Pavel,
I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add
feedback endpoint support") that Ferry reported the issue from
bisection. I see at least a couple problems in the new UAC2 changes.
1) usb_ep_dequeue() is asynchronous. Don't free requests before the
controller driver give them back.
2) Did you test with SuperSpeed? I don't see companion descriptor.
Please fix them.
Given it's late in the cycle I agree with Andy it would be best to
revert the series now.
I will be happy to test on dwc3 when a fixed series arrives.
Yes, I agree it's the best solution now. I have asked the patch devs
Ruslan and Jerome for help with these issues, I am mostly a tester of
the UAC2 gadget changes (with dwc2 USB2 only available for now).
Best regards,
Pavel.
From: Jack Pham <hidden> Date: 2021-09-02 00:28:24
Hi Thinh,
On Sat, Aug 21, 2021 at 02:57:07AM +0000, Thinh Nguyen wrote:
I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add
feedback endpoint support") that Ferry reported the issue from
bisection. I see at least a couple problems in the new UAC2 changes.
1) usb_ep_dequeue() is asynchronous. Don't free requests before the
controller driver give them back.
2) Did you test with SuperSpeed? I don't see companion descriptor.
We caught this too when testing f_uac2 in SuperSpeed mode. I can
prepare a patch.
Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Thinh,
On Sat, Aug 21, 2021 at 02:57:07AM +0000, Thinh Nguyen wrote:
quoted
I took a look at 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add
feedback endpoint support") that Ferry reported the issue from
bisection. I see at least a couple problems in the new UAC2 changes.
1) usb_ep_dequeue() is asynchronous. Don't free requests before the
controller driver give them back.
2) Did you test with SuperSpeed? I don't see companion descriptor.
We caught this too when testing f_uac2 in SuperSpeed mode. I can
prepare a patch.
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable traces
and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from 5.14.0-rc1.
That's great finding. We have a bisection point. There are a total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the usb
merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all
three 24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I do
not know if Ruslan or Jerome tested them on dwc3 but probably not.
Ruslan has talked about RPi (my case too) and BeagleboneBlack, both
with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have not
followed your long thread (it started as unrelated to uac). Does the
problem appear with f_uac1 or f_uac2? Please how have you reached the
above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Do you mind enabling dwc3 traces and collecting them?
Trying to figure
out how we got here.
I'll try if I can get the same error by booting with USB
in host mode
and then switch to device mode. If so I can enable
traces and collect as
you explained me before.
I'll try before monday, as then I fly for a holiday and
will not be
available before rc5.
No sure if I did this right, on oops everything is pushed to
console
(115k2 serial), I hope nothing essential is lost.
I copied the screen buffer to file see attached.
I wouldn't mind but am leaving on a holiday, won't have time
until 6 aug.
not a problem, we'll still be here when you're back :-)
Well, let's go then :-)
To get back in the mood I have retested 5.13.0, 5.14.0-rc1,
5.14.0-rc2
and 5.14.0-rc5.
I find that 5.13.0 works fine, and the issue starts from
5.14.0-rc1.
That's great finding. We have a bisection point. There are a
total of
13764 commits between v5.13 and v5.14-rc1
$ git rev-list --count v5.13..v5.14-rc1
13764
git bisect should find the offending commit in at most 14 tries.
That's
not too bad.
I correctly guesstimated that the problem got introduced by the
usb merge 79160a60
"Merge tag 'usb-5.14-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb"
116 commits(7 bisects).
24f779dac8f3efb9629adc0e486914d93dc45517 is the first bad commit
"usb: gadget: f_uac2/u_audio: add feedback endpoint support"
Ruslan's 3 patches are related to each other so I reverted all
three 24f779da...e89bb428 and applied the reverts to rc1.
I can confirm this indeed resolves the problem in rc1.
Is late now, tomorrow evening I will apply the reverts to rc6.
With these reverts rc6 works fine as well.
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Not sure how to do that. Do you mean the module should have a parameter
called c_sync? `modinfo` list no parameters for usb_f_uac2.
Those are configfs params, not available in modinfo.
I checked and the value is "adaptive"
https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312
In your configfs script:
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
On the USB Host:
cat /proc/asound/Gadget/stream:
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 64000
Data packet interval: 125 us
Bits: 16
Channel map: FL FR
Sync Endpoint: 0x82 (2 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No
lsusb -v -d 1d6b:0104 | | grep EP.*IN
bEndpointAddress 0x81 EP 1 IN
bEndpointAddress 0x82 EP 2 IN
bEndpointAddress 0x83 EP 3 IN
I have additional patches applied which define controls via EP IN
interrupt mode, not part of that patchset.
Switching to the adaptive mode:
# UAC2 device
mkdir functions/uac2.usb0
echo "adaptive" > functions/uac2.usb0/c_sync
ln -s functions/uac2.usb0 configs/c.1
On the USB Host:
cat /proc/asound/Gadget/stream:
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ADAPTIVE)
Rates: 64000
Data packet interval: 125 us
Bits: 16
Channel map: FL FR
lsusb -v -d 1d6b:0104 | grep EP.*IN
bEndpointAddress 0x81 EP 1 IN
bEndpointAddress 0x82 EP 2 IN
The feedback EP-IN is gone because the mode is adaptive now.
If you think the new input endpoints should not be created by default
for resource-compatibility reasons, the adaptive mode can be set by
default in a fixed patch.
Also the patches defining the new interrupt endpoints can have the
controls disabled by default (and not allocate the EP-IN). These patches
on top of the async patches are already accepted by Greg for usb-next
branch
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+/eaf6cbe0992052a46d93047dc122fad5126aa3bd
. That's why I was trying to sort out the async patches without
reverting them as it will call for more reverts.
Thanks,
Pavel.
From: Andy Shevchenko <hidden> Date: 2021-08-23 15:21:55
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman [off-list ref] wrote:
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
On the USB Host:
cat /proc/asound/Gadget/stream:
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 64000
Data packet interval: 125 us
Bits: 16
Channel map: FL FR
Sync Endpoint: 0x82 (2 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No
lsusb -v -d 1d6b:0104 | | grep EP.*IN
bEndpointAddress 0x81 EP 1 IN
bEndpointAddress 0x82 EP 2 IN
bEndpointAddress 0x83 EP 3 IN
I have additional patches applied which define controls via EP IN
interrupt mode, not part of that patchset.
Switching to the adaptive mode:
# UAC2 device
mkdir functions/uac2.usb0
echo "adaptive" > functions/uac2.usb0/c_sync
ln -s functions/uac2.usb0 configs/c.1
On the USB Host:
cat /proc/asound/Gadget/stream:
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ADAPTIVE)
Rates: 64000
Data packet interval: 125 us
Bits: 16
Channel map: FL FR
lsusb -v -d 1d6b:0104 | grep EP.*IN
bEndpointAddress 0x81 EP 1 IN
bEndpointAddress 0x82 EP 2 IN
The feedback EP-IN is gone because the mode is adaptive now.
If you think the new input endpoints should not be created by default
for resource-compatibility reasons, the adaptive mode can be set by
default in a fixed patch.
Would it be possible to change the mode? If so, then the user may
configure it and crash again.
Also the patches defining the new interrupt endpoints can have the
controls disabled by default (and not allocate the EP-IN). These patches
on top of the async patches are already accepted by Greg for usb-next
branch
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+/eaf6cbe0992052a46d93047dc122fad5126aa3bd
. That's why I was trying to sort out the async patches without
reverting them as it will call for more reverts.
From: Pavel Hofman <hidden> Date: 2021-08-23 15:35:08
Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a):
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman [off-list ref] wrote:
quoted
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
Sure, no problem with reverting. I am just trying to start up some
troubleshooting. A resource exhaustion was mentioned here, that's why I
suggested a way to test the patch with the original number of endpoints
allocated. I do not get any crashes on my setup which uses fewer gadget
functions. That's why I asked what happens if the functions load order
is changed. I am afraid this thread is so complex that the actual
problem has been burried in the history.
Again, I am not the author of the patches, my USB knowledge is way
unsufficient for that. I am trying to make them work as they are
important and make the existing audio gadget actually usable.
Thanks,
Pavel.
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman
[off-list ref] wrote:
quoted
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than
dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
I will send in reverts tomorrow, unless someone has a better idea.
Sure, no problem with reverting. I am just trying to start up some
troubleshooting. A resource exhaustion was mentioned here, that's why I
suggested a way to test the patch with the original number of endpoints
allocated. I do not get any crashes on my setup which uses fewer gadget
functions. That's why I asked what happens if the functions load order
is changed. I am afraid this thread is so complex that the actual
problem has been burried in the history.
Again, I am not the author of the patches, my USB knowledge is way
unsufficient for that. I am trying to make them work as they are
important and make the existing audio gadget actually usable.
Thanks for the suggestions, I didn't think to set params through configfs.
Maybe this will help in tracing the root cause, although that's way over
my head.
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman
[off-list ref] wrote:
quoted
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than
dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
Sure, no problem with reverting. I am just trying to start up some
troubleshooting. A resource exhaustion was mentioned here, that's why I
suggested a way to test the patch with the original number of endpoints
allocated. I do not get any crashes on my setup which uses fewer gadget
functions. That's why I asked what happens if the functions load order
is changed. I am afraid this thread is so complex that the actual
problem has been burried in the history.
As I pointed out previously, the crash is probably because of f_uac2
prematurely freeing feedback request before its completion.
usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous
call so you didn't get a crash.
Again, I am not the author of the patches, my USB knowledge is way
unsufficient for that. I am trying to make them work as they are
important and make the existing audio gadget actually usable.
I'm not sure how easy it is for you to obtain/test a device with dwc3,
but it would be great to also have it as part of your testing suite. :)
Thanks,
Thinh
From: Pavel Hofman <hidden> Date: 2021-08-24 05:39:48
Dne 24. 08. 21 v 0:50 Thinh Nguyen napsal(a):
Pavel Hofman wrote:
quoted
Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a):
quoted
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman
[off-list ref] wrote:
quoted
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than
dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
Sure, no problem with reverting. I am just trying to start up some
troubleshooting. A resource exhaustion was mentioned here, that's why I
suggested a way to test the patch with the original number of endpoints
allocated. I do not get any crashes on my setup which uses fewer gadget
functions. That's why I asked what happens if the functions load order
is changed. I am afraid this thread is so complex that the actual
problem has been burried in the history.
As I pointed out previously, the crash is probably because of f_uac2
prematurely freeing feedback request before its completion.
usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous
call so you didn't get a crash.
Thanks for your hint, it greatly helps.
quoted
I'm not sure how easy it is for you to obtain/test a device with dwc3,
but it would be great to also have it as part of your testing suite. :)
Can you recommend a reasonably priced device with viable kernel updates
for the testing? Optionally with SS which you mentioned last time? Thanks.
Best regards,
Pavel.
On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman
[off-list ref] wrote:
quoted
Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 23:04 schreef Pavel Hofman:
quoted
Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a):
quoted
Op 19-08-2021 om 09:51 schreef Pavel Hofman:
quoted
Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a):
quoted
Op 18-08-2021 om 00:00 schreef Ferry Toth:
...
quoted
quoted
quoted
quoted
quoted
quoted
So, where do we go from here?
I know the patches have been tested on dwc2 (by me and
others). I
do not know if Ruslan or Jerome tested them on dwc3 but probably
not. Ruslan has talked about RPi (my case too) and
BeagleboneBlack,
both with dwc2. Perhaps the dwc2 behaves a bit differently than
dwc3?
The patches add a new EP-IN for async feedback. I am sorry I have
not followed your long thread (it started as unrelated to
uac). Does
the problem appear with f_uac1 or f_uac2? Please how have you
reached the above problem?
I'm sorry too. I first believed the issue was related to the patch
mentioned in the subject line.
The problem appaers with f_uac2. I bost Edison_Arduino board in
host
mode (there is a switch allowing to select host/device mode). When
flipping the switch to device mode udev run a script:
But as I am using configfs (excerpt follows) and just disabling
the
last 2 line resolves the issue, I'm guessing uac2 is the issue. Or
exceeding the available resources.
# Create directory structure
mkdir "${GADGET_BASE_DIR}"
cd "${GADGET_BASE_DIR}"
mkdir -p configs/c.1/strings/0x409
mkdir -p strings/0x409
# Serial device
mkdir functions/gser.usb0
ln -s functions/gser.usb0 configs/c.1/
###
# Ethernet device
mkdir functions/eem.usb0
echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr
echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr
ln -s functions/eem.usb0 configs/c.1/
# Mass Storage device
mkdir functions/mass_storage.usb0
echo 1 > functions/mass_storage.usb0/stall
echo 0 > functions/mass_storage.usb0/lun.0/cdrom
echo 0 > functions/mass_storage.usb0/lun.0/ro
echo 0 > functions/mass_storage.usb0/lun.0/nofua
echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file
ln -s functions/mass_storage.usb0 configs/c.1/
# UAC2 device
mkdir functions/uac2.usb0
ln -s functions/uac2.usb0 configs/c.1
....
Kernel shouldn't crash with any available set of configuration
parameters, right? So, even if the parameter would fix the crash the
series is buggy and has to be reverted in my opinion.
Sure, no problem with reverting. I am just trying to start up some
troubleshooting. A resource exhaustion was mentioned here, that's why I
suggested a way to test the patch with the original number of endpoints
allocated. I do not get any crashes on my setup which uses fewer gadget
functions. That's why I asked what happens if the functions load order
is changed. I am afraid this thread is so complex that the actual
problem has been burried in the history.
As I pointed out previously, the crash is probably because of f_uac2
prematurely freeing feedback request before its completion.
usb_ep_dequeue() is asynchronous. dwc2() may treat it as a synchronous
call so you didn't get a crash.
Thanks for your hint, it greatly helps.
quoted
quoted
I'm not sure how easy it is for you to obtain/test a device with dwc3,
but it would be great to also have it as part of your testing suite. :)
Can you recommend a reasonably priced device with viable kernel
updates for the testing? Optionally with SS which you mentioned last
time? Thanks.
Edison-Arduino kit 2nd hand with display on ebay ~$100 :-)