Re: moxa uport 1110 RS232 USB to serial support?

2016-11-18 Thread Marko Cupać 
On Fri, 18 Nov 2016 14:28:58 +0100
Arrigo Marchiori via freebsd-stable  wrote:

> Hello,
> 
> I am resending this reply message to the freebsd-usb@ and
> freebsd-stable@ mailing list, because it bounced back to me after one
> day.
>
> I am afraid that the short answer is «no».
> 
> For what I could find on-line:
> 
>  - the Moxa UPort 1110 driver for Linux is the same as the Texas
>Instruments TUSB3410
>(source:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/serial?id=b923c6c62981cec5e2d2187fd700c2fc4386fc45)
> 
>  - the port comms/uticom was a driver for the TUSB3410, but it was
>deprecated, and removed three years ago.
>FreeBSD forum thread: https://forums.freebsd.org/threads/18151/
>Port information: http://www.freshports.org/comms/uticom
>SourceForge page: https://sourceforge.net/projects/uticom/
> 
> I hope this helps.

Arrigo,

it does help, thank you. I'm not subscribed to freebsd-usb, but I'm
gonna check archives to see if there are any follow-ups.

I am not sure, but I think I used this adapter on OpenBSD without the
need to install additional packages. Moxa Uport 1110 is also in
OpenBSD's usbdevs.h:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/usb/usbdevs.h?rev=1.683=text/plain

Perhaps someone with much more knowledge than me would be able to port
this to FreeBSD?
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: moxa uport 1110 RS232 USB to serial support?

2016-11-18 Thread Arrigo Marchiori via freebsd-stable 
Hello,

I am resending this reply message to the freebsd-usb@ and
freebsd-stable@ mailing list, because it bounced back to me after one
day.

On Thu, Nov 17, 2016 at 10:08:44AM +0100, Marko Cupać wrote:

> Hi,
> 
> is it possible to use Moxa Uport 1110 USB to serial adapter on FreeBSD
> 11.0?
> http://www.moxa.com/product/uport_1110.htm

I am afraid that the short answer is «no».

For what I could find on-line:

 - the Moxa UPort 1110 driver for Linux is the same as the Texas
   Instruments TUSB3410
   (source: 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/serial?id=b923c6c62981cec5e2d2187fd700c2fc4386fc45)

 - the port comms/uticom was a driver for the TUSB3410, but it was
   deprecated, and removed three years ago.
   FreeBSD forum thread: https://forums.freebsd.org/threads/18151/
   Port information: http://www.freshports.org/comms/uticom
   SourceForge page: https://sourceforge.net/projects/uticom/

I hope this helps.
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-18 Thread Henri Hennebert 



On 11/18/2016 13:30, Andriy Gapon wrote:

On 14/11/2016 14:00, Henri Hennebert wrote:

On 11/14/2016 12:45, Andriy Gapon wrote:

Okay.  Luckily for us, it seems that 'm' is available in frame 5.  It also
happens to be the first field of 'struct faultstate'.  So, could you please go
to frame and print '*m' and '*(struct faultstate *)m' ?


(kgdb) fr 4
#4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, wmesg=) at /usr/src/sys/vm/vm_page.c:753
753msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0);
(kgdb) print *m
$1 = {plinks = {q = {tqe_next = 0xf800dc5d85b0, tqe_prev =
0xf800debf3bd0}, s = {ss = {sle_next = 0xf800dc5d85b0},
  pv = 0xf800debf3bd0}, memguard = {p = 18446735281313646000, v =
18446735281353604048}}, listq = {tqe_next = 0x0,
tqe_prev = 0xf800dc5d85c0}, object = 0xf800b62e9c60, pindex = 11,
phys_addr = 3389358080, md = {pv_list = {
  tqh_first = 0x0, tqh_last = 0xf800df68cd78}, pv_gen = 426, pat_mode =
6}, wire_count = 0, busy_lock = 6, hold_count = 0,
  flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0 '\0',
segind = 3 '\003', order = 13 '\r',
  pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'}


If I interpret this correctly the page is in the 'exclusive busy' state.
Unfortunately, I can't tell much beyond that.
But I am confident that this is the root cause of the lock-up.


(kgdb) print *(struct faultstate *)m
$2 = {m = 0xf800dc5d85b0, object = 0xf800debf3bd0, pindex = 0, first_m =
0xf800dc5d85c0,
  first_object = 0xf800b62e9c60, first_pindex = 11, map = 0xca058000, entry
= 0x0, lookup_still_valid = -546779784,
  vp = 0x601aa}
(kgdb)


I was wrong on this one as 'm' is actually a pointer, so the above is not
correct.  Maybe 'info reg' in frame 5 would give a clue about the value of 'fs'.


(kgdb) fr 5
#5  0x8089dd4d in vm_page_sleep_if_busy (m=0xf800df68cd40, 
msg=0x809c51bc "vmpfw")

