Re: qlnxe driver not in 13.0 arm64

[Hans Petter Selasky]

On 3/30/21 8:31 PM, John-Mark Gurney wrote:

Daniel Morante via freebsd-stable wrote this message on Sun, Mar 28, 2021 at 
03:23 -0400:

I installed 13.0-RC3 ARM64 from the DVD ISO image
(FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso
).
There is no "if_qlnxe" kernel model present on the install media, or on
the system after installing.

Next I try to build a custom kernel. I add "device qlnxe" to the
configuration file as instructed in
https://www.freebsd.org/cgi/man.cgi?query=qlnxe=FreeBSD+13.0-current.


Running "make buildkernel KERNCONF=THUNDERX2" results in:

config: Error: device "qlnxe" is unknown

Is this module not available for ARM64 architecture?


Correct, this is only available for amd64.

HPS might have some more insight as to why it's amd64 only.

I have cc'd him.

It could be as simple as moving the qlnxe lines from files.amd64 to files,
but it does appear that qnlxe depends upon the Linux compat layer, which
may not be complete for arm64..



The LinuxKPI works for ARM64 aswell. Maybe the QLNXE driver is not 
tested for ARM64.


--HPS
___
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: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!)

[Hans Petter Selasky]

Hi Allan,

Can ZFS use atomic_add_64() in the kernel for i386 instead of building 
its own variant?


--HPS

On 2019-07-25 13:13, Peter wrote:

Hi Hans Petter,
  glad to read You! :)
  
On Thu, Jul 25, 2019 at 09:39:26AM +0200, Hans Petter Selasky wrote:

! On 2019-07-25 01:00, Peter wrote:

! >> The offending feature is either
! >> options ZFS
! >> or
! >> device dtrace
! >> (Adding any of these to the GENERIC config gives the same error.)

! Can you attach your kernel configuration file?

Yes, but to what point?
I can reproduce this with the GENERIC configuration by adding
   "options ZFS"

(My custom KERNCONF relates to my local patches, and is rather
pointless without these. So at first I tried to reproduce without
my local patches and with minimal changes from GENERIC config. And
the minimal change is to add "options ZFS" into the GENERIC conf.)

See here:

root@disp:/usr/src/sys/i386/compile/GENERIC # make
linking kernel.full
atomic.o: In function `atomic_add_64':
/usr/src/sys/i386/compile/GENERIC/./machine/atomic.h:629: multiple definition 
of `atomic_add_64'
opensolaris_atomic.o:/usr/src/sys/i386/compile/GENERIC/../../../cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71:
 first defined here
*** Error code 1

Stop.
make: stopped in /usr/src/sys/i386/compile/GENERIC
root@disp:/usr/src/sys/i386/compile/GENERIC #

root@disp:/usr/src/sys/i386/compile/GENERIC # cd ../../../..
root@disp:/usr/src # svn stat
M   sys/i386/conf/GENERIC
root@disp:/usr/src # svn diff
Index: sys/i386/conf/GENERIC
===
--- sys/i386/conf/GENERIC   (revision 350287)
+++ sys/i386/conf/GENERIC   (working copy)
@@ -1,3 +1,4 @@
+options ZFS
  #
  # GENERIC -- Generic kernel configuration file for FreeBSD/i386
  #

root@disp:/usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-east.freebsd.org/base/releng/11.3
Relative URL: ^/releng/11.3
Repository Root: https://svn0.us-east.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 350287
Node Kind: directory
Schedule: normal
Last Changed Author: gordon
Last Changed Rev: 350287
Last Changed Date: 2019-07-24 12:58:21 + (Wed, 24 Jul 2019)





___
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: Rel. 11.3: Kernel doesn't compile anymore (SVN-334762, please fix!)

[Hans Petter Selasky]

On 2019-07-25 01:00, Peter wrote:

Trying to compile my custom kernel in Rel. 11.3 results in this:

-- kernel.full ---
linking kernel.full
atomic.o: In function `atomic_add_64':
/usr/obj/usr/src/sys/E1R11V1/./machine/atomic.h:629: multiple definition of 
`atomic_add_64'
opensolaris_atomic.o:/usr/src/sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S:71:
 first defined here
*** [kernel.full] Error code 1

Same config worked with 11.2

The offending feature is either
options ZFS
or
device dtrace
(Adding any of these to the GENERIC config gives the same error.)

This happens only when building for i386. Building amd64 with these
options works.



Trying to analyze the issue:


The problem appears with SVN 334762 in 11.3:

This change adds two new functions to sys/i386/include/atomic.h:
atomic_add_64()
atomic_subtract_64()
[I don't really understand why this goes into a headerfile, but, well,
nevermind]

Also, this change deactivates two functions (only in case *i386*) from
sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c
atomic_add_64()
atomic_del_64()
[Now, there seems to be a slight strangeness here: if we *deactivate*
atomic_del_64(), and *insert* atomic_subtract_64(), then these two
names are not the same, and I might suppose that the atomic_del_64()
is then somehow missing. But, well, nevermind]

Now, the strange thing:
this file sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c
from which now two functions get excluded *only in case i386*, is not
even compiled for i386:


/usr/src/sys/conf$ grep opensolaris_atomic.c *
files.arm:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional zfs | dtrace 
compile-with "${CDDL_C}"
files.mips:cddl/compat/opensolaris/kern/opensolaris_atomic.coptional zfs | dtrace 
compile-with "${CDDL_C}"
files.powerpc:cddl/compat/opensolaris/kern/opensolaris_atomic.c optional 
zfs powerpc | dtrace powerpc compile-with "${ZFS_C}"
files.riscv:cddl/compat/opensolaris/kern/opensolaris_atomic.c   optional zfs | dtrace 
compile-with "${CDDL_C}"


[So maybe that's the reason why the now lack of atomic_del_64() is not
complained? Or maybe it's not used, or maybe I didn't find some
definition whereever. Well, nevermind]


Anyway, the actual name clash happens between
sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S,
because that one *is* compiled:


/usr/src/sys/conf$ grep i386/opensolaris_atomic.S *
files.i386:cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S optional 
zfs | dtrace compile-with "${ZFS_S}"



I tried to move out the changes from SVN 334762. Sadly, that didn't
work, because something does already use these atomic_add_64() stuff,

So instead, I did this one:

--- sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S
(revision 350287)
+++ sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S
(working copy)
@@ -66,8 +66,7 @@
  * specific mapfile and remove the NODYNSORT attribute
  * from atomic_add_64_nv.
  */
-   ENTRY(atomic_add_64)
-   ALTENTRY(atomic_add_64_nv)
+   ENTRY(atomic_add_64_nv)
 pushl   %edi
 pushl   %ebx
 movl12(%esp), %edi  // %edi = target address
@@ -87,7 +86,6 @@
 popl%edi
 ret
 SET_SIZE(atomic_add_64_nv)
-   SET_SIZE(atomic_add_64)
  
 ENTRY(atomic_or_8_nv)

 movl4(%esp), %edx   // %edx = target address


And at least it compiles now. If it actually runs, that remains to be
found out.


Can you attach your kernel configuration file?

--HPS

___
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: drm / drm2 removal in 12

[Hans Petter Selasky]

On 8/26/18 3:20 AM, blubee blubeeme wrote:

Have you or anyone working on this drm-legacy-kmod stuff done any testings
of how this will affect current users?


Hi Blubee,

Are you here to try to stir a conflict?
If so that is not appreciated.

--HPS
___
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: [HEADS UP] - OFED/RDMA stack update

[Hans Petter Selasky]

On 03/20/18 21:07, Navdeep Parhar wrote:

And what about the cxgb breakage?  Is there any simple way to make an
old style driver work with the new stack?  T3 iw_cxgb in head was
retired before the ofed overhaul.


Hi,

The most simple way is to pull this driver from Linux 4.9, including 
libcxgb for user-space, if possible, though I'm not sure about the 
FreeBSD specific areas of iWarp and socket handling. I think you know 
that part better than I do.


After pulling from Linux 4.9 you need to extend this change to cover the 
iw_cxgb:


https://svnweb.freebsd.org/changeset/base/330508

Or can you retire iw_cxgb?

--HPS
___
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: [HEADS UP] - OFED/RDMA stack update

[Hans Petter Selasky]

On 03/17/18 20:52, Navdeep Parhar wrote:

Hold your horses.  Do you have confirmation from the affected party that
the shims are adequate for them?  I have been waiting for that before
looking at this branch.


Hi Navdeep,

Mellanox has received an API list from at least one party, and has taken 
the action to support all the required APIs.



Is the iw_cxgbe breakage a simple merge conflict as previously discussed
or do the shims require driver changes?  


It is a merge conflict. The code already compiles in 12-current.


If they don't then it should be
possible to drop the iw_cxgbe from head into this branch and it should
just work, is that correct?


Yes, it shouldn't be too hard to do and I would appreciate if Chelsio 
could throw some resources at this ASAP. I believe the new code will 
benefit everyone using Infiniband/RoCE and iWarp with FreeBSD.


--HPS
___
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: [HEADS UP] - OFED/RDMA stack update

[Hans Petter Selasky]

Hi,

The bsd_rdma_4_9_stable_11 projects branch is close to being merged into 
FreeBSD 11-stable. Mellanox plans to merge no later than 12:00 CEST TUE 
20th of March 2018, unless objections are received.


A compatibility header file has been created, ib_verbs_compat.h, which 
offers full source compatibility to existing OFED kernel applications, 
as a response to the raised conserns. User-space compatibility is 
maintained through library symbol versioning.


https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/ofed/include/rdma/ib_verbs_compat.h

An example client for this header file can be found here:

https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/contrib/rdma/krping_compat/

Currently the cxgb and cxgbe i-Warp drivers are not building, and will 
be stubbed from the kernel build before the branch is merged, unless 
Chelsio can add patches for these.


Here is a quick and dirty patch to make the bsd_rdma_4_9_stable_11 
branch build:



diff --git a/sys/modules/Makefile b/sys/modules/Makefile
index 6b005c854d7..b918a208f21 100644
--- a/sys/modules/Makefile
+++ b/sys/modules/Makefile
@@ -530,7 +530,7 @@ _txp=   txp
 .if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
${MACHINE_ARCH:C/mips(el)?/mips/} != "mips" && \
${MACHINE_ARCH} != "powerpc" && ${MACHINE_CPUARCH} != "riscv"
-_cxgbe=cxgbe
+#_cxgbe=   cxgbe
 .endif
 
 .if ${MK_TESTS} != "no" || defined(ALL_MODULES)

@@ -554,7 +554,7 @@ _vpo=   vpo
 _sym=  sym
 # intr_disable() is a macro, causes problems
 .if ${MK_SOURCELESS_UCODE} != "no"
-_cxgb= cxgb
+#_cxgb=cxgb
 .endif
 .endif


--HPS
___
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: [CFT] [X11] graphics/drm-next-kmod now builds, loads and works on FreeBSD-11-stable

[Hans Petter Selasky]

On 02/18/18 23:27, Kevin Oberman wrote:

On Sun, Feb 18, 2018 at 12:35 PM, Hans Petter Selasky <h...@selasky.org>
wrote:


Hi FreeBSD desktop users!

During the past week and over the weekend all parts needed for building,
loading and using graphics/drm-next-kmod on FreeBSD-11-stable have been
completed!

A big thanks to all the people contributing to graphics support under
FreeBSD in both kernel and user-space! You'll find their names in the
commit logs including myself :-)

Links:
https://www.freshports.org/graphics/drm-next-kmod
https://svnweb.freebsd.org/changeset/base/329527

Issues are reported here:
https://github.com/FreeBSDDesktop/kms-drm/issues

--HPS



Hi Kevin,



Wow! That is awesome. Thanks to all of the contributors.


Thank you!



Any instructions? Am I right that the mod setting driver should generally
be used. None of the links above really covers implementation.


I believe the package when you install it will give you some 
instructions in the pkg-message.


Basically:

portsnap fetch update

Make sure your kernel sources in /usr/src .
cd /usr/src
make buildkernel -jX
make installkernel -jX

cd /usr/ports/graphics/drm-next-kmod
make all install clean

Edit /etc/rc.conf and add for example:

kld_list="i915kms"

Then reboot and twin your thumbs.

If it fails goto single user mode.

mount -a

Edit /etc/rc.conf and remove the kld_list=...
Save and type exit.

Before starting X.org you should have the correct xf86-video-xxx drivers 
installed, because then 2D and 3D acceleration will activate.


A quick tip for tear-free video with intel drivers:

cat /usr/local/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
   Identifier  "Device0"
   Driver "intel"
   Option "AccelMethod" "sna"
   Option "TearFree" "true"
EndSection

--HPS
___
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"

[CFT] [X11] graphics/drm-next-kmod now builds, loads and works on FreeBSD-11-stable

[Hans Petter Selasky]

Hi FreeBSD desktop users!

During the past week and over the weekend all parts needed for building, 
loading and using graphics/drm-next-kmod on FreeBSD-11-stable have been 
completed!


A big thanks to all the people contributing to graphics support under 
FreeBSD in both kernel and user-space! You'll find their names in the 
commit logs including myself :-)


Links:
https://www.freshports.org/graphics/drm-next-kmod
https://svnweb.freebsd.org/changeset/base/329527

Issues are reported here:
https://github.com/FreeBSDDesktop/kms-drm/issues

--HPS
___
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"

[HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

[Hans Petter Selasky]

Hi,

The change will happen this week.
This is part of ongoing work in FreeBSD 11-stable.

Make sure to update your /boot/loader.conf by adding
mlx4en_load="YES" if you are using the mlxen.ko kernel modules.

--HPS
___
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: panic when loading mlxen

[Hans Petter Selasky]

Hi,

I think Alexander came ahead of me:

https://svnweb.freebsd.org/base?view=revision=328805

Can you try r328805 ?

--HPS
___
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: panic when loading mlxen

[Hans Petter Selasky]

On 02/03/18 08:34, Daniel Braniss wrote:




On 2 Feb 2018, at 20:47, K. Macy  wrote:

That's odd since it doesn't use any of taskqgroup stuff. I take it you
can't get a core?


no core but some more info:
db> bt
Tracing pid 0 tid 10 td 0x81e0e500
taskqgroup_attach_cpu() at taskqgroup_attach_cpu+0x4f/frame 0x822e4c30
tasklet_subsystem_init() at tasklet_subsystem_init+0xde/frame 0x822e4c90
mi_startup() at mi_startup+0x9c/frame 0x822e4cb0
btext() at btext+0x2c



Also, why are you loading it in loader.conf (slower) as opposed to rc.conf?

sometimes it’s booted diskless, and the driver is needed early.
and btw, this box doesn’t even have a mellanox card.



-M



On Fri, Feb 2, 2018 at 4:46 AM, Daniel Braniss  wrote:

with latest stable (r328769) when I have
mlxen_load=“YES”
in my loader.conf it panics:

KDB: debugger backends: ddbsize 0x4638 at 0x22d6000 
f
KDB: current backend: ddb
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-STABLE #18: Fri Feb  2 10:46:12 IST 2018
   danny@pe-44:/home/obj/pe-44/net/rnd/r+d/stable/11/sys/HUJI amd64
FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 
5.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Xeon(R) CPU   E5507  @ 2.27GHz (2261.04-MHz K8-class CPU)
Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
Features=0xbfebfbff
Features2=0x9ce3bd
AMD Features=0x28100800
AMD Features2=0x1
VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
TSC: P-state invariant, performance statistics
real memory  = 25769803776 (24576 MB)
avail memory = 24931561472 (23776 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
ioapic1: Changing APIC ID to 1
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 32-55 on motherboard


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address   = 0x1818
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x80ad427f
stack pointer   = 0x28:0x822e3be0
frame pointer   = 0x28:0x822e3c30
code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at  taskqgroup_attach_cpu+0x4f: lock cmpxchgq   %r12,(%rdi)


Hi,

It should work if you "kldload mlxen" after boot or add it to kld_list 
in /etc/rc.conf. Looks like I have one more combination to test after 
the LinuxKPI upgrade in 11-stable. Thanks for notifying me.


--HPS
___
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: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1

[Hans Petter Selasky]

Hi,

I just upgraded and hit these SEGFAULTs too. First of all you need to 
install GDB 8.0 from ports to get the right backtrace (important). This 
leads straight into LibUnwind in libgcc:


(gdb) bt
#0  uw_frame_state_for (context=context@entry=0x7fffdf3bbe20, 
fs=fs@entry=0x7fffdf3bbb70)

at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
#1  0x000802cc8ffb in _Unwind_ForcedUnwind_Phase2 
(exc=exc@entry=0x804427230,
context=context@entry=0x7fffdf3bbe20) at 
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
#2  0x000802cc9334 in _Unwind_ForcedUnwind (exc=0x804427230, 
stop=0x8024d5450 ,
stop_argument=) at 
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
#3  0x0008024d52b3 in _Unwind_ForcedUnwind (ex=, 
stop_func=0x7fffdf3bb948, stop_arg=0x804427000)

at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:106
#4  thread_unwind () at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:172
#5  _pthread_exit_mask (status=, mask=)
at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:257
#6  0x0008024d50db in _pthread_exit (status=0x804427000) at 
/usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:206

#7  0x0008024c7c0d in thread_start (curthread=0x804427000)
at /usr/img/freebsd.11/lib/libthr/thread/thr_create.c:289
#8  0x7fffdf34 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdf3bc000

libgcc uses this format which is OK:

(gdb) ptype struct _Unwind_Context
type = struct _Unwind_Context {
_Unwind_Context_Reg_Val reg[18];
void *cfa;
void *ra;
void *lsda;
struct dwarf_eh_bases bases;
_Unwind_Word flags;
_Unwind_Word version;
_Unwind_Word args_size;
char by_value[18];
}


