sr-iov issues, reset_hw() failed with error -100

2016-02-20 Thread Ultima
 Decided to do some testing with iovctl to see how sr-iov is coming along.
Currently when adding the vf's there are a couple errors, and the network
no longer function after iovctl is started. My guess is the reset_hw() call
that is failing. Any ideas why this call would fail? I tested this on both
ports, ix1 is detached and unused for this test, however inserting a cable
results in an unusable port. iovctl -Dd ix1 removes the vf's, however
functionality is still not restored without a system restart.

FreeBSD S1 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295736: Wed Feb 17
21:17:28 EST 2016 root@S1:/usr/obj/usr/src/sys/MYKERNEL  amd64

/boot/loader.conf
hw.ix.num_queues="4"

/etc/iovctl.conf
PF {
device : ix1;
num_vfs : 31;
}

DEFAULT {
passthrough : true;
}
VF-0 {
passthrough : false;
}
VF-1 {
passthrough : false;
}

# iovctl -C -f /etc/iovctl.conf

dmesg
ixv0:  at device 0.129 on pci12
ixv0: Using MSIX interrupts with 2 vectors
ixv0: ixgbe_reset_hw() failed with error -100
device_attach: ixv0 attach returned 5
ixv0:  at device 0.131 on pci12
ixv0: Using MSIX interrupts with 2 vectors
ixv0: ixgbe_reset_hw() failed with error -100
device_attach: ixv0 attach returned 5
pci12:  at device 0.133 (no driver attached)
pci12:  at device 0.135 (no driver attached)
pci12:  at device 0.137 (no driver attached)
pci12:  at device 0.139 (no driver attached)
pci12:  at device 0.141 (no driver attached)
pci12:  at device 0.143 (no driver attached)
pci12:  at device 0.145 (no driver attached)
pci12:  at device 0.147 (no driver attached)
pci12:  at device 0.149 (no driver attached)
pci12:  at device 0.151 (no driver attached)
pci12:  at device 0.153 (no driver attached)
pci12:  at device 0.155 (no driver attached)
pci12:  at device 0.157 (no driver attached)
pci12:  at device 0.159 (no driver attached)
pci12:  at device 0.161 (no driver attached)
pci12:  at device 0.163 (no driver attached)
pci12:  at device 0.165 (no driver attached)
pci12:  at device 0.167 (no driver attached)
pci12:  at device 0.169 (no driver attached)
pci12:  at device 0.171 (no driver attached)
pci12:  at device 0.173 (no driver attached)
pci12:  at device 0.175 (no driver attached)
pci12:  at device 0.177 (no driver attached)
pci12:  at device 0.179 (no driver attached)
pci12:  at device 0.181 (no driver attached)
pci12:  at device 0.183 (no driver attached)
pci12:  at device 0.185 (no driver attached)
pci12:  at device 0.187 (no driver attached)
pci12:  at device 0.189 (no driver attached)

pciconf -lv
ix1@pci0:129:0:1:   class=0x02 card=0x1458 chip=0x15288086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10-Gigabit X540-AT2'
class  = network
subclass   = ethernet
none155@pci0:129:0:129: class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
none156@pci0:129:0:131: class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt0@pci0:129:0:133:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt1@pci0:129:0:135:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt2@pci0:129:0:137:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt3@pci0:129:0:139:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt4@pci0:129:0:141:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt5@pci0:129:0:143:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt6@pci0:129:0:145:class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class  = network
subclass   = ethernet
ppt7@pci0:129:0:147:class=0x02 card=0x1458 chip=0x15158086
rev=0

Re: Realtek MMC/MMCSD reader?

2016-02-20 Thread Kevin Lo
On Fri, Feb 19, 2016 at 11:25:45PM -0500, Gary Corcoran wrote:
> 
> On 2/19/2016 11:08 PM, Larry Rosenman wrote:
> > On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote:
> >> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman  wrote:
> >>
> >>> Great.  Since I've never done that
> >>>
> >>> Any ideas of anyone that might be able to help?
> >>>
> >>> Or where to even start?
> >>>
> >>>
> >>>
> >>
> >>
> >> Perhaps
> >>
> >> https://www.nostarch.com/bsddrivers.htm
> >> FreeBSD Device Drivers
> >>
> >>
> >> ?
> >>
> >>
> >> Mehmet Erol Sanliturk
> >>
> >>
> > perhaps.  But I'd need an NDA with RealTek to get the chip specs, and I'm 
> > not sure I can do that working for Nokia during the day
> > as I do.
> >
> > I'd love for one of the current folks that do realtek stuff to look.
> Sometimes people look to see if Linux has a driver, and if so, you might be 
> able to get enough
> programming info from their driver to be able to write a FreeBSD driver, 
> without getting the
> full chip specs.

