cvs-src summary for September 20-27

From: Mark Johnston <mjohnston_at_skyweb.ca>
Date: Tue, 28 Sep 2004 13:54:41 -0500
FreeBSD cvs-src summary for 20/09/04 to 27/09/04
++++++++++++++++++++++++++++++++++++++++++++++++
This is a regular weekly summary of FreeBSD's cutting-edge development.
It is intended to help the FreeBSD community keep up with the fast-paced
work going on in FreeBSD-CURRENT by distilling the deluge of data from
the CVS mailing list into a (hopefully) easy-to-read newsletter.  This
newsletter is marked up in reStructuredText_, so any odd punctuation
that you see is likely intended for the reST parser.

.. _reStructuredText: http://docutils.sourceforge.net/rst.html

You can get old summaries, and an HTML version of this one, at
http://www.xl0.org/FreeBSD/.  Please send any comments to Mark Johnston
(mark at xl0.org).

If you would like to get the summary without subscribing to current_at_,
please send mail to freebsd-cvs-summary-subscribe_at_lists.enderunix.org.
Thanks to Omer Faruk Sen and EnderUNIX for hosting this list.

For Lukasz Dudek and Szymon Roczniak's Polish translations of these
summaries, which may lag the English ones slightly, please see
http://mocart.pinco.pl/FreeBSD/.

.. contents::

===============
Notable changes
===============
Vinum RAID driver removed from the kernel
-----------------------------------------
Poul-Henning Kamp (phk) removed Vinum, the old volume manager and RAID
subsystem, from the kernel build.  It has been replaced by geom_vinum,
an implementation of the same functionality for the new GEOM disk access
layer, and all users should migrate to the new code.

http://www.freebsd.org/cgi/mid.cgi?200409230834.i8N8Yp3j015923

Device nodes on CD-ROM and ext2fs no longer supported
-----------------------------------------------------
Poul-Henning Kamp (phk) removed support for opening device nodes located
on cd9660 filesystems, as used on CD-ROMs, and on Linux-style ext2fs
filesystems.  They can be seen, but not opened and used as devices. devfs
(the device filesystem) should be used instead.

http://www.freebsd.org/cgi/mid.cgi?200409210842.i8L8gbhO058704
http://www.freebsd.org/cgi/mid.cgi?200409272038.i8RKckod020697

Daily security diff style changed to unified
--------------------------------------------
Joseph Koshy (koshy) added an option to /etc/periodic.conf called
"daily_security_status_diff_flags", which allows the format of the diffs
generated by periodic(8) scripts to be changed.  He also made the default
format "diff -u", for a unified diff.  This is the most-commonly-seen diff
type, with lines starting with + or -, as opposed to the old-style diffs,
with > and <.

http://www.freebsd.org/cgi/mid.cgi?200409230200.i8N20q8Q096334

=================
Discussion topics
=================
Generating hardware interrupts manually
---------------------------------------
After a brief, unrelated discussion about release engineering for 5.3,
the topic of generating interrupts came up.  It was first raised by Brian
Fundakowski Feldman (green), when he noted that on his hung system, "The
only way I can get reports other than 'it hung, serial DDB and SW_WATCHDOG
are no help' is if somehow I gain some kind of real hardware watchdog. :("

Peter Jeremy suggested, "If you have an ISA slot handy, you can trivially
generate NMI by shorting a [certain] pair of opposite pins [ . . . ]
Unfortunately, raising SERR# on a PCI bus appears to require some logic."

Scott Long (scottl) pointed out, "Not all PCI bridges are configured to
translate an SERR# signal to an NMI.  Some let you configure it in the
BIOS, some simply ignore SERR# and continue merrily on."

Alfred Perlstein (alfred) also replied to Peter, saying, "You are correct
on both counts.  However some ISA boards do not generate NMIs when
shorting the isa slot."

M. Warner Losh (imp) replied too, adding, "A1 and B1 pins.  This clocks
#IOCHK.  However, this doesn't work on all bridge chipsets, and many of
them don't reset correctly w/o changes to the tree. [ . . . ] However, it
will work on most chipsets."

Brian lamented, "Least of which my modern Athlon MP chipset which has no
physical ISA slots."

Daniel O'Connor speculated, "You can quite possibly do something similar
with PCI and #SERR directly..  I haven't tried it though :) Pin 42 is
#SERR and the other side of it in ground."

Peter wondered, "Does anyone with knowledge of the PCI spec know if just
shorting #SERR to ground will work?  (Assuming that the BIOS/chipset maps
#SERR to NMI)."

Roman Kurakin (rik) offered a link to an interesting-looking PCI to
ISA bridge card, saying, "I wonder if this could solve ISA problem
http://www.costronic.com/Ev71p.htm :-)"

Gavin Atkinson responded to Peter's question about shorting #SERR, saying,
"It is possible. The PCI 2.2 spec (section 3.7.4.2) says that it should
be asserted for a *single* clock cycle, then tri-stated. [ . . . ] So it
depends on how strictly they enforce the need for assertion to last a
'single clock cycle'."  He also noted, "Regardless of anything else, I
wouldn't like to just short SERR# to ground with a screwdriver as used to
be possible in the Good Ol' ISA Days... A bit of debounce logic would be
necessary to prevent multiple NMI's from being sent."

Daniel also replied to Peter, "You have to hold #SERR down for 1 PCI clock
and then tri-state it. I think you can do it with a basic 16V8 or so.  I'm
thinking of making such a board at work :)"

http://www.freebsd.org/cgi/mid.cgi?20040925203122.GF83620

===============
Other bug fixes
===============
Alan Cox (alc) fixed a long-standing bug that could cause panics in
pmap_enter on SMP systems.

http://www.freebsd.org/cgi/mid.cgi?200409220501.i8M51m8l009598

M. Warner Losh (imp) fixed a bug causing panics on boot with a USB hub
attached, as well as panics when detaching a USB hub.

http://www.freebsd.org/cgi/mid.cgi?200409220602.i8M62AGf011468

Max Laier (mlaier) fixed a bug preventing kernels from being built with
the options FAST_IPSEC and PF.  This closes `PR 71836`_.

.. _`PR 71836`: http://www.freebsd.org/cgi/query-pr.cgi?pr=71836

http://www.freebsd.org/cgi/mid.cgi?200409231244.i8NCiehC030045
Received on Tue Sep 28 2004 - 16:54:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:14 UTC