Re: svn commit: r359446 - head/sys/dev/sound/usb

[Alexander Leidinger via freebsd-usb]

Quoting Hans Petter Selasky  (from Tue, 31 Mar  
2020 14:44:12 +0200):



On 2020-03-31 14:35, Alexander Leidinger via freebsd-usb wrote:
Quoting Hans Petter Selasky  (from Mon, 30  
Mar 2020 16:50:33 + (UTC)):



Author: hselasky
Date: Mon Mar 30 16:50:32 2020
New Revision: 359446
URL: https://svnweb.freebsd.org/changeset/base/359446

Log:
  Add support for multiple playback and recording devices per  
physical USB audio
  device. This requires some structural refactoring inside the  
driver, mostly

  about converting existing audio channel structures into arrays.

  The main audio mixer is provided by the first PCM instance.
  The non-first audio instances may only have a software mixer for  
PCM playback.


Have you thought about providing different pcm devices per physical  
USB audio device for the functionality of dev.pcm.X.Y.vchanformat /  
vchanrate? Incompatible configs between those devices could be  
prevented at runtime via setting all the incompatible devices per  
physical device to return EBUSY or such while one of the group is  
open / in use. /dev/sndstat could also contain some kind of status  
to this effect and to which group of pcm devices pcmX belongs.




Hi,

There will be two pcm devices, belonging to the same uaudioX device  
having each their independent sysctl tree. So you get:


/dev/dsp0
/dev/mixer0
/dev/dsp1
/dev/mixer1

mixer1 only controls dsp1, and mixer0 only controls dsp0, while it  
may be the same physical USB audio device.


Was this your question?


I have this:
uaudio0: addr 3> on usbus8

uaudio0: Play: 48000 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 44100 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.

It has dev.pcm.0.play.vchanformat=48000 per default. If I want to  
switch this, I need to issue a sysctl (= root permission).


My question was to change the code to not need this sysctl anymore,  
but to generate a /dev/dspX for each of the possibilities the hardware  
supports. And if one dsp device is open, the other could by set into  
busy state so that it can not be opened until the first dsp device is  
closed. This way I only need user permissions to the dsp device to be  
able to select what I want (what I want may need a lookup of me to  
/dev/sndstat to find out which device would be the one for bit-perfect  
playing (even if vchans are enabled) instead of resampling inside the  
kernel).


Similar for e.g. vchanformat=s16le:5.1 or other formats which the  
hardware supports. Instead of requiring root access to do the sysctl,  
simply chosing the right pcm device would only need user permissions  
on the dev entry. BTW: how to find out what the hardware supports in  
this regard. The above dmesg snippd suggests the hardware is able to  
do s16le:2.0 or s16le:4.0, but not s16le:5.1 (but the device has  
connectors for a 7.1 setup - I haven't tried it, I have it connected  
via SPDIF).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpbgf8KdrndR.pgp
Description: Digitale PGP-Signatur

Re: svn commit: r359446 - head/sys/dev/sound/usb

[Alexander Leidinger via freebsd-usb]

Quoting Hans Petter Selasky  (from Mon, 30 Mar  
2020 16:50:33 + (UTC)):



Author: hselasky
Date: Mon Mar 30 16:50:32 2020
New Revision: 359446
URL: https://svnweb.freebsd.org/changeset/base/359446

Log:
  Add support for multiple playback and recording devices per  
physical USB audio

  device. This requires some structural refactoring inside the driver, mostly
  about converting existing audio channel structures into arrays.

  The main audio mixer is provided by the first PCM instance.
  The non-first audio instances may only have a software mixer for  
PCM playback.


Have you thought about providing different pcm devices per physical  
USB audio device for the functionality of dev.pcm.X.Y.vchanformat /  
vchanrate? Incompatible configs between those devices could be  
prevented at runtime via setting all the incompatible devices per  
physical device to return EBUSY or such while one of the group is open  
/ in use. /dev/sndstat could also contain some kind of status to this  
effect and to which group of pcm devices pcmX belongs.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpqEHA4sJ76J.pgp
Description: Digitale PGP-Signatur

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Gary Jennejohn <gljennj...@gmail.com> (from Wed, 11 Oct 2017  
06:07:34 +0200):



On Tue, 10 Oct 2017 20:14:37 +0200
Alexander Leidinger <alexan...@leidinger.net> wrote:

Quoting Hans Petter Selasky <h...@selasky.org> (from Mon, 9 Oct 2017  
22:38:32 +0200):


> On 10/09/17 21:47, Alexander Leidinger wrote:
>>> If you are using multi channel audio equipment with 24-bits,  
try >>> to avoid FULL-speed ones!


