Re: svn commit: r277199 - in head/sys: fs/devfs kern
Hi, On 01/15/15 04:31, Konstantin Belousov wrote: Please do not commit (to devfs) without seeking for the review first. I was a bit stuck this time either having the choice to back out a USB patch fixing no problems or to fix the kernel devfs to support what I needed. Actually "devfs" is not listed in src/MAINTAINERS. I understand a review can be good in such critical areas in advance as a general practice and I'm currently doing that for another kern/ patch which is much bigger than this one. --HPS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277199 - in head/sys: fs/devfs kern
On Thu, Jan 15, 2015 at 08:41:31AM +0100, Hans Petter Selasky wrote: > On 01/15/15 04:31, Konstantin Belousov wrote: > > On Wed, Jan 14, 2015 at 10:07:13PM +, Hans Petter Selasky wrote: > >> Author: hselasky > >> Date: Wed Jan 14 22:07:13 2015 > >> New Revision: 277199 > >> URL: https://svnweb.freebsd.org/changeset/base/277199 > >> > >> Log: > >>Avoid race with "dev_rel()" when using the recently added > >>"delist_dev()" function. Make sure the character device structure > >>doesn't go away until the end of the "destroy_dev()" function due to > >>concurrently running cleanup code inside "devfs_populate()". > >> > >>MFC after: 1 week > >>Reported by:dchagin@ > >> > >> Modified: > >>head/sys/fs/devfs/devfs_devs.c > >>head/sys/kern/kern_conf.c > >> > >> Modified: head/sys/fs/devfs/devfs_devs.c > >> == > >> --- head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:05:57 2015 > >> (r277198) > >> +++ head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:07:13 2015 > >> (r277199) > >> @@ -137,6 +137,12 @@ devfs_alloc(int flags) > >>vfs_timestamp(&ts); > >>cdev->si_atime = cdev->si_mtime = cdev->si_ctime = ts; > >>cdev->si_cred = NULL; > >> + /* > >> + * Avoid race with dev_rel() by setting the initial > >> + * reference count to 1. This last reference is taken > >> + * by the destroy_dev() function. > >> + */ > >> + cdev->si_refcount = 1; > > This is wrong. Not all devices are destroyed with destroy_dev(). > > dev_rel() must be allowed to clean up allocated device. > > > > That said, I do not understand what race you are trying to solve. > > Freeing of the accessible cdev memory cannot happen in parallel while > > dev_mtx is owned. > > > > Please do not commit (to devfs) without seeking for the review first. > > Hi Konstantin, > > From my analysis there are basically three ways for a cdev to die: > > 1) Through dev_free_devlocked() > 2) Through destroy_devl() which then later calls dev_free_devlocked() > 3) Through destroy_dev_sched() which really is a wrapper around > destroy_devl(). You only look from the consumers PoV. Devfs cdev can be dereferenced because e.g. clone handler decides that cdev is not valid/needed, and now the memory is never freed due to extra reference. Do not assume that all cdevs go through destroy_dev(). > > In the case of direct free through #1, the reference count is ignored > and it doesn't matter if it is one or zero. Only in the case of > destruction through destroy_dev() it matters. > > Like the comment says in destroy_devl(): > > /* Avoid race with dev_rel() */ > > The problem is that the "cdev->si_refcount" is zero when the initial > devfs_create() is called. Then one ref is made. When we clear the > CDP_ACTIVE flag in devfs_destroy() it instructs a !parallel! running > process to destroy all the FS related structures and the reference count > goes back to zero when the "cdp" is removed from the "cdevp_list". Then > the cdev is freed too early. This happens because destroy_devl() is > dropping the dev_lock() to sleep waiting for pending references. Basically, this is very good explanation why your delist hack is wrong, for one of the reason. Another reason is explained below. You are trying to cover it with additional reference, but this is wrong as well. > > Do you see something else? I think that what you are trying to do with the CDP_ACTIVE hack is doomed anyway, because you are allowing for devfs directory to have two entries with the same name, until the populate loop cleans up the inactive one. In the meantime, any access to the directory operates on random entry. The checks for existent names in make_dev() are performed for the reason, and you makes the rounds to effectively ignore it. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277211 - head/sys/compat/freebsd32
Author: kib
Date: Thu Jan 15 10:43:58 2015
New Revision: 277211
URL: https://svnweb.freebsd.org/changeset/base/277211
Log:
fcntl F_O{GET,SET}LK take pointer as the arg, handle them properly for
compat32.
Reported and tested by: Alex Tutubalin
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/compat/freebsd32/freebsd32_misc.c
Modified: head/sys/compat/freebsd32/freebsd32_misc.c
==
--- head/sys/compat/freebsd32/freebsd32_misc.c Thu Jan 15 06:14:42 2015
(r277210)
+++ head/sys/compat/freebsd32/freebsd32_misc.c Thu Jan 15 10:43:58 2015
(r277211)
@@ -3032,6 +3032,9 @@ freebsd32_fcntl(struct thread *td, struc
case F_GETLK:
case F_SETFD:
case F_SETFL:
+ case F_OGETLK:
+ case F_OSETLK:
+ case F_OSETLKW:
tmp = (unsigned int)(uap->arg);
break;
default:
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277199 - in head/sys: fs/devfs kern
On 01/15/15 10:38, Konstantin Belousov wrote: On Thu, Jan 15, 2015 at 08:41:31AM +0100, Hans Petter Selasky wrote: On 01/15/15 04:31, Konstantin Belousov wrote: On Wed, Jan 14, 2015 at 10:07:13PM +, Hans Petter Selasky wrote: Author: hselasky Date: Wed Jan 14 22:07:13 2015 New Revision: 277199 URL: https://svnweb.freebsd.org/changeset/base/277199 Log: Avoid race with "dev_rel()" when using the recently added "delist_dev()" function. Make sure the character device structure doesn't go away until the end of the "destroy_dev()" function due to concurrently running cleanup code inside "devfs_populate()". MFC after: 1 week Reported by:dchagin@ Modified: head/sys/fs/devfs/devfs_devs.c head/sys/kern/kern_conf.c Modified: head/sys/fs/devfs/devfs_devs.c == --- head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:05:57 2015 (r277198) +++ head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:07:13 2015 (r277199) @@ -137,6 +137,12 @@ devfs_alloc(int flags) vfs_timestamp(&ts); cdev->si_atime = cdev->si_mtime = cdev->si_ctime = ts; cdev->si_cred = NULL; + /* +* Avoid race with dev_rel() by setting the initial +* reference count to 1. This last reference is taken +* by the destroy_dev() function. +*/ + cdev->si_refcount = 1; This is wrong. Not all devices are destroyed with destroy_dev(). dev_rel() must be allowed to clean up allocated device. That said, I do not understand what race you are trying to solve. Freeing of the accessible cdev memory cannot happen in parallel while dev_mtx is owned. Please do not commit (to devfs) without seeking for the review first. Hi Konstantin, From my analysis there are basically three ways for a cdev to die: 1) Through dev_free_devlocked() 2) Through destroy_devl() which then later calls dev_free_devlocked() 3) Through destroy_dev_sched() which really is a wrapper around destroy_devl(). You only look from the consumers PoV. Devfs cdev can be dereferenced because e.g. clone handler decides that cdev is not valid/needed, and now the memory is never freed due to extra reference. Do not assume that all cdevs go through destroy_dev(). Hi, All cdevs go through either case #2 or case #1 eventually from what I can see, including clone devices, which call destroy_devl() in the end aswell. See the "clone_destroy()" function! I did a simple test with /dev/dspX.Y which use clone devices. I did: vmstat -m | grep -i devfs1 1) Before plugging USB audio device: DEVFS1 15779K - 189 512 2) Plug USB audio device: DEVFS1 16482K - 196 512 3) Play something (env AUDIODEV=/dev/dsp2.4 play track01.wav) DEVFS1 16583K - 197 512 4) Stop playing (clone device still exits): DEVFS1 16583K - 197 512 5) Detach USB audio device: DEVFS1 15779K - 197 512 I see no leakage in that case! Other case: 1) After "kldload if_tap" DEVFS1 15879K - 201 512 2) After creating TAP device (cat /dev/tap99) DEVFS1 15980K - 204 512 3) After creating TAP device (cat /dev/tap101) DEVFS1 16080K - 207 512 5) After "kldunload if_tap": DEVFS1 15879K - 207 512 6) After "kldload if_tap" again: DEVFS1 15879K - 207 512 I see no leakage in that case either! Are there more cases which I don't see? In the case of direct free through #1, the reference count is ignored and it doesn't matter if it is one or zero. Only in the case of destruction through destroy_dev() it matters. Like the comment says in destroy_devl(): /* Avoid race with dev_rel() */ The problem is that the "cdev->si_refcount" is zero when the initial devfs_create() is called. Then one ref is made. When we clear the CDP_ACTIVE flag in devfs_destroy() it instructs a !parallel! running process to destroy all the FS related structures and the reference count goes back to zero when the "cdp" is removed from the "cdevp_list". Then the cdev is freed too early. This happens because destroy_devl() is dropping the dev_lock() to sleep waiting for pending references. Basically, this is very good explanation why your delist hack is wrong, for one of the reason. Another reason is explained below. You are trying to cover it with additional reference, but this is wrong as well. Do you see something else? I think that what you are trying to do with the CDP_ACTIVE hack is doomed anyway, because you are allowing for devfs directory to have two entries with the same name, until the populate loop cleans up the inactive one. In the meantime, any access to the directory operates on random entry. The entry will not be random, because upon an open() call to a character device, I believe the devfs_looku
Re: svn commit: r277199 - in head/sys: fs/devfs kern
On Thu, Jan 15, 2015 at 11:49:09AM +0100, Hans Petter Selasky wrote: > On 01/15/15 10:38, Konstantin Belousov wrote: > > On Thu, Jan 15, 2015 at 08:41:31AM +0100, Hans Petter Selasky wrote: > >> On 01/15/15 04:31, Konstantin Belousov wrote: > >>> On Wed, Jan 14, 2015 at 10:07:13PM +, Hans Petter Selasky wrote: > Author: hselasky > Date: Wed Jan 14 22:07:13 2015 > New Revision: 277199 > URL: https://svnweb.freebsd.org/changeset/base/277199 > > Log: > Avoid race with "dev_rel()" when using the recently added > "delist_dev()" function. Make sure the character device structure > doesn't go away until the end of the "destroy_dev()" function due to > concurrently running cleanup code inside "devfs_populate()". > > MFC after: 1 week > Reported by: dchagin@ > > Modified: > head/sys/fs/devfs/devfs_devs.c > head/sys/kern/kern_conf.c > > Modified: head/sys/fs/devfs/devfs_devs.c > == > --- head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:05:57 2015 > (r277198) > +++ head/sys/fs/devfs/devfs_devs.c Wed Jan 14 22:07:13 2015 > (r277199) > @@ -137,6 +137,12 @@ devfs_alloc(int flags) > vfs_timestamp(&ts); > cdev->si_atime = cdev->si_mtime = cdev->si_ctime = ts; > cdev->si_cred = NULL; > +/* > + * Avoid race with dev_rel() by setting the initial > + * reference count to 1. This last reference is taken > + * by the destroy_dev() function. > + */ > +cdev->si_refcount = 1; > >>> This is wrong. Not all devices are destroyed with destroy_dev(). > >>> dev_rel() must be allowed to clean up allocated device. > >>> > >>> That said, I do not understand what race you are trying to solve. > >>> Freeing of the accessible cdev memory cannot happen in parallel while > >>> dev_mtx is owned. > >>> > >>> Please do not commit (to devfs) without seeking for the review first. > >> > >> Hi Konstantin, > >> > >> From my analysis there are basically three ways for a cdev to die: > >> > >> 1) Through dev_free_devlocked() > >> 2) Through destroy_devl() which then later calls dev_free_devlocked() > >> 3) Through destroy_dev_sched() which really is a wrapper around > >> destroy_devl(). > > You only look from the consumers PoV. Devfs cdev can be dereferenced > > because e.g. clone handler decides that cdev is not valid/needed, > > and now the memory is never freed due to extra reference. > > > > Do not assume that all cdevs go through destroy_dev(). > > Hi, > > All cdevs go through either case #2 or case #1 eventually from what I > can see, including clone devices, which call destroy_devl() in the end > aswell. See the "clone_destroy()" function! > > I did a simple test with /dev/dspX.Y which use clone devices. I did: > > vmstat -m | grep -i devfs1 > > 1) Before plugging USB audio device: > > DEVFS1 15779K - 189 512 > > 2) Plug USB audio device: > > DEVFS1 16482K - 196 512 > > 3) Play something (env AUDIODEV=/dev/dsp2.4 play track01.wav) > > DEVFS1 16583K - 197 512 > > 4) Stop playing (clone device still exits): > > DEVFS1 16583K - 197 512 > > 5) Detach USB audio device: > > DEVFS1 15779K - 197 512 > > I see no leakage in that case! > > Other case: > > 1) After "kldload if_tap" > >DEVFS1 15879K - 201 512 > > 2) After creating TAP device (cat /dev/tap99) > > DEVFS1 15980K - 204 512 > > 3) After creating TAP device (cat /dev/tap101) > > DEVFS1 16080K - 207 512 > > 5) After "kldunload if_tap": > > DEVFS1 15879K - 207 512 > > 6) After "kldload if_tap" again: > > DEVFS1 15879K - 207 512 > > I see no leakage in that case either! Because these cases come through destroy_dev(). > > Are there more cases which I don't see? You are breaking existig devfs KPI by your hack. You introduce yet another reference on the device, which is not supposed to be there. If some code calls delist_dev(), it could be said that it is a contract of the new function that destroy_dev() must be called eventually on the cdev. Then, the reference could be said to be shared-owned by delist_dev() and destroy_dev(). But, for arbitrary devfs user this new reference is unacceptable and breaks interface. > > > > >> > >> In the case of direct free through #1, the reference count is ignored > >> and it doesn't matter if it is one or zero. Only in the case of > >> destruction through destroy_dev() it matters. > >> > >> Like the comment says in destroy_devl(): > >> > >> /* Avoid race with dev_rel() */ > >> > >> The problem is th
Re: svn commit: r277199 - in head/sys: fs/devfs kern
On 01/15/15 12:51, Konstantin Belousov wrote: On Thu, Jan 15, 2015 at 11:49:09AM +0100, Hans Petter Selasky wrote: I see no leakage in that case either! Because these cases come through destroy_dev(). Are there more cases which I don't see? You are breaking existig devfs KPI by your hack. You introduce yet another reference on the device, which is not supposed to be there. Hi Konstantin, I need a non-sleeping way to say a character device is no longer supposed to be used and be able to re-use the device name right away creating a new device. I guess you got that. If some code calls delist_dev(), it could be said that it is a contract of the new function that destroy_dev() must be called eventually on the cdev. Then, the reference could be said to be shared-owned by delist_dev() and destroy_dev(). But, for arbitrary devfs user this new reference is unacceptable and breaks interface. delist_dev() changes no references. It can be called multiple times even, also inside destroy_devl(). Also I think that the "destroy_dev_sched_cbl()" function should call delist_dev() first so that we don't have a time from when the "destroy_dev_sched_cbl()" function is called where the device entry still exists in devfs mounts until the final destroy_devl() is done by a taskqueue. In the case of direct free through #1, the reference count is ignored and it doesn't matter if it is one or zero. Only in the case of destruction through destroy_dev() it matters. Like the comment says in destroy_devl(): /* Avoid race with dev_rel() */ The problem is that the "cdev->si_refcount" is zero when the initial devfs_create() is called. Then one ref is made. When we clear the CDP_ACTIVE flag in devfs_destroy() it instructs a !parallel! running process to destroy all the FS related structures and the reference count goes back to zero when the "cdp" is removed from the "cdevp_list". Then the cdev is freed too early. This happens because destroy_devl() is dropping the dev_lock() to sleep waiting for pending references. Basically, this is very good explanation why your delist hack is wrong, for one of the reason. Another reason is explained below. You are trying to cover it with additional reference, but this is wrong as well. Do you see something else? I think that what you are trying to do with the CDP_ACTIVE hack is doomed anyway, because you are allowing for devfs directory to have two entries with the same name, until the populate loop cleans up the inactive one. In the meantime, any access to the directory operates on random entry. The entry will not be random, because upon an open() call to a character device, I believe the devfs_lookup() function will be called, which always populate the devfs tree at first by calls to devfs_populate_xxx(). Any delisted devices which don't have the "CDP_ACTIVE" bit set, will never be seen by any open. Entry can be random, since after the populate loop is ran, your code in other thread could start and create duplicate entry. There is a window in the lookup where both directory vnode lock and mount point sx locks are dropped. So running the populate does not guarantee anything. If there is such a race, it is already there! My patch changes nothing in that area: Thread1: Calls destroy_dev() and clears CDP_ACTIVE, after dev_unlock() it goes waiting for some refs for xxx milliseconds. Thread2: Tries to create create a new character device having the same name like the one in thread1. Device name duplication check is missed because CDP_ACTIVE is cleared. Still thread1 is waiting. Thread3: Tries to open character device created by thread2 while thread1 is still waiting for some ref held by a userspace app to go away. This can happen already before my patches! What do you think? Regarding leftover filedescriptors which still access the old "cdev" this is not a problem, and these will be closed when the si_refcount goes to zero after the destroy_devl() call. The checks for existent names in make_dev() are performed for the reason, and you makes the rounds to effectively ignore it. These checks are still correct and don't conflict with my patch from what I can see. Else the existing destroy_devl() would also be broken even before my patch with regard to the "random" selection of character devices at open() from userspace. The checks are done to avoid duplicate names. Your patch makes these checks ineffective (i.e. broken). At what level do you mean duplicate names, I don't get this fully? At the directory level (DE nodes)? Or inside the list of character devices (LIST_XXX)? Let me summarize: - the extra reference on arbitrary cdev should be eliminated. The delist_dev_locked() may add the ref and set some CDP_ flag to indicate to destroy_dev() that it should do dev_rel(). It is possible to do this. I thought about this before doing my patch, but decided to try to avoid adding yet another cdev flag. - the existence of the duplicat
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 12:42:07AM +, Warner Losh wrote: > Author: imp > Date: Thu Jan 15 00:42:06 2015 > New Revision: 277204 > URL: https://svnweb.freebsd.org/changeset/base/277204 > > Log: > New MINIMAL kernel config. The goal with this configuration is to > only compile in those options in GENERIC that cannot be loaded as > modules. ufs is still included because many of its options aren't > present in the kernel module. There's some other exceptions documented Are you sure? I think defining UFS options in kernel connfig affect to module too. When I define this options in kernel config (w/o options FFS) I got ufs.ko with this SU, quota, acl etc. > +options SOFTUPDATES # Enable FFS soft updates support > +options UFS_ACL # Support for access control lists > +options UFS_DIRHASH # Improve performance on big directories > +options UFS_GJOURNAL# Enable gjournal-based UFS journaling > +options QUOTA # Enable disk quotas for UFS > +options SYSVSHM # SYSV-style shared memory > +options SYSVMSG # SYSV-style message queues > +options SYSVSEM # SYSV-style semaphores > +device agp # support several AGP chipsets > +device random # Entropy device > +device padlock_rng # VIA Padlock RNG > +device rdrand_rng # Intel Bull Mountain RNG > +device vlan# 802.1Q VLAN support > +device tun # Packet tunnel. > +device gif # IPv6 and IPv4 tunneling This is loadable too. And please include: NETMAP NFS_ROOT IEEE80211_DEBUG IEEE80211_AMPDU_AGE IEEE80211_SUPPORT_MESH AH_SUPPORT_AR5416 AH_AR5416_INTERRUPT_MITIGATION ATH_ENABLE_11N ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 04:23:03PM +0300, Slawa Olhovchenkov wrote: > On Thu, Jan 15, 2015 at 12:42:07AM +, Warner Losh wrote: > > New Revision: 277204 > > URL: https://svnweb.freebsd.org/changeset/base/277204 > > > > Log: > > New MINIMAL kernel config. The goal with this configuration is to > > only compile in those options in GENERIC that cannot be loaded as > > modules. ufs is still included because many of its options aren't > > present in the kernel module. There's some other exceptions documented > > Are you sure? > I think defining UFS options in kernel connfig affect to module too. > When I define this options in kernel config (w/o options FFS) I got > ufs.ko with this SU, quota, acl etc. > > [...] > This is loadable too. Right, it does not look like minimal to me either. But I welcome the intention. AFAIR last time we had a discussion about why our default kernel is not MINIMAL, it boiled down to two main problems: 1) loader's caching of disk reads (which makes loading *.ko's from /boot/loader.conf a PITA, esp. on ZFS), and 2) robust way to figure out which modules to load on an arbitrary user's system (so they won't have to write their /boot/loader.conf from scratch themselves). Speaking of (1), I recall there was one or two attempts to address it (keyword: fast-loader-3.diff). Can someone with more details on their hands comment a bit what had happened to that work and are there any ETA for it to get committed? That would be a big leap forward towards minimal kernel which can be feasible enough to replace (or be a real alternative to) GENERIC in the future. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 01:44:46PM +, Alexey Dokuchaev wrote: > On Thu, Jan 15, 2015 at 04:23:03PM +0300, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 12:42:07AM +, Warner Losh wrote: > > > New Revision: 277204 > > > URL: https://svnweb.freebsd.org/changeset/base/277204 > > > > > > Log: > > > New MINIMAL kernel config. The goal with this configuration is to > > > only compile in those options in GENERIC that cannot be loaded as > > > modules. ufs is still included because many of its options aren't > > > present in the kernel module. There's some other exceptions documented > > > > Are you sure? > > I think defining UFS options in kernel connfig affect to module too. > > When I define this options in kernel config (w/o options FFS) I got > > ufs.ko with this SU, quota, acl etc. > > > > [...] > > This is loadable too. > > Right, it does not look like minimal to me either. But I welcome the > intention. AFAIR last time we had a discussion about why our default > kernel is not MINIMAL, it boiled down to two main problems: 1) loader's > caching of disk reads (which makes loading *.ko's from /boot/loader.conf reading large monolitic kernel is slow too. > a PITA, esp. on ZFS), and 2) robust way to figure out which modules to > load on an arbitrary user's system (so they won't have to write their > /boot/loader.conf from scratch themselves). /boot/loader.conf (with all modules currently present in GENERIC) may be instaled by bsdinstall (and may be part of base.txz). > Speaking of (1), I recall there was one or two attempts to address it > (keyword: fast-loader-3.diff). Can someone with more details on their > hands comment a bit what had happened to that work and are there any > ETA for it to get committed? That would be a big leap forward towards > minimal kernel which can be feasible enough to replace (or be a real > alternative to) GENERIC in the future. This is not only space saving. This is allow to kenv hw.cxgbe.nrxq10g=8 ; kldunload if_cxgbe ; kldload if_cxgbe ; /etc/netstart only a few seconds downtime. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 04:53:42PM +0300, Slawa Olhovchenkov wrote: > On Thu, Jan 15, 2015 at 01:44:46PM +, Alexey Dokuchaev wrote: > > intention. AFAIR last time we had a discussion about why our default > > kernel is not MINIMAL, it boiled down to two main problems: 1) loader's > > caching of disk reads (which makes loading *.ko's from /boot/loader.conf > > reading large monolitic kernel is slow too. But not nearly as slow as loading 50-60 modules at boot time (on my stable/8 I have 59 right now). When you read one big file *once* you don't have to worry about caching reads. With everything moved to modules, loader does a lot of superfluous disk access, and to remedy this we need smart(er) caching implementation. > /boot/loader.conf (with all modules currently present in GENERIC) may > be instaled by bsdinstall (and may be part of base.txz). That could be done, but not before we solve (1), and from this POV it deems more important than (2). > This is not only space saving. > This is allow to [unload and load modules, change configuration in runtime > with minimal downtime and without reboot]. I think we all know what are the benefits of modularized kernels. But before we solve aforementioned problems, it will remain a custom option for advanced users. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r255323 - in head/sys: amd64/conf i386/conf
On Sun, Sep 08, 2013 at 01:02:44AM +0400, Slawa Olhovchenkov wrote: > On Sat, Sep 07, 2013 at 10:48:48PM +0200, Edward Tomasz Napiera?a wrote: > > > I'll be happy if someone does this right now, by populating a > > > /boot/loader.modules or something, and then force the "fixing" of > > > loader to cache metadata to make the reads faster. > > > > I have no idea on what's the loader(8) state right now, but long time > > ago I've made a patch that made it significantly faster by making > > caching actually work. No idea if anyone picked up the patch > > (http://people.freebsd.org/~trasz/fast-loader-3.diff), though. > > Some time ago Andrey V. Elsukov do improvement in loader for more > efficient caching and partition handling. Now loader load a lot of > modules faster. I am insert hist in CC: list. It's kind of funny we seem to have similar discussion happening right now again -- sixteen months later. Edward, Andrey, since you two seem to have some working code already, maybe you can work together to push out something that can be committed? :) ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On 15.01.2015 17:08, Alexey Dokuchaev wrote: >> reading large monolitic kernel is slow too. > > But not nearly as slow as loading 50-60 modules at boot time (on my stable/8 > I have 59 right now). When you read one big file *once* you don't have to > worry about caching reads. With everything moved to modules, loader does a > lot of superfluous disk access, and to remedy this we need smart(er) caching > implementation. Did you try on recent FreeBSD versions? E.g. stable/9 after r243243, or just /boot/loader from head/ ? -- WBR, Andrey V. Elsukov ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 05:35:41PM +0300, Andrey V. Elsukov wrote: > On 15.01.2015 17:08, Alexey Dokuchaev wrote: > > When you read one big file *once* you don't have to worry about caching > > reads. With everything moved to modules, loader does a lot of > > superfluous disk access, and to remedy this we need smart(er) caching > > implementation. > > Did you try on recent FreeBSD versions? E.g. stable/9 after r243243, or > just /boot/loader from head/ ? Admittedly, I didn't. My stable/8 laptop and year-or-two -CURRENT on ZFS both do show slowless with populated loader.conf. I will study r243243 and whether it changes anything for me, thanks! ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277212 - head/contrib/ofed/management/opensm/osmtest
Author: hselasky
Date: Thu Jan 15 14:47:48 2015
New Revision: 277212
URL: https://svnweb.freebsd.org/changeset/base/277212
Log:
Fix compilation for 32-bit architectures.
PR: 196580
Sponsored by: Mellanox Technologies
MFC after:3 days
Modified:
head/contrib/ofed/management/opensm/osmtest/osmtest.c
Modified: head/contrib/ofed/management/opensm/osmtest/osmtest.c
==
--- head/contrib/ofed/management/opensm/osmtest/osmtest.c Thu Jan 15
10:43:58 2015(r277211)
+++ head/contrib/ofed/management/opensm/osmtest/osmtest.c Thu Jan 15
14:47:48 2015(r277212)
@@ -2655,7 +2655,7 @@ static ib_api_status_t osmtest_stress_la
OSM_LOG_ENTER(&p_osmt->log);
gettimeofday(&start_tv, NULL);
- printf("-I- Start time is : %09ld:%06ld [sec:usec]\n", start_tv.tv_sec,
+ printf("-I- Start time is : %09ld:%06ld [sec:usec]\n",
(long)start_tv.tv_sec,
(long)start_tv.tv_usec);
while (num_queries < STRESS_LARGE_PR_RMPP_THR) {
@@ -2683,7 +2683,7 @@ static ib_api_status_t osmtest_stress_la
end_tv.tv_usec);
}
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
printf("-I- Querying %" PRId64
" Path Record queries CA to CA (rmpp)\n\ttook
%04ld:%06ld [sec:usec]\n",
num_queries, sec_diff, usec_diff);
@@ -2701,7 +2701,7 @@ static ib_api_status_t osmtest_stress_la
Exit:
gettimeofday(&end_tv, NULL);
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
if (end_tv.tv_usec > start_tv.tv_usec) {
sec_diff = end_tv.tv_sec - start_tv.tv_sec;
usec_diff = end_tv.tv_usec - start_tv.tv_usec;
@@ -2733,7 +2733,7 @@ static ib_api_status_t osmtest_stress_la
OSM_LOG_ENTER(&p_osmt->log);
gettimeofday(&start_tv, NULL);
- printf("-I- Start time is : %09ld:%06ld [sec:usec]\n", start_tv.tv_sec,
+ printf("-I- Start time is : %09ld:%06ld [sec:usec]\n",
(long)start_tv.tv_sec,
(long)start_tv.tv_usec);
while (num_queries < STRESS_LARGE_RMPP_THR) {
@@ -2772,7 +2772,7 @@ static ib_api_status_t osmtest_stress_la
end_tv.tv_usec);
}
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
printf("-I- Querying %" PRId64
" large mixed queries (rmpp) took %04ld:%06ld
[sec:usec]\n",
num_queries, sec_diff, usec_diff);
@@ -2785,7 +2785,7 @@ static ib_api_status_t osmtest_stress_la
Exit:
gettimeofday(&end_tv, NULL);
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
if (end_tv.tv_usec > start_tv.tv_usec) {
sec_diff = end_tv.tv_sec - start_tv.tv_sec;
usec_diff = end_tv.tv_usec - start_tv.tv_usec;
@@ -2819,7 +2819,7 @@ static ib_api_status_t osmtest_stress_sm
OSM_LOG_ENTER(&p_osmt->log);
gettimeofday(&start_tv, NULL);
printf("-I- Start time is : %09ld:%06ld [sec:usec]\n",
- start_tv.tv_sec, (long)start_tv.tv_usec);
+ (long)start_tv.tv_sec, (long)start_tv.tv_usec);
while ((num_queries < STRESS_SMALL_RMPP_THR) && (num_timeouts < 100)) {
delta_recs = 0;
@@ -2848,7 +2848,7 @@ static ib_api_status_t osmtest_stress_sm
end_tv.tv_usec);
}
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
printf("-I- Querying %" PRId64
" port_info queries (single mad) took
%04ld:%06ld [sec:usec]\n",
num_queries, sec_diff, usec_diff);
@@ -2859,7 +2859,7 @@ static ib_api_status_t osmtest_stress_sm
Exit:
gettimeofday(&end_tv, NULL);
printf("-I- End time is : %09ld:%06ld [sec:usec]\n",
- end_tv.tv_sec, (long)end_tv.tv_usec);
+ (long)end_tv.tv_sec, (long)end_tv.tv_usec);
if (end_tv.tv_usec > start_tv.tv_usec) {
sec_diff = end_tv.tv_sec - start_tv.tv
Re: svn commit: r277163 - head/sys/dev/cardbus
On 1/14/15 7:07 PM, Warner Losh wrote: > >> On Jan 14, 2015, at 7:23 AM, John Baldwin wrote: >> >> On 1/14/15 12:41 AM, Warner Losh wrote: >>> Author: imp >>> Date: Wed Jan 14 05:41:31 2015 >>> New Revision: 277163 >>> URL: https://svnweb.freebsd.org/changeset/base/277163 >>> >>> Log: >>> Add a rather obnoxious warning if you don't have NEW_PCIB defined >>> since it's a total crap shoot if things will work. >> >> Should we just make it a #error instead? (Some day I hope to have >> NEW_PCIB enabled by default and remove the old code. Will take a while >> to get there for the generic PCI code, but cardbus is probably only used >> on x86 so that would be fine.) > > CardBus is also used on PowerPC macs.. Ok. It shouldn't be hard to add the PCI_RES_BUS stuff to PowerPC. I believe I put the details of that in the NEW_PCIB page on the wiki. You just need to have the equivalent of the x86 nexus call some MI routines to allocate bus numbers for a given domain when bus_alloc_resource() requests bubble up from below. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
Author: hselasky Date: Thu Jan 15 15:32:30 2015 New Revision: 277213 URL: https://svnweb.freebsd.org/changeset/base/277213 Log: Major callout subsystem cleanup and rewrite: - Close a migration race where callout_reset() failed to set the CALLOUT_ACTIVE flag. - Callout callback functions are now allowed to be protected by spinlocks. - Switching the callout CPU number cannot always be done on a per-callout basis. See the updated timeout(9) manual page for more information. - The timeout(9) manual page has been updated to reflect how all the functions inside the callout API are working. The manual page has been made function oriented to make it easier to deduce how each of the functions making up the callout API are working without having to first read the whole manual page. Group all functions into a handful of sections which should give a quick top-level overview when the different functions should be used. - The CALLOUT_SHAREDLOCK flag and its functionality has been removed to reduce the complexity in the callout code and to avoid problems about atomically stopping callouts via callout_stop(). If someone needs it, it can be re-added. From my quick grep there are no CALLOUT_SHAREDLOCK clients in the kernel. - A new callout API function named "callout_drain_async()" has been added. See the updated timeout(9) manual page for a complete description. - Update the callout clients in the "kern/" folder to use the callout API properly, like cv_timedwait(). Previously there was some custom sleepqueue code in the callout subsystem, which has been removed, because we now allow callouts to be protected by spinlocks. This allows us to tear down the callout like done with regular mutexes, and a "td_slpmutex" has been added to "struct thread" to atomically teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and "SWT_SLEEPQTIMO" states can now be completely removed. Currently they are marked as available and will be cleaned up in a follow up commit. - Bump the __FreeBSD_version to indicate kernel modules need recompilation. - There has been several reports that this patch "seems to squash a serious bug leading to a callout timeout and panic". Kernel build testing: all architectures were built MFC after:2 weeks Differential Revision:https://reviews.freebsd.org/D1438 Sponsored by: Mellanox Technologies Reviewed by: jhb, adrian, sbruno and emaste Modified: head/share/man/man9/Makefile head/share/man/man9/timeout.9 head/sys/kern/init_main.c head/sys/kern/kern_condvar.c head/sys/kern/kern_lock.c head/sys/kern/kern_switch.c head/sys/kern/kern_synch.c head/sys/kern/kern_thread.c head/sys/kern/kern_timeout.c head/sys/kern/subr_sleepqueue.c head/sys/ofed/include/linux/completion.h head/sys/sys/_callout.h head/sys/sys/callout.h head/sys/sys/param.h head/sys/sys/proc.h Modified: head/share/man/man9/Makefile == --- head/share/man/man9/MakefileThu Jan 15 14:47:48 2015 (r277212) +++ head/share/man/man9/MakefileThu Jan 15 15:32:30 2015 (r277213) @@ -1570,6 +1570,7 @@ MLINKS+=timeout.9 callout.9 \ timeout.9 callout_active.9 \ timeout.9 callout_deactivate.9 \ timeout.9 callout_drain.9 \ + timeout.9 callout_drain_async.9 \ timeout.9 callout_handle_init.9 \ timeout.9 callout_init.9 \ timeout.9 callout_init_mtx.9 \ Modified: head/share/man/man9/timeout.9 == --- head/share/man/man9/timeout.9 Thu Jan 15 14:47:48 2015 (r277212) +++ head/share/man/man9/timeout.9 Thu Jan 15 15:32:30 2015 (r277213) @@ -29,13 +29,14 @@ .\" .\" $FreeBSD$ .\" -.Dd October 8, 2014 +.Dd January 14, 2015 .Dt TIMEOUT 9 .Os .Sh NAME .Nm callout_active , .Nm callout_deactivate , .Nm callout_drain , +.Nm callout_drain_async , .Nm callout_handle_init , .Nm callout_init , .Nm callout_init_mtx , @@ -63,279 +64,232 @@ .In sys/systm.h .Bd -literal typedef void timeout_t (void *); +typedef void callout_func_t (void *); .Ed -.Ft int -.Fn callout_active "struct callout *c" -.Ft void -.Fn callout_deactivate "struct callout *c" -.Ft int -.Fn callout_drain "struct callout *c" -.Ft void -.Fn callout_handle_init "struct callout_handle *handle" -.Bd -literal -struct callout_handle handle = CALLOUT_HANDLE_INITIALIZER(&handle); -.Ed -.Ft void -.Fn callout_init "struct callout *c" "int mpsafe" -.Ft void -.Fn callout_init_mtx "struct callout *c" "struct mtx *mtx" "int flags" -.Ft void -.Fn callout_init_rm "struct callout *c" "struct rmlock *rm" "int flags" -.Ft void -.Fn callout_init_rw "struct callout *c" "struct rwlock *rw" "int flags" -.Ft int -.Fn callout_pending "struct callout *c" -.Ft int -.Fn c
Re: svn commit: r277204 - head/sys/amd64/conf
On 1/14/15 7:42 PM, Warner Losh wrote: > Author: imp > Date: Thu Jan 15 00:42:06 2015 > New Revision: 277204 > URL: https://svnweb.freebsd.org/changeset/base/277204 > > Log: > New MINIMAL kernel config. The goal with this configuration is to > only compile in those options in GENERIC that cannot be loaded as > modules. ufs is still included because many of its options aren't > present in the kernel module. There's some other exceptions documented > in the file. This is part of some work to get more things > automatically loading in the hopes of obsoleting GENERIC one day. > > Added: > head/sys/amd64/conf/MINIMAL (contents, props changed) > > Added: head/sys/amd64/conf/MINIMAL > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/sys/amd64/conf/MINIMAL Thu Jan 15 00:42:06 2015 > (r277204) > @@ -0,0 +1,145 @@ > +# o acpi as a module has been reported flakey and not well tested, so > +# is included in the kernel. ACPI doesn't build as a module on amd64 and can't. It has to hook into kernel startup before modules can run to do things like enumerate CPUs and NUMA domains. i386 uses a hack to allow acpi.ko to load whereby it blows out all the CPU-sized tables to the static MAXCPU value instead of doing any runtime tuning. I'd probably prefer to drop acpi.ko from i386 and make it more like amd64. > +# o random is included due to uncertaty... s/uncertaty/uncertainty/, though I think you exhausted your irony quotient for the day with that one. :) > + > +device agp # support several AGP chipsets This works as a kld now IIRC? I think you can even load it at runtime? > + > +# Pseudo devices. > +device loop# Network loopback > +device random # Entropy device > +device padlock_rng # VIA Padlock RNG > +device rdrand_rng # Intel Bull Mountain RNG > +device ether # Ethernet support > +device vlan# 802.1Q VLAN support > +device tun # Packet tunnel. > +device gif # IPv6 and IPv4 tunneling These last three definitely work as modules. (vlan(4) was only recently added to GENERIC). -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 1/15/15 10:32 AM, Hans Petter Selasky wrote: > Author: hselasky > Date: Thu Jan 15 15:32:30 2015 > New Revision: 277213 > URL: https://svnweb.freebsd.org/changeset/base/277213 > > Log: > Major callout subsystem cleanup and rewrite: > - Close a migration race where callout_reset() failed to set the > CALLOUT_ACTIVE flag. > - Callout callback functions are now allowed to be protected by > spinlocks. > - Switching the callout CPU number cannot always be done on a > per-callout basis. See the updated timeout(9) manual page for more > information. > - The timeout(9) manual page has been updated to reflect how all the > functions inside the callout API are working. The manual page has > been made function oriented to make it easier to deduce how each of > the functions making up the callout API are working without having > to first read the whole manual page. Group all functions into a > handful of sections which should give a quick top-level overview > when the different functions should be used. > - The CALLOUT_SHAREDLOCK flag and its functionality has been removed > to reduce the complexity in the callout code and to avoid problems > about atomically stopping callouts via callout_stop(). If someone > needs it, it can be re-added. From my quick grep there are no > CALLOUT_SHAREDLOCK clients in the kernel. > - A new callout API function named "callout_drain_async()" has been > added. See the updated timeout(9) manual page for a complete > description. > - Update the callout clients in the "kern/" folder to use the callout > API properly, like cv_timedwait(). Previously there was some custom > sleepqueue code in the callout subsystem, which has been removed, > because we now allow callouts to be protected by spinlocks. This > allows us to tear down the callout like done with regular mutexes, > and a "td_slpmutex" has been added to "struct thread" to atomically > teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and > "SWT_SLEEPQTIMO" states can now be completely removed. Currently > they are marked as available and will be cleaned up in a follow up > commit. > - Bump the __FreeBSD_version to indicate kernel modules need > recompilation. > - There has been several reports that this patch "seems to squash a > serious bug leading to a callout timeout and panic". > > Kernel build testing: all architectures were built > MFC after: 2 weeks > Differential Revision: https://reviews.freebsd.org/D1438 > Sponsored by: Mellanox Technologies > Reviewed by:jhb, adrian, sbruno and emaste Eh, I have not reviewed this at all. (I still plan to though.) -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 15 January 2015 at 10:53, John Baldwin wrote: > On 1/15/15 10:32 AM, Hans Petter Selasky wrote: >> Author: hselasky >> Date: Thu Jan 15 15:32:30 2015 >> New Revision: 277213 >> URL: https://svnweb.freebsd.org/changeset/base/277213 >> > Eh, I have not reviewed this at all. (I still plan to though.) Yes, the list is "people listed as reviewers or subscribers on the Phabricator review." I don't believe anyone in the list has examined it closely enough to count as "Reviewed-by." I certainly haven't. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/15/15 16:53, John Baldwin wrote: On 1/15/15 10:32 AM, Hans Petter Selasky wrote: Author: hselasky Date: Thu Jan 15 15:32:30 2015 New Revision: 277213 URL: https://svnweb.freebsd.org/changeset/base/277213 Hi, Eh, I have not reviewed this at all. (I still plan to though.) The "Reviewed by" was simply a C&P of the review list in from the Differential Revision. When you mention it should probably simply have said: Reviewed by: sbruno @ Due to the meaning of "Reviewed by" in commit messages. Sorry. BTW: Nice if people respond quickly or remove themselves from the differential reviews if they don't plan to do any reviews. --HPS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277214 - in head/sys/dev/sound: pci pcm
Author: bapt
Date: Thu Jan 15 16:09:35 2015
New Revision: 277214
URL: https://svnweb.freebsd.org/changeset/base/277214
Log:
Sound: fix typos in user visible messages etc.
Submitted by: Sascha Wildner
Obtained from:DragonFly
MFC after:3 days
Modified:
head/sys/dev/sound/pci/emu10kx.c
head/sys/dev/sound/pci/envy24.c
head/sys/dev/sound/pci/envy24ht.c
head/sys/dev/sound/pcm/channel.c
Modified: head/sys/dev/sound/pci/emu10kx.c
==
--- head/sys/dev/sound/pci/emu10kx.cThu Jan 15 15:32:30 2015
(r277213)
+++ head/sys/dev/sound/pci/emu10kx.cThu Jan 15 16:09:35 2015
(r277214)
@@ -2316,7 +2316,7 @@ emu10kx_prepare(struct emu_sc_info *sc,
}
if (sc->midi[0] != NULL)
if (device_is_attached(sc->midi[0])) {
- sbuf_printf(s, "\tIR reciever MIDI events %s\n",
sc->enable_ir ? "enabled" : "disabled");
+ sbuf_printf(s, "\tIR receiver MIDI events %s\n",
sc->enable_ir ? "enabled" : "disabled");
}
sbuf_printf(s, "Card is in %s mode\n", (sc->mode == MODE_ANALOG) ?
"analog" : "digital");
Modified: head/sys/dev/sound/pci/envy24.c
==
--- head/sys/dev/sound/pci/envy24.c Thu Jan 15 15:32:30 2015
(r277213)
+++ head/sys/dev/sound/pci/envy24.c Thu Jan 15 16:09:35 2015
(r277214)
@@ -2312,7 +2312,7 @@ envy24_putcfg(struct sc_info *sc)
printf("from external clock synthesizer chip\n");
break;
default:
- printf("illeagal system setting\n");
+ printf("illegal system setting\n");
}
printf(" MPU-401 UART(s) #: ");
if (sc->cfg->scfg & PCIM_SCFG_MPU)
Modified: head/sys/dev/sound/pci/envy24ht.c
==
--- head/sys/dev/sound/pci/envy24ht.c Thu Jan 15 15:32:30 2015
(r277213)
+++ head/sys/dev/sound/pci/envy24ht.c Thu Jan 15 16:09:35 2015
(r277214)
@@ -2212,7 +2212,7 @@ envy24ht_putcfg(struct sc_info *sc)
printf("reserved\n");
break;
default:
- printf("illeagal system setting\n");
+ printf("illegal system setting\n");
}
printf(" MPU-401 UART(s) #: ");
if (sc->cfg->scfg & ENVY24HT_CCSM_SCFG_MPU)
Modified: head/sys/dev/sound/pcm/channel.c
==
--- head/sys/dev/sound/pcm/channel.cThu Jan 15 15:32:30 2015
(r277213)
+++ head/sys/dev/sound/pcm/channel.cThu Jan 15 16:09:35 2015
(r277214)
@@ -92,7 +92,7 @@ sysctl_hw_snd_latency_profile(SYSCTL_HAN
}
SYSCTL_PROC(_hw_snd, OID_AUTO, latency_profile, CTLTYPE_INT | CTLFLAG_RW,
0, sizeof(int), sysctl_hw_snd_latency_profile, "I",
- "buffering latency profile (0=aggresive 1=safe)");
+ "buffering latency profile (0=aggressive 1=safe)");
static int chn_timeout = CHN_TIMEOUT;
TUNABLE_INT("hw.snd.timeout", &chn_timeout);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277163 - head/sys/dev/cardbus
On 01/14/15 16:07, Warner Losh wrote: On Jan 14, 2015, at 8:32 AM, Justin Hibbits wrote: On Wed, 14 Jan 2015 09:23:05 -0500 John Baldwin wrote: On 1/14/15 12:41 AM, Warner Losh wrote: Author: imp Date: Wed Jan 14 05:41:31 2015 New Revision: 277163 URL: https://svnweb.freebsd.org/changeset/base/277163 Log: Add a rather obnoxious warning if you don't have NEW_PCIB defined since it's a total crap shoot if things will work. Should we just make it a #error instead? (Some day I hope to have NEW_PCIB enabled by default and remove the old code. Will take a while to get there for the generic PCI code, but cardbus is probably only used on x86 so that would be fine.) Also powerpc, but NEW_PCIB is default there as well. PowerPC doesn’t seem to defined the bus number resources. Warner Which ones? -Nathan ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
On Thu, Jan 15, 2015 at 10:51:55AM -0500, John Baldwin wrote: > > [...] > > +# Pseudo devices. > > +device loop# Network loopback > > +device random # Entropy device > > +device padlock_rng # VIA Padlock RNG > > +device rdrand_rng # Intel Bull Mountain RNG > > +device ether # Ethernet support > > +device vlan# 802.1Q VLAN support > > +device tun # Packet tunnel. > > +device gif # IPv6 and IPv4 tunneling > > These last three definitely work as modules. (vlan(4) was only recently > added to GENERIC). And many other things as well (like SYSV* for example). I usually go as far as nodevice'ing io and mem, FWIW. That said, if we supply reference MINIMAL, it should *really* be minimal. And it should not be limited to amd64; lest we forget, our primary target should still be i386. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277215 - in head/sys: amd64/include boot/common boot/fdt boot/forth boot/i386/libi386 boot/i386/loader i386/include x86/xen
Author: royger
Date: Thu Jan 15 16:27:20 2015
New Revision: 277215
URL: https://svnweb.freebsd.org/changeset/base/277215
Log:
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall
Added:
head/sys/boot/i386/libi386/multiboot.c (contents, props changed)
head/sys/boot/i386/libi386/multiboot.h (contents, props changed)
head/sys/boot/i386/libi386/multiboot_tramp.S (contents, props changed)
Modified:
head/sys/amd64/include/metadata.h
head/sys/boot/common/bootstrap.h
head/sys/boot/common/load_elf.c
head/sys/boot/common/load_elf_obj.c
head/sys/boot/common/module.c
head/sys/boot/fdt/fdt_loader_cmd.c
head/sys/boot/forth/beastie.4th
head/sys/boot/forth/loader.4th
head/sys/boot/forth/support.4th
head/sys/boot/i386/libi386/Makefile
head/sys/boot/i386/libi386/bootinfo64.c
head/sys/boot/i386/libi386/elf64_freebsd.c
head/sys/boot/i386/libi386/libi386.h
head/sys/boot/i386/loader/conf.c
head/sys/i386/include/metadata.h
head/sys/x86/xen/pv.c
Modified: head/sys/amd64/include/metadata.h
==
--- head/sys/amd64/include/metadata.h Thu Jan 15 16:09:35 2015
(r277214)
+++ head/sys/amd64/include/metadata.h Thu Jan 15 16:27:20 2015
(r277215)
@@ -34,6 +34,7 @@
#defineMODINFOMD_DTBP 0x1003
#defineMODINFOMD_EFI_MAP 0x1004
#defineMODINFOMD_EFI_FB0x1005
+#defineMODINFOMD_MODULEP 0x1006
struct efi_map_header {
size_t memory_size;
Modified: head/sys/boot/common/bootstrap.h
==
--- head/sys/boot/common/bootstrap.hThu Jan 15 16:09:35 2015
(r277214)
+++ head/sys/boot/common/bootstrap.hThu Jan 15 16:27:20 2015
(r277215)
@@ -232,9 +232,9 @@ int mod_loadkld(const char *name, int
void unload(void);
struct preloaded_file *file_alloc(void);
-struct preloaded_file *file_findfile(char *name, char *type);
+struct preloaded_file *file_findfile(const char *name, const char *type);
struct file_metadata *file_findmetadata(struct preloaded_file *fp, int type);
-struct preloaded_file *file_loadraw(char *name, char *type);
+struct preloaded_file *file_loadraw(char *name, char *type, int insert);
void file_discard(struct preloaded_file *fp);
void file_addme
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
Hans, On Thu, Jan 15, 2015 at 05:05:58PM +0100, Hans Petter Selasky wrote: H> > Eh, I have not reviewed this at all. (I still plan to though.) H> H> The "Reviewed by" was simply a C&P of the review list in from the H> Differential Revision. When you mention it should probably simply have said: H> H> Reviewed by: sbruno @ H> H> Due to the meaning of "Reviewed by" in commit messages. Sorry. H> H> BTW: Nice if people respond quickly or remove themselves from the H> differential reviews if they don't plan to do any reviews. I'd dare to say that such important change simply cannot be committed with a thorough review from at least two people very confident in this area. Look at r24. This is the way it should be done. -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On Thu, Jan 15, 2015 at 08:14:30PM +0300, Gleb Smirnoff wrote: T> I'd dare to say that such important change simply cannot be committed T> with a thorough review from at least two people very confident in this T> area. Of course, I typoed. I meant "cannot be committed withOUT a thorough review". -- Totus tuus, Glebius. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On Thu, Jan 15, 2015 at 05:05:58PM +0100, Hans Petter Selasky wrote: > The "Reviewed by" was simply a C&P of the review list in from the > Differential Revision. When you mention it should probably simply have said: > > Reviewed by: sbruno @ > > Due to the meaning of "Reviewed by" in commit messages. Sorry. > > BTW: Nice if people respond quickly or remove themselves from the > differential reviews if they don't plan to do any reviews. I think it's kind of wrong. Instead, lack of reviews should be treated as "lack of reviews" (and thus blocking commit), not that "people are not interested". ./danfe P.S. BTW, I still didn't receive your answer on an email I sent Jan 8th. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On Thu, Jan 15, 2015 at 7:32 AM, Hans Petter Selasky wrote: > Author: hselasky > Date: Thu Jan 15 15:32:30 2015 > New Revision: 277213 > URL: https://svnweb.freebsd.org/changeset/base/277213 > > Log: > Major callout subsystem cleanup and rewrite: I plan to review this as well -- although I didn't have time for it lately. Probably I'll be able to take a closer look during the weekend. I missed it because I'm terribly late with my backlog and I wasn't listed as reviewer so the mail didn't hit my mailbox. I think this is a huge improvement, for many reason I'll try to outline in my following review. OTOH, considering how complex is the subsystem, I would like you to take a look at Peter's (pho@) stress suite and run on that. He has an handful of scenarios that cause problems in migration an callout in general. Thanks for undertaking this, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> On 15 Jan 2015, at 15:32 , Hans Petter Selasky wrote: > > Author: hselasky > Date: Thu Jan 15 15:32:30 2015 > New Revision: 277213 > URL: https://svnweb.freebsd.org/changeset/base/277213 > > Log: > Major callout subsystem cleanup and rewrite: I see this for i386 and amd64 LINT* kernels. Is that a local problem or did you miss something? linking kernel addr.o: In function `set_timeout': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/addr.c:(.text+0xd37): undefined reference to `_callout_stop_safe' mad.o: In function `ib_unregister_mad_agent': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad.c:(.text+0x1ed4): undefined reference to `_callout_stop_safe' mad.o: In function `ib_mad_complete_send_wr': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad.c:(.text+0x3ea0): undefined reference to `_callout_stop_safe' cm.o: In function `ib_cm_cleanup': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/cm.c:(.text+0x40cf): undefined reference to `_callout_stop_safe' mad_rmpp.o: In function `ib_cancel_rmpp_recvs': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad_rmpp.c:(.text+0xc2): undefined reference to `_callout_stop_safe' mad_rmpp.o:/scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad_rmpp.c:(.text+0xe9): more undefined references to `_callout_stop_safe' follow --- kernel --- *** [kernel] Error code 1 — Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277163 - head/sys/dev/cardbus
On 1/15/15 11:20 AM, Nathan Whitehorn wrote: > > On 01/14/15 16:07, Warner Losh wrote: >>> On Jan 14, 2015, at 8:32 AM, Justin Hibbits >>> wrote: >>> >>> On Wed, 14 Jan 2015 09:23:05 -0500 >>> John Baldwin wrote: >>> On 1/14/15 12:41 AM, Warner Losh wrote: > Author: imp > Date: Wed Jan 14 05:41:31 2015 > New Revision: 277163 > URL: https://svnweb.freebsd.org/changeset/base/277163 > > Log: > Add a rather obnoxious warning if you don't have NEW_PCIB defined > since it's a total crap shoot if things will work. Should we just make it a #error instead? (Some day I hope to have NEW_PCIB enabled by default and remove the old code. Will take a while to get there for the generic PCI code, but cardbus is probably only used on x86 so that would be fine.) >>> Also powerpc, but NEW_PCIB is default there as well. >> PowerPC doesn’t seem to defined the bus number resources. >> >> Warner >> > > Which ones? > -Nathan PCI_RES_BUS. https://svnweb.freebsd.org/base?view=revision&revision=261790 I misspoke about it being in the nexus. On x86 it is done in the ACPI Host-PCI bridge drivers (since those have a _SEG method to know which PCI domain/segment/hose the child bus belongs to). You could conceivably do it higher up at whatever level understands which PCI domain a given Host-PCI bridge lives in. If you only ever support a single PCI domain, you could just place it in the nexus with a hardcoded domain arg of 0 to the pci_domain_*() functions. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 1/15/15 12:15 PM, Gleb Smirnoff wrote: > On Thu, Jan 15, 2015 at 08:14:30PM +0300, Gleb Smirnoff wrote: > T> I'd dare to say that such important change simply cannot be committed > T> with a thorough review from at least two people very confident in this > T> area. > > Of course, I typoed. I meant "cannot be committed withOUT a thorough review". There is something to be said for people taking time to review things and not wanting to be held up forever. However, I think it's been a clear practice with all other changes reviewed in phabric to date that the committer only lists people in 'Reviewed by' who actually signed off on the patch, not just the list of people asked to review it. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277216 - in head: etc/defaults etc/periodic/daily share/man/man5
Author: gjb
Date: Thu Jan 15 19:52:19 2015
New Revision: 277216
URL: https://svnweb.freebsd.org/changeset/base/277216
Log:
Evaluate running userland/kernel version in daily
periodic(8) run, taken from uname(1) '-U' and '-K'
flags.
Reviewed by: allanjude, dvl
Differential Revision:https://reviews.freebsd.org/D1541
MFC after:1 week
Sponsored by: The FreeBSD Foundation
Added:
head/etc/periodic/daily/510.status-world-kernel (contents, props changed)
Modified:
head/etc/defaults/periodic.conf
head/etc/periodic/daily/Makefile
head/share/man/man5/periodic.conf.5
Modified: head/etc/defaults/periodic.conf
==
--- head/etc/defaults/periodic.conf Thu Jan 15 16:27:20 2015
(r277215)
+++ head/etc/defaults/periodic.conf Thu Jan 15 19:52:19 2015
(r277216)
@@ -140,6 +140,10 @@ daily_status_ntpd_enable="NO"
# Check
daily_queuerun_enable="YES"# Run mail queue
daily_submit_queuerun="YES"# Also submit queue
+# 510.status-world-kernel
+daily_status_world_kernel="YES"# Check the
running
+ # userland/kernel
version
+
# 800.scrub-zfs
daily_scrub_zfs_enable="NO"
daily_scrub_zfs_pools="" # empty string selects all pools
Added: head/etc/periodic/daily/510.status-world-kernel
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/etc/periodic/daily/510.status-world-kernel Thu Jan 15 19:52:19
2015(r277216)
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+# Check that the running userland and kernel versions are in sync.
+
+# If there is a global system configuration file, suck it in.
+#
+if [ -r /etc/defaults/periodic.conf ]
+then
+. /etc/defaults/periodic.conf
+source_periodic_confs
+fi
+
+case "$daily_status_world_kernel" in
+[Yy][Ee][Ss])
+ rc=0
+ _U=$(/usr/bin/uname -U 2>/dev/null)
+ _K=$(/usr/bin/uname -K 2>/dev/null)
+ [ -z "${_U}" -o -z "${_K}" ] && exit 0
+ echo ""
+ echo "Checking userland and kernel versions:"
+ if [ "${_U}" != "${_K}" ]; then
+ echo "Userland and kernel are not in sync"
+ echo "Userland version: ${_U}"
+ echo "Kernel version: ${_K}"
+ rc=1
+ else
+ echo "Userland and kernel are in sync."
+ fi
+ ;;
+
+*) rc=0;;
+esac
+
+exit $rc
Modified: head/etc/periodic/daily/Makefile
==
--- head/etc/periodic/daily/MakefileThu Jan 15 16:27:20 2015
(r277215)
+++ head/etc/periodic/daily/MakefileThu Jan 15 19:52:19 2015
(r277216)
@@ -16,6 +16,7 @@ FILES=100.clean-disks \
409.status-gconcat \
420.status-network \
450.status-security \
+ 510.status-world-kernel \
999.local
# NB: keep these sorted by MK_* knobs
Modified: head/share/man/man5/periodic.conf.5
==
--- head/share/man/man5/periodic.conf.5 Thu Jan 15 16:27:20 2015
(r277215)
+++ head/share/man/man5/periodic.conf.5 Thu Jan 15 19:52:19 2015
(r277216)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd December 25, 2013
+.Dd January 15, 2015
.Dt PERIODIC.CONF 5
.Os
.Sh NAME
@@ -498,6 +498,11 @@ for yesterday's mail rejects.
Set to
.Dq Li YES
if you want to enable NTP status check.
+.It Va daily_status_world_kernel
+.Pq Vt bool
+Set to
+.Dq Li YES
+to check the running userland and kernel are in sync.
.It Va daily_queuerun_enable
.Pq Vt bool
Set to
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277163 - head/sys/dev/cardbus
On 01/15/15 10:51, John Baldwin wrote: On 1/15/15 11:20 AM, Nathan Whitehorn wrote: On 01/14/15 16:07, Warner Losh wrote: On Jan 14, 2015, at 8:32 AM, Justin Hibbits wrote: On Wed, 14 Jan 2015 09:23:05 -0500 John Baldwin wrote: On 1/14/15 12:41 AM, Warner Losh wrote: Author: imp Date: Wed Jan 14 05:41:31 2015 New Revision: 277163 URL: https://svnweb.freebsd.org/changeset/base/277163 Log: Add a rather obnoxious warning if you don't have NEW_PCIB defined since it's a total crap shoot if things will work. Should we just make it a #error instead? (Some day I hope to have NEW_PCIB enabled by default and remove the old code. Will take a while to get there for the generic PCI code, but cardbus is probably only used on x86 so that would be fine.) Also powerpc, but NEW_PCIB is default there as well. PowerPC doesn’t seem to defined the bus number resources. Warner Which ones? -Nathan PCI_RES_BUS. https://svnweb.freebsd.org/base?view=revision&revision=261790 I misspoke about it being in the nexus. On x86 it is done in the ACPI Host-PCI bridge drivers (since those have a _SEG method to know which PCI domain/segment/hose the child bus belongs to). You could conceivably do it higher up at whatever level understands which PCI domain a given Host-PCI bridge lives in. If you only ever support a single PCI domain, you could just place it in the nexus with a hardcoded domain arg of 0 to the pci_domain_*() functions. Most PPC systems have at least two and usually more PCI domains. I'll take a look at adding this. -Nathan ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/15/15 19:46, Bjoern A. Zeeb wrote: On 15 Jan 2015, at 15:32 , Hans Petter Selasky wrote: Author: hselasky Date: Thu Jan 15 15:32:30 2015 New Revision: 277213 URL: https://svnweb.freebsd.org/changeset/base/277213 Log: Major callout subsystem cleanup and rewrite: I see this for i386 and amd64 LINT* kernels. Is that a local problem or did you miss something? linking kernel addr.o: In function `set_timeout': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/addr.c:(.text+0xd37): undefined reference to `_callout_stop_safe' mad.o: In function `ib_unregister_mad_agent': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad.c:(.text+0x1ed4): undefined reference to `_callout_stop_safe' mad.o: In function `ib_mad_complete_send_wr': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad.c:(.text+0x3ea0): undefined reference to `_callout_stop_safe' cm.o: In function `ib_cm_cleanup': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/cm.c:(.text+0x40cf): undefined reference to `_callout_stop_safe' mad_rmpp.o: In function `ib_cancel_rmpp_recvs': /scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad_rmpp.c:(.text+0xc2): undefined reference to `_callout_stop_safe' mad_rmpp.o:/scratch/tmp/bz/head.svn/sys/ofed/drivers/infiniband/core/mad_rmpp.c:(.text+0xe9): more undefined references to `_callout_stop_safe' follow --- kernel --- *** [kernel] Error code 1 Hi, I think this is a local problem at your side. I get at r277215: --- kernel --- linking kernel objcopy --strip-debug kernel text data bssdec hex filename 28873399 10373165 1857376 41103940 0x2733244 kernel -- Kernel build for LINT completed on Thu Jan 15 23:07:58 IST 2015 -- When running: make -m $PWD/share/mk buildkernel WITH_OFED=YES TARGET_ARCH=i386 KERNCONF=LINT --HPS ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277217 - in head: contrib/libc++ contrib/libc++/include contrib/libc++/include/experimental contrib/libc++/include/ext contrib/libc++/src lib/libc++
Author: dim
Date: Thu Jan 15 21:17:36 2015
New Revision: 277217
URL: https://svnweb.freebsd.org/changeset/base/277217
Log:
Import libc++ trunk r224926. This fixes a number of bugs, completes
C++14 support[1], adds more C++1z features[2], and fixes the following
LWG issues[3]:
1450: Contradiction in regex_constants
2003: String exception inconsistency in erase.
2075: Progress guarantees, lock-free property, and scheduling
assumptions
2104: unique_lock move-assignment should not be noexcept
2112: User-defined classes that cannot be derived from
2132: std::function ambiguity
2135: Unclear requirement for exceptions thrown in
condition_variable::wait()
2142: packaged_task::operator() synchronization too broad?
2182: Container::[const_]reference types are misleadingly specified
2186: Incomplete action on async/launch::deferred
2188: Reverse iterator does not fully support targets that overload
operator&
2193: Default constructors for standard library containers are explicit
2205: Problematic postconditions of regex_match and regex_search
2213: Return value of std::regex_replace
2240: Probable misuse of term "function scope" in [thread.condition]
2252: Strong guarantee on vector::push_back() still broken with C++11?
2257: Simplify container requirements with the new algorithms
2258: a.erase(q1, q2) unable to directly return q2
2263: Comparing iterators and allocator pointers with different
const-character
2268: Setting a default argument in the declaration of a member
function assign of std::basic_string
2271: regex_traits::lookup_classname specification unclear
2272: quoted should use char_traits::eq for character comparison
2278: User-defined literals for Standard Library types
2280: begin / end for arrays should be constexpr and noexcept
2285: make_reverse_iterator
2288: Inconsistent requirements for shared mutexes
2291: std::hash is vulnerable to collision DoS attack
2293: Wrong facet used by num_put::do_put
2299: Effects of inaccessible key_compare::is_transparent type are not
clear
2301: Why is std::tie not constexpr?
2304: Complexity of count in unordered associative containers
2306: match_results::reference should be value_type&, not const
value_type&
2308: Clarify container destructor requirements w.r.t. std::array
2313: tuple_size should always derive from integral_constant
2314: apply() should return decltype(auto) and use decay_t before
tuple_size
2315: weak_ptr should be movable
2316: weak_ptr::lock() should be atomic
2317: The type property queries should be UnaryTypeTraits returning
size_t
2320: select_on_container_copy_construction() takes allocators, not
containers
2322: Associative(initializer_list, stuff) constructors are
underspecified
2323: vector::resize(n, t)'s specification should be simplified
2324: Insert iterator constructors should use addressof()
2329: regex_match()/regex_search() with match_results should forbid
temporary strings
2330: regex("meow", regex::icase) is technically forbidden but should
be permitted
2332: regex_iterator/regex_token_iterator should forbid temporary
regexes
2339: Wording issue in nth_element
2341: Inconsistency between basic_ostream::seekp(pos) and
basic_ostream::seekp(off, dir)
2344: quoted()'s interaction with padding is unclear
2346: integral_constant's member functions should be marked noexcept
2350: min, max, and minmax should be constexpr
2356: Stability of erasure in unordered associative containers
2357: Remaining "Assignable" requirement
2359: How does regex_constants::nosubs affect basic_regex::mark_count()?
2360: reverse_iterator::operator*() is unimplementable
[1] http://libcxx.llvm.org/cxx1y_status.html
[2] http://libcxx.llvm.org/cxx1z_status.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html
Exp-run: antoine
MFC after:1 month
Added:
head/contrib/libc++/include/__refstring
- copied unchanged from r276792, vendor/libc++/dist/include/__refstring
head/contrib/libc++/include/experimental/__config
- copied unchanged from r276792,
vendor/libc++/dist/include/experimental/__config
head/contrib/libc++/include/experimental/string_view
- copied unchanged from r276792,
vendor/libc++/dist/include/experimental/string_view
head/contrib/libc++/include/experimental/type_traits
- copied unchanged from r276792,
vendor/libc++/dist/include/experimental/type_traits
head/contrib/libc++/include/experimental/utility
- copied unchanged from r276792,
vendor/libc++/dist/include/experimental/utility
head/contrib/libc++/include/module.modulemap
- copied unchanged from r276792,
vendor/libc++/dist/include/module.modulemap
Modified:
head/contrib/libc++/CREDITS.TXT
head/contrib/libc++/LICENSE.TXT
head/contrib/libc++/include/__bit_reference
head
svn commit: r277218 - head/share/man/man4
Author: jfv Date: Thu Jan 15 21:47:02 2015 New Revision: 277218 URL: https://svnweb.freebsd.org/changeset/base/277218 Log: First draft man pages for ixl and ixlv drivers. MFC after: 1 week Added: head/share/man/man4/ixl.4 (contents, props changed) head/share/man/man4/ixlv.4 (contents, props changed) Added: head/share/man/man4/ixl.4 == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/man/man4/ixl.4 Thu Jan 15 21:47:02 2015(r277218) @@ -0,0 +1,188 @@ +.\" Copyright (c) 2013-2015, Intel Corporation +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright notice, +.\" this list of conditions and the following disclaimer. +.\" +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" +.\" 3. Neither the name of the Intel Corporation nor the names of its +.\" contributors may be used to endorse or promote products derived from +.\" this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" +.\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE +.\" LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\" POSSIBILITY OF SUCH DAMAGE. +.\" +.\" * Other names and brands may be claimed as the property of others. +.\" +.\" $FreeBSD$ +.\" +.Dd January 14, 2015 +.Dt IXL 4 +.Os +.Sh NAME +.Nm ixl +.Nd "Intel XL710 Ethernet 40Gb Base driver" +.Sh SYNOPSIS +To compile this driver into the kernel, +place the following lines in your +kernel configuration file: +.Bd -ragged -offset indent +.Cd "device ixl" +.Ed +.Pp +To load the driver as a +module at boot time, place the following lines in +.Xr loader.conf 5 : +.Bd -literal -offset indent +if_ixl_load="YES" +.Ed +.Sh DESCRIPTION +The +.Nm +driver provides support for PCI Express adapters or LOMs +in the XL710 Family of ethernet devices. +The driver supports Jumbo Frames, TX/RX checksum offload, +TCP segmentation offload (TSO), Large Receive Offload (LRO), VLAN +tag insertion/extraction, VLAN checksum offload, VLAN TSO, and +Receive Side Steering (RSS), all for both IPv4 and IPv6. +For further hardware information and questions related to hardware +requirements, see +.Pa http://support.intel.com/ . +.Pp +Support for Jumbo Frames is provided via the interface MTU setting. +Selecting an MTU larger than 1500 bytes with the +.Xr ifconfig 8 +utility configures the adapter to receive and transmit Jumbo Frames. +The maximum MTU size for Jumbo Frames is 9706. +.Pp +Offloads are also controlled via the interface, for instance, +checksumming for both IPv4 and IPv6 can be set and unset, TSO4 +and/or TSO6, and finally LRO can be set and unset. +.Pp +For more information on configuring this device, see +.Xr ifconfig 8 . +.Sh HARDWARE +The +.Nm +driver supports these SFP+ Pluggable Optics: +.Pp +.Bl -bullet -compact +.It +Intel TRIPLE RATE 1G/10G/40G QSFP+ SR (bailed) E40GQSFPSR +.It +Intel TRIPLE RATE 1G/10G/40G QSFP+ SR (bailed) E40GQSFPLR +.El +.Pp +The +.Nm +driver supports 10Gb and 1Gb Ethernet adapters with SR Modules: +.Pp +.Bl -bullet -compact +.It +Intel DUAL RATE 1G/10G SFP+ SR (bailed) FTLX8571D3BCV-IT +.It +Intel DUAL RATE 1G/10G SFP+ SR (bailed) AFBR-703SDZ-IN2 +.El +.Pp +The +.Nm +driver supports 10Gb and 1Gb Ethernet adapters with LR Modules: +.Pp +.Bl -bullet -compact +.It +Intel DUAL RATE 1G/10G SFP+ LR (bailed) FTLX1471D3BCV-IT +.It +Intel DUAL RATE 1G/10G SFP+ LR (bailed) AFCT-701SDZ-IN2 +.El +.Pp +Note that X710/XL710 Based SFP+ adapters also support all passive and active +limiting direct attach cables that comply with SFF-8431 v4.1 and +SFF-8472 v10.4 specifications. + +.Pp +.Sh LOADER TUNABLES +Tunables can be set at the +.Xr loader 8 +prompt before booting the kernel or stored in +.Xr loader.conf 5 . +.Bl -tag -width indent +.It Va hw.ixl.enable_msix +Allows one to enable/disable MSIX, thus forcing MSI instead. +.It Va hw.ixl.ringsz +Set the number of descriptors
Re: svn commit: r277218 - head/share/man/man4
On Thu, Jan 15, 2015 at 09:47:03PM +, Jack F Vogel wrote: > Author: jfv > Date: Thu Jan 15 21:47:02 2015 > New Revision: 277218 > URL: https://svnweb.freebsd.org/changeset/base/277218 > > Log: > First draft man pages for ixl and ixlv drivers. > > MFC after: 1 week > [...] > +.Nm > +driver was written by > +.An Jack Vogel Aq j...@freebsd.org ^ Missing Mt here (Mt == mailto) > +and > +.An Eric Joyner Aq ricer...@gmail.com . ^ Missing Mt here (Mt == mailto) > Same on the other manpage regards, Bapt pgpAT2P7vGrkZ.pgp Description: PGP signature
svn commit: r277219 - head/share/man/man4
Author: jfv Date: Thu Jan 15 22:17:11 2015 New Revision: 277219 URL: https://svnweb.freebsd.org/changeset/base/277219 Log: Add needed bits to the Makefile, and the Mt to the emails. Thanks to Nathan and Baptiste for the corrections :) MFC after: 1 week Modified: head/share/man/man4/Makefile head/share/man/man4/ixl.4 head/share/man/man4/ixlv.4 Modified: head/share/man/man4/Makefile == --- head/share/man/man4/MakefileThu Jan 15 21:47:02 2015 (r277218) +++ head/share/man/man4/MakefileThu Jan 15 22:17:11 2015 (r277219) @@ -217,6 +217,8 @@ MAN=aac.4 \ iwnfw.4 \ ixgb.4 \ ixgbe.4 \ + ixl.4 \ + ixlv.4 \ jme.4 \ joy.4 \ kbdmux.4 \ @@ -667,6 +669,8 @@ MLINKS+=ixgb.4 if_ixgb.4 MLINKS+=ixgbe.4 ix.4 MLINKS+=ixgbe.4 if_ix.4 MLINKS+=ixgbe.4 if_ixgbe.4 +MLINKS+=ixl.4 if_ixl.4 +MLINKS+=ixlv.4 if_ixlv.4 MLINKS+=jme.4 if_jme.4 MLINKS+=kue.4 if_kue.4 MLINKS+=lagg.4 trunk.4 Modified: head/share/man/man4/ixl.4 == --- head/share/man/man4/ixl.4 Thu Jan 15 21:47:02 2015(r277218) +++ head/share/man/man4/ixl.4 Thu Jan 15 22:17:11 2015(r277219) @@ -183,6 +183,6 @@ device driver first appeared in The .Nm driver was written by -.An Jack Vogel Aq j...@freebsd.org +.An Jack Vogel Aq Mt j...@freebsd.org and -.An Eric Joyner Aq ricer...@gmail.com . +.An Eric Joyner Aq Mt ricer...@gmail.com . Modified: head/share/man/man4/ixlv.4 == --- head/share/man/man4/ixlv.4 Thu Jan 15 21:47:02 2015(r277218) +++ head/share/man/man4/ixlv.4 Thu Jan 15 22:17:11 2015(r277219) @@ -135,6 +135,6 @@ device driver first appeared in The .Nm driver was written by -.An Jack Vogel Aq j...@freebsd.org +.An Jack Vogel Aq Mt j...@freebsd.org and -.An Eric Joyner Aq ricer...@gmail.com . +.An Eric Joyner Aq Mt ricer...@gmail.com . ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277215 - in head/sys: amd64/include boot/common boot/fdt boot/forth boot/i386/libi386 boot/i386/loader i386/include x86/xen
On Thu, 2015-01-15 at 16:27 +, Roger Pau Monné wrote: > Author: royger > Date: Thu Jan 15 16:27:20 2015 > New Revision: 277215 > URL: https://svnweb.freebsd.org/changeset/base/277215 > > Log: > loader: implement multiboot support for Xen Dom0 > [...] > > Added: > head/sys/boot/i386/libi386/multiboot.c (contents, props changed) > head/sys/boot/i386/libi386/multiboot.h (contents, props changed) > head/sys/boot/i386/libi386/multiboot_tramp.S (contents, props changed) > Modified: > head/sys/amd64/include/metadata.h > head/sys/boot/common/bootstrap.h > head/sys/boot/common/load_elf.c > head/sys/boot/common/load_elf_obj.c > head/sys/boot/common/module.c > head/sys/boot/fdt/fdt_loader_cmd.c > head/sys/boot/forth/beastie.4th > head/sys/boot/forth/loader.4th > head/sys/boot/forth/support.4th > head/sys/boot/i386/libi386/Makefile > head/sys/boot/i386/libi386/bootinfo64.c > head/sys/boot/i386/libi386/elf64_freebsd.c > head/sys/boot/i386/libi386/libi386.h > head/sys/boot/i386/loader/conf.c > head/sys/i386/include/metadata.h > head/sys/x86/xen/pv.c Something about this change breaks ubldr on arm (it works @ r277214). Now on an RPi I get this: /boot/kernel/kernel data=0x4cf8a4+0x3475c syms=[0x4+0x91650+0x4+0x53354] panic: Address offset 0x4000 bigger than size 0x1E00 There is a single physical extent of ram from 0-0x1e00. -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277225 - in head/sys: conf modules/cxgbe/if_cxgbe
Author: np
Date: Fri Jan 16 01:28:28 2015
New Revision: 277225
URL: https://svnweb.freebsd.org/changeset/base/277225
Log:
Make cxgbe(4) buildable with the gcc in base.
Modified:
head/sys/conf/files
head/sys/modules/cxgbe/if_cxgbe/Makefile
Modified: head/sys/conf/files
==
--- head/sys/conf/files Thu Jan 15 23:03:24 2015(r277224)
+++ head/sys/conf/files Fri Jan 16 01:28:28 2015(r277225)
@@ -1141,7 +1141,7 @@ dev/cxgb/sys/uipc_mvec.c optional cxgb p
dev/cxgb/cxgb_t3fw.c optional cxgb cxgb_t3fw \
compile-with "${NORMAL_C} -I$S/dev/cxgb"
dev/cxgbe/t4_mp_ring.c optional cxgbe pci \
- compile-with "${NORMAL_C} -I$S/dev/cxgbe"
+ compile-with "${NORMAL_C} -I$S/dev/cxgbe -fms-extensions"
dev/cxgbe/t4_main.coptional cxgbe pci \
compile-with "${NORMAL_C} -I$S/dev/cxgbe"
dev/cxgbe/t4_netmap.c optional cxgbe pci \
Modified: head/sys/modules/cxgbe/if_cxgbe/Makefile
==
--- head/sys/modules/cxgbe/if_cxgbe/MakefileThu Jan 15 23:03:24 2015
(r277224)
+++ head/sys/modules/cxgbe/if_cxgbe/MakefileFri Jan 16 01:28:28 2015
(r277225)
@@ -23,6 +23,6 @@ SRCS+=t4_tracer.c
# Provide the timestamp of a packet in its header mbuf.
#CFLAGS+= -DT4_PKT_TIMESTAMP
-CFLAGS+= -I${CXGBE}
+CFLAGS+= -I${CXGBE} -fms-extensions
.include
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277226 - head/sys/dev/cxgbe
Author: np
Date: Fri Jan 16 01:32:40 2015
New Revision: 277226
URL: https://svnweb.freebsd.org/changeset/base/277226
Log:
Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a
subset
of i386 systems.
Modified:
head/sys/dev/cxgbe/t4_main.c
head/sys/dev/cxgbe/t4_mp_ring.c
Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cFri Jan 16 01:28:28 2015
(r277225)
+++ head/sys/dev/cxgbe/t4_main.cFri Jan 16 01:32:40 2015
(r277226)
@@ -668,6 +668,14 @@ t4_attach(device_t dev)
goto done;
}
+#if defined(__i386__)
+ if ((cpu_feature & CPUID_CX8) == 0) {
+ device_printf(dev, "64 bit atomics not available.\n");
+ rc = ENOTSUP;
+ goto done;
+ }
+#endif
+
/* Prepare the firmware for operation */
rc = prep_firmware(sc);
if (rc != 0)
Modified: head/sys/dev/cxgbe/t4_mp_ring.c
==
--- head/sys/dev/cxgbe/t4_mp_ring.c Fri Jan 16 01:28:28 2015
(r277225)
+++ head/sys/dev/cxgbe/t4_mp_ring.c Fri Jan 16 01:32:40 2015
(r277226)
@@ -38,6 +38,11 @@ __FBSDID("$FreeBSD$");
#include "t4_mp_ring.h"
+#if defined(__i386__)
+#define atomic_cmpset_acq_64 atomic_cmpset_64
+#define atomic_cmpset_rel_64 atomic_cmpset_64
+#endif
+
union ring_state {
struct {
uint16_t pidx_head;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277227 - in head/sys: amd64/conf arm/conf conf modules powerpc/conf
Author: np
Date: Fri Jan 16 01:39:24 2015
New Revision: 277227
URL: https://svnweb.freebsd.org/changeset/base/277227
Log:
Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it
on amd64 only.
Modified:
head/sys/amd64/conf/NOTES
head/sys/arm/conf/NOTES
head/sys/conf/NOTES
head/sys/modules/Makefile
head/sys/powerpc/conf/NOTES
Modified: head/sys/amd64/conf/NOTES
==
--- head/sys/amd64/conf/NOTES Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/amd64/conf/NOTES Fri Jan 16 01:39:24 2015(r277227)
@@ -300,7 +300,6 @@ options DRM_DEBUG # Include debug print
# bxe: Broadcom NetXtreme II (BCM5771X/BCM578XX) PCIe 10Gb Ethernet
# adapters.
-# cxgbe: Chelsio T4/T5 1GbE/10GbE/40GbE PCIe Ethernet adapters
# ed: Western Digital and SMC 80xx; Novell NE1000 and NE2000; 3Com 3C503
# HP PC Lan+, various PC Card devices
# (requires miibus)
@@ -323,7 +322,6 @@ options DRM_DEBUG # Include debug print
# Requires the wpi firmware module
device bxe # Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE
-device cxgbe # Chelsio T4/T5 1GbE/10GbE/40GbE
device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards
optionsED_3C503
optionsED_HPP
Modified: head/sys/arm/conf/NOTES
==
--- head/sys/arm/conf/NOTES Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/arm/conf/NOTES Fri Jan 16 01:39:24 2015(r277227)
@@ -82,6 +82,7 @@ nodevice snake_saver
nodevice star_saver
nodevice warp_saver
+nodevice cxgbe
nodevice pcii
nodevice snd_cmi
nodevice tnt4882
Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/conf/NOTES Fri Jan 16 01:39:24 2015(r277227)
@@ -1917,6 +1917,8 @@ devicexmphy # XaQti XMAC II
# cas: Sun Cassini/Cassini+ and National Semiconductor DP83065 Saturn
# cm: Arcnet SMC COM90c26 / SMC COM90c56
# (and SMC COM90c66 in '56 compatibility mode) adapters.
+# cxgb: Chelsio T3 based 1GbE/10GbE PCIe Ethernet adapters.
+# cxgbe:Chelsio T4 and T5 based 1GbE/10GbE/40GbE PCIe Ethernet adapters.
# dc: Support for PCI fast ethernet adapters based on the DEC/Intel 21143
# and various workalikes including:
# the ADMtek AL981 Comet and AN985 Centaur, the ASIX Electronics
@@ -2065,6 +2067,7 @@ devicebge # Broadcom BCM570xx
Gigabit
device cas # Sun Cassini/Cassini+ and NS DP83065 Saturn
device cxgb# Chelsio T3 10 Gigabit Ethernet
device cxgb_t3fw # Chelsio T3 10 Gigabit Ethernet firmware
+device cxgbe # Chelsio T4 and T5 1GbE/10GbE/40GbE
device dc # DEC/Intel 21143 and various workalikes
device et # Agere ET1310 10/100/Gigabit Ethernet
device fxp # Intel EtherExpress PRO/100B (82557, 82558)
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/modules/Makefile Fri Jan 16 01:39:24 2015(r277227)
@@ -443,7 +443,8 @@ _ti=ti
_txp= txp
.endif
-.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} == "amd64"
+.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
+ ${MACHINE_CPUARCH} != "powerpc"
_cxgbe=cxgbe
.endif
Modified: head/sys/powerpc/conf/NOTES
==
--- head/sys/powerpc/conf/NOTES Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/powerpc/conf/NOTES Fri Jan 16 01:39:24 2015(r277227)
@@ -57,6 +57,7 @@ deviceadm1030 # Apple G4 MDD fan cont
# Devices we don't want to deal with
nodevice bktr
+nodevice cxgbe # XXX: builds on powerpc64 only.
nodevice fdc
nodevice ppc
nodevice splash
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277228 - head/sys/dev/ath
Author: adrian Date: Fri Jan 16 01:52:26 2015 New Revision: 277228 URL: https://svnweb.freebsd.org/changeset/base/277228 Log: Check the right value correctly. Thanks to clang for pointing out this silliness. Modified: head/sys/dev/ath/if_ath.c Modified: head/sys/dev/ath/if_ath.c == --- head/sys/dev/ath/if_ath.c Fri Jan 16 01:39:24 2015(r277227) +++ head/sys/dev/ath/if_ath.c Fri Jan 16 01:52:26 2015(r277228) @@ -7024,7 +7024,7 @@ ath_tx_update_tim(struct ath_softc *sc, /* * Don't bother grabbing the lock unless the queue is empty. */ - if (&an->an_swq_depth != 0) + if (an->an_swq_depth != 0) return; if (an->an_is_powersave && ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277229 - head/sys/ofed/include/linux
Author: np
Date: Fri Jan 16 02:20:24 2015
New Revision: 277229
URL: https://svnweb.freebsd.org/changeset/base/277229
Log:
Use parentheses instead of close proximity to ensure layer + 1 is evaluated
before the rest of the expression.
Modified:
head/sys/ofed/include/linux/linux_idr.c
Modified: head/sys/ofed/include/linux/linux_idr.c
==
--- head/sys/ofed/include/linux/linux_idr.c Fri Jan 16 01:52:26 2015
(r277228)
+++ head/sys/ofed/include/linux/linux_idr.c Fri Jan 16 02:20:24 2015
(r277229)
@@ -408,7 +408,7 @@ restart:
* to be rare.
*/
if (idx == IDR_SIZE) {
- starting_id = id + (1 << (layer+1 * IDR_BITS));
+ starting_id = id + (1 << ((layer + 1) * IDR_BITS));
goto restart;
}
if (idx > sidx)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277227 - in head/sys: amd64/conf arm/conf conf modules powerpc/conf
On 01/15/15 17:39, Navdeep Parhar wrote:
Author: np
Date: Fri Jan 16 01:39:24 2015
New Revision: 277227
URL: https://svnweb.freebsd.org/changeset/base/277227
Log:
Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it
on amd64 only.
Modified:
head/sys/amd64/conf/NOTES
head/sys/arm/conf/NOTES
head/sys/conf/NOTES
head/sys/modules/Makefile
head/sys/powerpc/conf/NOTES
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/modules/Makefile Fri Jan 16 01:39:24 2015(r277227)
@@ -443,7 +443,8 @@ _ti=ti
_txp= txp
.endif
-.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} == "amd64"
+.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
+ ${MACHINE_CPUARCH} != "powerpc"
_cxgbe= cxgbe
.endif
Don't you want MACHINE_ARCH != powerpc here rather than MACHINE_CPUARCH
if it builds on powerpc64?
-Nathan
Modified: head/sys/powerpc/conf/NOTES
==
--- head/sys/powerpc/conf/NOTES Fri Jan 16 01:32:40 2015(r277226)
+++ head/sys/powerpc/conf/NOTES Fri Jan 16 01:39:24 2015(r277227)
@@ -57,6 +57,7 @@ deviceadm1030 # Apple G4 MDD fan cont
# Devices we don't want to deal with
nodevice bktr
+nodevice cxgbe # XXX: builds on powerpc64 only.
nodevice fdc
nodevice ppc
nodevice splash
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r277227 - in head/sys: amd64/conf arm/conf conf modules powerpc/conf
On Thu, Jan 15, 2015 at 06:34:31PM -0800, Nathan Whitehorn wrote:
>
> On 01/15/15 17:39, Navdeep Parhar wrote:
> >Author: np
> >Date: Fri Jan 16 01:39:24 2015
> >New Revision: 277227
> >URL: https://svnweb.freebsd.org/changeset/base/277227
> >
> >Log:
> > Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it
> > on amd64 only.
> >
> >Modified:
> > head/sys/amd64/conf/NOTES
> > head/sys/arm/conf/NOTES
> > head/sys/conf/NOTES
> > head/sys/modules/Makefile
> > head/sys/powerpc/conf/NOTES
> >
> >
> >
> >Modified: head/sys/modules/Makefile
> >==
> >--- head/sys/modules/MakefileFri Jan 16 01:32:40 2015
> >(r277226)
> >+++ head/sys/modules/MakefileFri Jan 16 01:39:24 2015
> >(r277227)
> >@@ -443,7 +443,8 @@ _ti= ti
> > _txp= txp
> > .endif
> >-.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} == "amd64"
> >+.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
> >+${MACHINE_CPUARCH} != "powerpc"
> > _cxgbe=cxgbe
> > .endif
>
> Don't you want MACHINE_ARCH != powerpc here rather than
> MACHINE_CPUARCH if it builds on powerpc64?
> -Nathan
Hmm, I think you're right. I'll try building with MACHINE_ARCH and commit if
it succeeds.
Regards,
Navdeep
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277230 - head/sys/modules
Author: np
Date: Fri Jan 16 03:39:38 2015
New Revision: 277230
URL: https://svnweb.freebsd.org/changeset/base/277230
Log:
Build cxgbe(4) on powerpc64 too.
Modified:
head/sys/modules/Makefile
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Jan 16 02:20:24 2015(r277229)
+++ head/sys/modules/Makefile Fri Jan 16 03:39:38 2015(r277230)
@@ -444,7 +444,7 @@ _txp= txp
.endif
.if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
- ${MACHINE_CPUARCH} != "powerpc"
+ ${MACHINE_ARCH} != "powerpc"
_cxgbe=cxgbe
.endif
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277232 - head/sys/dev/pccbb
Author: imp
Date: Fri Jan 16 06:19:08 2015
New Revision: 277232
URL: https://svnweb.freebsd.org/changeset/base/277232
Log:
Back out the refactor. It turns out to cause interrupt storms on
resume sometimes (but not others). On powerup, other wierd issues show
up (sometimes the card comes up, but with really bogus pci config
space stuff. There may be more, but given my experience of historical
fussiness, stick to what works and make more minimal changes to that.
Modified:
head/sys/dev/pccbb/pccbb.c
head/sys/dev/pccbb/pccbb_isa.c
head/sys/dev/pccbb/pccbb_pci.c
head/sys/dev/pccbb/pccbbvar.h
Modified: head/sys/dev/pccbb/pccbb.c
==
--- head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:05 2015(r277231)
+++ head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:08 2015(r277232)
@@ -477,7 +477,7 @@ cbb_event_thread(void *arg)
*/
mtx_lock(&Giant);
status = cbb_get(sc, CBB_SOCKET_STATE);
- DEVPRINTF((sc->dev, "Status is %#x\n", status));
+ DPRINTF(("Status is 0x%x\n", status));
if (!CBB_CARD_PRESENT(status)) {
not_a_card = 0; /* We know card type */
cbb_removal(sc);
@@ -800,14 +800,13 @@ cbb_power(device_t brdev, int volts)
if (on) {
mtx_lock(&sc->mtx);
cnt = sc->powerintr;
-
/*
* We have a shortish timeout of 500ms here. Some bridges do
-* not generate a POWER_CYCLE event for 16-bit cards. In those
-* cases, we have to cope the best we can, and having only a
-* short delay is better than the alternatives. Others raise
-* the power cycle a smidge before it is really ready. We deal
-* with those below.
+* not generate a POWER_CYCLE event for 16-bit cards. In
+* those cases, we have to cope the best we can, and having
+* only a short delay is better than the alternatives. Others
+* raise the power cycle a smidge before it is really ready.
+* We deal with those below.
*/
sane = 10;
while (!(cbb_get(sc, CBB_SOCKET_STATE) & CBB_STATE_POWER_CYCLE)
&&
@@ -817,18 +816,19 @@ cbb_power(device_t brdev, int volts)
/*
* Relax for 100ms. Some bridges appear to assert this signal
-* right away, but before the card has stabilized. Other cards
-* need need more time to cope up reliabily. Experiments with
-* troublesome setups show this to be a "cheap" way to enhance
-* reliabilty.
+* right away, but before the card has stabilized. Other
+* cards need need more time to cope up reliabily.
+* Experiments with troublesome setups show this to be a
+* "cheap" way to enhance reliabilty. We need not do this for
+* "off" since we don't touch the card after we turn it off.
*/
pause("cbbPwr", min(hz / 10, 1));
/*
-* The TOPIC95B requires a little bit extra time to get its act
-* together, so delay for an additional 100ms. Also as
-* documented below, it doesn't seem to set the POWER_CYCLE bit,
-* so don't whine if it never came on.
+* The TOPIC95B requires a little bit extra time to get its
+* act together, so delay for an additional 100ms. Also as
+* documented below, it doesn't seem to set the POWER_CYCLE
+* bit, so don't whine if it never came on.
*/
if (sc->chipset == CB_TOPIC95)
pause("cbb95B", hz / 10);
@@ -838,27 +838,26 @@ cbb_power(device_t brdev, int volts)
/*
* After the power is good, we can turn off the power interrupt.
-* However, the PC Card standard says that we must delay turning the CD
-* bit back on for a bit to allow for bouncyness on power down. We just
-* pause a little below to cover that. Most bridges don't seem to need
-* this delay.
+* However, the PC Card standard says that we must delay turning the
+* CD bit back on for a bit to allow for bouncyness on power down
+* (recall that we don't wait above for a power down, since we don't
+* get an interrupt for that). We're called either from the suspend
+* code in which case we don't want to turn card change on again, or
+* we're called from the card insertion code, in which case the cbb
+* thread will turn it on for us before it waits to be woken by a
+* change event.
*
-* NB: Topic95B doesn't set the
svn commit: r277234 - head/sys/dev/pccbb
Author: imp
Date: Fri Jan 16 06:19:39 2015
New Revision: 277234
URL: https://svnweb.freebsd.org/changeset/base/277234
Log:
Move the suspsned and resume functions to the bus attachment. They
were accessing PCI config registers, which won't work for the ISA
version.
Modified:
head/sys/dev/pccbb/pccbb.c
head/sys/dev/pccbb/pccbb_isa.c
head/sys/dev/pccbb/pccbb_pci.c
head/sys/dev/pccbb/pccbbvar.h
Modified: head/sys/dev/pccbb/pccbb.c
==
--- head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:24 2015(r277233)
+++ head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:39 2015(r277234)
@@ -1563,61 +1563,6 @@ cbb_write_ivar(device_t brdev, device_t
}
int
-cbb_suspend(device_t brdev)
-{
- int error = 0;
- struct cbb_softc*sc = device_get_softc(brdev);
-
- error = bus_generic_suspend(brdev);
- if (error != 0)
- return (error);
- cbb_set(sc, CBB_SOCKET_MASK, 0);/* Quiet hardware */
- sc->cardok = 0; /* Card is bogus now */
- return (0);
-}
-
-int
-cbb_resume(device_t brdev)
-{
- int error = 0;
- struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev);
- uint32_t tmp;
-
- /*
-* In the APM and early ACPI era, BIOSes saved the PCI config
-* registers. As chips became more complicated, that functionality moved
-* into the ACPI code / tables. We must therefore, restore the settings
-* we made here to make sure the device come back. Transitions to Dx
-* from D0 and back to D0 cause the bridge to lose its config space, so
-* all the bus mappings and such are preserved.
-*
-* For most drivers, the PCI layer handles this saving. However, since
-* there's much black magic and arcane art hidden in these few lines of
-* code that would be difficult to transition into the PCI
-* layer. chipinit was several years of trial and error to write.
-*/
- pci_write_config(brdev, CBBR_SOCKBASE, rman_get_start(sc->base_res), 4);
- DEVPRINTF((brdev, "PCI Memory allocated: %08lx\n",
- rman_get_start(sc->base_res)));
-
- sc->chipinit(sc);
-
- /* reset interrupt -- Do we really need to do this? */
- tmp = cbb_get(sc, CBB_SOCKET_EVENT);
- cbb_set(sc, CBB_SOCKET_EVENT, tmp);
-
- /* CSC Interrupt: Card detect interrupt on */
- cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD);
-
- /* Signal the thread to wakeup. */
- wakeup(&sc->intrhand);
-
- error = bus_generic_resume(brdev);
-
- return (error);
-}
-
-int
cbb_child_present(device_t parent, device_t child)
{
struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(parent);
Modified: head/sys/dev/pccbb/pccbb_isa.c
==
--- head/sys/dev/pccbb/pccbb_isa.c Fri Jan 16 06:19:24 2015
(r277233)
+++ head/sys/dev/pccbb/pccbb_isa.c Fri Jan 16 06:19:39 2015
(r277234)
@@ -203,13 +203,25 @@ cbb_isa_attach(device_t dev)
return (ENOMEM);
}
+static int
+cbb_isa_suspend(device_t dev)
+{
+ return (0);
+}
+
+static int
+cbb_isa_resume(device_t dev)
+{
+ return (0);
+}
+
static device_method_t cbb_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, cbb_isa_probe),
DEVMETHOD(device_attach,cbb_isa_attach),
DEVMETHOD(device_detach,cbb_detach),
- DEVMETHOD(device_suspend, cbb_suspend),
- DEVMETHOD(device_resume,cbb_resume),
+ DEVMETHOD(device_suspend, cbb_isa_suspend),
+ DEVMETHOD(device_resume,cbb_isa_resume),
/* bus methods */
DEVMETHOD(bus_read_ivar,cbb_read_ivar),
Modified: head/sys/dev/pccbb/pccbb_pci.c
==
--- head/sys/dev/pccbb/pccbb_pci.c Fri Jan 16 06:19:24 2015
(r277233)
+++ head/sys/dev/pccbb/pccbb_pci.c Fri Jan 16 06:19:39 2015
(r277234)
@@ -877,14 +877,69 @@ cbb_write_config(device_t brdev, u_int b
b, s, f, reg, val, width);
}
+static int
+cbb_pci_suspend(device_t brdev)
+{
+ int error = 0;
+ struct cbb_softc*sc = device_get_softc(brdev);
+
+ error = bus_generic_suspend(brdev);
+ if (error != 0)
+ return (error);
+ cbb_set(sc, CBB_SOCKET_MASK, 0);/* Quiet hardware */
+ sc->cardok = 0; /* Card is bogus now */
+ return (0);
+}
+
+static int
+cbb_pci_resume(device_t brdev)
+{
+ int error = 0;
+ struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev);
+ uint32_t tmp;
+
+ /*
+* In
svn commit: r277233 - head/sys/dev/pccbb
Author: imp
Date: Fri Jan 16 06:19:24 2015
New Revision: 277233
URL: https://svnweb.freebsd.org/changeset/base/277233
Log:
Suspend and resume were the only two functions not to follow the brdev
convention here, so fix that.
Modified:
head/sys/dev/pccbb/pccbb.c
Modified: head/sys/dev/pccbb/pccbb.c
==
--- head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:08 2015(r277232)
+++ head/sys/dev/pccbb/pccbb.c Fri Jan 16 06:19:24 2015(r277233)
@@ -1563,12 +1563,12 @@ cbb_write_ivar(device_t brdev, device_t
}
int
-cbb_suspend(device_t self)
+cbb_suspend(device_t brdev)
{
int error = 0;
- struct cbb_softc*sc = device_get_softc(self);
+ struct cbb_softc*sc = device_get_softc(brdev);
- error = bus_generic_suspend(self);
+ error = bus_generic_suspend(brdev);
if (error != 0)
return (error);
cbb_set(sc, CBB_SOCKET_MASK, 0);/* Quiet hardware */
@@ -1577,10 +1577,10 @@ cbb_suspend(device_t self)
}
int
-cbb_resume(device_t self)
+cbb_resume(device_t brdev)
{
int error = 0;
- struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(self);
+ struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev);
uint32_t tmp;
/*
@@ -1596,8 +1596,8 @@ cbb_resume(device_t self)
* code that would be difficult to transition into the PCI
* layer. chipinit was several years of trial and error to write.
*/
- pci_write_config(self, CBBR_SOCKBASE, rman_get_start(sc->base_res), 4);
- DEVPRINTF((self, "PCI Memory allocated: %08lx\n",
+ pci_write_config(brdev, CBBR_SOCKBASE, rman_get_start(sc->base_res), 4);
+ DEVPRINTF((brdev, "PCI Memory allocated: %08lx\n",
rman_get_start(sc->base_res)));
sc->chipinit(sc);
@@ -1612,7 +1612,7 @@ cbb_resume(device_t self)
/* Signal the thread to wakeup. */
wakeup(&sc->intrhand);
- error = bus_generic_resume(self);
+ error = bus_generic_resume(brdev);
return (error);
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277231 - head/sys/modules
Author: imp
Date: Fri Jan 16 06:19:05 2015
New Revision: 277231
URL: https://svnweb.freebsd.org/changeset/base/277231
Log:
Add back a couple PC Card devices to amd64. There's only a couple of
them that were popular enough, so this doesn't adversly affect build
times.
Modified:
head/sys/modules/Makefile
Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile Fri Jan 16 03:39:38 2015(r277230)
+++ head/sys/modules/Makefile Fri Jan 16 06:19:05 2015(r277231)
@@ -474,6 +474,7 @@ _cardbus= cardbus
_cbb= cbb
_cpuctl= cpuctl
_cpufreq= cpufreq
+_cs= cs
_dpms= dpms
_drm= drm
_drm2= drm2
@@ -482,9 +483,11 @@ _dtrace= dtrace
.endif
_ed= ed
_em= em
+_ep= ep
_et= et
_exca= exca
_ext2fs= ext2fs
+_fe= fe
_filemon= filemon
_i2c= i2c
.if ${MK_OFED} != "no" || defined(ALL_MODULES)
@@ -519,6 +522,7 @@ _vmware=vmware
_vxge= vxge
_wbwd= wbwd
_wi= wi
+_xe= xe
.if ${MK_ZFS} != "no" || defined(ALL_MODULES)
_zfs= zfs
.endif
@@ -625,10 +629,7 @@ _coff= coff
.if ${MK_SOURCELESS_UCODE} != "no"
_cp= cp
.endif
-_cs= cs
_elink=elink
-_ep= ep
-_fe= fe
_glxiic= glxiic
_glxsb=glxsb
_ibcs2=ibcs2
@@ -644,7 +645,6 @@ _streams= streams
_stg= stg
_svr4= svr4
_wds= wds
-_xe= xe
.if ${MACHINE} == "i386"
.if ${MK_EISA} != "no"
_ahb= ahb
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277235 - head/sys/dev/pccbb
Author: imp
Date: Fri Jan 16 06:19:52 2015
New Revision: 277235
URL: https://svnweb.freebsd.org/changeset/base/277235
Log:
Always enable I/O, memory and dma cycles. Some BIOSes don't enable
them, sometimes they are reset for power state transitions or during
whatever happens while suspended. Also, it is good practice to always
do this.
Modified:
head/sys/dev/pccbb/pccbb_pci.c
Modified: head/sys/dev/pccbb/pccbb_pci.c
==
--- head/sys/dev/pccbb/pccbb_pci.c Fri Jan 16 06:19:39 2015
(r277234)
+++ head/sys/dev/pccbb/pccbb_pci.c Fri Jan 16 06:19:52 2015
(r277235)
@@ -479,10 +479,10 @@ cbb_chipinit(struct cbb_softc *sc)
pci_write_config(sc->dev, PCIR_SECBUS_2, sc->bus.sec, 1);
pci_write_config(sc->dev, PCIR_SUBBUS_2, sc->bus.sub, 1);
- /* Enable memory access */
+ /* Enable DMA, memory access for this card and I/O acces for children */
pci_enable_busmaster(sc->dev);
- /* XXX: This should not be necessary, but some chipsets require it */
- PCI_MASK_CONFIG(sc->dev, PCIR_COMMAND, | PCIM_CMD_PORTEN, 2);
+ pci_enable_io(sc->dev, SYS_RES_IOPORT);
+ pci_enable_io(sc->dev, SYS_RES_MEMORY);
/* disable Legacy IO */
switch (sc->chipset) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r277236 - head/sys/kern
Author: kib Date: Fri Jan 16 07:06:58 2015 New Revision: 277236 URL: https://svnweb.freebsd.org/changeset/base/277236 Log: For sigaction(2), ignore possible garbage in sa_flags for sa_handler == SIG_DFL or SIG_IGN. Sloppy code does not fully initialize struct sigaction for such cases, and being too demanding in the case of default handler does not catch anything. Reported and tested by: Alex Tutubalin Sponsored by: The FreeBSD Foundation MFC after:1 week Modified: head/sys/kern/kern_sig.c Modified: head/sys/kern/kern_sig.c == --- head/sys/kern/kern_sig.cFri Jan 16 06:19:52 2015(r277235) +++ head/sys/kern/kern_sig.cFri Jan 16 07:06:58 2015(r277236) @@ -653,9 +653,10 @@ kern_sigaction(td, sig, act, oact, flags if (!_SIG_VALID(sig)) return (EINVAL); - if (act != NULL && (act->sa_flags & ~(SA_ONSTACK | SA_RESTART | - SA_RESETHAND | SA_NOCLDSTOP | SA_NODEFER | SA_NOCLDWAIT | - SA_SIGINFO)) != 0) + if (act != NULL && act->sa_handler != SIG_DFL && + act->sa_handler != SIG_IGN && (act->sa_flags & ~(SA_ONSTACK | + SA_RESTART | SA_RESETHAND | SA_NOCLDSTOP | SA_NODEFER | + SA_NOCLDWAIT | SA_SIGINFO)) != 0) return (EINVAL); PROC_LOCK(p); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