Or do a port of the OpenBSD's rtsx(4).

> Gary

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


HWPMC on SkyLake

2016-02-20 Thread Larry Rosenman

Is there anything I can do to help:

hwpc_core: unknown PMC architecture: 4
hwpmc: SOFT/16/64/0x67

CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class 
CPU)

  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7ffafbbf

  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended 
Features=0x29c6fbf

  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


LOR: ZFS/syncer: on mount of msdosfs

2016-02-20 Thread Larry Rosenman

Is this a known LOR:
lock order reversal:
 1st 0xf801d20ea5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xf801d2fe6418 syncer (syncer) @ 
/usr/src/sys/kern/vfs_subr.c:2618

stack backtrace:
#0 0x80a7f810 at witness_debugger+0x70
#1 0x80a7f711 at witness_checkorder+0xe71
#2 0x809fe5cb at __lockmgr_args+0xd3b
#3 0x80ac525c at vop_stdlock+0x3c
#4 0x80fbd640 at VOP_LOCK1_APV+0x100
#5 0x80ae5f2a at _vn_lock+0x9a
#6 0x80ad6c38 at vputx+0x208
#7 0x80aceaf0 at dounmount+0x410
#8 0x80ace64d at sys_unmount+0x35d
#9 0x80e6e15b at amd64_syscall+0x2db
#10 0x80e4dd4b at Xfast_syscall+0xfb
lock order reversal:
 1st 0xf801d20ea5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xf801d2fe65f0 devfs (devfs) @ 
/usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994

stack backtrace:
#0 0x80a7f810 at witness_debugger+0x70
#1 0x80a7f711 at witness_checkorder+0xe71
#2 0x809fe5cb at __lockmgr_args+0xd3b
#3 0x80ac525c at vop_stdlock+0x3c
#4 0x80fbd640 at VOP_LOCK1_APV+0x100
#5 0x80ae5f2a at _vn_lock+0x9a
#6 0x809075a3 at msdosfs_sync+0x193
#7 0x80acebc9 at dounmount+0x4e9
#8 0x80ace64d at sys_unmount+0x35d
#9 0x80e6e15b at amd64_syscall+0x2db
#10 0x80e4dd4b at Xfast_syscall+0xfb

$ uname -a
FreeBSD lrosenman-dell 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r295833M: 
Sat Feb 20 06:13:34 CST 2016 
root@lrosenman-dell:/usr/obj/usr/src/sys/GENERIC  amd64

$


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: new computer, strange usb messages at boot

