Re: bugs in memstick GPT table, and in gpart(8)

[Perry Hutchison]

Ian Smith <smi...@nimnet.asn.au> wrote:
> On Sun, 25 Dec 2016 17:03:46 -0800, Perry Hutchison wrote:
> > ...
> > The 10.3-RELEASE-i386-memstick has the smallest possible GPT table
> > (one sector), three GPT table entries (boot, rootfs, & swap), and
> > hdr_entries == 3 in the GPT header ...
> > 
> > Since the GPT table is always a whole number of sectors, and each
> > sector has room for four GPT table entries, there's no reason for
> > hdr_entries not to be a multiple of 4.  Whatever constructed the
> > 10.3-RELEASE-i386-memstick image should have rounded it up.
>
> That would be mkimg(1).  Recall that the 10.3-R amd64 memstick.img still 
> (or rather, again?) used the BSD scheme (daXa) rather than GPT, due to a 
> some-BIOSes issue.  In 11+ both use mkimg, both adding a 1MB 'vestigial' 
> swap partition to keep some BIOSes happy (thanks to Glen who pointed me 
> to the relevant r265017)

There is something truly horrifying about a report that "some BIOSes"
require a FreeBSD-swap partition in order to boot.  (I could understand
FreeBSD _itself_ insisting on having a swap partition, but the BIOS?)

> However in both cases, this is affected by a quite early commit to 
> mkimg.c: https://svnweb.freebsd.org/base?view=revision=263382
>
> "Also (...), remove the enforcement of creating a GPT table with at 
> least 128 entries. While this is generally advised as the default or 
> minimum, it's not actually a hard requirement. We now recreate a table 
> that's precisely enough (rounded of course)."
>
> So '3' definitely seems an unrounded result, long after this commit.
>
> Have you checked this against an 11.0-RELEASE-i386-memstick.img ?

I hadn't, because I don't generally deal with .0 releases :)
but I just checked and it still has gpt_hdr.hdr_entries == 3.

> > The GPT support in the kernel and in gpart(8) should handle
> > hdr_entries consistently:  either always round it up to a multiple
> > of four, or always take it at face value.  It should not be possible
> > for gpart(8) to create a partition which will effectively disappear
> > the next time the provider is tasted.
>
> Agreed.  I'm not sure, even after checking the _possibly somewhat_ 
> authoritative https://en.wikipedia.org/wiki/GUID_Partition_Table
> whether this refers to the maximum (as I suspect) or the current
> number of partitions, as listed in 'GPT header format':
>
> 72 (0x48)  8 bytes  Starting LBA of array of partition entries ...
> 80 (0x50)  4 bytes  Number of partition entries in array
> 84 (0x54)  4 bytes  Size of a single partition entry (usually 80h or 128)
>
> Also from that, we're apparently disregarding: "The UEFI specification 
> stipulates that a minimum of 16,384 bytes, regardless of sector size,
> be allocated for the Partition Entry Array."  Ie, 128 entries.
>
> Which is probably just as well, though losing 16KB at the start and end 
> of a physical disk seems fairly minute these days, even on 1GB sticks,

It won't matter, until someday when it makes the difference between an
image fitting onto a stick of a given size or not :)

I have no complaint with minimizing wasted space, but limiting the size
to 3 when it necessarily occupies a multiple of 4 goes too far IMO.

> Still, there are various references, as in mkimg(1) above, stating this 
> is not required.  Similarly in gpart(8), optional for 'create' we have:
>
> -n entries  The number of entries in the partition table ...
> By default, partition tables are created with the
> minimum number of entries.
>
> In none of the instances of use of gpart(8) I've seen in any /release is 
> that -n flag used.  mkimg(1) doesn't take anything like the -n switch, 
> though perhaps it could / should?

mkimg(1) seems to set the number of partitions created according to
the number of -p switches provided on the command line -- but I'd
think it ought to round up rather than leave part of a sector unused.

> > The willingness of gpart(8) to add a partition exceeding the defined
> > size of the GPT table is a recent regression (as well as, arguably,
> > a buffer overrun):
>
> I'm surprised it didn't extend that '3' count (clearly bogus, not
> at all rounded) to 4 when it added another partition.

