Re: FreeBSD 10.4-RC2 Now Available

[Marius Strobl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, Sep 24, 2017 at 07:46:19PM +1000, Ian Smith wrote:
> On Sat, 23 Sep 2017 19:54:50 +0200, Marius Strobl wrote:
> 
>  > o Given that the amd64 disc1 image was overflowing, more of the base
>  >   components installed into the disc1 (live) file systems had to be
>  >   disabled.  Most notably, this removed the compiler toolchain from
>  >   the disc1 images.  All disabled tools are still available with the
>  >   dvd1 images, though.
> 
> 1) Does that also apply to the components installed on the memstick.img?

Yes, given that the disc1 file systems are also used to create the
memstick images.

> 2) Are we any closer to gettng a larger memstick.img with dvd1 contents?

No, given that we'd likely want to have a variant of the memstick
images which include all base tools also for snapshots. However, so
far the dvd1 images are only created for releases and around the
notion to contain packages, i. e. it's not as simple as creating
additional memstick images from the dvd1 file system. Also, given
that with head the amd64 disc1 image is overflowing despite all
of the stripping, the way to go for 12.0 likely is to drop the
historical limits on images sizes along with the disc1 images and
instead provide DVD images with all base tools and for releases,
additional DVD images with packages on top. Similar for memstick
images. All of this probably boils down to adding options to both
makefs(8) and mkimg(1) for simply excluding the packages directory
(as for makefs(8), simpler than via an mtree(8) file) first, so
we neither need to employ hacks in the release scripts nor build
yet another file system set.

Marius

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJZx89+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0Q5QjQzNTVGOTU5ODBGQzVENzZCMDIy
MEI3MERFMTNGMUQxRTRGAAoJECC3DeE/HR5PrNwQAI7hNUN3IZRFcV3fzAl88GKP
B6FmZKSWogxTwqLJCQgglJXoUkid5FfzMGH9qDjEE1g6W0sN4Q5aysv5+5s+WPWU
Xfhl5ivm070dYDBaqbR0cxCaK7cbIScf14dbpxE6hNUYHV5hnQZp8kT+vvvWYIQz
TZlHGiK1dccYH5WOg/UgR7nvs6piXI5XzmvP7o1mWv2TdT0DwaNXjuHznwZnAdW7
rStMPpvlC99a6+iAU74cbcBQi9w6Uuro+7V+DXZSwQRdP0PQsx1zOxkwAeY5+BKz
PFK7w0SC5GB1ym7ddQSyY3+8bQOEelwOX99yqU9SCqPnqyMOl+l+CAv8gCenyoBl
BgU4fTAAtsxNgne065/cGA+EEMDZtI2mdleGV8xXQGUFu2Dp8+HOhKBID95SW7LJ
+WDAKUvbkQvw5URjFZ3TtsbqZQptGji/Xze8i6nJ1dv0aU2ajU3sjR/N5yy+wg9i
KUK7K53Wx0TKVUkd4oUDePEUSjnRzalO8BPk4oLi08EvmX/yBMVswdaV4GIhCy5+
hSzud+98xmq3eDhoRsLqE2eRUbP9BegbM7VappEqFRE1I0mLQG9A/8DR49aZhzA2
TFg+rnYhjjW3gW3GtgZteHeRYIlk9ADsTxvbz2CEL2JpuUIFeb6g2OPPXeqTXZQZ
hQPI71i7MhhJXRg+sQdM
=nrnb
-END PGP SIGNATURE-
___
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: CAM status: Command timeout

[Andrei via freebsd-stable]

22 сентября 2017 г., 02:35, "Keith Hellman"  
написал:

> On Wed, Sep 20, 2017 at 11:06:11PM +, freebsd-stable List wrote:
> 
>> Sometimes it even can boot, but in few minutes will hang with same errors.
>> 
>> Hardware: Supermicro X8DTN+-F / 6xWD1502FYPS-02W3B0 /2xE5649
>> HDDs connected to sata ports on baseboard.
>> If I add
>> hint.ata.2.mode=PIO4
>> hint.ata.3.mode=PIO4
>> hint.ata.4.mode=PIO4
>> hint.ata.5.mode=PIO4
>> to device.hints I'm able to boot but performance of IO becomes really 
>> disappointing.
>> Also, if I add something like "find / -name something" to zfs rc script, 
>> than boots fine.
> 
> Boots fine but hangs in a few minutes? Or all is good to go? Here is a
> thught: it could be the find / ... command is causing enough delay to
> let some hardware "settle down" and behave more reasonably. Can you
> replace the find cmd with an equivalent sleep(1) command of like
> duration and get the same results?
> 
>> If I roll back system to 11.0 all works fine again.
> 
> Seemingly minor deltas in the system could have had the needed delay
> as an implicit part of the system...
> 
> Just my 2c
Nope, it can't boot fine at all, or init will get segfault or ttys or just 
system becomes unresponsive and I can't even login, so this heppens during 
start of services. I've also tried to disable all "non-base" services, but 
without success. 
As for trying just sleep - it doesn't helps. Seems that find helps because of 
caching by system triggered by find.



> --
> Keith Hellman #include 
> khell...@mcprogramming.com from disclaimer import standard
> khell...@mines.edu gpg key 9FCF40FD
> freenode.net as mrtuple
> 
> "The First Python function ever written (takes place in the Garden of Eden)"
> 
> Guido sayeth "I will write def foo():"
> "Hmm, I could use an import, or two",
> Satan said, in a whirl, "Why not write it in Perl?",
> and the second function ever written - def foo_you():
> 
> -- Python Limmerick Contest submission by cappy2112
> http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/d7a780beaff2e88a
___
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: disk errors: CAM status: Uncorrectable parity/CRC error

[Steven Hartland]

Try reducing the disk connection speed down to see if that helps.

On Sun, 24 Sep 2017 at 06:49, Graham Menhennitt 
wrote:

> G'day all,
>
> I'm setting up a machine running 11-Stable on a PC Engines APU2C board.
> It has a 16Gb SSD as its first disk (ada0), and a Seagate 2Tb SATA-3
> disk as its second (ada1). I'm getting lots of read errors on the second
> disk. They appear on the console as:
>
> (ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 00 00 6b 02 40 00 00 00
> 01 00 00
> (ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada1:ahcich1:0:0:0): Retrying command
>
> dmesg:
>
>  ACS-2 ATA SATA 3.x device
> ada1: Serial Number 
> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
> ada1: Command Queueing enabled
> ada1: 1907729MB (3907029168 512 byte sectors)
> ada1: quirks=0x1<4K>
>
> I've replaced the disk and the cable without improvement. Unfortunately,
> I don't have a second CPU board to try.
>
> Is it possible that the board can't keep up with the data coming from
> the disk? If so, can I try slowing it down somehow?
>
> Any other suggestions, please?
>
> Thanks,
>
>  Graham
>
> ___
> 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"
___
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: FreeBSD 10.4-RC2 Now Available

[Ian Smith]

On Sat, 23 Sep 2017 19:54:50 +0200, Marius Strobl wrote:

 > o Given that the amd64 disc1 image was overflowing, more of the base
 >   components installed into the disc1 (live) file systems had to be
 >   disabled.  Most notably, this removed the compiler toolchain from
 >   the disc1 images.  All disabled tools are still available with the
 >   dvd1 images, though.

1) Does that also apply to the components installed on the memstick.img?

2) Are we any closer to gettng a larger memstick.img with dvd1 contents?

cheers, Ian
___
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"