I have now tried every single USB connector, external and internal.  
None of them attaches to the EHCI bus. :( The only connector which  
Iwas not able to test is labeled "USB SSD" and has a smaller  
pin-gridthan those other internal usb-PIN-connectors with cables to  
the frontof the case.


I think I will now buy a PCIe USB3.0 card. Anything I should avoid?  
Anything you recommend? I found this:
 
www.amazon.de/CSL-Express-Controller-SATA-Stromanschluss-Schnittstellenkart

e/dp/B00OBACW0G
which seems to have some VLI chip on it. I haven't found anything  
usable in terms of vendor/product ID or such.
4 ports may be enough, for an external USB backup HD, the  
soundcard, and a video device, but for ~10 EUR difference...




I've been using the CSL B00F9XGPTI XHCI 4-port card which works.  I
bought it on amazon.de, but I don't know whether it's still available.


I bought the one I had listed. Works. I did a short Amazon review  
which mentions FreeBSD.


>> Well... first I want to get the 2 channel 16bit case working...  
>> then I will have a look at extending this to 5.1 (most probably  
>> 16bit, that's enough to watch action movies).

>
> Hi,
>
> Some more ideas:
>
> 2 channel 16 bit will only work if you turn off bitperfect. The

I activated bitperfect as a test because I got the distortion and  
was hoping to either gain some lower-latency or at least get rid of  
somelayers of code to rule out issues there.


> lowest number of channels the device exports is 4 for playback.  
That> means the kernel will re-format 2 channels to 4 channels  
always and> that is done by the PCM feeder. You'll need to check  
that there is a> filter which handle that.

>
> You might want to install virtual_oss from ports to handle this >  
device properly.


In the end I want 5.1 output, so if the bus speed doesn't give me  
this: no need to waste our time with the slow ports.


It looks like this now (here the second uaudio device is attached):
---snip---
ugen8.1: <0x1106 XHCI root HUB> at usbus8, cfg=0 md=HOST spd=SUPER  
(5.0Gbps) pwr=SAVE (0mA)
ugen8.2:  at usbus8, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE (100mA)
ugen8.3:  at usbus8, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE (0mA)
ugen8.4:  at usbus8, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=ON (500mA)
ugen8.5:  at usbus8, cfg=0 md=HOST  
spd=SUPER (5.0Gbps) pwr=SAVE (0mA)

---snip---

What I don't understand is it tells spd=FULL, so the device is not  
doing faster as it theoretically can do on the mainboard-usb device.  
Why does it work better (no audio distortion when connected to the  
xhci device)?


I also tried 5.1 output (data goes via optical connection to the pre-amp/DAC).
dev.pcm.2.bitperfect: 0
dev.pcm.2.buffersize: 0
dev.pcm.2.rec.vchanformat: s16le:2.0
dev.pcm.2.rec.vchanrate: 48000
dev.pcm.2.rec.vchanmode: fixed
dev.pcm.2.rec.vchans: 1
dev.pcm.2.play.vchanformat: s16le:5.1
dev.pcm.2.play.vchanrate: 48000
dev.pcm.2.play.vchanmode: passthrough
dev.pcm.2.play.vchans: 1

Audio comes out of all 5 speakers, but somehow I have the impression I  
get the same output everywhere... I need to download a 5.1 test and  
see. But this is another issue now.


Thanks!
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpuT7aQUMSTK.pgp
Description: Digitale PGP-Signatur

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Hans Petter Selasky <h...@selasky.org> (from Mon, 9 Oct 2017  
22:38:32 +0200):



On 10/09/17 21:47, Alexander Leidinger wrote:
If you are using multi channel audio equipment with 24-bits, try  
to avoid FULL-speed ones!


I have now tried every single USB connector, external and internal.  
None of them attaches to the EHCI bus. :( The only connector which I  
was not able to test is labeled "USB SSD" and has a smaller pin-grid  
than those other internal usb-PIN-connectors with cables to the front  
of the case.


I think I will now buy a PCIe USB3.0 card. Anything I should avoid?  
Anything you recommend? I found this:

www.amazon.de/CSL-Express-Controller-SATA-Stromanschluss-Schnittstellenkarte/dp/B00OBACW0G
which seems to have some VLI chip on it. I haven't found anything  
usable in terms of vendor/product ID or such.
4 ports may be enough, for an external USB backup HD, the soundcard,  
and a video device, but for ~10 EUR difference...


Well... first I want to get the 2 channel 16bit case working...  
then I will have a look at extending this to 5.1 (most probably  
16bit, that's enough to watch action movies).


Hi,

Some more ideas:

2 channel 16 bit will only work if you turn off bitperfect. The


I activated bitperfect as a test because I got the distortion and was  
hoping to either gain some lower-latency or at least get rid of some  
layers of code to rule out issues there.


lowest number of channels the device exports is 4 for playback. That  
means the kernel will re-format 2 channels to 4 channels always and  
that is done by the PCM feeder. You'll need to check that there is a  
filter which handle that.


You might want to install virtual_oss from ports to handle this  
device properly.


In the end I want 5.1 output, so if the bus speed doesn't give me  
this: no need to waste our time with the slow ports.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpm2nFXm_nZT.pgp
Description: Digitale PGP-Signatur

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Hans Petter Selasky <h...@selasky.org> (from Mon, 9 Oct 2017  
21:28:08 +0200):



On 10/09/17 21:05, Alexander Leidinger wrote:
Quoting Hans Petter Selasky <h...@selasky.org> (from Sun, 8 Oct 2017  
23:44:27 +0200):



Can you trace that with:

usbdump -i usbusX -f Y -v

?

What rates are supported. Can you try 48000 Hz?


44100 and 48000. The attached usbdumps are with 48000 Hz. The "1"  
is with 32bit audio output, the "2" with 16bit audio output.


This is what is reported in dmesg:
---snip---
uaudio0 on uhub3
uaudio0: rev 1.10/1.00, addr 2> on usbus5

uaudio0: Play: 48000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 44100 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.
pcm2:  on uaudio0
uaudio0: No HID volume keys found.
---snip---

As this is a 5.1 device, I would expect 6 channels, not 4 (the  
config descriptor dump is in my initial mail).




Hi,

Is this device connected directly to the computer or via a USB HUB?


Directly, see below for more info.


Can you show all USB devices on this computer?


# usbconfig
ugen6.1:  at usbus6, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen3.1:  at usbus3, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE (0mA)
ugen1.1:  at usbus1, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen4.1:  at usbus4, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen7.1:  at usbus7, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE (0mA)
ugen0.1:  at usbus0, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen5.1:  at usbus5, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen2.1:  at usbus2, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=SAVE (0mA)
ugen1.2:  at usbus1, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=SAVE (100mA)
ugen2.2:  at  
usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA)
ugen1.3:  at usbus1, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=ON (98mA)
ugen1.4:  at usbus1, cfg=0 md=HOST  
spd=FULL (12Mbps) pwr=ON (98mA)
ugen5.2:  at usbus5,  
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (308mA)



I suspect your device is connected via USB High-speed HUB and I  
think the payload per millisecond is a bit too much for the  
so-called High-Speed to Full-Speed transaction translator  
configuration FreeBSD is using. You need to connect the device  
directly to an XHCI, UHCI or OHCI controller for it work properly.


The uaudio device is attached directly to the USB connectors of the  
case. The connectors of the case are directly connected to the PINs on  
the mainboard. So this means the mainboard "exports" more FULL speed  
ports than HIGH speed ports and I just have to find the right  
connector and it will work much better?


I will search the connectors for ugen3 and ugen7 tomorrow and report  
back how it works (and maybe look again at the issue I had changing  
the number of channels...).


If you are using multi channel audio equipment with 24-bits, try to  
avoid FULL-speed ones!


Well... first I want to get the 2 channel 16bit case working... then I  
will have a look at extending this to 5.1 (most probably 16bit, that's  
enough to watch action movies).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpFH0Z99enIC.pgp
Description: Digitale PGP-Signatur

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Hans Petter Selasky  (from Sun, 8 Oct 2017  
23:44:27 +0200):



Can you trace that with:

usbdump -i usbusX -f Y -v

?

What rates are supported. Can you try 48000 Hz?


44100 and 48000. The attached usbdumps are with 48000 Hz. The "1" is  
with 32bit audio output, the "2" with 16bit audio output.


This is what is reported in dmesg:
---snip---
uaudio0 on uhub3
uaudio0: 1.10/1.00, addr 2> on usbus5

uaudio0: Play: 48000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 44100 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.
pcm2:  on uaudio0
uaudio0: No HID volume keys found.
---snip---

As this is a 5.1 device, I would expect 6 channels, not 4 (the config  
descriptor dump is in my initial mail).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpabuGA6OGHA.pgp
Description: Digitale PGP-Signatur

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Hans Petter Selasky <h...@selasky.org> (from Sun, 8 Oct 2017  
17:28:25 +0200):



On 10/08/17 14:25, Alexander Leidinger wrote:


Quoting Hans Petter Selasky <h...@selasky.org> (from Sun, 8 Oct 2017  
13:19:19 +0200):



On 10/08/17 12:56, Alexander Leidinger wrote:


Hi,

attached are the config descriptors and the device dump of two  
uaudio devices. Both exhibit distorted audio output. It sounds a  
little bit like clipping / not feeding enough samples fast  
enough...


I played around with dev.pcm.2.bitperfect=1,  
dev.pcm.2.play.vchans=0, dev.pcm.2.play.vchanrate and  
hw.snd.latency=1...10.


At some point vchanrate doesn't work anymore, it always stays at  
4.0 audio, even when trying to go back to 2.0. I have to  
usbconfig reset the device.


Sometimes (rarely) when playing around I get clear audio output,  
but when I try to reproduce it (going back to default value for  
the last sysctl setting and then going back again to the same  
setting again), the audio is distorted again.


To me it sounds like some kind of buffer is not big enough or the  
data is not delivered fast enough to the uaudio device. But this  
is a dual-socket system with:
    CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz  
(2133.36-MHz K8-class CPU)

    FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
    FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 hardware threads
And while playing around with uaudio the system has a load of  
around 1, so I would expect CPU/RAM is not an issue here.


Hi,

What version of FreeBSD is this?


current as of r323636


Try to enable hw.usb.uaudio.debug=16 during playback.


No such sysctl, only hw.usb.debug
I did the hw.usb.debug=16, but no output in dmesg nor  
/var/log/console.log nor /var/log/messages, where do I need to look?


Bye,
Alexander.



Can you compile and install snd_uaudio module with  
DEBUG_FLAGS="-DUSB_DEBUG" and KMODDIR=/boot/kernel ?


Occasionally I get this while playing:
---snip---
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: short transfer, 3680 of 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: short transfer, 3360 of 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: short transfer, 4224 of 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: short transfer, 4096 of 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
uaudio_chan_play_callback: transferring 4608 bytes
---snip---

The first number on the short transfer varies:
---snip---
# dmesg |grep "transferring 4608 bytes" | wc -l
2738

# dmesg |grep "short transfer" | wc -l
 124

# dmesg |grep "short transfer" | sort | uniq -c
   1 uaudio_chan_play_callback: short transfer, 2176 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 2528 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 2624 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 2848 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 2976 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3008 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3040 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3104 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3136 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3168 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3264 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3296 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3328 of 4608 bytes
   4 uaudio_chan_play_callback: short transfer, 3360 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3424 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3456 of 4608 bytes
   1 uaudio_chan_play_callback: short transfer, 3520 of 4608 bytes
   4 uaudio_chan_play_callback: short transfer, 3552 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3584 of 4608 bytes
   2 uaudio_chan_play_callback: short transfer, 3616 of 4608 bytes
   4 uaudio_chan_play_callback: short transfer, 3648 of 4608 bytes
   2 uaudio_ch

Re: uaudio - distorted output

[Alexander Leidinger]

Quoting Hans Petter Selasky <h...@selasky.org> (from Sun, 8 Oct 2017  
13:19:19 +0200):



On 10/08/17 12:56, Alexander Leidinger wrote:


Hi,

attached are the config descriptors and the device dump of two  
uaudio devices. Both exhibit distorted audio output. It sounds a  
little bit like clipping / not feeding enough samples fast enough...


I played around with dev.pcm.2.bitperfect=1,  
dev.pcm.2.play.vchans=0, dev.pcm.2.play.vchanrate and  
hw.snd.latency=1...10.


At some point vchanrate doesn't work anymore, it always stays at  
4.0 audio, even when trying to go back to 2.0. I have to usbconfig  
reset the device.


Sometimes (rarely) when playing around I get clear audio output,  
but when I try to reproduce it (going back to default value for the  
last sysctl setting and then going back again to the same setting  
again), the audio is distorted again.


To me it sounds like some kind of buffer is not big enough or the  
data is not delivered fast enough to the uaudio device. But this is  
a dual-socket system with:
    CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz  
(2133.36-MHz K8-class CPU)

    FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
    FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 hardware threads
And while playing around with uaudio the system has a load of  
around 1, so I would expect CPU/RAM is not an issue here.


Hi,

What version of FreeBSD is this?


current as of r323636


Try to enable hw.usb.uaudio.debug=16 during playback.


No such sysctl, only hw.usb.debug
I did the hw.usb.debug=16, but no output in dmesg nor  
/var/log/console.log nor /var/log/messages, where do I need to look?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpWOM__J9anr.pgp
Description: Digitale PGP-Signatur

uaudio - distorted output

[Alexander Leidinger]

Hi,

attached are the config descriptors and the device dump of two uaudio  
devices. Both exhibit distorted audio output. It sounds a little bit  
like clipping / not feeding enough samples fast enough...


I played around with dev.pcm.2.bitperfect=1, dev.pcm.2.play.vchans=0,  
dev.pcm.2.play.vchanrate and hw.snd.latency=1...10.


At some point vchanrate doesn't work anymore, it always stays at 4.0  
audio, even when trying to go back to 2.0. I have to usbconfig reset  
the device.


Sometimes (rarely) when playing around I get clear audio output, but  
when I try to reproduce it (going back to default value for the last  
sysctl setting and then going back again to the same setting again),  
the audio is distorted again.


To me it sounds like some kind of buffer is not big enough or the data  
is not delivered fast enough to the uaudio device. But this is a  
dual-socket system with:
CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2133.36-MHz  
K8-class CPU)

FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 hardware threads
And while playing around with uaudio the system has a load of around  
1, so I would expect CPU/RAM is not an issue here.


I would expect that just attaching an uaudio device like those and  
using madplay/mpg123 would just work (not looking at digital output  
and 5.1/7.1 output for video, just the basics like stereo output of  
MP3). So either I do something fundamentally wrong and would need a  
hint with the cluebat, or I would need some description how to debug  
this further from the USB side...


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
ugen5.2:  at usbus5, cfg=0 md=HOST 
spd=FULL (12Mbps) pwr=ON (308mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x041e 
  idProduct = 0x3040 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001 

ugen5.2:  at usbus5, cfg=0 md=HOST 
spd=FULL (12Mbps) pwr=ON (308mA)


 Configuration index 0

bLength = 0x0009 
bDescriptorType = 0x0002 
wTotalLength = 0x03d3 
bNumInterfaces = 0x0003 
bConfigurationValue = 0x0001 
iConfiguration = 0x  
bmAttributes = 0x0080 
bMaxPower = 0x009a 

Interface 0
  bLength = 0x0009 
  bDescriptorType = 0x0004 
  bInterfaceNumber = 0x 
  bAlternateSetting = 0x 
  bNumEndpoints = 0x0001 
  bInterfaceClass = 0x0001  
  bInterfaceSubClass = 0x0001 
  bInterfaceProtocol = 0x 
  iInterface = 0x  

  Additional Descriptor

  bLength = 0x0a
  bDescriptorType = 0x24
  bDescriptorSubType = 0x01
   RAW dump: 
   0x00 | 0x0a, 0x24, 0x01, 0x00, 0x01, 0x4c, 0x00, 0x02, 
   0x08 | 0x01, 0x02


  Additional Descriptor

  bLength = 0x0c
  bDescriptorType = 0x24
  bDescriptorSubType = 0x02
   RAW dump: 
   0x00 | 0x0c, 0x24, 0x02, 0x01, 0x01, 0x01, 0x00, 0x06, 
   0x08 | 0x3f, 0x00, 0x00, 0x00


  Additional Descriptor

  bLength = 0x0e
  bDescriptorType = 0x24
  bDescriptorSubType = 0x06
   RAW dump: 
   0x00 | 0x0e, 0x24, 0x06, 0x02, 0x01, 0x01, 0x03, 0x00, 
   0x08 | 0x00, 0x00, 0x00, 0x00, 0x00, 0x00


  Additional Descriptor

  bLength = 0x09
  bDescriptorType = 0x24
  bDescriptorSubType = 0x03
   RAW dump: 
   0x00 | 0x09, 0x24, 0x03, 0x03, 0x01, 0x03, 0x00, 0x02, 
   0x08 | 0x00

  Additional Descriptor

  bLength = 0x0c
  bDescriptorType = 0x24
  bDescriptorSubType = 0x02
   RAW dump: 
   0x00 | 0x0c, 0x24, 0x02, 0x04, 0x03, 0x06, 0x00, 0x02, 
   0x08 | 0x03, 0x00, 0x00, 0x00


  Additional Descriptor

  bLength = 0x0a
  bDescriptorType = 0x24
  bDescriptorSubType = 0x06
   RAW dump: 
   0x00 | 0x0a, 0x24, 0x06, 0x05, 0x04, 0x01, 0x02, 0x00, 
   0x08 | 0x00, 0x00


  Additional Descriptor

  bLength = 0x09
  bDescriptorType = 0x24
  bDescriptorSubType = 0x03
   RAW dump: 
   0x00 | 0x09, 0x24, 0x03, 0x06, 0x01, 0x01, 0x00, 0x05, 
   0x08 | 0x00

 Endpoint 0
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0083  
bmAttributes = 0x0003  
wMaxPacketSize = 0x0008 
bInterval = 0x000a 
bRefresh = 0x 
bSynchAddress = 0x 


Interface 1
  bLength = 0x0009 
  bDescriptorType = 0x0004 
  bInterfaceNumber = 0x0001 
  bAlternateSetting = 0x 
  bNumEndpoints = 0x 
  bInterfaceClass = 0x0001  
  bInterfaceSubClass = 0x0002 
  bInterfaceProtocol = 0x 
  iInterface = 0x  


Interface 1 Alt 1
  bLength = 

Re: GnuPG && card readers

[Alexander Leidinger]

Quoting Matthias Apitz  (from Tue, 9 May 2017  
11:47:29 +0200):



Hello,

The GnuPG project has a list of supported (USB) card readers:

https://gnupg.org/howtos/card-howto/en/smartcard-howto-single.html#id2503342

Any comments or experiences about which of them are supported in  
FreeBSD 12-C?

Best would be the smallest one to carry it all day in the bag.


It's not FreeBSD which needs the support. gnupg comes with the  
drivers, FreeBSD only needs to see "a device on the bus", that's enough.


Check out the ports security/opensc amd devel/libccid (and gnupg needs  
to be build with the SCDAEMON option of the port). This will bring in  
the pcsc-lite port as a depedency. Those are the "drivers" for USB  
card readers if you want to use them beyond what gnupg will do.


You need to pay attention that the card reader support "extended  
APDUs" (or support for digital signatures, which is more likely to be  
announced in marketing material from the vendor). It may be OK without  
extended APDUs if you only use OpenPGP v2 cards and generate the  
keys/certs on the card itself, but if you want to go for bigger keys  
than documented to work on the cards (I was able to put 4k-keys on the  
OpenPGP v2 cards) the extended APDUs are needed. If the reader is CCID  
compatible, the libccid driver will probably work. You can use the  
opensc and pcsc-lite tools to transfer certs to the card which you  
created with openssl (e.g. 4k keys).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpK4xoerpunU.pgp
Description: Digitale PGP-Signatur

Question about usb audio device - how to select output connector

[Alexander Leidinger]

Hi,

I had a look at snd_uaudio and there I don't find the info I look for.

What I want to do is to have 6 chanel (5.1) SPDIF output. What I don't  
understand is how to select the connectors. To my understanding the  
soundsystem only sees a line out and a line in, but not all the other  
connectors. Looking at the output of sysctl (dev.pcm, dev.uaudio and  
hw.snd) doesn't give me a hint either.


What I have:
---snip---
ugen5.2:  at usbus5
uaudio0 on uhub4
uaudio0: 1.10/1.00, addr 2> on usbus5

uaudio0: Play: 48000 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 44100 Hz, 4 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.
pcm5:  on uaudio0
uaudio0: No HID volume keys found.
---snip---

What the sound subsystem sees:
---snip---
# cat /dev/sndstat
FreeBSD Audio Driver (64bit 2009061500/amd64)
Installed devices:
pcm0:  on hdaa0 kld snd_hda  
(1p:1v/1r:1v) default

snddev flags=0x2e6
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags  
0x2100, 0x0004
interrupts 62, underruns 0, feed 62, ready 0  
[b:4096/2048/2|bs:4096/2048/2]

channel flags=0x2100
{userland} -> feeder_mixer(0x00200010) -> {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000,  
fmt 0x00201000/0x00200010, flags 0x1000, 0x002b

interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:131072/4096/32]
channel flags=0x1000
{userland} -> feeder_root(0x00201000) ->  
feeder_format(0x00201000 -> 0x00200010) -> feeder_volume(0x00200010)  
-> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware}
[pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags  
0x2100, 0x0005
interrupts 0, overruns 0, feed 0, hfree 4096, sfree 4096  
[b:4096/2048/2|bs:4096/2048/2]

channel flags=0x2100
{hardware} -> feeder_root(0x00200010) ->  
feeder_mixer(0x00200010) -> {userland}
pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt  
0x0018, flags 0x1000, 0x

interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000
{hardware} -> feeder_root(0x) -> {userland}
pcm1:  on hdaa0 kld snd_hda (1p:1v/2r:1v)
snddev flags=0x2e6
[pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags  
0x2100, 0x0004
interrupts 128, underruns 0, feed 128, ready 0  
[b:4096/2048/2|bs:4096/2048/2]

channel flags=0x2100
{userland} -> feeder_mixer(0x00200010) -> {hardware}
pcm1:play:dsp1.p0[pcm1:virtual:dsp1.vp0]: spd 22050/48000,  
fmt 0x00201000/0x00200010, flags 0x1000, 0x002b

interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:65536/2048/32]
channel flags=0x1000
{userland} -> feeder_root(0x00201000) ->  
feeder_format(0x00201000 -> 0x00200010) -> feeder_volume(0x00200010)  
-> feeder_rate(0x00200010 q:1 22050 -> 48000) -> {hardware}
[pcm1:record:dsp1.r0]: spd 48000, fmt 0x00200010, flags  
0x2100, 0x0005
interrupts 0, overruns 0, feed 0, hfree 4096, sfree 4096  
[b:4096/2048/2|bs:4096/2048/2]

channel flags=0x2100
{hardware} -> feeder_root(0x00200010) ->  
feeder_mixer(0x00200010) -> {userland}
[pcm1:record:dsp1.r1]: spd 8000, fmt 0x0018, flags  
0x, 0x
interrupts 0, overruns 0, feed 0, hfree 65536, sfree 0  
[b:65536/32768/2|bs:0/0/0]

channel flags=0x0
{hardware} -> feeder_root(0x) -> {userland}
pcm1:record:dsp1.r0[pcm1:virtual:dsp1.vr0]: spd 8000, fmt  
0x0018, flags 0x1000, 0x

interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000
{hardware} -> feeder_root(0x) -> {userland}
pcm2:  on hdaa0 kld snd_hda (1p:1v/0r:0v)
snddev  
flags=0x2e7
[pcm2:play:dsp2.p0]: spd 48000, fmt 0x00200010, flags  
0x6100, 0x0004
interrupts 133, underruns 0, feed 133, ready 0  
[b:4096/2048/2|bs:4096/2048/2]

channel flags=0x6100
{userland} -> feeder_mixer(0x00200010) -> {hardware}
pcm2:play:dsp2.p0[pcm2:virtual:dsp2.vp0]: spd 22050/48000,  
fmt 0x00201000/0x00200010, flags 0x1000, 0x002b

interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:65536/2048/32]
channel flags=0x1000
{userland} -> feeder_root(0x00201000) ->  
feeder_format(0x00201000 -> 0x00200010) -> feeder_volume(0x00200010)  
-> 

Re: Reiner SCT RFID unknown device id?

[Alexander Leidinger]

On Sat, 22 Feb 2014 18:48:53 +0100
Julian H. Stacey j...@berklix.com wrote:

 Alexander Leidinger wrote:

  A port at
  http://www.leidinger.net/test/pcsc-cyberjack.tar.bz2
  
  I did this port not for the RFID reader, it's for another one. It
  may or may not work for you.
 
 Thanks Alexander !, I downloaded  installed on 9.2-RELEASE,

[...]

 I ran make package-recursive to make sure any dependencies are in
 place,  installed security/pcsc-tools

[...]

  vi Info.plist
VendorID .. 0x0c4b same as mine
ProductID does not include my 0x9102
do a quick hack in 3 blocks to add it.

It may not be supported... did you check how it is supported in linux?

 /usr/local/etc/rc.d/pcscd restart
  pcsc_scan
   Waiting for the first reader...^D
 
 Got to stop for now.  Am I on course please ?

From something I wanted to finish and publish a year ago but didn't
yet (the following is just a small excerpt):
---snip---
Then I installed security/opensc (smart card framework),
devel/libccid (card reader driver for the Aladdin eToken PRO 72k and
for my Cherry card reader), pcsc-cyberjack (a card reader driver for my
Reiner SCT cyberJack secoder card reader which I ported to FreeBSD
but which is not in the Ports Collection, as it does not support enough
features you expect from a card reader), security/engine_pkcs12 (a
plugin-in for OpenSSL so that it can talk directly with the smart card)
and security/gnupg with the custom config option SCDAEMON (Smartcard
daemon).

As a dependency the pcsc-lite port (smart card reader framework) is
installed, and the pkg-message tells to add some lines
to /etc/devd.conf when USB card readers shall be used (so watch out and
follow the instructions). As I am using the smart card in a jail, I had
to modify those lines so that they execute the command inside the jail
(I prefixed the command with /usr/sbin/jexec jailname ).

For opensc the sample config file /usr/local/etc/openct.conf-sample has
to be copied to /usr/local/etc/openct.conf.
---snip---

The next thing in my what I did docs is the command which looks for
the openpgp card in the reader, so I don't have more. So check your
devd.conf for a suitable line for the pcsc-lite port.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Reiner SCT RFID unknown device id?

[Alexander Leidinger]

On Tue, 18 Feb 2014 22:16:17 +0100
Julian H. Stacey j...@berklix.com wrote:

 Hans Petter Selasky wrote:
  On 02/17/14 16:54, Mathias Picker wrote:
   I just found a used Reiner SCT RFID
   (http://www.reiner-sct.com/produkte/chipkartenleser/cyberJack_RFID_standard.html)
   and bought it, hoping I could get it to work in FreeBSD.

A port at
http://www.leidinger.net/test/pcsc-cyberjack.tar.bz2

I did this port not for the RFID reader, it's for another one. It may
or may not work for you.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?

[Alexander Leidinger]

On Fri, 10 May 2013 13:43:47 +0200
Uffe Jakobsen u...@uffe.org wrote:

 On 2013-05-10 12:11, Alexander Leidinger wrote:
 
  I worry about what is going on. We have something which is supposed
  to provide security as required, but is does not seem to work as
  described. We either need to fix the documentation, or a bug in the
  code. To do the later it needs to be debugged.
 
 
 It seems to me that you are struggeling with this - or a related -
 problem:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838

Indeed, this is the problem. I have all entries visible now. Anyone
interested to have this changed (as suggested by Andriy in the PR)
should voice his opinion. I voiced mine already.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

priv_check/make_dev/devfs.rules: What is preventing a device to show up in a jail?

[Alexander Leidinger]

Hi,

big picture: I want to get access to my USB DVB device in a jail. First
I explain what works (to show what I already know in this regard), then
I explain what doesn't work (where I seem to lack some knowledge).

What I did so far:
I already patched my kernel to give access to /dev/io and /dev/dri in a
jail to have X1 up and running in a jail (works since some years):
 - changed PRIV_DRIVER to PRIV_DRI_DRIVER (new in my kernel)
   for the priv_check() for /dev/dri
 - added cases PRIV_IO and PRIV_DRI_DRIVER to sys/kern/kern_jail.c
   which allow access if a specific allow.xxx flag is set for the jail
 - added the following lines to devfs.rules in a x11-jail specific
   section (plus some more devices):
---snip---
add path agpgart unhide
add path dri unhide
add path 'dri*' unhide
add path nvidiactl unhide
add path 'nvidia*' unhide
add path io unhide
add path mem unhide
---snip---

Patches at http://www.Leidinger.net/FreeBSD/current-patches/0_jail.diff

Result so far:
 - I see the io/mem/nvidia* devices (when I had a Radeon card which
   used /dev/dri, I was also seeing the devices in the /dev/dri/
   directory)
 - I have X11 running in a jail (some config stuff skipped in the
   above list).

My problem:
I try now to get the device nodes which are created by
multimedia/cuse4bsd-kmod + mltimedia/webcamd visible
in a jail, but they only show up in the jail-host, not in the jail
itself.

I patched the priv_check()s in cuse4bsd-kmod to use PRIV_DRI_DRIVER
(because it is already available in my kernel and allowed in the jail
where I test this; I expect this is necessary in case I want to run
webcamd in the jail instead on the host system) and have the following
entries in devfs.rules:
---snip---
[devfsrules_unhide_cuse=13]
add path cuse unhide
add path video unhide
add path 'video*' unhide
add path dvb unhide
add path 'dvb*' unhide
add path input unhide
add path 'input*' unhide
---snip---

I also tried with:
---snip---
add path 'dvb/*' unhide
add path 'dvb/adapter0/*' unhide
---snip---
(I was as desperate to even reboot the entire host system after
changing the rules to make sure I didn't forget to run something which
should be run before.)

When starting webcamd in the host system (to rule out some other
interactions if I would start it in the jail), i can see in the jail:
---snip---
/dev/cuse
/dev/dvb/
/dev/input/
/dev/input/event0
---snip---

In the host system I have additionally:
---snip---
/dev/dvb/adapter0/ca0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/frontend0
---snip---

I would expect to see at least the /dev/dvb/adapter0, if not all of
them in the jail itself.

Is there something to the devfs.rules syntax or priv_check() or
make_dev()/make_dev_cred() I don't know/understand which is involved
when subdirectories of subdirectories in /dev are involved?

How can I debug this (where to look, what to look for, ...)?

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Alexander Leidinger alexan...@leidinger.net (from Fri, 05  
Nov 2010 15:41:56 +0100):


I do not know yet if this is because of failed hardware, or because  
of a problem in the USB stack. As the first traces of this appeared  
after an update, I lean towards a regression...


I will have a look at getting some time to update the older FreeBSD  
9 system to something in between the working and not working version.


After a lot of testing with 2 machines I'm now at a state where I  
think the EHCI part of the mainboard is not far away of stopping  
working completely. So far the UHCI ports seem to still work correctly.


Does someone know if EHCI and UHCI in an ICH5 chipset are separate  
parts of the chip, or are they sharing common USB parts? Depending on  
the answer I should maybe raise the priority of the replacement of  
this...


Bye,
Alexander.

--
Q:  Have you heard about the man who didn't pay for his exorcism?
A:  He got re-possessed!

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov  
2010 10:36:41 +0100):



On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote:

Hi,

I have a memory stick which made problems (the stick is used as a ZFS
cache and it moaned about 8xxM write problems) in 9-current r214509. I
removed the device from the config, made a camcontrol reset all,
camcontrol rescan all (- device disappeared), and then tried an
usbconfig reset ugen4.2 (relevant devlist part from before the call is
below). The usbconfig reset does not return to the shell.

I do not know if the problem with the USB memory stick is related to
software or hardware. The stick survived just a weekend, I replaced it
because the old one showed similar problems after surviving about 9
months... I updated -current just before the problems appeared (and
then again after a week or two), but I do not remember from which
revision of -current I was updating from. I will try to stress-test
the memory sticks on a 8.1 system so see if it is some software problem.

The big question I have for now is: shouldn't there be some kind of
safety mechanism kicking in (timeout) with the usbconfig command (in
this case the reset)?

devlist:
---snip---
ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen4.2: Flash Disk USB 2.0 at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
---snip---

dmesg | grep -i usb:
---snip---
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xdc00-0xdc1f
irq 16 at device 29.0 on pci0
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe000-0xe01f
irq 19 at device 29.1 on pci0
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe400-0xe41f
irq 18 at device 29.2 on pci0
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xe800-0xe81f
irq 16 at device 29.3 on pci0
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xfe77fc00-0xfe77 irq 23 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
ugen0.1: Intel at usbus0
uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ugen1.1: Intel at usbus1
uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ugen2.1: Intel at usbus2
uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
ugen3.1: Intel at usbus3
uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3
ugen4.1: Intel at usbus4
uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
ugen4.2: USB 2.0 at usbus4
umass0: USB 2.0 Flash Disk, class 0/0, rev 2.00/1.00, addr 2 on usbus4
Root mount waiting for: usbus4
pass3: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
da0: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
Root mount waiting for: usbus4
ugen1.2: vendor 0x1941 at usbus1
ugen1.3: vendor 0x04f9 at usbus1
ulpt0: vendor 0x04f9 product 0x0100, class 0/0, rev 1.00/1.00, addr
3 on usbus1
ugen2.2: Logitech at usbus2
uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/49.00,
addr 2 on usbus2
ugen2.3: Logitech at usbus2
ukbd0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,
addr 3 on usbus2
ugen2.4: Logitech at usbus2
ums0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,
addr 4 on usbus2
---snip---


Hi,

If you dump all threads in this state I think you will see that USB  
is waiting

somewhere in umass_detach(), which is preventing the usbconfig reset from
grabbing the SX-lock associated with serialisation. Because umass_detach() is
not returning we are stuck.


I made some tests. I've used the initial stick in question on Solaris  
10u9 (no ZFS errors for several postmark runs) and FreeBSD 9 (r214509,  
own zpool with only the stick, one postmark run and I get I/O errors  
- any access to the stick hangs now due to 'failmode=wait').


On FreeBSD 9 as of r212247 I do not have problems with the second  
stick with which I experienced errors more quickly.


I do not know yet if this is because of failed hardware, or because of  
a problem in the USB stack. As the first traces of this appeared after  
an update, I lean towards a regression...


I will have a look at getting some time to update the older FreeBSD 9  
system to something in between the working and not working version.


Bye,
Alexander.

--
There must be at least 500,000,000 rats in the United
States; of course, I never heard the story before.

http://www.Leidinger.netAlexander

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Alexander Best arun...@freebsd.org (from Tue, 2 Nov 2010  
22:25:44 +):



i believe you're experiencing the same i issue i have [1].

cheers.
alex

[1] http://www.mail-archive.com/freebsd-usb@freebsd.org/msg07599.html


I don't think it is exactly the same, I was able to do top/ps/dmesg.

Bye,
Alexander.

--
I'm very old-fashioned.  I believe that people should marry for life,
like pigeons and Catholics.
-- Woody Allen

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Hi,

I have a memory stick which made problems (the stick is used as a ZFS  
cache and it moaned about 8xxM write problems) in 9-current r214509. I  
removed the device from the config, made a camcontrol reset all,  
camcontrol rescan all (- device disappeared), and then tried an  
usbconfig reset ugen4.2 (relevant devlist part from before the call is  
below). The usbconfig reset does not return to the shell.


I do not know if the problem with the USB memory stick is related to  
software or hardware. The stick survived just a weekend, I replaced it  
because the old one showed similar problems after surviving about 9  
months... I updated -current just before the problems appeared (and  
then again after a week or two), but I do not remember from which  
revision of -current I was updating from. I will try to stress-test  
the memory sticks on a 8.1 system so see if it is some software problem.


The big question I have for now is: shouldn't there be some kind of  
safety mechanism kicking in (timeout) with the usbconfig command (in  
this case the reset)?


devlist:
---snip---
ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE
ugen4.2: Flash Disk USB 2.0 at usbus4, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=ON

---snip---

dmesg | grep -i usb:
---snip---
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xdc00-0xdc1f  
irq 16 at device 29.0 on pci0

usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe000-0xe01f  
irq 19 at device 29.1 on pci0

usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe400-0xe41f  
irq 18 at device 29.2 on pci0

usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xe800-0xe81f  
irq 16 at device 29.3 on pci0

usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem  
0xfe77fc00-0xfe77 irq 23 at device 29.7 on pci0

usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
ugen0.1: Intel at usbus0
uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ugen1.1: Intel at usbus1
uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ugen2.1: Intel at usbus2
uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
ugen3.1: Intel at usbus3
uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3
ugen4.1: Intel at usbus4
uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
ugen4.2: USB 2.0 at usbus4
umass0: USB 2.0 Flash Disk, class 0/0, rev 2.00/1.00, addr 2 on usbus4
Root mount waiting for: usbus4
pass3: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
da0: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
Root mount waiting for: usbus4
ugen1.2: vendor 0x1941 at usbus1
ugen1.3: vendor 0x04f9 at usbus1
ulpt0: vendor 0x04f9 product 0x0100, class 0/0, rev 1.00/1.00, addr  
3 on usbus1

ugen2.2: Logitech at usbus2
uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/49.00,  
addr 2 on usbus2

ugen2.3: Logitech at usbus2
ukbd0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,  
addr 3 on usbus2

ugen2.4: Logitech at usbus2
ums0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,  
addr 4 on usbus2

---snip---

Bye,
Alexander.

--
The man who laughs has not yet been told the terrible news.
-- Bertolt Brecht

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov  
2010 10:36:41 +0100):



