Re: HEADS UP! DragonFly_Stable tag reverted to September 13th
On Thu, Oct 07, 2004 at 09:04:02PM -0700, Matthew Dillon wrote:
> :This particular breakage needs moving DragonFly_Stable tag on
> :/sys/sys/thread.h to 1.58, but it may not be enough. I feel against
> :moving Stable tag to anything other than a successfully built snapshot
> :that has been there for a while without serious bug reports.
>
> I think we can move the tag for anything non-VFS related. e.g. I
> already moved the tag for some other bug fixes and things. It's just
> the VFS stuff I am avoiding.
>
> I've moved that tag. There may be other issues, of course, please
> free to continue to post the ones that come up, I'm hip-deep in VFS.
Looking at the output from `cvs history -axT' (rtag history), what we have
now with DragonFly_Stable is the source from 29th of September with only /sys
reverted to the source from 13th(with an exception of /sys/sys/thread.h
being rev 1.58), which breaks while building pf-related tools. With /sys
updated to DragonFly_Snap29Sep2004, buildworld finishes but buildkernel
doesn't.
[ ... ]
T 2004-07-14 18:46 +0000 dillon if_re.c [DragonFly_1_0A_REL:A]
T 2004-09-13 18:51 +0000 dillon src [DragonFly_Stable:A]
T 2004-09-13 18:57 +0000 dillon src [DragonFly_Snap13Sep2004:A]
T 2004-09-30 02:35 +0000 dillon src [DragonFly_Stable:A]
T 2004-09-30 02:38 +0000 dillon src [DragonFly_Snap29Sep2004:A]
T 2004-10-06 05:47 +0000 dillon src/sys [DragonFly_Stable:A]
T 2004-10-07 20:48 +0000 dillon -rDragonFly_Snap13Sep2004 [DragonFly_Stable:A]
T 2004-10-07 20:48 +0000 dillon src/sys/Makefile [DragonFly_Stable:A]
T 2004-10-07 20:49 +0000 dillon src/sys/Makefile [DragonFly_Stable:DragonFly_Snap13Sep2004]
T 2004-10-07 20:49 +0000 dillon src/sys [DragonFly_Stable:DragonFly_Snap13Sep2004]
T 2004-10-07 20:50 +0000 dillon src/sys [DragonFly_Stable:DragonFly_Snap13Sep2004]
I have a crontab entry to sync DragonFly CVS repository every 7:30(JST)
in the morning, and checkout source trees from locally kept repository.
It means that DragonFly_Stable tree on October 6th(when I reported the panic)
was from '2004-09-30 02:35 +0000' rather than '2004-10-06 05:47 +0000'.
So I suspect VFS stages 5/99 and 6/99 had some bad side-effect, and it
agree with the fact that my laptop running 2004/09/28 world/kernel also
had similar panics and segmentation faults during buildworld.
I'm now going through buildworld followed by buildkernel with source tree
checked out as follows:
$ cd /usr/src
$ cvs up -dPrDragonFly_Stable
$ cvs up -dPrDragonFly_Snap29Sep2004 sys
$ cvs up -r1.75 sys/conf/files
$ cvs up -dPA sys/dev/raid/ips
$ cvs up -rDragonFly_Snap13Sep2004 sys/emulation/linux/linux_getcwd.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/emulation/svr4/svr4_misc.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/vfs_cache.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/vfs_vopops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/vfs_lookup.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/init_main.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/kern_descrip.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/vfs_default.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/kern/vfs_syscalls.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/sys/namecache.h
$ cvs up -rDragonFly_Snap13Sep2004 sys/sys/vfsops.h
$ cvs up -rDragonFly_Snap13Sep2004 sys/sys/namei.h
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/coda/coda_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/nfs/nfs_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/ntfs/ntfs_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/nullfs/null_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/nwfs/nwfs_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/smbfs/smbfs_vnops.c
$ cvs up -rDragonFly_Snap13Sep2004 sys/vfs/union/union_vnops.c
Most people don't need update of sys/dev/raid/ips; the driver is not
affected by the recent VFS changes, but HEAD contains devstat change and
is useful to a few people :)
For a build box, DragonFly_Snap13Sep2004 (or FreeBSD 4-STABLE) is the
safest choice at the moment until the next VFS change fixes the kernel.
討論串 (同標題文章)
完整討論串 (本文為第 3 之 6 篇)：