El día viernes, enero 04, 2019 a las 10:09:27p. m. +0100, Hans Petter Selasky
escribió:
> On 1/4/19 7:31 PM, Matthias Apitz wrote:
> > El día viernes, enero 04, 2019 a las 07:02:16p. m. +0100, Hans Petter
> > Selasky escribió:
> >
> >> On 1/4/19 7:03 PM, Matthias Apitz wrote:
> >>> I've
On Fri, 4 Jan 2019 22:09:27 +0100, Hans Petter Selasky wrote:
> On 1/4/19 7:31 PM, Matthias Apitz wrote:
>> El día viernes, enero 04, 2019 a las 07:02:16p. m. +0100, Hans
>> Petter Selasky escribió:
>>
>>> On 1/4/19 7:03 PM, Matthias Apitz wrote:
I've applied the 2nd patch on the already
On 1/4/19 7:31 PM, Matthias Apitz wrote:
El día viernes, enero 04, 2019 a las 07:02:16p. m. +0100, Hans Petter Selasky
escribió:
On 1/4/19 7:03 PM, Matthias Apitz wrote:
I've applied the 2nd patch on the already patched sources, it fails.
Should I use the original sources without your first
El día viernes, enero 04, 2019 a las 05:09:09p. m. +0100, Hans Petter Selasky
escribió:
>
> Can you try this patch aswell and attach new logs?
I've applied the 2nd patch on the already patched sources, it fails.
Should I use the original sources without your first patch?
mattias
--
On 1/4/19 5:05 PM, Hans Petter Selasky wrote:
On 1/4/19 4:27 PM, Matthias Apitz wrote:
El día viernes, enero 04, 2019 a las 12:45:47p. m. +0100, Hans Petter
Selasky escribió:
On 1/4/19 11:46 AM, Matthias Apitz wrote:
Jan 4 11:26:39 c720-r342378 kernel: uhub_read_port_status: port 13,
On 1/4/19 4:27 PM, Matthias Apitz wrote:
El día viernes, enero 04, 2019 a las 12:45:47p. m. +0100, Hans Petter Selasky
escribió:
On 1/4/19 11:46 AM, Matthias Apitz wrote:
Jan 4 11:26:39 c720-r342378 kernel: uhub_read_port_status: port 13,
wPortStatus=0x07a0, wPortChange=0x,
El día viernes, enero 04, 2019 a las 12:45:47p. m. +0100, Hans Petter Selasky
escribió:
> On 1/4/19 11:46 AM, Matthias Apitz wrote:
> > Jan 4 11:26:39 c720-r342378 kernel: uhub_read_port_status: port 13,
> > wPortStatus=0x07a0, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION
> > Jan 4
On 1/4/19 11:46 AM, Matthias Apitz wrote:
Jan 4 11:26:39 c720-r342378 kernel: uhub_read_port_status: port 13,
wPortStatus=0x07a0, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION
Jan 4 11:26:41 c720-r342378 kernel: uhub_read_port_status: port 1,
wPortStatus=0xe070, wPortChange=0x161e,
On 1/4/19 9:02 AM, Matthias Apitz wrote:
We definitely should resolve this before anything else.
The output of the 'usbconfig list' was:
# usbconfig list
ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER
El día jueves, enero 03, 2019 a las 01:36:08p. m. +0100, Ludovic Rousseau
escribió:
> I hope this email will go to freebsd-usb@ since I am not a member of this
> list.
>
> Le jeu. 3 janv. 2019 à 13:19, Hans Petter Selasky a écrit :
> >
> > On 1/3/19 12:35 PM, Matthias Apitz wrote:
> > > but
On 1/3/19 1:36 PM, Ludovic Rousseau wrote:
I hope this email will go to freebsd-usb@ since I am not a member of this list.
Le jeu. 3 janv. 2019 à 13:19, Hans Petter Selasky a écrit :
On 1/3/19 12:35 PM, Matthias Apitz wrote:
but is doing so 3000++ times:
$ dmesg | grep 'PID 544' | wc -l
I hope this email will go to freebsd-usb@ since I am not a member of this list.
Le jeu. 3 janv. 2019 à 13:19, Hans Petter Selasky a écrit :
>
> On 1/3/19 12:35 PM, Matthias Apitz wrote:
> > but is doing so 3000++ times:
> >
> > $ dmesg | grep 'PID 544' | wc -l
> > 3441
> >
> > This proc is
On 1/3/19 12:35 PM, Matthias Apitz wrote:
but is doing so 3000++ times:
$ dmesg | grep 'PID 544' | wc -l
3441
This proc is started by devd(8) with that devd(8) hook:
Hi,
Basically pcscd is congesting the enumeration SX lock, preventing
usbconfig from running because it tries to open
El día jueves, enero 03, 2019 a las 11:03:26a. m. +0100, Hans Petter Selasky
escribió:
> On 1/3/19 10:48 AM, Matthias Apitz wrote:
> > Is there a way log log any init call to libusb.so to see which process
> > is doing something with libusb.so after devd(8) started pcscd?
>
> Hi,
>
> You can
On 1/3/19 10:48 AM, Matthias Apitz wrote:
Is there a way log log any init call to libusb.so to see which process
is doing something with libusb.so after devd(8) started pcscd?
Hi,
You can add a print in the kernel sys/dev/usb/usb_generic.c in the function:
static int
ugen_open(struct
El día jueves, enero 03, 2019 a las 09:31:53a. m. +0100, Hans Petter Selasky
escribió:
> On 1/3/19 7:04 AM, Matthias Apitz wrote:
> > I think, we should isolate the problem from PCSC and focus (first) on the
> > question why are calls to usbconfig(8) are not answered anymore
> > *without* any
On 1/3/19 7:04 AM, Matthias Apitz wrote:
I think, we should isolate the problem from PCSC and focus (first) on the
question why are calls to usbconfig(8) are not answered anymore
*without* any kind of PCSC software being involved as I wrote in the
originating email of this thread. Here it is
El día miércoles, enero 02, 2019 a las 05:04:42p. m. +0100, Hans Petter Selasky
escribió:
> Let's move this thread freebsd-usb only.
>
> Have a look here:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231076
I read carefully through the PR 231076 (and deleted freebsd-current from
the
El día miércoles, enero 02, 2019 a las 06:15:18p. m. +0100, Hans Petter Selasky
escribió:
> On 1/2/19 6:14 PM, Matthias Apitz wrote:
> > On Wed, 2 Jan 2019 16:57:44 +0100, Hans Petter Selasky wrote:
> >> On 1/2/19 4:47 PM, Matthias Apitz wrote:
> >>> After card removal and insert devd(8) starts
On 1/2/19 6:14 PM, Matthias Apitz wrote:
On Wed, 2 Jan 2019 16:57:44 +0100, Hans Petter Selasky wrote:
On 1/2/19 4:47 PM, Matthias Apitz wrote:
After card removal and insert devd(8) starts a new pcsd:
Does pcsd install this devd(8) rule? I thought pcsd would no longer
need to be restarted.
On Wed, 2 Jan 2019 16:57:44 +0100, Hans Petter Selasky wrote:
> On 1/2/19 4:47 PM, Matthias Apitz wrote:
>> After card removal and insert devd(8) starts a new pcsd:
>
> Does pcsd install this devd(8) rule? I thought pcsd would no longer
> need to be restarted.
>
They are made and used for years
On 1/2/19 4:57 PM, Hans Petter Selasky wrote:
On 1/2/19 4:47 PM, Matthias Apitz wrote:
After card removal and insert devd(8) starts a new pcsd:
Does pcsd install this devd(8) rule? I thought pcsd would no longer need
to be restarted. >
Let's move this thread freebsd-usb only.
Have a look
On 1/2/19 4:47 PM, Matthias Apitz wrote:
After card removal and insert devd(8) starts a new pcsd:
Does pcsd install this devd(8) rule? I thought pcsd would no longer
need to be restarted.
--HPS
___
freebsd-usb@freebsd.org mailing list
El día miércoles, enero 02, 2019 a las 12:37:37p. m. +0100, Hans Petter Selasky
escribió:
> > Nothing. Only on boot it sees the card:
>
> And you are using the latest version of pcsd ?
Yes. Compiled with all ports from December 23.
>
> > Jan 2 11:25:39 c720-r342378 kernel: ugen0.1: <0x8086
On 1/2/19 11:48 AM, Matthias Apitz wrote:
El día miércoles, enero 02, 2019 a las 09:44:06a. m. +0100, Hans Petter Selasky
escribió:
On 1/1/19 2:51 PM, Matthias Apitz wrote:
Now with r342378, it works only after boot but not after withdraw/re-insert
anymore. To separate the problem from GnuPG
On 1/1/19 2:51 PM, Matthias Apitz wrote:
Now with r342378, it works only after boot but not after withdraw/re-insert
anymore. To separate the problem from GnuPG and it's software stack, I have
here some
small tests with usbconfig(8). First usbconfig reads fine the bus, but then
it takes 3-5
26 matches
Mail list logo