2016-02-20 Thread Larry Rosenman
On Sat, Feb 20, 2016 at 02:04:01PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 19, 2016 at 11:19:51PM -0600, Larry Rosenman wrote:
> > Does any of this look weird?  What can I provide to help?
> 
> > Sleeping on "acmtx" with the following non-sleepable locks held:
> > exclusive sleep mutex intr sources (intr sources) r = 0 
> > (0x81c7f630) locked @ /usr/src/sys/x86/x86/intr_machdep.c:549
> > stack backtrace:
> > #0 0x80a7f790 at witness_debugger+0x70
> > #1 0x80a80aa7 at witness_warn+0x3d7
> > #2 0x80a2e26d at _sleep+0x6d
> > #3 0x80399ff8 at AcpiOsAcquireMutex+0xc8
> > #4 0x8036891a at AcpiUtAcquireMutex+0x3a
> > #5 0x80355f2b at AcpiExEnterInterpreter+0xb
> > #6 0x8035a2fb at AcpiNsEvaluate+0x1cb
> > #7 0x8035d7b4 at AcpiEvaluateObject+0x174
> > #8 0x8039ac0d at acpi_GetInteger+0x3d
> > #9 0x80f94c01 at dmar_find_hpet+0x81
> > #10 0x80f9d54d at iommu_map_msi_intr+0x2d
> > #11 0x80fb2f91 at msi_map+0x171
> > #12 0x80e73035 at hpet_remap_intr+0xb5
> > #13 0x80fb2627 at msi_assign_cpu+0x1c7
> > #14 0x80fa9733 at intr_shuffle_irqs+0x73
> > #15 0x809c3a38 at mi_startup+0x108
> > #16 0x802fb02c at btext+0x2c
> > lock order reversal: (Giant after non-sleepable)
> >  1st 0x81c7f630 intr sources (intr sources) @ 
> > /usr/src/sys/x86/x86/intr_machdep.c:549
> >  2nd 0x81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244
> > stack backtrace:
> > #0 0x80a7f790 at witness_debugger+0x70
> > #1 0x80a7f691 at witness_checkorder+0xTrying to mount root from 
> > zfs:zroot/ROOT/default []...
> > e71
> > #2 0x80a06f94 at __mtx_lock_flags+0xa4
> > #3 0x80a2e5ba at _sleep+0x3ba
> > #4 0x80399ff8 at AcpiOsAcquireMutex+0xc8
> > #5 0x8036891a at AcpiUtAcquireMutex+0x3a
> > #6 0x80355f2b at AcpiExEnterInterpreter+0xb
> > #7 0x8035a2fb at AcpiNsEvaluate+0x1cb
> > #8 0x8035d7b4 at AcpiEvaluateObject+0x174
> > #9 0x8039ac0d at acpi_GetInteger+0x3d
> > #10 0x80f94c01 at dmar_find_hpet+0x81
> > #11 0x80f9d54d at iommu_map_msi_intr+0x2d
> > #12 0x80fb2f91 at msi_map+0x171
> > #13 0x80e73035 at hpet_remap_intr+0xb5
> > #14 0x80fb2627 at msi_assign_cpu+0x1c7
> > #15 0x80fa9733 at intr_shuffle_irqs+0x73
> > #16 0x809c3a38 at mi_startup+0x108
> > #17 0x802fb02c at btext+0x2c
> 
> For these two LORs, please try the following patch. Apparently
> acpi_GetInteger() might get acpi lock.  Patch also modernizes /dev/hpet
> creation.
> 
> Just patch and boot, the LOR messages should go away as the only change
> in behaviour.

Applied, and it does seem to fix the LOR:

