Re: Panic with wifi + usb in latest FreeBSD-current

2020-09-13 Thread Adrian Chadd
On Sun, 13 Sep 2020 at 22:34, Warner Losh wrote: > > > On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd > wrote: > >> Yeah, this was also reported in #freebsd-wireless today. >> >> Is there a lock being held in the rtwn path that shouldn't be? >> > > I'll check in the morning... this was like the 20t

Re: Panic with wifi + usb in latest FreeBSD-current

2020-09-13 Thread Warner Losh
On Sun, Sep 13, 2020, 11:29 PM Adrian Chadd wrote: > Yeah, this was also reported in #freebsd-wireless today. > > Is there a lock being held in the rtwn path that shouldn't be? > I'll check in the morning... this was like the 20th thing to go wrong this weekend, so I copied the panic down, send

Re: Panic with wifi + usb in latest FreeBSD-current

2020-09-13 Thread Adrian Chadd
Yeah, this was also reported in #freebsd-wireless today. Is there a lock being held in the rtwn path that shouldn't be? -adrian On Sun, 13 Sep 2020 at 21:30, Warner Losh wrote: > I'm running current as of -2h ago. > > When I plug in my rtwn0 device and it configures, etc, I get: > > rtwn0 o

Panic with wifi + usb in latest FreeBSD-current

2020-09-13 Thread Warner Losh
I'm running current as of -2h ago. When I plug in my rtwn0 device and it configures, etc, I get: rtwn0 on uhub 0 rtwn0: on usbus0 rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R host dpa_supplicant[1619]: ioctl[SIOS80211, op=20, val=0, arg_len=7]: Invalid argument panic: sleepq_add: td to sleep on wcha

Re: compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

2020-09-13 Thread Dimitry Andric
On 12 Sep 2020, at 23:00, Ronald Klop wrote: > > On Sat, 12 Sep 2020 18:28:03 +0200, Dimitry Andric wrote: >> On 12 Sep 2020, at 17:43, Ronald Klop wrote: >>> >>> Because I'm tired of hours of compilation of llvm/clang I'm testing >>> compiling FreeBSD with llvm11 from a pkg. ... It is during

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky
On 2020-09-13 16:13, Graham Perrin wrote: pcm3: (rec) pcm4: (play/rec) Or: -R /dev/dsp4 -P /dev/dsp4 -f /dev/dsp4 You can also add these parameters run-time via the GUI for virtual_oss. --HPS ___ freebsd-current@freebsd.org mailing list https://

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky
On 2020-09-13 16:13, Graham Perrin wrote:   -f /dev/dsp0 \ Try: -f /dev/dsp3 --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Graham Perrin
Now with On 13/09/2020 10:24, Hans Petter Selasky wrote: On 2020-09-13 11:21, Graham Perrin wrote: 1. Chromium simply does not play AV content e.g. – after a click to play, there's a moment of visual motion but no playback 2.

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Samy Mahmoudi
Hi, If reducing the audio buffer size in virtual_oss does not solve the issue and you temporarily resort to use PulseAudio to achieve switching devices on-the-fly (which does work very well with PulseAudio), you could indeed 'keep the devices connected' and use a variant of the following script:

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Tomasz CEDRO
I am using EMU10K1 attached to the sound system over USB on my laptop and the device needs to be connected on boot - unplug will crash the system. If device is plugged in on boot and I add `hw.snd.default_unit=3` to `/etc/sysctl.conf`, that is before I start X, then I have audio playback "by defau

Re: USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Hans Petter Selasky
On 2020-09-13 11:21, Graham Perrin wrote: 1. Chromium simply does not play AV content e.g. – after a click to play, there's a moment of visual motion but no playback 2. if Firefox media.cubeb.backend set to oss then behaviour is

USB sound devices with FreeBSD-CURRENT

2020-09-13 Thread Graham Perrin
I'm confused about use of USB devices for audio (primarily with Firefox and Chromium). Re: under 'switching dsp-devices on-the-fly' > … hw.snd.default_unit to "0", which will automatically assign > hw.sn