at /usr/src/sys/vm/vm_page.c:1086
1086vm_page_busy_sleep(m, msg);
(kgdb) info reg
rax0x0  0
rbx0xf800b62e9c78   -8793036514184
rcx0x0  0
rdx0x0  0
rsi0x0  0
rdi0x0  0
rbp0xfe0101836810   0xfe0101836810
rsp0xfe01018367e0   0xfe01018367e0
r8 0x0  0
r9 0x0  0
r100x0  0
r110x0  0
r120xf800b642aa00   -879303520
r130xf800df68cd40   -8792344834752
r140xf800b62e9c60   -8793036514208
r150x809c51bc   -2137239108
rip0x8089dd4d	0x8089dd4d 


eflags 0x0  0
cs 0x0  0
ss 0x0  0
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0

I don't know what to do from here.


I am not sure how to proceed from here.
The only thing I can think of is a lock order reversal between the vnode lock
and the page busying quasi-lock.  But examining the code I can not spot it.
Another possibility is a leak of a busy page, but that's hard to debug.

How hard is it to reproduce the problem?


After 7 days all seems normal only one copy of innd:

[root@avoriaz ~]# ps xa|grep inn
 1193  -  Is   0:01.40 /usr/local/news/bin/innd -r
13498  -  IN   0:00.01 /usr/local/news/bin/innfeed
 1194 v0- IW   0:00.00 /bin/sh /usr/local/news/bin/innwatch -i 60

I will try to stop and restart innd.

All continue to look good:

[root@avoriaz ~]# ps xa|grep inn
31673  -  Ss   0:00.02 /usr/local/news/bin/innd
31694  -  SN   0:00.01 /usr/local/news/bin/innfeed
31674  0  S0:00.01 /bin/sh /usr/local/news/bin/innwatch -i 60


I think to reproduce is just waiting it occurs by itself...

One thing here: The deadlock occurs at least 5 times since 10.0R. And 
always with the directory /usr/local/news/bin




Maybe Konstantin would have some ideas or suggestions.



Henri
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-18 Thread Andriy Gapon 
On 14/11/2016 14:00, Henri Hennebert wrote:
> On 11/14/2016 12:45, Andriy Gapon wrote:
>> Okay.  Luckily for us, it seems that 'm' is available in frame 5.  It also
>> happens to be the first field of 'struct faultstate'.  So, could you please 
>> go
>> to frame and print '*m' and '*(struct faultstate *)m' ?
>>
> (kgdb) fr 4
> #4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, 
> wmesg= optimized out>) at /usr/src/sys/vm/vm_page.c:753
> 753msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0);
> (kgdb) print *m
> $1 = {plinks = {q = {tqe_next = 0xf800dc5d85b0, tqe_prev =
> 0xf800debf3bd0}, s = {ss = {sle_next = 0xf800dc5d85b0},
>   pv = 0xf800debf3bd0}, memguard = {p = 18446735281313646000, v =
> 18446735281353604048}}, listq = {tqe_next = 0x0,
> tqe_prev = 0xf800dc5d85c0}, object = 0xf800b62e9c60, pindex = 11,
> phys_addr = 3389358080, md = {pv_list = {
>   tqh_first = 0x0, tqh_last = 0xf800df68cd78}, pv_gen = 426, pat_mode 
> =
> 6}, wire_count = 0, busy_lock = 6, hold_count = 0,
>   flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0 
> '\0',
> segind = 3 '\003', order = 13 '\r',
>   pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'}

If I interpret this correctly the page is in the 'exclusive busy' state.
Unfortunately, I can't tell much beyond that.
But I am confident that this is the root cause of the lock-up.

> (kgdb) print *(struct faultstate *)m
> $2 = {m = 0xf800dc5d85b0, object = 0xf800debf3bd0, pindex = 0, 
> first_m =
> 0xf800dc5d85c0,
>   first_object = 0xf800b62e9c60, first_pindex = 11, map = 0xca058000, 
> entry
> = 0x0, lookup_still_valid = -546779784,
>   vp = 0x601aa}
> (kgdb)

I was wrong on this one as 'm' is actually a pointer, so the above is not
correct.  Maybe 'info reg' in frame 5 would give a clue about the value of 'fs'.

I am not sure how to proceed from here.
The only thing I can think of is a lock order reversal between the vnode lock
and the page busying quasi-lock.  But examining the code I can not spot it.
Another possibility is a leak of a busy page, but that's hard to debug.

How hard is it to reproduce the problem?

Maybe Konstantin would have some ideas or suggestions.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"