On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote:

Hi,

I have a memory stick which made problems (the stick is used as a ZFS
cache and it moaned about 8xxM write problems) in 9-current r214509. I
removed the device from the config, made a camcontrol reset all,
camcontrol rescan all (- device disappeared), and then tried an
usbconfig reset ugen4.2 (relevant devlist part from before the call is
below). The usbconfig reset does not return to the shell.

I do not know if the problem with the USB memory stick is related to
software or hardware. The stick survived just a weekend, I replaced it
because the old one showed similar problems after surviving about 9
months... I updated -current just before the problems appeared (and
then again after a week or two), but I do not remember from which
revision of -current I was updating from. I will try to stress-test
the memory sticks on a 8.1 system so see if it is some software problem.

The big question I have for now is: shouldn't there be some kind of
safety mechanism kicking in (timeout) with the usbconfig command (in
this case the reset)?

devlist:
---snip---
ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE
ugen4.2: Flash Disk USB 2.0 at usbus4, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON
---snip---

dmesg | grep -i usb:
---snip---
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xdc00-0xdc1f
irq 16 at device 29.0 on pci0
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe000-0xe01f
irq 19 at device 29.1 on pci0
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe400-0xe41f
irq 18 at device 29.2 on pci0
usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xe800-0xe81f
irq 16 at device 29.3 on pci0
usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xfe77fc00-0xfe77 irq 23 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 480Mbps High Speed USB v2.0
ugen0.1: Intel at usbus0
uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ugen1.1: Intel at usbus1
uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ugen2.1: Intel at usbus2
uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
ugen3.1: Intel at usbus3
uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3
ugen4.1: Intel at usbus4
uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
ugen4.2: USB 2.0 at usbus4
umass0: USB 2.0 Flash Disk, class 0/0, rev 2.00/1.00, addr 2 on usbus4
Root mount waiting for: usbus4
pass3: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
da0: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device
Root mount waiting for: usbus4
ugen1.2: vendor 0x1941 at usbus1
ugen1.3: vendor 0x04f9 at usbus1
ulpt0: vendor 0x04f9 product 0x0100, class 0/0, rev 1.00/1.00, addr
3 on usbus1
ugen2.2: Logitech at usbus2
uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/49.00,
addr 2 on usbus2
ugen2.3: Logitech at usbus2
ukbd0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,
addr 3 on usbus2
ugen2.4: Logitech at usbus2
ums0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00,
addr 4 on usbus2
---snip---