x86_64_freebsd_fallback_frame_state
(struct _Unwind_Context *context, _Unwind_FrameState *fs)
{
  struct sigframe *sf;
  long new_cfa;

  /* Prior to FreeBSD 9, the signal trampoline was located immediately
 before the ps_strings.  To support non-executable stacks on AMD64,
 the sigtramp was moved to a shared page for FreeBSD 9.  Unfortunately
 this means looking frame patterns again (sys/amd64/amd64/sigtramp.S)
 rather than using the robust and convenient KERN_PS_STRINGS trick.

 :  lea 0x10(%rsp),%rdi
 :  pushq   $0x0
 :  mov $0x1a1,%rax
 :  syscall

 If we can't find this pattern, we're at the end of the stack.
  */

  if (!(   *(unsigned int *)(context->ra)  == 0x247c8d48

  fault is triggered by this read access on the stack

&& *(unsigned int *)(context->ra +  4) == 0x48006a10
&& *(unsigned int *)(context->ra +  8) == 0x01a1c0c7
&& *(unsigned int *)(context->ra + 12) == 0x050f ))
return _URC_END_OF_STACK;



The code in question is trying to access the return address of the 
caller on the stack which apparently I think is caught by the recently 
added MAP_GUARD feature:


https://svnweb.freebsd.org/changeset/base/320763

I think this feature can be disabled by setting:
sysctl security.bsd.stack_guard_page=0

And then restart Asterisk. Not sure if it helps, currently testing.
This my best guess why Asterisk started segfaulting when upgrading to 11.1.

--HPS
___
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: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1

[Hans Petter Selasky]

On 09/19/17 01:57, Tao Zhou wrote:

On 18/9/17 5:40 pm, Hans Petter Selasky wrote:

There is a known issue with the latest version of Asterisk 13.xxx 
crashing. I don't know the root cause. Try downgrading the Asterisk 
version. You probably should compile all code with debug flags enabled 
if you want to find the root cause of this. 


In our environment the crash happen almost always within two minutes. No 
calls or other activity are needed to make the crash happen.



Things that didn't help:

* downgrading asterisk13 to 13.17 or 13.16
* downgrading gcc5 or upgrading it to gcc6
* disabling all modules
* compiling asterisk13 with GCC or CLANG
* upgrading the poudriere build environment from 11.0 to 11.1

Thing that helped

* installing astersisk 13.16 from https://pkg.freebsd.org
(All our previous attempts were with software which was compiled locally 
on poudriere under FreeBSD 11.1 or 11.0)




Try to do an ldd diff on the resulting binaries. Or check the list of 
installed Asterisk modules. Maybe there are some leftover libraries or 
asterisk modules which weren't deleted when the port was upgraded.


--HPS

___
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: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1

[Hans Petter Selasky]

On 09/18/17 09:39, Tao Zhou wrote:
I recently upgraded asterisk13 from 13.17.0_1 to 13.17.1, and also 
upgraded freebsd from 11.0 to 11.1. since then asterisk starts crashing 
every few minutes.


I ran /usr/local/share/asterisk/scripts/ast_coredumper /tmp/asterisk.core

and got the following result in asterisk.core-full.txt


Thread 6 (LWP 101423):
#0  0x00080335558a in _poll () from /lib/libc.so.7
No symbol table info available.
#1  0x00080303e706 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2  0x004506b2 in ?? ()
No symbol table info available.
#3  0x005921ea in ?? ()
No symbol table info available.
#4  0x00080303bbc5 in ?? () from /lib/libthr.so.3
No symbol table info available.
#5  0x in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfe0a000

Thread 5 (LWP 101336):
#0  0x000803049c7c in ?? () from /lib/libthr.so.3
No symbol table info available.
#1  0x000803046325 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2  0x00589d18 in ?? ()
No symbol table info available.
#3  0x004552f1 in ?? ()
No symbol table info available.
#4  0x004552f1 in ?? ()
No symbol table info available.
#5  0x00589c4b in ?? ()
No symbol table info available.
#6  0x0058318e in ast_taskprocessor_execute ()
No symbol table info available.
#7  0x005832de in ?? ()
No symbol table info available.
#8  0x005921ea in ?? ()
No symbol table info available.
#9  0x00080303bbc5 in ?? () from /lib/libthr.so.3
No symbol table info available.
#10 0x in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdff04000

Thread 4 (LWP 101240):
#0  0x0008032d88b8 in _umtx_op () from /lib/libc.so.7
No symbol table info available.
#1  0x0008032c275d in sem_clockwait_np () from /lib/libc.so.7
No symbol table info available.
#2  0x005832c8 in ?? ()
No symbol table info available.
#3  0x005921ea in ?? ()
No symbol table info available.
#4  0x00080303bbc5 in ?? () from /lib/libthr.so.3
No symbol table info available.
#5  0x in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdff81000

Thread 3 (LWP 101183):
#0  0x000803049c7c in ?? () from /lib/libthr.so.3
No symbol table info available.
#1  0x00080303dba0 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2  0x0008030479f8 in ?? () from /lib/libthr.so.3
No symbol table info available.
#3  0x004c9756 in ?? ()
No symbol table info available.
#4  0x005921ea in ?? ()
No symbol table info available.
#5  0x00080303bbc5 in ?? () from /lib/libthr.so.3
No symbol table info available.
#6  0x in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7fffdfffe000

Thread 2 (LWP 100441):
#0  0x00080335558a in _poll () from /lib/libc.so.7
No symbol table info available.
#1  0x00080303e706 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2  0x00452980 in ?? ()
No symbol table info available.
#3  0x00436483 in ?? ()
No symbol table info available.
#4  0x00437b1f in ?? ()
No symbol table info available.
#5  0x000800876000 in ?? ()
No symbol table info available.
#6  0x in ?? ()
No symbol table info available.

Thread 1 (LWP 100493):
#0  x86_64_freebsd_fallback_frame_state (context=0x7fffdfd0fe20, 
context=0x7fffdfd0fe20, fs=0x7fffdfd0fb70) at ./md-unwind-support.h:60

 sf = 
 new_cfa = 
#1  uw_frame_state_for (context=context@entry=0x7fffdfd0fe20, 
fs=fs@entry=0x7fffdfd0fb70) at 
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249

 fde = 0x0
 cie = 
 aug = 
 insn = 
 end = 
#2  0x000802e2cffb in _Unwind_ForcedUnwind_Phase2 
(exc=exc@entry=0x80701dc30, context=context@entry=0x7fffdfd0fe20) at 
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
 fs = {regs = {reg = {{loc = {reg = 0, offset = 0, exp = 0x0}, 
how = REG_UNSAVED} }, prev = 0x0, cfa_offset = 0, 
cfa_reg = 0, cfa_exp = 0x0, cfa_how = CFA_UNSET}, pc = 0x0, personality 
= 0x0, data_align = 0, code_align = 0, retaddr_column = 0, fde_encoding 
= 0 '000', lsda_encoding = 0 '000', saw_z = 0 '000', signal_frame = 0 
'000', eh_ptr = 0x0}

 action = 
 stop = 0x8030497b0
 stop_argument = 0x0
 code = 
 stop_code = 