IMO it should either have enforced the limit of 3 -- with an accurate
message (not FreeBSD 8's misleading "No space left on device") -- or
incremented it (that being possible in this case since there was room
to enlarge the table).  However ...

> It didn't even need to allocate another table sector, as going from
> 4 to 5 or more would.

Allocating another sector would be a _very_ large and risky
operation if, as would usually be the case, the sector needed for
exp

bugs in memstick GPT table, and in gpart(8)

[Perry Hutchison]

Some months ago:

> I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive,
> and booted it into single-user mode where it appeared as da0.  Then,
> to resize the GPT to the media (to make space for another partition):
>
> # gpart show da0
> # gpart recover da0
> # gpart show da0
>
> which appeared to work ... [but] when I tried to create a 4th
> partition in that free space:
>
> # gpart show da0  # showed 3 partitions and about 3GB of free space
> # gpart add -t freebsd-ufs da0# reported "da0p4 added"
> # gpart show da0  # showed 4 partitions including the new one, and
>   # no free space -- as expected
> # shutdown -r now
>
> a "gpart show da0" after the reboot showed 3 partitions and about
> 3GB of free space, the same as before the "gpart add" operation.
> In other words, the new partition did not survive the reboot.

I finally had time to track down what was going on, and it turns
out that both the 10.3 GPT support, and the construction of the
10.3-RELEASE-i386-memstick, are buggy.

Details:

The 10.3-RELEASE-i386-memstick has the smallest possible GPT table
(one sector), three GPT table entries (boot, rootfs, & swap), and
hdr_entries == 3 in the GPT header.  Despite that setting, the
"gpart add" operation did create a fourth table entry -- and the
new entry was (temporarily) available for the system to use (e.g.
I was able to run an apparently-successful newfs on it).

A subsequent hexdump(1) of the GPT table sector showed that the new
entry had even been written to the device.  However, after a reboot
(or, likely, any event causing the device to be tasted again), the
hdr_entries setting causes the new, fourth entry to be ignored:
only the three original entries are recognized.

Bugs:

Since the GPT table is always a whole number of sectors, and each
sector has room for four GPT table entries, there's no reason for
hdr_entries not to be a multiple of 4.  Whatever constructed the
10.3-RELEASE-i386-memstick image should have rounded it up.

The GPT support in the kernel and in gpart(8) should handle
hdr_entries consistently:  either always round it up to a multiple
of four, or always take it at face value.  It should not be possible
for gpart(8) to create a partition which will effectively disappear
the next time the provider is tasted.

The willingness of gpart(8) to add a partition exceeding the defined
size of the GPT table is a recent regression (as well as, arguably,
a buffer overrun):  Under the same conditions the FreeBSD 8 version
of gpart(8) complained "gpart: index '4': No space left on device".
(The message is wrong -- it should be something like "Partition
table full" -- but apart from the misleading message the situation
seems to have been handled correctly.)  Meanwhile even FreeBSD 8's
gpart(8) is less helpful than its predecessor, gpt(8).  Trying to
perform this same operation on FreeBSD 6 produces:

# gpt -r show da0
start size  index  contents
01 PMBR
11 Pri GPT header
21 Pri GPT table
3   32  1  GPT part - 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   35  1348832  2  GPT part - FreeBSD UFS/UFS2
  1348867 2048  3  GPT part - FreeBSD swap
  1350915  6460155 
  78110701 Sec GPT table
  78110711 Sec GPT header
# gpt add da0
gpt add: da0: error: no available table entries
# gpt add -i 4 da0
gpt add: da0: error: index 4 out of range (3 max)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

10.3 gpart(8) strangeness

[Perry Hutchison]

I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive,
and booted it into single-user mode where it appeared as da0.  Then,
to resize the GPT to the media (to make space for another partition):

# gpart show da0
# gpart recover da0
# gpart show da0

which appeared to work:  the second "gpart show" showed a larger
free space following the partitions than the first, and that
resizing survived a reboot.  However, when I tried to create a
4th partition in that free space:

# gpart show da0  # showed 3 partitions and about 3GB of free space
# gpart add -t freebsd-ufs da0  # reported "da0p4 added" (or similar)
# gpart show da0  # showed 4 partitions including the new one, and
  # no free space -- as expected
# shutdown -r now

a "gpart show da0" after the reboot showed 3 partitions and about
3GB of free space, the same as before the "gpart add" operation.
In other words, the new partition did not survive the reboot.

I tried several variations, e.g. specifying "-f x" on the "gpart
add" command (followed by a separate "gpart commit"), and I could
never get the new partition to survive a reboot; but labels applied
to the 3 pre-existing partitions using "gpart modify -l" did survive.

Did I do something wrong, or have I stumbled over some obscure bug
in the 10.3 gpart(8)?  How do I create a partition, that will survive
reboot, in the free space at the end of the i386 10.3 memstick?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Where is 10.2-STABLE?

[Perry Hutchison]

Jack Raats  wrote:

> If you look at the ftp.freebsd.org than you can see that
> the 10.3-RELEASE can be downloaded.
> The strange thing is that there is no announcement yet.

The likely (short) explanation is that re@ are not entirely
done with it.  Before it can be announced, both the bits and
all associated infrastructure have to be ready.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ICH5 ATA DMA timeouts

[Perry Hutchison]

Interesting.  The ICH5 is part of the processor chipset, and it
could be "anywhere" on the system board, so finding/identifying
it (so as to point a fan at it, or figure out a way to add a
heatsink) may be less than straightforward -- but it's worth
keeping in mind as something to look into if problems arise.

Any idea where one finds cheap (but reliable) PCI SATA cards
these days?  It would have to be PCI -- this box does not have
PCI-E slots.

Florian Ermisch <florian.ermi...@alumni.tu-berlin.de> wrote:

> I had some onboard (S)ATA controllers becoming unreliable in the
> past. Two of them due to chipsets overheating under load which
> were fixable with additional cooling. In the third one we just
> added a cheap SATA card and spread the redundant disks between
> onboard and add-on controller to make a temporary failure a minor
> issue.
>
> Regards, Florian
>
> Am 6. Dezember 2015 22:21:35 MEZ, schrieb Steven Hartland 
> <kill...@multiplay.co.uk>:
> > Check cables and devices are in good condition. These things are
> > usually a connectivity issue or device failing
> > 
> > On 06/12/2015 03:06, Perry Hutchison wrote:
> > > Does anyone know the condition of the ICH5 ATA support in FreeBSD
> > > 10?
> > >
> > > In preparing to repurpose an elderly Dell Dimension 4600 from
> > > Windows to FreeBSD, and needing to decide what to do about
> > > drives, I found several mentions in the archives* of ICH5 ATA
> > > DMA timeouts -- mostly affecting the SATA ports, but the
> > > prevalence of SATA reports may just indicate which ports were
> > > getting the most use:  a couple of the reports involved the
> > > PATA ports.
> > >
> > > While there have been commits to the ATA code since then, I didn't
> > > find any definitive statement that the DMA timeouts had been fixed.
> > > Did I miss something, or would I be better off using a separate SATA
> > > or PATA PCI card instead of the ICH5's built-in ports?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ICH5 ATA DMA timeouts

[Perry Hutchison]

Er, there's nothing to check, yet.  I'm trying to *avoid* trouble
by finding out in advance about any dodgy hardware support.

In several of the cited threads, it was pretty clear that the
hardware was not faulty, since the identical hardware had run
properly on 4.x but started generating DMA timeouts on 5.x; also
diagnostics were run (=> drives OK), cables replaced, etc.  In at
least one case the failure was reproduced on a different box than
where it had originally been observed.

It was suspected that there might have been some kind of interaction
between geom and the ATA code, e.g. a timing problem, since many of
the failures involved software mirroring (vinum or gmirror).

Steven Hartland <kill...@multiplay.co.uk> wrote:

> Check cables and devices are in good condition. These things are
> usually a connectivity issue or device failing
>
> On 06/12/2015 03:06, Perry Hutchison wrote:
> > Does anyone know the condition of the ICH5 ATA support in FreeBSD 10?
> >
> > In preparing to repurpose an elderly Dell Dimension 4600 from Windows
> > to FreeBSD, and needing to decide what to do about drives, I found
> > several mentions in the archives* of ICH5 ATA DMA timeouts -- mostly
> > affecting the SATA ports, but the prevalence of SATA reports may
> > just indicate which ports were getting the most use:  a couple of
> > the reports involved the PATA ports.
> >
> > While there have been commits to the ATA code since then, I didn't
> > find any definitive statement that the DMA timeouts had been fixed.
> > Did I miss something, or would I be better off using a separate SATA
> > or PATA PCI card instead of the ICH5's built-in ports?
> >
> > Relevant parts of dmesg (with no hard drives attached):
> >
> > FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12 19:31:38 UTC 2015
> >  r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
> > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.06-MHz 686-class CPU)
> >Origin="GenuineIntel"  Id=0xf34  Family=0xf  Model=0x3  Stepping=4
> >
> > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> >Features2=0x441d<SSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR>
> >TSC: P-state invariant
> > uhci0:  port 0xff80-0xff9f irq 
> > 16 at device 29.0 on pci0
> > usbus0 on uhci0
> > uhci1:  port 0xff60-0xff7f irq 
> > 19 at device 29.1 on pci0
> > usbus1 on uhci1
> > uhci2:  port 0xff40-0xff5f irq 
> > 18 at device 29.2 on pci0
> > usbus2 on uhci2
> > uhci3:  port 0xff20-0xff3f irq 
> > 16 at device 29.3 on pci0
> > usbus3 on uhci3
> > ehci0:  mem 
> > 0xffa80800-0xffa80bff irq 23 at device 29.7 on pci0
> > usbus4: EHCI version 1.0
> > usbus4 on ehci0
> > atapci0:  port 
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7 
> > irq 18 at device 31.1 on pci0
> > ata0:  at channel 0 on atapci0
> > ata1:  at channel 1 on atapci0
> > atapci1:  port 
> > 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 
> > 18 at device 31.2 on pci0
> > ata2:  at channel 0 on atapci1
> > ata3:  at channel 1 on atapci1
> > pci0:  at device 31.3 (no driver attached)
> > pcm0:  port 0xee00-0xeeff,0xedc0-0xedff mem 
> > 0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0
> > pcm0: primary codec not ready!
> > pcm0: 
> > ata0: reset tp1 mask=00 ostat0=ff ostat1=ff
> > ata1: reset tp1 mask=03 ostat0=00 ostat1=00
> > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
> > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
> > ata1: reset tp2 stat0=00 stat1=00 devices=0x3
> > ata2: SATA reset: ports status=0x00
> > ata2: p0: SATA connect timeout status=0004
> > ata3: SATA reset: ports status=0x00
> > ata3: p0: SATA connect timeout status=0004
> > pass0 at ata1 bus 0 scbus1 target 0 lun 0
> > pass0:  Removable CD-ROM SCSI device
> > pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> > pass1 at ata1 bus 0 scbus1 target 1 lun 0
> > pass1:  Removable CD-ROM SCSI device
> > pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> > cd0 at ata1 bus 0 scbus1 target 0 lun 0
> > cd0:  Removable CD-ROM SCSI device
> > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> > cd0: Attempt to query device size failed: NOT READY, Medium not present
> > cd1 at ata1 bus 0 scbus1 target 1 lun 0
> > cd1:  Removable CD-ROM SCSI device
> > cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> > cd1: Attempt to