Hi,

If you dump all threads in this state I think you will see that USB  
is waiting


# procstat -kk 29213
  PIDTID COMM TDNAME   KSTACK
29213 100291 usbconfig-mi_switch+0x188  
sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30  
usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d  
ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21



somewhere in umass_detach(), which is preventing the usbconfig reset from


No umass_detach in there...


grabbing the SX-lock associated with serialisation. Because umass_detach() is
not returning we are stuck.


And there is no way to use some kind of timeout for cases which cause  
problem reports (like umass_detach() and maybe this one)? I could  
imagine several possibilities: usbconfig tries a trylock first (maybe  
several times) and if it does not succeed in a specified timeperiode,  
it returns an error. Adidtionally there is maybe the possibility to  
determine if a command did not finish in a given timeperiode and print  
out a warning message (syslog) to have an indication, that somthing is  
not in a good

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Alexander Motin m...@freebsd.org (from Tue, 02 Nov 2010  
14:02:17 +0200):



Alexander Leidinger wrote:


Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov 2010
10:36:41 +0100):



If you dump all threads in this state I think you will see that USB is
waiting


# procstat -kk 29213
  PIDTID COMM TDNAME   KSTACK
29213 100291 usbconfig-mi_switch+0x188
sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30
usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d
ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21


somewhere in umass_detach(), which is preventing the usbconfig reset from


No umass_detach in there...


umass_detach() (if there) should be in some other thread.


Not here:
---snip---
# procstat -kka | grep umass_detach

---snip---


grabbing the SX-lock associated with serialisation. Because
umass_detach() is
not returning we are stuck.


And there is no way to use some kind of timeout for cases which cause
problem reports (like umass_detach() and maybe this one)? I could
imagine several possibilities: usbconfig tries a trylock first (maybe
several times) and if it does not succeed in a specified timeperiode, it
returns an error. Adidtionally there is maybe the possibility to
determine if a command did not finish in a given timeperiode and print
out a warning message (syslog) to have an indication, that somthing is
not in a good condition.


Not sure what should it give. We should track the real problem, not the
consequences. Possible reason could be that due to some error umass/CAM
leaked some references, which made impossible to destroy CAM bus on
stick disconnection. But to diagnose it we need much more info.


Something I could provide? Some kdb magic I could copypaste?

Bye,
Alexander.

--
Phosflink, v.:
To flick a bulb on and off when it burns out (as if, somehow,
that will bring it back to life).
-- Rich Hall  Friends, Sniglets

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov  
2010 13:00:54 +0100):



On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote:

# procstat -kk 29213
   PIDTID COMM TDNAME   KSTACK
29213 100291 usbconfig-mi_switch+0x188
sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30
usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d
ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21

 somewhere in umass_detach(), which is preventing the usbconfig reset from

No umass_detach in there...


Hi,

The USB threads are joined into a single process and not visible from ps.


Is there a special reason why it is not visible?

Bye,
Alexander.

--
Killing is wrong.
-- Losira, That Which Survives, stardate unknown

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Andriy Gapon a...@icyb.net.ua (from Tue, 02 Nov 2010 14:30:34 +0200):


on 02/11/2010 14:00 Hans Petter Selasky said the following:

On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote:

# procstat -kk 29213
   PIDTID COMM TDNAME   KSTACK
29213 100291 usbconfig-mi_switch+0x188
sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30
usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d
ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21


somewhere in umass_detach(), which is preventing the usbconfig reset from


No umass_detach in there...


Hi,

The USB threads are joined into a single process and not visible from ps.
Not sure how you can get a list of all threads.


-H option would that for ps.
But I am not why mentioned ps, because procstat shows the threads,  
e.g. procstat

-k -a will show stacks of all non-running kernel threads.


So withdraw my last question (the answer to HPS' message that it is  
not shown in ps), as I already provided the procstat -kka | grep  
umass_detach part (no trace of it).