#3  0x000802e2d334 in _Unwind_ForcedUnwind (exc=0x80701dc30, 
stop=0x8030497b0, stop_argument=) at 
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
 this_context = {reg = {0x7fffdfd0ff18, 0x7fffdfd0ff20, 0x0, 
0x7fffdfd0ff28, 0x0, 0x0, 0x7fffdfd0ff50, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x7fffdfd0ff30, 0x7fffdfd0ff38, 0x7fffdfd0ff40, 0x7fffdfd0ff48, 
0x7fffdfd0ff58, 0x0}, cfa = 0x7fffdfd0ff60, ra = 

Re: mlx4en, timer irq @100%... (11.0 stuck on high network load ???)

[Hans Petter Selasky]

On 08/08/17 13:56, Slawa Olhovchenkov wrote:

On Tue, Aug 08, 2017 at 01:49:08PM +0200, Hans Petter Selasky wrote:


On 08/08/17 13:33, Slawa Olhovchenkov wrote:

TW_RUNLOCK(V_tw_lock);
and
if (INP_INFO_TRY_WLOCK(_tcbinfo)) {

`inp` can be invalidated, freed and this pointer may be invalid?


If you look one line up there is a pcbref ??


Yes.
Can different thread take this inp and freed it?
May be timer thread?


No, it cannot be freed while there is a ref.

Some lines down the ref is dropped once the inp pointer is no longer needed.

--HPS
___
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: mlx4en, timer irq @100%... (11.0 stuck on high network load ???)

[Hans Petter Selasky]

On 08/08/17 13:33, Slawa Olhovchenkov wrote:

TW_RUNLOCK(V_tw_lock);
and
if (INP_INFO_TRY_WLOCK(_tcbinfo)) {

`inp` can be invalidated, freed and this pointer may be invalid?


If you look one line up there is a pcbref ??

--HPS
___
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: mlx4en, timer irq @100%... (11.0 stuck on high network load ???)

[Hans Petter Selasky]

On 08/08/17 10:06, Ben RUBSON wrote:

On 08 Aug 2017, at 10:02, Hans Petter Selasky <h...@selasky.org> wrote:

On 08/08/17 10:00, Ben RUBSON wrote:

kgdb) print *twq_2msl.tqh_first
$2 = {
   tw_inpcb = 0xf8031c570740,


print *twq_2msl.tqh_first->tw_inpcb


(kgdb) print *twq_2msl.tqh_first->tw_inpcb
$3 = {
   inp_hash = {
 le_next = 0x0,
 le_prev = 0xfe000f78adb8
   },
   inp_pcbgrouphash = {
 le_next = 0x0,
 le_prev = 0x0
   },
   inp_list = {
 le_next = 0xf80c2a07f570,
 le_prev = 0x81e15e20
   },
   inp_ppcb = 0xf80d1bf12210,
   inp_pcbinfo = 0x81e15e28,
   inp_pcbgroup = 0x0,
   inp_pcbgroup_wild = {
 le_next = 0x0,
 le_prev = 0x0
   },
   inp_socket = 0x0,
   inp_cred = 0xf804ae6ca400,
   inp_flow = 0,
   inp_flags = 92274688,
   inp_flags2 = 16,
   inp_vflag = 0 '\0',
   inp_ip_ttl = 64 '@',
   inp_ip_p = 0 '\0',
   inp_ip_minttl = 0 '\0',
   inp_flowid = 946611505,
   inp_refcount = 2,
   inp_pspare = 0xf8031c5707c0,
   inp_flowtype = 191,
   inp_rss_listen_bucket = 0,
   inp_ispare = 0xf8031c5707f0,
   inp_inc = {
 inc_flags = 0 '\0',
 inc_len = 0 '\0',
 inc_fibnum = 0,
 inc_ie = {
   ie_fport = 53987,
   ie_lport = 47873,
   ie_dependfaddr = {
 ie46_foreign = {
   ia46_pad32 = 0xf8031c570808,
   ia46_addr4 = {
 s_addr = 3011802202
   }
 },
 ie6_foreign = {
   __u6_addr = {
 __u6_addr8 = 0xf8031c570808 "",
 __u6_addr16 = 0xf8031c570808,
 __u6_addr32 = 0xf8031c570808
   }
 }
   },
   ie_dependladdr = {
 ie46_local = {
   ia46_pad32 = 0xf8031c570818,
   ia46_addr4 = {
 s_addr = 4068705883
   }
 },
 ie6_local = {
   __u6_addr = {
 __u6_addr8 = 0xf8031c570818 "",
 __u6_addr16 = 0xf8031c570818,
 __u6_addr32 = 0xf8031c570818
   }
 }
   },
   ie6_zoneid = 0
 }
   },
   inp_label = 0x0,
   inp_sp = 0x0,
   inp_depend4 = {
 inp4_ip_tos = 0 '\0',
 inp4_options = 0x0,
 inp4_moptions = 0x0
   },
   inp_depend6 = {
 inp6_options = 0x0,
 inp6_outputopts = 0x0,
 inp6_moptions = 0x0,
 inp6_icmp6filt = 0x0,
 inp6_cksum = 0,
 inp6_hops = 0
   },
   inp_portlist = {
 le_next = 0xf80274298ae0,
 le_prev = 0xf800454999b0
   },
   inp_phd = 0xf800454999a0,
   inp_gencnt = 2119756,
   inp_lle = 0x0,
   inp_lock = {
 lock_object = {
   lo_name = 0x814e6940 "tcpinp",
   lo_flags = 90898432,
   lo_data = 0,
   lo_witness = 0x0
 },
 rw_lock = 18446735277871559936
   },
   inp_rt_cookie = 10,
   inp_rtu = {
 inpu_route = {
   ro_rt = 0x0,
   ro_lle = 0x0,
   ro_prepend = 0x0,
   ro_plen = 0,
   ro_flags = 384,
   ro_mtu = 0,
   spare = 0,
   ro_dst = {
 sa_len = 16 '\020',
 sa_family = 2 '\002',
 sa_data = 0xf8031c5708f2 ""
   }
 },
 inpu_route6 = {
   ro_rt = 0x0,
   ro_lle = 0x0,
   ro_prepend = 0x0,
   ro_plen = 0,
   ro_flags = 384,
   ro_mtu = 0,
   spare = 0,
   ro_dst = {
 sin6_len = 16 '\020',
 sin6_family = 2 '\002',
 sin6_port = 0,
 sin6_flowinfo = 3011802202,
 sin6_addr = {
   __u6_addr = {
 __u6_addr8 = 0xf8031c5708f8 "",
 __u6_addr16 = 0xf8031c5708f8,
 __u6_addr32 = 0xf8031c5708f8
   }
 },
 sin6_scope_id = 0
   }
 }
   }
}
(kgdb)



Hi,

Here is the conclusion:

The following code is going in an infinite loop:



for (;;) {
TW_RLOCK(V_tw_lock);
tw = TAILQ_FIRST(_twq_2msl);
if (tw == NULL || (!reuse && (tw->tw_time - ticks) > 0)) {
TW_RUNLOCK(V_tw_lock);
break;
}
KASSERT(tw->tw_inpcb != NULL, ("%s: tw->tw_inpcb == NULL",
__func__));

inp = tw->tw_inpcb;
in_pcbref(inp);
TW_RUNLOCK(V_tw_lock);

if (INP_INFO_TRY_RLOCK(_tcbinfo)) {

INP_WLOCK(inp);
tw = intotw(inp);
if (in_pcbrele_wlocked(inp)) {


in_pcbrele_wlocked() returns (1) because INP_FREED (16) is set in 
inp->inp_flags2. I guess you have invariants disabled, because the 
KASSERT() below should have caused a panic.



KASSERT(tw == NULL, ("%s: held last inp "
"reference but tw not NULL", __func__));
INP_INFO_RUNLOCK(_tcbi

Re: [USB] hang after upgrade from 11.0 to 11.1, ZFS or callout() related?

[Hans Petter Selasky]

On 08/07/17 18:28, Michael Schmiedgen wrote:

dmesg:

Aug  7 18:26:34 antares kernel: usbd_pipe_enter: enter
Aug  7 18:26:34 antares kernel: usbd_pipe_enter: enter
Aug  7 18:26:34 antares kernel: usbd_pipe_start: start
Aug  7 18:26:34 antares kernel: usbd_pipe_start: start
Aug  7 18:26:34 antares kernel: usbd_transfer_done: 
err=USB_ERR_NORMAL_COMPLETION
Aug  7 18:26:34 antares kernel: usbd_transfer_done: 
err=USB_ERR_NORMAL_COMPLETION

Aug  7 18:26:34 antares kernel


Can you get dmesg without the USB debug enabled?

--HPS
___
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: [USB] hang after upgrade from 10.0 to 10.1, ZFS or callout() related?

[Hans Petter Selasky]

On 08/07/17 17:59, Michael Schmiedgen wrote:

Hi list,

after upgrading kernel from 11.0 to 11.1 the boot process stopped,
waiting forever for some USB stuff. I tried to skip waiting with

hw.usb.no_boot_wait="1"

in /boot/loader.conf but then I got a very strange ZFS 'mount error 5',
which I had some time ago upgrading from 10.0 to 10.1. That error did
magically went away with 11.0, and now it seems to pop up again:

https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052900.html 



https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081192.html 



Can you try getting the dmesg.

You can also disable USB enumeration setting these:

hw.usb.disable_enumeration: 0
dev.uhub.2.disable_enumeration: 0
dev.uhub.1.disable_enumeration: 0
dev.uhub.0.disable_enumeration: 0

Are you sure you loaded all drivers, like XHCI, EHCI, OHCI, UHCI ? DOes 
the BIOS offer any USB options?


--HPS





So I reset the boot wait option to default again and switched on some USB
debug options:

https://imgur.com/a/xzkrC


Anybody? Thanks,
   Michael



___
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: decent 40G network adapters

[Hans Petter Selasky]

On 01/18/17 10:48, Eugene M. Zheganin wrote:

Hi.

Could someone recommend a decent 40Gbit adapter that are proven to be
working under FreeBSD ? The intended purpose - iSCSI traffic, not much
pps, but rates definitely above 10G. I've tried Supermicro-manufactured
Intel XL710 ones (two boards, different servers - same sad story:
packets loss, server unresponsive, spikes), seems like they have a
problem in a driver (or firmware), and though Intel support states this
is because the Supermicro tampered with the adapter, I'm still
suspicious about ixl(4). I've also seen in the ML a guy reported the
exact same problem with ixl(4) as I have found.

So, what would you say ? Chelsio ?



Hi,

I think also the Mellanox, mlx4 and mlx5 drivers will support this. Are 
you using infiniband or TCP for backend?


--HPS

___
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: Status of PCIe Hotplug?

[Hans Petter Selasky]

Hi,

Can you compile your kernel with debugging enabled so that we get the 
sourcelines in the dump below. Also please include some parts of the 
preceeding dmesg.


Do you have USB compiled into the kernel or loaded as a module?

What does kldstat output after you plug the card?

What is the dmesg leading up to this?

The bug looks like some .ko was unloaded too early, due to refcounts 
dropping incorrectly.


--HPS




Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; acpic id = 01
instruction pointer = 0x20:0x80b1549c
stack pointer   = 0x28:0xfe022f62ca00
frame pointer   = 0x28:0xfe022f62ca70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14 (usbus1)
trap number = 9
panic: general protection fault
cpuid = 1
KDB: stack backtrace:
#0 0x80b24077 at kdb_backtrace+0x67
#1 0x80ad93e2 at vpanic+0x182
#2 0x80ad9253 at panic+0x43
#3 0x80fa0d31 at trap_fatal+0x351
#4 0x80fa09c8 at trap+0x768
#5 0x80f84141 at calltrap+0x8
#6 0x808f2f63 at usb_detach_device+0xf3
#7 0x808f1d5b at usb_unconfigure+0x2b
#8 0x808f5623 at usb_free_device+0x103
#9 0x808f58b1 at usb_bus_detach+0x161
#10 0x80903e95 at usb_process+0x125
#11 0x80a90055 at fork_exit+0x85
#12 0x80f8467e at fork_trampoline+0xe
Uptime: 18m27s
Automatic reboot in 15 seconds - press a key on the console to abort


___
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: 11.0 stuck on high network load

[Hans Petter Selasky]

On 09/18/16 22:46, Slawa Olhovchenkov wrote:

userbase compatible?
can i recompile only kernel?


Yes, only the kernel.

--HPS
___
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: 11.0 stuck on high network load

[Hans Petter Selasky]

On 09/18/16 20:10, Slawa Olhovchenkov wrote:

On Sun, Sep 18, 2016 at 07:50:08PM +0200, Hans Petter Selasky wrote:


Hi,

Got some tips regarding this thread.

Some things you can try:

1) Compile kernel from projects/hps_head instead of your 11-stable?


How many difference from 11-stable?


Hi,

The callout subsystem has a different implementation. Else identical.




2) Set net.inet.tcp.per_cpu_timers=1


Already. From 10.x, by manual MFC.


OK.




If the system just hangs, it is pretty likely that the timers are going
in a loop due to typical use after free.

Please keep me CC'ed, hence I'm not subscribed to @stable.



--HPS

___
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"

11.0 stuck on high network load

[Hans Petter Selasky]

Hi,

Got some tips regarding this thread.

Some things you can try:

1) Compile kernel from projects/hps_head instead of your 11-stable?

2) Set net.inet.tcp.per_cpu_timers=1

If the system just hangs, it is pretty likely that the timers are going 
in a loop due to typical use after free.


Please keep me CC'ed, hence I'm not subscribed to @stable.

--HPS
___
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: XEN kernel broken with mlx5*

[Hans Petter Selasky]

On 12/14/15 16:05, Roger Pau Monné wrote:

El 14/12/15 a les 15.35, NGie Cooper ha escrit:

Hi HPS,
It seems that XEN.i386 is broken with the mlx5* module due to a 
mismatch in function definitions. Some refactoring took place on head that 
appears to have “fixed” this issue. Could you or Roger please fix it?


No refactoring took place on HEAD, the XEN.i386 kernel was simply
removed. AFAICT adding the affected drivers into the WITHOUT_MODULES
list in the XEN kernel config file should solve it.

Roger.




See here:
https://svnweb.freebsd.org/changeset/base/292213

Thank you!

--HPS
___
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: XEN kernel broken with mlx5*

[Hans Petter Selasky]

On 12/14/15 15:35, NGie Cooper wrote:

Hi HPS,
It seems that XEN.i386 is broken with the mlx5* module due to a 
mismatch in function definitions. Some refactoring took place on head that 
appears to have “fixed” this issue. Could you or Roger please fix it?
Thanks,
-NGie


Hi,

I'll have a look at it. Thank you for notifying me.

--HPS


___
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: urtwn regression(?) from 10.2 to current r291431

[Hans Petter Selasky]

On 12/06/15 15:14, Anton Shterenlikht wrote:

I posted this about a week ago:

http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html

The problem is that urtwn stopped
working in current r291431.

I did more testing with the same revision,
and sometimes it would work, but extremely
slowly, and sometimes seemingly associate
but get an address of 0.0.0.0.

I now installed 10.2-RELEASE-p8 and
the urtwn works fine, no issues at all.

Does this look like a bug at some recent
current revision? Should I file a PR?

I's just I recall there have been major
chages to wlan, so perphaps I'm forgetting
to change the config in recent current?

Please advise

Anton


Hi,

There is work ongoing in the WLAN drivers. Did you try the latest -current?

--HPS

___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

Hi,

I've now MFC'ed r287775 to 10-stable and 9-stable. I hope this will 
resolve the issues with m_defrag() being called on too long mbuf chains 
due to an off-by-one in the driver TSO parameters and that it will be 
easier to maintain these parameters in the future.


Some comments were made that we might want to have an option to select 
if the IP-header should be counted or not. Certain network drivers 
require copying of the whole ETH/TCP/IP-header into separate memory 
areas, and can then handle one more data payload mbuf for TSO. Others 
required DMA-ing of the whole mbuf TSO chain. I think it is acceptable 
to have one TX-DMA segment slot free, in case of 2K mbuf clusters being 
used for TSO. From my experience the limitation typically kicks in when 
2K mbuf clusters are used for TSO instead of 4K mbuf clusters. 65536 / 
4096 = 16, whereas 65536 / 2048 = 32. If an ethernet hardware driver has 
a limitation of 24 data segments (mlxen), and assuming that each mbuf 
represent a single segment, then iff the majority of mbufs being 
transmitted are 2K clusters we may have a small, 1/24 = 4.2%, loss of TX 
capability per TSO packet. From what I've seen using iperf, which in 
turn calls m_uiotombuf() which in turn calls m_getm2(), MJUMPPAGESIZE'ed 
mbuf clusters are preferred for large data transfers, so this issue 
might only happen in case of NODELAY being used on the socket and if the 
writes are small from the application point of view.  If an application 
is writing small amounts of data per send() system call, it is expected 
to degrade the system performance.


Please file a PR if it becomes an issue.

Someone asked me to MFC r287775 to 10.X release aswell. Is this still 
required?


--HPS
___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

Hi,

I've made some minor modifications to the patch from Rick, and made this 
review:


https://reviews.freebsd.org/D3477

--HPS
___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/24/15 01:02, Rick Macklem wrote:

The other thing is the degradation seems to cut the rate by about half each 
time.
300--150--70 I have no idea if this helps to explain it.


Might be a NUMA binding issue for the processes involved.

man cpuset

--HPS
___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/18/15 23:54, Rick Macklem wrote:

Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.

In my opinion, this should be fixed by setting if_hw_tsomaxsegcount to whatever
the driver provides - 1. It is not the driver's responsibility to know if a 
tcp/ip
header mbuf will be added and is a lot less confusing that expecting the driver
author to know to subtract one. (I had mistakenly thought that tcp_output() had
added the tc/ip header mbuf before the loop that counts mbufs in the list. Btw,
this tcp/ip header mbuf also has leading space for the MAC layer header.)



Hi Rick,

Your question is good. With the Mellanox hardware we have separate 
so-called inline data space for the TCP/IP headers, so if the TCP stack 
subtracts something, then we would need to add something to the limit, 
because then the scatter gather list is only used for the data part.


Maybe it can be controlled by some kind of flag, if all the three TSO 
limits should include the TCP/IP/ethernet headers too. I'm pretty sure 
we want both versions.


--HPS
___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/19/15 09:42, Yonghyeon PYUN wrote:

On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:

On 08/18/15 23:54, Rick Macklem wrote:

Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.

In my opinion, this should be fixed by setting if_hw_tsomaxsegcount to
whatever
the driver provides - 1. It is not the driver's responsibility to know if
a tcp/ip
header mbuf will be added and is a lot less confusing that expecting the
driver
author to know to subtract one. (I had mistakenly thought that
tcp_output() had
added the tc/ip header mbuf before the loop that counts mbufs in the list.
Btw,
this tcp/ip header mbuf also has leading space for the MAC layer header.)



Hi Rick,

Your question is good. With the Mellanox hardware we have separate
so-called inline data space for the TCP/IP headers, so if the TCP stack
subtracts something, then we would need to add something to the limit,
because then the scatter gather list is only used for the data part.



I think all drivers in tree don't subtract 1 for
if_hw_tsomaxsegcount.  Probably touching Mellanox driver would be
simpler than fixing all other drivers in tree.


Maybe it can be controlled by some kind of flag, if all the three TSO
limits should include the TCP/IP/ethernet headers too. I'm pretty sure
we want both versions.



Hmm, I'm afraid it's already complex.  Drivers have to tell almost
the same information to both bus_dma(9) and network stack.


Don't forget that not all drivers in the tree set the TSO limits before 
if_attach(), so possibly the subtraction of one TSO fragment needs to go 
into ip_output() 


--HPS

___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/19/15 09:42, Yonghyeon PYUN wrote:

On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:

On 08/18/15 23:54, Rick Macklem wrote:

Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.

In my opinion, this should be fixed by setting if_hw_tsomaxsegcount to
whatever
the driver provides - 1. It is not the driver's responsibility to know if
a tcp/ip
header mbuf will be added and is a lot less confusing that expecting the
driver
author to know to subtract one. (I had mistakenly thought that
tcp_output() had
added the tc/ip header mbuf before the loop that counts mbufs in the list.
Btw,
this tcp/ip header mbuf also has leading space for the MAC layer header.)



Hi Rick,

Your question is good. With the Mellanox hardware we have separate
so-called inline data space for the TCP/IP headers, so if the TCP stack
subtracts something, then we would need to add something to the limit,
because then the scatter gather list is only used for the data part.



I think all drivers in tree don't subtract 1 for
if_hw_tsomaxsegcount.  Probably touching Mellanox driver would be
simpler than fixing all other drivers in tree.


Hi,

If you change the behaviour don't forget to update and/or add comments 
describing it. Maybe the amount of subtraction could be defined by some 
macro? Then drivers which inline the headers can subtract it?


Your suggestion is fine by me.

The initial TSO limits were tried to be preserved, and I believe that 
TSO limits never accounted for IP/TCP/ETHERNET/VLAN headers!





Maybe it can be controlled by some kind of flag, if all the three TSO
limits should include the TCP/IP/ethernet headers too. I'm pretty sure
we want both versions.



Hmm, I'm afraid it's already complex.  Drivers have to tell almost
the same information to both bus_dma(9) and network stack.


You're right it's complicated. Not sure if bus_dma can provide an API 
for this though.


--HPS
___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/18/15 14:53, Rick Macklem wrote:

2572 ifp-if_hw_tsomax = 65518;

2573 ifp-if_hw_tsomaxsegcount = IXGBE_82599_SCATTER;
2574 ifp-if_hw_tsomaxsegsize = 2048;


Hi,

If IXGBE_82599_SCATTER is the maximum scatter/gather entries the 
hardware can do, remember to subtract one fragment for the TCP/IP-header 
mbuf!


I think there is an off-by-one here:

ifp-if_hw_tsomax = 65518;
ifp-if_hw_tsomaxsegcount = IXGBE_82599_SCATTER - 1;
ifp-if_hw_tsomaxsegsize = 2048;

Refer to:


 *
 * NOTE: The TSO limits only apply to the data payload part of
 * a TCP/IP packet. That means there is no need to subtract
 * space for ethernet-, vlan-, IP- or TCP- headers from the
 * TSO limits unless the hardware driver in question requires
 * so.


In sys/net/if_var.h

Thank you!

--HPS

___
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: ix(intel) vs mlxen(mellanox) 10Gb performance

[Hans Petter Selasky]

On 08/18/15 14:53, Rick Macklem wrote:

If this is just a test machine, maybe you could test with these lines (at about 
#880)
in sys/netinet/tcp_output.c commented out? (It looks to me like this will 
disable TSO
for almost all the NFS writes.)
- around line #880 in sys/netinet/tcp_output.c:
/*
 * In case there are too many small fragments
 * don't use TSO:
 */
if (len = max_len) {
len = max_len;
sendalot = 1;
tso = 0;
}

This was added along with the other stuff that did the if_hw_tsomaxsegcount, 
etc and I
never noticed it until now (not my patch).


FYI:

These lines are needed by other hardware, like the mlxen driver. If you 
remove them mlxen will start doing m_defrag(). I believe if you set the 
correct parameters in the struct ifnet for the TSO size/count limits 
this problem will go away. If you print the len and max_len and also 
the cases where TSO limits are reached, you'll see what parameter is 
triggering it and needs to be increased.


--HPS
___
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: OFED on stable/9 is not buildable at least on stable/10

[Hans Petter Selasky]

On 07/11/15 19:14, Dmitry Morozovsky wrote:

Hans Petter,

On Sat, 4 Jul 2015, Dmitry Morozovsky wrote:


on stable/10 trying to buildkernel with ALL_MODULES chokes at OFED
(actually,
for quite a few months already):

Could you please take a look at this?


Does this patch fix the problem for you:

https://svnweb.freebsd.org/changeset/base/285088


yes it does, thank you!


could you please MFC this small change to reduce burden of local patches a bit? 
:)



Here you go:

https://svnweb.freebsd.org/changeset/base/285410

--HPS

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

Re: OFED on stable/9 is not buildable at least on stable/10

[Hans Petter Selasky]

On 07/03/15 12:13, Dmitry Morozovsky wrote:

Dear colleagues,

on stable/10 trying to buildkernel with ALL_MODULES chokes at OFED (actually,
for quite a few months already):

marck@castor:/FreeBSD/pristine/src.9 make -DNO_CLEAN buildkernel
__MAKE_CONF=/dev/null SRCCONF=/dev/null KERNCONF=GENERIC ALL_MODULES=

cc1: warnings being treated as errors
/FreeBSD/pristine/src.9/sys/modules/ipoib/../../ofed/include/linux/linux_compat.c:
In function 'kvasprintf':
/FreeBSD/pristine/src.9/sys/modules/ipoib/../../ofed/include/linux/device.h:420:
warning: function 'kvasprintf' can never be inlined because it uses variable
argument lists [-Winline]
*** [linux_compat.o] Error code 1
ctfconvert -L VERSION -g linux_radix.o

Could you please take a look at this?



Hi,

I think if you use clang to build this compile problem will not happen. 
Anyhow, I'll make a fix for it. It is simply about declaring the 
function externally.


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

Re: OFED on stable/9 is not buildable at least on stable/10

[Hans Petter Selasky]

On 07/03/15 12:13, Dmitry Morozovsky wrote:

Dear colleagues,

on stable/10 trying to buildkernel with ALL_MODULES chokes at OFED (actually,
for quite a few months already):





Could you please take a look at this?



Hi,

Does this patch fix the problem for you:

https://svnweb.freebsd.org/changeset/base/285088

--HPS

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

Re: pkg 1.5.0 is out

[Hans Petter Selasky]

On 04/21/15 12:34, Slawa Olhovchenkov wrote:

On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote:


Hi all,

Final pkg 1.5.0 has been released.




Hi,

Is there a way the external SAT solver functionality can be memory 
optimised? When trying to use this feature having +750 packages 
installed, the memory usage starts growing and growing beyond 4GBytes 
until PKG segfaults, even before the CNF export has started.


env SAT_SOLVER=mysolver pkg upgrade

--HPS

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

Re: Help debugging stable/10

[Hans Petter Selasky]

On 06/17/15 09:24, Shane Ambler wrote:

On 24/03/2015 01:55, Shane Ambler wrote:

On 25/12/2014 23:03, Andriy Gapon wrote:

On 25/12/2014 11:29, Hans Petter Selasky wrote:

The cam_sim_free() is stuck, blocking the rest of that controller from
enumerating. It might look like a non-USB stack issue.

MAV: Do you have some ideas where to start looking, now we have a
dump? Any
refcounts to check in particular?


Apparently sim-refcount  0.
Not sure how to check who has the reference(s).



Can anyone think of something I can try?

To recap to save you going back through history -
After running 9.0 - 9.2 for 3 years I upgraded to 10.1RC3 and started
getting a locking issue, most new processes fail to start, top and ps
failing being indicators, the most info I have got is a back trace
using kgdb, there are 4 instances I got output from procstat -kk -a

On several occasions I have found that after inserting a usb memstick
the device failed to be created, leaving me unable to mount the
filesystem without a restart.

I then switched to stable/10 in hopes of a fix finding it's way in.

The back traces I have been able to collect (and a dmesg) are listed at
http://shaneware.biz/freebsddebugdata/

This is my everyday desktop machine. I am now running

FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #11 r283839: Thu
Jun  4 17:41:28 ACST 2015 root@leader.local:/usr/obj/usr/src/sys
/GENERIC  amd64

I can only say it appears to be getting worse, though I may just be
getting sick of having to restart nearly every day. Lately it seems that
the less I do the quicker it locks up. I have restarted twice this week
and then let it sit while I have gone out, after returning I get maybe
10-15 mins then have to restart, one of them was less than an hour uptime.

While running poudriere I have got past 1 day uptime but it locks up
harder and I don't usually get a chance to record any data.




Hi,

One solution is to use fuse instead of the native fs, until the CAM/SCSI 
refcount issues are resolved.


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Hans Petter Selasky]

Let me know when this issue settles, what changes you want in the umcs 
kernel driver.


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

Re: HFC-4S and pcm_slave

[Hans Petter Selasky]

On 09/18/13 15:20, Harald Schmalzbauer wrote:

  Hello,

thanks to Hans Petter Selasky, isdn4bsd (i4b) was easy to install and
seems to do the same great job these days with 9.2 as a decade ago with
3.x :-)
But I had a hard time getting isdntest-connection working with my atcom
AX-4S (HFC-4S).
Accidentally I read on HPSs site that HFC-4S/8S are by default
initialized in pcm_slave mode.
I had no idea about pcm_mode – nothing qualified found with a very quick
search – but I understand the need and possibilities of clock sources.

But why is the default to rely on external clock source with HFC-4S?


Hi,

This is just to avoid a conflict if the devices are physically connected.



And how – if it's describable in one sentence – does the HFC-4S read
external clock?


It depends on the board. I have not used this feature myself, but there 
is some wiring cables, you can put between the boards (if they support 
it), which also handles call-bridging in hardware.




Is there something like 'hint.hfc.X.pcm_master' (planned)?


No, but please submit a patch if you want it :-)



Why isn't isdn4bsd and libcapi in the official ports tree?


There is no specific reason for this. If you ask, the ports guys will 
eventually include it :-)


--HPS

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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Hans Petter Selasky]

On 09/17/13 10:47, Lev Serebryakov wrote:

Hello, Harald.
You wrote 17 сентября 2013 г., 12:46:25:

HS The Y is the device addr @ bus #X.
   Oh :)

HS Same posted some seconds ago :-)
   Yep, exactly the same pattern.




Hi,

Could you show the configuration descriptor for your device?

usbconfig -d X.Y dump_curr_config_desc


?

The interrupt endpoint in question can be throttled by the USB stack, if 
the latency of these events are not important to your application.


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Hans Petter Selasky]

On 09/17/13 11:06, Harald Schmalzbauer wrote:

  Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 10:57
(localtime):

On 09/17/13 10:47, Lev Serebryakov wrote:

Hello, Harald.
You wrote 17 сентября 2013 г., 12:46:25:

HS The Y is the device addr @ bus #X.
Oh :)

HS Same posted some seconds ago :-)
Yep, exactly the same pattern.




Hi,

Could you show the configuration descriptor for your device?

usbconfig -d X.Y dump_curr_config_desc


Shall we switch to non-list-comm?


Hi,

That's OK.


Hmm, in my case, this 4-port-serial-USB-hub will be used as console
concentrator. So most time it's doing nothing, just feeding tmux with
consoles output. What latency are we talking about? Less than a some
milliseconds should be fine.
What I'm curious about is why my prolific USB-serial converter doesn't
generate these high irqs.


