svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
Author: mav Date: Sun Apr 24 08:58:58 2011 New Revision: 220982 URL: http://svn.freebsd.org/changeset/base/220982 Log: Switch the GENERIC kernels for all architectures to the new CAM-based ATA stack. It means that all legacy ATA drivers are disabled and replaced by respective CAM drivers. If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential numbers for each type in order of detection, unless configured otherwise with tunables, see cam(4)). ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool for management. Instead of /dev/arX device names, use /dev/raid/rX. Modified: head/UPDATING head/sys/amd64/conf/GENERIC head/sys/arm/conf/AVILA head/sys/arm/conf/CAMBRIA head/sys/arm/conf/CRB head/sys/arm/conf/DB-78XXX head/sys/arm/conf/DB-88F5XXX head/sys/arm/conf/DB-88F6XXX head/sys/arm/conf/EP80219 head/sys/arm/conf/IQ31244 head/sys/arm/conf/TS7800 head/sys/conf/NOTES head/sys/i386/conf/GENERIC head/sys/i386/conf/XBOX head/sys/ia64/conf/GENERIC head/sys/mips/conf/MALTA head/sys/mips/conf/MALTA64 head/sys/mips/conf/OCTEON1 head/sys/mips/conf/std.SWARM head/sys/mips/malta/std.malta head/sys/pc98/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/powerpc/conf/GENERIC64 head/sys/powerpc/conf/MPC85XX head/sys/sparc64/conf/GENERIC head/sys/sun4v/conf/GENERIC Modified: head/UPDATING == --- head/UPDATING Sun Apr 24 01:11:28 2011(r220981) +++ head/UPDATING Sun Apr 24 08:58:58 2011(r220982) @@ -22,6 +22,34 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9. machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) +20110424: + The GENERIC kernels for all architectures now default to the new + CAM-based ATA stack. It means that all legacy ATA drivers were + removed and replaced by respective CAM drivers. If you are using + ATA device names in /etc/fstab or other places, make sure to update + them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, + where 'Y's are the sequential numbers for each type in order of + detection, unless configured otherwise with tunables, see cam(4)). + + ataraid(4) functionality is now supported by the RAID GEOM class. + To use it you can load geom_raid kernel module and use graid(8) tool + for management. Instead of /dev/arX device names, use /dev/raid/rX. + + No kernel config options or code have been removed, so if a problem + arises, please report it and optionally revert to the old ATA stack. + In order to do it you can remove from the kernel config: + optionsATA_CAM + device ahci + device mvs + device siis + , and instead add back: + device atadisk # ATA disk drives + device ataraid # ATA RAID drives + device atapicd # ATAPI CDROM drives + device atapifd # ATAPI floppy drives + device atapist # ATAPI tape drives + optionsATA_STATIC_ID # Static device numbering + 20110423: The default NFS server has been changed to the new server, which was referred to as the experimental server. If you need to switch Modified: head/sys/amd64/conf/GENERIC == --- head/sys/amd64/conf/GENERIC Sun Apr 24 01:11:28 2011(r220981) +++ head/sys/amd64/conf/GENERIC Sun Apr 24 08:58:58 2011(r220982) @@ -89,14 +89,12 @@ device pci # Floppy drives device fdc -# ATA and ATAPI devices -device ata -device atadisk # ATA disk drives -device ataraid # ATA RAID drives -device atapicd # ATAPI CDROM drives -device atapifd # ATAPI floppy drives -device atapist # ATAPI tape drives -optionsATA_STATIC_ID # Static device numbering +# ATA controllers +device ahci# AHCI-compatible SATA controllers +device ata # Legacy ATA/SATA controllers +optionsATA_CAM # Handle legacy controllers with CAM +device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA +device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices @@ -120,13 +118,13 @@ deviceadw # Advansys wide SCSI adapte device aic # Adaptec
Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, 24 Apr 2011 08:58:58 + (UTC) Alexander Motin wrote: > If you are using ATA > device names in /etc/fstab or other places, make sure to update them > respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, > where 'Y's are the sequential numbers for each type in order of > detection, unless configured otherwise with tunables, see cam(4)). People might expect that if ata(4) numbering starts with ad4, ada4 would be created. However on my machines I've seen ad4 get mapped to ada0. -- Bruce Cran ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24.04.2011 12:06, Bruce Cran wrote: On Sun, 24 Apr 2011 08:58:58 + (UTC) Alexander Motin wrote: If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential numbers for each type in order of detection, unless configured otherwise with tunables, see cam(4)). People might expect that if ata(4) numbering starts with ad4, ada4 would be created. However on my machines I've seen ad4 get mapped to ada0. Yes. With sequential I mean from 0 and up. :) What's about 4, I believe not so many people still remember what does it mean, and probably none for whom that reason is important now. :) -- Alexander Motin ___ 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: r220983 - head
Author: mav Date: Sun Apr 24 09:23:08 2011 New Revision: 220983 URL: http://svn.freebsd.org/changeset/base/220983 Log: Explicitly note that device numbers are starting from zero. Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Sun Apr 24 08:58:58 2011(r220982) +++ head/UPDATING Sun Apr 24 09:23:08 2011(r220983) @@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9. removed and replaced by respective CAM drivers. If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, - where 'Y's are the sequential numbers for each type in order of - detection, unless configured otherwise with tunables, see cam(4)). + where 'Y's are the sequential numbers starting from zero for each type + in order of detection, unless configured otherwise with tunables, + see cam(4)). ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, 24 Apr 2011 12:15:51 +0300 Alexander Motin wrote: > On 24.04.2011 12:06, Bruce Cran wrote: > > People might expect that if ata(4) numbering starts with ad4, ada4 > > would be created. However on my machines I've seen ad4 get mapped to > > ada0. > > Yes. With sequential I mean from 0 and up. :) Sorry I didn't read it properly and sent my reply before I noticed you said adX -> adaY, not adX -> adaX. -- Bruce Cran ___ 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: r220983 - head
On Sun Apr 24 11, Alexander Motin wrote:
> Author: mav
> Date: Sun Apr 24 09:23:08 2011
> New Revision: 220983
> URL: http://svn.freebsd.org/changeset/base/220983
>
> Log:
> Explicitly note that device numbers are starting from zero.
>
> Modified:
> head/UPDATING
>
> Modified: head/UPDATING
> ==
> --- head/UPDATING Sun Apr 24 08:58:58 2011(r220982)
> +++ head/UPDATING Sun Apr 24 09:23:08 2011(r220983)
> @@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
> removed and replaced by respective CAM drivers. If you are using
> ATA device names in /etc/fstab or other places, make sure to update
> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
> - where 'Y's are the sequential numbers for each type in order of
> - detection, unless configured otherwise with tunables, see cam(4)).
> + where 'Y's are the sequential numbers starting from zero for each type
> + in order of detection, unless configured otherwise with tunables,
> + see cam(4)).
maybe an extra sentence mentioning the fact that {geom,ufs}-labels and ufsids
are preferred over device nodes nowadays would be a good idea?
cheers.
alex
>
> ataraid(4) functionality is now supported by the RAID GEOM class.
> To use it you can load geom_raid kernel module and use graid(8) tool
--
a13x
___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote: > Author: mav > Date: Sun Apr 24 08:58:58 2011 > New Revision: 220982 > URL: http://svn.freebsd.org/changeset/base/220982 > > Log: > Switch the GENERIC kernels for all architectures to the new CAM-based ATA > stack. It means that all legacy ATA drivers are disabled and replaced by > respective CAM drivers. If you are using ATA device names in /etc/fstab or > other places, make sure to update them respectively (adX -> adaY, > acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential > numbers for each type in order of detection, unless configured otherwise > with tunables, see cam(4)). > > ataraid(4) functionality is now supported by the RAID GEOM class. > To use it you can load geom_raid kernel module and use graid(8) tool > for management. Instead of /dev/arX device names, use /dev/raid/rX. How many raid implementations, in particular, stripe and mirror ? Is gstripe/gmirror merged, or planned to be merged with geom_raid ? Does it make sense to merge if not yet ? pgptdXmkzc68r.pgp Description: PGP signature
Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24.04.2011 13:07, Kostik Belousov wrote: On Sun, Apr 24, 2011 at 08:58:58AM +, Alexander Motin wrote: Author: mav Date: Sun Apr 24 08:58:58 2011 New Revision: 220982 URL: http://svn.freebsd.org/changeset/base/220982 Log: Switch the GENERIC kernels for all architectures to the new CAM-based ATA stack. It means that all legacy ATA drivers are disabled and replaced by respective CAM drivers. If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential numbers for each type in order of detection, unless configured otherwise with tunables, see cam(4)). ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool for management. Instead of /dev/arX device names, use /dev/raid/rX. How many raid implementations, in particular, stripe and mirror ? Same as before: one out, another in. Is gstripe/gmirror merged, or planned to be merged with geom_raid ? Does it make sense to merge if not yet ? It is definitely possible, but it is not done yet to not put all eggs in one basket. -- Alexander Motin ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote: > Author: mav > Date: Sun Apr 24 08:58:58 2011 > New Revision: 220982 > URL: http://svn.freebsd.org/changeset/base/220982 > > Log: > Switch the GENERIC kernels for all architectures to the new CAM-based ATA > stack. It means that all legacy ATA drivers are disabled and replaced by > respective CAM drivers. If you are using ATA device names in /etc/fstab or > other places, make sure to update them respectively (adX -> adaY, > acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential > numbers for each type in order of detection, unless configured otherwise > with tunables, see cam(4)). Are you going to address that on updating magic will make it work within the next 2-4 weeks? If you will not then thanks for screwing 50% of our users and please back this out again. > ataraid(4) functionality is now supported by the RAID GEOM class. > To use it you can load geom_raid kernel module and use graid(8) tool > for management. Instead of /dev/arX device names, use /dev/raid/rX. > > Modified: > head/UPDATING > head/sys/amd64/conf/GENERIC > head/sys/arm/conf/AVILA > head/sys/arm/conf/CAMBRIA > head/sys/arm/conf/CRB > head/sys/arm/conf/DB-78XXX > head/sys/arm/conf/DB-88F5XXX > head/sys/arm/conf/DB-88F6XXX > head/sys/arm/conf/EP80219 > head/sys/arm/conf/IQ31244 > head/sys/arm/conf/TS7800 > head/sys/conf/NOTES > head/sys/i386/conf/GENERIC > head/sys/i386/conf/XBOX > head/sys/ia64/conf/GENERIC > head/sys/mips/conf/MALTA > head/sys/mips/conf/MALTA64 > head/sys/mips/conf/OCTEON1 > head/sys/mips/conf/std.SWARM > head/sys/mips/malta/std.malta > head/sys/pc98/conf/GENERIC > head/sys/powerpc/conf/GENERIC > head/sys/powerpc/conf/GENERIC64 > head/sys/powerpc/conf/MPC85XX > head/sys/sparc64/conf/GENERIC > head/sys/sun4v/conf/GENERIC -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: r220984 - head/sys/geom/eli
Author: pjd
Date: Sun Apr 24 10:41:13 2011
New Revision: 220984
URL: http://svn.freebsd.org/changeset/base/220984
Log:
One key is expected from providers smaller than or equal to (2^20)*sectorsize
bytes. Remove bogus assertion and while here remove another too obvious
assertion.
Reported by: Fabian Keil
MFC after:2 weeks
Modified:
head/sys/geom/eli/g_eli_key_cache.c
Modified: head/sys/geom/eli/g_eli_key_cache.c
==
--- head/sys/geom/eli/g_eli_key_cache.c Sun Apr 24 09:23:08 2011
(r220983)
+++ head/sys/geom/eli/g_eli_key_cache.c Sun Apr 24 10:41:13 2011
(r220984)
@@ -263,12 +263,6 @@ g_eli_key_hold(struct g_eli_softc *sc, o
if ((sc->sc_flags & G_ELI_FLAG_SINGLE_KEY) != 0)
return (sc->sc_ekey);
- KASSERT(sc->sc_ekeys_total > 1, ("%s: sc_ekeys_total=%ju", __func__,
- (uintmax_t)sc->sc_ekeys_total));
- KASSERT((sc->sc_flags & G_ELI_FLAG_SINGLE_KEY) == 0,
- ("%s: SINGLE_KEY flag set, but sc_ekeys_total=%ju", __func__,
- (uintmax_t)sc->sc_ekeys_total));
-
/* We switch key every 2^G_ELI_KEY_SHIFT blocks. */
keyno = (offset >> G_ELI_KEY_SHIFT) / blocksize;
___
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: r220983 - head
On Sun, 24 Apr 2011, Alexander Best wrote:
On Sun Apr 24 11, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 09:23:08 2011
New Revision: 220983
URL: http://svn.freebsd.org/changeset/base/220983
Log:
Explicitly note that device numbers are starting from zero.
Modified:
head/UPDATING
Modified: head/UPDATING
==
--- head/UPDATING Sun Apr 24 08:58:58 2011(r220982)
+++ head/UPDATING Sun Apr 24 09:23:08 2011(r220983)
@@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
removed and replaced by respective CAM drivers. If you are using
ATA device names in /etc/fstab or other places, make sure to update
them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
- where 'Y's are the sequential numbers for each type in order of
- detection, unless configured otherwise with tunables, see cam(4)).
+ where 'Y's are the sequential numbers starting from zero for each type
+ in order of detection, unless configured otherwise with tunables,
+ see cam(4)).
maybe an extra sentence mentioning the fact that {geom,ufs}-labels and ufsids
are preferred over device nodes nowadays would be a good idea?
cheers.
alex
For those of us using a ZFS root pool built out of /dev/gpt/ devices, will
these automagically pick up the new names?
Dan
___
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: r220985 - in head/sys/ufs: ffs ufs
Author: kib
Date: Sun Apr 24 10:47:56 2011
New Revision: 220985
URL: http://svn.freebsd.org/changeset/base/220985
Log:
VFS sometimes is unable to inactivate a vnode when vnode use count
goes to zero. E.g., the vnode might be only shared-locked at the time of
vput() call. Such vnodes are kept in the hash, so they can be found later.
If ffs_valloc() allocated an inode that has its vnode cached in hash, and
still owing the inactivation, then vget() call from ffs_valloc() clears
VI_OWEINACT, and then the vnode is reused for the newly allocated inode.
The problem is, the vnode is not reclaimed before it is put to the new
use. ffs_valloc() recycles vnode vm object, but this is not enough.
In particular, at least v_vflag should be cleared, and several bits of
UFS state need to be removed.
It is very inconvenient to call vgone() at this point. Instead, move
some parts of ufs_reclaim() into helper function ufs_prepare_reclaim(),
and call the helper from VOP_RECLAIM and ffs_valloc().
Reviewed by: mckusick
Tested by:pho
MFC after:3 weeks
Modified:
head/sys/ufs/ffs/ffs_alloc.c
head/sys/ufs/ufs/ufs_extern.h
head/sys/ufs/ufs/ufs_inode.c
Modified: head/sys/ufs/ffs/ffs_alloc.c
==
--- head/sys/ufs/ffs/ffs_alloc.cSun Apr 24 10:41:13 2011
(r220984)
+++ head/sys/ufs/ffs/ffs_alloc.cSun Apr 24 10:47:56 2011
(r220985)
@@ -1012,8 +1012,9 @@ dup_alloc:
ip->i_din2->di_birthtime = ts.tv_sec;
ip->i_din2->di_birthnsec = ts.tv_nsec;
}
+ ufs_prepare_reclaim(*vpp);
ip->i_flag = 0;
- vnode_destroy_vobject(*vpp);
+ (*vpp)->v_vflag = 0;
(*vpp)->v_type = VNON;
if (fs->fs_magic == FS_UFS2_MAGIC)
(*vpp)->v_op = &ffs_vnodeops2;
Modified: head/sys/ufs/ufs/ufs_extern.h
==
--- head/sys/ufs/ufs/ufs_extern.h Sun Apr 24 10:41:13 2011
(r220984)
+++ head/sys/ufs/ufs/ufs_extern.h Sun Apr 24 10:47:56 2011
(r220985)
@@ -76,6 +76,7 @@ intufs_inactive(struct vop_inactive_ar
int ufs_init(struct vfsconf *);
voidufs_itimes(struct vnode *vp);
int ufs_lookup(struct vop_cachedlookup_args *);
+voidufs_prepare_reclaim(struct vnode *vp);
int ufs_readdir(struct vop_readdir_args *);
int ufs_reclaim(struct vop_reclaim_args *);
voidffs_snapgone(struct inode *);
Modified: head/sys/ufs/ufs/ufs_inode.c
==
--- head/sys/ufs/ufs/ufs_inode.cSun Apr 24 10:41:13 2011
(r220984)
+++ head/sys/ufs/ufs/ufs_inode.cSun Apr 24 10:47:56 2011
(r220985)
@@ -172,6 +172,31 @@ out:
return (error);
}
+void
+ufs_prepare_reclaim(struct vnode *vp)
+{
+ struct inode *ip;
+#ifdef QUOTA
+ int i;
+#endif
+
+ ip = VTOI(vp);
+
+ vnode_destroy_vobject(vp);
+#ifdef QUOTA
+ for (i = 0; i < MAXQUOTAS; i++) {
+ if (ip->i_dquot[i] != NODQUOT) {
+ dqrele(vp, ip->i_dquot[i]);
+ ip->i_dquot[i] = NODQUOT;
+ }
+ }
+#endif
+#ifdef UFS_DIRHASH
+ if (ip->i_dirhash != NULL)
+ ufsdirhash_free(ip);
+#endif
+}
+
/*
* Reclaim an inode so that it can be used for other purposes.
*/
@@ -185,14 +210,9 @@ ufs_reclaim(ap)
struct vnode *vp = ap->a_vp;
struct inode *ip = VTOI(vp);
struct ufsmount *ump = ip->i_ump;
-#ifdef QUOTA
- int i;
-#endif
- /*
-* Destroy the vm object and flush associated pages.
-*/
- vnode_destroy_vobject(vp);
+ ufs_prepare_reclaim(vp);
+
if (ip->i_flag & IN_LAZYMOD)
ip->i_flag |= IN_MODIFIED;
UFS_UPDATE(vp, 0);
@@ -200,21 +220,7 @@ ufs_reclaim(ap)
* Remove the inode from its hash chain.
*/
vfs_hash_remove(vp);
- /*
-* Purge old data structures associated with the inode.
-*/
-#ifdef QUOTA
- for (i = 0; i < MAXQUOTAS; i++) {
- if (ip->i_dquot[i] != NODQUOT) {
- dqrele(vp, ip->i_dquot[i]);
- ip->i_dquot[i] = NODQUOT;
- }
- }
-#endif
-#ifdef UFS_DIRHASH
- if (ip->i_dirhash != NULL)
- ufsdirhash_free(ip);
-#endif
+
/*
* Lock the clearing of v_data so ffs_lock() can inspect it
* prior to obtaining the lock.
___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, 24 Apr 2011, Alexander Motin wrote: Author: mav Date: Sun Apr 24 08:58:58 2011 New Revision: 220982 URL: http://svn.freebsd.org/changeset/base/220982 Log: Switch the GENERIC kernels for all architectures to the new CAM-based ATA stack. It means that all legacy ATA drivers are disabled and replaced by respective CAM drivers. If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential numbers for each type in order of detection, unless configured otherwise with tunables, see cam(4)). ataraid(4) functionality is now supported by the RAID GEOM class. To use it you can load geom_raid kernel module and use graid(8) tool for management. Instead of /dev/arX device names, use /dev/raid/rX. I'm very pleased to see a continued movement towards the new ATA code; it offers clear benefits to all of our users, and is definitely something we want done for 9.0. Could you say more about the migration strategy for users? I recall that when you proposed throwing this switch, several strategies were discussed (likely in combination to handle both the immediate upgrade stumble issue and a longer-term migration): (1) Teach new ata parts to replicate the old naming convention in 99.9% of cases. Or some suppport module that creates the required symlinks if loaded (and we load it by default in 9.0, phasing it out later with appropriate boot-time warnings for 6-12 months). Obviously, this would be best-effort, but if it takes us from a 40% upgrade failure to a 1% upgrade failure, that's a big deal. (2) Over time, provide a migration to fstab naming storage targets by volume ID / name / serial number, rather than by hardware path. A good long-term strategy but one that requires changes to the installer, upgrade path, etc. (3) Teach freebsd-update/installer/etc to recognise *before* a new kernel is installed whether the current configuration will require hand-holding. (4) Thinking pretty hard about the roll-back path to avoid stumbles when there's a problem following a kernel update. In the past, linking kernel feature updates to /etc or userspace updates has caused significant issues for our users, who reasonably expect to follow our normal "install the kernel, reboot, let it sit for a week" path. What is your plan for implementing some combination of these (or did I miss the commits that brought them in already)? In the past, we've seen upgrade path problems dislodge users, and since then, we've grown an increased assumption of ease-of-upgrade that can be managed automatically by tools like freebsd-update. Breaking the automated upgrade (and roll-back) path would be extremely problematic. Robert ___ 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: r220983 - head
On Sun, 24 Apr 2011, Alexander Best wrote:
==
--- head/UPDATING Sun Apr 24 08:58:58 2011(r220982)
+++ head/UPDATING Sun Apr 24 09:23:08 2011(r220983)
@@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
removed and replaced by respective CAM drivers. If you are using
ATA device names in /etc/fstab or other places, make sure to update
them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
- where 'Y's are the sequential numbers for each type in order of
- detection, unless configured otherwise with tunables, see cam(4)).
+ where 'Y's are the sequential numbers starting from zero for each type
+ in order of detection, unless configured otherwise with tunables,
+ see cam(4)).
maybe an extra sentence mentioning the fact that {geom,ufs}-labels and
ufsids are preferred over device nodes nowadays would be a good idea?
If this is true, that's what our installer needs to do. Does our installer do
that?
(In general, a reasonable definition of "preferred" is "what the installer
does" -- if that's not the case, it's a serious bug.)
Robert
___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24.04.2011 13:20, Bjoern A. Zeeb wrote: On Apr 24, 2011, at 8:58 AM, Alexander Motin wrote: Author: mav Date: Sun Apr 24 08:58:58 2011 New Revision: 220982 URL: http://svn.freebsd.org/changeset/base/220982 Log: Switch the GENERIC kernels for all architectures to the new CAM-based ATA stack. It means that all legacy ATA drivers are disabled and replaced by respective CAM drivers. If you are using ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential numbers for each type in order of detection, unless configured otherwise with tunables, see cam(4)). Are you going to address that on updating magic will make it work within the next 2-4 weeks? s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should fit most. In what place should I put that magic? If you will not then thanks for screwing 50% of our users and please back this out again. Reverting is not an option. _Constructive_ propositions are welcome. -- Alexander Motin ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, 24 Apr 2011, Alexander Motin wrote: Are you going to address that on updating magic will make it work within the next 2-4 weeks? s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should fit most. In what place should I put that magic? If you will not then thanks for screwing 50% of our users and please back this out again. Reverting is not an option. _Constructive_ propositions are welcome. Hi Mav: It is the policy of this project that the release engineering team has final authority over what ships in a release. It is entirely within scope to revert this change for 9.0 if issues with the upgrade path are not addressed. My hope also that this path can be entirely avoided through a rapid addressing of upgrade path issues that have been known (and discussed on the mailing lists extensively) since you posted about the work on the public mailing lists. I agree with Bjoern that it is critical to address these issues in a timely manner -- our users depend on reliable and easy upgrades, and it seems (on face value) that significant work remains to be done to make that possible. Our release is increasingly close, and it's important we keep the tree as stable as possible so that merges of other straggling features can go uneventfully. Robert ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, 24 Apr 2011, Robert Watson wrote: I agree with Bjoern that it is critical to address these issues in a timely manner -- our users depend on reliable and easy upgrades, and it seems (on face value) that significant work remains to be done to make that possible. Our release is increasingly close, and it's important we keep the tree as stable as possible so that merges of other straggling features can go uneventfully. Just to follow up on the point: it's very important that the new ATA driver see as much testing exposure as possible -- that's one reason why paying close attention to the upgrade path. If we knock users off 9-CURRENT due to upgrade problems, then we'll reduce testing for this feature just as much as any others. This is a good reason to resolve the problems as quickly as possible! Robert ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24.04.2011 14:00, Robert Watson wrote: On Sun, 24 Apr 2011, Alexander Motin wrote: Are you going to address that on updating magic will make it work within the next 2-4 weeks? s/ad[0-9]+/ada0/ should fit 90%. A bit more sophisticated script should fit most. In what place should I put that magic? If you will not then thanks for screwing 50% of our users and please back this out again. Reverting is not an option. _Constructive_ propositions are welcome. It is the policy of this project that the release engineering team has final authority over what ships in a release. It is entirely within scope to revert this change for 9.0 if issues with the upgrade path are not addressed. My hope also that this path can be entirely avoided through a rapid addressing of upgrade path issues that have been known (and discussed on the mailing lists extensively) since you posted about the work on the public mailing lists. I agree with Bjoern that it is critical to address these issues in a timely manner -- our users depend on reliable and easy upgrades, and it seems (on face value) that significant work remains to be done to make that possible. Our release is increasingly close, and it's important we keep the tree as stable as possible so that merges of other straggling features can go uneventfully. I am asking for excuse if my tone was overly strict. It was not my real intention to offend anybody. May be inside I am indeed overreacting a bit on proposition to revert with no alternative things that I have put my heart into, which are broadly accepted by users, which I announced on the list few days ago and got no objections. I am sorry for that. I do worry about possible complications during migration process. And obviously this is not an easy question, as soon as it wasn't solved during so much time. I will gladly accept any help or real ideas people can provide. I just don't like to feel it my own problem. I am not doing it for myself. It would be nice to see some friendly support instead. Thank you. -- Alexander Motin ___ 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: r220983 - head
On 24.04.2011 13:25, Dan Mack wrote:
On Sun, 24 Apr 2011, Alexander Best wrote:
On Sun Apr 24 11, Alexander Motin wrote:
Author: mav
Date: Sun Apr 24 09:23:08 2011
New Revision: 220983
URL: http://svn.freebsd.org/changeset/base/220983
Log:
Explicitly note that device numbers are starting from zero.
Modified:
head/UPDATING
Modified: head/UPDATING
==
--- head/UPDATING Sun Apr 24 08:58:58 2011 (r220982)
+++ head/UPDATING Sun Apr 24 09:23:08 2011 (r220983)
@@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
removed and replaced by respective CAM drivers. If you are using
ATA device names in /etc/fstab or other places, make sure to update
them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
- where 'Y's are the sequential numbers for each type in order of
- detection, unless configured otherwise with tunables, see cam(4)).
+ where 'Y's are the sequential numbers starting from zero for each type
+ in order of detection, unless configured otherwise with tunables,
+ see cam(4)).
maybe an extra sentence mentioning the fact that {geom,ufs}-labels and
ufsids
are preferred over device nodes nowadays would be a good idea?
For those of us using a ZFS root pool built out of /dev/gpt/ devices,
will these automagically pick up the new names?
You should not notice transition. GPT labels should stay as they were.
--
Alexander Motin
___
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: r220983 - head
On Sun, Apr 24, 2011 at 05:25:00AM -0500, Dan Mack wrote: > For those of us using a ZFS root pool built out of /dev/gpt/ > devices, will these automagically pick up the new names? Even if you use adX devices in your ZFS pool and they will suddenly change to adaY, ZFS should detect this properly and no manual intervention should be needed. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpcLBAvSPesv.pgp Description: PGP signature
svn commit: r220987 - head/sys/sys
Author: kib Date: Sun Apr 24 13:22:14 2011 New Revision: 220987 URL: http://svn.freebsd.org/changeset/base/220987 Log: Fix typo. MFC after:3 days Modified: head/sys/sys/systm.h Modified: head/sys/sys/systm.h == --- head/sys/sys/systm.hSun Apr 24 11:01:42 2011(r220986) +++ head/sys/sys/systm.hSun Apr 24 13:22:14 2011(r220987) @@ -149,7 +149,7 @@ int nullop(void); inteopnotsupp(void); intureadc(int, struct uio *); void hashdestroy(void *, struct malloc_type *, u_long); -void *hashinit(int count, struct malloc_type *type, u_long *hashmark); +void *hashinit(int count, struct malloc_type *type, u_long *hashmask); void *hashinit_flags(int count, struct malloc_type *type, u_long *hashmask, int flags); #defineHASH_NOWAIT 0x0001 ___ 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: r220983 - head
On 04/24/11 05:49, Robert Watson wrote:
On Sun, 24 Apr 2011, Alexander Best wrote:
==
--- head/UPDATING Sun Apr 24 08:58:58 2011 (r220982)
+++ head/UPDATING Sun Apr 24 09:23:08 2011 (r220983)
@@ -28,8 +28,9 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 9.
removed and replaced by respective CAM drivers. If you are using
ATA device names in /etc/fstab or other places, make sure to update
them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
- where 'Y's are the sequential numbers for each type in order of
- detection, unless configured otherwise with tunables, see cam(4)).
+ where 'Y's are the sequential numbers starting from zero for each type
+ in order of detection, unless configured otherwise with tunables,
+ see cam(4)).
maybe an extra sentence mentioning the fact that {geom,ufs}-labels and
ufsids are preferred over device nodes nowadays would be a good idea?
If this is true, that's what our installer needs to do. Does our
installer do that?
(In general, a reasonable definition of "preferred" is "what the
installer does" -- if that's not the case, it's a serious bug.)
Our installer does not do that. I outlined the reasons in another
earlier email, but the summary is that labels seem to be somewhat
fragile. Gpart supports a partition-generic labeling interface for three
schemes: PC98, GPT, and APM. The installer now supports setting labels
on all of these. The appearance of labeled geom providers happens in a
different module, glabel, which relies on a totally parallel parse of
the partition map. As a result, labeled partitions appearing in /dev
works only on GPT volumes, and even then, due to endianness bugs, only
on little-endian platforms. Glabel is also not guaranteed available by
gpart, and I'm a little dubious that reparses happen at the correct time
with 100% reliability. The other, more minor, difficulty, is that it is
somewhat difficult to get the labeled provider name from the gpart
provider (you have to try to cross-correlate names, and there may be
many label providers to choose from for the same partition).
If gpart were modified to provide label providers itself based on its
generic labeling mechanism, and to provide the name of those providers
in its config XML, using labels by default in the installer would be
trivial and I would have it in the tree within 5 minutes of getting that
commit mail. Unfortunately, I don't have time to do the requisite gpart
modifications (which probably aren't that hard) at this time.
-Nathan
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r220988 - head/sys/dev/ath/ath_hal/ar5416
Author: adrian
Date: Sun Apr 24 14:50:29 2011
New Revision: 220988
URL: http://svn.freebsd.org/changeset/base/220988
Log:
Eliminate code duplication between AR5416/AR9160/AR9280 and AR9285.
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
Modified:
head/sys/dev/ath/ath_hal/ar5416/ar5416.h
head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416.h
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416.hSun Apr 24 13:22:14 2011
(r220987)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416.hSun Apr 24 14:50:29 2011
(r220988)
@@ -268,6 +268,8 @@ extern void ar5416WritePdadcValues(struc
extern HAL_BOOL ar5416SetPowerCalTable(struct ath_hal *ah,
struct ar5416eeprom *pEepData, const struct ieee80211_channel *chan,
int16_t *pTxPowerIndexOffset);
+extern void ar5416WriteTxPowerRateRegisters(struct ath_hal *ah,
+ const struct ieee80211_channel *chan, const int16_t ratesArray[]);
extern HAL_BOOL ar5416StopTxDma(struct ath_hal *ah, u_int q);
extern HAL_BOOL ar5416SetupTxDesc(struct ath_hal *ah, struct ath_desc *ds,
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c Sun Apr 24 13:22:14
2011(r220987)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c Sun Apr 24 14:50:29
2011(r220988)
@@ -795,6 +795,99 @@ ar5416GetChipPowerLimits(struct ath_hal
}
/**
+ * ar5416WriteTxPowerRateRegisters
+ *
+ * Write the TX power rate registers from the raw values given
+ * in ratesArray[].
+ *
+ * The CCK and HT40 rate registers are only written if needed.
+ * HT20 and 11g/11a OFDM rate registers are always written.
+ *
+ * The values written are raw values which should be written
+ * to the registers - so it's up to the caller to pre-adjust
+ * them (eg CCK power offset value, or Merlin TX power offset,
+ * etc.)
+ */
+void
+ar5416WriteTxPowerRateRegisters(struct ath_hal *ah,
+const struct ieee80211_channel *chan, const int16_t ratesArray[])
+{
+#define POW_SM(_r, _s) (((_r) & 0x3f) << (_s))
+
+/* Write the OFDM power per rate set */
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE1,
+POW_SM(ratesArray[rate18mb], 24)
+ | POW_SM(ratesArray[rate12mb], 16)
+ | POW_SM(ratesArray[rate9mb], 8)
+ | POW_SM(ratesArray[rate6mb], 0)
+);
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE2,
+POW_SM(ratesArray[rate54mb], 24)
+ | POW_SM(ratesArray[rate48mb], 16)
+ | POW_SM(ratesArray[rate36mb], 8)
+ | POW_SM(ratesArray[rate24mb], 0)
+);
+
+if (IEEE80211_IS_CHAN_2GHZ(chan)) {
+/* Write the CCK power per rate set */
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE3,
+POW_SM(ratesArray[rate2s], 24)
+ | POW_SM(ratesArray[rate2l], 16)
+ | POW_SM(ratesArray[rateXr], 8) /* XR target power */
+ | POW_SM(ratesArray[rate1l], 0)
+);
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE4,
+POW_SM(ratesArray[rate11s], 24)
+ | POW_SM(ratesArray[rate11l], 16)
+ | POW_SM(ratesArray[rate5_5s], 8)
+ | POW_SM(ratesArray[rate5_5l], 0)
+);
+HALDEBUG(ah, HAL_DEBUG_RESET,
+ "%s AR_PHY_POWER_TX_RATE3=0x%x AR_PHY_POWER_TX_RATE4=0x%x\n",
+ __func__, OS_REG_READ(ah,AR_PHY_POWER_TX_RATE3),
+ OS_REG_READ(ah,AR_PHY_POWER_TX_RATE4));
+}
+
+/* Write the HT20 power per rate set */
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE5,
+POW_SM(ratesArray[rateHt20_3], 24)
+ | POW_SM(ratesArray[rateHt20_2], 16)
+ | POW_SM(ratesArray[rateHt20_1], 8)
+ | POW_SM(ratesArray[rateHt20_0], 0)
+);
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE6,
+POW_SM(ratesArray[rateHt20_7], 24)
+ | POW_SM(ratesArray[rateHt20_6], 16)
+ | POW_SM(ratesArray[rateHt20_5], 8)
+ | POW_SM(ratesArray[rateHt20_4], 0)
+);
+
+if (IEEE80211_IS_CHAN_HT40(chan)) {
+/* Write the HT40 power per rate set */
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE7,
+POW_SM(ratesArray[rateHt40_3], 24)
+ | POW_SM(ratesArray[rateHt40_2], 16)
+ | POW_SM(ratesArray[rateHt40_1], 8)
+ | POW_SM(ratesArray[rateHt40_0], 0)
+);
+OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE8,
+POW_SM(ratesArray[rateHt40_7], 24)
+ | POW_SM(ratesArray[rateHt40_6], 16)
+ | POW_SM(ratesArray[rateHt40_5], 8)
+ | POW_SM(ratesArray[rateHt40_4], 0)
+);
+/* Write the Dup/Ext 40 power per rate set */
+O
Re: svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
Robert Watson wrote: > I'm very pleased to see a continued movement towards the new ATA code; > it offers clear benefits to all of our users, and is definitely > something we want done for 9.0. > > Could you say more about the migration strategy for users? I recall > that when you proposed throwing this switch, several strategies were > discussed (likely in combination to handle both the immediate upgrade > stumble issue and a longer-term migration): > > (1) Teach new ata parts to replicate the old naming convention in 99.9% of > cases. Or some suppport module that creates the required symlinks if > loaded (and we load it by default in 9.0, phasing it out later with > appropriate boot-time warnings for 6-12 months). Obviously, this > would be > best-effort, but if it takes us from a 40% upgrade failure to a 1% > upgrade > failure, that's a big deal. > > (2) Over time, provide a migration to fstab naming storage targets by > volume > ID / name / serial number, rather than by hardware path. A good > long-term > strategy but one that requires changes to the installer, upgrade path, > etc. > > (3) Teach freebsd-update/installer/etc to recognise *before* a new > kernel is > installed whether the current configuration will require hand-holding. > > (4) Thinking pretty hard about the roll-back path to avoid stumbles when > there's a problem following a kernel update. In the past, linking > kernel > feature updates to /etc or userspace updates has caused significant > issues > for our users, who reasonably expect to follow our normal "install the > kernel, reboot, let it sit for a week" path. > > What is your plan for implementing some combination of these (or did I > miss the commits that brought them in already)? In the past, we've seen > upgrade path problems dislodge users, and since then, we've grown an > increased assumption of ease-of-upgrade that can be managed > automatically by tools like freebsd-update. Breaking the automated > upgrade (and roll-back) path would be extremely problematic. I was hoping to not expand migration process onto another decade. Many users already migrated to the new infrastructure on both STABLE and CURRENT and AFAIK editing fstab was not a major problem for them. Since the last big discussion of this question about year ago we got graid implemented and some other things required to keep previous functionality, that could hold users from migration. Making this commit now I was prepared to spend few weeks on active bug fixing to minimize number of further rollback cases. So at this moment device names change is the last major problem I know. Yes, it was the same year ago, but there was same discussion as the last week about using labels in fstab, that equally ended with nothing. :( What's about creating some kind of symlinks, it could be nice if it worked, but I don't see the way to do it on disk(9) or GEOM layers without breaking device's access counters and as result further random problems. Looking now on these "do or revert" demands to keep old device naming, I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX" names. I see it in form of some loader tunable, disabled by default (as it should be on newly installed systems), but that could be set prior to upgrade if user doesn't want to bother with device names at that moment. It should partially hide problem for some time. Will such solution be acceptable? -- Alexander Motin ___ 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: r220989 - head/sys/dev/ath/ath_hal/ar9002
Author: adrian
Date: Sun Apr 24 15:48:07 2011
New Revision: 220989
URL: http://svn.freebsd.org/changeset/base/220989
Log:
Use the refactored ar5416WriteTxPowerRateRegisters() call in the ar9285 code.
Modified:
head/sys/dev/ath/ath_hal/ar9002/ar9285_reset.c
Modified: head/sys/dev/ath/ath_hal/ar9002/ar9285_reset.c
==
--- head/sys/dev/ath/ath_hal/ar9002/ar9285_reset.c Sun Apr 24 14:50:29
2011(r220988)
+++ head/sys/dev/ath/ath_hal/ar9002/ar9285_reset.c Sun Apr 24 15:48:07
2011(r220989)
@@ -148,76 +148,27 @@ ar9285SetTransmitPower(struct ath_hal *a
ar5416PrintPowerPerRate(ah, ratesArray);
#endif
-/* Write the OFDM power per rate set */
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE1,
-POW_SM(ratesArray[rate18mb], 24)
- | POW_SM(ratesArray[rate12mb], 16)
- | POW_SM(ratesArray[rate9mb], 8)
- | POW_SM(ratesArray[rate6mb], 0)
-);
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE2,
-POW_SM(ratesArray[rate54mb], 24)
- | POW_SM(ratesArray[rate48mb], 16)
- | POW_SM(ratesArray[rate36mb], 8)
- | POW_SM(ratesArray[rate24mb], 0)
-);
-
-/* Write the CCK power per rate set */
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE3,
-POW_SM(ratesArray[rate2s], 24)
- | POW_SM(ratesArray[rate2l], 16)
- | POW_SM(ratesArray[rateXr], 8) /* XR target power */
- | POW_SM(ratesArray[rate1l], 0)
-);
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE4,
-POW_SM(ratesArray[rate11s], 24)
- | POW_SM(ratesArray[rate11l], 16)
- | POW_SM(ratesArray[rate5_5s], 8)
- | POW_SM(ratesArray[rate5_5l], 0)
-);
-HALDEBUG(ah, HAL_DEBUG_RESET,
- "%s AR_PHY_POWER_TX_RATE3=0x%x AR_PHY_POWER_TX_RATE4=0x%x\n",
- __func__, OS_REG_READ(ah,AR_PHY_POWER_TX_RATE3),
- OS_REG_READ(ah,AR_PHY_POWER_TX_RATE4));
-
-/* Write the HT20 power per rate set */
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE5,
-POW_SM(ratesArray[rateHt20_3], 24)
- | POW_SM(ratesArray[rateHt20_2], 16)
- | POW_SM(ratesArray[rateHt20_1], 8)
- | POW_SM(ratesArray[rateHt20_0], 0)
-);
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE6,
-POW_SM(ratesArray[rateHt20_7], 24)
- | POW_SM(ratesArray[rateHt20_6], 16)
- | POW_SM(ratesArray[rateHt20_5], 8)
- | POW_SM(ratesArray[rateHt20_4], 0)
-);
-
+/*
+ * Adjust the HT40 power to meet the correct target TX power
+ * for 40MHz mode, based on TX power curves that are established
+ * for 20MHz mode.
+ *
+ * XXX handle overflow/too high power level?
+ */
if (IEEE80211_IS_CHAN_HT40(chan)) {
-/* Write the HT40 power per rate set */
- /* Correct PAR difference between HT40 and HT20/LEGACY */
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE7,
-POW_SM(ratesArray[rateHt40_3] + ht40PowerIncForPdadc, 24)
- | POW_SM(ratesArray[rateHt40_2] + ht40PowerIncForPdadc, 16)
- | POW_SM(ratesArray[rateHt40_1] + ht40PowerIncForPdadc, 8)
- | POW_SM(ratesArray[rateHt40_0] + ht40PowerIncForPdadc, 0)
-);
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE8,
-POW_SM(ratesArray[rateHt40_7] + ht40PowerIncForPdadc, 24)
- | POW_SM(ratesArray[rateHt40_6] + ht40PowerIncForPdadc, 16)
- | POW_SM(ratesArray[rateHt40_5] + ht40PowerIncForPdadc, 8)
- | POW_SM(ratesArray[rateHt40_4] + ht40PowerIncForPdadc, 0)
-);
-/* Write the Dup/Ext 40 power per rate set */
-OS_REG_WRITE(ah, AR_PHY_POWER_TX_RATE9,
-POW_SM(ratesArray[rateExtOfdm], 24)
- | POW_SM(ratesArray[rateExtCck], 16)
- | POW_SM(ratesArray[rateDupOfdm], 8)
- | POW_SM(ratesArray[rateDupCck], 0)
-);
+ratesArray[rateHt40_0] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_1] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_2] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_3] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_4] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_5] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_6] += ht40PowerIncForPdadc;
+ratesArray[rateHt40_7] += ht40PowerIncForPdadc;
}
+/* Write the TX power rate registers */
+ar5416WriteTxPowerRateRegisters(ah, chan, ratesArray);
+
return AH_TRUE;
#undef POW_SM
#undef N
___
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: r220990 - head/sys/dev/ath/ath_hal/ar5416
Author: adrian
Date: Sun Apr 24 15:53:57 2011
New Revision: 220990
URL: http://svn.freebsd.org/changeset/base/220990
Log:
Break out the PLL setup into an overridable method.
The only method right now is ar5416InitPLL() which handles multiple
chipsets; this can now be overridden by newer chipset HAL code.
Modified:
head/sys/dev/ath/ath_hal/ar5416/ar5416.h
head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c
head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416.h
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416.hSun Apr 24 15:48:07 2011
(r220989)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416.hSun Apr 24 15:53:57 2011
(r220990)
@@ -103,6 +103,10 @@ struct ath_hal_5416 {
const struct ieee80211_channel *chan,
int16_t *pTxPowerIndexOffset);
+ /* baseband operations */
+ void(*ah_initPLL) (struct ath_hal *ah,
+ const struct ieee80211_channel *chan);
+
u_int ah_globaltxtimeout; /* global tx timeout */
u_int ah_gpioMask;
int ah_hangs; /* h/w hangs state */
@@ -248,6 +252,8 @@ extern void ar5416EepromSetAddac(struct
const struct ieee80211_channel *chan);
extern uint16_t ar5416GetMaxEdgePower(uint16_t freq,
CAL_CTL_EDGES *pRdEdgesPower, HAL_BOOL is2GHz);
+extern void ar5416InitPLL(struct ath_hal *ah,
+ const struct ieee80211_channel *chan);
/* TX power setup related routines in ar5416_reset.c */
extern void ar5416GetGainBoundariesAndPdadcs(struct ath_hal *ah,
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c Sun Apr 24 15:48:07
2011(r220989)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416_attach.c Sun Apr 24 15:53:57
2011(r220990)
@@ -181,6 +181,9 @@ ar5416InitState(struct ath_hal_5416 *ahp
AH5416(ah)->ah_writeIni = ar5416WriteIni;
AH5416(ah)->ah_spurMitigate = ar5416SpurMitigate;
+ /* Internal baseband ops */
+ AH5416(ah)->ah_initPLL = ar5416InitPLL;
+
/* Internal calibration ops */
AH5416(ah)->ah_cal_initcal = ar5416InitCalHardware;
Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c
==
--- head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c Sun Apr 24 15:48:07
2011(r220989)
+++ head/sys/dev/ath/ath_hal/ar5416/ar5416_reset.c Sun Apr 24 15:53:57
2011(r220990)
@@ -54,7 +54,6 @@ static void ar5416SetDeltaSlope(struct a
static HAL_BOOL ar5416SetResetPowerOn(struct ath_hal *ah);
static HAL_BOOL ar5416SetReset(struct ath_hal *ah, int type);
-static void ar5416InitPLL(struct ath_hal *ah, const struct ieee80211_channel
*chan);
static HAL_BOOL ar5416SetPowerPerRateTable(struct ath_hal *ah,
struct ar5416eeprom *pEepData,
const struct ieee80211_channel *chan, int16_t *ratesArray,
@@ -513,7 +512,7 @@ ar5416InitBB(struct ath_hal *ah, const s
/* Turn on PLL on 5416 */
HALDEBUG(ah, HAL_DEBUG_RESET, "%s %s channel\n",
__func__, IEEE80211_IS_CHAN_5GHZ(chan) ? "5GHz" : "2GHz");
- ar5416InitPLL(ah, chan);
+ AH5416(ah)->ah_initPLL(ah, chan);
/* Activate the PHY (includes baseband activate and synthesizer on) */
OS_REG_WRITE(ah, AR_PHY_ACTIVE, AR_PHY_ACTIVE_EN);
@@ -655,7 +654,7 @@ ar5416ChipReset(struct ath_hal *ah, cons
if (!ar5416SetPowerMode(ah, HAL_PM_AWAKE, AH_TRUE))
return AH_FALSE;
- ar5416InitPLL(ah, chan);
+ AH5416(ah)->ah_initPLL(ah, chan);
/*
* Perform warm reset before the mode/PLL/turbo registers
@@ -1221,7 +1220,7 @@ ar5416SetReset(struct ath_hal *ah, int t
OS_REG_WRITE(ah, AR_CFG, INIT_CONFIG_STATUS);
}
-ar5416InitPLL(ah, AH_NULL);
+AH5416(ah)->ah_initPLL(ah, AH_NULL);
return AH_TRUE;
}
@@ -1278,7 +1277,7 @@ ar5416UpdateChainMasks(struct ath_hal *a
#defineIS_5GHZ_FAST_CLOCK_EN(ah, chan) AH_FALSE
#endif
-static void
+void
ar5416InitPLL(struct ath_hal *ah, const struct ieee80211_channel *chan)
{
uint32_t pll;
___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote: > What's about creating some kind of symlinks, it could be nice if it > worked, but I don't see the way to do it on disk(9) or GEOM layers > without breaking device's access counters and as result further random > problems. Speaking on Alexander's side, I'd want to mention that many of our users had been bitten by obscure adX naming during past years (largely due to ATA_STATIC_ID option which was probably useful back in times when there typically was only one IDE controller present in system, but leads to all sorts of weird ad4-6-8's in recent years) had already migrated to glabel or GPT labels, to avoid precisely the issues we're talking about here. ./danfe ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r220983 - head
On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote: > ATA device names in /etc/fstab or other places, make sure to update > them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, > - where 'Y's are the sequential numbers for each type in order of > - detection, unless configured otherwise with tunables, see cam(4)). > + where 'Y's are the sequential numbers starting from zero for each type > + in order of detection, unless configured otherwise with tunables, > + see cam(4)). Is there any way to guess resulting 'Y' numbers _before_ booting new kernel? I have remote machine with console access almost impossible (very hard for me). It seems something like vfs.root.mountfrom="ufs:/dev/ada0s1a ufs:/dev/ada1s1a ..." (up to max channels) helps to find root, but what about other mounted disks? -- http://ache.vniz.net/ ___ 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: r220983 - head
On 24.04.2011 19:19, Andrey Chernov wrote: On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote: ATA device names in /etc/fstab or other places, make sure to update them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY, - where 'Y's are the sequential numbers for each type in order of - detection, unless configured otherwise with tunables, see cam(4)). + where 'Y's are the sequential numbers starting from zero for each type + in order of detection, unless configured otherwise with tunables, + see cam(4)). Is there any way to guess resulting 'Y' numbers _before_ booting new kernel? I have remote machine with console access almost impossible (very hard for me). In most cases order of adaX devices should match order of ad devices, so first adX will become ada0, second - ada1, etc. The only exception there should be devices on ATA channels in legacy/ISA emulation mode: ata0 (ad0/ad1) and ata1 (ad2/ad3). Old ATA always allocated these devices first, but new ATA will allocate them as any other in order of their channels registration. That order you can see in dmesg. -- Alexander Motin ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24 Apr 2011, at 17:32, Alexey Dokuchaev wrote: > On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote: >> What's about creating some kind of symlinks, it could be nice if it >> worked, but I don't see the way to do it on disk(9) or GEOM layers >> without breaking device's access counters and as result further random >> problems. > > Speaking on Alexander's side, I'd want to mention that many of our users > had been bitten by obscure adX naming during past years (largely due to > ATA_STATIC_ID option which was probably useful back in times when there > typically was only one IDE controller present in system, but leads to all > sorts of weird ad4-6-8's in recent years) had already migrated to glabel > or GPT labels, to avoid precisely the issues we're talking about here. Yes, the argument is not over whether the change should be made, but how we can get it done in time for 9.0-RELEASE in such a way that it minimises disruption for our users. Clearly, we need the new AHCI driver as the default in the release. But if we make upgrading (and rolling back) significantly harder, that hurts us a lot. Ideally, we would have shipped the migration parts in 8.2 so that 9.0 was a driver change event, not a device naming model change event (easing in the administrative hurdle). Robert___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24 Apr 2011, at 12:49, Alexander Motin wrote: >>> Reverting is not an option. _Constructive_ propositions are welcome. >> >> It is the policy of this project that the release engineering team has >> final authority over what ships in a release. It is entirely within >> scope to revert this change for 9.0 if issues with the upgrade path are >> not addressed. My hope also that this path can be entirely avoided >> through a rapid addressing of upgrade path issues that have been known >> (and discussed on the mailing lists extensively) since you posted about >> the work on the public mailing lists. >> >> I agree with Bjoern that it is critical to address these issues in a >> timely manner -- our users depend on reliable and easy upgrades, and it >> seems (on face value) that significant work remains to be done to make >> that possible. Our release is increasingly close, and it's important we >> keep the tree as stable as possible so that merges of other straggling >> features can go uneventfully. > > I am asking for excuse if my tone was overly strict. It was not my real > intention to offend anybody. May be inside I am indeed overreacting a bit on > proposition to revert with no alternative things that I have put my heart > into, which are broadly accepted by users, which I announced on the list few > days ago and got no objections. I am sorry for that. > > I do worry about possible complications during migration process. And > obviously this is not an easy question, as soon as it wasn't solved during so > much time. I will gladly accept any help or real ideas people can provide. I > just don't like to feel it my own problem. I am not doing it for myself. It > would be nice to see some friendly support instead. Let's be clear: Bjoern didn't say you should revert it immediately. He said that the migration path needs to be fixed in the next month (2-4 weeks). That leaves plenty of time to resolve these issues, which I think the consensus is should have been resolved before committing the switch, not after. But given that it's in the tree, let's leave it there for now to continue to improve our testing exposure, and try to get it fixed as quickly as possible. Robert___ 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: r220983 - head
On 24/04/2011, at 18:19, Andrey Chernov wrote:
> On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote:
>> ATA device names in /etc/fstab or other places, make sure to update
>> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
>> -where 'Y's are the sequential numbers for each type in order of
>> -detection, unless configured otherwise with tunables, see cam(4)).
>> +where 'Y's are the sequential numbers starting from zero for each type
>> +in order of detection, unless configured otherwise with tunables,
>> +see cam(4)).
>
> Is there any way to guess resulting 'Y' numbers _before_ booting new
> kernel? I have remote machine with console access almost impossible (very
> hard for me).
>
> It seems something like
> vfs.root.mountfrom="ufs:/dev/ada0s1a ufs:/dev/ada1s1a ..."
> (up to max channels) helps to find root, but what about other mounted
> disks?
The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are on a GPT
system) or UFS IDs (/dev/ufsid/xxx) if you can't.
gpart list will show the GPTID (rawuuid) and dumpfs will show the UFS ID.
The following shell snippet will generate the UFS ID for a given FS.
getfsid() {
line=`dumpfs 2> /dev/null $1 | head | grep superblock\ location`
if [ $? -ne 0 ]; then
return 1
fi
# dumpfs doesn't print leading 0s
eval `echo $line | sed -nEe 's/superblock location.*id.*\[ (.*) (.*)\
]/printf %0x $((0x\1 << 32 | 0x\2))/p'`
}
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On Apr 24, 2011, at 3:28 PM, Alexander Motin wrote: > I was hoping to not expand migration process onto another decade. Many > users already migrated to the new infrastructure on both STABLE and > CURRENT and AFAIK editing fstab was not a major problem for them. Do not think that based on the hundred replies on the lists in two years, that any of the hundreds of thousands of machines you haven't heard of were migrated. A LOT of people simply run on defaults we provide. > ... So at this moment device names change > is the last major problem I know. Yes, it was the same year ago, but > there was same discussion as the last week about using labels in fstab, > that equally ended with nothing. :( I am sorry if I was too direct with the "fix it the next weeks or backout" earlier today. As I had said on current@ I have migrated machines myself and am testing things where possible and it's a good thing to move to. As I had also said on current@ "we must not screw our users and need transition magic". I think a couple of others just didn't repeat what was said months ago. > What's about creating some kind of symlinks, it could be nice if it > worked, but I don't see the way to do it on disk(9) or GEOM layers > without breaking device's access counters and as result further random > problems. I had been pondering devfs "link"s myself, the problem is that from the rc framework they come too late. If you can add a simple .ko that does it programmatically on 9 that would be great. The problem is that after booting the new kernel you don't know whether people had ATA_STATIC on or not, so we'd have to go with the defaults, that were in 8.x (and an extra tunable to flip the logic maybe)? > Looking now on these "do or revert" demands to keep old device naming, > I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX" > names. I see it in form of some loader tunable, disabled by default (as > it should be on newly installed systems), but that could be set prior to > upgrade if user doesn't want to bother with device names at that moment. > It should partially hide problem for some time. It would need to be in and on by default for the lifetime of 9 as it's not in the last 8.x release (which would need it the other way round anyway. MIght it be a good idea to do that as well afterwards providing ada links on the next 8.x release?). The user could disable it after the conversion happened though with a tunable to get rid of the extra /dev/* noise. We could even check for it being on and check fstab and warn/pester the user then that he'll need to migrate (on boot from rc.d, in weekly mails, ...). If we have both information available (old from the kernel transition code) and new we could even provide a script to do it. The reason we might not want to do it automatically is that if the user will decide to boot kernel.old because the new kernel panics after 2 days, she'll be facing the new ada entries in fstab with an 8.x kernel and that would not work either. So it's a decision users need to make eventually themselves during the lifetime of 9.x when upgrading from an older release. > Will such solution be acceptable? I think any solution will be acceptable if it (mostly) works and gets the possible fallout rate (significantly) down and thanks a lot for picking it up now! Bjoern PS: And I think you'll find a lot of testers the next days/weeks on current@ when people update their kernels and forgot to read UPDATING or fail to do the conversion properly.;) -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
On 24.04.2011 21:59, Bjoern A. Zeeb wrote: What's about creating some kind of symlinks, it could be nice if it worked, but I don't see the way to do it on disk(9) or GEOM layers without breaking device's access counters and as result further random problems. I had been pondering devfs "link"s myself, the problem is that from the rc framework they come too late. If you can add a simple .ko that does it programmatically on 9 that would be great. The problem is that after booting the new kernel you don't know whether people had ATA_STATIC on or not, so we'd have to go with the defaults, that were in 8.x (and an extra tunable to flip the logic maybe)? Devfs links won't help users with hardcoded provider names in gmirror, etc -- from GEOM PoV there will be no such providers. Also to create proper mapping that module should have real-time information from CAM about ATA controller details. And looking that it will have to link in real time any derivative providers also (ad4s1a -> ada0s1a) I worry if it is possible at all. Some devfs expert needed here. Looking now on these "do or revert" demands to keep old device naming, I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX" names. I see it in form of some loader tunable, disabled by default (as it should be on newly installed systems), but that could be set prior to upgrade if user doesn't want to bother with device names at that moment. It should partially hide problem for some time. It would need to be in and on by default for the lifetime of 9 as it's not in the last 8.x release (which would need it the other way round anyway. MIght it be a good idea to do that as well afterwards providing ada links on the next 8.x release?). I wouldn't like to keep that ugly numbering on by default till the 9.x EoL even for new installations. Also remember about number of people already using new ATA, for whom requirement to disable that tunable may also be uncomfortable. The user could disable it after the conversion happened though with a tunable to get rid of the extra /dev/* noise. We could even check for it being on and check fstab and warn/pester the user then that he'll need to migrate (on boot from rc.d, in weekly mails, ...). It would be fine if it was just devfs noise, but I have some doubts about it (above). If we have both information available (old from the kernel transition code) and new we could even provide a script to do it. The reason we might not want to do it automatically is that if the user will decide to boot kernel.old because the new kernel panics after 2 days, she'll be facing the new ada entries in fstab with an 8.x kernel and that would not work either. So it's a decision users need to make eventually themselves during the lifetime of 9.x when upgrading from an older release. Reasonable. Will such solution be acceptable? I think any solution will be acceptable if it (mostly) works and gets the possible fallout rate (significantly) down and thanks a lot for picking it up now! But that solution should not include setting tunables before upgrading? Can't we teach mergemaster or whatever else to set it depending on whet disks are now present in system? PS: And I think you'll find a lot of testers the next days/weeks on current@ when people update their kernels and forgot to read UPDATING or fail to do the conversion properly.;) I can always say: "read UPDATING" (for log: I am not completely serious here. :)). -- Alexander Motin ___ 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: r220983 - head
On Sun, 24 Apr 2011, Pawel Jakub Dawidek wrote: On Sun, Apr 24, 2011 at 05:25:00AM -0500, Dan Mack wrote: For those of us using a ZFS root pool built out of /dev/gpt/ devices, will these automagically pick up the new names? Even if you use adX devices in your ZFS pool and they will suddenly change to adaY, ZFS should detect this properly and no manual intervention should be needed. Yep, confirmed. My boot zroot RAID10 pool previously built from ad4, ad6, ad8, ad10 worked without a hitch with the new enumeration scheme: borg# gpart status Name Status Components ada0p1 OK ada0 ada0p2 OK ada0 ada0p3 OK ada0 ada1p1 OK ada1 ada1p2 OK ada1 ada1p3 OK ada1 ada2p1 OK ada2 ada2p2 OK ada2 ada2p3 OK ada2 ada3p1 OK ada3 ada3p2 OK ada3 ada3p3 OK ada3 borg# zpool status pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 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: r221005 - head/sys/dev/msk
Author: glebius Date: Mon Apr 25 04:55:50 2011 New Revision: 221005 URL: http://svn.freebsd.org/changeset/base/221005 Log: When msk_detach() is called from msk_attach(), ifp may be yet not initialized. Modified: head/sys/dev/msk/if_msk.c Modified: head/sys/dev/msk/if_msk.c == --- head/sys/dev/msk/if_msk.c Mon Apr 25 04:33:42 2011(r221004) +++ head/sys/dev/msk/if_msk.c Mon Apr 25 04:55:50 2011(r221005) @@ -1964,7 +1964,8 @@ msk_detach(device_t dev) /* Can't hold locks while calling detach. */ MSK_IF_UNLOCK(sc_if); callout_drain(&sc_if->msk_tick_ch); - ether_ifdetach(ifp); + if (ifp) + ether_ifdetach(ifp); MSK_IF_LOCK(sc_if); } ___ 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: r220983 - head
On Apr 24, 2011, at 11:34 AM, Daniel O'Connor wrote:
>
> On 24/04/2011, at 18:19, Andrey Chernov wrote:
>> On Sun, Apr 24, 2011 at 09:23:08AM +, Alexander Motin wrote:
>>> ATA device names in /etc/fstab or other places, make sure to update
>>> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
>>> - where 'Y's are the sequential numbers for each type in order of
>>> - detection, unless configured otherwise with tunables, see cam(4)).
>>> + where 'Y's are the sequential numbers starting from zero for each type
>>> + in order of detection, unless configured otherwise with tunables,
>>> + see cam(4)).
>>
>> Is there any way to guess resulting 'Y' numbers _before_ booting new
>> kernel? I have remote machine with console access almost impossible (very
>> hard for me).
>>
>> It seems something like
>> vfs.root.mountfrom="ufs:/dev/ada0s1a ufs:/dev/ada1s1a ..."
>> (up to max channels) helps to find root, but what about other mounted
>> disks?
>
> The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are on a GPT
> system) or UFS IDs (/dev/ufsid/xxx) if you can't.
I've been running with ufs labels for a couple of years now, since the first
rumblings of this hit the streets. They work great no matter what the
underlying partitioning scheme. The one drawback is that if you have multiple
disks with the same labels, then the first one wins. Normally not a problem,
but when you have it, you need to ensure the right one is selected. I avoid
this problem by prefixing a hostname to the label...
> gpart list will show the GPTID (rawuuid) and dumpfs will show the UFS ID.
>
> The following shell snippet will generate the UFS ID for a given FS.
>
> getfsid() {
> line=`dumpfs 2> /dev/null $1 | head | grep superblock\ location`
> if [ $? -ne 0 ]; then
>return 1
> fi
> # dumpfs doesn't print leading 0s
> eval `echo $line | sed -nEe 's/superblock location.*id.*\[ (.*) (.*)\
> ]/printf %0x $((0x\1 << 32 | 0x\2))/p'`
> }
This is also good.
Warner___
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: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf
Now that the horse is out of the barn, the following might be a little late (unless we unpull the trigger for a month). But what if we warned that / was on a device name, and not on a 'named' device. Complain if it was on /dev/da0, but not if it was on /dev/ufs/fred-root. Users would see this warning and react. Next best thing: make installkernel check for devices on /dev/adX and refuse to install the kernel if they are (unless REALLY_THIS_IS_RIGHT is defined :). This won't help the binary upgrader, but will prevent massive footshooting in the mean time. Warner On Apr 24, 2011, at 1:41 PM, Alexander Motin wrote: > On 24.04.2011 21:59, Bjoern A. Zeeb wrote: >>> What's about creating some kind of symlinks, it could be nice if it >>> worked, but I don't see the way to do it on disk(9) or GEOM layers >>> without breaking device's access counters and as result further random >>> problems. >> >> I had been pondering devfs "link"s myself, the problem is that from the rc >> framework they come too late. If you can add a simple .ko that does it >> programmatically on 9 that would be great. The problem is that after booting >> the new kernel you don't know whether people had ATA_STATIC on or not, so >> we'd have to go with the defaults, that were in 8.x (and an extra tunable to >> flip the logic maybe)? > > Devfs links won't help users with hardcoded provider names in gmirror, etc -- > from GEOM PoV there will be no such providers. Also to create proper mapping > that module should have real-time information from CAM about ATA controller > details. And looking that it will have to link in real time any derivative > providers also (ad4s1a -> ada0s1a) I worry if it is possible at all. Some > devfs expert needed here. > >>> Looking now on these "do or revert" demands to keep old device naming, >>> I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX" >>> names. I see it in form of some loader tunable, disabled by default (as >>> it should be on newly installed systems), but that could be set prior to >>> upgrade if user doesn't want to bother with device names at that moment. >>> It should partially hide problem for some time. >> >> It would need to be in and on by default for the lifetime of 9 as it's not >> in the last 8.x release (which would need it the other way round anyway. >> MIght it be a good idea to do that as well afterwards providing ada links >> on the next 8.x release?). > > I wouldn't like to keep that ugly numbering on by default till the 9.x EoL > even for new installations. Also remember about number of people already > using new ATA, for whom requirement to disable that tunable may also be > uncomfortable. > >> The user could disable it after the conversion happened though with a tunable >> to get rid of the extra /dev/* noise. We could even check for it being on >> and check fstab and warn/pester the user then that he'll need to migrate >> (on boot from rc.d, in weekly mails, ...). > > It would be fine if it was just devfs noise, but I have some doubts about it > (above). > >> If we have both information available (old from the kernel transition code) >> and new we could even provide a script to do it. >> >> The reason we might not want to do it automatically is that if the user will >> decide to boot kernel.old because the new kernel panics after 2 days, she'll >> be facing the new ada entries in fstab with an 8.x kernel and that would not >> work either. So it's a decision users need to make eventually themselves >> during the lifetime of 9.x when upgrading from an older release. > > Reasonable. > >>> Will such solution be acceptable? >> >> I think any solution will be acceptable if it (mostly) works and gets the >> possible fallout rate (significantly) down and thanks a lot for picking it >> up now! > > But that solution should not include setting tunables before upgrading? Can't > we teach mergemaster or whatever else to set it depending on whet disks are > now present in system? > >> PS: And I think you'll find a lot of testers the next days/weeks on current@ >> when people update their kernels and forgot to read UPDATING or fail to >> do the conversion properly.;) > > I can always say: "read UPDATING" (for log: I am not completely serious here. > :)). > > -- > Alexander Motin > > ___ 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: r221006 - head/etc/rc.d
Author: dougb Date: Mon Apr 25 05:57:01 2011 New Revision: 221006 URL: http://svn.freebsd.org/changeset/base/221006 Log: Add svn:executable property Modified: Directory Properties: head/etc/rc.d/opensm (props changed) ___ 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: r221007 - head/etc/rc.d
Author: dougb
Date: Mon Apr 25 06:03:22 2011
New Revision: 221007
URL: http://svn.freebsd.org/changeset/base/221007
Log:
Create a function for the code from r192246 so that it can be used both
times mount is called.
Limit the automatic behavior to when AUTO is specified (as it is in
etc/defaults/rc.conf) and for everything else take advantage of all
of the goodness in checkyesno.
Modified:
head/etc/rc.d/tmp
Modified: head/etc/rc.d/tmp
==
--- head/etc/rc.d/tmp Mon Apr 25 05:57:01 2011(r221006)
+++ head/etc/rc.d/tmp Mon Apr 25 06:03:22 2011(r221007)
@@ -37,20 +37,20 @@ stop_cmd=':'
load_rc_config $name
+mount_tmpmfs ()
+{
+ if ! /bin/df /tmp | grep -q "^/dev/md[0-9]"; then
+ mount_md ${tmpsize} /tmp "${tmpmfs_flags}"
+ chmod 01777 /tmp
+ fi
+}
+
# If we do not have a writable /tmp, create a memory
# filesystem for /tmp. If /tmp is a symlink (e.g. to /var/tmp,
# then it should already be writable).
#
case "${tmpmfs}" in
-[Yy][Ee][Ss])
- if ! /bin/df /tmp | grep -q "^/dev/md[0-9]"; then
- mount_md ${tmpsize} /tmp "${tmpmfs_flags}"
- chmod 01777 /tmp
- fi
- ;;
-[Nn][Oo])
- ;;
-*)
+[Aa][Uu][Tt][Oo])
if _tmpdir=$(mktemp -d -q /tmp/.diskless.XX); then
rmdir ${_tmpdir}
else
@@ -59,9 +59,13 @@ case "${tmpmfs}" in
echo "dropping into shell, ^D to continue anyway."
/bin/sh
else
- mount_md ${tmpsize} /tmp "${tmpmfs_flags}"
- chmod 01777 /tmp
+ mount_tmpmfs
fi
fi
;;
+*)
+ if checkyesno tmpmfs; then
+ mount_tmpmfs
+ fi
+ ;;
esac
___
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: r220983 - head
On 25/04/2011, at 6:55, Warner Losh wrote: >> The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are on a >> GPT system) or UFS IDs (/dev/ufsid/xxx) if you can't. > > I've been running with ufs labels for a couple of years now, since the first > rumblings of this hit the streets. They work great no matter what the > underlying partitioning scheme. The one drawback is that if you have > multiple disks with the same labels, then the first one wins. Normally not a > problem, but when you have it, you need to ensure the right one is selected. > I avoid this problem by prefixing a hostname to the label... This is why I prefer IDs since they are nominally unique (UFS ones, GPTs damn well better be :) Although I concede it is rather annoying to work out which is which, or type them out manually.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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"