There is every half an hour a job which is polling an USB device. This  
job is not proceeding anymore (each instance started hangs), so it  
looks like the USB system is in a f*ed-up state (it does not matter to  
me if this is because of the usbconfig reset ugen4.2 or not). I  
rebooted the system to get again the data flowing from this job.


Looks like I'm able to trigger this situation within some days. If  
someone wants me to run some specific commands, be it in kdb or  
something else, please specify clearly (kdb commands / instructions)  
what you want and I try to provide this info by setting up the system  
in a way to get into the same situation again.


Bye,
Alexander.

--
TOTD (T-shirt Of The Day):
I'm the person your mother warned you about.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Andriy Gapon a...@icyb.net.ua (from Tue, 02 Nov 2010 14:30:34 +0200):


on 02/11/2010 14:00 Hans Petter Selasky said the following:

On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote:

# procstat -kk 29213
   PIDTID COMM TDNAME   KSTACK
29213 100291 usbconfig-mi_switch+0x188
sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30
usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d
ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21


somewhere in umass_detach(), which is preventing the usbconfig reset from


No umass_detach in there...


Hi,

The USB threads are joined into a single process and not visible from ps.
Not sure how you can get a list of all threads.


-H option would that for ps.
But I am not why mentioned ps, because procstat shows the threads,  
e.g. procstat

-k -a will show stacks of all non-running kernel threads.


So withdraw my last question (the answer to HPS' message that it is  
not shown in ps), as I already provided the procstat -kka | grep  
umass_detach part (no trace of it).


There is every half an hour a job which is polling an USB device. This  
job is not proceeding anymore (each instance started hangs), so it  
looks like the USB system is in a f*ed-up state (it does not matter to  
me if this is because of the usbconfig reset ugen4.2 or not). I  
rebooted the system to get again the data flowing from this job.


Looks like I'm able to trigger this situation within some days. If  
someone wants me to run some specific commands, be it in kdb or  
something else, please specify clearly (kdb commands / instructions)  
what you want and I try to provide this info by setting up the system  
in a way to get into the same situation again.


Bye,
Alexander.

--
TOTD (T-shirt Of The Day):
I'm the person your mother warned you about.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: USB on -current is filling my messages log

[Alexander Leidinger]

Quoting Paul B Mahol one...@gmail.com (from Mon, 4 Oct 2010 19:36:29 +):


On 9/29/10, Alexander Leidinger alexan...@leidinger.net wrote:

Hi,

every half an hour I get two log entries in /var/log/messages. They
look like this:
---snip---
Sep 28 23:30:00 M87 root: Unknown USB device: vendor 0x1941 product
0x8021 bus uhub1
Sep 28 23:30:00 M87 root: Unknown USB device: vendor 0x1941 product
0x8021 bus uhub1
---snip---

What is causing this and how to disable it?


devd(8) ?


Yes and no... Now that I investigated it a little bit: every half an  
hour an application is polling some data from this device. The  
software (ports/net/fowsr) is disconnecting this device from it's  
driver, does it's job, and then exits. Problably the USB stack is  
reprobing the device afterwards?


Thanks for pointing out devd, I have a look at a rule to match this  
device, so that I do not get spammed by the message anymore.


Bye,
Alexander.

--
Her rent will remain what it was.
-- Signor Roberto, Chapter 14, page 209

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

USB on -current is filling my messages log

[Alexander Leidinger]

Hi,

every half an hour I get two log entries in /var/log/messages. They  
look like this:

---snip---
Sep 28 23:30:00 M87 root: Unknown USB device: vendor 0x1941 product  
0x8021 bus uhub1
Sep 28 23:30:00 M87 root: Unknown USB device: vendor 0x1941 product  
0x8021 bus uhub1

---snip---

What is causing this and how to disable it?

Bye,
Alexander.

--
It's difficult to see the picture when you are inside the frame.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: [USB] Keyboard, mouse and ergonomy

[Alexander Leidinger]

Quoting Hans Petter Selasky hsela...@c2i.net (from Mon, 27 Sep 2010  
14:21:42 +0200):



Hi,

I was thinking about adding a sysctl to ukbd and ums that shows how many
keypresses have been done and how many pixels you have moved the mouse during
a day. These number will mostly be useful for making ergonomic arguments that
a certain way of working is better than another one.

Anyone have any comments or input on this? Are there any security concerns
about this?


Be careful with ergonomic arguments. For example the screen corners  
are easy (and fast) mouse targets (if they are used for something in  
the software), and would give a false impression if you count  
mouse-device movement instead of mouse-pointer movement on the screen  
(which you can not measure in ums). The most easy ergonomic point for  
a mouse is the current position (pop-up menus), and this involves not  
much movement...


Regarding key-presses there's also the problem of having the keys  
directly under your fingers, or having to move back and forth with the  
hands (also depends upon the keyboard layout and type of work you do).


Regarding metrics I suggest to:
 - add a click-count
 - not hardcode the counter-reset (let a sysctl handle the counter reset
   upon request)
 - differentiate between normal key presses and shift-ed/control-ed/...
   ones (I do not think that caps-lock should count as shift-ed)
 - I do not know if it makes sense to have a hold-time (for
   shift/control/...), if this is for real ergonomic research,
   this could be helpful

Regarding the security:
 - don't make this real-time stats, add some artificial delay
   (you could interpolate what is typed just by watching the
   stats), I suggest to make the delay at least several
   seconds long (to cover people with disabilities and maybe
   people which search each character with one finger), for
   real ergonomic research this is counter-productive (but
   you stated that you want to measure on a per-day basis,
   to this should not matter in your case)
 - make it depending on a compile time knob (disabled
   by default) and issue a warning on device attach if
   compiled in

Bye,
Alexander.

--
An honest tale speeds best being plainly told.
-- William Shakespeare, Henry VI

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Porting an USB software from linux (libusb)

[Alexander Leidinger]

Quoting Jim Bryant kc5vdj.free...@gmail.com (from Mon, 30 Aug 2010  
19:22:49 -0500):



easy fix.  just drop the _np

the functions are there under legacy naming.


Not in my revision of FreeBSD-current. I commented it out like HPS  
suggested (the right way, with the correct macros to enable  
automatically when those functions are merged from P4 to SVN) and the  
linker doesn't complain anymore.


Bye,
Alexander.


Alexander Leidinger wrote:

Hi,

I try to port a linux userland USB program and I get the following  
error message when trying to link to libusb (current as of r210105):

---snip---
cc -lusb -lm -o fowsr  fowsr.o
fowsr.o(.text+0x1546): In function `CUSB_Open':
: undefined reference to `usb_get_driver_np'
fowsr.o(.text+0x1710): In function `CUSB_Open':
: undefined reference to `usb_detach_kernel_driver_np'
gmake: *** [fowsr] Fehler 1
---snip---

