Re: CVS commit: src/sys/dev/mii

[Masanobu SAITOH]

On 2016/09/19 11:00, Ryo ONODERA wrote:

Hi,

With this change, the following wm(4) device links in 10BASE-T when it
is connected to 100BASE or 1000BASE hub.


Could you show me the dmesg of wm and *phy?

Thanks in advance.





From: "SAITOH Masanobu" , Date: Fri, 9 Sep 2016 06:34:10 
+


Module Name:src
Committed By:   msaitoh
Date:   Fri Sep  9 06:34:10 UTC 2016

Modified Files:
src/sys/dev/mii: inbmphyreg.h

Log Message:
 HV_OEM_BITS is not page 0 but page 768.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/sys/dev/mii/inbmphyreg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



--
Ryo ONODERA // ryo...@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch

[Manuel Bouyer]

On Fri, Sep 16, 2016 at 11:48:10AM +, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date: Fri Sep 16 11:48:10 UTC 2016
> 
> Modified Files:
>   src/sys/arch/amd64/amd64: trap.c
>   src/sys/arch/i386/i386: trap.c
> 
> Log Message:
> Put two KASSERTs, to make sure the fault is happening in the correct
> half of the vm space when using special copy functions. It can detect
> bugs where the kernel would fault when copying a kernel buffer which
> it wrongly believes comes from userland.

Hello,
i386/Xen now panics, maybe because of this commit:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/i386/201609171110Z_anita.txt

kernel/t_kauth_pr_47598 (75/660): 1 test cases
kauth_curtain: panic: kernel diagnostic assertion "onfault == kcopy_fault 
|| rcr2() < VM_MAXUSER_ADDRESS" failed: file 
"/usr/src/sys/arch/i386/i386/trap.c", line 358 
cpu2: Begin traceback...
?(c055cc10,cddcec74,cddcecf8,c010bd8e,c055cc10,c055cb52,c055d32c,c055d250,166,c01157a4)
 at c0429e3d
uvm_fault(0xc18a335c, 0x53e58000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0110d35 cs 9 eflags 10246 cr2 53e58955 ilevel 8 esp 
cddce734
curlwp 0xc19bb2a0 pid 10874 lid 1 lowest kstack 0xcddcc2c0
Skipping crash dump on recursive panic
panic: trap
Faulted in mid-traceback; aborting...
rebooting...


Any idea ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: CVS commit: src/sys/dev/ic

[Taylor R Campbell]

   Date: Mon, 19 Sep 2016 01:36:14 +
   From: David Holland 

   On Sun, Sep 18, 2016 at 09:52:37PM +, Jaromir Dolecek wrote:
> Modified Files:
>   src/sys/dev/ic: ld_nvme.c
> 
> Log Message:
> must use PR_NOWAIT also during ldattach()/dkwedge discover, our
> i/o is there called with a spin lock held, which triggers
> LOCKDEBUG panic

   That sounds like it should be corrected upstream of nvme...?

Here's the relevant call tree:

ld_diskstart
  acquires sc->sc_mutex (an IPL_VM spin lock)
  calls sc->sc_start = ld_nvme_start
calls ld_nvme_dobio
  calls nvme_ns_get_ctx with PR_WAITOK or PR_NOWAIT
  releases sc->sc_mutex

In this call tree, it is *never* correct to use PR_WAITOK, because the
spin lock is unconditionally held.  And the only other caller of
ld_nvme_dobio is ld_nvme_dump, which is probably not allowed to block
either for other reasons -- which presumably led to the abuse of
cpu_(soft)intr_p here.

Instead, you should prime nvme_ns_ctx_cache up front, e.g. by calling
pool_cache_setlowat in ld_nvme_attach (and maintaining a count of the
nvme instances), and always use PR_NOWAIT.  Also, you need to handle
failure in nvme_ns_get_ctx.  From a cursory examination of dk_start,
it looks like returning EAGAIN will DTRT -- dk_start will retry the
block later.

(Incidentally, it looks like nvme is statically wired to use a maximum
queue depth of 128.  In that case, you could just use a fixed array of
128 entries -- that's just a few pages of RAM.  But maybe you want to
be able to change the queue depth later.)