Maxime Villard | 28 Aug 11:17 2015
Picon

Brainy: some bugs

Hi,
I've added some bugs here:

	http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Unsorted-4

I don't have time to investigate, review and fix them. They don't seem all
easy to fix, so please make sure you can test/carefully review your changes,
as usual. Below is a summary, in case it inspires someone:

_09/ DOUBLE RUNTIME BRANCH: sys/arch/arm/arm/cpufunc.c
_10/ MEMORY LEAK: sys/net/if_ieee1394subr.c
_11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c
_12/ USE-AFTER-FREE: sys/arch/mips/alchemy/dev/aupcmcia.c
_13/ MEMORY LEAK: sys/dev/ic/smc91cxx.c
_14/ UNINITIALIZED VAR: sys/compat/linux/common/linux_futex.c
_15/ MEMORY LEAK: sys/arch/acorn26/ioc/arcpp.c
_16/ MEMORY LEAK: sys/dev/pci/cxgb/cxgb_l2t.c
_17/ MEMORY LEAK: sys/dev/ic/gem.c
_18/ MEMORY LEAK: sys/dev/ic/rrunner.c
_19/ USE-AFTER-FREE: sys/dev/ic/rrunner.c
_20/ MEMORY LEAK: sys/dev/spi/spiflash.c
_21/ USE-AFTER-FREE: sys/dev/ic/daic.c

Maxime

Maxime Villard | 28 Aug 11:20 2015
Picon

Small bug with offline cpus

Hi,
a bug I must have spotted some weeks ago: the kernel decrements the
number of offline cpus even when trying to shutting down one fails.
How to reproduce:

	# schedctl -p SOME_RANDOM_PROC_PID -A 0
	# sysctl hw.ncpuonline
	# cpuctl offline 0     (it fails)
	# sysctl hw.ncpuonline (one cpu missing)

If you cpuctl too much, the value goes negative. This is not a harmful
bug.

Index: kern_cpu.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_cpu.c,v
retrieving revision 1.70
diff -u -r1.70 kern_cpu.c
--- kern_cpu.c	20 Aug 2015 09:45:45 -0000	1.70
+++ kern_cpu.c	28 Aug 2015 08:51:36 -0000
 <at>  <at>  -444,7 +444,6  <at>  <at> 
 		if ((spc->spc_flags & SPCF_OFFLINE) == 0)
 			return 0;
 		func = (xcfunc_t)cpu_xc_online;