ICH5 ATA DMA timeouts

[Perry Hutchison]

Does anyone know the condition of the ICH5 ATA support in FreeBSD 10?

In preparing to repurpose an elderly Dell Dimension 4600 from Windows
to FreeBSD, and needing to decide what to do about drives, I found
several mentions in the archives* of ICH5 ATA DMA timeouts -- mostly
affecting the SATA ports, but the prevalence of SATA reports may
just indicate which ports were getting the most use:  a couple of
the reports involved the PATA ports.

While there have been commits to the ATA code since then, I didn't
find any definitive statement that the DMA timeouts had been fixed.
Did I miss something, or would I be better off using a separate SATA
or PATA PCI card instead of the ICH5's built-in ports?

Relevant parts of dmesg (with no hard drives attached):

FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12 19:31:38 UTC 2015
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.06-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0xf34  Family=0xf  Model=0x3  Stepping=4
  
Features=0xbfebfbff
  Features2=0x441d
  TSC: P-state invariant
uhci0:  port 0xff80-0xff9f irq 16 at 
device 29.0 on pci0
usbus0 on uhci0
uhci1:  port 0xff60-0xff7f irq 19 at 
device 29.1 on pci0
usbus1 on uhci1
uhci2:  port 0xff40-0xff5f irq 18 at 
device 29.2 on pci0
usbus2 on uhci2
uhci3:  port 0xff20-0xff3f irq 16 at 
device 29.3 on pci0
usbus3 on uhci3
ehci0:  mem 0xffa80800-0xffa80bff 
irq 23 at device 29.7 on pci0
usbus4: EHCI version 1.0
usbus4 on ehci0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf mem 0xfeb7fc00-0xfeb7 irq 
18 at device 31.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
atapci1:  port 
0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 18 at 
device 31.2 on pci0
ata2:  at channel 0 on atapci1
ata3:  at channel 1 on atapci1
pci0:  at device 31.3 (no driver attached)
pcm0:  port 0xee00-0xeeff,0xedc0-0xedff mem 
0xfeb7fa00-0xfeb7fbff,0xfeb7f900-0xfeb7f9ff irq 17 at device 31.5 on pci0
pcm0: primary codec not ready!
pcm0: 
ata0: reset tp1 mask=00 ostat0=ff ostat1=ff
ata1: reset tp1 mask=03 ostat0=00 ostat1=00
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: reset tp2 stat0=00 stat1=00 devices=0x3
ata2: SATA reset: ports status=0x00
ata2: p0: SATA connect timeout status=0004
ata3: SATA reset: ports status=0x00
ata3: p0: SATA connect timeout status=0004
pass0 at ata1 bus 0 scbus1 target 0 lun 0
pass0:  Removable CD-ROM SCSI device
pass0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
pass1 at ata1 bus 0 scbus1 target 1 lun 0
pass1:  Removable CD-ROM SCSI device
pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0 at ata1 bus 0 scbus1 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
cd1 at ata1 bus 0 scbus1 target 1 lun 0
cd1:  Removable CD-ROM SCSI device
cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd1: Attempt to query device size failed: NOT READY, Medium not present - tray 
closed
GEOM: new disk cd0
GEOM: new disk cd1

