Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display
From: Jun Ebihara Subject: Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display Date: Wed, 13 Jul 2022 08:22:11 +0900 (JST) > with NetBSD-9.99.98-amd64-20220750Z, > testing HDMI port on i915,seems working again! > https://twitter.com/ebijun/status/1546995945652764672 audio output problem: On drm2/dist/drm/i915/intel_uncore.c:1197 https://twitter.com/ebijun/status/1547029830386196481 -- Jun Ebihara
Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display
From: Jun Ebihara Subject: Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display Date: Mon, 23 May 2022 19:27:57 +0900 (JST) > with this change, > https://twitter.com/ebijun/status/1528682086520893441 > find HDMI port again! > but > - cant set CRTC 64 > - XRandR returned error code 1: b'xrandr: Configure crtc 1 failed with NetBSD-9.99.98-amd64-20220750Z, testing HDMI port on i915,seems working again! https://twitter.com/ebijun/status/1546995945652764672 need more checking.and thanks your works. -- Jun Ebihara
Re: CVS commit: src
Date:Wed, 25 May 2022 14:07:09 -0400 From:Greg Troxel Message-ID: | kre@ disagrees with me about it being wrong; Only mildly, I can see your point. My reply was sent before I saw yours. | the mbone was a particular overlay network, a social phenomenon, yes. | My point was just that the basic system routing support was not | "mbone", but simply "multicast routing". Also agreed. | You wouldn't really use video chat over | local because you'd just walk down the hall instead. Don't bet on it. Some of us are inherently lazy beasts... (I, even now, use phone calls to talk within the house, could easily just walk and talk, but that's work!) But that wasn't mbone, which as you have said, was one particular overlay network (almost a vpn, but only for multicast). I wonder if the nasa satellite images are still being broadcast? Anyone know? | It was talking to people at other sites that was a big deal. Yes. kre
Re: CVS commit: src
>> All of these applications depends on the "MROUTING" kernel option, >> it seems, which is mostly default-off, except for a few (tending >> on the more obscure side) kernel configs. I wonder if anyone >> knows the history there. > > I'm not really sure why MROUTING is default off [...] Isn't MROUTING the kernel support to act as a multicast router, typically by using the DVMRP protocol, implemented in mrouted. People operating multicast networks today typically do that using real routers and variants of PIM. I don't think NetBSD ever got the ability to do PIM, nor IGMP3 for that matter, I vaguely seem to recall there being licensing issues involved, at least for the latter. Typically, MROUTING isn't needed to *use* most of the non- routing-focused multicast-based tools, e.g. I run a dbeacon instance with just a normal GENERIC kernel using any-source PIM. Regards, - Håvard
Re: CVS commit: src
Alistair Crooks writes: > On Wed, May 25, 2022 at 15:13 Greg Troxel wrote: > >> >> Slightly, but not really. Back then, there was multicast routing, and >> then there was the mbone project for wide-area multicast because the >> internet didn't yet support it like it eventually would (reality ended >> up different). Things like vic and vac came out of the research effort >> that was associated with mbone deployment, and that's why I mentioned >> them as "mbone". It's true they work on multicast rather than mbone, >> and thus arguably we should rename the category, but in pkgsrc we don'd >> do that. I'd say the pkgsrc name is wrong though. > > I haven't looked at cvs history, but my recollection (it was 25 years ago) > is that the pkgsrc mbone category name came from FreeBSD at the initial > import - over time, we got rid of some categories that didn't match the > functionality requirement - plan9, japanese, etc - and we and they added > others without coordination - inputmethods, ftp, dns etc. > > My bad for not being aware of these things at the time, sorry kre@ disagrees with me about it being wrong; the mbone was a particular overlay network, a social phenomenon, and a group of tools built for that network all at the same time, and most of the mbone/ category is what people of that day would have thought of as mbone tools. My point was just that the basic system routing support was not "mbone", but simply "multicast routing". You wouldn't really use video chat over local because you'd just walk down the hall instead. It was talking to people at other sites that was a big deal. signature.asc Description: PGP signature
Re: CVS commit: src
Date:Wed, 25 May 2022 17:01:45 + From:Greg Troxel Message-ID: <3b44ca5a-2d54-4e91-937b-90e8557c3...@lexort.com> | On May 25, 2022 4:55:58 PM UTC, nia wrote: | >I will rename the option to MKMROUTING. | | Thanks -- I think that's a good name and better than what I suggested. I agree, much more appropriate. Thanks. kre
Re: CVS commit: src
On May 25, 2022 4:55:58 PM UTC, nia wrote: >On Wed, May 25, 2022 at 09:50:29PM +0700, Robert Elz wrote: >> What is in pkgsrc/mbone is mostky tge ancient mbone tools >> (I don't recognise everything) and the name fits for that. >> We have nothing mbone in base that I know if, nomkmbone >> (or whatever) doesn't make a lot of sense (as a name). >> >> kre >> >> ps: I build kernels with MROUTING turned on. > >I will rename the option to MKMROUTING. > Thanks -- I think that's a good name and better than what I suggested.
Re: CVS commit: src
On Wed, May 25, 2022 at 09:50:29PM +0700, Robert Elz wrote: > What is in pkgsrc/mbone is mostky tge ancient mbone tools > (I don't recognise everything) and the name fits for that. > We have nothing mbone in base that I know if, nomkmbone > (or whatever) doesn't make a lot of sense (as a name). > > kre > > ps: I build kernels with MROUTING turned on. I will rename the option to MKMROUTING.
Re: CVS commit: src
Date:Wed, 25 May 2022 10:13:19 -0400 From:Greg Troxel Message-ID: | if you set the | wayback machine to a VAX with 1MB of RAM and a 100 MB disk, or 8MB and | 250 MB. I'm fuzzy on the exact numbers, but I'm sure kernel RAM usage | was a much bigger deal than disk. A 780 would usually have been 4MB RAM, though 1 was possible. Sometimes 8. A couple of systems went beyond what was expected and had 12. ENORMOUS. A 750 might have had only 1 or 2. A 730 I don't recall, but those things ran slower than a snail through molasses, almost unusable. Disk varied, 60MB was common early (usually 2 of them), some 300MB were around. Then 335MB eagles appeared (lots cheaper than the earlier 300MB revovables ... until then, essentially everything was removable packs). Having 2 eagles was luxury indeed! As for ram vs disk space ... running a system with hundreds of user accounts, all sharing 30 or 60MB, made disk conservation and management critical - hence quotas. Undergrad users might have only been allowed 50KB of long term storage... kre ps: when doing comparisons, remember that those were the days when a MB was a MB, not just a wimpy million bytes!
Re: CVS commit: src
Date:Wed, 25 May 2022 14:06:31 + From:nia Message-ID: | All of these applications depends on the "MROUTING" kernel option, | it seems, which is mostly default-off, except for a few (tending | on the more obscure side) kernel configs. I wonder if anyone | knows the history there. Some if us do - some of us used the mbone when it was just a few dozen users, and one could chat with Deering, van Jacobsen (etc) What is in pkgsrc/mbone is mostky tge ancient mbone tools (I don't recognise everything) and the name fits for that. We have nothing mbone in base that I know if, nomkmbone (or whatever) doesn't make a lot of sense (as a name). kre ps: I build kernels with MROUTING turned on.
Re: CVS commit: src
nia writes: > On Wed, May 25, 2022 at 08:42:20AM -0400, Greg Troxel wrote: >> I was really surprisd that we had mbone applications in base; to me, >> that would mean things like vic and vat. >> >> This is not about about MBONE; it's about multicast routing. The mbone >> was an overlay network to connect local multicast islands, and operated >> in the 90s. > > Interesting, thanks. > >> Separately from the mbone, I have used multicast routing support in >> NetBSD across connected local networks. >> >> (Arguably map-mbone is misnamed; it really isn't about the mbone per se >> but about whatever multicast network is available. But that's just a >> historical note.) > > Is the name situation same for the category in pkgsrc? Slightly, but not really. Back then, there was multicast routing, and then there was the mbone project for wide-area multicast because the internet didn't yet support it like it eventually would (reality ended up different). Things like vic and vac came out of the research effort that was associated with mbone deployment, and that's why I mentioned them as "mbone". It's true they work on multicast rather than mbone, and thus arguably we should rename the category, but in pkgsrc we don'd do that. I'd say the pkgsrc name is wrong though. >> I don't object to a default-on MK knob; having knobs to make base >> smaller seems entirely reasonable. >> >> I would suggest "multicast" as a word rather than mbone, as what this >> knob does is remove user-space support for IP multicast routing. >> Someone who understands the history would not expect mrouted to vanish >> by disabling mbone. > > All of these applications depends on the "MROUTING" kernel option, > it seems, which is mostly default-off, except for a few (tending > on the more obscure side) kernel configs. I wonder if anyone > knows the history there. I'm not really sure why MROUTING is default off, but I think BSD tradition is that the user-space tools are present even for kernel options that are off, and that was ok because ~everybody built their own kernel anyway, but almost nobody rebuilt userland. The disk space for these programs was small, and kernel RAM was a big deal, if you set the wayback machine to a VAX with 1MB of RAM and a 100 MB disk, or 8MB and 250 MB. I'm fuzzy on the exact numbers, but I'm sure kernel RAM usage was a much bigger deal than disk. signature.asc Description: PGP signature
Re: CVS commit: src
On Wed, May 25, 2022 at 08:42:20AM -0400, Greg Troxel wrote: > I was really surprisd that we had mbone applications in base; to me, > that would mean things like vic and vat. > > This is not about about MBONE; it's about multicast routing. The mbone > was an overlay network to connect local multicast islands, and operated > in the 90s. Interesting, thanks. > Separately from the mbone, I have used multicast routing support in > NetBSD across connected local networks. > > (Arguably map-mbone is misnamed; it really isn't about the mbone per se > but about whatever multicast network is available. But that's just a > historical note.) Is the name situation same for the category in pkgsrc? > I don't object to a default-on MK knob; having knobs to make base > smaller seems entirely reasonable. > > I would suggest "multicast" as a word rather than mbone, as what this > knob does is remove user-space support for IP multicast routing. > Someone who understands the history would not expect mrouted to vanish > by disabling mbone. All of these applications depends on the "MROUTING" kernel option, it seems, which is mostly default-off, except for a few (tending on the more obscure side) kernel configs. I wonder if anyone knows the history there.
Re: CVS commit: src
"Nia Alarie" writes: > Module Name: src > Committed By: nia > Date: Wed May 25 10:18:30 UTC 2022 > > Modified Files: > src/distrib/sets/lists/base: mi > src/distrib/sets/lists/etc: mi > src/distrib/sets/lists/man: mi > src/etc: Makefile > src/etc/mtree: special > src/etc/rc.d: Makefile > src/share/man/man5: mk.conf.5 > src/share/mk: bsd.README bsd.own.mk > src/usr.sbin: Makefile > > Log Message: > mk: Allow building base without the MBONE applications by setting > MKMBONE=no in mk.conf I was really surprisd that we had mbone applications in base; to me, that would mean things like vic and vat. This is not about about MBONE; it's about multicast routing. The mbone was an overlay network to connect local multicast islands, and operated in the 90s. Separately from the mbone, I have used multicast routing support in NetBSD across connected local networks. (Arguably map-mbone is misnamed; it really isn't about the mbone per se but about whatever multicast network is available. But that's just a historical note.) I don't object to a default-on MK knob; having knobs to make base smaller seems entirely reasonable. I would suggest "multicast" as a word rather than mbone, as what this knob does is remove user-space support for IP multicast routing. Someone who understands the history would not expect mrouted to vanish by disabling mbone. signature.asc Description: PGP signature
Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display
with this change, https://twitter.com/ebijun/status/1528682086520893441 find HDMI port again! but - cant set CRTC 64 - XRandR returned error code 1: b'xrandr: Configure crtc 1 failed thanx and need one more. From: "Taylor R Campbell" Subject: CVS commit: src/sys/external/bsd/drm2/dist/drm/i915/display Date: Sun, 22 May 2022 21:18:12 + > Module Name: src > Committed By: riastradh > Date: Sun May 22 21:18:12 UTC 2022 > > Modified Files: > src/sys/external/bsd/drm2/dist/drm/i915/display: intel_gmbus.c > > Log Message: > i915: Fix sense of conditional for gmbus wait. > > This enables i915 to again retrieve EDID data from displays over the > I2C DDC. > > Embarrassing. > > > To generate a diff of this commit: > cvs rdiff -u -r1.6 -r1.7 \ > src/sys/external/bsd/drm2/dist/drm/i915/display/intel_gmbus.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: /dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Tue, May 17, 2022 at 12:48:06PM +0300, Valery Ushakov wrote: > Any thoughts on this? The problematic scenario is that the system is > upgraded, new MAKEDEV is run after the upgrade to (re)create the > devices, it creates world readabile /dev/wsfont, and then an old > kernel is booted (which is kinda in the unsupported territory). That > would allow fonts to be loaded by anyone, exposing whatever bugs are > lurking in wsfont(4) to J. Random User. I guess we can live with that risk. > Does anyone have a secret devfs project that can be merged in time for > 10 by any chance? :) There is no time left to be "in time for 10"! (We are a few days past planned branch date already) Martin
Re: /dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Fri, May 13, 2022 at 02:49:29 +0300, Valery Ushakov wrote: > On Thu, May 12, 2022 at 23:17:42 +, Valeriy E. Ushakov wrote: > > > Module Name:src > > Committed By: uwe > > Date: Thu May 12 23:17:42 UTC 2022 > > > > Modified Files: > > src/sys/dev/wsfont: wsfontdev.c > > > > Log Message: > > wsfont(4): WSDISPLAYIO_LDFONT requires device opened for writing. > > /dev/wsfont used to be root:root 0600 and didn't bother to check > FWRITE in its ioctl code. macallan@ recently added support for > listing the loaded fonts (WSDISPLAYIO_LISTFONTS, wsfontload -l). It > would make sense to make that available to normal users - it's weird > to allow them to set the font but not list the available fonts. But > that creates a bit of a problem if someone uses new MAKEDEV that > creates 0644 /dev/wsfont but boots an old kernel that doesn't have the > FWRITE check. Any thoughts on this? The problematic scenario is that the system is upgraded, new MAKEDEV is run after the upgrade to (re)create the devices, it creates world readabile /dev/wsfont, and then an old kernel is booted (which is kinda in the unsupported territory). That would allow fonts to be loaded by anyone, exposing whatever bugs are lurking in wsfont(4) to J. Random User. Does anyone have a secret devfs project that can be merged in time for 10 by any chance? :) -uwe
/dev/wsfont permissions (Was: CVS commit: src/sys/dev/wsfont)
On Thu, May 12, 2022 at 23:17:42 +, Valeriy E. Ushakov wrote: > Module Name: src > Committed By: uwe > Date: Thu May 12 23:17:42 UTC 2022 > > Modified Files: > src/sys/dev/wsfont: wsfontdev.c > > Log Message: > wsfont(4): WSDISPLAYIO_LDFONT requires device opened for writing. /dev/wsfont used to be root:root 0600 and didn't bother to check FWRITE in its ioctl code. macallan@ recently added support for listing the loaded fonts (WSDISPLAYIO_LISTFONTS, wsfontload -l). It would make sense to make that available to normal users - it's weird to allow them to set the font but not list the available fonts. But that creates a bit of a problem if someone uses new MAKEDEV that creates 0644 /dev/wsfont but boots an old kernel that doesn't have the FWRITE check. -uwe
Re: dhcpd broken on -current (Re: CVS commit: src/external/mpl/dhcp)
Should work now... [2:55pm] 173>cvs commit socket.c /cvsroot/src/external/mpl/bind/dist/lib/isc/unix/socket.c,v <-- socket.c new revision: 1.16; previous revision: 1.15 christos signature.asc Description: Message signed with OpenPGP
Re: dhcpd broken on -current (Re: CVS commit: src/external/mpl/dhcp)
Yes, I see that too. Strange because not much has changed... christos > On May 31, 2020, at 8:01 AM, Tobias Nygren wrote: > > Hi, > > On Sun, 24 May 2020 15:50:13 -0400 > Christos Zoulas wrote: > >> Modified Files: >> src/external/mpl/dhcp: Makefile.inc >> src/external/mpl/dhcp/dist/omapip: isclib.c >> >> Log Message: >> Adjust for bind-9.16.3 > > After the bind update I found my dhcpd is no longer giving out > leases and it again started exhibiting the old problem where > "/etc/rc.d/dhcpd stop" hangs. Probably there is a libisc > incompatibility again? > > -Tobias signature.asc Description: Message signed with OpenPGP
dhcpd broken on -current (Re: CVS commit: src/external/mpl/dhcp)
Hi, On Sun, 24 May 2020 15:50:13 -0400 Christos Zoulas wrote: > Modified Files: > src/external/mpl/dhcp: Makefile.inc > src/external/mpl/dhcp/dist/omapip: isclib.c > > Log Message: > Adjust for bind-9.16.3 After the bind update I found my dhcpd is no longer giving out leases and it again started exhibiting the old problem where "/etc/rc.d/dhcpd stop" hangs. Probably there is a libisc incompatibility again? -Tobias
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 29, 2020, at 1:56 PM, Robert Swindells wrote: > > > On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >> >> I think this commit broke lang/oracle8-jre: > > Linux Java doesn't crash now for me but doesn't do much, top(1) shows it > to be waiting on a futex. > > Tried doing "java -version" and running larger things. "java -version" fails very intermittently for me. Or, rather, it fails once (gets stuck), and then after killing it with SIGKILL it no longer gets stuck when I try it again. Investigating. -- thorpej
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: > > I think this commit broke lang/oracle8-jre: Linux Java doesn't crash now for me but doesn't do much, top(1) shows it to be waiting on a futex. Tried doing "java -version" and running larger things.
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 28, 2020, at 4:25 PM, Robert Swindells wrote: > > Jason Thorpe wrote: >>> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >>> >>> I think this commit broke lang/oracle8-jre: >> >> This is a Linux binary running under COMPAT_LINUX? It would be strange >> if it broke it because it essentially makes the whole system do what the >> Linux emulation was already doing. > > Has anything changed around where the initial stack gets put in VM ? > > The Linux build of OpenJDK uses this to work out whether it is using > the initial thread or another one. No. There were actually a few problems: - A mistake I made in the compat_linux futex syscall stub that redirects to the native. - A difference in how process lookup works between NetBSD and Linux that was accidentally removed when the LWP ID overhaul changes were made. - Some latent bugs in argument handling in some of the scheduling-related Linux syscalls. I'll check in fixes for these tonight. -- thorpej
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
Jason Thorpe wrote: >> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >> >> I think this commit broke lang/oracle8-jre: > >This is a Linux binary running under COMPAT_LINUX? It would be strange >if it broke it because it essentially makes the whole system do what the >Linux emulation was already doing. Has anything changed around where the initial stack gets put in VM ? The Linux build of OpenJDK uses this to work out whether it is using the initial thread or another one.
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote:
>
> I think this commit broke lang/oracle8-jre:
This is a Linux binary running under COMPAT_LINUX? It would be strange if it
broke it because it essentially makes the whole system do what the Linux
emulation was already doing.
I'll take a look.
>
> My test case is:
> $ ftp https://webstart.buergerkarte.at/PDF-Over/setup_pdf-over_linux.jar
> ...
> $ oracle8-java -jar setup_pdf-over_linux.jar
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (os_linux_x86.cpp:730), pid=9919, tid=0x7f7ff5f2b700
> # fatal error: pthread_getattr_np failed with errno = 3
> #
> # JRE version: (8.0_202-b08) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode
> linux-amd64 compressed oops)
> # Core dump written. Default location: /home/wiz/core or core.9919
> #
> # An error report file with more information is saved as:
> # /home/wiz/hs_err_pid9919.log
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> [1] Abort trap (core dumped) /usr/pkg/java/oracle-8/bin/java "${@}"
>
> Thomas
-- thorpej
Problem with Linux emulation [was Re: CVS commit: src/sys]
On Fri, Apr 24, 2020 at 03:22:06AM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Fri Apr 24 03:22:06 UTC 2020
>
> Modified Files:
> src/sys/compat/linux/common: linux_exec.c linux_sched.c
> src/sys/kern: kern_exec.c kern_exit.c kern_fork.c kern_lwp.c
> kern_proc.c sys_lwp.c
> src/sys/sys: lwp.h proc.h
>
> Log Message:
> Overhaul the way LWP IDs are allocated. Instead of each LWP having it's
> own LWP ID space, LWP IDs came from the same number space as PIDs. The
> lead LWP of a process gets the PID as its LID. If a multi-LWP process's
> lead LWP exits, the PID persists for the process.
>
> In addition to providing system-wide unique thread IDs, this also lets us
> eliminate the per-process LWP radix tree, and some associated locks.
>
> Remove the separate "global thread ID" map added previously; it is no longer
> needed to provide this functionality.
>
> Nudged in this direction by ad@ and chs@.
I think this commit broke lang/oracle8-jre:
My test case is:
$ ftp https://webstart.buergerkarte.at/PDF-Over/setup_pdf-over_linux.jar
...
$ oracle8-java -jar setup_pdf-over_linux.jar
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:730), pid=9919, tid=0x7f7ff5f2b700
# fatal error: pthread_getattr_np failed with errno = 3
#
# JRE version: (8.0_202-b08) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64
compressed oops)
# Core dump written. Default location: /home/wiz/core or core.9919
#
# An error report file with more information is saved as:
# /home/wiz/hs_err_pid9919.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
[1] Abort trap (core dumped) /usr/pkg/java/oracle-8/bin/java "${@}"
Thomas
Re: CVS commit: src/sys [freeze on boot]
> On Jan 20, 2020, at 3:44 PM, Christos Zoulas wrote: > > In article <20200120185023.gd28...@homeworld.netbsd.org>, > Andrew Doran wrote: >> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the >> problem as I am running with LOCKDEBUG. >> >> Apologies for the disruption. > > FYI: powerpc/arm do not build anymore... This should fix the powerpc problem: Index: lock_stubs.S === RCS file: /cvsroot/src/sys/arch/powerpc/powerpc/lock_stubs.S,v retrieving revision 1.10 diff -u -p -r1.10 lock_stubs.S --- lock_stubs.S28 Feb 2014 05:38:15 - 1.10 +++ lock_stubs.S21 Jan 2020 04:09:26 - @@ -101,8 +101,8 @@ ENTRY(mutex_exit) /* * void rw_enter(krwlock_t *krw, krw_t op); */ -#if RW_READ_INCR != 16 -#error RW_READ_INCR != 16, clrrXi need fixing +#if RW_READ_INCR != 32 +#error RW_READ_INCR != 32, clrrXi need fixing #endif #if RW_OWNER != 0 #error RW_OWNER != 0, ldptr should be ldptru @@ -115,7 +115,7 @@ ENTRY(rw_enter) bne-1f ldptr %r9,RW_OWNER(%r3) - clrrptri %r9,%r9,4 /* clear low 4 bits */ + clrrptri %r9,%r9,5 /* clear low 5 bits */ addi%r7,%r9,RW_READ_INCR b 2f 1: @@ -140,7 +140,7 @@ ENTRY(rw_tryenter) bne-1f ldptr %r9,RW_OWNER(%r3) - clrrptri %r9,%r9,4 /* clear low 4 bits */ + clrrptri %r9,%r9,5 /* clear low 5 bits */ addi%r7,%r9,RW_READ_INCR b 2f @@ -169,7 +169,7 @@ ENTRY(rw_exit) andi. %r0,%r9,RW_WRITE_LOCKED bne-1f - clrrptri. %r9,%r9,4 /* clear low 4 bits */ + clrrptri. %r9,%r9,5 /* clear low 5 bits */ beq-3f /* if 0, no reader, go slow */ addi%r7,%r9,-RW_READ_INCR > > http://releng.netbsd.org/builds/HEAD/202001201020Z/ > > christos > -- thorpej
Re: CVS commit: src/sys [freeze on boot]
На 2020-01-20 в 18:50, Andrew Doran написа: > Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the > problem as I am running with LOCKDEBUG. > > Apologies for the disruption. All good now, thanks. > Andrew
Re: CVS commit: src/sys [freeze on boot]
Hi, Thanks for your quick fix. It works fine for my laptop now. On January 21, 2020 3:50:23 AM GMT+09:00, Andrew Doran wrote: >Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the >problem as I am running with LOCKDEBUG. > >Apologies for the disruption. > >Andrew -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys [freeze on boot]
Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the problem as I am running with LOCKDEBUG. Apologies for the disruption. Andrew
Re: CVS commit: src/usr.sbin/postinstall
Roy Marples writes: > On 13/06/2019 09:00, Manuel Bouyer wrote: >> On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: >>> [...] >>> I've been using etcupdate for ages so I only ever really used >>> postinstall to fix "obsolete" and "catpages". etcupdate -a has some >>> kinks and may be we should concentrate on fixing those instead? >> >> I *never* used etcupdate, so for me it's better to have a working postinstall >> (I have a PR about it: install/52349, which may have been fixed by the >> recent change) > > I used etc-update once and accidently overwrote master.passwd > Never used it since, far too risky. etcmanage, in pkgsrc, was designed to specifically avoid touching any file unless it is reliably recorded as matching upstream.
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 17:07:36 -, Christos Zoulas wrote: > In article <20190613112930.gr17...@pony.stderr.spb.ru>, > Valery Ushakov wrote: > >On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > > > >> On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > >> > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > >> > > >> > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > >> > > > [...] > >> > > > I've been using etcupdate for ages so I only ever really used > >> > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > >> > > > kinks and may be we should concentrate on fixing those instead? > >> > > > >> > > I *never* used etcupdate, so for me it's better to have a working > >postinstall > >> > > (I have a PR about it: install/52349, which may have been fixed by the > >> > > recent change) > >> > > >> > The rc.d part is probably addressed by this very change that Christos > >> > made (that i was replying to). > >> > > >> > The other part is exactly what I'm talking about. postinstall does > >> > NOT update your system to the new etc.tgz set, it cherry picks stuff > >> > from the new etc.tgz. > >> > >> It should create files and directory that are expected to be there > >> but are not. > > > >That "should" seems to be the crux of the matter. It seems that > >different people think that postinstall should do different things. > > >Most new files added to etc that were not previously there are not > >needed to boot your system with its old etc (shinynewd may be hip and > >progressive, but if that system ran without it, it will happily > >continue to run without it for the time being). My conception of > >postinstall has always been that it takes care specifically about > >those rare cases where a new file in etc *is* required to keep the > >system operational and you, for whatever reasons, can't/don't want to > >do a full etc update. I may be misremembering, it's been about 15 > >years, please correct me if I do. > > No, this is correct (most shiny new files are not needed). There are > problems though: > 1. Files that get updated sometimes need the new files (npf for example >recently), and break otherwise. Was that file that get updated also in etc, as I understood from your private comments - in which case the new file won't be there since you still have mostly old etc, right? If something in the base set changes that requires a coordinated update to the configuration in etc then yes, that's the prime thing for postinstall to fix, as I understand. Consider e.g. ssh check that moves existing(!) /etc/ssh* files to /etc/ssh/* > 2. There is significant amount of work to keep things synchronized over. >There are multiple places people need to edit when adding/removing stuff >and this is error prone. Right. > 3. Keep upgrading and you end up missing more and more files in >/etc. What's the mechanism *in base* to help you keep them in >sync. etcupdate(8)? I've been using it all this time, since Martti committed it to base. I used it to upgrade very old machines (my mr.coffee hasn't been booted in a decade since 2007 and I upgraded it in 2017 and it was all very smooth). As I said, it has its kinks. Special handling for passwd/group would be very nice and -a (automatic) should really install new files without asking. Other then that I really love it. Adding a bit more user-friendliness to it might be in order simpley because most people that don't track current only use it may be once in a couple of years, so some handholding in this rather delicate task of merging new etc would definitely help to reassure them. > 4. Unpacking sets installs programs, postinstall deletes programs. This is >driven from the sets. OTOH their respective rc files don't get installed >or removed from postinstall; this seems inconsistent to me. For example, >dhclient got removed as a program, the rc file is still there. >The automount stuff got installed as programs the rc files did not. postinstall fix obsolete will delete programs, yes, but it should not be run blindly. Say, oldd is removed from base, as long as you don't run fix obsolete, you should be fine. Except, as I mentioned, fix rc seems to also delete obsolete rc files, in which case fix rc might screw your system by deleting oldd rc script (while the oldd itself and oldd.conf are still in place). fix obsolete and fix catpages are really quite orthogonal to the rest of postinstall. As I said, I use etcupdate, and obsolete and catpages are the only postinstall fixes that I need to use. So for fix rc to delete stuff seems a bit reckless. Again, as I said, after etcupdate fix obsolete will take care of obsolete etc stuff b/c you will get new /var/db/obsolete/etc When the automount staff got installed, again, that doesn't affect the current configuration of the system as embodied in the state of its etc. You can't use the new stuff
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 05:07:36PM -, Christos Zoulas wrote: > > I think that the desire here is for postinstall is to be a very safe process > that keeps the system up-to-date with minimal (or zero risk). The question is > how to achieve that? We have risk added because of the manual process of > keeping lists of things that postinstall does, and at the same time we have > risk added by inadvertently adding and running things that were not there > before. But this is not postinstall's fault. We should design things so > that they need to be explicitly enabled by the user. And there is gray > areas, like npf_boot which changes the functionality of the system. I'm perfectly happy with postinstall pointing at things that needs to be manually updated (like it does for e.g. users, groups or man.conf). I add new users to master.passwd or group and I'm perfectly happy with that (and I don't want something that does it for me because on some systems, these files are generated automatically from a database, so it's the database or the generating scripts that needs to be updated). The point of my PR is that there are files obviously missing from the system (as /etc/daily complains) and postinstall didn't even tell me. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/usr.sbin/postinstall
In article <20190613112930.gr17...@pony.stderr.spb.ru>, Valery Ushakov wrote: >On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > >> On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: >> > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: >> > >> > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: >> > > > [...] >> > > > I've been using etcupdate for ages so I only ever really used >> > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some >> > > > kinks and may be we should concentrate on fixing those instead? >> > > >> > > I *never* used etcupdate, so for me it's better to have a working >postinstall >> > > (I have a PR about it: install/52349, which may have been fixed by the >> > > recent change) >> > >> > The rc.d part is probably addressed by this very change that Christos >> > made (that i was replying to). >> > >> > The other part is exactly what I'm talking about. postinstall does >> > NOT update your system to the new etc.tgz set, it cherry picks stuff >> > from the new etc.tgz. >> >> It should create files and directory that are expected to be there >> but are not. > >That "should" seems to be the crux of the matter. It seems that >different people think that postinstall should do different things. >Most new files added to etc that were not previously there are not >needed to boot your system with its old etc (shinynewd may be hip and >progressive, but if that system ran without it, it will happily >continue to run without it for the time being). My conception of >postinstall has always been that it takes care specifically about >those rare cases where a new file in etc *is* required to keep the >system operational and you, for whatever reasons, can't/don't want to >do a full etc update. I may be misremembering, it's been about 15 >years, please correct me if I do. No, this is correct (most shiny new files are not needed). There are problems though: 1. Files that get updated sometimes need the new files (npf for example recently), and break otherwise. 2. There is significant amount of work to keep things synchronized over. There are multiple places people need to edit when adding/removing stuff and this is error prone. 3. Keep upgrading and you end up missing more and more files in /etc. What's the mechanism *in base* to help you keep them in sync. 4. Unpacking sets installs programs, postinstall deletes programs. This is driven from the sets. OTOH their respective rc files don't get installed or removed from postinstall; this seems inconsistent to me. For example, dhclient got removed as a program, the rc file is still there. The automount stuff got installed as programs the rc files did not. I think that the desire here is for postinstall is to be a very safe process that keeps the system up-to-date with minimal (or zero risk). The question is how to achieve that? We have risk added because of the manual process of keeping lists of things that postinstall does, and at the same time we have risk added by inadvertently adding and running things that were not there before. But this is not postinstall's fault. We should design things so that they need to be explicitly enabled by the user. And there is gray areas, like npf_boot which changes the functionality of the system. I would like postinstall to improve in these three areas (in priority order): 1. Make postinstall as safe as we can, by designing the installed files properly and blacklisting the dangerous ones. 2. Automate as much of it as possible so that there are fewer mistakes or omissions, and less work to be done. 3. Keep /etc as much in sync with a newly installed system, without breaking (1). christos
Re: CVS commit: src/usr.sbin/postinstall
On 06/13, Roy Marples wrote: > On 13/06/2019 09:00, Manuel Bouyer wrote: > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > [...] > > > I've been using etcupdate for ages so I only ever really used > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > kinks and may be we should concentrate on fixing those instead? > > > > I *never* used etcupdate, so for me it's better to have a working > > postinstall > > (I have a PR about it: install/52349, which may have been fixed by the > > recent change) > > I used etc-update once and accidently overwrote master.passwd > Never used it since, far too risky. If etcupdate is far too risky, then something needs to be fixed: etcupdate or the guide. Anyone following the guide is very likely to use it. In 33.1.4, "Updating the system configuration files" https://netbsd.org/docs/guide/en/chap-updating.html#updating-configfiles it says Updating your system's configuration files is done in two steps. First, postinstall(8) is used to check and fix things that can be easily automated. Afterwards, etcupdate(8) is used to merge the remaining configuration file changes. # /usr/sbin/postinstall -s /usr/src check # /usr/sbin/postinstall -s /usr/src fix # /usr/sbin/etcupdate -s /usr/src Lewis
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 12:50:02 +0200, Manuel Bouyer wrote: > On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > > > > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > > [...] > > > > I've been using etcupdate for ages so I only ever really used > > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > > kinks and may be we should concentrate on fixing those instead? > > > > > > I *never* used etcupdate, so for me it's better to have a working > > > postinstall > > > (I have a PR about it: install/52349, which may have been fixed by the > > > recent change) > > > > The rc.d part is probably addressed by this very change that Christos > > made (that i was replying to). > > > > The other part is exactly what I'm talking about. postinstall does > > NOT update your system to the new etc.tgz set, it cherry picks stuff > > from the new etc.tgz. > > It should create files and directory that are expected to be there > but are not. That "should" seems to be the crux of the matter. It seems that different people think that postinstall should do different things. Most new files added to etc that were not previously there are not needed to boot your system with its old etc (shinynewd may be hip and progressive, but if that system ran without it, it will happily continue to run without it for the time being). My conception of postinstall has always been that it takes care specifically about those rare cases where a new file in etc *is* required to keep the system operational and you, for whatever reasons, can't/don't want to do a full etc update. I may be misremembering, it's been about 15 years, please correct me if I do. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 01:13:52PM +0300, Valery Ushakov wrote: > On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > [...] > > > I've been using etcupdate for ages so I only ever really used > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > kinks and may be we should concentrate on fixing those instead? > > > > I *never* used etcupdate, so for me it's better to have a working > > postinstall > > (I have a PR about it: install/52349, which may have been fixed by the > > recent change) > > The rc.d part is probably addressed by this very change that Christos > made (that i was replying to). > > The other part is exactly what I'm talking about. postinstall does > NOT update your system to the new etc.tgz set, it cherry picks stuff > from the new etc.tgz. It should create files and directory that are expected to be there but are not. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 10:24:58 +0100, Roy Marples wrote: > Date: Thu, 13 Jun 2019 10:24:58 +0100 > From: Roy Marples > Subject: Re: CVS commit: src/usr.sbin/postinstall > To: Manuel Bouyer , current-users@NetBSD.org > > On 13/06/2019 09:00, Manuel Bouyer wrote: > > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > > [...] > > > I've been using etcupdate for ages so I only ever really used > > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > > kinks and may be we should concentrate on fixing those instead? > > > > I *never* used etcupdate, so for me it's better to have a working > > postinstall > > (I have a PR about it: install/52349, which may have been fixed by the > > recent change) > > I used etc-update once and accidently overwrote master.passwd > Never used it since, far too risky. Well, updating your etc is risky. Handling of passwd/group (or rather lack of special handling for them) is probably the weakest part of etcupdate UX. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 10:00:03 +0200, Manuel Bouyer wrote: > On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > > [...] > > I've been using etcupdate for ages so I only ever really used > > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > > kinks and may be we should concentrate on fixing those instead? > > I *never* used etcupdate, so for me it's better to have a working postinstall > (I have a PR about it: install/52349, which may have been fixed by the > recent change) The rc.d part is probably addressed by this very change that Christos made (that i was replying to). The other part is exactly what I'm talking about. postinstall does NOT update your system to the new etc.tgz set, it cherry picks stuff from the new etc.tgz. -uwe
Re: CVS commit: src/usr.sbin/postinstall
On 13/06/2019 09:00, Manuel Bouyer wrote: On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: [...] I've been using etcupdate for ages so I only ever really used postinstall to fix "obsolete" and "catpages". etcupdate -a has some kinks and may be we should concentrate on fixing those instead? I *never* used etcupdate, so for me it's better to have a working postinstall (I have a PR about it: install/52349, which may have been fixed by the recent change) I used etc-update once and accidently overwrote master.passwd Never used it since, far too risky. Roy
Re: CVS commit: src/usr.sbin/postinstall
On Thu, Jun 13, 2019 at 06:17:29AM +0300, Valery Ushakov wrote: > [...] > I've been using etcupdate for ages so I only ever really used > postinstall to fix "obsolete" and "catpages". etcupdate -a has some > kinks and may be we should concentrate on fixing those instead? I *never* used etcupdate, so for me it's better to have a working postinstall (I have a PR about it: install/52349, which may have been fixed by the recent change) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/usr.sbin/postinstall
On Wed, Jun 12, 2019 at 13:45:24 -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Jun 12 17:45:24 UTC 2019 > > Modified Files: > src/usr.sbin/postinstall: postinstall > > Log Message: > Remove hard-coded lists of rc files and generate them dynamically > from the sets. Fixes issues with automount, npf_boot etc. that were > never updated here! Isn't it the job of etcupdate to install the new files? Also, from a quick look postinstall fix rc will happily overwrite any local modifications you made to rc.d scripts - yes, changing them is not the best practice, but life happens. Also isn't it kinda strange to install /etc/rc.d/shinynewd and not install /etc/shinynewd.conf? Deleting obsolete rc.d files in "rc" (not "obsolete") also looks kinda scary to me. Say, we obsolete oldd. Alice installs new base.tgz, the old /sbin/oldd is still there (she's careful not to run "fix obsolete") and she has it still enabled for now. Then "fix rc" will delete its rc.d script, won't it? Note that if you do etcupdate you will get new /var/db/obsolete/etc, so later when you are ready you can do "fix obsolete" and get the rc script deleted along with the obsoleted binary. I guess what I'm trying to say is, does it really make sense to try to make postinstall provide some of the etcupdate functionality but in an ad-hoc and not quite safe manner? We are effectively trying to support the scenario where you do NOT do a full update to the new etc.tgz and still expect things to run. This might be not an unreasonable scenario to support, but then we probably shouldn't install inconsistent subset of the new etc.tgz in a a potentially unsafe manner. I've been using etcupdate for ages so I only ever really used postinstall to fix "obsolete" and "catpages". etcupdate -a has some kinks and may be we should concentrate on fixing those instead? -uwe
Re: CVS commit: src/etc
This should definitely be a post-install fix. -- thorpej Sent from my iPhone. > On Jul 21, 2018, at 9:58 AM, Thomas Klausner wrote: > > Is this something that we should let postinstall fix? > Or what is the upgrade strategy for the users not reading source-changes? > Thomas > >> On Sat, Jul 21, 2018 at 07:46:57AM +, Maxime Villard wrote: >> Module Name:src >> Committed By:maxv >> Date:Sat Jul 21 07:46:56 UTC 2018 >> >> Modified Files: >>src/etc: MAKEDEV.tmpl >> >> Log Message: >> Create /dev/ksyms as "440 $g_kmem". This prevents unprivileged users from >> reading the kernel symbols. Discussed in January 2018 on tech-kern@, >> reported by maya@, tested by tih@. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.190 -r1.191 src/etc/MAKEDEV.tmpl >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> > >> Modified files: >> >> Index: src/etc/MAKEDEV.tmpl >> diff -u src/etc/MAKEDEV.tmpl:1.190 src/etc/MAKEDEV.tmpl:1.191 >> --- src/etc/MAKEDEV.tmpl:1.190Sun May 20 14:08:33 2018 >> +++ src/etc/MAKEDEV.tmplSat Jul 21 07:46:56 2018 >> @@ -1,5 +1,5 @@ >> #!/bin/sh - >> -#$NetBSD: MAKEDEV.tmpl,v 1.190 2018/05/20 14:08:33 thorpej Exp $ >> +#$NetBSD: MAKEDEV.tmpl,v 1.191 2018/07/21 07:46:56 maxv Exp $ >> # >> # Copyright (c) 2003,2007,2008 The NetBSD Foundation, Inc. >> # All rights reserved. >> @@ -940,7 +940,7 @@ std) >>mkdevfullc %mem_chr% 11666 >>mkdevzeroc %mem_chr% 12666 >>mkdevklogc %log_chr% 0600 >> -mkdevksymsc %ksyms_chr% 0 444 >> +mkdevksymsc %ksyms_chr% 0 440 $g_kmem >>mkdevrandomc %rnd_chr% 0444 >>mkdevurandomc %rnd_chr% 1644 >>if ! $fdesc_mounted; then >> >
Re: CVS commit: src/etc
Is this something that we should let postinstall fix? Or what is the upgrade strategy for the users not reading source-changes? Thomas On Sat, Jul 21, 2018 at 07:46:57AM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sat Jul 21 07:46:56 UTC 2018 > > Modified Files: > src/etc: MAKEDEV.tmpl > > Log Message: > Create /dev/ksyms as "440 $g_kmem". This prevents unprivileged users from > reading the kernel symbols. Discussed in January 2018 on tech-kern@, > reported by maya@, tested by tih@. > > > To generate a diff of this commit: > cvs rdiff -u -r1.190 -r1.191 src/etc/MAKEDEV.tmpl > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/etc/MAKEDEV.tmpl > diff -u src/etc/MAKEDEV.tmpl:1.190 src/etc/MAKEDEV.tmpl:1.191 > --- src/etc/MAKEDEV.tmpl:1.190Sun May 20 14:08:33 2018 > +++ src/etc/MAKEDEV.tmpl Sat Jul 21 07:46:56 2018 > @@ -1,5 +1,5 @@ > #!/bin/sh - > -#$NetBSD: MAKEDEV.tmpl,v 1.190 2018/05/20 14:08:33 thorpej Exp $ > +#$NetBSD: MAKEDEV.tmpl,v 1.191 2018/07/21 07:46:56 maxv Exp $ > # > # Copyright (c) 2003,2007,2008 The NetBSD Foundation, Inc. > # All rights reserved. > @@ -940,7 +940,7 @@ std) > mkdev fullc %mem_chr% 11 666 > mkdev zeroc %mem_chr% 12 666 > mkdev klogc %log_chr% 0 600 > - mkdev ksyms c %ksyms_chr% 0 444 > + mkdev ksyms c %ksyms_chr% 0 440 $g_kmem > mkdev random c %rnd_chr% 0 444 > mkdev urandom c %rnd_chr% 1 644 > if ! $fdesc_mounted; then >
Re: CVS commit: src/sys/arch/xen/xen
Date:Sat, 30 Jun 2018 20:53:30 + From:"Robert Elz" Message-ID: <20180630205330.99dd8f...@cvs.netbsd.org> | Modified Files: | src/sys/arch/xen/xen: xen_machdep.c | | Log Message: | Build fix bandaid. | | This allows the builds including XEN to complete, but XEN kernels | built from these sources (at least, DomU) do not boot successfully. Note that while 1.17 of xem_machdep.c did break the build (compile testing at least before committing really is a good ideas) it was not that that broke the system - after fixing the build and having iit fail top boot, I reverted it to 1.16 and tried again, still no boot (and I couldn't see how those changes could affect booting. If smeone else can't guess what may have broken it, I wii start hunting in a day or two. kre
Re: pool_grow hangs (Re: CVS commit: src/sys)
On Fri, 29 Dec 2017 16:40:52 + co...@sdf.org wrote: > On Fri, Dec 29, 2017 at 03:41:42PM +0100, Tobias Nygren wrote: > > The machine has survived for 30+ minutes where it previously hung after > > just 20 seconds. > > Do you mean "30+ minutes so far" or does it still hang somewhere? where? No, I did not manage to break it yet.
Re: pool_grow hangs (Re: CVS commit: src/sys)
On Fri, Dec 29, 2017 at 03:41:42PM +0100, Tobias Nygren wrote: > The machine has survived for 30+ minutes where it previously hung after > just 20 seconds. Do you mean "30+ minutes so far" or does it still hang somewhere? where?
Re: pool_grow hangs (Re: CVS commit: src/sys)
> Meanwhile another process, waiting for the grower to finish, is > spinning forever at 100% doing the mutex_exit/mutex_enter/ERESTART > thing on the same pool. It looks to me like the grower never actually > gets scheduled to run. The attached diff works around the problem by not releasing the lock during allocation in the PR_NOWAIT case. I don't know if doing it that way could have any negative side effects? The machine has survived for 30+ minutes where it previously hung after just 20 seconds. Kind regards, -Tobias Index: subr_pool.c === RCS file: /cvsroot/src/sys/kern/subr_pool.c,v retrieving revision 1.219 diff -u -r1.219 subr_pool.c --- subr_pool.c 16 Dec 2017 03:13:29 - 1.219 +++ subr_pool.c 29 Dec 2017 14:33:40 - @@ -1091,7 +1091,9 @@ if ((flags & PR_WAITOK) == 0) pp->pr_flags |= PR_GROWINGNOWAIT; - mutex_exit(&pp->pr_lock); + if (flags & PR_WAITOK) + mutex_exit(&pp->pr_lock); + char *cp = pool_allocator_alloc(pp, flags); if (__predict_false(cp == NULL)) goto out; @@ -1102,7 +1104,8 @@ goto out; } - mutex_enter(&pp->pr_lock); + if (flags & PR_WAITOK) + mutex_enter(&pp->pr_lock); pool_prime_page(pp, cp, ph); pp->pr_npagealloc++; KASSERT(pp->pr_flags & PR_GROWING); @@ -1115,8 +1118,9 @@ return 0; out: KASSERT(pp->pr_flags & PR_GROWING); + if (flags & PR_WAITOK) + mutex_enter(&pp->pr_lock); pp->pr_flags &= ~(PR_GROWING|PR_GROWINGNOWAIT); - mutex_enter(&pp->pr_lock); return ENOMEM; }
pool_grow hangs (Re: CVS commit: src/sys)
On Sat, 16 Dec 2017 03:13:29 + matthew green wrote: > Module Name: src > Committed By: mrg > Date: Sat Dec 16 03:13:29 UTC 2017 > > Modified Files: > src/sys/kern: subr_pool.c > src/sys/sys: pool.h > > Log Message: > hopefully workaround the irregularly "fork fails in init" problem. > > if a pool is growing, and the grower is PR_NOWAIT, mark this. > if another caller wants to grow the pool and is also PR_NOWAIT, > busy-wait for the original caller, which should either succeed > or hard-fail fairly quickly. > > implement the busy-wait by unlocking and relocking this pools > mutex and returning ERESTART. other methods (such as having > the caller do this) were significantly more code and this hack > is fairly localised. > > ok chs@ riastradh@ Hi! I have an easily reproducable system hang that I believe originates from this change. It can be triggered by doing lots of block and network i/o (like 3 multiple rsyncs) on a uniprocessor system running under Linux KVM. Basically what happens is that for unknown reasons the PR_NOWAIT grower blocks forever when it tries to reaquire the pool lock to do pool_prime_page() in pool_grow(). Meanwhile another process, waiting for the grower to finish, is spinning forever at 100% doing the mutex_exit/mutex_enter/ERESTART thing on the same pool. It looks to me like the grower never actually gets scheduled to run. Also, although it doesn't fix the issue, this pr_flags modification looks like it should be moved to after the mutex is acquired: pp->pr_flags &= ~(PR_GROWING|PR_GROWINGNOWAIT); mutex_enter(&pp->pr_lock); Kind regards, -Tobias
Re: CVS commit: src
On 08/09/17 23:06, Swift Griggs wrote: On Wed, 9 Aug 2017, Brian Buhrow wrote: SCO was pretty much pure SVR3, so noting that COMPAT_IBCS2 implements SVR3 functionality is pretty much correct. Is anyone still using it? I used it back-in-the day. I'm probably running some of the oldest Unix variants and versions you'll run across. Also, where I work we support legacy Unix platforms and we don't have any more SCO clients. In my view "it's dead Jim". If we want to emulate a platform for Oracle, I'd think the method dejour today would be Linux emulation. Nowadays, I find that Unixware is a lot more interesting (free VxVM anyone?) than SCO ever was. As you say, it was pretty much straight SysV without many cool bells or whistles. I also find SCO super-annoying now because it's so disagreeable about it's licenses. It's tough to be more annoying than Tru64 about licenses, but SCO manages. I know IT shouldn't be personal, but after we all watched their public demise then Zombie SCO suing every FOSS company they could left ashes in my mouth, personally. I'm not anyone important in TNF, but I am a longtime user and user of other platforms (SCO included) and my vote is to kill it and reduce the kernel code size. :-) I think the real question is, is someone still using old iBCS closed source software and relying on it. regards, chris
Re: CVS commit: src
I've heard of how some legacy systems powering the world. Like Melbourne's train network which runs on Windows XP ... emulating a PDP-11. There's certainly a real world need for it. But if someone wants to do things like that with NetBSD, it can't be a default and he needs to be proactive about handling bugs. Now we are at a point people who don't see a benefit to it are fixing bugs, and that is a point where it should become a deletion candidate, not a disable candidate.
Re: CVS commit: src
Someone recently tried pkgsrc on SCO OpenServer5. I'm pretty new so I haven't heard of these operating systems before. It was an interesting experience. pkgsrc/bootstrap/README.OpenServer5 has the instructions. You start with the all-shiny GCC 2.99.3, patched. then use it to build a patched GCC 4.2, which is the last version to support SCO/x86. (GCC 4.8 is almost the minimum version for an acceptable pkgsrc experience, as C++11 is pretty widespread) After the GCC hurdle, be sure to replace rm with a version that supports deleting files over 2GB. when I looked up what is wrong with it, I found this remarkable response, suggesting that for the sake of compatibility, it shouldn't be fixed, or anything, ever. http://lists.celestial.com/pipermail/sco-misc/2007-September/010474.html (Spoiler alert from the next message: it wasn't because of compat) So, it's not just SCO, but that was my first impression of the system. I find it really hard to believe this system can run anything currently useful.
Re: CVS commit: src
On Wed, 9 Aug 2017, Brian Buhrow wrote: SCO was pretty much pure SVR3, so noting that COMPAT_IBCS2 implements SVR3 functionality is pretty much correct. Is anyone still using it? I used it back-in-the day. I'm probably running some of the oldest Unix variants and versions you'll run across. Also, where I work we support legacy Unix platforms and we don't have any more SCO clients. In my view "it's dead Jim". If we want to emulate a platform for Oracle, I'd think the method dejour today would be Linux emulation. Nowadays, I find that Unixware is a lot more interesting (free VxVM anyone?) than SCO ever was. As you say, it was pretty much straight SysV without many cool bells or whistles. I also find SCO super-annoying now because it's so disagreeable about it's licenses. It's tough to be more annoying than Tru64 about licenses, but SCO manages. I know IT shouldn't be personal, but after we all watched their public demise then Zombie SCO suing every FOSS company they could left ashes in my mouth, personally. I'm not anyone important in TNF, but I am a longtime user and user of other platforms (SCO included) and my vote is to kill it and reduce the kernel code size. :-) -Swift
Re: CVS commit: src
hello. COMPAT_IBCS2 implements the functionality necessary to run SCO OS/5 binary files. I haven't used this in a long while, but it was good enough to run a whole set of Oracle tools better than they ran under the native OS.(I used it with great success under NetBSD-1.4). I realize that's a long time ago, but SCO hasn't changed their binary format for this platform in forever and there used to be a lot of closed source software that ran under that platform. SCO was pretty much pure SVR3, so noting that COMPAT_IBCS2 implements SVR3 functionality is pretty much correct. Is anyone still using it? -Brian
Re: CVS commit: src
On Wed, Aug 09, 2017 at 06:45:30PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Wed Aug 9 18:45:30 UTC 2017 > > Modified Files: > src/distrib/sets/lists/modules: md.i386 > src/sys/arch/i386/conf: ALL GENERIC GENERIC_TINY INSTALL_FLOPPY > INSTALL_TINY MODULAR NET4501 XEN3_DOM0 XEN3_DOMU files.i386 > src/sys/arch/i386/i386: compat_16_machdep.c > src/sys/modules/compat_ibcs2: Makefile > Removed Files: > src/sys/arch/i386/i386: ibcs2_machdep.c ibcs2_sigcode.S ibcs2_syscall.c > > Log Message: > Remove compat_ibcs2 from i386. After a discussion on port-vax, it turns > out that compat_ibcs2 does not implement the iBCS2 standard - which is > x86-specific - but rather SVR3. Our real iBCS2 implementation was a > mixture of compat_ibcs2 and compat_svr4, and was only partial. Keeping > support for this in i386 is totally irrelevant today. I also asked on > port-i386 but didn't wait long. > > The main issue is that compat_ibcs2 should have been called compat_svr3. Can someone who knows enough about this stuff please update compat_ibcs2(8)? It doesn't mention SVR3 at all right now. Thomas
Re: CVS commit: src/sys/external/bsd/drm2
Hi, 2017-03-02 7:59 GMT+09:00 Yorick Hardy : > On 2017-03-01, Martin Husemann wrote: >> On Wed, Mar 01, 2017 at 06:55:24PM +0900, Kimihiro Nonaka wrote: >> > Updated the patch. >> >> Still works fine for me! >> >> Martin > > Also works fine for me on i386+intel and amd64+radeon. > > Thanks! I've commited it. Thank you for testing! Regards, -- Kimihiro Nonaka
Re: CVS commit: src/sys/external/bsd/drm2
On 2017-03-01, Martin Husemann wrote: > On Wed, Mar 01, 2017 at 06:55:24PM +0900, Kimihiro Nonaka wrote: > > Updated the patch. > > Still works fine for me! > > Martin Also works fine for me on i386+intel and amd64+radeon. Thanks! -- Kind regards, Yorick Hardy
Re: CVS commit: src/sys/external/bsd/drm2
On Wed, Mar 01, 2017 at 06:55:24PM +0900, Kimihiro Nonaka wrote: > Updated the patch. Still works fine for me! Martin
Re: CVS commit: src/sys/external/bsd/drm2
Hi,
2017-03-01 13:30 GMT+09:00 Kimihiro Nonaka :
> 2017-03-01 3:21 GMT+09:00 Yorick Hardy :
>
>> It is not obvious to me why the MSI changes were problematic.
>> Do you have any ideas what went wrong?
>
> It seem necessary to implement pci_enable_msi() and pci_disable_msi().
> I tried again to write a new patch.
> Could you try it?
Updated the patch.
Regards,
--
Kimihiro Nonaka
diff --git
a/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
b/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
index 860690054a7..31282f88f49 100644
---
a/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
+++
b/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
@@ -30,10 +30,13 @@ __KERNEL_RCSID(0, "$NetBSD: nouveau_subdev_mc_base.c,v 1.5
2015/10/22 23:17:08 j
#include
#include
-#if defined(__NetBSD__) && defined(__arm__)
+#if defined(__NetBSD__)
+#include
+#if defined(__arm__)
/* XXX nouveau platform kludge */
#include
#endif
+#endif /* __NetBSD__ */
static inline u32
nouveau_mc_intr_mask(struct nouveau_mc *pmc)
@@ -114,7 +117,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_mc *pmc = (void *)object;
#if defined(__NetBSD__)
if (nv_device_is_pci(device)) {
- pci_intr_disestablish(device->pdev->pd_pa.pa_pc,
pmc->irq_cookie);
+ struct drm_device *dev = pci_get_drvdata(device->pdev);
+ (*dev->driver->bus->irq_uninstall)(dev, pmc->irq_cookie);
#if defined(__arm__)
} else {
intr_disestablish(pmc->irq_cookie);
@@ -175,16 +179,12 @@ nouveau_mc_create_(struct nouveau_object *parent, struct
nouveau_object *engine,
#if defined(__NetBSD__)
if (nv_device_is_pci(device)) {
- const pci_chipset_tag_t pc = device->pdev->pd_pa.pa_pc;
- pci_intr_handle_t ih;
-
- if (pci_intr_map(&device->pdev->pd_pa, &ih))
- return -EIO;
-
- pmc->irq_cookie = pci_intr_establish(pc, ih, IPL_VM,
- &nouveau_mc_intr, pmc);
- if (pmc->irq_cookie == NULL)
- return -EIO;
+ struct drm_device *dev = pci_get_drvdata(device->pdev);
+ ret = (*dev->driver->bus->irq_install)(dev, nouveau_mc_intr,
+ IRQF_SHARED, "nouveau", pmc,
+ (struct drm_bus_irq_cookie **)&pmc->irq_cookie);
+ if (ret < 0)
+ return ret;
#if defined (__arm__)
} else {
pmc->irq_cookie = intr_establish(TEGRA_INTR_GPU,
diff --git a/sys/external/bsd/drm2/include/linux/pci.h
b/sys/external/bsd/drm2/include/linux/pci.h
index d7d153deb3d..d9c6eb38a8f 100644
--- a/sys/external/bsd/drm2/include/linux/pci.h
+++ b/sys/external/bsd/drm2/include/linux/pci.h
@@ -155,6 +155,7 @@ struct pci_dev {
uint8_t revision;
uint32_tclass;
boolmsi_enabled;
+ pci_intr_handle_t *intr_handles;
};
static inline device_t
@@ -289,19 +290,28 @@ pci_write_config_byte(struct pci_dev *pdev, int reg,
uint8_t value)
return 0;
}
-/*
- * XXX pci msi
- */
static inline int
pci_enable_msi(struct pci_dev *pdev)
{
- return -ENOSYS;
+ const struct pci_attach_args *const pa = &pdev->pd_pa;
+
+ if (pci_msi_alloc_exact(pa, &pdev->intr_handles, 1))
+ return -EINVAL;
+
+ pdev->msi_enabled = 1;
+ return 0;
}
static inline void
pci_disable_msi(struct pci_dev *pdev __unused)
{
- KASSERT(pdev->msi_enabled);
+ const struct pci_attach_args *const pa = &pdev->pd_pa;
+
+ if (pdev->intr_handles != NULL) {
+ pci_intr_release(pa->pa_pc, pdev->intr_handles, 1);
+ pdev->intr_handles = NULL;
+ }
+ pdev->msi_enabled = 0;
}
static inline void
diff --git a/sys/external/bsd/drm2/pci/drm_pci.c
b/sys/external/bsd/drm2/pci/drm_pci.c
index ddfa79f445f..caa1bd6694b 100644
--- a/sys/external/bsd/drm2/pci/drm_pci.c
+++ b/sys/external/bsd/drm2/pci/drm_pci.c
@@ -40,6 +40,11 @@ __KERNEL_RCSID(0, "$NetBSD: drm_pci.c,v 1.15 2017/02/27
23:52:05 nonaka Exp $");
#include
+struct drm_bus_irq_cookie {
+ pci_intr_handle_t *intr_handles;
+ void *ih_cookie;
+};
+
static int drm_pci_get_irq(struct drm_device *);
static int drm_pci_irq_install(struct drm_device *,
irqreturn_t (*)(void *), int, const char *, void *,
@@ -228,40 +233,48 @@ drm_pci_get_irq(struct drm_device *dev)
static int
drm_pci_irq_install(struct drm_device *dev, irqreturn_t (*handler)(void *),
-int flags, const char *name, void *arg,
-struct drm_bus_irq_cookie **cookiep)
+int flags, const char *name, void *arg, struct drm_bus_irq_cookie
**cookiep)
{
const struct pci_attach_args *const pa = drm_pci_attach_args(dev);
- pci_intr_hand
Re: CVS commit: src/sys/external/bsd/drm2
On Wed, Mar 01, 2017 at 01:30:50PM +0900, Kimihiro Nonaka wrote: > Hi, > > 2017-03-01 3:21 GMT+09:00 Yorick Hardy : > > > It is not obvious to me why the MSI changes were problematic. > > Do you have any ideas what went wrong? > > It seem necessary to implement pci_enable_msi() and pci_disable_msi(). > I tried again to write a new patch. > Could you try it? This works fine on my machine where the previous version slowed down X a lot. Yorick? Martin
Re: CVS commit: src/sys/external/bsd/drm2
Hi,
2017-03-01 3:21 GMT+09:00 Yorick Hardy :
> It is not obvious to me why the MSI changes were problematic.
> Do you have any ideas what went wrong?
It seem necessary to implement pci_enable_msi() and pci_disable_msi().
I tried again to write a new patch.
Could you try it?
Regards,
--
Kimihiro Nonaka
diff --git a/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/mc.h
b/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/mc.h
index d914ed8827a..c1e8bd61af0 100644
--- a/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/mc.h
+++ b/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/mc.h
@@ -15,6 +15,7 @@ struct nouveau_mc {
unsigned int irq;
#ifdef __NetBSD__
void *irq_cookie;
+ pci_intr_handle_t *intr_handles;
#endif
};
diff --git
a/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
b/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
index 860690054a7..9371b127c55 100644
---
a/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
+++
b/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c
@@ -114,7 +114,9 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_mc *pmc = (void *)object;
#if defined(__NetBSD__)
if (nv_device_is_pci(device)) {
- pci_intr_disestablish(device->pdev->pd_pa.pa_pc,
pmc->irq_cookie);
+ const struct pci_attach_args *pa = &device->pdev->pd_pa;
+ pci_intr_disestablish(pa->pa_pc, pmc->irq_cookie);
+ pci_intr_release(pa->pa_pc, pmc->intr_handles, 1);
#if defined(__arm__)
} else {
intr_disestablish(pmc->irq_cookie);
@@ -175,16 +177,33 @@ nouveau_mc_create_(struct nouveau_object *parent, struct
nouveau_object *engine,
#if defined(__NetBSD__)
if (nv_device_is_pci(device)) {
- const pci_chipset_tag_t pc = device->pdev->pd_pa.pa_pc;
- pci_intr_handle_t ih;
-
- if (pci_intr_map(&device->pdev->pd_pa, &ih))
+ const struct pci_attach_args *pa = &device->pdev->pd_pa;
+ const pci_chipset_tag_t pc = pa->pa_pc;
+ char intrbuf[PCI_INTRSTR_LEN];
+ const char *intrstr;
+ int counts[PCI_INTR_TYPE_MSI + 1];
+
+ counts[PCI_INTR_TYPE_INTX] = pmc->use_msi ? 0 : 1;
+ counts[PCI_INTR_TYPE_MSI] = pmc->use_msi ? 1 : 0;
+ if (pci_intr_alloc(pa, &pmc->intr_handles, counts,
+ PCI_INTR_TYPE_MSI))
return -EIO;
- pmc->irq_cookie = pci_intr_establish(pc, ih, IPL_VM,
- &nouveau_mc_intr, pmc);
- if (pmc->irq_cookie == NULL)
+ intrstr = pci_intr_string(pc, pmc->intr_handles[0], intrbuf,
+ sizeof(intrbuf));
+ pmc->irq_cookie = pci_intr_establish_xname(pc,
+ pmc->intr_handles[0], IPL_VM, nouveau_mc_intr, pmc,
+ "nouveau");
+ if (pmc->irq_cookie == NULL) {
+ aprint_error_dev(device->pdev->pd_dev,
+ "couldn't establish interrupt at %s (nouveau)\n",
+ intrstr);
+ pci_intr_release(pa->pa_pc, pmc->intr_handles, 1);
return -EIO;
+ }
+
+ aprint_normal_dev(device->pdev->pd_dev,
+ "interrupting at %s (nouveau)\n", intrstr);
#if defined (__arm__)
} else {
pmc->irq_cookie = intr_establish(TEGRA_INTR_GPU,
diff --git a/sys/external/bsd/drm2/dist/include/drm/drmP.h
b/sys/external/bsd/drm2/dist/include/drm/drmP.h
index d4b8ecb5fd7..b25b525ddcf 100644
--- a/sys/external/bsd/drm2/dist/include/drm/drmP.h
+++ b/sys/external/bsd/drm2/dist/include/drm/drmP.h
@@ -1268,6 +1268,7 @@ struct drm_device {
bool irq_enabled; /**< True if irq handler is enabled */
#ifdef __NetBSD__
struct drm_bus_irq_cookie *irq_cookie;
+ pci_intr_handle_t *intr_handles;
#endif
__volatile__ long context_flag; /**< Context swapping flag */
int last_context; /**< Last current context */
diff --git a/sys/external/bsd/drm2/include/linux/pci.h
b/sys/external/bsd/drm2/include/linux/pci.h
index d7d153deb3d..c7b4aaf170e 100644
--- a/sys/external/bsd/drm2/include/linux/pci.h
+++ b/sys/external/bsd/drm2/include/linux/pci.h
@@ -289,19 +289,24 @@ pci_write_config_byte(struct pci_dev *pdev, int reg,
uint8_t value)
return 0;
}
-/*
- * XXX pci msi
- */
static inline int
pci_enable_msi(struct pci_dev *pdev)
{
- return -ENOSYS;
+ const struct pci_attach_args *const pa = &pdev->pd_pa;
+ pci_intr_handle_t *ihps;
+
+ if (pci_msi_alloc_exact(pa, &ihps, 1))
+ return -EINVAL;
+
+ pci_intr_release(pa->pa_pc, ihps, 1);
+ pdev->msi_enabled = 1;
+
Re: CVS commit: src/sys/external/bsd/drm2
On 2017-02-28, Kimihiro Nonaka wrote: > Hi, > > 2017-02-28 4:10 GMT+09:00 Martin Husemann : > > > On Mon, Feb 27, 2017 at 07:39:49PM +0100, Martin Husemann wrote: > >> On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote: > >> > Is anyone else experiencing GPU hangs since revision 1.14 > >> > of src/sys/external/bsd/drm2/pci/drm_pci.c ? > >> > >> Thanks for the hint, I'm testing if it is the cause for > >> > >> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51997 > >> > >> and will report back ASAP... > > > > Yes, that seems to be the case. > > I've reverted. Thank you! It is not obvious to me why the MSI changes were problematic. Do you have any ideas what went wrong? -- Kind regards, Yorick Hardy
Re: CVS commit: src/sys/external/bsd/drm2
Hi, 2017-02-28 4:10 GMT+09:00 Martin Husemann : > On Mon, Feb 27, 2017 at 07:39:49PM +0100, Martin Husemann wrote: >> On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote: >> > Is anyone else experiencing GPU hangs since revision 1.14 >> > of src/sys/external/bsd/drm2/pci/drm_pci.c ? >> >> Thanks for the hint, I'm testing if it is the cause for >> >> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51997 >> >> and will report back ASAP... > > Yes, that seems to be the case. I've reverted. Regards, -- Kimihiro Nonaka
Re: CVS commit: src/sys/external/bsd/drm2
On Mon, Feb 27, 2017 at 07:39:49PM +0100, Martin Husemann wrote: > On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote: > > Is anyone else experiencing GPU hangs since revision 1.14 > > of src/sys/external/bsd/drm2/pci/drm_pci.c ? > > Thanks for the hint, I'm testing if it is the cause for > > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51997 > > and will report back ASAP... Yes, that seems to be the case. Martin
Re: CVS commit: src/sys/external/bsd/drm2
On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote: > Is anyone else experiencing GPU hangs since revision 1.14 > of src/sys/external/bsd/drm2/pci/drm_pci.c ? Thanks for the hint, I'm testing if it is the cause for http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51997 and will report back ASAP... Martin
Re: CVS commit: src/sys/external/bsd/drm2
Dear list, On 2017-02-21, NONAKA Kimihiro wrote: > Module Name: src > Committed By: nonaka > Date: Tue Feb 21 14:19:40 UTC 2017 > > Modified Files: > src/sys/external/bsd/drm2/dist/include/drm: drmP.h > src/sys/external/bsd/drm2/pci: drm_pci.c > > Log Message: > drmkms_pci: use MSI if available. > > > To generate a diff of this commit: > cvs rdiff -u -r1.11 -r1.12 src/sys/external/bsd/drm2/dist/include/drm/drmP.h > cvs rdiff -u -r1.13 -r1.14 src/sys/external/bsd/drm2/pci/drm_pci.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. Is anyone else experiencing GPU hangs since revision 1.14 of src/sys/external/bsd/drm2/pci/drm_pci.c ? Going back to 1.13 makes opengl and Xv usable again for me. Here is the dmesg of the affected machine: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.62 (YORICK.i386) #0: Mon Feb 27 00:24:44 SAST 2017 root@HOME:/root/build.i386.local/obj/sys/arch/i386/compile/YORICK.i386 total memory = 1013 MB avail memory = 983 MB rnd: seeded with 128 bits timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done RTC BIOS diagnostic error 0x80 timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 LG Electronics X130-L.ASW6Z (05) mainbus0 (root) ACPI: RSDP 0x000FE020 24 (v02 LGE ) ACPI: XSDT 0x3F6FE120 64 (v01 LGELGPC 0001 0113) ACPI: FACP 0x3F6FC000 F4 (v04 LGELGPC 0001 MSFT 0113) ACPI: DSDT 0x3F6F 007068 (v01 LGELGPC 0001 MSFT 0113) ACPI: FACS 0x3F688000 40 ACPI: FACS 0x3F688000 40 ACPI: SSDT 0x3F6FD000 0004C4 (v02 LGELGPC 3000 INTL 20051117) ACPI: HPET 0x3F6FB000 38 (v01 LGELGPC 0001 MSFT 0113) ACPI: APIC 0x3F6FA000 68 (v02 LGELGPC 0001 MSFT 0113) ACPI: MCFG 0x3F6F9000 3C (v01 LGELGPC 0001 MSFT 0113) ACPI: ASF! 0x3F6F8000 A5 (v32 LGELGPC 0001 MSFT 0113) ACPI: SLIC 0x3F6EF000 000176 (v01 LGELGPC 0001 MSFT 0113) ACPI: BOOT 0x3F6EE000 28 (v01 LGELGPC 0001 MSFT 0113) ACPI: Executed 1 blocks of module-level executable AML code ACPI: 2 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 4: pa 0xfec0, version 0x20, 24 pins cpu0 at mainbus0 apid 0 cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz, id 0x106c2 cpu1 at mainbus0 apid 1 cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz, id 0x106c2 acpi0 at mainbus0: Intel ACPICA 20170119 acpi0: X/RSDT: OemId , AslId <,0113> acpi0: MCFG: segment 0, bus 0-255, address 0xe000 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xC2234C84 000239 (v02 LGELGPC 3000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xC2081A04 0001C1 (v02 LGELGPC 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xC20501CC D0 (v02 LGELGPC 3000 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0xC20690AC 83 (v02 LGELGPC 3000 INTL 20051117) acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900 hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000 acpiec0 at acpi0 (EC0, PNP0C09-1) : io 0x62,0x66 acpibut0 at acpi0 (PWRB, PNP0C0C): ACPI Power Button acpibut1 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button acpilid0 at acpi0 (LID0, PNP0C0D): ACPI Lid Switch acpiacad0 at acpi0 (ACAD, ACPI0003): ACPI AC Adapter acpibat0 at acpi0 (BAT0, PNP0C0A-1): ACPI Battery acpibat0: Dynapack LION rechargeable battery acpibat0: granularity: low->warn 0.010 Ah, warn->full 0.025 Ah SYSR (PNP0C02) at acpi0 not configured FPU (PNP0C04) at acpi0 not configured attimer0 at acpi0 (TIMR, PNP0100): io 0x40-0x43,0x50-0x53 FWHD (INT0800) at acpi0 not configured pckbc0 at acpi0 (KBC, PNP0303) (kbd port): io 0x60,0x64 irq 1 pckbc1 at acpi0 (MOUE, SYN1304) (aux port): irq 12 acpiwmi0 at acpi0 (MAP1, PNP0C14-0): ACPI WMI Interface acpiwmibus at acpiwmi0 not configured acpivga0 at acpi0 (OVGA): ACPI Display Adapter acpiout0 at acpivga0 (CRT1, 0x0100): ACPI Display Output Device acpiout1 at acpivga0 (DTV1, 0x0240): ACPI Display Output Device acpiout2 at acpivga0 (LCD, 0x0410): ACPI Display Output Device acpiout2: brightness levels: [10,20,30,40,50,65,80,90,100] acpiout3 at acpivga0 (DTV2, 0x0004): ACPI Display Output Device acpiout4 at acpivga0 (DFP2, 0x0005): ACPI Display Out
Re: CVS commit: src/sys
In article , bch wrote: > > >This is still faulting for me after building both kernel and modules, and >commenting-out ipf pseudo-device and associated IPF* configs from GENERIC >(amd64) config... > > >Transcribed (rough) backtrace: > >breakpoint() at netbsd:breakpoint+0x5 >vpanic() at netbsd: vpanic+0x140 >ch_voltag_covert_in() at ... >pfil_add_hook() at ... >Ipfattach() at ipl:ipfattach+0x124 >ipf_ipf_ioctl() at ipl:ipf_ipf_ioctl+0x692 >ipfioctl() at ipl:ipfioctl... >cdev_ioctl() at ... > Is that the same panic as before? I can't reproduce it with current as of a few minutes ago. christos
Re: CVS commit: src/sys
On Dec 27, 2016 14:18, "bch" wrote: On Dec 27, 2016 05:50, "Christos Zoulas" wrote: On Dec 26, 9:28pm, brad.har...@gmail.com (bch) wrote: -- Subject: Re: CVS commit: src/sys | On Dec 26, 2016 15:21, "Christos Zoulas" wrote: | | Module Name:src | Committed By: christos | Date: Mon Dec 26 23:21:49 UTC 2016 | | Modified Files: | src/sys/dist/pf/net: pf_if.c | src/sys/external/bsd/ipf/netinet: ip_fil_netbsd.c | src/sys/net: if.c if_pppoe.c if_spppsubr.c pfil.c pfil.h | | Log Message: | pfil(9) improvements to handle address changes: | | | My kernel with these changes is faulting (transcribed): | | Panic: kernel diagnostic assertion "(flags &~PFIL_ALL)==0" failed: file | "/usr/src/sys/net/pfil.c", line 187 | Fatal breakpoint trap in supervisor mode | ... | Stopped in PID 78.1 (ipf) at NetBSD: breakpoint+0x5: leave | | Add: | PFIL_IFADDR call on interface reconfig (mbuf is ioctl #) | PFIL_IFNET call on interface attach/detach (mbuf is PFIL_IFNET_*) | | from rmind@ Should be fixed now! This is still faulting for me after building both kernel and modules, and commenting-out ipf pseudo-device and associated IPF* configs from GENERIC (amd64) config... Transcribed (rough) backtrace: breakpoint() at netbsd:breakpoint+0x5 vpanic() at netbsd: vpanic+0x140 ch_voltag_covert_in() at ... pfil_add_hook() at ... Ipfattach() at ipl:ipfattach+0x124 ipf_ipf_ioctl() at ipl:ipf_ipf_ioctl+0x692 ipfioctl() at ipl:ipfioctl... cdev_ioctl() at ... christos
Re: CVS commit: src/sys
On Dec 27, 2016 05:50, "Christos Zoulas" wrote: On Dec 26, 9:28pm, brad.har...@gmail.com (bch) wrote: -- Subject: Re: CVS commit: src/sys | On Dec 26, 2016 15:21, "Christos Zoulas" wrote: | | Module Name:src | Committed By: christos | Date: Mon Dec 26 23:21:49 UTC 2016 | | Modified Files: | src/sys/dist/pf/net: pf_if.c | src/sys/external/bsd/ipf/netinet: ip_fil_netbsd.c | src/sys/net: if.c if_pppoe.c if_spppsubr.c pfil.c pfil.h | | Log Message: | pfil(9) improvements to handle address changes: | | | My kernel with these changes is faulting (transcribed): | | Panic: kernel diagnostic assertion "(flags &~PFIL_ALL)==0" failed: file | "/usr/src/sys/net/pfil.c", line 187 | Fatal breakpoint trap in supervisor mode | ... | Stopped in PID 78.1 (ipf) at NetBSD: breakpoint+0x5: leave | | Add: | PFIL_IFADDR call on interface reconfig (mbuf is ioctl #) | PFIL_IFNET call on interface attach/detach (mbuf is PFIL_IFNET_*) | | from rmind@ Should be fixed now! This is still faulting for me after building both kernel and modules, and commenting-out ipf pseudo-device and associated IPF* configs from GENERIC (amd64) config... christos
Re: CVS commit: src/sys
On Dec 26, 9:28pm, brad.har...@gmail.com (bch) wrote: -- Subject: Re: CVS commit: src/sys | On Dec 26, 2016 15:21, "Christos Zoulas" wrote: | | Module Name:src | Committed By: christos | Date: Mon Dec 26 23:21:49 UTC 2016 | | Modified Files: | src/sys/dist/pf/net: pf_if.c | src/sys/external/bsd/ipf/netinet: ip_fil_netbsd.c | src/sys/net: if.c if_pppoe.c if_spppsubr.c pfil.c pfil.h | | Log Message: | pfil(9) improvements to handle address changes: | | | My kernel with these changes is faulting (transcribed): | | Panic: kernel diagnostic assertion "(flags &~PFIL_ALL)==0" failed: file | "/usr/src/sys/net/pfil.c", line 187 | Fatal breakpoint trap in supervisor mode | ... | Stopped in PID 78.1 (ipf) at NetBSD: breakpoint+0x5: leave | | Add: | PFIL_IFADDR call on interface reconfig (mbuf is ioctl #) | PFIL_IFNET call on interface attach/detach (mbuf is PFIL_IFNET_*) | | from rmind@ Should be fixed now! christos
Re: CVS commit: src/sys
On Dec 26, 2016 15:21, "Christos Zoulas" wrote: Module Name:src Committed By: christos Date: Mon Dec 26 23:21:49 UTC 2016 Modified Files: src/sys/dist/pf/net: pf_if.c src/sys/external/bsd/ipf/netinet: ip_fil_netbsd.c src/sys/net: if.c if_pppoe.c if_spppsubr.c pfil.c pfil.h Log Message: pfil(9) improvements to handle address changes: My kernel with these changes is faulting (transcribed): Panic: kernel diagnostic assertion "(flags &~PFIL_ALL)==0" failed: file "/usr/src/sys/net/pfil.c", line 187 Fatal breakpoint trap in supervisor mode ... Stopped in PID 78.1 (ipf) at NetBSD: breakpoint+0x5: leave Add: PFIL_IFADDR call on interface reconfig (mbuf is ioctl #) PFIL_IFNET call on interface attach/detach (mbuf is PFIL_IFNET_*) from rmind@ To generate a diff of this commit: cvs rdiff -u -r1.31 -r1.32 src/sys/dist/pf/net/pf_if.c cvs rdiff -u -r1.19 -r1.20 src/sys/external/bsd/ipf/netinet/ip_fil_netbsd.c cvs rdiff -u -r1.368 -r1.369 src/sys/net/if.c cvs rdiff -u -r1.121 -r1.122 src/sys/net/if_pppoe.c cvs rdiff -u -r1.163 -r1.164 src/sys/net/if_spppsubr.c cvs rdiff -u -r1.28 -r1.29 src/sys/net/pfil.c cvs rdiff -u -r1.31 -r1.32 src/sys/net/pfil.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch (lapic va change)
Upon further investigation it seems that the lapic va change is not the cause of the hangs I've been seeing. I'm currently looking further to find the real root cause. On Sat, 17 Dec 2016, Maxime Villard wrote: Le 15/12/2016 à 09:21, Paul Goyette a écrit : Module Name:src Committed By: maxv Date: Sun Dec 11 08:31:53 UTC 2016 Modified Files: src/sys/arch/amd64/amd64: machdep.c src/sys/arch/i386/i386: machdep.c src/sys/arch/x86/x86: pmap.c Log Message: Kenter local_apic_va to a fake physical page, because our x86 implementation expects this va to be valid even if no lapic is present; which probably is a bug in itself, but let's just reproduce the old behavior and rehide that bug. This change (and the subsequent fix for the build break) breaks the installation process when running under pkgsrc/emulators/qemu-2.7.0nb1 Booting the install media image gets as far as the end of device auto-configuration, and hangs after reporting the boot device and /path/to/modules. It never gets to starting the init(8) process. Reverting this fix (and the build break fix) restores the ability to finish booting, and actually gets into sysinst. I don't know what the correct fix is, but I think we should revert this commit (at least for amd64, not sure about i386) until it is better understood and can be fixed properly. This problem doesn't seem to be affecting the rel-eng amd64 test-bed, probably because it is likely running an older version of qemu? Given what you say, I would tend to believe that it is not related to lapic. The fix just reproduces the old behavior, the exact same way. The only place where things could go wrong is before the pa is kentered, which is done way before the autoconfiguration. I guess you were running a generic amd64? And I guess this change [1] does not fix the issue? [1] http://mail-index.netbsd.org/source-changes/2016/12/16/msg079925.html !DSPAM:58555bbd239482100721278! +--+--++ | 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 | +--+--++
Re: CVS commit: src/sys/arch (lapic va change)
Le 15/12/2016 à 09:21, Paul Goyette a écrit : >> Module Name:src >> Committed By: maxv >> Date: Sun Dec 11 08:31:53 UTC 2016 >> >> Modified Files: >> src/sys/arch/amd64/amd64: machdep.c >> src/sys/arch/i386/i386: machdep.c >> src/sys/arch/x86/x86: pmap.c >> >> Log Message: >> Kenter local_apic_va to a fake physical page, because our x86 >> implementation expects this va to be valid even if no lapic is >> present; which probably is a bug in itself, but let's just reproduce >> the old behavior and rehide that bug. > > This change (and the subsequent fix for the build break) breaks the > installation process when running under pkgsrc/emulators/qemu-2.7.0nb1 > > Booting the install media image gets as far as the end of device > auto-configuration, and hangs after reporting the boot device and > /path/to/modules. It never gets to starting the init(8) process. > > Reverting this fix (and the build break fix) restores the ability to > finish booting, and actually gets into sysinst. > > I don't know what the correct fix is, but I think we should revert this > commit (at least for amd64, not sure about i386) until it is better > understood and can be fixed properly. > > This problem doesn't seem to be affecting the rel-eng amd64 test-bed, > probably because it is likely running an older version of qemu? Given what you say, I would tend to believe that it is not related to lapic. The fix just reproduces the old behavior, the exact same way. The only place where things could go wrong is before the pa is kentered, which is done way before the autoconfiguration. I guess you were running a generic amd64? And I guess this change [1] does not fix the issue? [1] http://mail-index.netbsd.org/source-changes/2016/12/16/msg079925.html
Re: CVS commit: src/sys/arch (lapic va change)
Module Name:src Committed By: maxv Date: Sun Dec 11 08:31:53 UTC 2016 Modified Files: src/sys/arch/amd64/amd64: machdep.c src/sys/arch/i386/i386: machdep.c src/sys/arch/x86/x86: pmap.c Log Message: Kenter local_apic_va to a fake physical page, because our x86 implementation expects this va to be valid even if no lapic is present; which probably is a bug in itself, but let's just reproduce the old behavior and rehide that bug. This change (and the subsequent fix for the build break) breaks the installation process when running under pkgsrc/emulators/qemu-2.7.0nb1 Booting the install media image gets as far as the end of device auto-configuration, and hangs after reporting the boot device and /path/to/modules. It never gets to starting the init(8) process. Reverting this fix (and the build break fix) restores the ability to finish booting, and actually gets into sysinst. I don't know what the correct fix is, but I think we should revert this commit (at least for amd64, not sure about i386) until it is better understood and can be fixed properly. This problem doesn't seem to be affecting the rel-eng amd64 test-bed, probably because it is likely running an older version of qemu? XXX Note that this is not the only problem with amd64 on -HEAD. The rel-eng test-bed has not had a successful install for several days. It seems to "hang" and time-out while running 'progress cp /usr/mdec/boot /mnt2/boot' command. (My own system, after reverting the lapic changes, hangs at the exact same place.) Perhaps I should start a separate thread for this 2nd issue? +--+--++ | 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 | +--+--++
Re: CVS commit: src/sys
The following commit has broken IPv6 functionality within pkgsrc's
net/openvpn package. Please see PR kern/51301 for details.
Module Name:src
Committed By: ozaki-r
Date: Thu Jun 30 01:34:53 UTC 2016
Modified Files:
src/sys/net: if_spppsubr.c
src/sys/netinet: if_arp.c in.c
src/sys/netinet6: in6.c nd6.c
Log Message:
Make sure that ifaddr is published after its initialization finished
Basically we should insert an item to a collection (say a list) after
item's initialization has been completed to avoid accessing an item
that is initialized halfway. ifaddr (in{,6}_ifaddr) isn't processed
like so and needs to be fixed.
In order to do so, we need to tweak {arp,nd6}_rtrequest that depend
on that an ifaddr is inserted during its initialization; they explore
interface's address list to determine that rt_getkey(rt) of a given
rtentry is in the list to know whether the route's interface should
be a loopback, which doesn't work after the change. To make it work,
first check RTF_LOCAL flag that is set in rt_ifa_addlocal that calls
{arp,nd6}_rtrequest eventually. Note that we still need the original
code for the case to remove and re-add a local interface route.
To generate a diff of this commit:
cvs rdiff -u -r1.143 -r1.144 src/sys/net/if_spppsubr.c
cvs rdiff -u -r1.213 -r1.214 src/sys/netinet/if_arp.c
cvs rdiff -u -r1.168 -r1.169 src/sys/netinet/in.c
cvs rdiff -u -r1.201 -r1.202 src/sys/netinet6/in6.c
cvs rdiff -u -r1.197 -r1.198 src/sys/netinet6/nd6.c
+--+--++
| 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 |
+--+--++
Re: CVS commit: src/sys/dev/usb
On Wed, Feb 17, 2016 at 11:12:48AM +, Iain Hibbert wrote: > > I see the Linux driver does match against Vendor=Apple Class=Vendor > Subclass=RF Proto=Bluetooth in the same way but no Apple VendorIDs are > listed in any of the Broadcom driver files I found so I haven't added it. > Perhaps the ones which you added would be better covered by that? I am not > clear.. Maybe. The current list is what Apple devices FreeBSD has added individually. FreeBSD lists even more devices from other vendors. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: CVS commit: src/sys/dev/usb
> Module Name:src > Committed By: riastradh > Date: Wed Feb 17 00:49:28 UTC 2016 > > Modified Files: > src/sys/dev/usb: ubt.c > > Log Message: > Match various Apple USB Bluetooth controllers. > > >From mlelstv. btw I just commited a change to this which adds matching of several manufacturers who use modern Broadcom Bluetooth chips which are upgradeable at run-time. (and I also updated the sysutils/bcmfw package to handle this) I see the Linux driver does match against Vendor=Apple Class=Vendor Subclass=RF Proto=Bluetooth in the same way but no Apple VendorIDs are listed in any of the Broadcom driver files I found so I haven't added it. Perhaps the ones which you added would be better covered by that? I am not clear.. iain
Re: Regression on rtadvd (was: Re: CVS commit: src/usr.sbin/rtadvd)
On Mon, Jun 15, 2015 at 1:00 PM, Timo Buhrmester wrote: >> It seems that the kernel attempts to read non-existent cmsg >> which was removed by the commit. Can you try the below patch? >> It reduces cmsg buffer length as hoplimit cmsg is removed. > Your patch seems to have resolved the issue, thanks! Committed the fix. Thank you for your report! ozaki-r
Re: Regression on rtadvd (was: Re: CVS commit: src/usr.sbin/rtadvd)
> It seems that the kernel attempts to read non-existent cmsg > which was removed by the commit. Can you try the below patch? > It reduces cmsg buffer length as hoplimit cmsg is removed. Your patch seems to have resolved the issue, thanks! Cheers, Timo
Re: Regression on rtadvd (was: Re: CVS commit: src/usr.sbin/rtadvd)
On Mon, Jun 15, 2015 at 5:58 AM, Timo Buhrmester wrote:
>> Module Name: src
>> Committed By: roy
>> Date: Fri Jun 5 14:15:41 UTC 2015
>>
>> Modified Files:
>> src/usr.sbin/rtadvd: rtadvd.c
>>
>> Log Message:
>> Set the hoplimit of 255 as specified in RFC 4861 section 4.2
>> using the IPV6_MULTICAST_HOPS socket option rather than using CMSG
>> when constructing each message.
> This commit broke rtadvd for me, on i386, which now gives "Invalid argument"
> on the call to sendmsg() that is supposed to generate RAs.
>
> Here's two gdb transcripts:
>
> This is what happens AFTER the offending commit:
>
> | # gdb -q rtadvd
> | (gdb) break rtadvd.c:1699
> | (gdb) run -df vr1
> | [...]
> | Breakpoint 1, ra_output (rai=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1699
> | 1699 i = sendmsg(sock, &sndmhdr, 0);
> | (gdb) bt
> | #0 ra_output (rai=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1699
> | #1 0x0804cdbf in ra_timeout (data=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1779
> | #2 0x08052610 in rtadvd_check_timer () at
> /usr/src.head/usr.sbin/rtadvd/timer.c:130
> | #3 0x080499c0 in main (argc=-1, argv=0xbfbfec64) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:315
> | (gdb) x/28xb &sndmhdr
> | 0x8058b2c :0x40 0x7e0x050x080x1c0x000x00
> 0x00
> | 0x8058b34 : 0xc4 0x8a0x050x080x010x000x00
> 0x00
> | 0x8058b3c : 0xd0 0xa00x900xbb0x300x000x00
> 0x00
> | 0x8058b44 : 0x00 0x000x000x00
> | (gdb) n
> | 1701 if (i < 0 || (size_t)i != rai->ra_datalen) {
> | (gdb) print i
> | $1 = -1
> | (gdb) n
> | [...]
> | rtadvd[3794]: sendmsg on vr1: Invalid argument
>
>
>
> The following is what it looked like BEFORE the offending commit:
>
> | # gdb -q rtadvd
> | (gdb) break rtadvd.c:1702
> | (gdb) run -df vr1
> | [...]
> | Breakpoint 1, ra_output (rai=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1702
> | 1702 i = sendmsg(sock, &sndmhdr, 0);
> | (gdb) bt
> | #0 ra_output (rai=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1702
> | #1 0x0804cdcf in ra_timeout (data=0xbb91c0e0) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1782
> | #2 0x08052620 in rtadvd_check_timer () at
> /usr/src.head/usr.sbin/rtadvd/timer.c:130
> | #3 0x080499c0 in main (argc=-1, argv=0xbfbfec64) at
> /usr/src.head/usr.sbin/rtadvd/rtadvd.c:315
> | (gdb) x/28xb &sndmhdr
> | 0x8058b0c :0x20 0x7e0x050x080x1c0x000x00
> 0x00
> | 0x8058b14 : 0xa4 0x8a0x050x080x010x000x00
> 0x00
> | 0x8058b1c : 0xd0 0xa00x900xbb0x300x000x00
> 0x00
> | 0x8058b24 : 0x00 0x000x000x00
> | (gdb) n
> | 1704 if (i < 0 || (size_t)i != rai->ra_datalen) {
> | (gdb) print i
> | $2 = 56
>
>
>
> The difference in the representations of `sndmhdr` are in the 1st and 9th
> byte, which on i386 correspond to the 1st and 3rd members of struct sndhdr:
> |void*msg_name; /* optional address */
> | andstruct iovec*msg_iov; /* scatter/gather array */
>
>
> I've manually tracked the failing code path down through the sendmsg system
> call:
> sys/kern/uipc_syscalls.c:620 do_sys_sendmsg_so() ``error =
> (*so->so_send)(so, sa, &auio, NULL, control, flags, l);''
> sys/kern/uipc_socket.c:1602 sosend() ``error =
> (*so->so_proto->pr_usrreqs->pr_send)(so, top, addr, control, l);''
> sys/netinet6/raw_ip6.c:891 rip6_send()``error = rip6_output(m,
> so, dst, control);''
> sys/netinet6/raw_ip6.c:391 rip6_output() ``if ((error =
> ip6_setpktopts(control, &opt, [...]''
> sys/netinet6/ip6_output.c:2705 ip6_setpktopts() ``if (cm->cmsg_len == 0 ||
> cm->cmsg_len > control->m_len)''
>
> The last function is where the EINVAL is produced, due to cm->cmsg_len being
> zero (in the 2nd iteration of the enclosing loop)
> Unfortunately, I couldn't figure out what's supposed to happen there.
>
>
> Any ideas?
It seems that the kernel attempts to read non-existent cmsg
which was removed by the commit. Can you try the below patch?
It reduces cmsg buffer length as hoplimit cmsg is removed.
ozaki-r
diff --git a/usr.sbin/rtadvd/rtadvd.c b/usr.sbin/rtadvd/rtadvd.c
index 66885c4..f2016eb 100644
--- a/usr.sbin/rtadvd/rtadvd.c
+++ b/usr.sbin/rtadvd/rtadvd.c
@@ -1503,8 +1503,7 @@ sock_open(void)
exit(1);
}
- sndcmsgbuflen = CMSG_SPACE(sizeof(struct in6_pktinfo)) +
- CMSG_SPACE(sizeof(int));
+ sndcmsgbuflen = CMSG_SPACE(sizeof(struct in6_pktinfo));
sndcmsgbuf = malloc(sndcmsgbuflen);
if (sndcmsgbuf == NULL) {
syslog(LOG_ERR, "<%s> malloc: %m", __func__);
Regression on rtadvd (was: Re: CVS commit: src/usr.sbin/rtadvd)
> Module Name: src
> Committed By: roy
> Date: Fri Jun 5 14:15:41 UTC 2015
>
> Modified Files:
> src/usr.sbin/rtadvd: rtadvd.c
>
> Log Message:
> Set the hoplimit of 255 as specified in RFC 4861 section 4.2
> using the IPV6_MULTICAST_HOPS socket option rather than using CMSG
> when constructing each message.
This commit broke rtadvd for me, on i386, which now gives "Invalid argument" on
the call to sendmsg() that is supposed to generate RAs.
Here's two gdb transcripts:
This is what happens AFTER the offending commit:
| # gdb -q rtadvd
| (gdb) break rtadvd.c:1699
| (gdb) run -df vr1
| [...]
| Breakpoint 1, ra_output (rai=0xbb91c0e0) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:1699
| 1699 i = sendmsg(sock, &sndmhdr, 0);
| (gdb) bt
| #0 ra_output (rai=0xbb91c0e0) at /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1699
| #1 0x0804cdbf in ra_timeout (data=0xbb91c0e0) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:1779
| #2 0x08052610 in rtadvd_check_timer () at
/usr/src.head/usr.sbin/rtadvd/timer.c:130
| #3 0x080499c0 in main (argc=-1, argv=0xbfbfec64) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:315
| (gdb) x/28xb &sndmhdr
| 0x8058b2c :0x40 0x7e0x050x080x1c0x000x00
0x00
| 0x8058b34 : 0xc4 0x8a0x050x080x010x000x00
0x00
| 0x8058b3c : 0xd0 0xa00x900xbb0x300x000x00
0x00
| 0x8058b44 : 0x00 0x000x000x00
| (gdb) n
| 1701 if (i < 0 || (size_t)i != rai->ra_datalen) {
| (gdb) print i
| $1 = -1
| (gdb) n
| [...]
| rtadvd[3794]: sendmsg on vr1: Invalid argument
The following is what it looked like BEFORE the offending commit:
| # gdb -q rtadvd
| (gdb) break rtadvd.c:1702
| (gdb) run -df vr1
| [...]
| Breakpoint 1, ra_output (rai=0xbb91c0e0) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:1702
| 1702 i = sendmsg(sock, &sndmhdr, 0);
| (gdb) bt
| #0 ra_output (rai=0xbb91c0e0) at /usr/src.head/usr.sbin/rtadvd/rtadvd.c:1702
| #1 0x0804cdcf in ra_timeout (data=0xbb91c0e0) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:1782
| #2 0x08052620 in rtadvd_check_timer () at
/usr/src.head/usr.sbin/rtadvd/timer.c:130
| #3 0x080499c0 in main (argc=-1, argv=0xbfbfec64) at
/usr/src.head/usr.sbin/rtadvd/rtadvd.c:315
| (gdb) x/28xb &sndmhdr
| 0x8058b0c :0x20 0x7e0x050x080x1c0x000x00
0x00
| 0x8058b14 : 0xa4 0x8a0x050x080x010x000x00
0x00
| 0x8058b1c : 0xd0 0xa00x900xbb0x300x000x00
0x00
| 0x8058b24 : 0x00 0x000x000x00
| (gdb) n
| 1704 if (i < 0 || (size_t)i != rai->ra_datalen) {
| (gdb) print i
| $2 = 56
The difference in the representations of `sndmhdr` are in the 1st and 9th byte,
which on i386 correspond to the 1st and 3rd members of struct sndhdr:
|void*msg_name; /* optional address */
| andstruct iovec*msg_iov; /* scatter/gather array */
I've manually tracked the failing code path down through the sendmsg system
call:
sys/kern/uipc_syscalls.c:620 do_sys_sendmsg_so() ``error = (*so->so_send)(so,
sa, &auio, NULL, control, flags, l);''
sys/kern/uipc_socket.c:1602 sosend() ``error =
(*so->so_proto->pr_usrreqs->pr_send)(so, top, addr, control, l);''
sys/netinet6/raw_ip6.c:891 rip6_send()``error = rip6_output(m, so,
dst, control);''
sys/netinet6/raw_ip6.c:391 rip6_output() ``if ((error =
ip6_setpktopts(control, &opt, [...]''
sys/netinet6/ip6_output.c:2705 ip6_setpktopts() ``if (cm->cmsg_len == 0 ||
cm->cmsg_len > control->m_len)''
The last function is where the EINVAL is produced, due to cm->cmsg_len being
zero (in the 2nd iteration of the enclosing loop)
Unfortunately, I couldn't figure out what's supposed to happen there.
Any ideas?
Timo Buhrmester
Re: CVS commit: src/sys/sys
w...@netbsd.org (Thomas Klausner) writes: >I've built a 7.99.11 kernel today and booted it, and it twice failed >in the same place during boot. The subsystems are initialized in the following order: 1 module_init() 2 module_init_class(MODULE_CLASS_SECMODEL); 3 sysmon_task_queue_preinit(); 4 configure(); 5 configure2(); 6 module_init_class(MODULE_CLASS_ANY); 7 module_builtin_require_force(); 8 config_finalize(); Drivers registering with sysmon do that usually in 4. The sysmon module is initialized (including the mutex) in 6. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: CVS commit: src/sys/sys
FYI -- I sent msg to current-users this morning about same (not recognizing subject of this existing thread). Ref: http://mail-index.netbsd.org/current-users/2015/04/24/msg027232.html -bch On 4/24/15, Paul Goyette wrote: > On Fri, 24 Apr 2015, Thomas Klausner wrote: > >> On Thu, Apr 23, 2015 at 11:23:20PM +, Paul Goyette wrote: >>> Log Message: >>> Welcome to 7.99.x and the modularization of sysmon! >> >> I've built a 7.99.11 kernel today and booted it, and it twice failed >> in the same place during boot. >> >> acpicpu1 at cpu1: ACPI CPU >> coretemp1 at cpu1: thermal sensor, 1 C resolution >> Mutex error: mutex_vector_enter: locking against myself >> >> lock address : 0x811c0040 >> current cpu : 0 >> current lwp : 0x810d2b80 >> owner field : 0x810d2b80 wait spin: 0/0 >> >> panic: lock error: Mutex: mutex_vector_enter: locking against myself: lock >> 0x811c0040 cpu 0 lwp 0x810d2b80 >> fata breakpoint trap in supervisor mode >> trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8 rsp >> 81373c00 >> curlwp 0x810d2b80 pid 0.1 lowest kstrack 0x813702c0 >> >> 7.99.10 from yesterday boots fine. > > Hmmm. The dmesg would at least suggest that this would be a result of > my changes. Is there any chance you can get a backtrace? Or use the > kernel map to identify which lock is being referenced? (Both data would > be useful.) > > > > - > | 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 | > - >
Re: CVS commit: src/sys/sys
On Fri, 24 Apr 2015, Thomas Klausner wrote: On Thu, Apr 23, 2015 at 11:23:20PM +, Paul Goyette wrote: Log Message: Welcome to 7.99.x and the modularization of sysmon! I've built a 7.99.11 kernel today and booted it, and it twice failed in the same place during boot. acpicpu1 at cpu1: ACPI CPU coretemp1 at cpu1: thermal sensor, 1 C resolution Mutex error: mutex_vector_enter: locking against myself lock address : 0x811c0040 current cpu : 0 current lwp : 0x810d2b80 owner field : 0x810d2b80 wait spin: 0/0 panic: lock error: Mutex: mutex_vector_enter: locking against myself: lock 0x811c0040 cpu 0 lwp 0x810d2b80 fata breakpoint trap in supervisor mode trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8 rsp 81373c00 curlwp 0x810d2b80 pid 0.1 lowest kstrack 0x813702c0 7.99.10 from yesterday boots fine. Hmmm. The dmesg would at least suggest that this would be a result of my changes. Is there any chance you can get a backtrace? Or use the kernel map to identify which lock is being referenced? (Both data would be useful.) - | 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 | -
Re: CVS commit: src/sys/sys
On Thu, Apr 23, 2015 at 11:23:20PM +, Paul Goyette wrote: > Log Message: > Welcome to 7.99.x and the modularization of sysmon! I've built a 7.99.11 kernel today and booted it, and it twice failed in the same place during boot. acpicpu1 at cpu1: ACPI CPU coretemp1 at cpu1: thermal sensor, 1 C resolution Mutex error: mutex_vector_enter: locking against myself lock address : 0x811c0040 current cpu : 0 current lwp : 0x810d2b80 owner field : 0x810d2b80 wait spin: 0/0 panic: lock error: Mutex: mutex_vector_enter: locking against myself: lock 0x811c0040 cpu 0 lwp 0x810d2b80 fata breakpoint trap in supervisor mode trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8 rsp 81373c00 curlwp 0x810d2b80 pid 0.1 lowest kstrack 0x813702c0 7.99.10 from yesterday boots fine. Thomas
Re: CVS commit: src/sys/dev/pci
Hi, all. (2014/01/10 10:39), SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Fri Jan 10 01:39:48 UTC 2014 Modified Files: src/sys/dev/pci: pcidevs Log Message: Rework for Marvell 88SE9128. Change the description of 0x9123 to 88SE912[38]. For 0x91a3, add '(unclear)' into the description. FreeBSD, Linux and http://pci-ids.ucw.cz have no such device. To generate a diff of this commit: cvs rdiff -u -r1.1179 -r1.1180 src/sys/dev/pci/pcidevs Anyone who have Marvell device that the product ID is 0x91a3? jakllsch who added that entry before doesn't have the device anymore. If you have the device, please check the laser marking on the chip and tell me the name and the dmesg. Thanks. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/dev/i2c
Hi, > Module Name: src > Committed By: soren > Date: Wed Aug 7 19:38:45 UTC 2013 > > Modified Files: > src/sys/dev/i2c: at24cxx.c dbcool_reg.h i2c.c lm75reg.h max6900reg.h > pcf8583reg.h sdtemp_reg.h spdmem_i2c.c x1226reg.h > > Log Message: > Allow i2c addr wildcard matching. Use with care! > To generate a diff of this commit: > cvs rdiff -u -r1.39 -r1.40 src/sys/dev/i2c/i2c.c There is slight snag with this change to i2c.c, as it changes the match when the kernel configuration contains both direct and indirect matching for i2c busses, as on sparc64. It causes the kernel to attempt to attach the modified device at every possible address - for example: alipm0 at pci1 dev 6 function 0: 223KHz clock iic1 at alipm0: I2C bus seeprom4 at iic1 addr 0x50: AT24Cxx EEPROM seeprom4: invalid size specified; assuming 2KB (16Kb) lmtemp0 at iic1 addr 0x48: LM75 Temperature Sensor lmtemp0: unable to write config register dbcool_chip_ident: addr 0x2c c_id 0x00 d_id 0x00 r_id 0x00: No match. admtemp0 at iic1 addr 0x18: ADM1021 or compatible environmental sensor admtemp0: cannot get control register (each device appears at each possible address for that device). The sparc64 configuration contains (direct config): spdmem* at iic? addr? admtemp* at iic? addr? lmtemp* at iic? addr? dbcool* at iic? addr? # SB25000 seeprom* at iic? addr? # i2c-at24c64 fru's and (indirect config): spdmem* at iic? addr 0x50 # SPARCle memory spdmem* at iic? addr 0x51 # SPARCle memory Prior to this change, the config entries "at iic? addr?" would only be matched when ia->ia_name was not null. With this change, they match for busses that attach with indirect config too, like iic at alipm. I'm not sure what the best way to fix this is - we want to have the device entries "at iic? addr?" only match with direct config. Thanks, J -- NetBSD: simple; works; documented/Sailing at Newbiggin http://www.netbsd.org// http://www.newbigginsailingclub.org/
Re: wm(4) BMC related change (Fwd: CVS commit: src/sys/dev/pci)
Hello, Tom. (2013/06/27 22:29), Tom Ivar Helbekkmo wrote: > SAITOH Masanobu writes: > >> I fixed some BMC related bugs. If you have troble with BMC capable >> machine, please try the latest -current and report whether the problem >> is solved or not. If you still have problems, please compile the kernel >> with WM_DEBUG and send the full dmesg to me. > > I've been having stability problems for a while, on a Dell Poweredge > 2850 that uses a wm interface to do VLAN trunking to a Cisco switch. > The machine is both default router and NFS server for my home systems. > It displays very frequent short pauses in network communication, less > frequent longer pauses, and occasional complete hangs. The hanging > affects disk I/O (ld over amr), in that a logged-in shell on the > console, for instance, will still work until it does something that > tries to access disk. The situation worsens with increasing network > usage, and firing up a bittorrent client on another machine behind it > will normally bring it to its knees before very long, especially if I > have the bittorrent client store files it pulls down on NFS storage > served by the 2850... > > Does this sound like a situation your bug fixes might be relevant to? Perhaps, no, it doesn't. I checked the specification of Dell Poweredge 2850. It has two 82541EI and that chip is not so complexed and has not so many errata. I couldn't find what south bridge chip is used on the machine. If it's 63xxESB I/O controller HUB, the problem may be caused by the chips errata because of the lack of the errata's workaround in NetBSD. That chip aggressively introduced new features to improve I/O performance, but the number of errata is.. One of other problem is that I have no machine which has 82541EI and BMC function. > -tih > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: wm(4) BMC related change (Fwd: CVS commit: src/sys/dev/pci)
SAITOH Masanobu writes: > I fixed some BMC related bugs. If you have troble with BMC capable > machine, please try the latest -current and report whether the problem > is solved or not. If you still have problems, please compile the kernel > with WM_DEBUG and send the full dmesg to me. I've been having stability problems for a while, on a Dell Poweredge 2850 that uses a wm interface to do VLAN trunking to a Cisco switch. The machine is both default router and NFS server for my home systems. It displays very frequent short pauses in network communication, less frequent longer pauses, and occasional complete hangs. The hanging affects disk I/O (ld over amr), in that a logged-in shell on the console, for instance, will still work until it does something that tries to access disk. The situation worsens with increasing network usage, and firing up a bittorrent client on another machine behind it will normally bring it to its knees before very long, especially if I have the bittorrent client store files it pulls down on NFS storage served by the 2850... Does this sound like a situation your bug fixes might be relevant to? -tih -- It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong. -Richard Feynman
wm(4) BMC related change (Fwd: CVS commit: src/sys/dev/pci)
Hello. I fixed some BMC related bugs. If you have troble with BMC capable machine, please try the latest -current and report whether the problem is solved or not. If you still have problems, please compile the kernel with WM_DEBUG and send the full dmesg to me. Thanks. Original Message Return-Path: X-Original-To: msai...@execsw.org Delivered-To: msai...@execsw.org Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by vslock.execsw.org (Postfix) with ESMTP id E8397439846 for ; Wed, 26 Jun 2013 02:38:41 +0900 (JST) Received: by mail.netbsd.org (Postfix, from userid 605) id 6571214A132; Tue, 25 Jun 2013 17:38:40 + (UTC) Delivered-To: source-chan...@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A15C514A12E for ; Tue, 25 Jun 2013 17:38:39 + (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3V79upZcnzM6 for ; Tue, 25 Jun 2013 17:38:39 + (UTC) Received: from cvs.netbsd.org (cvs.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe30:95bd]) by mail.netbsd.org (Postfix) with ESMTP id EAC0F14A127 for ; Tue, 25 Jun 2013 17:38:38 + (UTC) Received: by cvs.netbsd.org (Postfix, from userid 500) id EB66496; Tue, 25 Jun 2013 17:38:38 + (UTC) Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" MIME-Version: 1.0 Date: Tue, 25 Jun 2013 17:38:38 + From: SAITOH Masanobu Subject: CVS commit: src/sys/dev/pci To: source-chan...@netbsd.org X-Mailer: log_accum Message-Id: <20130625173838.eb66...@cvs.netbsd.org> Sender: source-changes-ow...@netbsd.org List-Id: source-changes.NetBSD.org Precedence: bulk Reply-To: source-change...@netbsd.org Mail-Reply-To: "SAITOH Masanobu" Mail-Followup-To: source-change...@netbsd.org Module Name:src Committed By: msaitoh Date: Tue Jun 25 17:38:38 UTC 2013 Modified Files: src/sys/dev/pci: if_wm.c if_wmreg.h Log Message: Sync the wm_enable_mng_pass_thru() function with FreeBSD. Don't check MANC_EN_MAC_ADDR_FILTER bit. Add 82574 and 82583 specific check. This modification may change the setting of WM_F_HAS_MANAGE flag on some machines. Sync the wm_release_manageablilty() fucntion with FreeBSD. Set MANC_ARP_EN. This change enables HW ARP function when entering suspend. When the chip is 82580(ER) or I350, set WM_F_ASF_FIRMWARE_PRES flag and check for the WM_F_ARC_SUBSYS_VALID flag. Same as FreeBSD. To generate a diff of this commit: cvs rdiff -u -r1.259 -r1.260 src/sys/dev/pci/if_wm.c cvs rdiff -u -r1.53 -r1.54 src/sys/dev/pci/if_wmreg.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