-		ncpuonline++;
 	} else {
 		if ((spc->spc_flags & SPCF_OFFLINE) != 0)
 			return 0;
 <at>  <at>  -463,16 +462,19  <at>  <at> 
 		if (nonline == 1)
(Continue reading)

Takahiro Hayashi | 28 Aug 09:23 2015
Picon

[patch] xhci patch 20150827

Hello,

Here is xhci patch for nick-nhusb branch.

sys/dev/usb/xhci.c
sys/dev/usb/xhcivar.h
sys/dev/pci/xhci_pci.c
	+ Use usbd_xfer_isread().
	+ Change mutex to be initialized at IPL_USB.
	+ Add vendor init/portsc hook.
	+ Modify xhci_trb_put() to take host byte order arguments and
	  convert them to little endian byte order.
	+ Return PCI vendor ID of xhci instead of NetBSD(0x0) as a root hub
	  vendor ID like other HCs do.
	+ Move sc_ih in struct xhci_softc to struct xhci_pci_softc.
	+ Improve debug message.
sys/dev/pci/ehci_pci.c
	+ Unmap busspace/intr if initialization fails.

--

-- 
t-hash
--- sys/dev/usb/xhci.c.orig	2015-06-27 01:08:34.000000000 +0900
+++ sys/dev/usb/xhci.c	2015-08-27 07:50:23.000000000 +0900
 <at>  <at>  -493,9 +493,9  <at>  <at>  static inline void
 xhci_trb_put(struct xhci_trb * const trb, uint64_t parameter, uint32_t status,
     uint32_t control)
 {
-	trb->trb_0 = parameter;
(Continue reading)

Ryo ONODERA | 21 Aug 02:13 2015
Picon

Why kc_bitsize is zero?

Hi,

I am trying to run NetBSD/evbarm GUMSTIX kernel on qemu-system-arm -M connex,
emulated Gumstix Connex.
qemu's PXA255 CPU emulation is incorrect and qemu-pxa255.diff should be
applied (for qemu master).
http://www.netbsd.org/~ryoon/20150821-on-qemu-connex/qemu-pxa255.diff

And GUMSTIX kernel should be applied connex-on-qemu.diff patch
(for NetBSD current).
http://www.netbsd.org/~ryoon/20150821-on-qemu-connex/connex-on-qemu.diff

oarm kernel starts as
$ ~/repos/qemu/arm-softmmu/qemu-system-arm -M connex -drive if=pflash,file=./flash,format=raw
-nographic -drive if=sd,file=sd2.img,format=raw
main-loop: WARNING: I/O thread spun for 1000 iterations
pxa2xx_clkcfg_write: CPU frequency change attempt

U-Boot 1.2.0 (May 10 2008 - 13:33:03) - 400 MHz - 1604

*** Welcome to Gumstix ***

DRAM:  64 MB
Flash: 16 MB
Using default environment

SMC91C1111-0
Net:   SMC91C1111-0
Hit any key to stop autoboot:  0
GUM> cp.l b00000 a0200000 3bd35c
(Continue reading)

David Brownlee | 20 Aug 15:41 2015

Changing default CHILD_MAX and OPEN_MAX for all ports

A while back mrg updated some of the ports most likely to be running
on bigger machines to have a larger CHILD_MAX and OPEN_MAX (160=>1024
and 128=>1024 respectively). That was amd64, aarch64, evbarm,
evbarm64, i386 & sparc64.

I think it would make sense to set the defaults for all ports to the
higher value and then if anyone has a need to override it down for a
specific environment they can go ahead.

If anything there is an argument for autosizing them based on the
memory in a machine, but that might violate the POLS :)

What do people think?

On 7 May 2015 at 20:14, matthew green <mrg <at> netbsd.org> wrote:
> Module Name:    src
> Committed By:   mrg
> Date:           Thu May  7 19:14:56 UTC 2015
>
> Modified Files:
>         src/sys/arch/aarch64/conf: std.aarch64
>         src/sys/arch/amd64/conf: std.amd64
>         src/sys/arch/evbarm/conf: std.evbarm
>         src/sys/arch/evbarm64/conf: std.evbarm64
>         src/sys/arch/i386/conf: std.i386
>         src/sys/arch/sparc64/conf: std.sparc64 std.sparc64-32
>
> Log Message:
> bump CHILD_MAX and OPEN_MAX defaults on several platforms, both to 1024.
>
(Continue reading)

Paul Goyette | 20 Aug 12:13 2015

option P1003_1B_SEMAPHORE

There are three man pages that reference P1003_1B_SEMAPHORE, including 
options(4).

 	# cd $SRCDIR && find . -printx | xargs grep P1003_1B_SEMAPHORE
 	./lib/libc/gen/sysconf.3:.Li P1003_1B_SEMAPHORE
 	./share/man/man4/options.4:.It Cd options P1003_1B_SEMAPHORE
 	./share/man/man4/sem.4:.Cd "options P1003_1B_SEMAPHORE"

Yet there is no reference to this option in any other file.

Is there any reason why these man pages should continue to refer to this 
non-existent option?  Or can I go ahead and clean them up?

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

Ryota Ozaki | 17 Aug 11:23 2015
Picon

Restructuring ARP cache

Hi,

Here is a new patch that restructures ARP caches, which
aims for MP-safe network stack:
http://www.netbsd.org/~ozaki-r/lltable-arpcache.diff
(https://github.com/ozaki-r/netbsd-src/tree/lltable-arpcache)

The patch replaces old llinfo for ARP caches with
lltable/llentry derived from FreeBSD.

Highlights of the patch are:
- Import lltable/llentry from FreeBSD
- Use llentry instead of llinfo to manage ARP caches
  - ARP specific data are stored in the hashed list
    of an interface instead of the global list (llinfo_arp)
- Fine-grain locking on llentry
- arptimer (callout) per ARP cache
  - the global timer callout with the big locks can be
    removed (though softnet_lock is still required for now)
- net.inet.arp.prune is removed
  - it is the interval of the global timer callout
- net.inet.arp.refresh is removed
  - it is a parameter that prevents expiration of active caches
  - Removed to simplify the timer logic, but we may be able to
    restore the feature if really needed

One aim of the changes is to proceed the nexthop cache
separation that was raised in the thread "Improving use
of rt_refcnt", although the routing table is not changed
by this patch. I'll proceed it if we have consensus on
(Continue reading)

Masanobu SAITOH | 13 Aug 07:16 2015

Tester(s) needed: ixv(4)

 Hi, all.

 I've commited change to support ixv(4), Intel 10G Ethernet's virtual
function. The reason why this driver had not been compilable is that
it supports MSI-X only.

 Currently, I have not environment to test this driver. Could some
people who are familiar with it test with the latest -current
(and fix bugs)?

 Regards.

--

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh <at> execsw.org
                                 msaitoh <at> netbsd.org)

John Klos | 13 Aug 00:50 2015

netbsd-7 panic

I have an amd64 machine running netbsd-7 from 6-August-2015 which 
does common hosting (email, web, DNS), IPv6 tunnels and NAT, 
amongst other things. It paniced like this a few weeks ago when it had 
been running netbsd-7 from March, but otherwise it's been problem free.

Any thoughts or ideas about what could be causing this?

fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff80722fb2 cs 8 rflags 10297 cr2 36 ilevel 2 
rsp ff
fffe811cfebec0
curlwp 0xfffffe842df3b860 pid 0.5 lowest kstack 0xfffffe811cfe92c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x96
ipf_frag_delete() at netbsd:ipf_frag_delete+0x74
ipf_frag_expire() at netbsd:ipf_frag_expire+0x152
ipf_slowtimer() at netbsd:ipf_slowtimer+0x15
ipf_timer_func() at netbsd:ipf_timer_func+0x2d
callout_softclock() at netbsd:callout_softclock+0x248
softint_dispatch() at netbsd:softint_dispatch+0x79
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffffe811cfebff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
cpu0: End traceback...

(Continue reading)

Jeff Rizzo | 11 Aug 06:31 2015
Picon

wapbl + discard panic

I'm guessing at the moment the answer is "don't do that," but it looks 
like wapbl and discard aren't playing nice together:

panic: kernel diagnostic assertion "rw_lock_held(&wl->wl_rwlock)" 
failed: file "/home/riz/src/sys/kern/vfs_wapbl.c", line 1715
Stopped in pid 0.54 (system) at netbsd:cpu_Debugger+0x4: bx      r14
db{0}> bt
0xbfaffe34: netbsd:vpanic+0xc
0xbfaffe4c: netbsd:__udivmoddi4
0xbfaffe74: netbsd:wapbl_jlock_assert+0x54
0xbfaffe9c: netbsd:wapbl_add_buf+0x3c
0xbfaffebc: netbsd:bdwrite+0xc4
0xbfafff1c: netbsd:ffs_blkfree_cg+0x190
0xbfafff4c: netbsd:ffs_blkfree_td+0x60
0xbfafff7c: netbsd:ffs_discardcb+0x64
0xbfafffac: netbsd:workqueue_worker+0x84
db{0}>

Masanobu SAITOH | 6 Aug 13:49 2015

argument of pci_msi[x]_count()

 Hi, all.

 Currently, pci_msi_count() and pci_msix_count() take one pci_attach_args argument.
These functions may be used in other than attach function. So, it might be
better to use pci_chipset_tag_t and pcitag_t.

 Is the following diff better than current specification?

Index: share/man/man9/pci_msi.9
===================================================================
RCS file: /cvsroot/src/share/man/man9/pci_msi.9,v
retrieving revision 1.6
diff -u -p -r1.6 pci_msi.9
--- share/man/man9/pci_msi.9	24 Jul 2015 07:40:58 -0000	1.6
+++ share/man/man9/pci_msi.9	6 Aug 2015 11:24:57 -0000
 <at>  <at>  -44,7 +44,8  <at>  <at> 
 .Nd PCI MSI{,-X} manipulation functions
 .Sh SYNOPSIS
 .Ft int
-.Fn pci_msi_count "struct pci_attach_args *pa"
+.Fn pci_msi_count "pci_chipset_tag_t pc" \
+"pcitag_t tag"
 .Ft int
 .Fn pci_msi_alloc  "struct pci_attach_args *pa" \
 "pci_intr_handle_t **ihps" "int *count"
 <at>  <at>  -52,7 +53,8  <at>  <at> 
 .Fn pci_msi_alloc_exect "struct pci_attach_args *pa" \
 "pci_intr_handle_t **ihps" "int count"
 .Ft int
-.Fn pci_msix_count "struct pci_attach_args *pa"
(Continue reading)


Gmane