Try this patch and see what happens:

==
--- umcs.c  (revision 255492)
+++ umcs.c  (local)
@@ -230,6 +230,7 @@
.bufsize = 0,   /* use wMaxPacketSize */
.callback = umcs7840_intr_callback,
.if_index = 0,
+   .interval = 20, /* ms */
},
 };


BTW: I see that the umcs driver shouldn't do synchronous control 
transfers from the USB interrupt transfer callback. This should be 
postponed into some worker thread, for example the USB explore thread. 
See USB audio driver for an example.


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Hans Petter Selasky]

On 09/17/13 17:38, Harald Schmalzbauer wrote:

  Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24
(localtime):

On 09/17/13 11:06, Harald Schmalzbauer wrote:

...
Shall we switch to non-list-comm?


Hi,

That's OK.


Hmm, in my case, this 4-port-serial-USB-hub will be used as console
concentrator. So most time it's doing nothing, just feeding tmux with
consoles output. What latency are we talking about? Less than a some
milliseconds should be fine.
What I'm curious about is why my prolific USB-serial converter doesn't
generate these high irqs.


Try this patch and see what happens:

==
--- umcs.c(revision 255492)
+++ umcs.c(local)
@@ -230,6 +230,7 @@
  .bufsize = 0,/* use wMaxPacketSize */
  .callback = umcs7840_intr_callback,
  .if_index = 0,
+.interval = 20, /* ms */
  },
  };


BTW: I see that the umcs driver shouldn't do synchronous control
transfers from the USB interrupt transfer callback. This should be
postponed into some worker thread, for example the USB explore thread.
See USB audio driver for an example.

--HPS


I tried your patch and it works as expected: IRQs decreased to ~64/s
when idle/disconnected.

One interesting thing I never measured before:
Console connection with 115k2 via umcs and 'while ( 21 ) echo ---...
end' results in 8000 irqs/s :-( But that's also true for the prolific
(uplcom). The latter just goes down to 0.0 irqs/s when idle.

Doing the same with uart0 results in 1444irqs/s.
Is it by design/unavoidable that transfering the same via USB multiplies
by factor 5-6?

Thanks,

-Harry



Hi,

I think the adapters use very small buffers. You can try adding 
.interval = 4 to the other USB configs, above the one you patched, and 
see what happens. I cannot tell if you will loose characters or not.


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

RE: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Hans Petter Selasky]

Hi,

Check using usbdump -i usbusX -f Y -s 65536 -vvv

what is going on. Maybe some USB transfers are returning zero length data from 
the chip.

--HPS

 
 
-Original message-
 From:Lev Serebryakov l...@freebsd.org mailto:l...@freebsd.org 
 Sent: Monday 16th September 2013 23:38
 To: Harald Schmalzbauer h.schmalzba...@omnilan.de 
 mailto:h.schmalzba...@omnilan.de 
 Cc: FreeBSD Stable freebsd-stable@FreeBSD.org 
 mailto:freebsd-stable@FreeBSD.org ; freebsd-...@freebsd.org 
 mailto:freebsd-...@freebsd.org 
 Subject: Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
 
 Hello, Harald.
 You wrote 16 сентября 2013 г., 20:11:38:
 
 HS I have some of these 4-Port-Serial-USB-Hubs:
 HS http://www.delock.com/produkte/F_673_USB---Seriell_87414/merkmale.html 
 http://www.delock.com/produkte/F_673_USB---Seriell_87414/merkmale.html 
 HS They have the MosChip MCS7840 inside, wich also understands RS485/422
 HS besides RS232.
 
 HS FreeBSDs umcs(4) supports the RS232 mode with standard baudrates and
 HS works with that device.
 
 HS Unfortunately, as soon as I open any of the 4 cuaU0.x ports, there are
 HS 500irq/s from ehci.
   I have only one 2-port noname adapter with this chip, which I used to
  write this driver. And it works fine (at least right now):
 
 usbus0: 12Mbps Full Speed USB v1.0
 usbus1: 12Mbps Full Speed USB v1.0
 usbus2: 12Mbps Full Speed USB v1.0
 usbus3: 480Mbps High Speed USB v2.0
 
 ugen3.2: vendor 0x9710 at usbus3
 umcs78400: vendor 0x9710 product 0x7840, rev 2.00/0.01, addr 2 on usbus3
 umcs78400: Chip mcs7840, found 2 active ports
 umcs78400: On-die confguration: RST: active low, HRD: yes, PLL: avail, POR: 
 avail, Ports: 4, EEPROM write disabled, IrDA is not available
 
 % vmstat -i
 interrupt  total   rate
 irq1: atkbd0 799  0
 irq18: uhci2 ehci0+ 1210  0
 irq20: hpet0   529850590647
 irq21: uhci1 2861007  3
 irq23: uhci3 ehci1   2181202  2
 irq256: em0   1139745179   1393
 irq257: ahci0   76093174 93
 Total 1750731961   2140
 
   I have never seen other devices on this chip and I have never had chance
  to try it with 4-port version of device...
 
   To be honest, I didn't know much about USB at all, I wrote this driver
 without complete understanding USB magic and use USB only as transport to
 access MCS7840 registers...
 
  Maybe, local USB Guru Hans Petter Selasky could give cime advicec how to
  debug this situation. I've added freebsd-usb@ to CC:
 
 -- 
 // Black Lion AKA Lev Serebryakov l...@freebsd.org mailto:l...@freebsd.org 
 
 
 ___
 freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org  mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-usb 
 http://lists.freebsd.org/mailman/listinfo/freebsd-usb 
 To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org 
 mailto:freebsd-usb-unsubscr...@freebsd.org 

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

RE: USB ports on Lenovo T400 do not work after a suspend/resume

[Hans Petter Selasky]

Hi,

FYI: The USB stack will currently run a complete controller reset upon resume, 
like during boot.

--HPS 

 
-Original message-
 From:Ian Smith smi...@nimnet.asn.au mailto:smi...@nimnet.asn.au 
 Sent: Sunday 7th July 2013 7:52
 To: Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org 
 Cc: freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org ; 
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org ; 
 freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org 
 Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume
 
 On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
   On 30 June 2013 07:22, Ian Smith smi...@nimnet.asn.au 
 mailto:smi...@nimnet.asn.au  wrote:
 [..]
Nothing of note that I can see, if that usb hub-to-bus remapping is
normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
Maybe someone who knows might comment on that?
 
 Does noone know what that signifies?  Maybe it's not relevant to this.
 
Just checking: you've tried other USB devices apart from uftdi0?
   
   Yup, there's no 5v on the port.
 
 I was rather taken aback to hear this.  Would not this indicate a 
 failure to reinitialise the basic underlying USB hardware on resume?
 
 More than a bit bemused, Ian
 ___
 freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org  mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
 http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
 To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org 
 mailto:freebsd-acpi-unsubscr...@freebsd.org 
 

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

RE: XHCI umass support breaks between r248085 and r252560 on 9-STABLE

[Hans Petter Selasky]

Hi,

Check for CAM/SCSI related changes. There has not been so many USB changes 
recently. Possibly not USB related.

Thank you,

--HPS
 
-Original message-
 From:Alexandre Kovalenko bsd.gai...@gmail.com mailto:bsd.gai...@gmail.com 
 Sent: Thursday 4th July 2013 20:58
 To: freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org 
 Cc: freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org 
 Subject: XHCI umass support breaks between r248085 and r252560 on 9-STABLE
 
 Three different external hard drives (Seagate, Western Digital and noname USB 
 3.0 enclosure) refused to be recognized as the umass devices. Reverting 
 /usr/src/sys/dev/bsd/controller to r248085, building and loading just xhci 
 module makes drives appear again. Below are snippets from the log in both 
 cases:
 
 Non working:
 
 Jul  4 14:35:17 twinhead kernel: xhci0: XHCI (generic) USB 3.0 controller 
 mem 0xfddfe000-0xfddf irq 16 at device 0.0 on pci2
 Jul  4 14:35:17 twinhead kernel: xhci0: 64 byte context size.
 Jul  4 14:35:17 twinhead kernel: usbus0 on xhci0
 Jul  4 14:35:17 twinhead kernel: usbus0: 5.0Gbps Super Speed USB v3.0
 Jul  4 14:35:17 twinhead kernel: ugen0.1: 0x1912 at usbus0
 Jul  4 14:35:17 twinhead kernel: uhub0: 0x1912 XHCI root HUB, class 9/0, rev 
 3.00/1.00, addr 1 on usbus0
 Jul  4 14:35:17 twinhead kernel: uhub0: 8 ports with 8 removable, self powered
 Jul  4 14:35:24 twinhead kernel: ugen0.2: ASMedia at usbus0
 Jul  4 14:35:24 twinhead kernel: umass0: ASMedia AS2105, class 0/0, rev 
 3.00/0.01, addr 1 on usbus0
 Jul  4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 
 00 00 00 24 00 
 Jul  4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB 
 request completed with an error
 Jul  4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command
 Jul  4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 
 00 00 00 24 00 
 Jul  4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB 
 request completed with an error
 Jul  4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command
 Jul  4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 
 00 00 00 24 00 
 Jul  4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB 
 request completed with an error
 Jul  4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command
 Jul  4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 
 00 00 00 24 00 
 Jul  4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB 
 request completed with an error
 Jul  4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command
 Jul  4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 
 00 00 00 24 00 
 Jul  4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB 
 request completed with an error
 Jul  4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries 
 exhausted
 
 Working:
 
 Jul  4 14:40:20 twinhead kernel: ugen0.2: ASMedia at usbus0 (disconnected)
 Jul  4 14:40:20 twinhead kernel: umass0: at uhub0, port 2, addr 1 
 (disconnected)
 Jul  4 14:40:27 twinhead kernel: ugen0.2: vendor 0x174c at usbus0
 Jul  4 14:40:27 twinhead kernel: umass0: vendor 0x174c product 0x5106, class 
 0/0, rev 3.00/0.01, addr 1 on usbus0
 Jul  4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: 
 a0 00 00 00 00 00 00 00 00 10 00 00 
 Jul  4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: SCSI 
 Status Error
 Jul  4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI status: 
 Check Condition
 Jul  4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI sense: 
 ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
 Jul  4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 22, 
 Unretryable error
 Jul  4 14:40:27 twinhead kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
 Jul  4 14:40:27 twinhead kernel: da0: Hitachi HTS542520K9SA00 BBDO Fixed 
 Direct Access SCSI-5 device 
 Jul  4 14:40:27 twinhead kernel: da0: 400.000MB/s transfers
 Jul  4 14:40:27 twinhead kernel: da0: 190782MB (390721968 512 byte sectors: 
 255H 63S/T 24321C)
 Jul  4 14:40:27 twinhead kernel: da0: quirks=0x2NO_6_BYTE
 
 I can provide additional information or try  patches as necessary.
 
 Alexandre Sunny Kovalenko (Олександр Коваленко)
 
 ___
 freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org  mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-usb 
 http://lists.freebsd.org/mailman/listinfo/freebsd-usb 
 To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org 
 mailto:freebsd-usb-unsubscr...@freebsd.org 

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

RE: USB ports on Lenovo T400 do not work after a suspend/resume

[Hans Petter Selasky]

Hi,

The USB code should re-attach the uhub driver to the root HUB and any other 
HUBs after resume. Part of the attach code is to set the  power on.

See /sys/dev/usb/usb_hub.c

And:

grep -r UHF_PORT_POWER /sys/dev/usb/

--HPS
 
 
-Original message-
 From:Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org 
 Sent: Sunday 7th July 2013 18:43
 To: Hans Petter Selasky hans.petter.sela...@bitfrost.no 
 mailto:hans.petter.sela...@bitfrost.no 
 Cc: freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org ; 
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org ; Ian Smith 
 smi...@nimnet.asn.au mailto:smi...@nimnet.asn.au ; 
 freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org 
 Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume
 
 I don't think it's a USB controller issue.
 
 Those ports are connected to USB hubs, right? I wonder if there's some
 ACPI nonsense that's resulting in the hubs not being powered up on
 resume.
 
 
 
 -adrian
 
 On 7 July 2013 00:32, Hans Petter Selasky
 hans.petter.sela...@bitfrost.no mailto:hans.petter.sela...@bitfrost.no  
 wrote:
  Hi,
 
  FYI: The USB stack will currently run a complete controller reset upon
  resume, like during boot.
 
  --HPS
 
 
 
  -Original message-
  From:Ian Smith smi...@nimnet.asn.au mailto:smi...@nimnet.asn.au 
  Sent: Sunday 7th July 2013 7:52
  To: Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org 
  Cc: freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org ; 
  freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org ;
  freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org 
  Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume
 
  On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:
On 30 June 2013 07:22, Ian Smith smi...@nimnet.asn.au 
  mailto:smi...@nimnet.asn.au  wrote:
  [..]
 Nothing of note that I can see, if that usb hub-to-bus remapping is
 normal.  As you said, 'CPU0: local APIC error 0x40' looks maybe sus.
 Maybe someone who knows might comment on that?
 
  Does noone know what that signifies?  Maybe it's not relevant to this.
 
 Just checking: you've tried other USB devices apart from uftdi0?
   
Yup, there's no 5v on the port.
 
  I was rather taken aback to hear this.  Would not this indicate a
  failure to reinitialise the basic underlying USB hardware on resume?
 
  More than a bit bemused, Ian
  ___
  freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org  mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
  http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
  To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org 
  mailto:freebsd-acpi-unsubscr...@freebsd.org 
 
 ___
 freebsd-a...@freebsd.org mailto:freebsd-a...@freebsd.org  mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
 http://lists.freebsd.org/mailman/listinfo/freebsd-acpi 
 To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org 
 mailto:freebsd-acpi-unsubscr...@freebsd.org 
 

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

RE: 8.4 and EHCI - regression?

[Hans Petter Selasky]

Hi,

EHCI is probed by PCI. It will print if probing fails. Probably ACPI 
regression. Did you load ACPI?