Copyright (c) 1992-2016 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.0-CURRENT #1 r295833M: Sat Feb 20 06:13:34 CST 2016
root@lrosenman-dell:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 2048x1200
CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.13-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended 
Features=0x29c6fbf
  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16396095488 (15636 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
random: unblocking device.
ioapic0  irqs 0-119 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80ee1ea0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 2400 Hz quality 950
Event timer "HPET" frequency 2400 Hz quality 550
atrtc0:  port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i825

Re: new computer, strange usb messages at boot

2016-02-20 Thread Larry Rosenman
On Sat, Feb 20, 2016 at 10:25:31AM +0100, Hans Petter Selasky wrote:
> On 02/20/16 06:19, Larry Rosenman wrote:
> > ugen0.2:  at usbus0
> > Root mount waiting for: usbus0
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_IOERROR
> > Root mount waiting for: usbus0
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_IOERROR
> > Root mount waiting for: usbus0
> > Root mount waiting for: usbus0
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_IOERROR
> > Root mount waiting for: usbus0
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_IOERROR
> > Root mount waiting for: usbus0
> > Root mount waiting for: usbus0
> > usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
> > USB_ERR_IOERROR
> 
> Hi,
> 
> Looks like there is an error enumerating one of the USB devices. It is 
> harmless.
> 
> What does "pciconf -lv" say about your USB controllers?
> 
> --HPS

Here is the full pciconf -lv:

hostb0@pci0:0:0:0:  class=0x06 card=0x07061028 chip=0x19108086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sky Lake Host Bridge/DRAM Registers'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 card=0x20158086 chip=0x19018086 rev=0x07 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sky Lake PCIe Controller (x16)'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 card=0x07061028 chip=0x19058086 rev=0x07 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sky Lake PCIe Controller (x8)'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0: class=0x03 card=0x07061028 chip=0x191b8086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 card=0x07061028 chip=0x19038086 rev=0x07 
hdr=0x00
vendor = 'Intel Corporation'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 card=0x07061028 chip=0xa12f8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H USB 3.0 xHCI Controller'
class  = serial bus
subclass   = USB
none1@pci0:0:20:2:  class=0x118000 card=0x07061028 chip=0xa1318086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H Thermal subsystem'
class  = dasp
none2@pci0:0:21:0:  class=0x118000 card=0x07061028 chip=0xa1608086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPSS I2C Controller'
class  = dasp
none3@pci0:0:22:0:  class=0x078000 card=0x07061028 chip=0xa13a8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H CSME HECI'
class  = simple comms
ahci0@pci0:0:23:0:  class=0x010601 card=0x07061028 chip=0xa1038086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SATA Controller [AHCI mode]'
class  = mass storage
subclass   = SATA
pcib3@pci0:0:28:0:  class=0x060400 card=0x07061028 chip=0xa1108086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 card=0x07061028 chip=0xa1148086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 card=0x07061028 chip=0xa1158086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 card=0x07061028 chip=0xa1168086 rev=0xf1 
hdr=0x01
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 card=0x07061028 chip=0xa14e8086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H LPC Controller'
class  = bridge
subclass   = PCI-ISA
none4@pci0:0:31:2:  class=0x058000 card=0x07061028 chip=0xa1218086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H PMC'
class  = memory
hdac0@pci0:0:31:3:  class=0x040300 card=0x07061028 chip=0xa1708086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H HD Audio'
class  = multimedia
subclass   = HDA
none5@pci0:0:31:4:  class=0x0c0500 card=0x07061028 chip=0xa1238086 rev=0x31 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Sunrise Point-H SMBus'
class  = serial bus
subclass   = SMBus
vgapci0@pci0:2:0:0: class=0x030200 card=0x07061028 chip=0x139b10de rev

Re: new computer, strange usb messages at boot

2016-02-20 Thread Konstantin Belousov
On Fri, Feb 19, 2016 at 11:19:51PM -0600, Larry Rosenman wrote:
> Does any of this look weird?  What can I provide to help?

> Sleeping on "acmtx" with the following non-sleepable locks held:
> exclusive sleep mutex intr sources (intr sources) r = 0 (0x81c7f630) 
> locked @ /usr/src/sys/x86/x86/intr_machdep.c:549
> stack backtrace:
> #0 0x80a7f790 at witness_debugger+0x70
> #1 0x80a80aa7 at witness_warn+0x3d7
> #2 0x80a2e26d at _sleep+0x6d
> #3 0x80399ff8 at AcpiOsAcquireMutex+0xc8
> #4 0x8036891a at AcpiUtAcquireMutex+0x3a
> #5 0x80355f2b at AcpiExEnterInterpreter+0xb
> #6 0x8035a2fb at AcpiNsEvaluate+0x1cb
> #7 0x8035d7b4 at AcpiEvaluateObject+0x174
> #8 0x8039ac0d at acpi_GetInteger+0x3d
> #9 0x80f94c01 at dmar_find_hpet+0x81
> #10 0x80f9d54d at iommu_map_msi_intr+0x2d
> #11 0x80fb2f91 at msi_map+0x171
> #12 0x80e73035 at hpet_remap_intr+0xb5
> #13 0x80fb2627 at msi_assign_cpu+0x1c7
> #14 0x80fa9733 at intr_shuffle_irqs+0x73
> #15 0x809c3a38 at mi_startup+0x108
> #16 0x802fb02c at btext+0x2c
> lock order reversal: (Giant after non-sleepable)
>  1st 0x81c7f630 intr sources (intr sources) @ 
> /usr/src/sys/x86/x86/intr_machdep.c:549
>  2nd 0x81cd4d60 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:244
> stack backtrace:
> #0 0x80a7f790 at witness_debugger+0x70
> #1 0x80a7f691 at witness_checkorder+0xTrying to mount root from 
> zfs:zroot/ROOT/default []...
> e71
> #2 0x80a06f94 at __mtx_lock_flags+0xa4
> #3 0x80a2e5ba at _sleep+0x3ba
> #4 0x80399ff8 at AcpiOsAcquireMutex+0xc8
> #5 0x8036891a at AcpiUtAcquireMutex+0x3a
> #6 0x80355f2b at AcpiExEnterInterpreter+0xb
> #7 0x8035a2fb at AcpiNsEvaluate+0x1cb
> #8 0x8035d7b4 at AcpiEvaluateObject+0x174
> #9 0x8039ac0d at acpi_GetInteger+0x3d
> #10 0x80f94c01 at dmar_find_hpet+0x81
> #11 0x80f9d54d at iommu_map_msi_intr+0x2d
> #12 0x80fb2f91 at msi_map+0x171
> #13 0x80e73035 at hpet_remap_intr+0xb5
> #14 0x80fb2627 at msi_assign_cpu+0x1c7
> #15 0x80fa9733 at intr_shuffle_irqs+0x73
> #16 0x809c3a38 at mi_startup+0x108
> #17 0x802fb02c at btext+0x2c

For these two LORs, please try the following patch. Apparently
acpi_GetInteger() might get acpi lock.  Patch also modernizes /dev/hpet
creation.

Just patch and boot, the LOR messages should go away as the only change
in behaviour.

diff --git a/sys/dev/acpica/acpi_hpet.c b/sys/dev/acpica/acpi_hpet.c
index 1b5a161..76fbd5a 100644
--- a/sys/dev/acpica/acpi_hpet.c
+++ b/sys/dev/acpica/acpi_hpet.c
@@ -85,6 +85,7 @@ struct hpet_softc {
struct resource *intr_res;
void*intr_handle;
ACPI_HANDLE handle;
+   uint32_tacpi_uid;
uint64_tfreq;
uint32_tcaps;
struct timecounter  tc;
@@ -295,6 +296,15 @@ hpet_intr(void *arg)
return (FILTER_STRAY);
 }
 
+uint32_t
+hpet_get_uid(device_t dev)
+{
+   struct hpet_softc *sc;
+
+   sc = device_get_softc(dev);
+   return (sc->acpi_uid);
+}
+
 static ACPI_STATUS
 hpet_find(ACPI_HANDLE handle, UINT32 level, void *context,
 void **status)
@@ -422,8 +432,9 @@ hpet_attach(device_t dev)
 {
struct hpet_softc *sc;
struct hpet_timer *t;
+   struct make_dev_args mda;
int i, j, num_msi, num_timers, num_percpu_et, num_percpu_t, cur_cpu;
-   int pcpu_master;
+   int pcpu_master, error;
static int maxhpetet = 0;
uint32_t val, val2, cvectors, dvectors;
uint16_t vendor, rev;
@@ -745,11 +756,16 @@ hpet_attach(device_t dev)
maxhpetet++;
}
}
-
-   sc->pdev = make_dev(&hpet_cdevsw, 0, UID_ROOT, GID_WHEEL,
-   0600, "hpet%d", device_get_unit(dev));
-   if (sc->pdev) {
-   sc->pdev->si_drv1 = sc;
+   acpi_GetInteger(sc->handle, "_UID", &sc->acpi_uid);
+
+   make_dev_args_init(&mda);
+   mda.mda_devsw = &hpet_cdevsw;
+   mda.mda_uid = UID_ROOT;
+   mda.mda_gid = GID_WHEEL;
+   mda.mda_mode = 0600;
+   mda.mda_si_drv1 = sc;
+   error = make_dev_s(&mda, &sc->pdev, "hpet%d", device_get_unit(dev));
+   if (error == 0) {
sc->mmap_allow = 1;
TUNABLE_INT_FETCH("hw.acpi.hpet.mmap_allow",
&sc->mmap_allow);
@@ -766,9 +782,10 @@ hpet_attach(device_t dev)
OID_AUTO, "mmap_allow_write",
CTLFLAG_RW, &sc->mmap_allow_write, 0,
"Allow userland write to the HPET register space");
-   } else
-   device_printf(dev, "could not create /dev/hpet%d\n",
-   device_get_unit(dev));
+   } else {
+   device_printf(dev, "could not create /dev/hpet%d, error %

Re: Possible bug in bc(1)

2016-02-20 Thread Wolfgang Petzold
Hi,

actually, if you "ignore \ within numbers", your
input reads 2*12*1, doesn't it?

W.

Am 20.02.2016 um 12:07 schrieb Ruslan Makhmatkhanov:
> Hello,
> 
> I'm getting strange result with something looking like valid data:
> 
> [rm@smsh-zfs ~]> bc
> 2*1\
> 2*1
> 24
> 
> I'd expect the output being like that:
> 2*1\
> 2
> 2*1
> 2
> 
> What I see in bc(1) man-page regarding to backslash is:
> "The sequence ‘\’ is ignored within numbers."
> 
> So looks like it doesn't actually ignored or I missing something?
> 
> Thanks for clarification.
> 

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

Re: [Bug 207366] openssh do not generate dsa host key by default

2016-02-20 Thread Jov
fyi
2016年2月20日 7:13 PM, 写道:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207366
>
> Bug ID: 207366
>Summary: openssh do not generate dsa host key by default
>Product: Base System
>Version: 11.0-CURRENT
>   Hardware: arm
> OS: Any
> Status: New
>   Severity: Affects Some People
>   Priority: ---
>  Component: arm
>   Assignee: freebsd-...@freebsd.org
>   Reporter: am...@amutu.com
>
> /var/log/message error:
> sshd[779]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
>
> root@rpi-b:~/.ssh # uname -a
> FreeBSD rpi-b 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17
> 10:21:45
> UTC 2016 r...@releng2.nyi.freebsd.org:
> /usr/obj/arm.armv6/usr/src/sys/RPI-B
> arm
> root@rpi-b:~/.ssh # ssh -V
> OpenSSH_7.1p2, OpenSSL 1.0.2f-freebsd  28 Jan 2016
>
> r294912 do not have this problem,ant the openssh version is 1.0.2e:
> root@fbpi2:~ # uname -a
> FreeBSD pi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294912: Thu Jan 28
> 02:05:30
> UTC 2016 r...@releng2.nyi.freebsd.org:
> /usr/obj/arm.armv6/usr/src/sys/RPI2
> arm
> root@pi2:~ # ssh -V
> OpenSSH_7.1p2, OpenSSL 1.0.2e-freebsd 3 Dec 2015
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Possible bug in bc(1)

2016-02-20 Thread Ruslan Makhmatkhanov

Hello,

I'm getting strange result with something looking like valid data:

[rm@smsh-zfs ~]> bc
2*1\
2*1
24

I'd expect the output being like that:
2*1\
2
2*1
2

What I see in bc(1) man-page regarding to backslash is:
"The sequence ‘\’ is ignored within numbers."

So looks like it doesn't actually ignored or I missing something?

Thanks for clarification.

--
Regards,
Ruslan

T.O.S. Of Reality
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Realtek MMC/MMCSD reader?

2016-02-20 Thread Gary Jennejohn
On Fri, 19 Feb 2016 23:02:26 -0600
Larry Rosenman  wrote:

> On 2016-02-19 22:25, Gary Corcoran wrote:
> > On 2/19/2016 11:08 PM, Larry Rosenman wrote:  
> >> On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote:  
> >>> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman  
> >>> wrote:
> >>>   
>  Great.  Since I've never done that
>  
>  Any ideas of anyone that might be able to help?
>  
>  Or where to even start?
>  
>  
>    
> >>> 
> >>> 
> >>> Perhaps
> >>> 
> >>> https://www.nostarch.com/bsddrivers.htm
> >>> FreeBSD Device Drivers
> >>> 
> >>> 
> >>> ?
> >>> 
> >>> 
> >>> Mehmet Erol Sanliturk
> >>> 
> >>>   
> >> perhaps.  But I'd need an NDA with RealTek to get the chip specs, and 
> >> I'm not sure I can do that working for Nokia during the day
> >> as I do.
> >> 
> >> I'd love for one of the current folks that do realtek stuff to look.  
> > Sometimes people look to see if Linux has a driver, and if so, you
> > might be able to get enough
> > programming info from their driver to be able to write a FreeBSD
> > driver, without getting the
> > full chip specs.
> > 
> > Gary
> >   
> http://askubuntu.com/questions/731093/sd-card-reader-realtek-522a-not-working-in-dell-i7559-in-ubuntu-15-10
> 
> I'm still VERY much a newbie (like ZERO experience) writing drivers.
> 
> Does anyone want to help?
> 
> I'm more than willing to guinea pig stuff.
> 

Looking at the patch some non-trivial changes were made to the driver.
It's hard to tell whether most of them were meant to make the driver
more flexible, or whether they were really added to support this
device.

That said, a number of device-specific commands and at least one new
function were added just for this.

Whether these changes can easily be implemented in the FBSD code I
can't answer without investing more time.

There's also the point that any programmer willing to help may need
the hardware.  Blindly making changes to a driver in the hope they
might work isn't exactly good practice.

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


Re: new computer, strange usb messages at boot

2016-02-20 Thread Hans Petter Selasky

On 02/20/16 06:19, Larry Rosenman wrote:

ugen0.2:  at usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR


Hi,

Looks like there is an error enumerating one of the USB devices. It is 
harmless.


What does "pciconf -lv" say about your USB controllers?

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