From owner-freebsd-stable Mon Mar 3 22:53:27 2003 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3394137B401; Mon, 3 Mar 2003 22:53:18 -0800 (PST) Received: from ns0.binep.ac.ru (serv2.binep.ac.ru [193.233.44.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBBC243F3F; Mon, 3 Mar 2003 22:53:03 -0800 (PST) (envelope-from goshik@binep.ac.ru) Received: from byfi (byfi.binep.ac.ru [193.233.44.234]) by ns0.binep.ac.ru (8.11.6/8.11.6) with SMTP id h246u5a29435; Tue, 4 Mar 2003 09:56:05 +0300 (MSK) (envelope-from goshik@binep.ac.ru) Message-ID: <054e01c2e21a$ab2d6060$ea2ce9c1@binep.ac.ru> From: "Igor B. Bykhalo" To: Cc: Subject: Forgotten MFCs? (Was: 4.8 RC1 Now Available) Date: Tue, 4 Mar 2003 09:52:44 +0300 Organization: BINEPCP RAS MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > The first release candidate is now available. The i386 FTP [...] > Please email re@ if you have an open issue that should be reflected [...] > - Murray / Release Engineering Team I'm not jumping on anyone, but i just compared contents of my "MFC candidates" mail folder with http://www.freebsd.org/cgi/cvsweb.cgi/src/?only_with_tag=RELENG_4 and it seems to me that following commits were forgotten somehow... Well, if cvsweb isn't fooling me. Sorry if i made a mistake... (BTW, sysinstall is a mystery for me: why cvsweb doesn't show its files in usr/sbin/sysinstall with RELENG_4 tag?) Igor > ume 2003/02/03 09:43:20 PST > > Modified files: > sys/alpha/linux linux.h > sys/compat/linux linux_socket.c > sys/i386/linux linux.h > sys/modules/linux Makefile > Log: > Add IPv6 support for Linuxlator. > > Reviewed by: dwmalone > MFC after: 10 days > > Revision Changes Path > 1.57 +1 -0 src/sys/alpha/linux/linux.h > 1.35 +372 -88 src/sys/compat/linux/linux_socket.c > 1.61 +1 -0 src/sys/i386/linux/linux.h > 1.61 +5 -2 src/sys/modules/linux/Makefile > > joerg 2003/02/05 13:02:57 PST > > Modified files: > sys/conf options > sys/dev/vinum vinum.c vinumhdr.h vinumio.c > Log: > Finally make vinum ready for the root filesystem in FreeBSD 5.x. (A > similar patch has been in 4.x for a while, but is more hacky there.) > > For this to work, vinum has to be loaded early (e. g. from > boot/loader), for obvious reasons. If the kernel env variable > (aka. loader variable) "vinum.autostart" is set, vinum then asks the > sysctl kern.disks for all available disks in the system, and scans > them for possible vinum headers. > > For statically compiled kernels, this behaviour can be obtained even > without boot/loader by using "options VINUM_AUTOSTART" (though this is > not the recommended way). > > Alternatively, the 4.x way to specify "vinum.drives" is also supported. > > No further hacks (like the 4.x "vinum.root" variable) are needed, > since in 5.x, mountroot() asks back at the drivers to have them > resolve the name of the root FS into a dev_t (using the dev_clone > eventhandler). > > (The MFC reminder below is for a partial MFC for vinum.autostart, the > rest is already there in 4.x.) > > Timed out on: grog > MFC after: 2 weeks > > Revision Changes Path > 1.373 +1 -0 src/sys/conf/options > 1.50 +82 -0 src/sys/dev/vinum/vinum.c > 1.28 +1 -0 src/sys/dev/vinum/vinumhdr.h > 1.80 +7 -22 src/sys/dev/vinum/vinumio.c > > joerg 2003/02/05 13:05:03 PST > > Modified files: > share/man/man4 vinum.4 > Log: > Document the recent changes for vinum as root filesystem. > > MFC after: 2 weeks > > Revision Changes Path > 1.46 +62 -9 src/share/man/man4/vinum.4 > > njl 2003/02/09 13:49:45 PST > > Modified files: > sys/cam/scsi scsi_da.c > Log: > Quirk for Lexar Media Jumpdrive > > PR: kern/47006 > Tested by: George Hartzell > MFC after: 1 week > > Revision Changes Path > 1.124 +8 -0 src/sys/cam/scsi/scsi_da.c > > mbr 2003/02/09 14:04:50 PST > > Modified files: > usr.sbin/sysinstall tcpip.c > Log: > Explicitly release a existing lease before we start dhclient (again). > If we already have a lease and restart sysinstall (or something with > the net configuration goes wrong), we would have to reboot just > because there is a dhclient hanging around. > > Reviewed by: murray (re) > MFC after: 5 days > > Revision Changes Path > 1.126 +1 -0 src/usr.sbin/sysinstall/tcpip.c > > gallatin 2003/02/16 09:30:49 PST > > Modified files: > sys/alpha/alpha machdep.c > Log: > When trimming memory to fit Maxmem, and we discard an entire cluster, > make certain to subtract its pages from physmem. Otherwise we end up > running phys_avail_cnt negative, and bad stuff happens. > > MFC After: 1 week > > Revision Changes Path > 1.193 +1 -0 src/sys/alpha/alpha/machdep.c > > gallatin 2003/02/16 11:25:04 PST > > Modified files: > sys/alpha/alpha machdep.c > Log: > zero the end of the memory cluster we're disposing of. Otherwise teh > vm page startup code finds a 20GB cluster on this wacky alphaserver I'm > working on.. > > MFC After: 7 days > > Revision Changes Path > 1.194 +1 -0 src/sys/alpha/alpha/machdep.c > > maxim 2003/02/17 05:41:56 PST > > Modified files: > sys/net if_spppsubr.c > Log: > o Restore an interrupt priority level before return. > > Submitted by: Roman Kurakin > Reviewed by: joerg > MFC after: 5 days > > Revision Changes Path > 1.99 +2 -0 src/sys/net/if_spppsubr.c > > kris 2003/02/17 17:35:58 PST > > Modified files: > usr.sbin/keyserv keyserv.c > Log: > Use arc4random() instead of random() when generating the master key. > > MFC after: 1 week > > Revision Changes Path > 1.11 +3 -2 src/usr.sbin/keyserv/keyserv.c > > des 2003/02/18 06:30:43 PST > > Modified files: > usr.bin/find option.c > Log: > Correctly alphabetize options[] so we don't stop at -nouser when searching > for -not. > > PR: bin/48423 > Submitted by: Matsumura Naoki > MFC after: 3 days > > Revision Changes Path > 1.19 +1 -1 src/usr.bin/find/option.c > > ceri 2003/02/19 13:48:28 PST > > Modified files: > usr.sbin/sysinstall install.c > Log: > s/to try and retry/to retry/ > > PR: misc/48226 > Submitted by: Gary W. Swearingen > MFC After: 2 days > Approved by: murray (mentor) > > Revision Changes Path > 1.340 +1 -1 src/usr.sbin/sysinstall/install.c > > mikeh 2003/02/20 12:13:07 PST > > Modified files: > usr.sbin/pkg_install/sign sign.c > Log: > Initialize sign to NULL so that we don't attempt to free() it in case > of failure. > > MFC after: 1 week > > Revision Changes Path > 1.3 +1 -0 src/usr.sbin/pkg_install/sign/sign.c > > bmilekic 2003/02/21 15:12:32 PST > > Modified files: > sys/dev/tx if_txvar.h > Log: > Nuke EPIC_MGETCLUSTER entirely. Since 1.60 we don't use it anymore and > instead use our optimized m_getcl(). > > Submitted by: Hiten Pandya > MFC After: 1 week > > Revision Changes Path > 1.17 +0 -13 src/sys/dev/tx/if_txvar.h > > bmilekic 2003/02/22 06:46:31 PST > > Modified files: > sys/pci if_xl.c > Log: > Make xl use m_getcl() to allocate an mbuf and a cluster in one shot, > as opposed to one after the other. This is faster in both -CURRENT > and -STABLE. Additionally, there is less code duplication for > error-checking. > > One thing to note is that this code seems to return(1) when no buffers > are available; perhaps ENOBUFS should be the correct return value? > > mikeh 2003/02/23 21:56:37 PST > > Modified files: > usr.sbin/zic zic.c > Log: > Check whether setmode(3) fails and deallocate its return value after > calling getmode(3). > > Approved by: wollman > MFC after: 1 week > > Revision Changes Path > 1.15 +5 -1 src/usr.sbin/zic/zic.c > > des 2003/02/25 07:01:54 PST > > Modified files: > usr.sbin/pkg_install/delete Makefile perform.c > Log: > Fix a long-standing bug where if the package being deleted had no > post-deinstall script, the variable intended to hold the name of that > script would be used uninitialized. In some cases, fexists() would > succeed, causing pkg_delete to try to chmod +x it, then execute it, > resulting in bizarre error messages such as: > > .//: Permission denied > > This bug would normally only occur when multiple packages were > specified on the command line; otherwise post_script would be located > in a previously unused part of the stack, and implicitly (but quite > accidentally) initialized to all-zeros. > > MFC after: 3 days > > Revision Changes Path > 1.18 +1 -1 src/usr.sbin/pkg_install/delete/Makefile > 1.38 +11 -13 src/usr.sbin/pkg_install/delete/perform.c > > simokawa 2003/02/27 04:51:24 PST > > Modified files: > sys/dev/firewire firewire.c firewirereg.h fwdev.c fwmem.c > sbp.c > Log: > MFp4(simokawa_sbp branch) > > Improve SBP device probeing: > - Wait 2 sec before issuing LOGIN ORB expecting the reconnection > hold timer expires. > - Serialize management ORB and scanning LUN by CAM on each target. > This should fix the problem for devices which have multiple LUNs. > Test device is donated by: Jaye Mathisen > - Freeze SIM queue for 2 sec after BUS RESET. > - Retry with LOGIN rather than RECONNECT after LOGIN is not completed for > BUS RESET. > - Use appropriate CAM status for BUS RESET and DEVICE RESET. > - Let CAM to scan targets after BUS REST. > - Implement CAM scan target function. > - Keep our own devq freeze count. > - Let CAM to know that SBP does tagged queuing. > > These should be merged to RELENG_4 before 4.8-RELEASE. > > Revision Changes Path > 1.43 +4 -8 src/sys/dev/firewire/firewire.c > 1.21 +6 -0 src/sys/dev/firewire/firewirereg.h > 1.21 +8 -0 src/sys/dev/firewire/fwdev.c > 1.15 +4 -0 src/sys/dev/firewire/fwmem.c > 1.35 +288 -100 src/sys/dev/firewire/sbp.c > > sobomax 2003/02/27 12:43:52 PST > > Modified files: > usr.sbin/sysinstall index.c > Log: > Increase size of the static buffer used to hold runtime dependency list > read from CD from 2k to 16k, because in the modern world of meta-packages > (Gnome et al) the length of this list could easily owerflow limit causing > strange things to happen, ranging from installation failure due to list > truncation to complete stack trashing (there is very vague bounds checking). > For example, x11/gnome2-fifth-toe runtime dependencies list is 2,418 bytes > long. > > Due to obvious reasons, this is an immediate MFC candidate. > > Sponsored by: Porta Software Ltd > MFC after: 1 day > > Revision Changes Path > 1.100 +4 -4 src/usr.sbin/sysinstall/index.c > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message