--HPS
 
 
-Original message-
 From:Jeremy Chadwick j...@koitsu.org
 Sent: Sunday 9th June 2013 19:16
 To: l...@lena.kiev.ua
 Cc: freebsd-stable@freebsd.org; freebsd-...@freebsd.org
 Subject: Re: 8.4 and EHCI - regression?
 
 On Sun, Jun 09, 2013 at 08:03:13PM +0300, l...@lena.kiev.ua wrote:
  After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`.
  Details:
  
  Motherboard: ASUS M2NPV-MX ACPI BIOS Revision 1101
  
  Before upgrade, 8.3-RELEASE-p2 i386:
  
  ~ $ egrep -i 'usb|hci' dmesg.yesterday
  ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at 
  device 11.0 on pci0
  ohci0: [ITHREAD]
  usbus0: OHCI (generic) USB controller on ohci0
  ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02e000-0xfe02e0ff irq 22 
  at device 11.1 on pci0
  ehci0: [ITHREAD]
  usbus1: EHCI version 1.0
  usbus1: EHCI (generic) USB 2.0 controller on ehci0
  usbus0: 12Mbps Full Speed USB v1.0
  usbus1: 480Mbps High Speed USB v2.0
  ugen0.1: nVidia at usbus0
  uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
  ugen1.1: nVidia at usbus1
  uhub1: nVidia EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1
  Root mount waiting for: usbus1 usbus0
  Root mount waiting for: usbus1
  Root mount waiting for: usbus1
  Root mount waiting for: usbus1
  ugen0.2: vendor 0x055f at usbus0
  
  (the last line - a scanner).
  
  After upgrade to 8.4-RELEASE - no EHCI:
  
  ~ $ dmesg | egrep -i 'usb|hci'
  ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq 21 at 
  device 11.0 on pci0
  ohci0: [ITHREAD]
  usbus0 on ohci0
  usbus0: 12Mbps Full Speed USB v1.0
  ugen0.1: nVidia at usbus0
  uhub0: nVidia OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
  Root mount waiting for: usbus0
  Root mount waiting for: usbus0
  ugen0.2: vendor 0x055f at usbus0
  
  ~ $ pciconf -l | grep hci
  ohci0@pci0:0:11:0:  class=0x0c0310 card=0x81c01043 chip=0x026d10de 
  rev=0xa3
  hdr=0x00
  ehci0@pci0:0:11:1:  class=0x0c0320 card=0x81c01043 chip=0x026e10de 
  rev=0xa3
  hdr=0x00
  ~ $ kldstat
  Id Refs AddressSize Name
   1   33 0xc040 58ae60   kernel
   22 0xc098b000 57964sound.ko
   31 0xc09e3000 2abe8snd_hda.ko
   41 0xc0a0e000 3288 speaker.ko
   51 0xc0a12000 a91200   nvidia.ko
   61 0xc14a4000 308c aibs.ko
   71 0xc6169000 8000 linprocfs.ko
   81 0xc6175000 4000 fdescfs.ko
   91 0xc62eb000 2000 linux_adobe.ko
  101 0xc6497000 2000 rtc.ko
  ~ $ kldstat -v | grep hci
  131 ohci/usbus
  130 uhci/usbus
  129 ehci/usbus
  128 xhci/usbus
  124 pci/uhci
  123 pci/ohci
  42 pci/ata_ahci
  122 pci/ehci
  41 atapci/ata_ahci_ata
  ~ # kldload ehci
  module_register: module pci/ehci already exists!
  Module pci/ehci failed to register: 17
  kldload: can't load ehci: File exists
  
  How I upgraded:
  
  rm -rf /usr/src
  svn export svn://svn0.us-east.FreeBSD.org/base/releng/8.4 /usr/src
  (created custom kernel config from GENERIC)
  cd /usr/obj
  chflags -R noschg *
  rm -rf *
  cd /usr/src
  make buildworld kernel
  shutdown -p now
  (boot in single user)
  fsck -p
  mount -a
  swapon -a
  cd /usr/src
  adjkerntz -i
  mergemaster -p
  make installworld
  make delete-old
  mergemaster -Fi
  shutdown -p now
  cd /usr/src
  make delete-old-libs
  
  In /etc/make.conf :
  
  KERNCONF=BEDSIDE
  INSTALL_NODEBUG=yes
  CPUTYPE?=athlon64
  
  Custom kernel config in /usr/src/sys/i386/conf/BEDSIDE
  (I edited from GENERIC 8.4):
  
  #
  # GENERIC -- Generic kernel configuration file for FreeBSD/i386
  #
  # For more information on this file, please read the config(5) manual page,
  # and/or the handbook section on Kernel Configuration Files:
  #
  #
  http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
  #
  # The handbook is also available locally in /usr/share/doc/handbook
  # if you've installed the doc distribution, otherwise always see the
  # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
  # latest information.
  #
  # An exhaustive list of options and more detailed explanations of the
  # device lines is also present in the ../../conf/NOTES and NOTES files.
  # If you are in doubt as to the purpose or necessity of a line, check first
  # in NOTES.
  #
  # $FreeBSD: sys/i386/conf/GENERIC 247909 2013-03-07 07:28:05Z bryanv $
  
  #lena cpu   I486_CPU
  #lena cpu   I586_CPU
  cpu I686_CPU
  ident   BEDSIDE #lena was GENERIC
  
  # To statically compile in device wiring instead of /boot/device.hints
  #hints  GENERIC.hints # Default places to look for 
  devices.
  
  # Use the following to compile in values accessible to the kernel
  # 

Re: 8.4 and EHCI - never mind

[Hans Petter Selasky]

On 06/09/13 21:00, l...@lena.kiev.ua wrote:

From: Steven Hartland



After upgrade from 8.3 to 8.4, ehci (USB 2.0) disappeared from `dmesg`.


Does a verbose boot give you any insight?


Thank you, it was my fault: hint.ehci.0.disabled=1 in /boot/device.hints
I can't recall what I tried to fix when I wrote that. It didn't work in 8.3
but works in 8.4. I commented it out, ECHI reappeared. Sorry and thank you.


No, problem :-)

--HPS

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Monday 27 August 2012 14:59:43 Alexey Dokuchaev wrote:
 On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote:
  On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote:
   On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote:
On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote:
 Try the attached patch.  At least, it fixed my problem.

I've committed your patch with some minor modifications.

http://svn.freebsd.org/changeset/base/232448
   
   Unfortunately, it does not fix resume for me; and
   hw.usb.no_shutdown_wait flipping did not make any difference either. 
   Any other ideas? Particularly, I'm curious why disabling all USB
   modules still does not allow this laptop to resume.  What are USB
   debugging techniques?
  
  USB debugging:
  
  Have options USB_DEBUG in kernel config. Then set xxx.debug = 15 under
  hw.usb, typically hw.usb.uhub.debug=15
 
 Today I've csupped to latest RELENG_8 (hoping that maybe the problem was
 fixed during last few months), rebuilt the kernel with USB_DEBUG option.
 
 After fresh reboot, the following snippet releately pop up on the console
 (hand-copied):
 
   usb_needs_explore:
   usb_bus_powerd: bus=0xc55cccf0  -- bus= number changes
   usb_bus_powerd: Recomputing power masks
   uhub_explore: udev=0xc5647400 addr=1-- udev= number changes
   uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x,
 err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2,
 wPortStatus=0x0100, wPortChange=0x, err=USB_ERR_NORMAL_COMPLETION
 
 (USB-CRC32 has plugged in, no other USB devices)
 
 Aroung zzz(8) time (keyboard die upon wake-up as described earlier with
 100% CPU load -- fans are at full burst) debug mode yielded these:
 
   uhub_child_pnpinfo_string: device not on bub
   uhub_child_location_string: device not on bub
   uhub_child_pnpinfo_string: device not on bub
   usb_bus_powerd: bus=0xc55e2c78
   usb_bus_powerd: Recomputing power masks
   uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x,
 err=USB uhub_read_port_status: port 2, wPortStatus=0x0500,
 wPortChange=0x, err=USB ... up to port 8 ...
   uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x,
 err=USB  usual (disconnected) messages 
   usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0
   usb_needs_explore:
   usb_needs_explore:
   usb_needs_explore:
   usb_needs_explore:
   usb_needs_explore:
   uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4
   uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
   ... UHCI also found on usbus 2, 3, 0 (in that order)
   uhub_attach: depth=0 selfpowered=1, parent=0, parent-selfpowered=0
   uhub_attach: Getting HUB descriptior
   uhub_attach: turn on port 1 power
   uhub_attach: turn on port 1 power
   uhub_attach: turn on port 1 power
   uhub_attach: turn on port 1 power
   uhub_attach: turn on port 1 power
   uhub_attach: turn on port 2 power
   uhub_attach: turn on port 2 power
   uhub_attach: turn on port 2 power
   uhub_attach: turn on port 2 power
   uhub1: 2 ports with 2 removable, self powered
   ... usb_needs_explore: loop quoted above repeats; system unusable
 
 Any ideas?
 
 ./danfe

If the USB HC is feeding too many such IRQ's it will be stuck. However, if you 
see that uhub_read_port_status() is called, the kernel is at least running, 
though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you 
try to get some IRQ stats?

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

Re: How to bind a route to a network adapter and not IP

[Hans Petter Selasky]

On Monday 18 June 2012 00:00:51 H wrote:
 sth...@nethelp.no wrote:
  I loose packets because I use a WLAN adapter. Sometimes the link is
  down for various reasons, and then the routes start changing for
  manually created routes, and I want to prevent that.
  
  well that is certainly not a reason for changing routes
  
  I have the feeling you are not explaining good enough what really is
  going on and it may help sending your configurations and an example of
  routes and IP addresses before and after this route change
  
  Why is this so hard to understand? Link down leads to static route
  is deleted. This is standard FreeBSD behavior, and has been this way
  for as long as I can remember (btw, I believe this behavior is from
  the original BSD, not FreeBSD specific).
  
  You can show this by having a static default route pointing to an
  address on an Ethernet interface which has link. And then pulling the
  TP cable from the Ethernet interface. Observe that the default route
  is automatically removed.
 
 may be you have not understood your own problem yet
 
 because so far is nothing to be understood because none of your
 statements is correct, it is also not FreeBSD's standard behavior and
 never has been
 
 as long as there is the valid IP address on the related interface, no
 static route will be deleted, you can even boot without cable and the
 [default] static route is there
 
 so you need to explain better your problem in order to understand it
 
 probably you have some other stuff running, thirdparty network manager
 or something, incorrect or incomplete ppoe or dhc configuration or
 whatever leads to the problem
 
 FYI static routes usually are the manually configured routes, so what
 you say is redundant and not correct, I guess you're loosing some kind
 of dynamic route
 
 since WL networks usually do not run RIP/OSPF/BGP I guess the route you
 apparently loose is coming from some dhcp server and may be your
 dhclient configuration is incomplete or none existent, but here now it
 would be useful to see your config

Hi,

I think we need to distinguish between two matters. One is where the route is 
directly reachable on the local-net of the network adapter, and ARP is 
valid/responding. The second case is when the route is not directly reachable. 
The second case is where the problem happens, like Stian kindly explained.

# For example:

ifconfig wlan0 10.0.0.2 255.255.255.0 up

# Assume the router is at 10.0.0.1
# And we want to reach a certain destination through 10.0.0.1
# Then we do:

route add 10.22.1.1 10.0.0.1

#
# First the FreeBSD network stack will resolve the ethernet address for
# 10.0.0.1, and all 10.22.1.1 IP packets will get sent to 10.0.0.1.
#

However, if the wlan0 link goes down, which sometimes happen, then the route 
for 10.22.1.1 is deleted. This is sometimes very annoying, and also, if it 
happens that the 10.22.1.1 is reachable from another network adapter, then 
traffic sometimes can end up mis-routed.

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

Re: How to bind a route to a network adapter and not IP

[Hans Petter Selasky]

On Monday 18 June 2012 23:03:34 H wrote:
 On Monday 18 June 2012 12:54 Hans Petter Selasky wrote:
  On Monday 18 June 2012 00:00:51 H wrote:
   sth...@nethelp.no wrote:
I loose packets because I use a WLAN adapter. Sometimes the link is
down for various reasons, and then the routes start changing for
manually created routes, and I want to prevent that.

well that is certainly not a reason for changing routes

I have the feeling you are not explaining good enough what really is
going on and it may help sending your configurations and an example
of routes and IP addresses before and after this route change

Why is this so hard to understand? Link down leads to static route
is deleted. This is standard FreeBSD behavior, and has been this way
for as long as I can remember (btw, I believe this behavior is from
the original BSD, not FreeBSD specific).

You can show this by having a static default route pointing to an
address on an Ethernet interface which has link. And then pulling the
TP cable from the Ethernet interface. Observe that the default route
is automatically removed.
   
   may be you have not understood your own problem yet
   
   because so far is nothing to be understood because none of your
   statements is correct, it is also not FreeBSD's standard behavior and
   never has been
   
   as long as there is the valid IP address on the related interface, no
   static route will be deleted, you can even boot without cable and the
   [default] static route is there
   
   so you need to explain better your problem in order to understand it
   
   probably you have some other stuff running, thirdparty network manager
   or something, incorrect or incomplete ppoe or dhc configuration or
   whatever leads to the problem
   
   FYI static routes usually are the manually configured routes, so what
   you say is redundant and not correct, I guess you're loosing some kind
   of dynamic route
   
   since WL networks usually do not run RIP/OSPF/BGP I guess the route you
   apparently loose is coming from some dhcp server and may be your
   dhclient configuration is incomplete or none existent, but here now it
   would be useful to see your config
  
  Hi,
  
  I think we need to distinguish between two matters. One is where the
  route is directly reachable on the local-net of the network adapter, and
  ARP is valid/responding. The second case is when the route is not
  directly reachable. The second case is where the problem happens, like
  Stian kindly explained.
  
  # For example:
  
  ifconfig wlan0 10.0.0.2 255.255.255.0 up
  
  # Assume the router is at 10.0.0.1
  # And we want to reach a certain destination through 10.0.0.1
  # Then we do:
  
  route add 10.22.1.1 10.0.0.1
 
 no no no my friend, wrong again
 
 that is a static route and it goes away same way it was created, manually
 or by deleting the IP address 10.0.0.2 from the related interface
 
 wether there is or not an active link on that interface does not matter
 

Hi,

Can it be that dhclient which I'm running on this interface with manual routes 
disrupts stuff then ??

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

Re: How to bind a route to a network adapter and not IP

[Hans Petter Selasky]

On Friday 15 June 2012 19:02:27 animelo...@gmail.com wrote:
 Perhaps you can ask the very same question in another way so its easier
 to understand why you losing packets? All in all I always thought TCP/IP
 was the basic unit in Internet based networking but feel free to correct
 me if you have any news I might have missed... :)
 
 Also do you have any idea why AMD based CPUs could be vulnerable to this
 alternative networking scheme and cause a remote denial service in fbsd
 stable but not in CURRENT?
 
 Thanks,
 
 Etienne

Hi,

I loose packets because I use a WLAN adapter. Sometimes the link is down for 
various reasons, and then the routes start changing for manually created 
routes, and I want to prevent that.

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

How to bind a route to a network adapter and not IP

[Hans Petter Selasky]

Hi,

Maybe there is a simple answer, but how do I bind a route to a network 
interface in 8-stable? Is that possible at all? I'm asking because the routes 
I add in my network setup are lost because of ARP packet drops. I.E. they 
exist for a while, but not forever like I want to.

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote:
 On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote:
  On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote:
   Try the attached patch.  At least, it fixed my problem.
  
  I've committed your patch with some minor modifications.
  
  http://svn.freebsd.org/changeset/base/232448
 
 Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait
 flipping did not make any difference either.  Any other ideas?
 Particularly, I'm curious why disabling all USB modules still does not
 allow this laptop to resume.  What are USB debugging techniques?

USB debugging:

Have options USB_DEBUG in kernel config. Then set xxx.debug = 15 under 
hw.usb, typically hw.usb.uhub.debug=15

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote:
 On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote:
  On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote:
   It does not make a difference for me (i.e., usb suspend/resume
   still broken) but I think I found a typo:
   
   --- sys/dev/usb/controller/usb_controller.c   (revision 232365)
   +++ sys/dev/usb/controller/usb_controller.c   (working copy)
   @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
   
 USB_BUS_UNLOCK(bus);
   
   - bus_generic_shutdown(bus-bdev);
   + bus_generic_suspend(bus-bdev);
   
 usbd_enum_lock(udev);
  
  Same thing here, does not seem to improve anything.  It might
  suspend, resume (with keyboard working), then die on next suspend
  completely.  Or it may die on the first suspend (without suspending
  -- fans are spinning, screen is black and no response to anything
  except hard power-off), this actually happens more often.
 
 Try the attached patch.  At least, it fixed my problem.

Hi,

I've committed your patch with some minor modifications.

http://svn.freebsd.org/changeset/base/232448

Will you take care of the MFC to 8.3-RC + 8-stable?

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote:
 On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote:
  If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and
  see what port change events are coming.
 
 I don't see such oid hw.usb.uhub.debug.  Perhaps it should be hw.usb.debug?
 
  If cfg=255 in usbconfig, then something is wrong.
 
 It seems they are all zeros, per the output I've sent earlier.

If they are all zeros, then everything is working like it should. If you can 
dump the device and configuration descriptors, then there is no USB problem.

I'm thinking it might be some MICROCODE issue that causes the problem. Maybe 
we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to 
the MICROCODE suspend handler?

Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for 
suspend.

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote:
 On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote:
  On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote:
   I was mistaken, the latest kernel with working resume is from Jan 4
   00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to
   come back from zzz(8) successfully.  It seems that offending change is
   rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev
   229450).
 
 I've redone my bisecting, now suspending/resuming around at least ten
 times in console with zzz(8).  I must apologize to rmacklem@, his commit
 has nothing to do with it.  Apparently, the culprit is SVN rev 229370 on
 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to
 bring better support for USB controller suspend and resume.  Kernel csuped
 and built before this date resumes just fine for me.  However, the problem
 might lay deeper: disabling all USB modules (I traditionally run slim
 kernels with everything down to io/mem offloaded into modules) does not fix
 the hang, see below.  Selectively disabling UHCI or EHCI does not make any
 difference either.
 
 Debugging of this issue is, however, complicated by the fact that doing
 call doadump results in Dumping 68M: message (similar problem was
 reported[1] by glebius@ back in 2004), and then nothing happens except for
 IDE led light-up and frozen debugger, which makes post-mortem analysis
 with kgdb(1) impossible.  Setting up serial console (since it's a laptop,
 the only possibility for me right now is to use some noname USB adapter
 via uftdi(4)) works, but kernel GDB does not like it.  Perhaps I'm just
 not passing 0x80 flag correctly, but hint.uftdi.0.flags=0x80 does not
 work.  Is GDB backend impossible with USB serial adapters, or I am just
 doing it wrong?
 
 What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still
 cannot resume, even on previous (before r229370) kernels (the earliest
 I've tried is from Jan 1 00:00 UTC).  Any debugging hints or patches to
 try are highly appreciated.
 
 Thus far, the latest kernel where resume works (with USB stuff enabled) is
 from Jan 3 19:15 UTC.  Hans Petter, do you have any ideas about it?
 

Hi,

The USB controllers should be reset after resume.

Suspend is currently ASYNC. This might be one problem.

Resume is also ASYNC, because we cannot block in the device_resume() callback.

Make sure no serial port adapters have open devices and are blocking suspend 
and resume.

What is output from usbconfig as root, before and after suspend/resume ?

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

Re: Resume broken in 8.3-PRERELEASE

[Hans Petter Selasky]

On Thursday 01 March 2012 22:55:03 Jung-uk Kim wrote:
 On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote:
  On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote:
   On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote:
On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev
 
 wrote:
 I was mistaken, the latest kernel with working resume is from
 Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow
 my laptop to come back from zzz(8) successfully.  It seems
 that offending change is rev. 1.9.2.5 of
 sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450).
   
   I've redone my bisecting, now suspending/resuming around at least
   ten times in console with zzz(8).  I must apologize to rmacklem@,
   his commit has nothing to do with it.  Apparently, the culprit is
   SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which
   (ironically enough) supposed to bring better support for USB
   controller suspend and resume.  Kernel csuped and built before
   this date resumes just fine for me.  However, the problem might
   lay deeper: disabling all USB modules (I traditionally run slim
   kernels with everything down to io/mem offloaded into modules)
   does not fix the hang, see below.  Selectively disabling UHCI or
   EHCI does not make any difference either.
   
   Debugging of this issue is, however, complicated by the fact that
   doing call doadump results in Dumping 68M: message (similar
   problem was reported[1] by glebius@ back in 2004), and then
   nothing happens except for IDE led light-up and frozen debugger,
   which makes post-mortem analysis with kgdb(1) impossible.
   Setting up serial console (since it's a laptop, the only
   possibility for me right now is to use some noname USB adapter
   via uftdi(4)) works, but kernel GDB does not like it.  Perhaps
   I'm just not passing 0x80 flag correctly, but
   hint.uftdi.0.flags=0x80 does not work.  Is GDB backend
   impossible with USB serial adapters, or I am just doing it wrong?
   
   What strikes me most is that even with plain kbdmux(4) or
   atkdb(4) I still cannot resume, even on previous (before r229370)
   kernels (the earliest I've tried is from Jan 1 00:00 UTC).  Any
   debugging hints or patches to try are highly appreciated.
   
   Thus far, the latest kernel where resume works (with USB stuff
   enabled) is from Jan 3 19:15 UTC.  Hans Petter, do you have any
   ideas about it?
  
  Hi,
  
  The USB controllers should be reset after resume.
  
  Suspend is currently ASYNC. This might be one problem.
  
  Resume is also ASYNC, because we cannot block in the
  device_resume() callback.
  
  Make sure no serial port adapters have open devices and are
  blocking suspend and resume.
  
  What is output from usbconfig as root, before and after
  suspend/resume ?
 
 It does not make a difference for me (i.e., usb suspend/resume still
 broken) but I think I found a typo:
 
 Index: sys/dev/usb/controller/usb_controller.c
 ===
 --- sys/dev/usb/controller/usb_controller.c   (revision 232365)
 +++ sys/dev/usb/controller/usb_controller.c   (working copy)
 @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm)
 
   USB_BUS_UNLOCK(bus);
 
 - bus_generic_shutdown(bus-bdev);
 + bus_generic_suspend(bus-bdev);
 
   usbd_enum_lock(udev);
 
 Jung-uk Kim

Hi,

It should be shutdown, because suspend in this case is something else.

USB suspend resume works like this:

At suspend we reset and stop all controllers.

At resume we reset and start all controllers again.

If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see 
what port change events are coming.

If cfg=255 in usbconfig, then something is wrong.

Currently suspend and resume is ASYNC, so that means we are not waiting for 
the actual HC reset to complete.

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

Re: devd based AUTOMOUNTER

[Hans Petter Selasky]

On Saturday 18 February 2012 10:48:11 vermaden wrote:
 Added a check if ntfs-3g is available, if not then mount_ntfs is used
 instead. Added deleting of empty directories at ${MNTPREFIX}.
 Added ${MNTPREFIX} to be set to /mnt or /media according to preference
 
 #! /bin/sh
 
 PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 MNTPREFIX=/media
 LOG=/var/log/automount.log
 STATE=/var/run/automount.state
 DATEFMT=%Y-%m-%d %H:%M:%S
 
 __create_mount_point() { # /* 1=DEV */
   MNT=${MNTPREFIX}/$( basename ${1} )
   mkdir -p ${MNT}
 }
 
 __state_lock() {
   while [ -f ${STATE}.lock ]; do sleep 0.5; done
 
   : ${STATE}.lock
 
 }
 
 __state_unlock() {
   rm ${STATE}.lock
 }
 
 __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */
   __state_lock
   grep -E ${3} ${STATE} 1 /dev/null 2 /dev/null  {
 __log ${1}:duplicated '${STATE}'
 return 1
   }
   echo ${1} ${2} ${3}  ${STATE}
   __state_unlock
 }
 
 __state_remove() { # /* 1=MNT 2=STATE 3=LINE */
   BSMNT=$( echo ${1} | sed 's/\//\\\//g' )
   sed -i '' /${BSMNT}\$/d ${2}
 }
 
 __log() { # /* @=MESSAGE */
   echo $( date +${DATEFMT} ) ${@}  ${LOG}
 }
 
 case ${2} in
   (attach)
 for I in /dev/${1}*
 do
   case $( file -L -s ${I} | sed -E 's/label:\ \.*\//g' ) in
 (*NTFS*)
   dd  ${I} count=1 2 /dev/null \
 
 | strings \
 | head -1 \
 | grep -q NTFS  {
 
   __create_mount_point ${I}
   which ntfs-3g 1 /dev/null 2 /dev/null  {
 ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */
   } || {
 mount_ntfs ${I} ${MNT}
   }
   __log ${I}:mount (ntfs)
   }
   ;;
 (*FAT*)
   dd  ${I} count=1 2 /dev/null \
 
 | strings \
 | grep -q FAT32  {
 
   __create_mount_point ${I}
   fsck_msdosfs -y ${I}
   mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I}
 ${MNT} __log ${I}:mount (fat)
   }
   ;;
 (*ext2*)
   __create_mount_point ${I}
   fsck.ext2 -y ${I}
   mount -t ext2fs ${I} ${MNT}
   __log ${I}:mount (ext2)
   ;;
 (*ext3*)
   __create_mount_point ${I}
   fsck.ext3 -y ${I}
   mount -t ext2fs ${I} ${MNT}
   __log ${I}:mount (ext3)
   ;;
 (*ext4*)
   __create_mount_point ${I}
   fsck.ext4 -y ${I}
   ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */
   __log ${I}:mount (ext4)
   ;;
 (*Unix\ Fast\ File*)
   __create_mount_point ${I}
   fsck_ufs -y ${I}
   mount ${I} ${MNT}
   __log ${I}:mount (ufs)
   ;;
 (*)
   case $( dd  ${I} count=1 2 /dev/null | strings | head -1 ) in
 (EXFAT)
   __create_mount_point ${I}
   mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */
   __log ${I}:mount (ufs)
   ;;
 (*) continue ;;
   esac
   ;;
   esac
   __state_add ${I} $( mount | grep -m 1  ${MNT}  | awk '{printf $1}'
 ) \ ${MNT} || continue
 done
 ;;
 
   (detach)
 MOUNT=$( mount )
 __state_lock
 grep ${1} ${STATE} \
 
   | while read DEV PROVIDER MNT
 
 do
   TARGET=$( echo ${MOUNT} | grep -E ^${PROVIDER}  | awk '{print
 $3}' ) [ -z ${TARGET} ]  {
 __state_remove ${MNT} ${STATE} ${LINE}
 continue
   }
   umount -f ${TARGET} 
   unset TARGET
   __state_remove ${MNT} ${STATE} ${LINE}
   __log ${DEV}:umount
 done
 __state_unlock
 __log /dev/${1}:detach
 find ${MNTPREFIX} -type d -empty -delete
 ;;
 
 esac
 
  Not sure if you've looked at disktype in sysutils
  but it may be useful to you.
 

Hi,

Should your script be written like an rc.d script, so that one can 
enable/disable this automounting from /etc/rc.conf?

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

Re: panic: umass1: Unknown state 1

[Hans Petter Selasky]

On Thursday 13 October 2011 20:06:34 Oliver Fromme wrote:
 I just got this panic on a recent stable/8 amd/64 system:
 panic: umass1: Unknown state 1
 
 Here's a screen shot from the KVM console:
 
 http://www.secnetix.de/olli/tmp/umass-panic.jpg
 
 Unfortunately, the crash dump that was written seems to be
 lost.  A quick search on the PRs doesn't reveal anything
 either ...  has anyone seen this type of panic before?
 
 It happened when I was switching virtual remote drives in
 the management application of an IBM blade center, i.e.
 the USB drive is actually a virtual drive emulated by the
 blade management system.  I did similar things a few times
 before without a panic, so this isn't 100% reproducable.
 Also, I'm reluctant to try again because this is a quite
 important production server.
 

Hi,

ehci_softintr() is not part of the USB stack in 8-stable and 9-stable. Must be 
7-stable you are running.

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

Re: USB/coredump hangs in 8 and 9

[Hans Petter Selasky]

On Friday 19 August 2011 18:32:13 Andriy Gapon wrote:
 on 19/08/2011 00:24 Hans Petter Selasky said the following:
  On Thursday 18 August 2011 19:04:10 Andriy Gapon wrote:
  If you can help Hans to figure out what you is wrong with USB subsystem
  in this respect that would help us all.
  
  Hi,
  
  usb_busdma.c:   /* we use mtx_owned() instead of this function */
  usb_busdma.c:   owned = mtx_owned(uptag-mtx);
  usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
  usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
  usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
  usb_hub.c:  if (mtx_owned(bus-bus_mtx)) {
  usb_transfer.c: if (!mtx_owned(info-xfer_mtx)) {
  usb_transfer.c: if (mtx_owned(xfer-xroot-xfer_mtx)) {
  usb_transfer.c: while (mtx_owned(xroot-udev-bus-bus_mtx)) {
  usb_transfer.c: while (mtx_owned(xroot-xfer_mtx)) {
 
  One fix you will need to do, if mtx_owned is not giving correct value is:
 First, could you please clarify what is the correct, or rather - expected,
 value in this case.  It's not immediately clear to me if we should
 consider all locks as owned or un-owned in a situation where all locks are
 actually skipped behind the scenes.
 Maybe USB code should explicitly check for that condition as to not make
 any unsafe assumptions.
 
 Second, it's not clear to me what the above list actually represents in the
 context of this discussion.

Hi,

The mtx_owned() is not only used to assert mutex ownership, but also to figure 
out which context the function is being called from. If the correct mutex is 
not locked already we postpone the work until later. In the panic case, there 
is no way to postpone work, so this check should be skipped in case of panic, 
because there is no other thread to put work to.

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

Re: USB/coredump hangs in 8 and 9

[Hans Petter Selasky]

On Saturday 20 August 2011 18:45:57 Andriy Gapon wrote:
 SCHEDULER_STOPPED

The USB code needs to check for the SCHEDULER_STOPPED and cold at the present 
moment. If this state can be set during bootup, and cleared at the same time 
like cold, it would be very good.

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

Re: USB/coredump hangs in 8 and 9

[Hans Petter Selasky]

On Saturday 20 August 2011 19:09:02 Andriy Gapon wrote:
 on 20/08/2011 19:54 Hans Petter Selasky said the following:
  On Saturday 20 August 2011 18:45:57 Andriy Gapon wrote:
  SCHEDULER_STOPPED
  
  The USB code needs to check for the SCHEDULER_STOPPED and cold at the
  present moment. If this state can be set during bootup, and cleared at
  the same time like cold, it would be very good.
 
 Sorry again - not sure if I follow.
 SCHEDULER_STOPPED is supposed to be set on panic and never be reset.  It's
 like a mirror of 'cold' in a sense.

OK. Then you should add a test  !SCHEDULER_STOPPED where I pointed out:

static void
usbd_callback_wrapper(struct usb_xfer_queue *pq)
{
struct usb_xfer *xfer = pq-curr;
struct usb_xfer_root *info = xfer-xroot;

USB_BUS_LOCK_ASSERT(info-bus, MA_OWNED);
if (!mtx_owned(info-xfer_mtx)  !SCHEDULER_STOPPED) {
/*
 * Cases that end up here:
 *

And also ensure that no mutex asserts can trigger further panics.

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

Re: USB/coredump hangs in 8 and 9

[Hans Petter Selasky]

On Thursday 18 August 2011 19:04:10 Andriy Gapon wrote:
 If you can help Hans to figure out what you is wrong with USB subsystem in
 this respect that would help us all.

Hi,

usb_busdma.c:   /* we use mtx_owned() instead of this function */
usb_busdma.c:   owned = mtx_owned(uptag-mtx);
usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
usb_compat_linux.c: do_unlock = mtx_owned(Giant) ? 0 : 1;
usb_hub.c:  if (mtx_owned(bus-bus_mtx)) {
usb_transfer.c: if (!mtx_owned(info-xfer_mtx)) {
usb_transfer.c: if (mtx_owned(xfer-xroot-xfer_mtx)) {
usb_transfer.c: while (mtx_owned(xroot-udev-bus-bus_mtx)) {
usb_transfer.c: while (mtx_owned(xroot-xfer_mtx)) {

One fix you will need to do, if mtx_owned is not giving correct value is:

static void
usbd_callback_wrapper(struct usb_xfer_queue *pq)
{
struct usb_xfer *xfer = pq-curr;
struct usb_xfer_root *info = xfer-xroot;

USB_BUS_LOCK_ASSERT(info-bus, MA_OWNED);
if (!mtx_owned(info-xfer_mtx)) {

The above if should be anded with  !paniced  !dumping ... or maybe the 
new not scheduling variable is good for this purpose?

/*
 * Cases that end up here:
 *

#if USB_HAVE_BUSDMA
if (mtx_owned(xfer-xroot-xfer_mtx)) {
struct usb_xfer_queue *pq;


This case is more like a BUS-DMA error case, and is not so important to 
execute.

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

Re: USB/coredump hangs in 8 and 9

[Hans Petter Selasky]

On Friday 12 August 2011 21:59:21 Andrew Boyer wrote:
 Re: panic: bufwrite: buffer is not busy??? (originally on freebsd-net)
 Re: debugging frequent kernel panics on 8.2-RELEASE (originally on
 freebsd-stable) Re: System hang in USB umass module while processing panic
  (originally on freebsd-usb)
 
 Hello Andriy and Hans,
 
 Sorry for tying in so many discussions on this topic, but I think I have an
 explanation for the problems we have been reporting* with hanging
 coredumps on multicore systems on 8.2-RELEASE, and it has implications for
 Andriy's proposed scheduler patch** and for USB.
 
 In today's 8.X and 9.X branches, nothing that I can find stops the other
 CPUs when the kernel panics, but many parts of the locking code get
 disabled (grep on 'panicstr').  The 'bufwrite: buffer is not busy???'
 panic is caused by the syncer encountering an error.  If that happens when
 it's on the dumping CPU everything hangs.  If it's running on a different
 CPU, it will be blocked and hidden by the panic_cpu spinlock in panic(),
 and the dump continues, polling every attached keyboard for a Ctl-C.
 
 But, the new 8.X USB stack relies on multithreading.  (The new stack is the
 variable that broke coredumps for us in the 7.1-8.2 transition, I think.)
  SVN 224223 fixes a hang that would happen when dumpsys() polls the USB
 keyboard (IPMI KVM, in our case).  That helps, but it only gets as far as
 usb_process(), where it hangs in a loop around a cv_wait() call.  This is
 easy to reproduce by adding code to the watchdog to break into the
 debugger if panicstr is set.
 
 I am experimenting with Andriy's patch** to stop the scheduler and it seems
 to be most of the way there, stopping the CPUs and disabling the rest of
 locking.  There are a few places that still reference panicstr, but that's
 minor.  These are the changes I made to the patch: * Changed
 ukbd_do_poll() to return immediately if SCHEDULER_STOPPED() is true, so
 that we don't hang up in USB.  ukbd_yield()  locks up in DROP_GIANT(), and
 if you skip ukbd_yield(), usbd_transfer_poll() locks up trying to drop
 mutexes. * Changed the call to spinlock_enter() back to critical_enter(),
 so that interrupts stay enabled and the hardclock still functions. * Added
 code in the beginning of panic() to switch to CPU 0, so that we're able to
 service the hardclock interrupts and so that watchdog panics get through.
 
 This has worked 100% for me so far, although anyone using a USB keyboard or
 dump device would still be out of luck.
 
 Thoughts?  It seems like stopping all of the other CPUs is the right thing
 to do on a panic (what are they doing otherwise?).  Are the USB issues
 fixable?  If Andriy's patch get committed it might just involve
 short-circuiting all of the locking in the polling path, but I haven't
 gotten that far yet.  I bet dumping to NFS will have the same problem.

Hi.

USB does not rely on multithreading when doing polling. It bypasses the 
processing thread and calls the function directly. Also I can add the USB has 
recursive checking flags, so that if important functions are already called, 
the code will simply return.

USB does not rely on locking after panic, except maybe mtx_owned() returning 
the correct value. Your approaching having the mtx_lock() / mtx_unlock() 
functions simply do nothing will affect the USB polling ability if mtx_owned() 
does not return true when the lock is locked. So maybe in case of SCHEDULER 
stopped we should just steal the lock instead of just returning. Also I sssume  
that all interrupts and all other processes are blocked at the moment of panic 
or dump.

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

Re: problem with urtw

[Hans Petter Selasky]

On Thursday 09 June 2011 22:34:18 Jim Bryant wrote:
 I just bought one of those chinese (apparently the same unit relabeled
 and being sold by multiple companies) realtek RTL8187B wifi units.  The
 price is right.
 
 The label name on this one is WiFySky 1500mW.
 
 other than the fact that the case it is enclosed in is really cheesy,
 there is a more immediate problem with this.
 
 the current urtw driver returns a 6.
 
 here we go:
 
 on insert:
 
 ugen3.2: vendor 0x0bda at usbus3
 
 after kldload if_urtw.ko:
 
 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
 on usbus3
 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
 device_attach: urtw0 attach returned 6
 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
 on usbus3
 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
 device_attach: urtw0 attach returned 6
 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
 on usbus3
 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
 device_attach: urtw0 attach returned 6
 urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/2.00, addr 2
 on usbus3
 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
 device_attach: urtw0 attach returned 6
 
  3:28:35pm  argus(48): usbconfig -u 3 -a 2 dump_device_desc
 ugen3.2: product 0x8187 vendor 0x0bda at usbus3, cfg=0 md=HOST
 spd=HIGH (480Mbps) pwr=ON
 
   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x
   bDeviceSubClass = 0x
   bDeviceProtocol = 0x
   bMaxPacketSize0 = 0x0040
   idVendor = 0x0bda
   idProduct = 0x8187
   bcdDevice = 0x0200
   iManufacturer = 0x0001  Wireless Manufacturer
   iProduct = 0x0002  USB2.0 WLAN Adapter
   iSerialNumber = 0x  no string
   bNumConfigurations = 0x0001
 
  3:28:48pm  argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc
 ugen3.2: product 0x8187 vendor 0x0bda at usbus3, cfg=0 md=HOST
 spd=HIGH (480Mbps) pwr=ON
 
 
  Configuration index 0
 
 bLength = 0x0009
 bDescriptorType = 0x0002
 wTotalLength = 0x0051
 bNumInterfaces = 0x0001
 bConfigurationValue = 0x0001
 iConfiguration = 0x0004  Wireless Network Card
 bmAttributes = 0x0080
 bMaxPower = 0x00fa
 
 Interface 0
   bLength = 0x0009
   bDescriptorType = 0x0004
   bInterfaceNumber = 0x
   bAlternateSetting = 0x
   bNumEndpoints = 0x0009
   bInterfaceClass = 0x00ff
   bInterfaceSubClass = 0x00ff
   bInterfaceProtocol = 0x00ff
   iInterface = 0x0002  USB2.0 WLAN Adapter
 
  Endpoint 0
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0083  IN
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 1
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0004  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 2
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0005  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 3
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0006  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 4
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0007  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 5
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x0089  IN
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 6
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x000a  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 7
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x000b  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 bRefresh = 0x
 bSynchAddress = 0x
 
  Endpoint 8
 bLength = 0x0007
 bDescriptorType = 0x0005
 bEndpointAddress = 0x000c  OUT
 bmAttributes = 0x0002  BULK
 wMaxPacketSize = 0x0200
 bInterval = 0x
 

Re: [releng_8 tinderbox] failure on arm/arm

[Hans Petter Selasky]

On Friday 29 April 2011 01:51:24 Andrew Thompson wrote:
 On 29 April 2011 11:30, Jeremy Chadwick free...@jdc.parodius.com wrote:

 CC'ing hselasky and thompsa for review of this.
 
 For failure logs (so far ia64 and arm), please see end of this page:
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html
 
 Commit question is revision 1.6.2.2 to RELENG_8:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/usbdump/usbdump.c
 
 Relevant code bits:
 
 I merged the missing rev a few hours ago, 
 http://svnweb.freebsd.org/base?view=revisionrevision=221185

Thank you Andrew!

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

Re: Fwd: SNDCTL_DSP_GETIPTR implementation

[Hans Petter Selasky]

On Friday 29 April 2011 07:59:39 Andriy Gapon wrote:
 I intend to commit the following change soon and MFC it after a short
 period of time.  Please test it if you use multimedia applications, both
 native and Linux, especially if they deal with audio recording/capture.
 
 Thank you.

Seems to work with AMD64 8-stable.

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

Fwd: Re: System lockups caused by USB external HDD

[Hans Petter Selasky]

--  Forwarded Message  --

Subject: Re: System lockups caused by USB external HDD
Date: Tuesday 25 January 2011, 01:48:03
From: CDP dr.c...@gmail.com
To: freebsd-...@freebsd.org
CC: Hans Petter Selasky hsela...@c2i.net, m...@freebsd.org

On 01/24/11 13:27, Hans Petter Selasky wrote:
 On Monday 24 January 2011 12:08:47 CDP wrote:
 On 01/24/11 11:34, Hans Petter Selasky wrote:
 On Monday 24 January 2011 10:00:53 CDP wrote:
 On 01/24/11 01:56, Daniel O'Connor wrote:
 On 24/01/2011, at 9:10, CDP wrote:
 g_vfs_done():da0s2[WRITE(offset=, length=16384)]error = 5
 [several more lines similar to the above]
 panic: softdep_move_dependencies: need merge code
 cpuid = 0
 KDB: stack backtrace:
 #0 0x... at kdb_backtrace+0x5e
 #1 0x... at panic+0x182

 It looks like the disk is dying, or the FS is corrupt (the former might
 cause the later).

 Can you run smartctl on the disk? Unfortunately a lot of enclosures
 reject SMART commands so you might not be able to :(

 I have attached the output of smartctl -d sat -a /dev/da0. I didn't yet
 run a SMART long test for the simple reason that the disk is going into
 sleep mode and interrupts it. Haven't bothered to keep it alive for a
 long test but I might just do that.

 Although, I doubt it's a disk failure, since I do backups on it without
 problems by using FreeBSD 7.3, on the same space where FreeBSD 8.x
 fails. And I am talking about over 150GB of data in one run, while
 8.2-RC2 crashes after 5-10GB. I have experienced disk failure in the
 past, on SATA, and a few read/write errors never caused a system lockup.

 My feeling is that enough traffic on USB causes the problem, and that
 this problem is only present in the new USB stack.
 Unfortunately downgrading to 7.x is not an option because there are
 things that won't work on this notebook.

 If you run a simple test like this:

 dd if=/dev/da0 of=/dev/null bs=65536
 dd if=/dev/da0 of=/dev/null bs=16384

 Do you then see any errors?

 Do you have a spare USB memory stick which you could run similar write
 tests on?

 Both reads fail with I/O error, while writes to an unused partition seem
 to be fine (I interrupted the writes after a while):

 % dd if=/dev/da0 of=/dev/null bs=65536
 dd: /dev/da0: Input/output error
 191732+0 records in
 191732+0 records out
 12565348352 bytes transferred in 429.999272 secs (29221790 bytes/sec)

 % dd if=/dev/da0 of=/dev/null bs=16384
 dd: /dev/da0: Input/output error
 126427+0 records in
 126427+0 records out
 2071379968 bytes transferred in 169.431766 secs (12225452 bytes/sec)

 # dd if=/dev/random of=/dev/da0s3 bs=65536
 ^C329378+0 records in
 329377+0 records out
 21586051072 bytes transferred in 1003.020293 secs (21521051 bytes/sec)

 # dd if=/dev/random of=/dev/da0s3 bs=16384
 ^C679571+0 records in
 679571+0 records out
 11134091264 bytes transferred in 690.135793 secs (16133189 bytes/sec)

 This is what I get in /var/log/messages when the I/O error occurs:
 (da0:umass-sim0:0:0:0): AutoSense failed

 However, I experience no lockup. Maybe this situation is not handled
 correctly at another level ?
 
 I haven't looked into the code of CAM or GEOM that much so I won't say too 
 much about that. I believe the USB/umass is not to blame. What you could do 
is 
 to add a conditional error printout in umass_t_bbb_status_callback() in 
 /sys/dev/usb/storage/umass.c when the error happens. If that error is not a 
 USB transport error, then we are most likely seeing a SCSI issue in layers 
 above umass. Or if you have access to USB analyser use that. There is now 
also 
 the option to trace USB from the kernel itself, but the feature is in its 
 early development.


The panics I was able to catch/inspect (latest from add_to_worklist() /
ffs_softdep.c) indicated they were thrown by ffs/softupdates code,
therefore I tried disabling softupdates.
The system doesn't panic anymore. The operations on the USB HDD still
stop, but after several tens of seconds the system logs the 'autosense
failed' error, a bunch of write errors, and the copy operation resumes.
md5 shows the copied files are identical to the source files.

In 7.x I don't recall having any kind of errors, neither temporary locks
in disk operations, so I'm guessing the 'autosense failed' situation is
handled differently in 8.x, compared to 7.x.

Claudiu.


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

Re: Keyboard repeat issues with Dell Optiplex 980s

[Hans Petter Selasky]

On Wednesday 19 January 2011 15:51:41 Steve Polyack wrote:
 On 01/19/11 08:48, Steve Polyack wrote:
  On 1/18/2011 5:56 PM, Jeremy Chadwick wrote:
  On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote:
  We've recently upgraded a few desktop workstations from Dell
  Optiplex 960s to Optiplex 980s.  We were running FreeBSD
  8.1-RELEASE.  The migration was performed by simply swapping the
  drives into the new systems.  Immediately after switching people
  over, they all began to report bizarre keyboard issues - things like
  infinite key repeats (letters, numbers, enter) for keys they did
  not hold down.  The key repeats continue indefinitely until another
  key is pressed.  Occasionally, even mouse input will trigger similar
  infinite keyboard input repetition.  In addition to the repeat
  issue, sometimes physical key-presses are not registered by FreeBSD,
  leading to typos and angry developers.
  
  We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these
  systems, and the issue persists.  Because of the observed behavior,
  I'm thinking that this is due to new hardware in the 980s which
  isn't timing or handling interrupts correctly under the FreeBSD
  kernel.
  
  Looking at a 'pciconf -lvb' from each system, I noticed that the 980
  has two USB controllers which probe under ehci(4), while the 960
  (which does not exhibit this problem), enumerates six uhci(4)
  controllers and two ehci(4) controllers.  To cut to the chase here,
  the 960 users' keyboards probe under a USB1.0 uhci(4), while the
  980s only have ehci(4) devices to attach to.
  
  So, I guess what I'm asking is - has anyone else seen any keyboard
  repeat or other USB craziness with ehci(4) ports or otherwise Intel
  PCH controllers?Any fellow Optiplex 980 users?  I'd be more than
  happy to provide pciconf or other output if requested.
  
  Try adding the following to /boot/loader.conf then reboot and see if
  the excessive repeat behaviour changes:
  
  hint.kbdmux.0.disabled=1
  
  It would also help if you would state exactly what brand/model of
  keyboard is used.  Yes, believe it or not, it matters.  dmesg output
  would be helpful in this case.
  
  The keyboard is also a Dell model - model KB1421, or listed as Dell
  QuiteKey Keyboard under dmesg.  The same keyboard does not exhibit
  the strange behavior when used with the older model of tower (Optiplex
  960).
  
   I'll reboot today with the loader.conf hint you provided.  I'll let
  
  you guys know if it helps.  Thanks!
 
 The problem still exists with the kbdmux.0.disabled hint.  It definitely
 took effect, as there is no longer a /dev/kbdmux0, and dmesg lists the
 refusal to register the kbdmux module.  Any other ideas?  We've tried
 playing with the hw.usb.ehci.lostinrbug and hw.usb.ehci.no_hs sysctls,
 but they don't make a difference either.
 
 Looking at the ehci(4) man page, this sticks out at me:
 BUGS
   The driver is not finished and is quite buggy.
 
   There is currently no support for isochronous transfers.

For FreeBSD 8+ this is not true. Probably the manpage has not been updated. 
Hence you are seeing a different number of UHCI controllers, this looks like 
an ACPI problem. USB keyboards usually require a UHCI to enumerate. The EHCI 
can only enumerate High Speed devices.

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

Webcamd testers wanted on FreeBSD 8.2

[Hans Petter Selasky]

Hi,

Can someone running FreeBSD 8.2-RC1 with more than one or external USB webcam 
or DVB-XXX devices verify the following:

1) Install /usr/ports/multimedia/webcamd

2) Reboot

3) Check that character devices are created for your device(s) under /dev

/dev/videoX for webcams

/dev/dvb/adapterX for DVB devices

3) HAL should show your device.

lshal | grep -i video
lshal | grep -i dvb

4) Hot replug the USB plug of your USB webcam/DVB device, perform checks 1,2 
and 3. If same result everything is OK.

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

Re: Webcamd testers wanted on FreeBSD 8.2

[Hans Petter Selasky]

On Saturday 08 January 2011 18:41:10 Hans Petter Selasky wrote:
 Hi,
 
 Can someone running FreeBSD 8.2-RC1 with more than one or external USB
 webcam or DVB-XXX devices verify the following:
 
 1) Install /usr/ports/multimedia/webcamd
 
 2) Reboot
 
 3) Check that character devices are created for your device(s) under /dev
 
 /dev/videoX for webcams
 
 /dev/dvb/adapterX for DVB devices
 
 3) HAL should show your device.
 
 lshal | grep -i video
 lshal | grep -i dvb
 
 4) Hot replug the USB plug of your USB webcam/DVB device, perform checks
 1,2 and 3. If same result everything is OK.
 

Hi,

After that the devd notify string was changed last year, hald stopped 
registering attached USB devices because the match string was too narrow. Can 
someone with HAL knowledge please review the attached patch for 
/usr/ports/sysutils/hal .

My patch uses strstr() instead of strncmp(), but really a full parse with 
respect to  characters is required, because cdev=ugen, could appear inside 
some strings.

When it works, lshal will show USB devices plugged after boot.

--HPS
diff -ur hal.orig/files/patch-hald_freebsd_hf-usb2.c hal/files/patch-hald_freebsd_hf-usb2.c
--- hal.orig/files/patch-hald_freebsd_hf-usb2.c	2011-01-08 19:01:54.0 +0100
+++ hal/files/patch-hald_freebsd_hf-usb2.c	2011-01-08 19:05:14.0 +0100
@@ -133,8 +133,8 @@
 +  (strcmp(type, CREATE)  strcmp(type, DESTROY)))
 +return FALSE;
 +
-+  if (! strncmp(data, cdev=ugen, strlen(cdev=ugen)) ||
-+  ! strncmp(data, cdev=usb, strlen(cdev=usb)))
++  if ((strstr(data, cdev=ugen) != NULL) ||
++  (strstr(data, cdev=usb) != NULL))
 +return TRUE;
 +
 +  return FALSE;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Webcamd testers wanted on FreeBSD 8.2

[Hans Petter Selasky]

On Sunday 09 January 2011 00:17:04 Luigi Rizzo wrote:
 speaking of webcamd, any idea on how to debug operation
 of skype and webcamd ?
 
 The thread at
 
 http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-October/011327.h
 tml
 
 indicates the problem and shows symptoms.
 The most recent version of webcamd (0.1.18) now supports
 more of my webcams but still with similar problems.
 
 If (as it seems) the problem is related to the output format
 generated by the camera, i wonder if it is possible to
 tweak webcamd to generate a specific video format
 on startup, irrespective of the native camera format ?
 

Hi Luigi,

You can try adding a printout in:

kernel/kern_file.c, function linux_ioctl()

to get all the ioctls that skype issues. Maybe you get some clues from that.

 I am under the impression (perhaps wrong) that webcamd
 (or libv4l1) implements some conversion of the native formats ?

libv4l does format conversion yes. That's the idea behind libv4l, to not do 
that format conversion in the kernel.

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

Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

[Hans Petter Selasky]

On Wednesday 01 September 2010 18:53:46 Julian H. Stacey wrote:
  FreeBSD -7  -8 do not support ISDN I'm told.
  So 6.4 is the last working FreeBSD ISDN.
  
  Could FreeBSD reinsert ISDN back into current/8/7 support ?
  Perhaps via:
  - a student SOC project ?
  - FreeBSD foundation paying a FreeBSD consultant (I know one who has the
  
expertise already, has the time,  could use some money (I don't mean
me,  he didn't aske me to post this, it'll come as a suprise to him
:-)
  
  - Or whatever other method to get ISDN back in kernel ?
 
 It seems code exists :-)
 
 http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html
   ISDN4BSD package has been updated to compile on FreeBSD
   8-current
 
   http://www.selasky.org/hans_petter/isdn4bsd/
 
 Apparently needs massaging into main FreeBSD tree.

I agree that my I4B code should be re-written somewhat before committed. 
Possibly we should update the API's present too, to support IP-telephony 
aswell.

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

Re: Regression with Asus K8N7-E deluxe motherboard on 8-stable: ACPI or PCI drivers bug ?

[Hans Petter Selasky]

On Saturday 02 January 2010 19:54:11 Olivier Cochard-Labbé wrote:
 ohci early: SMM active, request owner change
 ohci early: SMM does not respond, resetting

If the I/O address range changed, then the above can be explained by that we 
are reading/writing to an invalid range.

USB debug sysctls: /boot/loader.conf

hw.usb.ohci.debug=15
hw.usb.ehci.debug=15

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

Re: 8.0-RC USB/FS problem

[Hans Petter Selasky]

On Thursday 26 November 2009 08:30:52 Guojun Jin wrote:
 Most crash had the same back trace. This is also true when USB access
 hangs, then unplug the drive.

I think from the backtrace that this is not an USB issue. It is a file-system 
issue.

--HPS

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

Re: 8.0-RC USB/FS problem

[Hans Petter Selasky]

On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote:
 What other debug shall we turn on to analyze this problem.

Are you able to extract the panic message? Try enabling dump on the swap 
partition.

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

Re: 8.0-RC USB/FS problem

[Hans Petter Selasky]

On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote:
 http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2

I'm not able to fetch this file. Could you extract the panic backtrace?

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

Re: 8.0-RC USB/FS problem

[Hans Petter Selasky]

On Tuesday 24 November 2009 17:58:47 Guojun Jin wrote:
 Sorry for the typo -- it is public not pub in the middle. The others should
 be all public.

 http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2


%fetch http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2
fetch: http:/www.daemonfun.com/archives/public/USB/crash1-reset.bz2: No 
address record

--HPS

 -Original Message-
 From: Hans Petter Selasky [mailto:hsela...@c2i.net]
 Sent: Tue 11/24/2009 12:33 AM
 To: Guojun Jin
 Cc: freebsd-...@freebsd.org; b...@freebsd.org; freebsd-stable@freebsd.org
 Subject: Re: 8.0-RC USB/FS problem

 On Tuesday 24 November 2009 09:12:45 Guojun Jin wrote:
  http:/www.daemonfun.com/archives/pub/USB/crash1-reset.bz2

 I'm not able to fetch this file. Could you extract the panic backtrace?

 --HPS

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

Re: 8.0-RC USB problem -- how to recover a damaged USB stick

[Hans Petter Selasky]

On Sunday 22 November 2009 04:40:27 Guojun Jin wrote:
 Does anyone know if it is possible to revocer such damaged USB stick?

Hi,

There are several recovery tools in /usr/ports for this kind of task.

For example photorec .

--HPS

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

Re: 8.0-RC USB/FS problem

[Hans Petter Selasky]

On Sunday 22 November 2009 05:38:13 Guojun Jin wrote:
 Tried on the USB hard drive:

 Deleted slice 3 and recreated slice 3 with two partitions s3d and s3e.
 Was happy because successfully did dump/restore on s3d, and thought it just
 partition format issue; but system crashed during dump/restore on s3e, and
 partition lost the file system type.

 wolf# mount /dev/da0s3e /mnt
 WARNING: /mnt was not properly dismounted
 /mnt: mount pending error: blocks 35968 files 0
 wolf# fsck da0s3e
 fsck: Could not determine filesystem type
 wolf# bsdlabel da0s3
 # /dev/da0s3:
 8 partitions:
 #size   offsetfstype   [fsize bsize bps/cpg]
   c: 1757350350unused0 0 # raw part,
 don't edi t
   d: 1887436804.2BSD0 0 0
   e: 156860667 188743684.2BSD0 0 0

 Therefore, tried directly use fsck_ufs on both USB hard drive and USB stick
 to get file system clean up. All data got back now.

 The machine has run with FreeBSD 6.1 all the way to 7.2 without such
 problem. How can we determine what could go wrong in 8.0? FS or USB.

Hi,

Error 5 means IO error, so probably the transport layer, USB or lower, is to 
blame.

Some things to check:

1) Make sure the connection for your memory stick is Ok.
2) Make sure there is enough power for your memory stick.

Regarding memory sticks:

Other operating systems do a port bus reset when the device has a problem. On 
FreeBSD we just try a software reset via the control endpoint. I guess that it 
is a device problem you are seeing. The USB stack in FreeBSD is faster than 
the old one, and maybe the faster queueing of mass storage requests trigger 
some hidden bugs in your device.

When the problem happens try:

sysctl hw.usb.umass.debug=-1

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

Re: 8.0-RC3 USB lock up on mounting two partitions from one USB drive

[Hans Petter Selasky]

Hi,

I'm not sure if this is an USB issue or not. If you get READ/WRITE errors and 
the drive simply dies then it might be the case. Else it is a system issue.

There are quirks for mass storage which you can add to 
sys/dev/usb/storage/umass.c .

--HPS

On Wednesday 18 November 2009 08:33:07 Guojun Jin wrote:
 Did newfs on those partition and made things worsen -- restore completely
 fails: (I had experienced another similar problem on an IDE, which works
 well for 6.4 and 7.2, but 8.0.) This dirve works fine under FreeBSD 6.4.

 Is something new in 8.0 making disk partition schema changed?

 g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6
 g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6
 fopen: Device not configured
 cannot create save file ./restoresymtable for symbol table
 abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status ==
 0xa, scs i status == 0x0
 (da0:umass-sim0:0:0:0): removing device entry
 ugen1.2: DMI at usbus1
 umass0: DMI Ultra HDD, class 0/0, rev 2.00/1.19, addr 2 on usbus1
 umass0:  SCSI over Bulk-Only; quirks = 0x
 umass0:0:0:-1: Attached to scbus0
 da0 at umass-sim0 bus 0 target 0 lun 0
 da0: DMI Ultra HDD 1.19 Fixed Direct Access SCSI-0 device
 da0: 40.000MB/s transfers
 da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)
 Device da0s3d went missing before all of the data could be written to it;
 expect data loss.

 99  23:19   sysinstall
100  23:20   newfs /dev/da0s3d
101  23:20   newfs /dev/da0s3e
102  23:21   mount /dev/da0s3d /mnt
103  23:21   cd /mnt
104  23:21   dump -0f - /home | restore -rf -
105  23:27   history 15



 -Original Message-
 From: Guojun Jin
 Sent: Tue 11/17/2009 11:05 PM
 To: freebsd-stable@freebsd.org
 Cc: questi...@freebsd.org; freebsd-...@freebsd.org
 Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive

 When mounting two partitions from a USB dirve, it can cause the drive
 access lock up for a long time. Details:

 Terminal 1 --
 term1# mount /dev/da0s3d  /mnt
 term1# cd /mnt ; rm -fr *

 when rm starts, go to terminal 2 and do:

 term2# mount /dev/da0s3e /dist ### this will hanging for a long time and
 USB hard drive activity light is off. After more than 1-2 minutes, mount
 returns, and the drive activity light is blinking, thus removing is going
 on.

 term2# ls /dist   ### this will cause dUSB dirve hanging again -- no
 avtivity. Similarly, ls will finish in a couple of miniutes or longer, the
 rm command continues; but for a while, the drive activity will stop again.

 Reboot machine, repeat the above steps, and result will be the same. Reboot
 machine again, and just mount one partition, then doing rm -rf * without
 involve the second partition, rm will finish quickly.

 Has anyone obseved this behave on 8.0-RC?

 -Jin

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

Re: Console has no name?

[Hans Petter Selasky]

Hi,

Your patch has been committed to USB P4:


http://p4web.freebsd.org/chv.cgi?CH=170003


Thanks for reporting!

--HPS

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

Re: Console has no name?

[Hans Petter Selasky]

On Saturday 31 October 2009 15:53:53 Dimitry Andric wrote:
 On 2009-10-31 14:14, Dimitry Andric wrote:
  Somewhere between r198312 and r198702 I started getting this message
  during boot, on a machine using serial console:
 
  WARNING: console at 0xc093cea0 has no name

 Okay, this seems to be caused by r198655, which is an MFC of r197570,
 where experimental support for USB serial console was added.

 However, the consdev::cn_name field is never initialized in
 usb_serial.c, whereas this does happen in other console drivers.

 There doesn't seem to be a consensus whether this field needs to be
 initialized in the _cnprobe() or _cninit() functions: I count 9 instances
 of initialization in the former, and 3 in the latter.  Is there a
 preferred way?

 Since _cnprobe seems more popular, I propose the following fix:

 Index: sys/dev/usb/serial/usb_serial.c
 ===
 --- sys/dev/usb/serial/usb_serial.c   (revision 198702)
 +++ sys/dev/usb/serial/usb_serial.c   (working copy)
 @@ -1301,6 +1301,7 @@ static void
  ucom_cnprobe(struct consdev  *cp)
  {
   cp-cn_pri = CN_NORMAL;
 + strlcpy(cp-cn_name, ucom, sizeof cp-cn_name);
  }

  static void

Patch looks fine by me.

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

Re: Unable to read from CCID USB reader

[Hans Petter Selasky]

On Tuesday 19 May 2009, Mario Pavlov wrote:
 Hi,
 I tired CURRENT and it's working for me :)
 I only have one small issue...
 when I unplug the reader pcscd goes to some sort of infinite loop
 it would print this forever:

 48111939 ccid_usb.c:491:WriteUSB() usb_bulk_write(/dev/usb//dev/ugen4.2):
 Device busy 0020 ifdwrapper.c:469:IFDStatusICC() Card not transacted:
 612
 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to:
 ACS ACR 38U-CCID 00 00 00402930 ccid_usb.c:491:WriteUSB()
 usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 0021
 ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to:
 ACS ACR 38U-CCID 00 00 00402953 ccid_usb.c:491:WriteUSB()
 usb_bulk_write(/dev/usb//dev/ugen4.2): Device not configured 0016
 ifdwrapper.c:469:IFDStatusICC() Card not transacted: 612
 0010 eventhandler.c:333:EHStatusHandlerThread() Error communicating to:
 ACS ACR 38U-CCID 00 00 ...

Maybe a bug in the pcsc driver.

 ...
 ...

 firefox does almost the same thing:

 [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No
 readers found [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers:
 SCardEstablishContext failed: 0x8010001d [opensc-pkcs11]
 reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found
 [opensc-pkcs11] reader-pcsc.c:906:pcsc_detect_readers:
 SCardEstablishContext failed: 0x8010001d [opensc-pkcs11]
 reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found
 ...
 ...
 ...

 I guess this is not FreeBSD's fault, is it ?

If the usb device /dev/usb/xxx for your device is not accessible to firefox 
then firefox can't open it.

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

Re: Unable to read from CCID USB reader

[Hans Petter Selasky]

On Sunday 17 May 2009, Mario Pavlov wrote:
 Hi,
 I just got a CCID USB reader with my digital signature...unfortunately I
 can't make it work I installed pcsc-lite and libccid from ports...
 when I plug-in the reader I can see this:

 ugen0: vendor 0x072f CCID USB Reader, class 0/0, rev 1.10/1.00, addr 2 on
 uhub4

 then I do this:


Is the problem the same on -current?

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

Re: Unable to read from CCID USB reader

[Hans Petter Selasky]

On Monday 18 May 2009, Mario Pavlov wrote:
 Hi,
 no I haven't tried it on CURRENT
 should I do that ?
 is there something new in the USB stuff there ?

There is a new USB stack in 8-current and a new libusb which is installed as a 
part of the base system.

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

Re: UPEK/TouchChip Biometric Device problem

[Hans Petter Selasky]

On Friday 22 June 2007 22:42, Patrick Tracanelli wrote:
 Hello all,

 I have used the mentioned devices on FreeBSD 5.4 in the past, and they
 worked just fine, but now I get problems with the same device, on top of
 6.2-STABLE and also 7.0-CURRENT.

  From `usbdevs -v`, I get:

 Controller /dev/usb2:
 addr 1: full speed, self powered, config 1, UHCI root hub(0x),
 Intel(0x), rev 1.00
   port 1 addr 2: full speed, power 100 mA, config 1, Biometric
 Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01
   port 2 powered

 I have security/bsp_upektfmess, security/pam_bsdbioapi and
 security/bioapi installed. It is a 6.2-STABLE system from 2 hours ago.

 Listing bsp devices, I get:

 # bbdm -l bsp
 UUID {----}
   Example Vendor libbioapi_dummy100.so (BioAPI v1.1 Dummy BSP)
 UUID {263a41e0-71eb-11d4-9c34-12403700}
   BioAPI Consortium libpwbsp.so (BioAPI Password BSP)
 UUID {5550454b-2054-464d-2f45-535320425350}
   UPEK, Inc. libtfmessbsp.so (TouchChip TFM/ESS Fingerprint BSP)

 Backend configurations:

 # bbdm -l birdb
 Installed BIRDB modules
 filedb   Filebacked database (b-tree)
 plainPlain text file

 And now, the problem:

 # bbdm -b {5550454b-2054-464d-2f45-535320425350} -m filedb -c eksffa
 bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350}

 And on /var/log/messages as well as dmesg, I get:

 All threads purged from ugen1.1
 All threads purged from ugen1.2
 All threads purged from ugen1.3

 What is this about threads purged? Also, the port want libintl.so.6
 while 6.2-STABLE has libintl.so.8. I have tried 1) linking .8 to .6 and
 also copied .6 from another system (also, 6.2-STABLE) to the current
 one. Didnt work both way. Same behavior, exactly.

 On 7.0-CURRENT things are worse. libpthread is not found, and the same
 command core dumps. Anyway, 6.2-STABLE is more important to me right
 now, since I need this device to work on FreeBSD for an ongoing project,
 but if a solution to 7.0 happens first my work can move to that version.


There is a list called [EMAIL PROTECTED] maybe we can handle this 
issue there.

First of all, can you turn on more debugging in your bbdm?

The default USB kernel is usually not compiled with USB debugging.

There exists an:

options USB_DEBUG

I think.

If you have time you can also try the my new USB stack:

See:

http://www.turbocat.net/~hselasky/usb4bsd/

Download the SVN version.

If my new USB stack solves the problem then it is probably a regression issue 
in 6.2-STABLE, and as I recall there have been lots of changes.

What kind of platform are you using?

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

Re: atacontrol kernel crash (atausb?)

[Hans Petter Selasky]

On Wednesday 24 January 2007 12:38, Ed Schouten wrote:
 Hello,

 * Pietro Cerutti [EMAIL PROTECTED] wrote:
  On 1/15/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
  No. What happens when you use/load umass and unload atausb ?
 
  Everything works nice with umass. It creates the da0 device node.
  It just shows up these errors, as it always did...
  GEOM: new disk da0
  da0 at umass-sim0 bus 0 target 0 lun 0
  da0:  USB2.0 FlashDisk 1.1b Removable Direct Access SCSI-0 device
  da0: Serial Number
  da0: 40.000MB/s transfers
  da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C)
  (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi
  status == 0x0
  (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi
  status == 0x0
  (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi
  status == 0x0
  (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi
  status == 0x0

 I had these messages with two other devices before, an MP3 player and a
 USB floppy drive. I fixed these errors by adding a quirk to
 /sys/cam/scsi/scsi_da.c.

   http://www.freebsd.org/cgi/query-pr.cgi?pr=97174
   http://www.freebsd.org/cgi/query-pr.cgi?pr=107101

Instead of having all these quirks, isn't it possible that the SCSI layer can 
auto-probe this?

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

Re: atacontrol kernel crash (atausb?)

[Hans Petter Selasky]

On Monday 15 January 2007 12:22, Pietro Cerutti wrote:
 Hello,
 this is a reproducible kernel page-fault crash on stable as of 1h ago:

 FreeBSD gahrtop.localhost 6.2-STABLE FreeBSD 6.2-STABLE #4: Mon Jan 15
 11:24:56 CET 2007
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP  i386

 1) atacontrol list
 ATA channel 0:
 Master:  ad0 FUJITSU MHW2120BH/0012 Serial ATA v1.0
 Slave:   no device present
 ATA channel 1:
 Master:  no device present
 Slave:  acd0 HL-DT-ST DVDRAM GSA-T10N/PA02 ATA/ATAPI revision 5

 2) - plug in USB stick (microspot 256MB USB2.0)

 3) atacontrol list
 ATA channel 0:
 Master:  ad0 FUJITSU MHW2120BH/0012 Serial ATA v1.0
 Slave:   no device present
 ATA channel 1:
 Master:  no device present
 Slave:  acd0 HL-DT-ST DVDRAM GSA-T10N/PA02 ATA/ATAPI revision 5
 ATA channel 2:
 Master:  no device present
 Slave:   no device present

 4) atacontrol attach ata2

This is a known issue that SOS should fix. If you look into the code of 
ata_attach() you will see that it tries to do things that are not allowed 
by USB devices, like allocating an IRQ:

int
ata_attach(device_t dev)
{
struct ata_channel *ch = device_get_softc(dev);
int error, rid;

/* check that we have a virgin channel to attach */
if (ch-r_irq)
return EEXIST;

/* initialize the softc basics */
ch-dev = dev;
ch-state = ATA_IDLE;
bzero(ch-state_mtx, sizeof(struct mtx));
mtx_init(ch-state_mtx, ATA state lock, NULL, MTX_DEF);
bzero(ch-queue_mtx, sizeof(struct mtx));
mtx_init(ch-queue_mtx, ATA queue lock, NULL, MTX_DEF);
TAILQ_INIT(ch-ata_queue);

/* reset the controller HW, the channel and device(s) */
while (ATA_LOCKING(dev, ATA_LF_LOCK) != ch-unit)
tsleep(error, PRIBIO, ataatch, 1);
ATA_RESET(dev);
ATA_LOCKING(dev, ATA_LF_UNLOCK);

/* setup interrupt delivery */
rid = ATA_IRQ_RID;
ch-r_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, rid,
   RF_SHAREABLE | RF_ACTIVE);
if (!ch-r_irq) {
device_printf(dev, unable to allocate interrupt\n);
return ENXIO;
}
if ((error = bus_setup_intr(dev, ch-r_irq, ATA_INTR_FLAGS,
(driver_intr_t *)ata_interrupt, ch, ch-ih))) 
{
device_printf(dev, unable to setup interrupt\n);
return error;
}

/* probe and attach devices on this channel unless we are in early boot */
if (!ata_delayed_attach)
ata_identify(dev);
return 0;
}

Same with ata_detach().


 last one: why atausb doesn't have a manual page??

Probably the device driver is too new.

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

Re: atacontrol kernel crash (atausb?)

[Hans Petter Selasky]

On Monday 15 January 2007 15:37, Pietro Cerutti wrote:
 On 1/15/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
   last one: why atausb doesn't have a manual page??
 
  Probably the device driver is too new.

 Maybe we should adopt the OpenBSD's everything not documented is a
 bug philosophy, don't you think?

 So, anyone knows how to use atausb?

It is just plug and play. If you don't get any new USB devices like /dev/adXX 
after that you plug the device, then maybe there is something wrong or the 
protocol used is not supported by atausb.

PS: You maybe want to try out my new and rewritten USB stack + atausb:

#
# How to get the latest sources: (you need subversion installed)
#

svn --username anonsvn --password anonsvn \
  checkout svn://svn.turbocat.net/i4b
#
# The following commands will
# install the driver on FreeBSD:
#
cd i4b/trunk/i4b/FreeBSD.usb
make S=../src package
make install

#
# Then build a new kernel.
#

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

Re: atacontrol kernel crash (atausb?)

[Hans Petter Selasky]

On Monday 15 January 2007 16:54, Pietro Cerutti wrote:
 On 1/15/07, Hans Petter Selasky [EMAIL PROTECTED] wrote:
  It is just plug and play. If you don't get any new USB devices like
  /dev/adXX after that you plug the device, then maybe there is something
  wrong or the protocol used is not supported by atausb.

 This is the only thing showing on the console:

 atausb0: using SCSI over Bulk-Only
 ata2: USB lun 0 on atausb0

 Can you see anything wrong with it?

No. What happens when you use/load umass and unload atausb ?


  PS: You maybe want to try out my new and rewritten USB stack + atausb:

 Tried, nothing changed... what functionality is your patch supposed to add?

No new functionality with regard to atausb.

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

Re: usb to serial

[Hans Petter Selasky]

On Friday 10 November 2006 10:08, Maxim Konovalov wrote:
 Hi Hans,

 On Fri, 10 Nov 2006, 08:38+0100, Hans Petter Selasky wrote:
  On Thursday 09 November 2006 18:29, Maxim Konovalov wrote:
   [ iedowse CC'ed ]
  
   Hello,
  
   On Fri, 5 May 2006, 11:04-0400, David Coder wrote:
thx for the suggestions, guys.  with
   
 device uftdi
 device uplcom
   
in the kernel config the adapter shows up as
   
 ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2
   
no specific com port shows up, however, so i must need something
else.
  
   Alex Rodin have ported uark(4) driver from OpenBSD.  I made code
   cleanup and intergation in the tree.  You can gettest patches for
   HEAD and RELENG_6 there:
  
   http://maxim.int.ru/stuff/uark.diff
   http://maxim.int.ru/stuff/uark.diff.6
  
   Ian, could you please review the patches?
 
  Hi, do you think that you could also port the serial driver to the new
  USB stack, and send me a patch file?
 
  Please see:
 
  http://www.turbocat.net/~hselasky/usb4bsd
 
  Download the SVN version, and type svn diff to generate a patch when
  you are finished. Look at the other serial drivers in my SVN tree, how
  the USB/UCOM stuff is done.

 Are there any correlations with p4://depot/projects/usb?

Yes, it is the same.


 The second question: is it OK to commit uark(4) as is and then convert
 it to the new model?

I would prefer no. It is better to commit uark(4) to the USB p4 project, 
than HEAD, because then we don't have to worry about integrating the driver.

I looked at your uark.diff, and it shouldn't be too difficult to port it to 
the new USB architecture.

Have a look at ufoma.c:

http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ufoma.c

From what I can see you need to:

Make a config thread, from where you do the configuration. You should not call 
usbd_do_request() directly from the ucom callbacks!

Add config for the USB BULK transfers needed.

And a little more.

Do you have hardware that you can test the UARK driver with?

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

Re: usb to serial

[Hans Petter Selasky]

On Thursday 09 November 2006 18:29, Maxim Konovalov wrote:
 [ iedowse CC'ed ]

 Hello,

 On Fri, 5 May 2006, 11:04-0400, David Coder wrote:
  thx for the suggestions, guys.  with
 
   device uftdi
   device uplcom
 
  in the kernel config the adapter shows up as
 
   ugen0: ArkMicroChips USB-UART Controller, rev 1.10/0.01, addr 2
 
  no specific com port shows up, however, so i must need something else.

 Alex Rodin have ported uark(4) driver from OpenBSD.  I made code
 cleanup and intergation in the tree.  You can gettest patches for
 HEAD and RELENG_6 there:

 http://maxim.int.ru/stuff/uark.diff
 http://maxim.int.ru/stuff/uark.diff.6

 Ian, could you please review the patches?


Hi, do you think that you could also port the serial driver to the new USB 
stack, and send me a patch file?

Please see:

http://www.turbocat.net/~hselasky/usb4bsd

Download the SVN version, and type svn diff to generate a patch when you are 
finished. Look at the other serial drivers in my SVN tree, how the USB/UCOM 
stuff is done.

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

Re: Problems with Mitsumi 7-in-1 USB Card Reader/Floppy combo

[Hans Petter Selasky]

On Tuesday 05 September 2006 03:16, Indigo 23 wrote:
 Thanks for the reply.  I already tried that, but unfortunetly the same
 thing happens :(
 Any other suggestions?

Maybe you want to try my new Giant free USB driver:

#
# How to install the new USB driver:
#

#
# First get all the sources 
# (you need /usr/ports/devel/subversion installed):
#

svn --username anonsvn --password anonsvn \
  checkout svn://svn.turbocat.net/i4b

#
# The following commands will
# install the driver on FreeBSD 6.x/7.x:
#

cd i4b/trunk/i4b/FreeBSD.usb
make S=../src package
make install

#
# Then build a new kernel (with modules)
#

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

Re: Problems with Mitsumi 7-in-1 USB Card Reader/Floppy combo

[Hans Petter Selasky]

On Tuesday 05 September 2006 13:28, Indigo 23 wrote:
 Thanks for that excellent suggestion.  It worked perfectly.  I just
 have a few questions.

 1) Any idea when this will be imported in to RELENG_6?

I don't know. If I am right, you will see my driver in freebsd-current some 
time after Christmas.

 2) I have to do this everytime I update my sources, correct?

Yes.

 3) This is relatively stable, correct?  (I did test it out a bit, but
 of course not thorougly enough to see how stable it is)

Yes, it is stable, but be aware that if your system runs low on memory, you 
can get a panic saying, sleeping with mutex XXX locked, or something alike. 
That is because the umass device driver is still under the USB emulation 
layer of the old USB API, which is depreciated, and will be removed once I 
have completed the conversion of all USB device drivers. This will most 
likely happen before the end of this month. Then I need some help testing all 
the rewritten USB device drivers.

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