Re: CVS commit: src/sys/arch/arm
On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson sk...@netbsd.org wrote: On 04/07/15 04:19, Ryota Ozaki wrote: Module Name:src Committed By: ozaki-r Date: Tue Apr 7 03:19:25 UTC 2015 Modified Files: src/sys/arch/arm/ep93xx: ep93xx_intr.c src/sys/arch/arm/ixp12x0: ixp12x0_intr.c Log Message: Add missing #include arm/cpu.h sys/lwp.h is preferred, I think I see. It works for me too. I'll change so. Just curious, why is sys/lwp.h better? Because it is MI while arm/cpu.h is MD? Thanks, ozaki-r
Re: CVS commit: src/sys/dev/pci
Hi, Martin. On 2015/04/06 16:38, Martin Husemann wrote: Module Name:src Committed By: martin Date: Mon Apr 6 07:38:17 UTC 2015 Modified Files: src/sys/dev/pci: if_bge.c Log Message: Make sure to halt (not just stop) the bge_tick callout during detach. To generate a diff of this commit: cvs rdiff -u -r1.280 -r1.281 src/sys/dev/pci/if_bge.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. What does this change fix? To prevent panic on shutdown? Almost all drviers have the same code. Should we fix all of them like this? -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/arch/arm
On Apr 7, 2015, at 1:27 AM, Ryota Ozaki ozak...@netbsd.org wrote: On Tue, Apr 7, 2015 at 5:13 PM, Nick Hudson sk...@netbsd.org wrote: On 04/07/15 04:19, Ryota Ozaki wrote: Module Name:src Committed By: ozaki-r Date: Tue Apr 7 03:19:25 UTC 2015 Modified Files: src/sys/arch/arm/ep93xx: ep93xx_intr.c src/sys/arch/arm/ixp12x0: ixp12x0_intr.c Log Message: Add missing #include arm/cpu.h sys/lwp.h is preferred, I think I see. It works for me too. I'll change so. Just curious, why is sys/lwp.h better? Because it is MI while arm/cpu.h is MD? arm/cpu.h has a dependency on sys/lwp.h
Re: CVS commit: src
On Mon, Apr 6, 2015 at 7:02 PM, Martin Husemann mar...@duskware.de wrote: On Sun, Apr 05, 2015 at 09:40:22AM -0400, Christos Zoulas wrote: Hmm, it is building things twice... I am trying to figure out why but I can't reproduce it. Not surprising at all if multiple output hack (*.y) is involved. Not sure, but it basically fails for me on all build machines if using low values for -j. I can get past it by doing a cleandir and dependall without -j. Also below is a log of a non-cleandir'd build failing, but that looks mostly the same now. If I were you, I'd look at make -dm output. (Remember that make(1) has no idea that foo.c and ./foo.c are identical; they are just strings for make(1).)
