svn commit: r260184 - head/sys/dev/usb/controller
Author: hselasky
Date: Thu Jan 2 08:02:57 2014
New Revision: 260184
URL: http://svnweb.freebsd.org/changeset/base/260184
Log:
Minor correction for the XHCI reset logic.
MFC after:1 week
Found by: Horse Ma
Modified:
head/sys/dev/usb/controller/xhci.c
Modified: head/sys/dev/usb/controller/xhci.c
==
--- head/sys/dev/usb/controller/xhci.c Thu Jan 2 07:34:36 2014
(r260183)
+++ head/sys/dev/usb/controller/xhci.c Thu Jan 2 08:02:57 2014
(r260184)
@@ -386,8 +386,8 @@ xhci_start_controller(struct xhci_softc
for (i = 0; i != 100; i++) {
usb_pause_mtx(NULL, hz / 100);
- temp = XREAD4(sc, oper, XHCI_USBCMD) &
- (XHCI_CMD_HCRST | XHCI_STS_CNR);
+ temp = (XREAD4(sc, oper, XHCI_USBCMD) & XHCI_CMD_HCRST) |
+ (XREAD4(sc, oper, XHCI_USBSTS) & XHCI_STS_CNR);
if (!temp)
break;
}
___
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: r260185 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
Author: delphij
Date: Thu Jan 2 08:10:35 2014
New Revision: 260185
URL: http://svnweb.freebsd.org/changeset/base/260185
Log:
MFV r260155:
When we encounter an I/O error on a piece of metadata while deleting
a file system or zvol, we don't update the bptree_entry_phys_t's
bookmark. This would lead to double free of bp's which will lead to
space map corruption.
Instead of tolerating and allowing the corruption, panic immediately.
See Illumos #4390 for more details.
4391 panic system rather than corrupting pool if we hit bug 4390
Illumos/illumos-gate@8b36997aa24d9817807faa4efa301ac9c07a2b78
MFC after:2 weeks
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bptree.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_debug.h
Directory Properties:
head/sys/cddl/contrib/opensolaris/ (props changed)
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bptree.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bptree.cThu Jan
2 08:02:57 2014(r260184)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bptree.cThu Jan
2 08:10:35 2014(r260185)
@@ -180,6 +180,7 @@ bptree_iterate(objset_t *os, uint64_t ob
err = 0;
for (i = ba.ba_phys->bt_begin; i < ba.ba_phys->bt_end; i++) {
bptree_entry_phys_t bte;
+ int flags = TRAVERSE_PREFETCH_METADATA | TRAVERSE_POST;
ASSERT(!free || i == ba.ba_phys->bt_begin);
@@ -188,13 +189,13 @@ bptree_iterate(objset_t *os, uint64_t ob
if (err != 0)
break;
+ if (zfs_recover)
+ flags |= TRAVERSE_HARD;
err = traverse_dataset_destroyed(os->os_spa, &bte.be_bp,
- bte.be_birth_txg, &bte.be_zb,
- TRAVERSE_PREFETCH_METADATA | TRAVERSE_POST,
+ bte.be_birth_txg, &bte.be_zb, flags,
bptree_visit_cb, &ba);
if (free) {
- ASSERT(err == 0 || err == ERESTART);
- if (err != 0) {
+ if (err == ERESTART) {
/* save bookmark for future resume */
ASSERT3U(bte.be_zb.zb_objset, ==,
ZB_DESTROYED_OBJSET);
@@ -202,11 +203,21 @@ bptree_iterate(objset_t *os, uint64_t ob
dmu_write(os, obj, i * sizeof (bte),
sizeof (bte), &bte, tx);
break;
- } else {
- ba.ba_phys->bt_begin++;
- (void) dmu_free_range(os, obj,
- i * sizeof (bte), sizeof (bte), tx);
}
+ if (err != 0) {
+ /*
+* We can not properly handle an i/o
+* error, because the traversal code
+* does not know how to resume from an
+* arbitrary bookmark.
+*/
+ zfs_panic_recover("error %u from "
+ "traverse_dataset_destroyed()", err);
+ }
+
+ ba.ba_phys->bt_begin++;
+ (void) dmu_free_range(os, obj,
+ i * sizeof (bte), sizeof (bte), tx);
}
}
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c Thu Jan
2 08:02:57 2014(r260184)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c Thu Jan
2 08:10:35 2014(r260185)
@@ -383,7 +383,7 @@ traverse_visitbp(traverse_data_t *td, co
(void) arc_buf_remove_ref(buf, &buf);
post:
- if (err == 0 && lasterr == 0 && (td->td_flags & TRAVERSE_POST)) {
+ if (err == 0 && (td->td_flags & TRAVERSE_POST)) {
err = td->td_func(td->td_spa, NULL, bp, zb, dnp, td->td_arg);
if (err == ERESTART)
pause = B_TRUE;
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_scan.c Thu Jan
2 08:02:57 2014(r260184)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_
svn commit: r260186 - head/sys/netgraph/netflow
Author: delphij Date: Thu Jan 2 08:39:47 2014 New Revision: 260186 URL: http://svnweb.freebsd.org/changeset/base/260186 Log: Fix !INET6 build for various platforms. Modified: head/sys/netgraph/netflow/netflow.c Modified: head/sys/netgraph/netflow/netflow.c == --- head/sys/netgraph/netflow/netflow.c Thu Jan 2 08:10:35 2014 (r260185) +++ head/sys/netgraph/netflow/netflow.c Thu Jan 2 08:39:47 2014 (r260186) @@ -278,7 +278,9 @@ ng_netflow_copyinfo(priv_p priv, struct i->nfinfo_inact_exp = counter_u64_fetch(priv->nfinfo_inact_exp); i->nfinfo_used = uma_zone_get_cur(priv->zone); +#ifdef INET6 i->nfinfo_used6 = uma_zone_get_cur(priv->zone6); +#endif i->nfinfo_alloc_failed = priv->nfinfo_alloc_failed; i->nfinfo_export_failed = priv->nfinfo_export_failed; ___ 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: r260187 - in head/sys: netinet netinet6
Author: ae
Date: Thu Jan 2 08:40:37 2014
New Revision: 260187
URL: http://svnweb.freebsd.org/changeset/base/260187
Log:
lla_lookup() does modification only when LLE_CREATE is specified.
Thus we can use IF_AFDATA_RLOCK() instead of IF_AFDATA_LOCK() when doing
lla_lookup() without LLE_CREATE flag.
Reviewed by: glebius, adrian
MFC after:1 week
Sponsored by: Yandex LLC
Modified:
head/sys/netinet/if_ether.c
head/sys/netinet6/nd6.c
head/sys/netinet6/nd6_nbr.c
Modified: head/sys/netinet/if_ether.c
==
--- head/sys/netinet/if_ether.c Thu Jan 2 08:39:47 2014(r260186)
+++ head/sys/netinet/if_ether.c Thu Jan 2 08:40:37 2014(r260187)
@@ -149,10 +149,10 @@ arp_ifscrub(struct ifnet *ifp, uint32_t
addr4.sin_len= sizeof(addr4);
addr4.sin_family = AF_INET;
addr4.sin_addr.s_addr = addr;
- IF_AFDATA_LOCK(ifp);
+ IF_AFDATA_RLOCK(ifp);
lla_lookup(LLTABLE(ifp), (LLE_DELETE | LLE_IFADDR),
(struct sockaddr *)&addr4);
- IF_AFDATA_UNLOCK(ifp);
+ IF_AFDATA_RUNLOCK(ifp);
}
#endif
@@ -801,9 +801,9 @@ reply:
struct llentry *lle = NULL;
sin.sin_addr = itaddr;
- IF_AFDATA_LOCK(ifp);
+ IF_AFDATA_RLOCK(ifp);
lle = lla_lookup(LLTABLE(ifp), 0, (struct sockaddr *)&sin);
- IF_AFDATA_UNLOCK(ifp);
+ IF_AFDATA_RUNLOCK(ifp);
if ((lle != NULL) && (lle->la_flags & LLE_PUB)) {
(void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln);
Modified: head/sys/netinet6/nd6.c
==
--- head/sys/netinet6/nd6.c Thu Jan 2 08:39:47 2014(r260186)
+++ head/sys/netinet6/nd6.c Thu Jan 2 08:40:37 2014(r260187)
@@ -1146,9 +1146,9 @@ nd6_nud_hint(struct rtentry *rt, struct
return;
ifp = rt->rt_ifp;
- IF_AFDATA_LOCK(ifp);
+ IF_AFDATA_RLOCK(ifp);
ln = nd6_lookup(dst6, ND6_EXCLUSIVE, NULL);
- IF_AFDATA_UNLOCK(ifp);
+ IF_AFDATA_RUNLOCK(ifp);
if (ln == NULL)
return;
@@ -1574,16 +1574,16 @@ nd6_cache_lladdr(struct ifnet *ifp, stru
* description on it in NS section (RFC 2461 7.2.3).
*/
flags = lladdr ? ND6_EXCLUSIVE : 0;
- IF_AFDATA_LOCK(ifp);
+ IF_AFDATA_RLOCK(ifp);
ln = nd6_lookup(from, flags, ifp);
-
+ IF_AFDATA_RUNLOCK(ifp);
if (ln == NULL) {
flags |= ND6_EXCLUSIVE;
+ IF_AFDATA_LOCK(ifp);
ln = nd6_lookup(from, flags | ND6_CREATE, ifp);
IF_AFDATA_UNLOCK(ifp);
is_newentry = 1;
} else {
- IF_AFDATA_UNLOCK(ifp);
/* do nothing if static ndp is set */
if (ln->la_flags & LLE_STATIC) {
static_route = 1;
Modified: head/sys/netinet6/nd6_nbr.c
==
--- head/sys/netinet6/nd6_nbr.c Thu Jan 2 08:39:47 2014(r260186)
+++ head/sys/netinet6/nd6_nbr.c Thu Jan 2 08:40:37 2014(r260187)
@@ -723,9 +723,9 @@ nd6_na_input(struct mbuf *m, int off, in
* If no neighbor cache entry is found, NA SHOULD silently be
* discarded.
*/
- IF_AFDATA_LOCK(ifp);
+ IF_AFDATA_RLOCK(ifp);
ln = nd6_lookup(&taddr6, LLE_EXCLUSIVE, ifp);
- IF_AFDATA_UNLOCK(ifp);
+ IF_AFDATA_RUNLOCK(ifp);
if (ln == NULL) {
goto freeit;
}
___
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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
>
> On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek wrote:
>
> > This commit also breaks compatibility with some existing Capsicum system
> > calls,
> > but I see no other way to do that. This should be fine as Capsicum is still
> > experimental and this change is not going to 9.x.
>
> Hi!
>
> This change also increases the size of kinfo_file structure, which won’t allow
> programs not compiled against HEAD and working with kern.info.filedesc sysctl
> to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won’t run properly on
> HEAD,
> and it also broke valgrind). Is there absolutely no way to avoid extending
> the size
> of this struct?
Well, I made this change to have space for future cap_rights_t
expension. I did that change for a major branch, so we don't have to do
it in the middle of 10.x or to not block the work until 11.0.
Note that the structure changed size not only because of _kf_cap_spare[3]
field, but also because cap_rights_t is not uint64_t anymore, it is now
struct that contains two uint64_t (1424 - 1392 = 4 * 8).
I'm afraid it is too late to change it for 10.0 at this point anyway.
Not sure if you are aware this was merged to 10, because you write about
10.x jails not working properly on HEAD. 10.x jails will work properly
on HEAD.
BTW. I'd love if we stop using such structures for a running kernel.
We should really move to using libnv to export data like that.
> > #if defined(__amd64__) || defined(__i386__)
> > -#defineKINFO_FILE_SIZE 1392
> > +#defineKINFO_FILE_SIZE 1424
> > #endif
> >
> > struct kinfo_file {
> > @@ -389,6 +390,7 @@
> > uint16_tkf_pad1;/* Round to 32 bit
> > alignment. */
> > int _kf_ispare0;/* Space for more stuff. */
> > cap_rights_tkf_cap_rights; /* Capability rights. */
> > + uint64_t_kf_cap_spare[3]; /* Space for future
> > cap_rights_t. */
> > int _kf_ispare[4]; /* Space for more stuff. */
> > /* Truncated before copyout in sysctl */
> > charkf_path[PATH_MAX]; /* Path to file, if any. */
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
pgpAKlvQ0I1pi.pgp
Description: PGP signature
svn commit: r260188 - head/sys/netinet
Author: glebius
Date: Thu Jan 2 10:18:39 2014
New Revision: 260188
URL: http://svnweb.freebsd.org/changeset/base/260188
Log:
Fix regression from r249894. Now we pass "gw" as argument to if_output
method, thus for multicast case we need it to point at "dst".
PR: 185395
Submitted by: ae
Modified:
head/sys/netinet/ip_output.c
Modified: head/sys/netinet/ip_output.c
==
--- head/sys/netinet/ip_output.cThu Jan 2 08:40:37 2014
(r260187)
+++ head/sys/netinet/ip_output.cThu Jan 2 10:18:39 2014
(r260188)
@@ -333,6 +333,12 @@ again:
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) {
m->m_flags |= M_MCAST;
/*
+* IP destination address is multicast. Make sure "gw"
+* still points to the address in "ro". (It may have been
+* changed to point to a gateway address, above.)
+*/
+ gw = dst;
+ /*
* See if the caller provided any multicast options
*/
if (imo != NULL) {
___
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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14 1:33 AM, Pawel Jakub Dawidek wrote:
On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek wrote:
This commit also breaks compatibility with some existing Capsicum system
calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Hi!
This change also increases the size of kinfo_file structure, which won’t allow
programs not compiled against HEAD and working with kern.info.filedesc sysctl
to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won’t run properly on
HEAD,
and it also broke valgrind). Is there absolutely no way to avoid extending the
size
of this struct?
Well, I made this change to have space for future cap_rights_t
expension. I did that change for a major branch, so we don't have to do
it in the middle of 10.x or to not block the work until 11.0.
Note that the structure changed size not only because of _kf_cap_spare[3]
field, but also because cap_rights_t is not uint64_t anymore, it is now
struct that contains two uint64_t (1424 - 1392 = 4 * 8).
I'm afraid it is too late to change it for 10.0 at this point anyway.
Not sure if you are aware this was merged to 10, because you write about
10.x jails not working properly on HEAD. 10.x jails will work properly
on HEAD.
BTW. I'd love if we stop using such structures for a running kernel.
We should really move to using libnv to export data like that.
Aren't there enough bits in int _kf_ispare[4]; /* Space
for more stuff. */
to make this work for the time being until you can provide an alternate
way to fetch the cap stuff from the kernel.
Afaik you could just remove the "spare" and steal 2 or 4 entries from
_kf_ispare until it is sorted.
Can you please make use of that and discuss merge to 10 with re@?
It really sounds like breaking top/etc under jails is something that
should and can be avoided.
Thank you,
-Alfred
#if defined(__amd64__) || defined(__i386__)
-#defineKINFO_FILE_SIZE 1392
+#defineKINFO_FILE_SIZE 1424
#endif
struct kinfo_file {
@@ -389,6 +390,7 @@
uint16_tkf_pad1;/* Round to 32 bit alignment.
*/
int _kf_ispare0;/* Space for more stuff. */
cap_rights_tkf_cap_rights; /* Capability rights. */
+ uint64_t_kf_cap_spare[3]; /* Space for future
cap_rights_t. */
int _kf_ispare[4]; /* Space for more stuff. */
/* Truncated before copyout in sysctl */
charkf_path[PATH_MAX]; /* Path to file, if any. */
--
Alfred Perlstein
___
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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 02:28:57AM -0800, Alfred Perlstein wrote:
> On 1/2/14 1:33 AM, Pawel Jakub Dawidek wrote:
> > On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
> >> On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek wrote:
> >>
> >>> This commit also breaks compatibility with some existing Capsicum
> >>> system calls,
> >>> but I see no other way to do that. This should be fine as Capsicum is
> >>> still
> >>> experimental and this change is not going to 9.x.
> >> Hi!
> >>
> >> This change also increases the size of kinfo_file structure, which won’t
> >> allow
> >> programs not compiled against HEAD and working with kern.info.filedesc
> >> sysctl
> >> to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won’t run properly
> >> on HEAD,
> >> and it also broke valgrind). Is there absolutely no way to avoid
> >> extending the size
> >> of this struct?
> > Well, I made this change to have space for future cap_rights_t
> > expension. I did that change for a major branch, so we don't have to do
> > it in the middle of 10.x or to not block the work until 11.0.
> >
> > Note that the structure changed size not only because of _kf_cap_spare[3]
> > field, but also because cap_rights_t is not uint64_t anymore, it is now
> > struct that contains two uint64_t (1424 - 1392 = 4 * 8).
> >
> > I'm afraid it is too late to change it for 10.0 at this point anyway.
> > Not sure if you are aware this was merged to 10, because you write about
> > 10.x jails not working properly on HEAD. 10.x jails will work properly
> > on HEAD.
> >
> > BTW. I'd love if we stop using such structures for a running kernel.
> > We should really move to using libnv to export data like that.
>
> Aren't there enough bits in int _kf_ispare[4]; /* Space
> for more stuff. */
> to make this work for the time being until you can provide an alternate
> way to fetch the cap stuff from the kernel.
I don't plan to provide alternative way to fetch the cap stuff. Well, I
implemented libnv, which can be used to reimplement how we fetch all
data like kinfo_file in a ABI friendly way, but I don't plan to modify
this specific code myself.
> Afaik you could just remove the "spare" and steal 2 or 4 entries from
> _kf_ispare until it is sorted.
Yes, this would work for current cap_rights_t structure, at least for
i386 and amd64, but would only allow to expand the structure by one
uint64_t in the future (which might or might not be enough). The
cap_rights_t structure is designed to be expanded to 5 uint64_ts without
breaking ABI. I don't want to stuck with current cap_rights_t that is
designed to expand, but cannot be, because kinfo_file wasn't modified at
the start of a major branch.
> Can you please make use of that and discuss merge to 10 with re@?
I'm Bccing re@, but I'm pretty sure it is too late for such a change,
especially that it breaks ABI with all 10-RCs. I'm also not changing my
mind. I'd like to structure to stay as-is.
> It really sounds like breaking top/etc under jails is something that
> should and can be avoided.
I agree. Maybe it should be done every 10 major releases (I'm still fine
with that rule), but we cannot just stuck with it forever.
My suggestions would be:
1. Move to libnv.
2. Detect that the given binary was compiled against some older version
of this structure and copy old structure to userland. Not sure if we
can do that now or not, but I'd expect we can detect that.
> >>> #if defined(__amd64__) || defined(__i386__)
> >>> -#defineKINFO_FILE_SIZE 1392
> >>> +#defineKINFO_FILE_SIZE 1424
> >>> #endif
> >>>
> >>> struct kinfo_file {
> >>> @@ -389,6 +390,7 @@
> >>> uint16_tkf_pad1;/* Round to 32 bit
> >>> alignment. */
> >>> int _kf_ispare0;/* Space for more stuff.
> >>> */
> >>> cap_rights_tkf_cap_rights; /* Capability rights. */
> >>> + uint64_t_kf_cap_spare[3]; /* Space for future
> >>> cap_rights_t. */
> >>> int _kf_ispare[4]; /* Space for more stuff.
> >>> */
> >>> /* Truncated before copyout in sysctl */
> >>> charkf_path[PATH_MAX]; /* Path to file, if any.
> >>> */
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
pgpes5xRY9JCs.pgp
Description: PGP signature
Re: svn commit: r260165 - head/sys/dev/ahci
On 01.01.2014 21:32, Konstantin Belousov wrote: > On Wed, Jan 01, 2014 at 08:26:08PM +, Zbigniew Bodek wrote: >> Author: zbb Date: Wed Jan 1 20:26:08 2014 New Revision: 260165 >> URL: http://svnweb.freebsd.org/changeset/base/260165 >> >> Log: Use only mapped BIOs on ARM >> >> Using unmapped BIOs causes failure inside bus_dmamap_sync, since >> this function requires valid MVA address, which is not present >> if mapping is not set up. >> >> Submitted by:Wojciech Macek Obtained from: >> Semihalf >> >> Modified: head/sys/dev/ahci/ahci.c >> >> Modified: head/sys/dev/ahci/ahci.c >> == >> >> >> --- head/sys/dev/ahci/ahci.cWed Jan 1 20:22:29 2014(r260164) >> +++ head/sys/dev/ahci/ahci.c Wed Jan 1 20:26:08 2014(r260165) >> @@ -3066,7 +3066,15 @@ ahciaction(struct cam_sim *sim, union cc >> if (ch->caps & AHCI_CAP_SPM) cpi->hba_inquiry |= PI_SATAPM; >> cpi->target_sprt = 0; +#ifdef __arm__ + /* + * Do >> not use >> unmapped buffers on ARM. Doing so will cause +* failure >> inside bus_dmamap_sync due to lack of VA. + */ + >> cpi->hba_misc >> = PIM_SEQSCAN; +#else cpi->hba_misc = PIM_SEQSCAN | PIM_UNMAPPED; >> +#endif cpi->hba_eng_cnt = 0; if (ch->caps & AHCI_CAP_SPM) >> cpi->max_target = 15; > > I think this is wrong. If bus_dmamap_sync(9) is not functional on > arm, then unmapped io should be disabled on arm unconditionally, > using unmapped_buf_allowed. Why ahci(4) is special in this > regard, leaving other controllers broken for arm ? > Hello Konstantin. Thanks for pointing that out. You are right, we didn't know about unmapped_buf_allowed flag. bus_dmamap_sync() is functional on ARM however it needs virtual address therefore unmapped_buf_allowed should be set to 0 on ARM (it is set to 1 now). I will revert this commit but we will need some time to test the other solution. Best regards zbb ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14 2:49 AM, Pawel Jakub Dawidek wrote:
On Thu, Jan 02, 2014 at 02:28:57AM -0800, Alfred Perlstein wrote:
On 1/2/14 1:33 AM, Pawel Jakub Dawidek wrote:
On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek wrote:
This commit also breaks compatibility with some existing Capsicum system
calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Hi!
This change also increases the size of kinfo_file structure, which won’t allow
programs not compiled against HEAD and working with kern.info.filedesc sysctl
to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won’t run properly on
HEAD,
and it also broke valgrind). Is there absolutely no way to avoid extending the
size
of this struct?
Well, I made this change to have space for future cap_rights_t
expension. I did that change for a major branch, so we don't have to do
it in the middle of 10.x or to not block the work until 11.0.
Note that the structure changed size not only because of _kf_cap_spare[3]
field, but also because cap_rights_t is not uint64_t anymore, it is now
struct that contains two uint64_t (1424 - 1392 = 4 * 8).
I'm afraid it is too late to change it for 10.0 at this point anyway.
Not sure if you are aware this was merged to 10, because you write about
10.x jails not working properly on HEAD. 10.x jails will work properly
on HEAD.
BTW. I'd love if we stop using such structures for a running kernel.
We should really move to using libnv to export data like that.
Aren't there enough bits in int _kf_ispare[4]; /* Space
for more stuff. */
to make this work for the time being until you can provide an alternate
way to fetch the cap stuff from the kernel.
I don't plan to provide alternative way to fetch the cap stuff. Well, I
implemented libnv, which can be used to reimplement how we fetch all
data like kinfo_file in a ABI friendly way, but I don't plan to modify
this specific code myself.
Afaik you could just remove the "spare" and steal 2 or 4 entries from
_kf_ispare until it is sorted.
Yes, this would work for current cap_rights_t structure, at least for
i386 and amd64, but would only allow to expand the structure by one
uint64_t in the future (which might or might not be enough). The
cap_rights_t structure is designed to be expanded to 5 uint64_ts without
breaking ABI. I don't want to stuck with current cap_rights_t that is
designed to expand, but cannot be, because kinfo_file wasn't modified at
the start of a major branch.
Can you please make use of that and discuss merge to 10 with re@?
I'm Bccing re@, but I'm pretty sure it is too late for such a change,
especially that it breaks ABI with all 10-RCs. I'm also not changing my
mind. I'd like to structure to stay as-is.
It really sounds like breaking top/etc under jails is something that
should and can be avoided.
I agree. Maybe it should be done every 10 major releases (I'm still fine
with that rule), but we cannot just stuck with it forever.
My suggestions would be:
1. Move to libnv.
2. Detect that the given binary was compiled against some older version
of this structure and copy old structure to userland. Not sure if we
can do that now or not, but I'd expect we can detect that.
Well I agree strongly with what you are doing except the part where 9.x
jails and earlier are broken because of this change.
It seems like there is a way out and you agree. Perhaps since the cap
fits in the spare area we can make do for the time being?
The way to do a major re-org of the kinfo_file/proc/whatever is to
either use libnv as you suggest, check the binary version (as you
suggest) or to make an entirely new one and make the old one
kinfo_file_old and make a new way to fetch the new data as we did with
the various syscalls ostatfs, ostat, etc.
It still seems like we have a way out that would even give capabilities
another "version" (there are enough cells in _kf_ispare for the next
version of the capabilities code.
-Alfred
#if defined(__amd64__) || defined(__i386__)
-#defineKINFO_FILE_SIZE 1392
+#defineKINFO_FILE_SIZE 1424
#endif
struct kinfo_file {
@@ -389,6 +390,7 @@
uint16_tkf_pad1;/* Round to 32 bit alignment.
*/
int _kf_ispare0;/* Space for more stuff. */
cap_rights_tkf_cap_rights; /* Capability rights. */
+ uint64_t_kf_cap_spare[3]; /* Space for future
cap_rights_t. */
int _kf_ispare[4]; /* Space for more stuff. */
/* Truncated before copyout in sysctl */
charkf_path[PATH_MAX]; /* Path to file, if any. */
--
Alfred Perlstein
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsub
Re: svn commit: r260188 - head/sys/netinet
On 2014-Jan-02 10:18:40 +, Gleb Smirnoff wrote: >Log: > Fix regression from r249894. Now we pass "gw" as argument to if_output > method, thus for multicast case we need it to point at "dst". > > PR: 185395 > Submitted by:ae Thank you for that. I'd gotten as far as working out that r249894 was the probable cause but not come up with a patch. Given that it breaks IPv4 multicast, I'm surprised no-one else noticed it in the past 8 months. (My excuse is that I only tried to use multicast for the first time yesterday). And, whilst it's _really_ late in the 10.0 release cycle, I'm not sure we want to roll a release with broken multicast. -- Peter Jeremy pgp2NmtUnk4Au.pgp Description: PGP signature
svn commit: r260189 - head/sys/dev/ahci
Author: zbb Date: Thu Jan 2 11:24:04 2014 New Revision: 260189 URL: http://svnweb.freebsd.org/changeset/base/260189 Log: Revert r260165: Proper configuration of unmapped_buf_allowed should be used To avoid failures in bus_dmamap_sync() on ARM unmapped_buf_allowed should be set to 0. Hence, ARM-specific changes in AHCI should not be applied. Modified: head/sys/dev/ahci/ahci.c Modified: head/sys/dev/ahci/ahci.c == --- head/sys/dev/ahci/ahci.cThu Jan 2 10:18:39 2014(r260188) +++ head/sys/dev/ahci/ahci.cThu Jan 2 11:24:04 2014(r260189) @@ -3066,15 +3066,7 @@ ahciaction(struct cam_sim *sim, union cc if (ch->caps & AHCI_CAP_SPM) cpi->hba_inquiry |= PI_SATAPM; cpi->target_sprt = 0; -#ifdef __arm__ - /* -* Do not use unmapped buffers on ARM. Doing so will cause -* failure inside bus_dmamap_sync due to lack of VA. -*/ - cpi->hba_misc = PIM_SEQSCAN; -#else cpi->hba_misc = PIM_SEQSCAN | PIM_UNMAPPED; -#endif cpi->hba_eng_cnt = 0; if (ch->caps & AHCI_CAP_SPM) cpi->max_target = 15; ___ 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: r260073 - in head/contrib/gcc: . cp
Hi Pedro, Happy new Year! On 30.12.13 03:52, Pedro F. Giffuni wrote: > Author: pfg > Date: Mon Dec 30 02:52:43 2013 > New Revision: 260073 > URL: http://svnweb.freebsd.org/changeset/base/260073 > > Log: > gcc: small diff reduction wrt gcc43 and Apple GCC. > > Obtained from: gcc 4.3 (rev. 121464, 122528, 124106; GPLv2) > MFC after: 3 weeks > > Modified: > head/contrib/gcc/ChangeLog.gcc43 > head/contrib/gcc/cp/ChangeLog > head/contrib/gcc/cp/g++spec.c > head/contrib/gcc/libgcc2.c > head/contrib/gcc/libgcc2.h > head/contrib/gcc/loop-init.c > head/contrib/gcc/toplev.c > head/contrib/gcc/tree-ssa-address.c May I ask you to revert this commit? It causes an ICE on powerpc(64) and sparc64 while compiling dev/trm/trm.c. Tinderbox also showed this one a few days ago. It should pop up again soon. -- /export/devel/fbsd/src/sys/modules/trm/../../dev/trm/trm.c:3522: internal compiler error: in create_mem_ref, at tree-ssa-address.c:606 Please submit a full bug report, with preprocessed source if appropriate. -- Thank you, Andreas ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Jan 2, 2014, at 3:01 AM, Alfred Perlstein wrote: > Well I agree strongly with what you are doing except the part where 9.x jails > and earlier are broken because of this change. > > It seems like there is a way out and you agree. Perhaps since the cap fits > in the spare area we can make do for the time being? > > The way to do a major re-org of the kinfo_file/proc/whatever is to either use > libnv as you suggest, check the binary version (as you suggest) or to make an > entirely new one and make the old one kinfo_file_old and make a new way to > fetch the new data as we did with the various syscalls ostatfs, ostat, etc. > > It still seems like we have a way out that would even give capabilities > another "version" (there are enough cells in _kf_ispare for the next version > of the capabilities code. I agree that we should move to libnv or maybe even something more structured (like ASN.1 or protobufs) in the future for such usecases to avoid this situation altogether. I should have looked into doing that much earlier. :( It’d be really nice if we can avoid this issue by using the spare fields at the moment, and switch to a new struct/proper serialization by the time we need to export more capabilities data from the kernel. We actually did exactly that once between 7.x and 8.x, that is the reason why there is also kinfo_ofile struct in that file as well. It’s a pity I have not noticed that before it was merged to 10.x, as I’m not sure we can do anything about it at the moment. I agree with Pawel that it is questionable what will lead to more damage. PS: I should also note that the change does not entirely break programs that deal with proc/filedesc as most of the fields are at the same position. The ones that need to obtain the file path of a file descriptor won’t be able to do so (think procstat -f, procstat -v, fstat). -- ST4096-RIPE ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote:
> On Thu, Jan 02, 2014 at 02:28:57AM -0800, Alfred Perlstein wrote:
> > On 1/2/14 1:33 AM, Pawel Jakub Dawidek wrote:
> > > On Wed, Jan 01, 2014 at 11:16:22PM -0800, Stanislav Sedov wrote:
> > >> On Sep 4, 2013, at 5:09 PM, Pawel Jakub Dawidek wrote:
> > >>
> > >>> This commit also breaks compatibility with some existing Capsicum
> > >>> system calls,
> > >>> but I see no other way to do that. This should be fine as Capsicum is
> > >>> still
> > >>> experimental and this change is not going to 9.x.
> > >> Hi!
> > >>
> > >> This change also increases the size of kinfo_file structure, which
> > >> won???t allow
> > >> programs not compiled against HEAD and working with kern.info.filedesc
> > >> sysctl
> > >> to run properly on HEAD (e.g. 8.x, 9.x and 10.x jails won???t run
> > >> properly on HEAD,
> > >> and it also broke valgrind). Is there absolutely no way to avoid
> > >> extending the size
> > >> of this struct?
> > > Well, I made this change to have space for future cap_rights_t
> > > expension. I did that change for a major branch, so we don't have to do
> > > it in the middle of 10.x or to not block the work until 11.0.
> > >
> > > Note that the structure changed size not only because of _kf_cap_spare[3]
> > > field, but also because cap_rights_t is not uint64_t anymore, it is now
> > > struct that contains two uint64_t (1424 - 1392 = 4 * 8).
> > >
> > > I'm afraid it is too late to change it for 10.0 at this point anyway.
> > > Not sure if you are aware this was merged to 10, because you write about
> > > 10.x jails not working properly on HEAD. 10.x jails will work properly
> > > on HEAD.
> > >
> > > BTW. I'd love if we stop using such structures for a running kernel.
> > > We should really move to using libnv to export data like that.
> >
> > Aren't there enough bits in int _kf_ispare[4]; /* Space
> > for more stuff. */
> > to make this work for the time being until you can provide an alternate
> > way to fetch the cap stuff from the kernel.
>
> I don't plan to provide alternative way to fetch the cap stuff. Well, I
> implemented libnv, which can be used to reimplement how we fetch all
> data like kinfo_file in a ABI friendly way, but I don't plan to modify
> this specific code myself.
I.e. you break something and decline to fix it, putting the burden on
somebody else.
>
> > Afaik you could just remove the "spare" and steal 2 or 4 entries from
> > _kf_ispare until it is sorted.
>
> Yes, this would work for current cap_rights_t structure, at least for
> i386 and amd64, but would only allow to expand the structure by one
> uint64_t in the future (which might or might not be enough). The
> cap_rights_t structure is designed to be expanded to 5 uint64_ts without
> breaking ABI. I don't want to stuck with current cap_rights_t that is
> designed to expand, but cannot be, because kinfo_file wasn't modified at
> the start of a major branch.
The ABI stability is not limited to the single branch. It must be
preserved across whole project lifetime.
>
> > Can you please make use of that and discuss merge to 10 with re@?
>
> I'm Bccing re@, but I'm pretty sure it is too late for such a change,
> especially that it breaks ABI with all 10-RCs. I'm also not changing my
> mind. I'd like to structure to stay as-is.
This is just awful breakage of _ABI_. We cannot leave it as is,
unless we also claim that project gave up on ABI stability at all.
>
> > It really sounds like breaking top/etc under jails is something that
> > should and can be avoided.
>
> I agree. Maybe it should be done every 10 major releases (I'm still fine
> with that rule), but we cannot just stuck with it forever.
>
> My suggestions would be:
> 1. Move to libnv.
> 2. Detect that the given binary was compiled against some older version
>of this structure and copy old structure to userland. Not sure if we
>can do that now or not, but I'd expect we can detect that.
The only way to fix this is either to stop passing caps in kinfo_file,
reverting it to the pre-commit state, or follow Alfred suggestion
by consuming spares.
My own opinion is that the kinfo change must be removed, and the bug
is so critical that another RC must be issued.
>
> > >>> #if defined(__amd64__) || defined(__i386__)
> > >>> -#defineKINFO_FILE_SIZE 1392
> > >>> +#defineKINFO_FILE_SIZE 1424
> > >>> #endif
> > >>>
> > >>> struct kinfo_file {
> > >>> @@ -389,6 +390,7 @@
> > >>> uint16_tkf_pad1;/* Round to 32 bit
> > >>> alignment. */
> > >>> int _kf_ispare0;/* Space for more
> > >>> stuff. */
> > >>> cap_rights_tkf_cap_rights; /* Capability rights.
> > >>> */
> > >>> + uint64_t_kf_cap_spare[3]; /* Space for future
> > >>> cap_rights_t. */
> > >>> int _kf_ispare[4]; /* Space for more
> > >>> s
svn commit: r260194 - in head/contrib/gcc: . cp
Author: pfg
Date: Thu Jan 2 13:53:53 2014
New Revision: 260194
URL: http://svnweb.freebsd.org/changeset/base/260194
Log:
Revert r260073; small diff reduction wrt gcc43 and Apple GCC.
Unfortunately this causes ICE on powerpc and sparc64.
Reducing these differences against upstream is not important
anymore so hopefully I have finished breaking the compiler
occasionally.
Modified:
head/contrib/gcc/ChangeLog.gcc43
head/contrib/gcc/cp/ChangeLog
head/contrib/gcc/cp/g++spec.c
head/contrib/gcc/libgcc2.c
head/contrib/gcc/libgcc2.h
head/contrib/gcc/loop-init.c
head/contrib/gcc/toplev.c
head/contrib/gcc/tree-ssa-address.c
Modified: head/contrib/gcc/ChangeLog.gcc43
==
--- head/contrib/gcc/ChangeLog.gcc43Thu Jan 2 13:48:54 2014
(r260193)
+++ head/contrib/gcc/ChangeLog.gcc43Thu Jan 2 13:53:53 2014
(r260194)
@@ -156,15 +156,6 @@
* reload1.c (merge_assigned_reloads) : Do not merge a RELOAD_OTHER
instruction with a RELOAD_FOR_OPERAND_ADDRESS instruction.
-2007-04-24 Richard Henderson (r124106)
-
- * libgcc2.h (AVOID_FP_TYPE_CONVERSION): Rename from
- IS_IBM_EXTENDED. Also define in terms of WIDEST_HARDWARE_FP_SIZE.
- * libgcc2.c (__floatdisf): Avoid double-word arithmetic when
- looking for non-zero bits shifted out. Avoid a recursive call
- when constructing the scalar.
- (__floatundisf): Likewise.
-
2007-04-16 Lawrence Crowl (r123909)
* doc/invoke.texi (Debugging Options): Add documentation for the
@@ -257,11 +248,6 @@
* tree-vrp.c (vrp_int_const_binop): Handle PLUS_EXPR and
the *_DIV_EXPR codes correctly with overflow infinities.
-2007-03-04 Zdenek Dvorak (r122528)
-
- * tree-ssa-address.c (create_mem_ref): Do not put an expression
- containing a cast to the base of TARGET_MEM_REF.
-
2007-02-09 Dwarakanath Rajagopal (r121763)
* config/i386/driver-i386.c: Turn on -mtune=native for AMDFAM10.
@@ -438,11 +424,6 @@
and amdfam10.
* doc/extend.texi: Add documentation for SSE4A builtins.
-2007-02-01 Zdenek Dvorak (r121464)
-
- * toplev.c (lang_dependent_init): Call init_set_costs.
- * loop-init.c (loop_optimizer_init): Do not call init_set_costs.
-
2007-01-24 Jakub Jelinek (r121140)
* config/i386/i386.h (x86_cmpxchg16b): Remove const.
Modified: head/contrib/gcc/cp/ChangeLog
==
--- head/contrib/gcc/cp/ChangeLog Thu Jan 2 13:48:54 2014
(r260193)
+++ head/contrib/gcc/cp/ChangeLog Thu Jan 2 13:53:53 2014
(r260194)
@@ -314,12 +314,6 @@
PR c++/30895
* tree.c (cp_tree_equal): Properly handle COMPLEX_CST trees.
-2007-03-02 Geoffrey Keating (r122488)
-
- * g++spec.c (lang_specific_driver): Add -lstdc++ when compiling
- Objective-C++. Don't exit early if -shared-libgcc needs to be
- added.
-
2007-02-22 Simon Martin
PR c++/29475
Modified: head/contrib/gcc/cp/g++spec.c
==
--- head/contrib/gcc/cp/g++spec.c Thu Jan 2 13:48:54 2014
(r260193)
+++ head/contrib/gcc/cp/g++spec.c Thu Jan 2 13:53:53 2014
(r260194)
@@ -159,19 +159,11 @@ lang_specific_driver (int *in_argc, cons
arg = "";
if (library == 0
&& (strcmp (arg, "c++") == 0
- || strcmp (arg, "c++-cpp-output") == 0
- || strcmp (arg, "objective-c++") == 0
- || strcmp (arg, "objective-c++-cpp-output") == 0))
+ || strcmp (arg, "c++-cpp-output") == 0))
library = 1;
saw_speclang = 1;
}
- else if (strcmp (argv[i], "-ObjC++") == 0)
- {
- if (library == 0)
- library = 1;
- saw_speclang = 1;
- }
/* Arguments that go directly to the linker might be .o files,
or something, and so might cause libstdc++ to be needed. */
else if (strcmp (argv[i], "-Xlinker") == 0)
@@ -245,6 +237,13 @@ lang_specific_driver (int *in_argc, cons
if (quote)
fatal ("argument to '%s' missing\n", quote);
+ /* If we know we don't have to do anything, bail now. */
+ if (! added && library <= 0)
+{
+ free (args);
+ return;
+}
+
/* There's no point adding -shared-libgcc if we don't have a shared
libgcc. */
#ifndef ENABLE_SHARED_LIBGCC
Modified: head/contrib/gcc/libgcc2.c
==
--- head/contrib/gcc/libgcc2.c Thu Jan 2 13:48:54 2014(r260193)
+++ head/contrib/gcc/libgcc2.c Thu Jan 2 13:53:53 2014(r260194)
@@ -1420,7 +1420,11 @@ __floatunditf (UDWtype u)
#define
Re: svn commit: r260073 - in head/contrib/gcc: . cp
On 02.01.2014 06:25, Andreas Tobler wrote: Hi Pedro, Happy new Year! On 30.12.13 03:52, Pedro F. Giffuni wrote: Author: pfg Date: Mon Dec 30 02:52:43 2013 New Revision: 260073 URL: http://svnweb.freebsd.org/changeset/base/260073 Log: gcc: small diff reduction wrt gcc43 and Apple GCC. Obtained from: gcc 4.3 (rev. 121464, 122528, 124106; GPLv2) MFC after: 3 weeks Modified: head/contrib/gcc/ChangeLog.gcc43 head/contrib/gcc/cp/ChangeLog head/contrib/gcc/cp/g++spec.c head/contrib/gcc/libgcc2.c head/contrib/gcc/libgcc2.h head/contrib/gcc/loop-init.c head/contrib/gcc/toplev.c head/contrib/gcc/tree-ssa-address.c May I ask you to revert this commit? It causes an ICE on powerpc(64) and sparc64 while compiling dev/trm/trm.c. Tinderbox also showed this one a few days ago. It should pop up again soon. Done, thank you! FWIW, I have almost finished the patch to add Block support to gcc. I still have to check many things and document the changes but I got to a point where the example in Wikipedia works :). Pedro. ___ 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: r260204 - head/sys/amd64/amd64
Author: kib
Date: Thu Jan 2 18:49:05 2014
New Revision: 260204
URL: http://svnweb.freebsd.org/changeset/base/260204
Log:
Assert that accounting for the pmap resident pages does not underflow.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/amd64/amd64/pmap.c
Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Thu Jan 2 18:30:24 2014(r260203)
+++ head/sys/amd64/amd64/pmap.c Thu Jan 2 18:49:05 2014(r260204)
@@ -608,6 +608,9 @@ pmap_resident_count_dec(pmap_t pmap, int
{
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
+ KASSERT(pmap->pm_stats.resident_count >= count,
+ ("pmap %p resident count underflow %ld %d", pmap,
+ pmap->pm_stats.resident_count, count));
pmap->pm_stats.resident_count -= count;
}
___
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: r260205 - head/sys/amd64/amd64
Author: kib
Date: Thu Jan 2 18:50:52 2014
New Revision: 260205
URL: http://svnweb.freebsd.org/changeset/base/260205
Log:
Update the description for pmap_remove_pages() to match the modern
times [1]. Assert that the pmap passed to pmap_remove_pages() is only
active on current CPU.
Submitted by: alc [1]
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/amd64/amd64/pmap.c
Modified: head/sys/amd64/amd64/pmap.c
==
--- head/sys/amd64/amd64/pmap.c Thu Jan 2 18:49:05 2014(r260204)
+++ head/sys/amd64/amd64/pmap.c Thu Jan 2 18:50:52 2014(r260205)
@@ -5123,12 +5123,20 @@ pmap_page_is_mapped(vm_page_t m)
}
/*
- * Remove all pages from specified address space
- * this aids process exit speeds. Also, this code
- * is special cased for current process only, but
- * can have the more generic (and slightly slower)
- * mode enabled. This is much faster than pmap_remove
- * in the case of running down an entire address space.
+ * Destroy all managed, non-wired mappings in the given user-space
+ * pmap. This pmap cannot be active on any processor besides the
+ * caller.
+ *
+ * This function cannot be applied to the kernel pmap. Moreover, it
+ * is not intended for general use. It is only to be used during
+ * process termination. Consequently, it can be implemented in ways
+ * that make it faster than pmap_remove(). First, it can more quickly
+ * destroy mappings by iterating over the pmap's collection of PV
+ * entries, rather than searching the page table. Second, it doesn't
+ * have to test and clear the page table entries atomically, because
+ * no processor is currently accessing the user address space. In
+ * particular, a page table entry's dirty bit won't change state once
+ * this function starts.
*/
void
pmap_remove_pages(pmap_t pmap)
@@ -5148,10 +5156,24 @@ pmap_remove_pages(pmap_t pmap)
boolean_t superpage;
vm_paddr_t pa;
- if (pmap != PCPU_GET(curpmap)) {
- printf("warning: pmap_remove_pages called with non-current
pmap\n");
- return;
+ /*
+* Assert that the given pmap is only active on the current
+* CPU. Unfortunately, we cannot block another CPU from
+* activating the pmap while this function is executing.
+*/
+ KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap));
+#ifdef INVARIANTS
+ {
+ cpuset_t other_cpus;
+
+ other_cpus = all_cpus;
+ critical_enter();
+ CPU_CLR(PCPU_GET(cpuid), &other_cpus);
+ CPU_AND(&other_cpus, &pmap->pm_active);
+ critical_exit();
+ KASSERT(CPU_EMPTY(&other_cpus), ("pmap active %p", pmap));
}
+#endif
lock = NULL;
PG_M = pmap_modified_bit(pmap);
___
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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: > > > Afaik you could just remove the "spare" and steal 2 or 4 entries from > > > _kf_ispare until it is sorted. > > > > Yes, this would work for current cap_rights_t structure, at least for > > i386 and amd64, but would only allow to expand the structure by one > > uint64_t in the future (which might or might not be enough). The > > cap_rights_t structure is designed to be expanded to 5 uint64_ts without > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > designed to expand, but cannot be, because kinfo_file wasn't modified at > > the start of a major branch. > The ABI stability is not limited to the single branch. It must be > preserved across whole project lifetime. Umm. when did this policy change happen? I thought ABI compatibility was limited to major releases of FreeBSD? How are you suppose to do any work if you can't break ABI ever? I did a quick search for "freebsd policy abi breakage" and found some mailing list posts about this, but no authoritative statement... Of course the problem is that when we move to (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, or introduce tons of compatibility code that will rot... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14, 11:14 AM, John-Mark Gurney wrote: Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: Afaik you could just remove the "spare" and steal 2 or 4 entries from _kf_ispare until it is sorted. Yes, this would work for current cap_rights_t structure, at least for i386 and amd64, but would only allow to expand the structure by one uint64_t in the future (which might or might not be enough). The cap_rights_t structure is designed to be expanded to 5 uint64_ts without breaking ABI. I don't want to stuck with current cap_rights_t that is designed to expand, but cannot be, because kinfo_file wasn't modified at the start of a major branch. The ABI stability is not limited to the single branch. It must be preserved across whole project lifetime. Umm. when did this policy change happen? I thought ABI compatibility was limited to major releases of FreeBSD? How are you suppose to do any work if you can't break ABI ever? I did a quick search for "freebsd policy abi breakage" and found some mailing list posts about this, but no authoritative statement... Of course the problem is that when we move to (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, or introduce tons of compatibility code that will rot... I agree, however there is a very easy way to fix it for the time being. Let's not be binary about it "well it's going to have to break, so let's break it!" when such an easy way to not break it exists. It should be "let's see if there's a non-intrusive way of not breaking it" and the answer to that seems to be "yes". -Alfred ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 11:14:20AM -0800, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: > > > > Afaik you could just remove the "spare" and steal 2 or 4 entries from > > > > _kf_ispare until it is sorted. > > > > > > Yes, this would work for current cap_rights_t structure, at least for > > > i386 and amd64, but would only allow to expand the structure by one > > > uint64_t in the future (which might or might not be enough). The > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts without > > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > > designed to expand, but cannot be, because kinfo_file wasn't modified at > > > the start of a major branch. > > The ABI stability is not limited to the single branch. It must be > > preserved across whole project lifetime. > > Umm. when did this policy change happen? I thought ABI compatibility > was limited to major releases of FreeBSD? How are you suppose to do > any work if you can't break ABI ever? Policy did not changed. Breaking ABI was never allowed, except for the kernel management interfaces. Later was only accepted due to tight relation of the typical management facilities and internal kernel structures, but this is considered a bug. > > I did a quick search for "freebsd policy abi breakage" and found some > mailing list posts about this, but no authoritative statement... Re tried to write down the policy, last time it was several years ago. The efforts should be revived. > > Of course the problem is that when we move to > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, > or introduce tons of compatibility code that will rot... I do not understand what are you trying to say. pgp6xjh1okpZV.pgp Description: PGP signature
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 11:23:55AM -0800, Alfred Perlstein wrote: > > On 1/2/14, 11:14 AM, John-Mark Gurney wrote: > > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: > Afaik you could just remove the "spare" and steal 2 or 4 entries from > _kf_ispare until it is sorted. > >>> Yes, this would work for current cap_rights_t structure, at least for > >>> i386 and amd64, but would only allow to expand the structure by one > >>> uint64_t in the future (which might or might not be enough). The > >>> cap_rights_t structure is designed to be expanded to 5 uint64_ts without > >>> breaking ABI. I don't want to stuck with current cap_rights_t that is > >>> designed to expand, but cannot be, because kinfo_file wasn't modified at > >>> the start of a major branch. > >> The ABI stability is not limited to the single branch. It must be > >> preserved across whole project lifetime. > > Umm. when did this policy change happen? I thought ABI compatibility > > was limited to major releases of FreeBSD? How are you suppose to do > > any work if you can't break ABI ever? > > > > I did a quick search for "freebsd policy abi breakage" and found some > > mailing list posts about this, but no authoritative statement... > > > > Of course the problem is that when we move to > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, > > or introduce tons of compatibility code that will rot... > > > I agree, however there is a very easy way to fix it for the time being. > Let's not be binary about it "well it's going to have to break, so let's > break it!" when such an easy way to not break it exists. It should be > "let's see if there's a non-intrusive way of not breaking it" and the > answer to that seems to be "yes". If parts of ABI is broken, then why spend efforts trying to keep other parts stable ? You already have random set of binaries broken, sometimes in subtle way. Then, making other interfaces stable is just a waste. ABI stability is a yes/no proposition, you cannot have it partly done. Personally, I do not want to spend a time on hobbyist system. BTW, to point out obvious thing, Linux has almost perfect ABI stability and forward compatibility. It is pity to see that our people do not understand the importance and benefits of it. pgpvcq9Sc8JKx.pgp Description: PGP signature
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14, 11:34 AM, Konstantin Belousov wrote: On Thu, Jan 02, 2014 at 11:23:55AM -0800, Alfred Perlstein wrote: On 1/2/14, 11:14 AM, John-Mark Gurney wrote: Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: Afaik you could just remove the "spare" and steal 2 or 4 entries from _kf_ispare until it is sorted. Yes, this would work for current cap_rights_t structure, at least for i386 and amd64, but would only allow to expand the structure by one uint64_t in the future (which might or might not be enough). The cap_rights_t structure is designed to be expanded to 5 uint64_ts without breaking ABI. I don't want to stuck with current cap_rights_t that is designed to expand, but cannot be, because kinfo_file wasn't modified at the start of a major branch. The ABI stability is not limited to the single branch. It must be preserved across whole project lifetime. Umm. when did this policy change happen? I thought ABI compatibility was limited to major releases of FreeBSD? How are you suppose to do any work if you can't break ABI ever? I did a quick search for "freebsd policy abi breakage" and found some mailing list posts about this, but no authoritative statement... Of course the problem is that when we move to (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, or introduce tons of compatibility code that will rot... I agree, however there is a very easy way to fix it for the time being. Let's not be binary about it "well it's going to have to break, so let's break it!" when such an easy way to not break it exists. It should be "let's see if there's a non-intrusive way of not breaking it" and the answer to that seems to be "yes". If parts of ABI is broken, then why spend efforts trying to keep other parts stable ? You already have random set of binaries broken, sometimes in subtle way. Then, making other interfaces stable is just a waste. ABI stability is a yes/no proposition, you cannot have it partly done. Personally, I do not want to spend a time on hobbyist system. BTW, to point out obvious thing, Linux has almost perfect ABI stability and forward compatibility. It is pity to see that our people do not understand the importance and benefits of it. I agree strongly. -Alfred ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +0200: > On Thu, Jan 02, 2014 at 11:14:20AM -0800, John-Mark Gurney wrote: > > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 +0200: > > > > > Afaik you could just remove the "spare" and steal 2 or 4 entries from > > > > > _kf_ispare until it is sorted. > > > > > > > > Yes, this would work for current cap_rights_t structure, at least for > > > > i386 and amd64, but would only allow to expand the structure by one > > > > uint64_t in the future (which might or might not be enough). The > > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts without > > > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > > > designed to expand, but cannot be, because kinfo_file wasn't modified at > > > > the start of a major branch. > > > The ABI stability is not limited to the single branch. It must be > > > preserved across whole project lifetime. > > > > Umm. when did this policy change happen? I thought ABI compatibility > > was limited to major releases of FreeBSD? How are you suppose to do > > any work if you can't break ABI ever? > Policy did not changed. Breaking ABI was never allowed, except for the > kernel management interfaces. Later was only accepted due to tight > relation of the typical management facilities and internal kernel > structures, but this is considered a bug. Please do no use such absolutes, since the ABI has been allowed to break in the recent past, as I'm looking at a commit in 2005 that broke struct kproc_info size... > > I did a quick search for "freebsd policy abi breakage" and found some > > mailing list posts about this, but no authoritative statement... > Re tried to write down the policy, last time it was several years ago. > The efforts should be revived. > > > > > Of course the problem is that when we move to > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, > > or introduce tons of compatibility code that will rot... > > I do not understand what are you trying to say. My point is that once we move to the "new ABI", we will either have to accept that we stop maintaining the old interface, or we write and maintain the old interface, but if we do, what's the point of going to the new interface if the old interface "never" breaks? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: r260163 - head/sys/dev/ahci
On Wednesday, January 01, 2014 3:18:03 pm Zbigniew Bodek wrote: > Author: zbb > Date: Wed Jan 1 20:18:03 2014 > New Revision: 260163 > URL: http://svnweb.freebsd.org/changeset/base/260163 > > Log: > Do not attach to PCI bridges in AHCI driver > > Some vendors use the same VID:PID combination in AHCI and PCI bridge cards Would it be better to require the class to be PCIC_STORAGE instead? -- 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thursday, January 02, 2014 2:59:35 pm John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +0200: > > On Thu, Jan 02, 2014 at 11:14:20AM -0800, John-Mark Gurney wrote: > > > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 > > > +0200: > > > > > > Afaik you could just remove the "spare" and steal 2 or 4 entries > > > > > > from > > > > > > _kf_ispare until it is sorted. > > > > > > > > > > Yes, this would work for current cap_rights_t structure, at least for > > > > > i386 and amd64, but would only allow to expand the structure by one > > > > > uint64_t in the future (which might or might not be enough). The > > > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts > > > > > without > > > > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > > > > designed to expand, but cannot be, because kinfo_file wasn't modified > > > > > at > > > > > the start of a major branch. > > > > The ABI stability is not limited to the single branch. It must be > > > > preserved across whole project lifetime. > > > > > > Umm. when did this policy change happen? I thought ABI compatibility > > > was limited to major releases of FreeBSD? How are you suppose to do > > > any work if you can't break ABI ever? > > Policy did not changed. Breaking ABI was never allowed, except for the > > kernel management interfaces. Later was only accepted due to tight > > relation of the typical management facilities and internal kernel > > structures, but this is considered a bug. > > Please do no use such absolutes, since the ABI has been allowed to break > in the recent past, as I'm looking at a commit in 2005 that broke struct > kproc_info size... > > > > I did a quick search for "freebsd policy abi breakage" and found some > > > mailing list posts about this, but no authoritative statement... > > Re tried to write down the policy, last time it was several years ago. > > The efforts should be revived. > > > > > > > > Of course the problem is that when we move to > > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, > > > or introduce tons of compatibility code that will rot... > > > > I do not understand what are you trying to say. > > My point is that once we move to the "new ABI", we will either have to > accept that we stop maintaining the old interface, or we write and > maintain the old interface, but if we do, what's the point of going to > the new interface if the old interface "never" breaks? *cough* Ahem. We've changed the ABI of kinfo_file once before already and supported both just fine. Please search for COMPAT_FREEBSD7 in kern_descrip.c. In this case this works because the relevant sysctls use fixed nodes, so you can add a new ABI by moving the names to the new numbers but leaving the old nodes in place for the old ABI. Shouldn't take a huge amount of work for Pawel to bang out appropriate COMPAT_FREEBSD8 | COMPAT_FREEBSD9 diffs for this. OTOH, this breaks the ABI for existing 10.x binaries, so it needs to be done ASAP. I don't know if any ports use these sysctls directly (psutil might). If so a recompile should generally "fix" them to move them to the new ABI once it is in place. (And yes, Pawel, since you are changing kinfo_file, this is your responsibility to fix.) -- 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: r260206 - head/usr.sbin/bhyve
Author: jhb
Date: Thu Jan 2 21:26:59 2014
New Revision: 260206
URL: http://svnweb.freebsd.org/changeset/base/260206
Log:
Rework the DSDT generation code a bit to generate more accurate info about
LPC devices. Among other things, the LPC serial ports now appear as
ACPI devices.
- Move the info for the top-level PCI bus into the PCI emulation code and
add ResourceProducer entries for the memory ranges decoded by the bus
for memory BARs.
- Add a framework to allow each PCI emulation driver to optionally write
an entry into the DSDT under the \_SB_.PCI0 namespace. The LPC driver
uses this to write a node for the LPC bus (\_SB_.PCI0.ISA).
- Add a linker set to allow any LPC devices to write entries into the
DSDT below the LPC node.
- Move the existing DSDT block for the RTC to the RTC driver.
- Add DSDT nodes for the AT PIC, the 8254 ISA timer, and the LPC UART
devices.
- Add a "SuperIO" device under the LPC node to claim "system resources"
aling with a linker set to allow various drivers to add IO or memory
ranges that should be claimed as a system resource.
- Add system resource entries for the extended RTC IO range, the registers
used for ACPI power management, the ELCR, PCI interrupt routing register,
and post data register.
- Add various helper routines for generating DSDT entries.
Reviewed by: neel (earlier version)
Modified:
head/usr.sbin/bhyve/acpi.c
head/usr.sbin/bhyve/acpi.h
head/usr.sbin/bhyve/atpic.c
head/usr.sbin/bhyve/elcr.c
head/usr.sbin/bhyve/pci_emul.c
head/usr.sbin/bhyve/pci_emul.h
head/usr.sbin/bhyve/pci_lpc.c
head/usr.sbin/bhyve/pci_lpc.h
head/usr.sbin/bhyve/pit_8254.c
head/usr.sbin/bhyve/pm.c
head/usr.sbin/bhyve/post.c
head/usr.sbin/bhyve/rtc.c
Modified: head/usr.sbin/bhyve/acpi.c
==
--- head/usr.sbin/bhyve/acpi.c Thu Jan 2 18:50:52 2014(r260205)
+++ head/usr.sbin/bhyve/acpi.c Thu Jan 2 21:26:59 2014(r260206)
@@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#include
#include
#include
#include
@@ -67,6 +68,7 @@ __FBSDID("$FreeBSD$");
#include "bhyverun.h"
#include "acpi.h"
+#include "pci_emul.h"
/*
* Define the base address of the ACPI tables, and the offsets to
@@ -98,6 +100,13 @@ static uint32_t hpet_capabilities;
static char basl_template[MAXPATHLEN];
static char basl_stemplate[MAXPATHLEN];
+/*
+ * State for dsdt_line(), dsdt_indent(), and dsdt_unindent().
+ */
+static FILE *dsdt_fp;
+static int dsdt_indent_level;
+static int dsdt_error;
+
struct basl_fio {
int fd;
FILE*fp;
@@ -606,119 +615,122 @@ err_exit:
return (errno);
}
+/*
+ * Helper routines for writing to the DSDT from other modules.
+ */
+void
+dsdt_line(const char *fmt, ...)
+{
+ va_list ap;
+ int err;
+
+ if (dsdt_error != 0)
+ return;
+
+ if (strcmp(fmt, "") != 0) {
+ if (dsdt_indent_level != 0)
+ EFPRINTF(dsdt_fp, "%*c", dsdt_indent_level * 2, ' ');
+ va_start(ap, fmt);
+ if (vfprintf(dsdt_fp, fmt, ap) < 0)
+ goto err_exit;
+ va_end(ap);
+ }
+ EFPRINTF(dsdt_fp, "\n");
+ return;
+
+err_exit:
+ dsdt_error = errno;
+}
+
+void
+dsdt_indent(int levels)
+{
+
+ dsdt_indent_level += levels;
+ assert(dsdt_indent_level >= 0);
+}
+
+void
+dsdt_unindent(int levels)
+{
+
+ assert(dsdt_indent_level >= levels);
+ dsdt_indent_level -= levels;
+}
+
+void
+dsdt_fixed_ioport(uint16_t iobase, uint16_t length)
+{
+
+ dsdt_line("IO (Decode16,");
+ dsdt_line(" 0x%04X, // Range Minimum", iobase);
+ dsdt_line(" 0x%04X, // Range Maximum", iobase);
+ dsdt_line(" 0x01, // Alignment");
+ dsdt_line(" 0x%02X, // Length", length);
+ dsdt_line(" )");
+}
+
+void
+dsdt_fixed_irq(uint8_t irq)
+{
+
+ dsdt_line("IRQNoFlags ()");
+ dsdt_line(" {%d}", irq);
+}
+
+void
+dsdt_fixed_mem32(uint32_t base, uint32_t length)
+{
+
+ dsdt_line("Memory32Fixed (ReadWrite,");
+ dsdt_line(" 0x%08X, // Address Base", base);
+ dsdt_line(" 0x%08X, // Address Length", length);
+ dsdt_line(" )");
+}
+
static int
basl_fwrite_dsdt(FILE *fp)
{
int err;
err = 0;
+ dsdt_fp = fp;
+ dsdt_error = 0;
+ dsdt_indent_level = 0;
+
+ dsdt_line("/*");
+ dsdt_line(" * bhyve DSDT template");
+ dsdt_line(" */");
+ dsdt_line("DefinitionBlock (\"bhyve_dsdt.aml\", \"DSDT\", 2,"
+"\"BHYVE \", \"BVDSDT \", 0x0001)");
+ dsdt_line("{");
+ dsdt_line(" Name (_S5, Package (0x02)");
+ dsdt_line(" {");
+ dsdt_line(" 0x05,");
+ dsdt_line(" Zero,");
+ dsdt_line(" })");
+
+ pci_write_dsdt(
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 11:59:35AM -0800, John-Mark Gurney wrote: > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 21:26 +0200: > > On Thu, Jan 02, 2014 at 11:14:20AM -0800, John-Mark Gurney wrote: > > > Konstantin Belousov wrote this message on Thu, Jan 02, 2014 at 15:13 > > > +0200: > > > > > > Afaik you could just remove the "spare" and steal 2 or 4 entries > > > > > > from > > > > > > _kf_ispare until it is sorted. > > > > > > > > > > Yes, this would work for current cap_rights_t structure, at least for > > > > > i386 and amd64, but would only allow to expand the structure by one > > > > > uint64_t in the future (which might or might not be enough). The > > > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts > > > > > without > > > > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > > > > designed to expand, but cannot be, because kinfo_file wasn't modified > > > > > at > > > > > the start of a major branch. > > > > The ABI stability is not limited to the single branch. It must be > > > > preserved across whole project lifetime. > > > > > > Umm. when did this policy change happen? I thought ABI compatibility > > > was limited to major releases of FreeBSD? How are you suppose to do > > > any work if you can't break ABI ever? > > Policy did not changed. Breaking ABI was never allowed, except for the > > kernel management interfaces. Later was only accepted due to tight > > relation of the typical management facilities and internal kernel > > structures, but this is considered a bug. > > Please do no use such absolutes, since the ABI has been allowed to break > in the recent past, as I'm looking at a commit in 2005 that broke struct > kproc_info size... 'Allowed' is wrong term. Correct term is 'bug'. ABI bugs are special because we cannot fix them, due to impact lasting forever in the infected binaries. For kernel panic, you update kernel; for interface breakage, you have no exit strategy, either old or new binaries are broken. > > > > I did a quick search for "freebsd policy abi breakage" and found some > > > mailing list posts about this, but no authoritative statement... > > Re tried to write down the policy, last time it was several years ago. > > The efforts should be revived. > > > > > > > > Of course the problem is that when we move to > > > (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, > > > or introduce tons of compatibility code that will rot... > > > > I do not understand what are you trying to say. > > My point is that once we move to the "new ABI", we will either have to > accept that we stop maintaining the old interface, or we write and > maintain the old interface, but if we do, what's the point of going to > the new interface if the old interface "never" breaks? Point of providing the old interface is to allow old binaries to still work, or degrade in controlled and safe way. pgpC36EnyZxuG.pgp Description: PGP signature
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 03:13:08PM +0200, Konstantin Belousov wrote: > On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote: > > I don't plan to provide alternative way to fetch the cap stuff. Well, I > > implemented libnv, which can be used to reimplement how we fetch all > > data like kinfo_file in a ABI friendly way, but I don't plan to modify > > this specific code myself. > I.e. you break something and decline to fix it, putting the burden on > somebody else. That's a bit too far. I wasn't declining fixing a bug I introduced. I was declining implementing an improvement. That's two very different things. Chose your words more carefully and not only this time. > > Yes, this would work for current cap_rights_t structure, at least for > > i386 and amd64, but would only allow to expand the structure by one > > uint64_t in the future (which might or might not be enough). The > > cap_rights_t structure is designed to be expanded to 5 uint64_ts without > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > designed to expand, but cannot be, because kinfo_file wasn't modified at > > the start of a major branch. > The ABI stability is not limited to the single branch. It must be > preserved across whole project lifetime. [...] To address your statement that either entire ABI is stable or not and there is nothing in between. That's of course incorrect. First of all, we, as a project, don't consider all existing interfaces as stable. This would be a suicide. There are plenty of private interfaces we must and we do break from release to release. There was at least one case, AFAIR, where we broke ABI because of a security issue. I also think that breaking ABI on unused interfaces can be fine too. We don't support ABI compatibility with FreeBSD 1, no matter how close we are, and we had this discussion in the past. I'm also in opinion that even if one day we run out of spare fields in kinfo_* structures the FreeBSD project should not be terminated. Ok, let's be more constructive. I can use existing spare ints. This would move the problem into the future and will break ABI for existing 10-RCs. We can also investigate how huge breakage that is. The sysctl interface is not public API, so I don't believe we should be concerned by its direct consumers. We have two public interfaces for this: libutil's kinfo_getfile(3) which has exactly one in-base consumer - libprocstat, so this change breaks procstat(1) and fstat(1). > This is just awful breakage of _ABI_. We cannot leave it as is, > unless we also claim that project gave up on ABI stability at all. [...] > My own opinion is that the kinfo change must be removed, and the bug > is so critical that another RC must be issued. I personally don't consider it so awful and critical as you do, clearly, but I do recognize it as a problem. I'm happy to consume spares, which should fix compatibility with older releases at the cost of breaking compatibility with 10-RCs. At least for i386 and amd64, not sure how using ints for uint64_t will work for other archs. I'll leave it for re@ to decide. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpbwoYDuzFrD.pgp Description: PGP signature
svn commit: r260207 - head/sys/net
Author: gnn
Date: Thu Jan 2 21:30:59 2014
New Revision: 260207
URL: http://svnweb.freebsd.org/changeset/base/260207
Log:
Convert #defines to enums so that the values are visible in the debugger.
Requested by: gibbs
MFC after:2 weeks
Modified:
head/sys/net/sff8472.h
Modified: head/sys/net/sff8472.h
==
--- head/sys/net/sff8472.h Thu Jan 2 21:26:59 2014(r260206)
+++ head/sys/net/sff8472.h Thu Jan 2 21:30:59 2014(r260207)
@@ -62,104 +62,107 @@
/* Table 3.1 Two-wire interface ID: Data Fields */
-#define SFF_8472_BASE 0xa0 /* Base address for all our queries. */
-#define SFF_8472_ID0 /* Transceiver Type (Table 3.2) */
-#define SFF_8472_EXT_ID1 /* Extended transceiver type (Table
3.3) */
-#define SFF_8472_CONNECTOR 2 /* Connector type (Table 3.4) */
-#define SFF_8472_TRANS_START 3 /* Elec or Optical Compatibility
+enum {
+ SFF_8472_BASE = 0xa0, /* Base address for all our queries.
*/
+ SFF_8472_ID = 0, /* Transceiver Type (Table 3.2) */
+ SFF_8472_EXT_ID = 1, /* Extended transceiver type (Table 3.3)
*/
+ SFF_8472_CONNECTOR = 2, /* Connector type (Table 3.4) */
+ SFF_8472_TRANS_START= 3, /* Elec or Optical Compatibility
* (Table 3.5) */
-#define SFF_8472_TRANS_END 10
-#define SFF_8472_ENCODING 11 /* Encoding Code for high speed
- * serial encoding algorithm (see
- * Table 3.6) */
-#define SFF_8472_BITRATE 12 /* Nominal signaling rate, units
- * of 100MBd. (see details for
- * rates > 25.0Gb/s) */
-#define SFF_8472_RATEID13 /* Type of rate select
- * functionality (see Table
- * 3.6a) */
-#define SFF_8472_LEN_SMF_KM14 /* Link length supported for single
+ SFF_8472_TRANS_END = 10,
+ SFF_8472_ENCODING = 11, /* Encoding Code for high speed
+* serial encoding algorithm (see
+* Table 3.6) */
+ SFF_8472_BITRATE= 12, /* Nominal signaling rate, units
+* of 100MBd. (see details for
+* rates > 25.0Gb/s) */
+ SFF_8472_RATEID = 13, /* Type of rate select
+* functionality (see Table
+* 3.6a) */
+ SFF_8472_LEN_SMF_KM = 14, /* Link length supported for single
* mode fiber, units of km */
-#define SFF_8472_LEN_SMF 15 /* Link length supported for single
+ SFF_8472_LEN_SMF= 15, /* Link length supported for single
* mode fiber, units of 100 m */
-#define SFF_8472_LEN_50UM 16 /* Link length supported for 50 um
+ SFF_8472_LEN_50UM = 16, /* Link length supported for 50 um
* OM2 fiber, units of 10 m */
-#define SFF_8472_LEN_625UM 17 /* Link length supported for 62.5
+ SFF_8472_LEN_625UM = 17, /* Link length supported for 62.5
* um OM1 fiber, units of 10 m */
-#define SFF_8472_LEN_OM4 18 /* Link length supported for 50um
+ SFF_8472_LEN_OM4= 18, /* Link length supported for 50um
* OM4 fiber, units of 10m.
* Alternatively copper or direct
* attach cable, units of m */
-#define SFF_8472_LEN_OM3 19 /* Link length supported for 50 um OM3
fiber, units of 10 m */
-#define SFF_8472_VENDOR_START 20 /* Vendor name [Address A0h, Bytes
+ SFF_8472_LEN_OM3= 19, /* Link length supported for 50 um OM3
fiber, units of 10 m */
+ SFF_8472_VENDOR_START = 20, /* Vendor name [Address A0h, Bytes
* 20-35] */
-#define SFF_8472_VENDOR_END35
-#define SFF_8472_TRANS 36 /* Transceiver Code for electronic
+ SFF_8472_VENDOR_END = 35,
+ SFF_8472_TRANS = 36, /* Transceiver Code for electronic
* or optical compatibility (see
* Table 3.5) */
-#define SFF_8472_VENDOR_OUI_START 37 /* Vendor OUI SFP vendor IEEE
+ SFF_8472_VENDOR_OUI_START = 37, /* Vendor OUI SFP vendor IEEE
* company ID */
-#define SFF_8472_VENDOR_OUI_END39
-#define SFF_8472_PN_START 40 /* Vendor PN */
-#define SFF_8472_PN_END55
-#define SFF_8472_REV_START 56 /* Vendor Revision */
-#define SFF_8472_REV_END 59
-#define SFF_8472_WAVELEN_START
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 10:27:57PM +0100, Pawel Jakub Dawidek wrote: > I'll leave it for re@ to decide. Proposed patch: http://people.freebsd.org/~pjd/patches/sys_user.h.patch -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpVLF904ptQE.pgp Description: PGP signature
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Thu, Jan 02, 2014 at 10:27:58PM +0100, Pawel Jakub Dawidek wrote: > On Thu, Jan 02, 2014 at 03:13:08PM +0200, Konstantin Belousov wrote: > > On Thu, Jan 02, 2014 at 11:49:04AM +0100, Pawel Jakub Dawidek wrote: > > > I don't plan to provide alternative way to fetch the cap stuff. Well, I > > > implemented libnv, which can be used to reimplement how we fetch all > > > data like kinfo_file in a ABI friendly way, but I don't plan to modify > > > this specific code myself. > > I.e. you break something and decline to fix it, putting the burden on > > somebody else. > > That's a bit too far. I wasn't declining fixing a bug I introduced. > I was declining implementing an improvement. That's two very different > things. Chose your words more carefully and not only this time. I read this as decline to fix the ABI breakage. I am sorry. > > > > Yes, this would work for current cap_rights_t structure, at least for > > > i386 and amd64, but would only allow to expand the structure by one > > > uint64_t in the future (which might or might not be enough). The > > > cap_rights_t structure is designed to be expanded to 5 uint64_ts without > > > breaking ABI. I don't want to stuck with current cap_rights_t that is > > > designed to expand, but cannot be, because kinfo_file wasn't modified at > > > the start of a major branch. > > The ABI stability is not limited to the single branch. It must be > > preserved across whole project lifetime. > [...] > > To address your statement that either entire ABI is stable or not and > there is nothing in between. That's of course incorrect. > > First of all, we, as a project, don't consider all existing interfaces > as stable. This would be a suicide. There are plenty of private > interfaces we must and we do break from release to release. Yes. > > There was at least one case, AFAIR, where we broke ABI because of a > security issue. > > I also think that breaking ABI on unused interfaces can be fine too. Probably yes. > > We don't support ABI compatibility with FreeBSD 1, no matter how close > we are, and we had this discussion in the past. Yes, backward compatibility is a practical feature, and as each practical thing, it has its usefulness limits. But, for active interfaces, it is a binary state, and kinfo_file definitely falls into the active and recent interfaces pool. > > I'm also in opinion that even if one day we run out of spare fields in > kinfo_* structures the FreeBSD project should not be terminated. Sure, we provide the backward compat when we are unable to extend the current interface. This is routinely done with syscalls and sysctls. See kinfo_ofile as the relevant example. John also wrote about this. > > Ok, let's be more constructive. > > I can use existing spare ints. This would move the problem into the > future and will break ABI for existing 10-RCs. > > We can also investigate how huge breakage that is. The sysctl interface > is not public API, so I don't believe we should be concerned by its > direct consumers. We have two public interfaces for this: > > libutil's kinfo_getfile(3) which has exactly one in-base consumer - > libprocstat, so this change breaks procstat(1) and fstat(1). It started from the report of valgrind breakage AFAIR. > > > This is just awful breakage of _ABI_. We cannot leave it as is, > > unless we also claim that project gave up on ABI stability at all. > [...] > > My own opinion is that the kinfo change must be removed, and the bug > > is so critical that another RC must be issued. > > I personally don't consider it so awful and critical as you do, clearly, > but I do recognize it as a problem. I'm happy to consume spares, which > should fix compatibility with older releases at the cost of breaking > compatibility with 10-RCs. At least for i386 and amd64, not sure how > using ints for uint64_t will work for other archs. At the moment, only x86 is considered Tier-1, which we guarantee to have stable ABI. From the inspection of the patch referenced in the followup message, I think that other architectures should be fine too, but I did not verified this. > > I'll leave it for re@ to decide. My opinion is that the patch should go into HEAD with the 3-day MFC track to stable/10. Then, it is up to re to decide indeed, my vote already is to allow this for releng/10.0 and to have RC5, unfortunately. pgp4BETDnYcut.pgp Description: PGP signature
Re: svn commit: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14, 8:34 PM, Konstantin Belousov wrote: On Thu, Jan 02, 2014 at 11:23:55AM -0800, Alfred Perlstein wrote: Of course the problem is that when we move to (ASN.1/libnv/ctf/YAML/JSON/XML/etc) we will break ABI compatibility too, or introduce tons of compatibility code that will rot... I agree, however there is a very easy way to fix it for the time being. Let's not be binary about it "well it's going to have to break, so let's break it!" when such an easy way to not break it exists. It should be "let's see if there's a non-intrusive way of not breaking it" and the answer to that seems to be "yes". If parts of ABI is broken, then why spend efforts trying to keep other parts stable ? You already have random set of binaries broken, sometimes in subtle way. Then, making other interfaces stable is just a waste. ABI stability is a yes/no proposition, you cannot have it partly done. Personally, I do not want to spend a time on hobbyist system. BTW, to point out obvious thing, Linux has almost perfect ABI stability and forward compatibility. It is pity to see that our people do not understand the importance and benefits of it. I always assume that there is a subset of programs that will not run in jails of different major releases, and that must be replaced by statically linked versions of the new ones.. these include ifconfig, netstat, ps, top and other similar programs. ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On 1/2/14, 10:27 PM, Pawel Jakub Dawidek wrote: I also think that breaking ABI on unused interfaces can be fine too. We don't support ABI compatibility with FreeBSD 1, no matter how close we are, and we had this discussion in the past. actually, we do.. I have run FreebSD 1 binaries as recently as a year ago. the get a "make world" to work you need a small kernel change. (limit PIDS to < 6) or it hangs after a few minutes. ___ 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: r260210 - head/sys/dev/cxgbe
Author: adrian
Date: Thu Jan 2 23:23:33 2014
New Revision: 260210
URL: http://svnweb.freebsd.org/changeset/base/260210
Log:
Add an option to enable or disable the small RX packet copying that
is done to improve performance of small frames.
When doing RX packing, the RX copying isn't necessarily required.
Reviewed by: np
Modified:
head/sys/dev/cxgbe/adapter.h
head/sys/dev/cxgbe/t4_main.c
head/sys/dev/cxgbe/t4_sge.c
Modified: head/sys/dev/cxgbe/adapter.h
==
--- head/sys/dev/cxgbe/adapter.hThu Jan 2 23:17:48 2014
(r260209)
+++ head/sys/dev/cxgbe/adapter.hThu Jan 2 23:23:33 2014
(r260210)
@@ -646,6 +646,8 @@ struct adapter {
const char *last_op;
const void *last_op_thr;
#endif
+
+ int sc_do_rxcopy;
};
#define ADAPTER_LOCK(sc) mtx_lock(&(sc)->sc_lock)
Modified: head/sys/dev/cxgbe/t4_main.c
==
--- head/sys/dev/cxgbe/t4_main.cThu Jan 2 23:17:48 2014
(r260209)
+++ head/sys/dev/cxgbe/t4_main.cThu Jan 2 23:23:33 2014
(r260210)
@@ -4239,6 +4239,10 @@ t4_sysctls(struct adapter *sc)
oid = device_get_sysctl_tree(sc->dev);
c0 = children = SYSCTL_CHILDREN(oid);
+ sc->sc_do_rxcopy = 1;
+ SYSCTL_ADD_INT(ctx, children, OID_AUTO, "do_rx_copy", CTLFLAG_RW,
+ &sc->sc_do_rxcopy, 1, "Do RX copy of small frames");
+
SYSCTL_ADD_INT(ctx, children, OID_AUTO, "nports", CTLFLAG_RD, NULL,
sc->params.nports, "# of ports");
Modified: head/sys/dev/cxgbe/t4_sge.c
==
--- head/sys/dev/cxgbe/t4_sge.c Thu Jan 2 23:17:48 2014(r260209)
+++ head/sys/dev/cxgbe/t4_sge.c Thu Jan 2 23:23:33 2014(r260210)
@@ -1447,7 +1447,7 @@ get_fl_payload1(struct adapter *sc, stru
bus_dmamap_sync(fl->tag[sd->tag_idx], sd->map,
BUS_DMASYNC_POSTREAD);
- if (len < RX_COPY_THRESHOLD) {
+ if (sc->sc_do_rxcopy && (len < RX_COPY_THRESHOLD)) {
#ifdef T4_PKT_TIMESTAMP
/* Leave room for a timestamp */
m0->m_data += 8;
@@ -1598,7 +1598,7 @@ get_fl_payload2(struct adapter *sc, stru
bus_dmamap_sync(fl->tag[sd->tag_idx], sd->map, BUS_DMASYNC_POSTREAD);
- if (len < RX_COPY_THRESHOLD) {
+ if (sc->sc_do_rxcopy && (len < RX_COPY_THRESHOLD)) {
#ifdef T4_PKT_TIMESTAMP
/* Leave room for a timestamp */
m0->m_data += 8;
___
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: r260212 - head/sys/dev/nand
Author: imp
Date: Fri Jan 3 00:17:52 2014
New Revision: 260212
URL: http://svnweb.freebsd.org/changeset/base/260212
Log:
The HOT-E HL201 has 128MB Samsung SLC NAND, ID it properly.
Modified:
head/sys/dev/nand/nand_id.c
Modified: head/sys/dev/nand/nand_id.c
==
--- head/sys/dev/nand/nand_id.c Thu Jan 2 23:24:50 2014(r260211)
+++ head/sys/dev/nand/nand_id.c Fri Jan 3 00:17:52 2014(r260212)
@@ -41,6 +41,8 @@ struct nand_params nand_ids[] = {
0x200, 0x800, 0x40, 0x40, 0 },
{ { NAND_MAN_SAMSUNG, 0xda }, "Samsung NAND 256MiB 3,3V 8-bit",
0x100, 0x800, 0x40, 0x40, 0 },
+ { { NAND_MAN_SAMSUNG, 0xf1 }, "Samsung NAND 128MiB 3,3V 8-bit",
+ 0x80, 0x800, 0x40, 0x40, 0 },
{ { NAND_MAN_HYNIX, 0x76 }, "Hynix NAND 64MiB 3,3V 8-bit",
0x40, 0x200, 0x10, 0x20, 0 },
{ { NAND_MAN_HYNIX, 0xdc }, "Hynix NAND 512MiB 3,3V 8-bit",
___
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: r260214 - head/sys/dev/nand
Author: imp
Date: Fri Jan 3 00:26:56 2014
New Revision: 260214
URL: http://svnweb.freebsd.org/changeset/base/260214
Log:
Fill in some more info about the (somewhat old) Samsung parts I have
here...
Modified:
head/sys/dev/nand/nand_id.c
Modified: head/sys/dev/nand/nand_id.c
==
--- head/sys/dev/nand/nand_id.c Fri Jan 3 00:18:38 2014(r260213)
+++ head/sys/dev/nand/nand_id.c Fri Jan 3 00:26:56 2014(r260214)
@@ -33,21 +33,21 @@ __FBSDID("$FreeBSD$");
#include
struct nand_params nand_ids[] = {
- { { NAND_MAN_SAMSUNG, 0x75 }, "Samsung K9F5608U0B",
+ { { NAND_MAN_SAMSUNG, 0x75 }, "Samsung K9F5608U0B NAND 32MiB 1-bit",
0x20, 0x200, 0x10, 0x20, 0 },
{ { NAND_MAN_SAMSUNG, 0xd3 }, "Samsung NAND 1GiB 3,3V 8-bit",
0x400, 0x800, 0x40, 0x40, 0 },
{ { NAND_MAN_SAMSUNG, 0xdc }, "Samsung NAND 512MiB 3,3V 8-bit",
0x200, 0x800, 0x40, 0x40, 0 },
- { { NAND_MAN_SAMSUNG, 0xda }, "Samsung NAND 256MiB 3,3V 8-bit",
+ { { NAND_MAN_SAMSUNG, 0xda }, "Samsung K9F2G08U0A NAND 256MiB 3,3V
8-bit",
0x100, 0x800, 0x40, 0x40, 0 },
- { { NAND_MAN_SAMSUNG, 0xf1 }, "Samsung NAND 128MiB 3,3V 8-bit",
+ { { NAND_MAN_SAMSUNG, 0xf1 }, "Samsung K9F1G08U0A NAND 128MiB 3,3V
8-bit",
0x80, 0x800, 0x40, 0x40, 0 },
{ { NAND_MAN_HYNIX, 0x76 }, "Hynix NAND 64MiB 3,3V 8-bit",
0x40, 0x200, 0x10, 0x20, 0 },
{ { NAND_MAN_HYNIX, 0xdc }, "Hynix NAND 512MiB 3,3V 8-bit",
0x200, 0x800, 0x40, 0x40, 0 },
- { { NAND_MAN_HYNIX, 0x79 }, "NAND 128MB 3,3V 8-bit",
+ { { NAND_MAN_HYNIX, 0x79 }, "Hynix NAND 128MB 3,3V 8-bit",
0x80, 0x200, 0x10, 0x20, 0 },
{ { NAND_MAN_STMICRO, 0xf1 }, "STMicro 128MB 3,3V 8-bit",
0x80, 2048, 64, 0x40, 0 },
___
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: r260217 - in head/sys: netinet netinet6
Author: ae
Date: Fri Jan 3 02:32:05 2014
New Revision: 260217
URL: http://svnweb.freebsd.org/changeset/base/260217
Log:
Add IF_AFDATA_WLOCK_ASSERT() in case lla_lookup() is called with
LLE_CREATE flag.
MFC after:1 week
Modified:
head/sys/netinet/in.c
head/sys/netinet6/in6.c
Modified: head/sys/netinet/in.c
==
--- head/sys/netinet/in.c Fri Jan 3 02:22:45 2014(r260216)
+++ head/sys/netinet/in.c Fri Jan 3 02:32:05 2014(r260217)
@@ -1127,6 +1127,7 @@ in_lltable_lookup(struct lltable *llt, u
#endif
if (!(flags & LLE_CREATE))
return (NULL);
+ IF_AFDATA_WLOCK_ASSERT(ifp);
/*
* A route that covers the given address must have
* been installed 1st because we are doing a resolution,
Modified: head/sys/netinet6/in6.c
==
--- head/sys/netinet6/in6.c Fri Jan 3 02:22:45 2014(r260216)
+++ head/sys/netinet6/in6.c Fri Jan 3 02:32:05 2014(r260217)
@@ -2332,6 +2332,7 @@ in6_lltable_lookup(struct lltable *llt,
if (lle == NULL) {
if (!(flags & LLE_CREATE))
return (NULL);
+ IF_AFDATA_WLOCK_ASSERT(ifp);
/*
* A route that covers the given address must have
* been installed 1st because we are doing a resolution,
___
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: r260218 - head/sys/netinet6
Author: ae Date: Fri Jan 3 02:40:56 2014 New Revision: 260218 URL: http://svnweb.freebsd.org/changeset/base/260218 Log: Use pointer to struct sockaddr_in6 in lla_lookup() call. This prevents from triggering KASSERT in in6_lltable_lookup. Modified: head/sys/netinet6/in6_src.c Modified: head/sys/netinet6/in6_src.c == --- head/sys/netinet6/in6_src.c Fri Jan 3 02:32:05 2014(r260217) +++ head/sys/netinet6/in6_src.c Fri Jan 3 02:40:56 2014(r260218) @@ -621,7 +621,7 @@ selectroute(struct sockaddr_in6 *dstsock rt = ron->ro_rt; ifp = rt->rt_ifp; IF_AFDATA_RLOCK(ifp); - la = lla_lookup(LLTABLE6(ifp), 0, (struct sockaddr *)&sin6_next->sin6_addr); + la = lla_lookup(LLTABLE6(ifp), 0, (struct sockaddr *)sin6_next); IF_AFDATA_RUNLOCK(ifp); if (la != NULL) LLE_RUNLOCK(la); ___ 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: r255219 - in head: contrib/tcpdump lib/libc lib/libc/capability lib/libc/include lib/libc/sys lib/libprocstat sbin/dhclient sbin/hastd sys/amd64/linux32 sys/bsm sys/cddl/compat/opensol
On Jan 2, 2014, at 1:27 PM, Pawel Jakub Dawidek wrote: > I personally don't consider it so awful and critical as you do, clearly, > but I do recognize it as a problem. I'm happy to consume spares, which > should fix compatibility with older releases at the cost of breaking > compatibility with 10-RCs. At least for i386 and amd64, not sure how > using ints for uint64_t will work for other arches. Personally, I’d prefer if we use spare fields for now. That will allow us to maintain ABI stability for the current release, and have enough time to implement the new, incompatible, interface in addition to the old one in HEAD. The interface is used a lot by 3rd party applications to obtain the information about open file descriptors (in place of the Linux’ /proc interface), and this change will leave 9.x and before binaries broken in a subtle way on 10.x and beyond. Most of the commercial applications are shipped compiled against 9.x or even 8.x and 7.x, and although the extent of the damage is unknown, it might turn out to be a problem. To me, it seems that breaking the ABI with 10.x RC is less dangerous. -- ST4096-RIPE ___ 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: r260219 - in head: share/man/man4 sys/dev/usb sys/dev/usb/wlan
Author: kevlo Date: Fri Jan 3 06:01:05 2014 New Revision: 260219 URL: http://svnweb.freebsd.org/changeset/base/260219 Log: Add support for the MediaTek/Ralink RT3593 chipset. Committed over the ZyXEL NWD2705 on amd64 with WPA. Modified: head/share/man/man4/run.4 head/sys/dev/usb/usbdevs head/sys/dev/usb/wlan/if_run.c head/sys/dev/usb/wlan/if_runreg.h head/sys/dev/usb/wlan/if_runvar.h Modified: head/share/man/man4/run.4 == --- head/share/man/man4/run.4 Fri Jan 3 02:40:56 2014(r260218) +++ head/share/man/man4/run.4 Fri Jan 3 06:01:05 2014(r260219) @@ -16,7 +16,7 @@ .\" .\" $FreeBSD$ .\" -.Dd December 27, 2013 +.Dd January 3, 2014 .Dt RUN 4 .Os .Sh NAME @@ -64,8 +64,17 @@ The RT3000U is a single-chip solution ba an RT3020 (1T1R), RT3021 (1T2R) or RT3022 (2T2R) single-band radio transceiver. .Pp -The RT3900E is a single-chip solution based on an RT5390 MAC/BBP and -an RT5370 (1T1R) or RT5372 (2T2R) single-band radio transceiver. +The RT3900E is a single-chip USB 2.0 802.11n solution. +The MAC/Baseband Processor can be an RT3593, RT5390, RT5392 or an RT5592. +The radio can be an RT3053, RT5370, RT5372 or an RT5572. +The RT3053 chip operates in the 2GHz and 5GHz spectra and supports up to +3 transmit paths and 3 receiver paths (3T3R). +The RT5370 chip operates in the 2GHz spectrum and supports 1 transmit path +and 1 receiver path (1T1R). +The RT5372 chip operates in the 2GHz spectrum and supports up to 2 transmit +paths and 2 receiver paths (2T2R). +The RT5572 chip operates in the 2GHz and 5GHz spectra and supports up to +2 transmit paths and 2 receiver paths (2T2R). .Pp These are the modes the .Nm @@ -116,11 +125,13 @@ driver supports the following wireless a .It Airlink101 AWLL6090 .It ASUS USB-N11 .It ASUS USB-N13 ver. A1 +.It ASUS USB-N66 .It ASUS WL-160N .It Belkin F5D8051 ver 3000 .It Belkin F5D8053 .It Belkin F5D8055 .It Belkin F6D4050 ver 1 +.It Belkin F9L1103 .It Buffalo WLI-UC-AG300N .It Buffalo WLI-UC-G300N .It Buffalo WLI-UC-G301N @@ -134,11 +145,13 @@ driver supports the following wireless a .It D-Link DWA-130 rev B1 .It D-Link DWA-140 rev B1, B2, B3, D1 .It D-Link DWA-160 rev B2 +.It D-Link DWA-162 .It DrayTek Vigor N61 .It Edimax EW-7711UAn .It Edimax EW-7711UTn .It Edimax EW-7717Un .It Edimax EW-7718Un +.It Edimax EW-7733UnD .It Gigabyte GN-WB30N .It Gigabyte GN-WB31N .It Gigabyte GN-WB32L @@ -164,6 +177,7 @@ driver supports the following wireless a .It TP-LINK TL-WN727N v3 .It Unex DNUR-81 .It Unex DNUR-82 +.It ZyXEL NWD2705 .It ZyXEL NWD210N .It ZyXEL NWD270N .El @@ -235,4 +249,4 @@ driver was written by The .Nm driver does not support any of the 802.11n capabilities offered by the -RT2800 and RT3000 chipsets. +RT2800, RT3000 and RT3900 chipsets. Modified: head/sys/dev/usb/usbdevs == --- head/sys/dev/usb/usbdevsFri Jan 3 02:40:56 2014(r260218) +++ head/sys/dev/usb/usbdevsFri Jan 3 06:01:05 2014(r260219) @@ -1146,6 +1146,7 @@ product ASUS USBN13 0x1784 USB-N13 productASUS RT3070_1 0x1790 RT3070 product ASUS USBN100x1786 USB-N10 product ASUS RTL8192CU 0x17ab RTL8192CU +product ASUS USBN660x17ad USB-N66 product ASUS RTL8192SU 0x1791 RTL8192SU product ASUS A730W 0x4202 ASUS MyPal A730W product ASUS P535 0x420f ASUS P535 PDA @@ -1245,6 +1246,7 @@ product BELKIN F5U409 0x0409 F5U409 Ser product BELKIN F6C550AVR 0x0551 F6C550-AVR UPS product BELKIN F5U120 0x1203 F5U120-PC Hub product BELKIN RTL8188CU 0x1102 RTL8188CU Wireless Adapter +product BELKIN F9L1103 0x1103 F9L1103 Wireless Adapter product BELKIN RTL8192CU 0x2102 RTL8192CU Wireless Adapter product BELKIN F7D2102 0x2103 F7D2102 Wireless Adapter product BELKIN ZD1211B 0x4050 ZD1211B @@ -1558,6 +1560,7 @@ product DLINK RT3072 0x3c0a RT3072 product DLINK DWA140B3 0x3c15 DWA-140 rev B3 product DLINK DWA160B2 0x3c1a DWA-160 rev B2 product DLINK DWA127 0x3c1b DWA-127 Wireless Adapter +product DLINK DWA162 0x3c1f DWA-162 Wireless Adapter product DLINK DWA140D1 0x3c20 DWA-140 rev D1 product DLINK DSB650C 0x4000 10Mbps Ethernet product DLINK DSB650TX10x4001 10/100 Ethernet @@ -1619,6 +1622,7 @@ product EDIMAX EW7622UMN 0x7622 EW-7622U product EDIMAX RT2870_10x7711 RT2870 product EDIMAX EW7717 0x7717 EW-7717 product EDIMAX EW7718 0x7718 EW-7718 +product EDIMAX EW7733UND 0x7733 EW-7733UnD product EDIMAX EW7811UN0x7811 EW-7811Un productEDIMAX RTL8192CU0x7822 RTL8192CU @@ -3608,6 +3612,7 @@ product RALINK RT3071 0x3071 RT307
svn commit: r260220 - head/etc/devd
Author: kevlo
Date: Fri Jan 3 06:02:08 2014
New Revision: 260220
URL: http://svnweb.freebsd.org/changeset/base/260220
Log:
Regen.
Modified:
head/etc/devd/usb.conf
Modified: head/etc/devd/usb.conf
==
--- head/etc/devd/usb.conf Fri Jan 3 06:01:05 2014(r260219)
+++ head/etc/devd/usb.conf Fri Jan 3 06:02:08 2014(r260220)
@@ -721,6 +721,14 @@ nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
match "vendor" "0x050d";
+ match "product" "0x1103";
+ action "kldload -n if_run";
+};
+
+nomatch 32 {
+ match "bus" "uhub[0-9]+";
+ match "mode" "host";
+ match "vendor" "0x050d";
match "product" "0x1203";
action "kldload -n ubsa";
};
@@ -1064,6 +1072,14 @@ nomatch 32 {
nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
+ match "vendor" "0x0586";
+ match "product" "0x3421";
+ action "kldload -n if_run";
+};
+
+nomatch 32 {
+ match "bus" "uhub[0-9]+";
+ match "mode" "host";
match "vendor" "0x058f";
match "product" "0x9720";
action "kldload -n uplcom";
@@ -2313,6 +2329,14 @@ nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
match "vendor" "0x0b05";
+ match "product" "0x17ad";
+ action "kldload -n if_run";
+};
+
+nomatch 32 {
+ match "bus" "uhub[0-9]+";
+ match "mode" "host";
+ match "vendor" "0x0b05";
match "product" "(0x17b5|0x17cb)";
action "kldload -n ng_ubt";
};
@@ -3825,7 +3849,7 @@ nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
match "vendor" "0x148f";
- match "product"
"(0x2770|0x2870|0x3070|0x3071|0x3072|0x3370|0x3572|0x5370|0x5572|0x8070)";
+ match "product"
"(0x2770|0x2870|0x2878|0x3070|0x3071|0x3072|0x3370|0x3572|0x3573|0x5370|0x5572|0x8070)";
action "kldload -n if_run";
};
@@ -4625,7 +4649,7 @@ nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
match "vendor" "0x2001";
- match "product" "(0x3c09|0x3c0a|0x3c15|0x3c1a|0x3c1b|0x3c20)";
+ match "product" "(0x3c09|0x3c0a|0x3c15|0x3c1a|0x3c1b|0x3c1f)";
action "kldload -n if_run";
};
@@ -5057,7 +5081,7 @@ nomatch 32 {
match "bus" "uhub[0-9]+";
match "mode" "host";
match "vendor" "0x7392";
- match "product" "(0x7711|0x7717|0x7718)";
+ match "product" "(0x7711|0x7717|0x7718|0x7733)";
action "kldload -n if_run";
};
@@ -5341,5 +5365,5 @@ nomatch 32 {
action "kldload -n umass";
};
-# 2577 USB entries processed
+# 2583 USB entries processed
___
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"