* Archive mentions, in http://lists.freebsd.org/pipermail/...

  freebsd-hardware/2004-September/thread.html#1924
  freebsd-current/2005-February/thread.html#46719
  freebsd-current/2005-February/thread.html#46737
  freebsd-stable/2005-March/thread.html#13265
  freebsd-stable/2007-May/thread.html#35061
  freebsd-stable/2007-July/thread.html#36308
  freebsd-bugs/2012-November/thread.html#50729
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: svn - but smaller?

[Perry Hutchison]

Slawa Olhovchenkov s...@zxy.spb.ru wrote:
  pkg_info -r /usr/ports/packages6/All/subversion-1.7.8.tbz 
 Information for /usr/ports/packages6/All/subversion-1.7.8.tbz:

 Depends on:

 

 Static linked, NEON included, run on 6+.

This posting looks like an announcement of a package available for
download, but it doesn't look right for a pathname on freebsd.org
and Google isn't finding it (either on freebsd.org, or elsewhere).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Does / Is anyone maintaining CVS for FreeBSD?

[Perry Hutchison]

Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote:

   I'm a bit reluctant to installing svn on every system that
   needs source updates. Are there more lightweight ways?

http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070794.html
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: NFS-exported ZFS instability

[Perry Hutchison]

Hiroki Sato h...@freebsd.org wrote:

  I have been in a trouble about my NFS server for a long time.
  The symptom is that it stops working in one or two weeks after
  a boot ...  It did not panic, just stopped working---while it
  responded to ping, userland programs seemed not working ...

  Does anyone see how to debug this?  I guess this is due to a
  deadlock somewhere ...

If you can afford the overhead, you could try running with some
of the kernel debug options enabled (e.g. WITNESS, INVARIANTS,
MUTEX_DEBUG).  See conf/NOTES for descriptions.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: confirm that csup is still usable fos the new 9.1

[Perry Hutchison]

Kevin Oberman kob6...@gmail.com wrote:

 ... don't bet that csup and cvs will be around long ...
 It's really time to get away from CVS and I suspect
 it will be going away sooner than had been planned.

Once csup goes away, how will a base-only system update
the sources, e.g. to follow a security branch?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org