Do I need those functions on FreeBSD (the device may show up as a  
HID device, I hadn't a chance to attach it to a FreeBSD box yet),  
or can I just remove them (I could make sure the HID driver is not  
loaded in the kernel)?


Here is the related source:
---snip---
   devh = usb_open(dev);
   assert(devh);

   signal(SIGTERM, release_usb_device);

   ret = usb_get_driver_np(devh, 0, buf, sizeof(buf));
   printf(usb_get_driver_np returned %d\n, ret);
   if (ret == 0) {
   printf(interface 0 already claimed by driver  
\\'%s\\', attempting to detach it\n, buf);

   ret = usb_detach_kernel_driver_np(devh, 0);
   printf(usb_detach_kernel_driver_np returned %d\n, ret);
   }
   ret = usb_claim_interface(devh, 0);
   if (ret != 0) {
   printf(claim failed with error %d\n, ret);
   exit(1);
   }

   ret = usb_set_altinterface(devh, 0);
---snip---

Bye,
Alexander.








--
Star Trek Lives!

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Porting an USB software from linux (libusb)

[Alexander Leidinger]

Quoting Hans Petter Selasky hsela...@c2i.net (from Mon, 30 Aug 2010  
21:11:22 +0200):



I've added these missing functions to LibUSB in USB P4 change 183086.


Do you need someone to commit them to SVN, or is there something  
scheduled already?



Consider adding a compile time check for the existence of these functions.
They are marked non-portable in LibUSB.


Done.

Thanks,
Alexander.

--
Dr. Zoidberg: It funny because it's poisonous.
Fry: Yeah, keep laughing, brine shrimp.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Porting an USB software from linux (libusb)

[Alexander Leidinger]

Hi,

I try to port a linux userland USB program and I get the following  
error message when trying to link to libusb (current as of r210105):

---snip---
cc -lusb -lm -o fowsr  fowsr.o
fowsr.o(.text+0x1546): In function `CUSB_Open':
: undefined reference to `usb_get_driver_np'
fowsr.o(.text+0x1710): In function `CUSB_Open':
: undefined reference to `usb_detach_kernel_driver_np'
gmake: *** [fowsr] Fehler 1
---snip---

Do I need those functions on FreeBSD (the device may show up as a HID  
device, I hadn't a chance to attach it to a FreeBSD box yet), or can I  
just remove them (I could make sure the HID driver is not loaded in  
the kernel)?


Here is the related source:
---snip---
devh = usb_open(dev);
assert(devh);

signal(SIGTERM, release_usb_device);

ret = usb_get_driver_np(devh, 0, buf, sizeof(buf));
printf(usb_get_driver_np returned %d\n, ret);
if (ret == 0) {
printf(interface 0 already claimed by driver  
\\'%s\\', attempting to detach it\n, buf);

ret = usb_detach_kernel_driver_np(devh, 0);
printf(usb_detach_kernel_driver_np returned %d\n, ret);
}
ret = usb_claim_interface(devh, 0);
if (ret != 0) {
printf(claim failed with error %d\n, ret);
exit(1);
}

ret = usb_set_altinterface(devh, 0);
---snip---

Bye,
Alexander.

--
Famous last words:

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Ioctl 0x7601 on /dev/video0 - `linux' in kernel

[Alexander Leidinger]

Quoting Xiaofan Chen xiaof...@gmail.com (from Fri, 11 Jun 2010  
15:22:56 +0800):


On Fri, Jun 11, 2010 at 2:43 PM, Mikhail T.  
mi+t...@aldan.algebra.com wrote:


I have linuxulator in the kernel (option COMPAT_LINUX), however, so, I
thought, it is supposed to just work... But it does not. Is anyone
successful getting skype with video on FreeBSD?



If that would work, it will be a perfect world. ;-)

I would not think that the Linux emulation is good for USB hardware.


The corresponding linuc v4l to FreeBSD v4l translation layer is not in  
8.x. You have to run 9-current if you want to use it (or wait until  
8.1 is released and 8-stable open for new features, merging the code  
in 8-stable is on my TODO list).


Bye,
Alexander.

--
But don't you worry, its for a cause -- feeding global corporations
paws.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Regression with ukbd/ums

[Alexander Leidinger]

On Thu, 18 Feb 2010 20:55:53 +0100 Hans Petter Selasky
hsela...@c2i.net wrote:

 Have you checked battery, etc.

Hmpf... before charging the battery, I checked if the fancy lights
(e.g. led display of the volume control which this kbd provides but
FreeBSD does not have native support for) go on, and they did. Despite
the fact that there was still enough power for this, it seems the kbd
lost the association with the USB dongle. After pushing the connect
buttons everything was working again.

As there is a switch to power-off the kbd, and because it is working
fine when having it switched off for a while, I expected that the
association stuff is stored in some non-volatile storage. It seems this
is not the case.

Sorry for the noise I created,
Alexander.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: Regression with ukbd/ums

[Alexander Leidinger]

On Thu, 18 Feb 2010 17:01:04 +0100 Hans Petter Selasky
hsela...@c2i.net wrote:

 On Thursday 18 February 2010 16:09:39 Alexander Leidinger wrote:
  Hi,
  
  I have the following ukbd/ums hardware (ugen2.*) which was working
  fine with 9-current before, but fails to work now with r203813.
  
  It is a Logitec diNovo kbd with integrated mousepad. Previously this
  was workinf fine, but now no mouse movement and no kkey press is
  registered. When I reboot into the console, I can press any key I
  want, but no reaction is visible on the screen, when I start X
  remotely, no mouse movement and no key press can be noticed. It
  looks like no kbd and no mouse is attached.
  
 
 Try:
 
 sysctl hw.usb.ums.debug=15
 sysctl hw.usb.ukbd.debug=15
 
 Do you see anything when using kbd/mouse?

Nothing at all.

Bye,
Alexander.

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usb4bsd patch review

[Alexander Leidinger]

Quoting Hans Petter Selasky [EMAIL PROTECTED] (Sat, 23 Aug 2008 08:03:55 
+0200):

 On Friday 22 August 2008, Alexander Leidinger wrote:
  Quoting Kris Kennaway [EMAIL PROTECTED] (from Fri, 22 Aug 2008
 
  10:59:38 +0200):
   Alexander Leidinger wrote:
   Quoting M. Warner Losh [EMAIL PROTECTED] (from Thu, 21 Aug 2008
  
   11:52:10 -0600 (MDT)):
   In message: [EMAIL PROTECTED]
  
  Kris Kennaway [EMAIL PROTECTED] writes:
   : Hans Petter Selasky wrote:
   :  The USB stack will work fine without usbconfig. Its purpose
  
   is :  mostly to
  
   :  view the currently attached USB devices, where the USB devices
   :  are located
   :  and to select a non-default USB configuration. One thing which
   :  might be missed is to change owner and permission of a USB device,
  
   which means you
  
   :  must be either UID=root or GID=OPERATOR to be able to use USB
   :  devices that
   :  create devices under /dev/ .
   :
   : OK great, this isn't critical either.  I think all of the issues I
   : raised are agreed upon now!
  
   Wait a moment. Does this mean the devfs stuff to handle the access
   rights (devfs.rules or manual chown/chmod by root) does not work
   with the new usb stuff? If the answer is yes, I would see this as
   some kind of nasty bug (I don't think this shall be a showstopper,
   as long as this is fixed later).
  
   Yes, he said it will be fixed later.
 
  You are aware that I point out that this may or may not suggest that
  HPS is circumventing the normal devfs infrastructure and that this may
  or may not be a problem and should be reviewed by someone with
  knowledge about the devfs infrastructure?
 
  And as he mentioned that in the context of the userland utilities, it
  may be interesting if this means if an USB specific userland utility
  will be responsible to change the ownership and file access or not. If
  yes, what are the consequences from a security point of view and what
  about POLA (devfs.rules, chown/chmod)?
 
  I want to see this new USB subsystem, but if the answer to the above
  paragraph is yes, then this would be a showstopper for me (IMO the
  replacement should work in this regard as before, I don't say it can
  not be changed after enough people agree that the replacement was
  successful).
 
  Bye,
  Alexander.
 
 Hi Alexander,
 
 You have to ask Paul Henning Kamp about that. He does not like the idea 
 about /dev/ being the inventory list.

We already have a lot of cloning devices, so it's not about showing a
device node in /dev or not, I'm talking about chmod/chflags/devfs.rules.

 Besides, there are no more visible /dev/ devices. All devices are so-called 
 cloneable and invisible, so you need a separate utility. The good news is 

No, devfs.rules is handling this case already, no need for another
utility:
---snip---
NAME
 devfs.rules -- devfs configuration information

DESCRIPTION
 The devfs.rules file provides an easy way to create and apply devfs(8)
 rules, even for devices that are not available at boot.

 For devices available at boot, see devfs.conf(5).
---snip---

With your new utility you are changing the security policy, and this
without discussing this in public (who is able to change the
permissions, are changes permanent and survive a reboot, ...). With
devfs.rules we already have a tested and reviewed feature where root
can configure access.

 that you can set the permissions on a USB subtree (a HUB and all subdevices) 
 before devices are eventually plugged !

I don't know of a scenario where this is useful, but I'm not surprised
if someone has an use for this. And I think this feature can be
available while respecting the current semantics of devfs and
devfs.rules (e.g. if your feature is used, give priority to it, else
respect devfs.rules).

Bye,
Alexander.

-- 
Ferengi Rule of Acquisition #7:
 Keep your ears open.
-- ST:DS9, In the Hands of the Prophets
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb4bsd patch review

[Alexander Leidinger]

Quoting Poul-Henning Kamp [EMAIL PROTECTED] (Sat, 23 Aug 2008 15:27:24 
+):

 In message [EMAIL PROTECTED], Hans Petter Selasky writes:
 
 
 The problem about devfs.rules with regard to USB is that you don't know 
 what 
 you are giving permissions to. A rule that gives permission to /dev/ulpt0 
 will give permissions to the first printer you plug into the USB system. 
 That 
 is not neccessarily what the user wants.
 
 I think this might be a good time to consider the devd/devfs
 distribution of work.
 
 The reason devfs(8) works like firewall rules is that we did not want
 some mandatory daemon to set the modes, in particular on embedded
 systems.
 
 The alternative solution is to always create device nodes root:wheel r--
 and let the daemon set the mode as desired.
 
 This model has the advantage of not needing the uid, gid and mode arguments
 to make_dev, something that has always been acknowleded as a kludge.
 
 The down side is that devd(8) becomes a mandatory daemon on most systems.

A downside which belongs into its own discussion, an not into the
already huge back and forth for the new USB subsystem.

 Given that devfs(8) has not exactly been a stellar success and that it
 often and repeatedly bites people with it slightly pedantic semantics,
 transitioning in that direction might be a good thing.

Unpredictable behavior (except you know by heard which entry is
behaving how... something someone should not need to know)
instead of doing it right by doing all at once? I don't think this is a
good idea, and it seems Warner thinks the same (see his answer to the
mail you answered to).

Bye,
Alexander.

-- 
Ferengi Rule of Acquisition #177:
Know your enemies... but do business with them always.
-- ST: Legends of the Ferengi
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb4bsd patch review

[Alexander Leidinger]

Quoting Kris Kennaway [EMAIL PROTECTED] (from Fri, 22 Aug 2008  
10:59:38 +0200):



Alexander Leidinger wrote:
Quoting M. Warner Losh [EMAIL PROTECTED] (from Thu, 21 Aug 2008  
11:52:10 -0600 (MDT)):



In message: [EMAIL PROTECTED]
   Kris Kennaway [EMAIL PROTECTED] writes:
: Hans Petter Selasky wrote:


:  The USB stack will work fine without usbconfig. Its purpose  
is :  mostly to
:  view the currently attached USB devices, where the USB devices  
:  are located

:  and to select a non-default USB configuration. One thing which might be
:  missed is to change owner and permission of a USB device,  
which means you
:  must be either UID=root or GID=OPERATOR to be able to use USB  
:  devices that

:  create devices under /dev/ .
:
: OK great, this isn't critical either.  I think all of the issues I
: raised are agreed upon now!


Wait a moment. Does this mean the devfs stuff to handle the access  
rights (devfs.rules or manual chown/chmod by root) does not work  
with the new usb stuff? If the answer is yes, I would see this as  
some kind of nasty bug (I don't think this shall be a showstopper,  
as long as this is fixed later).


Yes, he said it will be fixed later.


You are aware that I point out that this may or may not suggest that  
HPS is circumventing the normal devfs infrastructure and that this may  
or may not be a problem and should be reviewed by someone with  
knowledge about the devfs infrastructure?


And as he mentioned that in the context of the userland utilities, it  
may be interesting if this means if an USB specific userland utility  
will be responsible to change the ownership and file access or not. If  
yes, what are the consequences from a security point of view and what  
about POLA (devfs.rules, chown/chmod)?


I want to see this new USB subsystem, but if the answer to the above  
paragraph is yes, then this would be a showstopper for me (IMO the  
replacement should work in this regard as before, I don't say it can  
not be changed after enough people agree that the replacement was  
successful).


Bye,
Alexander.

--
Such a fine first dream!
But they laughed at me; they said
I had made it up.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: USB Video class

[Alexander Leidinger]

Quoting Peter B [EMAIL PROTECTED] (from Tue, 19 Aug 2008 15:05:29  
+0200 (MEST)):




Is there any ongoing project towards USB Video class support in FreeBSD ..?


This is better asked on usb@ (CCed). I'm not aware of such an effort,  
feel free to start it (you better wait some days until the new USB  
stack hits CVS).


Bye,
Alexander.


(Looking at the Asus eee builtin webcam 0x04F2 (CHICONY) 0xB071)

Some links:
  http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/   uvideo.c
  http://developer.berlios.de/projects/linux-uvc
  http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]






--
While you don't greatly need the outside world, it's
still very reassuring to know that it's still there.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: How to remap or ignore certain mouse buttons? (was: Fun with Logitech keyboard/mouse kombo (diNovo Edge)...)

[Alexander Leidinger]

Quoting Kai Wang [EMAIL PROTECTED] (Thu, 8 May 2008 12:59:29 +0200):

 On Thu, May 8, 2008 at 10:36 AM, Alexander Leidinger 
 [EMAIL PROTECTED] wrote:
 
  Quoting Alexander Leidinger [EMAIL PROTECTED] (Wed, 7 May 2008
  19:24:20 +0200):
 
   Hi,
  
   I bought a keyboard with an integrated touchpad from logitech. Just
   plugging in the BT-dongle gives an usb hub with ums and ukbd.
   Unfortunately the ums doesn't work. When I start moused with
   -p /dev/ums0 -3 -f -d I get no output when I press the buttons or
   touch the touchpad. Any hints how to debug this problem? usbhidctl
   doesn't print anything useful (but I don't know if it is ok to use it
   with /dev/ums0).
 
  After a little bit of googling I found a description of the problem
  with the diNovo Edge. Quoting from
 
  http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html
 
 
 Hello Alexander,
 
 Our hid parser sometimes has problems dealing with multiple report IDs, and
 our parser
 is different from the Linux one.

I've found a posting to the usb@ list where someone teached the USB
code to parse multiple report IDs for HIDs. Did someone had a look at
it?

 Could you please dump the report descriptor of your mouse and post it here?

It's a kbd/mouse-combo, here's the output when I plug it in:
---snip---
[report desc size=59]
USAGE PAGE Generic Desktop(0x1)
USAGE Keyboard(0x6)[Generic Desktop(0x1)]
COLLECTION Application(1)
  USAGE PAGE Keyboard(0x7)
  USAGE MINIMUM Keyboard LeftControl(224)
  USAGE MAXIMUM Keyboard Right GUI(231)
  LOGICAL MINIMUM 0
  LOGICAL MAXIMUM 1
  REPORT SIZE 1
  REPORT COUNT 8
  INPUT ( Data Variable Absolute ) (2)
  INPUT ( Const Variable Absolute ) (3)
  REPORT COUNT 5
  USAGE PAGE LEDs(0x8)
  USAGE MINIMUM Num Lock(1)
  USAGE MAXIMUM Kana(5)
  OUTPUT ( Data Variable Absolute ) (2)
  REPORT COUNT 1
  REPORT SIZE 3
  OUTPUT ( Const Array Absolute ) (1)
  REPORT COUNT 6
  REPORT SIZE 8
  LOGICAL MINIMUM 0
  LOGICAL MAXIMUM 164
  USAGE PAGE Keyboard(0x7)
  USAGE MINIMUM Reserved (no event indicated)(0)
  USAGE MAXIMUM Keyboard ExSel(164)
  INPUT ( Data Array Absolute ) (0)
END COLLECTION
[hexdump]
 05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
0010 75 01 95 08 81 02 81 03 95 05 05 08 19 01 29 05
0020 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 A4
0030 00 05 07 19 00 2A A4 00 81 00 C0
ukbd0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00, addr 3 
on uhub5
kbd1 at ukbd0

[report desc size=301]
USAGE PAGE Generic Desktop(0x1)
USAGE Mouse(0x2)[Generic Desktop(0x1)]
COLLECTION Application(1)
  REPORT ID 2
  USAGE Pointer(0x1)[Generic Desktop(0x1)]
  COLLECTION Physical(0)
USAGE PAGE Button(0x9)
USAGE MINIMUM Button1(1)
USAGE MAXIMUM Button8(8)
LOGICAL MINIMUM 0
LOGICAL MAXIMUM 1
REPORT COUNT 8
REPORT SIZE 1
INPUT ( Data Variable Absolute ) (2)
USAGE PAGE Generic Desktop(0x1)
LOGICAL MINIMUM -2047
LOGICAL MAXIMUM 2047
REPORT SIZE 12
REPORT COUNT 2
USAGE X(0x30)[Generic Desktop(0x1)]
USAGE Y(0x31)[Generic Desktop(0x1)]
INPUT ( Data Variable Relative ) (6)
LOGICAL MINIMUM -127
LOGICAL MAXIMUM 127
REPORT SIZE 8
REPORT COUNT 1
USAGE Wheel(0x38)[Generic Desktop(0x1)]
INPUT ( Data Variable Relative ) (6)
USAGE PAGE Consumer(0xc)
USAGE AC Pan(0x238)[Consumer(0xc)]
LOGICAL MINIMUM -7
LOGICAL MAXIMUM 7
REPORT SIZE 4
REPORT COUNT 1
INPUT ( Data Variable Relative ) (6)
USAGE PAGE Button(0x9)
USAGE MINIMUM Button9(9)
USAGE MAXIMUM Button12(12)
LOGICAL MINIMUM 0
LOGICAL MAXIMUM 1
REPORT SIZE 1
REPORT COUNT 4
INPUT ( Data Variable Absolute ) (2)
  END COLLECTION
END COLLECTION
USAGE PAGE Generic Desktop(0x1)
USAGE Mouse(0x2)[Generic Desktop(0x1)]
COLLECTION Application(1)
  REPORT ID 5
  USAGE Pointer(0x1)[Generic Desktop(0x1)]
  COLLECTION Physical(0)
USAGE PAGE Button(0x9)
USAGE MINIMUM Button1(1)
USAGE MAXIMUM Button8(8)
LOGICAL MINIMUM 0
LOGICAL MAXIMUM 1
REPORT COUNT 8
REPORT SIZE 1
INPUT ( Data Variable Absolute ) (2)
USAGE PAGE Generic Desktop(0x1)
LOGICAL MINIMUM -2047
LOGICAL MAXIMUM 2047
REPORT SIZE 12
REPORT COUNT 2
USAGE X(0x30)[Generic Desktop(0x1)]
USAGE Y(0x31)[Generic Desktop(0x1)]
INPUT ( Data Variable Relative ) (6)
LOGICAL MINIMUM -127
LOGICAL MAXIMUM 127
REPORT SIZE 8
REPORT COUNT 1
USAGE Wheel(0x38)[Generic Desktop(0x1)]
INPUT ( Data Variable Relative ) (6)
USAGE PAGE Consumer(0xc)
USAGE AC Pan(0x238)[Consumer(0xc)]
LOGICAL MINIMUM -127
LOGICAL MAXIMUM 127
REPORT SIZE 8
REPORT COUNT 1
INPUT ( Data Variable Relative ) (6)
  END COLLECTION
END COLLECTION
USAGE PAGE Consumer(0xc)
USAGE Consumer Control(0x1)[Consumer(0xc)]
COLLECTION Application(1)
  REPORT ID 3
  REPORT SIZE 16
  REPORT COUNT 2
  LOGICAL MINIMUM 1
  LOGICAL MAXIMUM 652
  USAGE MINIMUM Consumer Control(1)
  USAGE MAXIMUM AC Send(652)
  INPUT ( Data Array Absolute

Re: PR backlog [was: Re: usb/umass, devfs: this sucks]

[Alexander Leidinger]

Quoting Mark Linimon [EMAIL PROTECTED] (from Sat, 29 Dec 2007  
22:26:02 -0600):



On Sun, Dec 30, 2007 at 01:01:19AM +0100, Alexander Leidinger wrote:

Quoting Mark Linimon [EMAIL PROTECTED] (from Wed, 26 Dec 2007
12:04:15 -0600):

 - The creation of a weekly posting bugs the bugmeister team thinks are
   ready for commit.  This doesn't seem to have attracted the desired
   attention.  Perhaps this is a problem of push not being the right
   solution here; perhaps it just hasn't been publicized enough.

Where is/was this mail send to?


  To: [EMAIL PROTECTED]
  Subject: PRs recommended for committer evaluation by the bugbusting team

It's sent out weekly.


So only people which are on bugbusters@ receive it. If someone is  
interested in this but is not interested in the other bugbusters@  
mails, they will not see it.


What about an experiment: send those mails (additionally) to hackers@  
or [EMAIL PROTECTED]


Bye,
Alexander.

--
Beware of self-styled experts: an ex is a has-been, and a spurt is a
drip under pressure.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: PR backlog [was: Re: usb/umass, devfs: this sucks]

[Alexander Leidinger]

Quoting Mark Linimon [EMAIL PROTECTED] (from Wed, 26 Dec 2007  
12:04:15 -0600):



 - The creation of a weekly posting bugs the bugmeister team thinks are
   ready for commit.  This doesn't seem to have attracted the desired
   attention.  Perhaps this is a problem of push not being the right
   solution here; perhaps it just hasn't been publicized enough.


Where is/was this mail send to?

Bye,
Alexander.

--
When I met th'POPE back in '58, I scrubbed him with a MILD SOAP or
DETERGENT for 15 minutes.  He seemed to enjoy it ...

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Motorola A41x/V32x driver

[Alexander Leidinger]

Quoting Kenneth F. Morse Sr. [EMAIL PROTECTED] (Thu, 8 Nov 2007 17:27:03 
-0500):

 I find I am not alone in the need for the driver for Motorola A41x/v32x
 driver.  I cannot find it either but I did not find where there was any
 response to the request.

There's no driver for Motorola A41x/v32x available. I also think it is
not necessary. It would help if you describe what you want to do and
what you tried to do so far. Most probably you just need to load one of
the USB serial device modules and attach your mobile after this to
get a serial line to your mobile.

This is as far as you can get here. For everything else (tools to
access the address book or whatever) you need to lock out for software
tools which know how to get this data out of your phone via the serial
connection (and for this you are at the wrong place here).

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: How do I use my USB headset?

[Alexander Leidinger]

Quoting Andreas Davour [EMAIL PROTECTED] (from Thu, 11 Oct 2007  
20:24:44 +0200 (CEST)):



On Wed, 10 Oct 2007, Julian Elischer wrote:


Hans Petter Selasky wrote:


Hi,

If you are not using FreeBSD-7 current, something like the   
following might do the trick:


rm /dev/dsp0
ln -s /dev/dsp1 /dev/dsp0

Although that means you will loose access to /dev/dsp0 .


back when I used skype on BSD it was a linux binary,
which means it was looking in /compat/linux/dev

you need to have the correct symlinks in there..


No.


I didn't think that the fact it was a linux binary could cause michief,
but of course that's a prime suspect for troubles. Strangely enough I
didn't even have a /dev folder under /compat/linux !


This is intended. If the linux emulation can not find /compat/linux/X,  
it searches for /X. As there's no /compat/linux/dev/, it goes to /dev/  
directly.


Bye,
Alexander.

--
I am just a nice, clean-cut Mongolian boy.
-- Yul Brynner, 1956

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: How do I use my USB headset?

[Alexander Leidinger]

Quoting Ariff Abdullah [EMAIL PROTECTED] (from Fri, 12 Oct 2007  
02:38:47 +0800):



/dev/dsp1: Device or resource busy is the response I get from Skype,
and  oddly enough the only device I can choose from now is /dev/dsp1
so maybe  the port maintainger managed to patch Skype to look in the
right place  after all. Still no response from either program
though, the microphone  is not working. :(



Are you really sure the microphone is working in the first place?

Full duplex capabilities are largely improved with FreeBSD 7.x and
beyond, or you might want to try these binary modules for 6.x:


We have full duplex support now in uaudio? I thought it is still  
disabled by intend (because of problems with some usb chipsets). If it  
is still disabled... any ideas how to autodetect the problem and fall  
back to simplex instead of hardcoding it for all chips?


Bye,
Alexander.

--
Another megabytes the dust.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 32bit apps on FreeBSD-6.1-R amd64

[Alexander Leidinger]

Quoting [EMAIL PROTECTED] (Sun, 8 Jul 2007 12:29:55 -0300):

Dear Sirs
 
 
I own a Canon iP1600 usb printer and I need run it on
 FBSD-6.1-Ramd64. Its driver when uncompressed shows
 i386.rpm files. I've installed linux_base-8 but some messages appear up when

If it tries to communicate to the USB stuff directly instead of being
just a filter which outputs a printer language which can be saved to a
file too, it will probably not work, as there's no linux-USB emulation.

linu_base-8 is outdated. The current default linux base port is
linux_base-fc4.

 trying to install i386.rpm files by using rpm commands...and now?

There's rpm2cpio and then you can extract it with cpio. Using rpm when
we have our own ports collection to track installed file is superflous,
and as we will never have everything correctly registered in the rpm
database (when we would use it additionally) anyway (as we delete some
linux stuff for various reasons), we don't install rpm at all (makes
various ports stuff much easier and prevents some nasty misbehavior
when rpm is not used as needed).

Bye,
Alexander.

-- 
Men don't talk peace unless they're ready to back it up with war.
-- Col. Green, The Savage Curtain, stardate 5906.4
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: reminder

[Alexander Leidinger]

Quoting M. Warner Losh [EMAIL PROTECTED] (from Mon, 18 Jun 2007  
13:40:13 -0600 (MDT)):



In message: [EMAIL PROTECTED]
Julian Elischer [EMAIL PROTECTED] writes:
: Warner is doing a lot of cleaning in the existing code I notice...

I'm just doing a preening of the code to finish up the removal of the
compatibility macros I started many moons ago.  I've found at least
one real bug, but it may have been a bug in my earlier cleaning.  I
don't plan on doing anything more extensive than a few bugs fixes.

After I get done with the cleaning, I plan on restoring usb_port.h so
that drivers can include it explicitly if they think they can use it
to be portable between systems.


Do you plan to look at some (more or less) easy PRs?

http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/77940 (rejecting patch?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/80862 (just close PR?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/81308 (patch in trail!)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/90162 (patch in trail)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/91263 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94742
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/97174 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107101 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/108097
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110122
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110856
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110988
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/53025 (just close?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59698 (patch in the
trail, interesting (not only) for Mac users)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/61234
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/63837 (patch in trail)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/68232 (not easy)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/68412 (feedback timeout?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/70523 (patch in trail)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/71605
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/72732
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/74609
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/79725
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/82436
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/83451
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/86195
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/88939
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/91546 (link in trail)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/92306 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94132
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94148
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94311 (link in trail)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94439 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/94946 (size ok?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/95241
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/96714
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/97472 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/101757 (man page)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/101761 (ABI change)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/101775
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/103046 (not easy)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/105518
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/106538 (just close)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107243
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107526
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/108427 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/108810 (fixed in HEAD?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110477
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110681 (bug or feature?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110991
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/110992
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/111710
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/112392
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/113060 (fixed by one
   of the above not easy PRs?)
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113324

The above ones are mostly adding quirks and adding device IDs PRs.  
Some of them fix bugs, and the not so easy ones fix some larger  
issues. I haven't looked at all PRs, only those which seem to be easy  
by reading the subject. As you changed already several things in the  
cleanup work (and core has a some kind of lock for it), you are  
probably better suited to look at the non-quirks/IDs PRs. Most of them  
seem to be as something we should have in the release...


PR for HPS-stack? It doesn't belong into gnats currently.
http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/85992

Bye,
Alexander.

--
It is better to have loved and lost than just to have lost.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 

Re: Support for new device, important fix and enhancement to umass.c

[Alexander Leidinger]

Quoting grem [EMAIL PROTECTED] (from Wed, 28 Mar 2007 04:52:53 +0200):

[analysis of the problem]

Any feedback is welcome, since I'm not an expert in how USB works/is  
 implemented in FreeBSD.


Please submit this as a problem report. Quirks have to be registered  
in GNATS before we can commit them so that we are able to reevaluate  
them if the need arises.



@@ -1665,6 +1673,8 @@
USETDW(sc-csw.dCSWSignature, CSWSIGNATURE);
}

+   if (sc-quirks  IGNORE_RESIDUE)
+ USETDW(sc-csw.dCSWDataResidue, 0);
int Residue;
Residue = UGETDW(sc-csw.dCSWDataResidue);
if (Residue == 0 


Wrong indent for the USETDW line. I don't know much about the USB  
code. If the residue is not used somewhere else, wouldn't it be better  
to do if quirk set the Residue variable to 0 else get it from the  
device instead of setting it?


Bye,
Alexander.

--
BOFH excuse #71:

The file system is full of it

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP

[Alexander Leidinger]

Quoting Steinar Hamre [EMAIL PROTECTED] (from Thu, 1 Feb 2007  
00:09:20 +0100):



On Mon, Jan 29, 2007 at 08:38:52PM +0100, Alexander Leidinger wrote:
Quoting Steinar Hamre [EMAIL PROTECTED] (Wed, 10 Jan 2007   
00:50:24 GMT):


  I have reworked the uscanner module so that it can use the device
  simultaniously with the ulpt and umass modules.

This panics my system at boot time probing. I think my scanner is not
the first interface of the device.


uscanner has never supported attaching to other than the first
interface on the device. This is hardcoded in USB_ATTACH(uscanner)
and is not changed by my patch.

Do you have a plain scanner or a multi function device?


It's a multi function device (scan-print-fax).


(What is the product number or output of  usbdevs -av?)


Vendor: BROTHER (see usbdevs)
Product: 0x0100


Did the device work without my patch?


I never tried, I don't have a driver for this scanner (Brother has  
binary only drivers for sane on linux only).


Bye,
Alexander.

--
She's learned to say things with her eyes
that others waste time putting into words.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP

[Alexander Leidinger]

The following reply was made to PR kern/107665; it has been noted by GNATS.

From: Alexander Leidinger [EMAIL PROTECTED]
To: Steinar Hamre [EMAIL PROTECTED]
Cc: freebsd-usb@freebsd.org, [EMAIL PROTECTED]
Subject: Re: kern/107665: [usb] [patch] uscanner support for epson stylus
DX5050 MFP
Date: Thu, 01 Feb 2007 08:33:33 +0100

 Quoting Steinar Hamre [EMAIL PROTECTED] (from Thu, 1 Feb 2007 =20
 00:09:20 +0100):
 
  On Mon, Jan 29, 2007 at 08:38:52PM +0100, Alexander Leidinger wrote:
  Quoting Steinar Hamre [EMAIL PROTECTED] (Wed, 10 Jan 2007  =20
  00:50:24 GMT):
 
I have reworked the uscanner module so that it can use the device
simultaniously with the ulpt and umass modules.
 
  This panics my system at boot time probing. I think my scanner is not
  the first interface of the device.
 
  uscanner has never supported attaching to other than the first
  interface on the device. This is hardcoded in USB_ATTACH(uscanner)
  and is not changed by my patch.
 
  Do you have a plain scanner or a multi function device?
 
 It's a multi function device (scan-print-fax).
 
  (What is the product number or output of  usbdevs -av?)
 
 Vendor: BROTHER (see usbdevs)
 Product: 0x0100
 
  Did the device work without my patch?
 
 I never tried, I don't have a driver for this scanner (Brother has =20
 binary only drivers for sane on linux only).
 
 Bye,
 Alexander.
 
 --=20
 She's learned to say things with her eyes
 that others waste time putting into words.
 
 http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID =3D B0063FE7
 http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID =3D 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP

[Alexander Leidinger]

Quoting Steinar Hamre [EMAIL PROTECTED] (Wed, 10 Jan 2007 00:50:24 GMT):

  I have reworked the uscanner module so that it can use the device
  simultaniously with the ulpt and umass modules.

This panics my system at boot time probing. I think my scanner is not
the first interface of the device.

Bye,
Alexander.

-- 
   84: Psychologe
  neurolinguistischer Programmierer (Oliver Bandel)
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kern/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP

[Alexander Leidinger]

The following reply was made to PR kern/107665; it has been noted by GNATS.

From: Alexander Leidinger [EMAIL PROTECTED]
To: freebsd-usb@freebsd.org
Cc: Steinar Hamre [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/107665: [usb] [patch] uscanner support for epson stylus
 DX5050 MFP
Date: Mon, 29 Jan 2007 20:38:52 +0100

 Quoting Steinar Hamre [EMAIL PROTECTED] (Wed, 10 Jan 2007 00:50:24 GMT):
 
   I have reworked the uscanner module so that it can use the device
   simultaniously with the ulpt and umass modules.
 
 This panics my system at boot time probing. I think my scanner is not
 the first interface of the device.
 
 Bye,
 Alexander.
 
 -- 
84: Psychologe
   neurolinguistischer Programmierer (Oliver Bandel)
 http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
 http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/106462: Motorola U6 PEBL not recognized by system via USB [patch attached]

[Alexander Leidinger]

The following reply was made to PR usb/106462; it has been noted by GNATS.

From: Alexander Leidinger [EMAIL PROTECTED]
To: Maxim Azarov[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: usb/106462: Motorola U6 PEBL not recognized by system via USB
 [patch attached]
Date: Sun, 28 Jan 2007 17:33:43 +0100

 Quoting Maxim Azarov[EMAIL PROTECTED] (Thu, 7 Dec 2006 22:08:31 GMT):
 
  Description:
  Motorola U6 PEBL phone is not recognized by system. I made a
  little patch that adds it as a device and enaples charge and
  other USB functions of this phone (including data transfer,
  GPRS and so on).
 
 I have a MOTOKRZR and it has the same device ID as your U6 PEBL. I
 don't need a quirk to enable the battery charging (tested with
 ugen and the ucom driver). With the ucom driver I get:
 ---snip---
 ucom0: Motorola Inc. Motorola Phone (K1), class 2/0, rev 1.10/0.01, addr 5 
on uhub1
 ucom0: Motorola Inc. Motorola Phone (K1), rev 1.10/0.01, addr 5, iclass 2/2
 ucom0: data interface 1, has CM over data, has no break
 ucom0: status change notification available
 ---snip---
 
 How did you test the functionality and how did you noticed a change
 in behavior with/without the quirk?
 
 Note: your patch contains the same quirk at two locations in the same
 file.
 
 Bye,
 Alexander.
 
 -- 
 If a man is not a liberal at 25, he has no heart.
 If he's not a conservative by 45, he has no brain.
 http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
 http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/107572: Immidiate System Reboot after removing an activeusb-stick

[Alexander Leidinger]

The following reply was made to PR usb/107572; it has been noted by GNATS.

From: Alexander Leidinger [EMAIL PROTECTED]
To: Andreas Burghardt [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: usb/107572: Immidiate System Reboot after removing an
activeusb-stick
Date: Mon, 08 Jan 2007 15:58:27 +0100

 Quoting Andreas Burghardt [EMAIL PROTECTED] (from Fri, 5 Jan 2007  
 17:16:47 GMT):
 
  Description:
  I removed a Job-it (2.0 USB, 1GB) USB-Stick from its slot while a   
  file copy to this stick was still in progress. The result was an   
  immidiate reboot of FreeBSD without syncing or unmounting any logal   
  file systems.
 
 Yes, removing a stick while the FS is still mounted or a direct access  
 is in progress is something you should not do. This is a known  
 problem. The workaround for now: don't do that!
 
 Bye,
 Alexander.
 
 -- 
 Love tells us many things that are not so.
-- Krainian Proverb
 
 http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
 http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/97169: [uhid] [patch] uhid + Xbox 360 gamepad: turn off blinking LED on attach

[Alexander Leidinger]

Synopsis: [uhid] [patch] uhid + Xbox 360 gamepad: turn off blinking LED on 
attach

State-Changed-From-To: open-closed
State-Changed-By: netchild
State-Changed-When: Sun Jun 18 17:18:45 UTC 2006
State-Changed-Why: 
Committed, thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=97169
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/93738: [ukbd] [patch] ukbd_check_char returns FALSE with character buffered

[Alexander Leidinger]

Synopsis: [ukbd] [patch] ukbd_check_char returns FALSE with character buffered

State-Changed-From-To: open-closed
State-Changed-By: netchild
State-Changed-When: Sun Jun 18 17:31:13 UTC 2006
State-Changed-Why: 
Close on request by submitter. Thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=93738
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/98908: Update usb drivers for modems and scanner

[Alexander Leidinger]

Synopsis: Update usb drivers for modems and scanner

State-Changed-From-To: open-closed
State-Changed-By: netchild
State-Changed-When: Sun Jun 18 17:46:52 UTC 2006
State-Changed-Why: 
Committed to current, except for the scanner (it's supported already). Thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=98908
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/82839: [patch] add support for Aceeca Mez1000 device to uvisor.c

[Alexander Leidinger]

Synopsis: [patch] add support for Aceeca Mez1000 device to uvisor.c

State-Changed-From-To: open-closed
State-Changed-By: netchild
State-Changed-When: Sun Jun 18 17:57:08 UTC 2006
State-Changed-Why: 
Committed. Thanks. Sorry for the delay.

http://www.freebsd.org/cgi/query-pr.cgi?pr=82839
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: external usb dvdrw

[Alexander Leidinger]

Nenhum de Nos [EMAIL PROTECTED] wrote:


hello,

i have a LG dvdrw and a vipower external enclosure,
and a toshiba notebook that can burn dvd's and cd's
using it.

every command that is not reading a cd/dvd gets me an
error. when i run dvd+rw-mediainfo /dev/cd0 it
produces an 0x46 error in dmesg.


There where some commits regarding something like this to -current recently.
I don't know if they will be in 6.1-RELEASE or not, but the probability is
high that those changes will be merged to 6.1.

Bye,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
Kerr's Three Rules for a Successful College:
Have plenty of football for the alumni, sex for the students,
and parking for the faculty.


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: trouble using IBM USB Multi-Burner

[Alexander Leidinger]

Adrian Filipi [EMAIL PROTECTED] wrote:

Hi,

this is not an multimedia@ issue, redirecting to [EMAIL PROTECTED] but maybe 
it's a
scsi issue.

Bye,
Alexander.



	I'm trying to get an IBM USB 2.0 Portable Multi-Burner working 
fully on a 6-stable Thinkpad X31.


	I can get a table of contents with cdcontrol for audio discs, and 
mounting data discs works, but I cannot write to anything, nor can I 
read audio data from the disc.  Oddly cdcontrol play works, but 
given that there is no headphone jack, this is kind of pointless.


	I found some patches at 
http://www.jaist.ac.jp/~uehara/etc/ThinkPadX40/ , but they don't seem 
to improve the situation any.  The resulting diff is attached for 
reference.


I've tried reading with cdparanoia, and here's what I get:

: [EMAIL PROTECTED]; sudo cdparanoia -v 1
cdparanoia III release 9.8 (March 23, 2001)
.
Checking /dev/cd0 for cdrom...

CDROM model sensed: IBM USB2 MultiBurner U0B1

Checking for ATAPICAM...
Drive is SCSI

Checking for MMC style command set...
Drive does not have MMC CDDA support
Setting default read size to 26 sectors (61152 bytes).

Verifying CDDA command set...
Could not find any audio tracks on this disk.

Unable to open disc.
: [EMAIL PROTECTED];

	Additionally the check drive function of the xmms cdaudio plug-in 
returns Digital audio extraction test failed: inappropriate ioctl 
for device.


	Anybody have suggestions on what to try next?  This is a pretty 
nifty drive, that I'd like to get fully functional.


FYI, this is a link the the specific IBM drive:

http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-53489

thanks,

Adrian
--
[ [EMAIL PROTECTED] ]





--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
The shifts of Fortune test the reliability of friends.
-- Marcus Tullius Cicero


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: usb/83353: [ums] [patch] ums driver limits number of buttons to 7

[Alexander Leidinger]

Synopsis: [ums] [patch] ums driver limits number of buttons to 7

State-Changed-From-To: open-closed
State-Changed-By: netchild
State-Changed-When: Thu Dec 29 17:44:42 UTC 2005
State-Changed-Why: 
Committed. Thanks.

http://www.freebsd.org/cgi/query-pr.cgi?pr=83353
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: the mechanism of USB hotplug

[Alexander Leidinger]

M. Warner Losh [EMAIL PROTECTED] wrote:


The USB stuff, btw, is confusingly located in uhub.c.  There are a
number of bugs in the newbus integration of usb, and various people
have tried to fix it.  In usbland uhub is the bus, not the usb device,
which is confusing at first, and poorly documented.  The usb_port.h
obfuscation also doesn't help.


Are the bugs you are talking about documented somewhere? Are they worth an
entry in the upcomming list of projects for volunteers?

Bye,
Alexander.

--
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
The best things in life are for a fee.


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]