Re: Skylake/HD graphics support

[Warren Block]

On Sun, 13 Nov 2016, Daniel Campos do Nascimento wrote:


Hello,

First time posting on a mailing list...

I currently have 11.0-STABLE installed on my laptop which has a Core
i7-6500U. I can't get Xorg-server to work neither with xf86-driver-intel,
nor with i915kms driver; I'm falling back on the scfb driver. I would like
to know how the situation is with 12.0-CURRENT regarding graphics?


TrueOS.org is FreeBSD-current (yes, a rolling release) plus the latest 
video driver work that is not in -current plus some other things like 
LibreSSL.  It worked on a Core M Broadwell tablet, but I have not really 
tested it thoroughly.  It is supports Skylake, but my only Skylake 
machine has a Radeon board and is running plain -current.


This was formerly called PC-BSD, but it has changed name and design 
lately.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Destroy GPT partition scheme absolutely, how?

[Warren Block]

On Mon, 26 Sep 2016, John Baldwin wrote:


On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote:



On Sep 26, 2016, at 22:48, Ernie Luzar  wrote:


...


This little script has been posted before. Maybe it will be what your looking 
for. Called gpart.nuke

#! /bin/sh
echo "What disk do you want"
echo "to wipe? For example - da1 :"
read disk
echo "OK, in 10 seconds I will destroy all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
# Delete MBR and partition table.
dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
# Delete GEOM metadata.
dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
count=2
done


Why not just use "gpart destroy -F provider"?


That doesn't always work.  In particular, if a disk was partitioned with GPT
and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the
MBR will leave most of the GPT intact and the disk will come up with the old
GPT partitions, not as a raw disk.


Right.  So do a gpart destroy -F of whatever is on there, ignoring 
errors, then a gpart create -s gpt.  Now there is definitely a secondary 
GPT, and a final gpart destroy -F removes it cleanly.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r300951: mountroot: waiting for device /dev/ad4s1a...

[Warren Block]

On Sat, 4 Jun 2016, Matthias Apitz wrote:


El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió:


It's also covered in UPDATING:

20151011:
Compatibility shims for legacy ATA device names have been
removed. It includes ATA_STATIC_ID kernel option,
kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases
loader tunables, kern.devalias.* environment variables, /dev/ad*
and /dev/ar* symbolic links.



Next time I will do read UPDATING. Thanks for your help.


Use labels so there are no static device names at all.  With MBR, the 
options are limited, but UFS labels work and have no metadata problems:


http://www.wonkity.com/~wblock/docs/html/labels.html

GPT has very nice partition labels that can be set with gpart -l.  It 
works with i386 and BIOS booting.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI dual boot zfs root

[Warren Block]

On Sun, 15 May 2016, Andreas Nilsson wrote:


Hello,

I'm trying to install current on my lenovo x1 yoga ( and keeping it dual
boot for now).

I have a fair amount of disk free after resizing. I can't seem to workout
how to do the partitioning. Do I only need the freebsd-zfs partition (
assuming no/zvol-swap?


I would think, but have not tested ZFS with UEFI.


Do I manually copy boot1.efi to the existing EFI partition?


Yes.  Mount the EFI partition with msdosfs, then copy boot1.efi to 
/EFI/BOOT/.  Then comes the tricky part, getting the UEFI firmware to 
add that as a boot option.  In a Dell UEFI system, it could be added to 
the boot options, and the firmware has the user select the file from the 
EFI partition for that option.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CAM I/O Scheduler (was Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd))

[Warren Block]

On Tue, 3 May 2016, Johan Hendriks wrote:


Op 02/05/16 om 02:49 schreef Warren Block:
  CAM I/O Scheduler

     Links
     I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
     https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
     The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU

     Contact: Warner Losh <wl...@netflix.com>

     An enhanced CAM I/O scheduler has been committed to the tree. By
     default, this scheduler implements the old behavior. In addition, an
     advanced adaptive scheduler is available. Along with the scheduler,
     SATA disks can now use Queued Trims with devices that support them.
     Details about the new scheduler are available in the I/O Scheduling in
     FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.

I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error about an 
unknown option.
If I use CAM_NETFLIX_IOSCHED the kernel compiles.
Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?


That is my understanding, yes.  Warner can certainly explain it better 
than I can, so CCed.


Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)

[Warren Block]

Introduction

   The first quarter of 2016 showed that FreeBSD retains a strong sense of
   ipseity. Improvements were pervasive, lending credence to the concept
   of meliorism.

   Panegyrics are relatively scarce, but not for lack of need. Perhaps
   this missive might serve that function in some infinitesimal way.

   There was propagation, reformation, randomization, accumulation,
   emulation, transmogrification, debuggenation, and metaphrasal during
   this quarter.

   In the financioartistic arena, pork snout futures narrowly edged out
   pointilism, while parietal art remained fixed.

   In all, a discomfiture of abundance. View the rubrics below, and marvel
   at their profusion and magnitude! Marvel!

   --Warren Block
 __

   Please submit status reports for the second quarter of 2016 by July 7.
   A thesaurus will be provided for submitters who do not have one of
   their own. We will need them back afterwards, preferably with no new
   teeth marks on the covers. Thank you!
 __

FreeBSD Team Reports

 * Cluster Admin
 * The FreeBSD Core Team

Projects

 * Address Space Layout Randomization
 * Ceph on FreeBSD
 * Process-Shared Locks for libthr
 * RCTL Disk IO Limits
 * The Graphics Stack on FreeBSD

Kernel

 * ARM Allwinner SoC Support
 * CAM I/O Scheduler
 * FDT Overlay Support in UBLDR
 * Filemon Performance/Stability Improvements
 * FreeBSD Integration Services (BIS)
 * Infiniband
 * MMC Stack Under CAM Framework
 * NFS Server
 * Static Analysis of the FreeBSD Kernel with PVS Studio

Architectures

 * AmigaOne X5000 Support
 * FreeBSD on Cavium ThunderX (arm64)
 * powerpcspe Target

Userland Programs

 * ELF Tool Chain Tools
 * Native PCI-express HotPlug
 * Updates to GDB
 * Using lld, the LLVM Linker, to Link FreeBSD

Ports

 * GitLab Port
 * GNOME on FreeBSD
 * KDE on FreeBSD
 * Obsoleting Rails 3
 * Ports Collection

Documentation

 * New FreeBSD Mastery Books
 * Spanish FAQ and Chinese Porter's Handbook Translations

Miscellaneous

 * FreeBSD Build
 * Qt 5.6 on Raspberry Pi
 * The FreeBSD Foundation
 __

FreeBSD Team Reports

Cluster Admin

   Contact: <cluster...@freebsd.org>

   This quarter, we:
 * migrated services out of the hosting space in ISC (peter, sbruno)
 * began migration of services into the RootBSD hosting space (peter,
   sbruno)
 * collaborated with the phabricator admin team to migrate to a new
   and improved host in NYI. (allanjude, peter, sbruno)
 * installed a new and beefier Jenkins machine (gnn, lwshu, sbruno)
 * are still looking for more Asian mirrors for pkg, svn, and ftp
   (Japan, India). (sbruno)
 * completed the migration of the Taiwanese mirror to its new
   location. (lwshu)
 * started hosting a clang/llvm buildbbot in the FreeBSD cluster at
   NYI (sbruno, emaste)
 * resolved a UK mirror outage with Bytemark (gavin, peter)
 __

The FreeBSD Core Team

   Contact: FreeBSD Core Team <c...@freebsd.org>

   During the first quarter of 2016, the most important business of the
   FreeBSD Core Team has been to respond to the harassment incident last
   year. Core's actions were to assemble a timeline of the events and in
   the light of that to review Core's actions at the time; and to make
   recommendations about how better to handle such cases in future. During
   this process, draft reports were reviewed by people concerned in the
   case and in addition a number of interested members of the FreeBSD
   community. Core would like to thank everyone involved for their
   contributions.

   The report was published to the FreeBSD developer community in
   mid-February, and contained six recommendations for the community to
   consider.

   Core is also coordinating with the committee headed by Anne Dickison
   who are reviewing the Code of Conduct. A corpus of case studies is
   being assembled, which will be re-examined to see what impact changes
   to the Code of Conduct would have had.

   Core, together with John Baldwin, are working on a plan to create a
   separate repository containing GPLv3 toolchain components. This will
   allow modernization of code within base beyond what the existing GPLv2
   toolchain can handle, and permit support of certain new architectures
   where a copyfree licensed alternative (i.e., LLVM) is not yet
   available. A position paper will soon be circulated to developers for
   comment.

   During this quarter three new commit bits were issued, and one was
   returned for safekeeping. Please welcome Wojciech Macek, Jared McNeil
   and Stanislav Galabov, and 

Re: qsort() documentation

[Warren Block]

On Tue, 19 Apr 2016, Aleksander Alekseev wrote:


Why Wikipedia, specifically?  There are a lot of places that describe
quicksort.  How about just

   Note: This implementation of qsort() is designed to avoid the
   worst-case complexity of N**2 that is often seen with standard
   versions.


I would say that this statement is just false. Worst-case complexity is
still N**2. How about something like:

"""
This implementation of qsort() has worst case complexity of N**2.
However measures were taken that make it very unlikely that for some
random input N**2 swaps will be made. It's still possible to generate
such an input on purpose though. See code below for more details.
"""


Okay:

  The quicksort algorithm worst-case is O(N**2), but this implementation
  has been designed to avoid that for most real data.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: qsort() documentation

[Warren Block]

On Mon, 18 Apr 2016, Hans Petter Selasky wrote:


Hi,

Are there any objections adding the following as part of documenting our 
kernel's qsort function?


Index: sys/libkern/qsort.c
===
--- sys/libkern/qsort.c (revision 298202)
+++ sys/libkern/qsort.c (working copy)
@@ -45,6 +45,10 @@

/*
 * Qsort routine from Bentley & McIlroy's "Engineering a Sort Function".
+ *
+ * NOTE: This implementation of qsort() was designed to not have the


"was designed to avoid the"


+ * worst case complexity of N**2, as seen with the regular quick sort
+ * functions as described by Wikipedia.
 */


Why Wikipedia, specifically?  There are a lot of places that describe 
quicksort.  How about just


  Note: This implementation of qsort() is designed to avoid the
  worst-case complexity of N**2 that is often seen with standard
  versions.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Heads up

[Warren Block]

On Thu, 14 Apr 2016, Warner Losh wrote:



On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wbl...@wonkity.com> wrote:
  On Thu, 14 Apr 2016, Warner Losh wrote:

The CAM I/O scheduler has been committed to current. This work is 
described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though 
the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on 
ada SSDs.
There are a few rogue drives that claim support for this feature, 
but
actually implement data corrupt instead of queued trims. The list 
of known
rogues is believed to be complete, but some caution is in order.

 
  Is the list of drives queryable?  Is there an easy way to tell if the 
currently-connected drives are on the list?


/usr/src/sys/cam/ata/ata_da.c has the list.

dmesg will tell you if it detected a bad one since it prints the drive's quirks.
But that's no big deal, because the bad one work just fine if you never issue
a NCQ TRIM. This small group of drives were early adapters of this technology

Here's the full list of known rogues:

Crucial/Micron M500 (all firmware prior to MU07)
Micron M510 MU01 firmware (newer firmware is good)
Crucial/Micron M550 MU01 firmware (newer firmware is good)
Crucial MX100 MU01 firmware (newer firmware is good)
FCCT M500 all firmware
Samsung 830 all firmware
Samsung 840 all firmware
Samsung 850 all firmware

All of these are at least 18 months old (if not older). There's some confusing 
in Linux lists on
the full impact of the Samsung drives (there was a bug in the Linux 
implementation (that can't
be present in the FreeBSD implementation) that may have been the root cause for 
the Samsung
black listing). Out of an abundance of caution, I've kept them in the list. 
Also, it's my belief that
the Crucial/Micron models with MU01 firmware were mostly corrected after early 
samples
since most of the channel drives I've helped people debug had MU02 firmware. 
Also, a quick
google search shows the MU02 firmware for each of these models has been 
available for
at least a year.


After updating a Dell E7240, booting showed a bunch of FPDMA errors and 
then panicked after about 30 seconds.


The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q.  I 
believe this is the OEM version of the Samsung 840 Evo.  According to 
the Dell support page, the machine shipped on January 22, 2015.  So 
while the drive might not have been manufactured in a while, Dell was 
still using them that recently.  Note that this is a used machine, I 
have only had it a week.


After booting with mfsBSD, a quick fsck, and setting 
kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without 
errors and appears to be working normally.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Heads up

[Warren Block]

On Thu, 14 Apr 2016, Warner Losh wrote:


The CAM I/O scheduler has been committed to current. This work is described
in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on ada SSDs.
There are a few rogue drives that claim support for this feature, but
actually implement data corrupt instead of queued trims. The list of known
rogues is believed to be complete, but some caution is in order.


Is the list of drives queryable?  Is there an easy way to tell if the 
currently-connected drives are on the list?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

D3702: add support for Bluetooth Magic Mouse

[Warren Block]

Is anyone working on Bluetooth stuff?  https://reviews.freebsd.org/D3702 
adds support for the Apple Magic Mouse, and has been tested and reported 
working: 
https://lists.freebsd.org/pipermail/freebsd-bluetooth/2016-April/002053.html


Could someone please review and commit this?  Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need some help with ports and rebuilding the world

[Warren Block]

On Wed, 30 Mar 2016, Aleksander Alekseev wrote:


CPUTYPE?=native
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe



These will bite with no provocation, and prevent ports that want to
set their own flags from using them.


Frankly as a rule of thumb I prefer binary packages. But how would you
recommend to change these lines? You see if I use ports I would like
compiled code to be optimized and preferably for local CPU.


Don't set them at all, just remove those lines from make.conf.  Well, 
let me be more specific.  It is probably safe to set CPUTYPE, although 
choosing native has caused problems for me, where specifically setting a 
type like core-avx2 has been fine.


It is just the CFLAGS and CXXFLAGS that are best not set.  When not set, 
the world and kernel build will use safe defaults, but ports that can 
safely override those flags for better performance can do so.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need some help with ports and rebuilding the world

[Warren Block]

On Tue, 29 Mar 2016, Aleksander Alekseev wrote:


Do you still have your old make.conf for comparison?


Sure. Current make.conf:

```
CPUTYPE?=native
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe


These will bite with no provocation, and prevent ports that want to set 
their own flags from using them.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Need some help with ports and rebuilding the world

[Warren Block]

On Mon, 28 Mar 2016, Aleksander Alekseev wrote:


I think I realized what's going on. I probably rebuilded the world on
two different machines but forgot to do it on this one. I will
re-check this and report results a bit later.


OK, here is a problem. I can't upgrade the world because of compile
errors I mentioned before:

http://lpaste.net/948188758727983104

This issue reproduces with both CLang 3.6 and new CLang compiled
manually from trunk (I created symlinks clang++-3.9 and clang-cpp-3.9
to clang-3.9 and it solved my problem with CLang I mentioned before).


Did you erase /usr/src before checking out -CURRENT?  Obsolete files 
left in there can easily break things.  'svn stat /usr/src' will show 
those files with a '?'.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: question on support processor Intel Atom Z3735F

[Warren Block]

On Fri, 25 Mar 2016, Lundberg, Johannes wrote:


One problem is that most of these devices have only 32 bit UEFI which
FreeBSD does not support (except Intel Compute Stick which has 64 bit UEFI).


The MinnowBoard has both 32-bit and 64-bit UEFI.  My Turbot came with 
64-bit UEFI, and the FreeBSD amd64 UEFI install image works fine with 
it.  This is an Atom E3826 board.



I use special built Grub to boot a 64 bit Arch Linux on this chip, maybe
same approach could be used to boot a 64 bit FreeBSD. However, you probably
won't be able to use the internal eMMC (if your device got it) since the
controller can not initiate mmc memory correctly. Work in progress here
though by me and Ilya.

On a side note,
it would though be nice to have 32 bit UEFI support on FreeBSD because that
would include support for Intel IoT boards like Galileo etc which are all
32 bit. Might be a lot of work though..


If any existing 32-bit Linux UEFI loader could be made to work with 
FreeBSD (possibly chainloading?), that would be better than nothing.  I 
would like to have the opposite method also, having a 64-bit UEFI boot a 
32-bit FreeBSD.  (Why?  So my run-on-anything 32-bit FreeBSD image could 
still work on any UEFI system.)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loaders got fatter in the last few days

[Warren Block]

On Fri, 18 Mar 2016, Guido Falsi wrote:


On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision=296963



I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.


I have always recommended using the largest possible size for the 
bootcode partition, 512K.  There is no reason to go with a smaller size, 
the space savings are insignificant.  It is safe to guess that bootcode 
will never get smaller.


I also recommend starting the first real partition at 1M.  This also is 
frequently ignored.


Here are my instructions:

http://www.wonkity.com/~wblock/docs/html/disksetup.html

The wiki should be updated.  Better yet, that section should be removed 
and the corrected procedure shown in the Handbook.



Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Warren Block]

On Sun, 6 Mar 2016, Glen Barber wrote:


On Sun, Mar 06, 2016 at 12:39:57PM +0100, Baptiste Daroussin wrote:

On Thu, Mar 03, 2016 at 10:27:00AM +, Matthew Seaman wrote:

On 03/02/16 23:54, Glen Barber wrote:

Also note (as repeated below), running 'pkg delete -a' will implicitly
remove base system packages after they are installed.


This has the potential for many feet to be shot, given that up to now,
'pkg delete -a' would always leave you with a viable system.

We already make an exception for pkg itself -- you need 'pkg delete -fa'
to actually remove pkg(8) as well.  (Note to self: this needs to be
documented in the pkg-delete(8) man page.)

We should have similar exceptions for the essential bits of the base
system -- at minimum everything you need to boot the system up and
install stuff from a package repository.

We should also have a command line that will remove all ported software
but leave the base intact.   Maybe by adding '-r reponame' functionality
to 'pkg delete'?



It is planned to have a "precious" flag for packages which will prevent pkg
delete -a from dropping them



Note, there are valid use cases for deleting all packages, even those
marked as 'precious'.  For example, a test chroot(8) or jail(8).  So the
'precious' flag would also need an override.


# pkg delete -f --delete-my-precious-yes-i-know-just-do-it-already -a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CVE-2015-7547: critical bug in libc

[Warren Block]

On Thu, 18 Feb 2016, Kubilay Kocak wrote:


On 18/02/2016 3:51 AM, Warren Block wrote:

On Wed, 17 Feb 2016, Eric van Gyzen wrote:


On 02/17/2016 08:19, Warren Block wrote:

On Wed, 17 Feb 2016, Kurt Jaeger wrote:


A short note on the www.freebsd.org website would probably be helpful,
as this case will produce a lot of noise.


Maybe a short article like we did for leap seconds?
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html




Articles are permanent, which makes sense for the recurring issue of
leap seconds.  This vulnerability is transient, so I would suggest a
news item.


Yes, but news items are usually just links.  For the amount of
information we have so far, an article seems like the easiest way to do
this.  Or maybe an addition to the security part of the web site?

For now, I'll collect the information as just text.


Don't we also want our sec teams to investigate/confirm it anyway,
independent of how it's communicated?


Absolutely.


If so, doesn't a security advisory (with secteam and/or ports-secteam as
appropriate) make the most sense here, given the scope of vulnerability
for base/linux emulation/ports is yet to be completely established and
is still to be investigated properly?


Have there been security advisories for unconfirmed or 
not-actually-a-problem events before?  My impression was that they have 
only been announced when a problem exists and action needs to be taken.


However, a real problem *does* exist for Linux VMs and applications on 
FreeBSD, so it could be addressed that way.  A "we are investigating" 
advisory right now could do some good, if the protocols allow it.



Finally, would users expect a news item, an article or a heads up from
our security teams for something like this, even in the case where it's
only a "confirmed we're not affected" ?


A news item linking to a "it's not us!" advisory would be no problem. 
People have to go looking for that.


Those who are subscribed to the security mailing list will receive those 
notices directly, and because those are expected to be problems that 
need to be addressed immediately, it might cause some initial 
palpitations as if it were an actual problem with FreeBSD.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CVE-2015-7547: critical bug in libc

[Warren Block]

On Wed, 17 Feb 2016, Eric van Gyzen wrote:


On 02/17/2016 08:19, Warren Block wrote:

On Wed, 17 Feb 2016, Kurt Jaeger wrote:


A short note on the www.freebsd.org website would probably be helpful,
as this case will produce a lot of noise.


Maybe a short article like we did for leap seconds?
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html



Articles are permanent, which makes sense for the recurring issue of
leap seconds.  This vulnerability is transient, so I would suggest a
news item.


Yes, but news items are usually just links.  For the amount of 
information we have so far, an article seems like the easiest way to do 
this.  Or maybe an addition to the security part of the web site?


For now, I'll collect the information as just text.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CVE-2015-7547: critical bug in libc

[Warren Block]

On Wed, 17 Feb 2016, Kurt Jaeger wrote:


Hi!


The project that's vulnerable is called "glibc", not "libc". The BSDs
don't use glibc, so the phrase "nothing to see here" applies. glibc
isn't even available in FreeBSD's ports tree.

TL;DR: FreeBSD is not affected by CVE-2015-7547.


What about software that uses emulators/linux_base?


A short note on the www.freebsd.org website would probably be helpful,
as this case will produce a lot of noise.


Maybe a short article like we did for leap seconds?
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html

I can help with that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Aw: Re: No X on Dell E6540

[Warren Block]

On Tue, 15 Dec 2015, Carsten Kunze wrote:


Hello Michael,


It looks like that is a machine with Haswell integrated graphics.
Haswell graphics has not yet landed in CURRENT but there is a
development branch availible for testing.

https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20L
inux%203.8


there is also an additional AMD graphics card in this laptop (AMD Radeon HD 
8790M).  Is this supported by CURRENT?


The vesa driver can be run on most systems where the newer graphics are 
not directly supported.  See the last example here:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html#x-config-video-cards-file
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Warren Block]

On Mon, 19 Oct 2015, John-Mark Gurney wrote:


Ed Maste wrote this message on Mon, Oct 19, 2015 at 17:13 -0400:

On 19 October 2015 at 16:50, John-Mark Gurney  wrote:

O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200:

For me, I'd like to know what is the benefit/performance of each technique and
a clear preparation of each ones advantages over the other. That would make the
decission process much easier and hopefully would not scare people away and
announce "FreeBSD does not have a, b, c, ..." ...


So, one thing that the docs talk about is that geli uses the crypto(9)
framework.  This doesn't mean much on it's own, but if you have a machine
with AES-NI instructions or an accelerator card that supports the cipher
mode used, then you can get faster performance of hardware off load,
while gbde uses the software only routines which are slow..


John-Mark, thanks for listing these differences. This is the sort of
information we should have available for end users to help choose one
or the other -- this info ought to make it into the handbook.


I'm working on updating the section now...

Also realized we should include verbage to say that it's best to use
page size sectors when possible to reduce overhead of the crypto...


I can help with markup and editing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] Buildworld ccache support

[Warren Block]

On Thu, 15 Oct 2015, Bryan Drewery wrote:


Hi,

If you are interested in using ccache in buildworld please consider
using this patch locally and giving me some feedback.  The current
advice for ccache+buildworld (the CC:= trick in make.conf) actually
results in the build thinking you are using a cross-compiler which
results in unintended side-effects.  It also doesn't work with meta mode
as it handles CC and toolchain differently.  This patch intends to cover
all cases.

https://people.freebsd.org/~bdrewery/patches/world-ccache.diff

To use just set WITH_CCACHE_BUILD= in src.conf or make.conf.  I
purposely matched it to the same as the ports build.


Will this work on -stable?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: em broken on current amd64

[Warren Block]

On Sat, 12 Sep 2015, Mark R V Murray wrote:


I just caught this, on today’s build:

em0: Watchdog timeout Queue[0]-- resetting
Interface is RUNNING and ACTIVE
em0: TX Queue 0 --
em0: hw tdh = 127, hw tdt = 139
em0: Tx Queue Status = -2147483648
em0: TX descriptors avail = 1012
em0: Tx Descriptors avail failure = 0
em0: RX Queue 0 --
em0: hw rdh = 0, hw rdt = 1023
em0: RX discarded packets = 0
em0: RX Next to Check = 0
em0: RX Next to Refresh = 1023

[graveyard] /usr/ports 09:42 pm # uname -a
FreeBSD graveyard.grondar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287705: Sat 
Sep 12 15:07:54 BST 2015 
r...@graveyard.grondar.org:/b/obj/usr/src/sys/G_AMD64_GATE  amd64


That happened on an amd64 10-STABLE (r287148) system here a couple of 
days ago.  Both I217-V and 82574L cards in that system, but I did not 
save the message and can't say which had the error.  Never seen before, 
has not happened again.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ramblings.. or not

[Warren Block]

On Fri, 28 Aug 2015, Lars Engels wrote:


On Thu, Aug 27, 2015 at 02:31:21PM -0700, Craig Rodrigues wrote:

On Wed, Aug 26, 2015 at 8:44 PM, Julian Elischer jul...@freebsd.org wrote:


We should also do a better job of productising and incorporating GSOC
work..



Definitely!  It's sad to see people put a lot of working into something via
GSOC,
and then have the work die on the vine once the summer is over.


There's a lack of communication. Every year we have GSOC students
working on a part of FreeBSD, but after GSOC is over nothing happens.
Some code goes into base quietly, some good code may be lurking in an
external repository but nobody knows.
My proposal is that every student and mentor should write a short
summary of the work done and if was already committed to the tree or why
it hasn't been committed.


That is an excellent idea.  Isn't something like that already submitted 
to Google at the end of the project?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Call for FreeBSD 2015Q2 (April-June) Status Reports

[Warren Block]

Have you submitted your quarterly report yet?  People need to know about 
the cool things being done with, or to, or by FreeBSD.


In an effort that will surely never come back to haunt us all, I have 
committed all the reports I saw in monthly@ to the upcoming status 
report.  However, I am also easily distracted by shiny objects and might 
have missed some.


If you have not yet received a passive-aggressive thanks mail, please 
make sure your report is included here: 
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml?view=markup


If your report is missing or not present, please resubmit to 
b...@freebsd.org, mont...@freebsd.org, and cc me at wbl...@freebsd.org.


The deadline is July 14 (yes, today), but of course some of us would 
rather wait than miss interesting reports.  Or dull ones, to be honest. 
But there is an interesting report lurking inside even the dull ones. 
Particularly if some words are replaced with others.


Assistance in polishing a bare list of feats into a truly Herculean 
accomplishment can be provided on a limited-time, first-come 
first-serve, contents may have settled during shipment basis.


Grammer can be goodered and Englished up, too.

On Wed, 8 Jul 2015, Benjamin Kaduk wrote:


Dear FreeBSD Community,

Only one week remains before the deadline to submit entries for the next
FreeBSD Quarterly Status update -- the deadline is July 14, 2015, for work
done in April through June.

Status report submissions do not have to be very long.  They may be
about anything happening in the FreeBSD project and community, and
provide a great way to inform FreeBSD users and developers about what
you're working on.  Submission of reports is not restricted to
committers.  Anyone doing anything interesting and FreeBSD-related
can -- and should -- write one!

The preferred and easiest submission method is to use the XML
generator [1] with the results emailed to the status report team at
monthly at freebsd.org .  There is also an XML template [2] which can be
filled out manually and attached if preferred.  For the expected
content and style, please study our guidelines on how to write a good
status report [3].  You can also review previous issues [4][5] for
ideas on the style and format.

We are looking forward to all of your 2015Q2 reports!

Thanks,
Ben (on behalf of monthly@)


[1] http://www.freebsd.org/cgi/monthly.cgi
[2] http://www.freebsd.org/news/status/report-sample.xml
[3] http://www.freebsd.org/news/status/howto.html
[4] http://www.freebsd.org/news/status/report-2014-10-2014-12.html
[5] http://www.freebsd.org/news/status/report-2015-01-2015-03.html



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Adrian Chadd wrote:


But the problem here is that we're using GPT but /not/ UEFI, right?
That's why that's all a mess?


If you have a GPT layout, but it boots on a BIOS machine, the missing 
active flag on a standards-correct PMBR partition usually does not keep 
it from booting.  Usually.


The Lenovo thing is just a bug, firmware that sees GPT and automatically 
assumes that a GPT disk has all the UEFI features (extra partitions and 
security and cryptography and all that).


That is wrong.  Lenovo can fix it, and there should be villagers with 
pitchforks at their gates politely requesting that they fix it for these 
still-broken models like they have for other models.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it 
is still supported.  That they've fixed the problem in other models 
shows they understand the issue.  So owners of those models should be 
bugging Lenovo, so to speak.


Long-term, it seems like they as a company would be concerned that 
special bug fixes naming their specific models are needed.


Short-term, we probably can't avoid this.  It would be nice to be able 
to remove a Lenovo-specific hack from gpart in the future with a commit 
that says Fixed by Lenovo BIOS update #123, no longer needed.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken 
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term 
hack.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 14:08, Warren Block wrote:

On Mon, 13 Jul 2015, Allan Jude wrote:


On 2015-07-13 11:19, Warren Block wrote:


Needing the active flag set is indeed a different problem. I am working
on a patch for bsdinstall that will allow the user to request the
active
bit be set as well.


For GPT, that should be the default, because it matches the standard.

I would like to see an effort to get Lenovo to fix their broken
UEFI/BIOS.  Adding non-standard PMBR configurations should be short-term
hack.


Lenovo has fixed the issue in newer models, x230, t530, t540 etc work
fine.

Just the x220, t420, and t520 etc series do not.


The latest BIOS update for the x220 was less than two months ago, so it
is still supported.  That they've fixed the problem in other models
shows they understand the issue.  So owners of those models should be
bugging Lenovo, so to speak.

Long-term, it seems like they as a company would be concerned that
special bug fixes naming their specific models are needed.

Short-term, we probably can't avoid this.  It would be nice to be able
to remove a Lenovo-specific hack from gpart in the future with a commit
that says Fixed by Lenovo BIOS update #123, no longer needed.


I tried the latest bios update for the X220, from 2015-05-27

It does not resolve the issue.

Also, it required some hoop jumping, as they only provide a bootable cd 
(x220s do not have CD drives) and a windows program.


However, if others are interested, this handy perl script: 
http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/


can be used to extract the el torito image from that .iso to a file, that can 
then be dd'd to a USB stick and update the bios.


Sorry, I did not mean to imply that the latest X220 BIOS fixed the 
problem, just that they were continuing to release BIOS updates for it 
and could not disown responsibility by saying the system was no longer 
supported.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Kevin Oberman wrote:


This is possibly orthogonal and possibly not of use on X2nn systems, but I boot 
my T520 with a GPT formatted disk as the secondary drive by having the MBR 
disk0 configured with booteasy
and telling it to boot disk1. While this is of no use on single spindle systems 
like the X220, I have been told that a MBR USB drive can be used to do the same 
thing. I have not tried
this and can't confirm, though. Clearly a kludge work-around, but better than 
nothing and works well for me as I have always left Windows on the main drive 
and put FreeBSD on the
removable one.


Please, whoever has one of these systems, find a contact address for 
Lenovo.  It should be on every one of these messages, and we should be 
encouraging every affected user to contact Lenovo support.  I can post 
it in the forums, also.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lenovo BIOS boot fix

[Warren Block]

On Mon, 13 Jul 2015, Adrian Chadd wrote:


I'm really confused. Why is the active flag not set again?

I thought that was the whole point of the active flag in the partition table.


At one point, smart people explained this to me.  My fault if I do not 
remember it correctly (not that it will stop me from attempting an 
explanation):


MBR partitions have active flags.  The BIOS is supposed to boot from the 
one that is set active.  It is not required that one be set active, 
though.  Most BIOS systems will still boot without any MBR partitions 
set active, presumably from the first partition.


The PMBR on a GPT disk is a simulation of an MBR.  However, according to 
the GPT standard, that simulated first MBR partition in the PMBR must 
not be set active.  A strict UEFI implementation will *not* boot if 
there is an active flag set for a PMBR partition.


Earlier versions of the FreeBSD PMBR had the PMBR partition set active, 
which was wrong.  The current version is correct.


I'm fairly sure we've seen people with both problems on the mailing 
lists and in the forums: BIOS systems that would not boot without an MBR 
partition set active, and UEFI systems that would not boot when a PMBR 
partition was set active.  They are rare, but it goes to prove you can't 
win.


(To fix old, incorrect FreeBSD PMBR versions, gpart can be used to set 
the active property on the GPT disk itself, which clears an active 
flag set on a PMBR partition.  So the problem should already be fixed, 
but this is the set active we are talking about.)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Newer yacc needed for building world

[Warren Block]

On Wed, 22 Apr 2015, Willem Jan Withagen wrote:


Hi,

[I thought that I've seen talk about this before.]

On a customers system I'm trying to build a new world, with a fresh tree.
I've deleted lines from other tracks in parallel compilation.

--- aslcompilerparse.c ---
yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y
yacc: 89 shift/reduce conflicts.
yacc: f - maximum table size exceeded
*** [aslcompilerparse.c] Error code 2

And I do not find yacc in the tools/tmp tree.

So here the buildsystem is in a catch22. And perhaps yacc needs to be added 
to the buildtools?


Probably I can get out of this by first
cd /usr/src/usr.bin/yacc
make; make install


Yes:
https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: default pager (csh)

[Warren Block]

On Thu, 19 Feb 2015, Kevin Oberman wrote:


On Thu, Feb 19, 2015 at 5:10 PM, Warren Block wbl...@wonkity.com wrote:
  On Thu, 19 Feb 2015, Julian Elischer wrote:

On 2/18/15 3:41 PM, Xin Li wrote:

  The _only_ reason that I can think of is that more(1) does 
not clear
  screen for certain terminals (done with 'ti' and 'te' 
sequences),
  while less(1) when running as less does.

  The less(1) behavior can be annoying to some people 
(sometimes even
  myself when using less to show contents of a file and ^Z to 
paste
  them), and unfortunately quite a few of them also happen to 
be the
  more vocal ones when it comes to a change.


I find that behaviour infuriating

I page down to a place to get some text on the screen to use as  a 
reference, then exit to run a command with that information, and *bam* the info 
I wanted to
use has gone away.


  It doesn't do that on csh.  Or maybe I figured out how to prevent it long 
ago and forgot, but all I use is this:

  setenv  PAGER   less -RS


You probably did what I used to do. Modify the termcaps/terminfo to eliminate 
this behavior. See Exorcising the Evil Alternate Screen.

In the past, FreeBSD disabled this by default. It was changed several years 
ago, but you can change it back as per the aboved referenced article.


I'm pretty sure I have not done that, it would show up in mergemaster. 
As far as I can remember, less(1) has never done that clear-the-screen 
thing on FreeBSD, which is why it is so jarring on Linux.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: default pager (csh)

[Warren Block]

On Thu, 19 Feb 2015, Julian Elischer wrote:


On 2/18/15 3:41 PM, Xin Li wrote:


The _only_ reason that I can think of is that more(1) does not clear
screen for certain terminals (done with 'ti' and 'te' sequences),
while less(1) when running as less does.

The less(1) behavior can be annoying to some people (sometimes even
myself when using less to show contents of a file and ^Z to paste
them), and unfortunately quite a few of them also happen to be the
more vocal ones when it comes to a change.


I find that behaviour infuriating

I page down to a place to get some text on the screen to use as  a reference, 
then exit to run a command with that information, and *bam* the info I wanted 
to use has gone away.


It doesn't do that on csh.  Or maybe I figured out how to prevent it 
long ago and forgot, but all I use is this:


setenv  PAGER   less -RS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Acer C720 Chromebook (was: Re: looking for new netbook)

[Warren Block]

On Wed, 7 Jan 2015, Matthias Apitz wrote:


The keyboard of the C720, in principle a normal PC105, mine with German
layout QWERTZ, is a bit tricky: it has

- only F-keys from F1 to F10 and they are labeled with symbols for the
 ChromeOS applications;
- no hardware power-off (only by an ACPI key which is situated where F11
 would be, i.e. right above the Backspace key, you see the risk :-) )
- no Windows key which could be used as Modifier-key in X11;
- no PageUP/DOWN keys


Ouch.  But the older Acer netbooks used Fn+up/down, so probably 
something similar can be done.  Alt+up/down, maybe.


When researching this machine a couple of weeks back, I saw somewhere 
that it was based on a similar existing PC-compatible Acer model, V3 or 
V5 maybe, or the ES1 series (can't find the reference again, of course). 
But all of those with 11.6 displays look to have older or less powerful 
processors, typically the Celeron N2840.  The Celeron 2955 in the C720 
is about 50% faster.


The E3-111-P8DW has a faster CPU, but it is a third-generation N3530. 
Standard hard drive and socketed RAM, though.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [HEADSUP] man(1) now uses mandoc

[Warren Block]

On Sun, 23 Nov 2014, Baptiste Daroussin wrote:


The default renderer on HEAD has been switched to mandoc(1) by default
The man(1) command has been instrumented to first test the manpage and fallback
on groff if the man page cannot be rendered with mandoc(1).

If base is built without groff then man(1) recommands to install groff from
packages.

makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent.


Thanks and congratulations to all involved!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC] Moving troff only documentation to the doc repository

[Warren Block]

On Sun, 23 Nov 2014, Remko Lodder wrote:

On 23 Nov 2014, at 20:10, Baptiste Daroussin b...@freebsd.org wrote:

Hi all,

I would like to move the troff documentation which is not very useful anymore on
a recent FreeBSD system but still part of history into the doc repository, a
dedicated branch will probably fit (anyone has an idea for the name of the
branch?)

FYI the troff only docs concern:
share/docs/{papers,psd,smm,usd}

Anyone has a concern about that?



Not from me, I actually have never read the documentation.

How about doc-history, or something where we can archive documentation that has
high historic value?


There is the doc archive: https://docs.freebsd.org/doc/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: Enabling vt(4) by default

[Warren Block]

On Wed, 5 Nov 2014, Chris H wrote:

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com wrote


No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.


Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?


Or Intel, or anything with KMS drivers.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: Enabling vt(4) by default

[Warren Block]

On Wed, 5 Nov 2014, Chris H wrote:


On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wbl...@wonkity.com wrote


On Wed, 5 Nov 2014, Chris H wrote:

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn gljennj...@gmail.com
wrote 

No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.


Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?


Or Intel, or anything with KMS drivers.


Thanks. Everything I manage, is using nVidia. Looks like
the kms VESA might work. But I'm not sure if there would
be any appreciable gain going that route (assuming it's even
possible).


It's worth asking Nvidia directly.  I would not be optimistic about 
that, but it's easy to try, and they might surprise everyone.


Another option might be nouveau.  Don't know the current status of 
whether that works on FreeBSD, though.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: WiFi 802.11/ac PCIe supported adaptor

[Warren Block]

On Sun, 19 Oct 2014, O. Hartmann wrote:


Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:


On Sun, 28 Sep 2014, Gavin Atkinson wrote:

On Sun, 28 Sep 2014, O. Hartmann wrote:

Networking wasn't an issue for me for years, but now, sitting on a pile of neat 
new
hardware of which FreeBSD can not make any serious use, let me rethink. 
Luckily, The
Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs 
agony
I'm able to swap the NIC with a piece of hardware that is supported. But it is
additional


Unfortunately, many Lenovo laptops lock the BIOS down in such a way that
they won't boot without the NIC they were shipped with :(


Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't 
recognized, the crap
of Laptop rejects starting firmware and I get a message telling me using 
uncertified
hardware. Last time I bought a Laptop from Lenovo!



Well, or a short list of approved Lenovo-branded cards.  In the past,
Lenovo (or IBM) has supplied Atheros cards.  The trick will be finding
that list and identifying the chipsets on each.  There are also
unofficial BIOS modifications to remove the limits.


There are lists, but they are outdated and newer chipsets aren't listed.


No, I mean each particular Thinkpad notebook has a list of allowed cards 
in the BIOS.  However, it is not the same list for each model.  So the 
trick is to find the list of approved cards for your particular model, 
and then figure out which of those is Atheros-based.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: WiFi 802.11/ac PCIe supported adaptor

[Warren Block]

On Sun, 28 Sep 2014, Gavin Atkinson wrote:

On Sun, 28 Sep 2014, O. Hartmann wrote:

Networking wasn't an issue for me for years, but now, sitting on a pile of neat 
new
hardware of which FreeBSD can not make any serious use, let me rethink. 
Luckily, The
Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs 
agony I'm
able to swap the NIC with a piece of hardware that is supported. But it is 
additional


Unfortunately, many Lenovo laptops lock the BIOS down in such a way that
they won't boot without the NIC they were shipped with :(


Well, or a short list of approved Lenovo-branded cards.  In the past, 
Lenovo (or IBM) has supplied Atheros cards.  The trick will be finding 
that list and identifying the chipsets on each.  There are also 
unofficial BIOS modifications to remove the limits.



it is also due to a bad politics. nVidia, for instance, offers a BLOB for their 
GPUs.
Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts 
regarding
opensource drivers is a pity.


AMD has actually supported the open Radeon driver, both with programming 
information and (I think) employing developers to work on it.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: WiFi 802.11/ac PCIe supported adaptor

[Warren Block]

On Sat, 27 Sep 2014, O. Hartmann wrote:



I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to 
replace it
with an 802.11ac adaptor.

Since I made very bad experiences with CURRENT and support of modest modern 
hardware
(Haswell CPU/Intel  7260 DualBand WiFi NIC), I'd like to ask here first.

I found this PCIe adaptor card attractive:

GigaByte Gigabyte GC-WB867D-I

I can not find ad hoc the WLAN chip used on that specific card, but maybe 
someone has
experiences with that litte board.


Newegg reviews say this is an Intel 7260HMW:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813995032Tpk=N82E16813995032

I don't know if that is supported on FreeBSD yet.

PCIe to mini-PCIe adapters like that can be found separately, allowing 
the use of any mini-PCIe card.  I've successfully tested an Atheros 
AR9280 card in one.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

[Warren Block]

On Fri, 19 Sep 2014, O. Hartmann wrote:


nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 
11.0-CURRENT
#2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 
laptop with
CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia 
GT 740M
(Optimus) working correctly.


Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The 
extra GPU uses the same display memory and can be enabled to speed up 
the Intel graphics or disabled for power saving.  I don't know if 
versions where the Nvidia section is a full discrete video adapter that 
can be used alone are still called Optimus.


Some Optimus owners have reported being able to use the Intel drivers 
after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to 
disable the Nvidia GPU is not present, some people have reported success 
with an xorg.conf that uses only the intel driver and ignores the Nvidia 
hardware.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

[Warren Block]

On Sat, 20 Sep 2014, O. Hartmann wrote:


Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:


On Fri, 19 Sep 2014, O. Hartmann wrote:


nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD
11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo 
ThinkPad Edge
E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and
dedicated nVidia GT 740M (Optimus) working correctly.


Optimus is supposed to be full Intel graphics plus an Nvidia GPU.  The
extra GPU uses the same display memory and can be enabled to speed up
the Intel graphics or disabled for power saving.  I don't know if
versions where the Nvidia section is a full discrete video adapter that
can be used alone are still called Optimus.

Some Optimus owners have reported being able to use the Intel drivers
after disabling the Nvidia GPU in the BIOS or UEFI.  If an option to
disable the Nvidia GPU is not present, some people have reported success
with an xorg.conf that uses only the intel driver and ignores the Nvidia
hardware.


Thanks Warren.

But this sounds even more frustrating now. I look around the web even at 
Lenovo's support
forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with 
Optimus
technology and everything sounds to me like it can be selected exclusively. 
What you
describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the 
first place
since the nVidia hardware is a kind of appendix to the HD4600.


Optimus started out that way, but they might use the same name now for 
models where the additional GPU is a full discrete adapter.



Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work 
properly: it
doesn't even start up and loading the intel driver complains about a missing 
device -
preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, 
that this
HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: 
entry in
the kernel log when enabling Integrated Graphics only in the laptop's 
UEFI/Firmware.
When enabling nVidia Optimus, a recognized vga0: device shows up.


Whoops, HD4600 is Haswell.  The intel driver on FreeBSD does not support 
Haswell video yet.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

[Warren Block]

On Sat, 20 Sep 2014, O. Hartmann wrote:


The very same CURRENT (most recent as I built world on all system today) doesn't
recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me 
that
people can report having this GPU working if even the most recent FreeBSD 
CURRENT
doesn't recognize it.


Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: 
device in
the pciconf-listing (it is very early and I stoped looking at the very end ...).


At this point, it's worth trying the vesa driver, which should work on 
Haswell.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: did tar(1) loose xz compression support in 11?

[Warren Block]

On Tue, 26 Aug 2014, Daniel Eischen wrote:


On Tue, 26 Aug 2014, Tim Kientzle wrote:


On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote:


Greetings,
I'm currently testing 11. My build / install is from about 2 days ago.
I generally use xz compression, when creating archives. But when I
attempt the following:

tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file

it returns the following:

tar: Undefined option: `xz:9'

This has always worked in previous versions. Has the syntax changed,
and the man(1) pages just haven't caught up?


I can?t see any evidence in libarchive?s source that this ever worked.


The man page is a little confusing.  Here it says:

 --options options
 Select optional behaviors for particular modules.  The
 argument is a text string containing comma-separated
 keywords and values. These are passed to the modules that
 handle particular formats to control how those formats will
 behave.  Each option has one of the following forms:

 key=value
 The key will be set to the specified value in every
 module that supports it.  Modules that do not
 support this key will ignore it.


Then below, after the last option, it says:

 ...
 zip:compression=type
 Use type as compression method.  Supported values are
 store (uncompressed) and deflate (gzip algorithm).

 If a provided option is not supported by any module, that is a
 fatal error.

The first states that it is ignored, the latter states that it
is a fatal error.  The meaning of any module is subtle, at
least for my feeble brain ;-)


It suggests that options are passed to all modules, and each module is 
free to ignore options it does not understand.  But at least one module 
must understand the option, or a fatal error is reported.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: How to get a mouse in vt(4) -- NEWCONS

[Warren Block]

On Mon, 25 Aug 2014, Chris H wrote:

I also read that hw.vga.textmode is available. However sysctl 
hw.vga.textmode returns unknown oid.


It is a boot-time-only setting for loader.conf.

  hw.vga.textmode=1

boots in text mode.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: No bootable device

[Warren Block]

On Sun, 10 Aug 2014, Eric L. Camachat wrote:



/usr/local/libexec/ppf_verify: pgp command failed

gpg: Signature made Sun Aug 10 16:49:09 2014 MDT
gpg:using DSA key 0x49F050BB7A0EC18C
gpg: Can't check signature: No public key


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/09/2014 10:32, Mehmet Erol Sanliturk wrote:


the installed systems are not bootable , and the last sentence on the
screen is the following :


No bootable device -- insert boot disk and press any key



If you installed into GPT partitions like this:
$ gpart show ada0
=   34  488397101  ada0  GPT  (233G)
34   1038 1  freebsd-boot  (519K)
  1072  455081984 2  freebsd-ufs  (217G)
 455083056   33314079 3  freebsd-swap  (16G)

Try to make GPT in MBR as bootable (active) partition:
$ fdisk -s /dev/ada0
/dev/ada0: 484521 cyl 16 hd 63 sec
PartStartSize Type Flags
  1:   1   488397167 0xee 0x80
$ fdisk -p /dev/ada0
# /dev/ada0
g c484521 h16 s63
p 1 0xee 1 488397167
a 1

This is an known issue on HP laptops.


The simpler version is
  gpart set -a active ada0

There are multiple possible issues.  This one is due to strict 
compliance with the GPT standard.


Another problem is when a BIOS system does weird things based on an MBR
partition type.  Some Lenovo systems do that.  When that is the problem, 
using MBR partitioning rather than the PMBR from GPT can work.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

[Warren Block]

On Fri, 25 Jul 2014, Craig Rodrigues wrote:


What I'd like to see is an article on freebsd.org either on the wiki
or in the handbook, which compares using apt, yum, rpm, whatever
to pkg.  Is anyone interested in working on an article like this?
I don't have the bandwidth right now.


A person to write that article needs detailed knowledge of pkg and the 
Linux package systems.  I don't have that, but would be willing to help 
you develop an outline for the article.  Having a design like that makes 
it easier to write when time and resources are available.


Writing an article is hard.  Writing a small section on how deleting 
packages is different between pkg and, say, apt, is much easier.  The 
scope is known.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

[Warren Block]

On Fri, 25 Jul 2014, Craig Rodrigues wrote:





On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman 
woll...@hergotha.csail.mit.edu wrote:
  In article alpine.bsf.2.11.1407251459370.72...@wonkity.com you write:

  Writing an article is hard.  Writing a small section on how deleting
  packages is different between pkg and, say, apt, is much easier.  The
  scope is known.

Indeed, it's pretty trivial.

I think the sort of article Craig was looking for was more on the
order of

        apt command             pkg command
        apt-get update          pkg update (*1)
        ...                     ...

(*1) Explanation of differences between how apt behaves and how pkg
behaves.

The set of common apt operations is pretty well-known, and most of
them have direct pkg(8) equivalents.



Garrett is describing exactly what I am looking for.

I'm not looking for a complicated article explaining the internal
differences between apt and pkg.  Very few people have the
interest or patience to read that.

Providing a simple table contrasting the basic apt/yum/rpm/pkg commands
for installing/upgrading/deleting packages is mostly what is needed.


This gave me a flashback to the last time somebody said Oh, I just want 
a simple little program. :)



We need to show people that installing packages on FreeBSD is
not like the bad old pkg_add days which people have bad memories of.  We need 
to show that pkg is as good as what people are used to on modern Linux
distributions.


The wiki should be ideal for this.  Start a table, fill in what you can, 
and others can fill in the other parts.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Boot loader too large

[Warren Block]

On Fri, 11 Jul 2014, Benjamin Kaduk wrote:


On Fri, Jul 4, 2014 at 7:07 AM, Alie Tan a...@afflemedialab.com wrote:


On Fri, Jul 4, 2014 at 5:57 PM, Alie Tan a...@afflemedialab.com wrote:


Hi,

I am getting Boot loader too large message while using
FreeBSD-11.0-CURRENT-i386-20140701-r268111-disc1.iso

Is there any way to solve this issue?


Strange, resizing the freebsd-boot to 128k solved my issue. why default
slice size making such issue?



Resizing to 128k from what value?

I seem to recall that having larger freebsd-boot partitions caused problems.


Up to 512K is okay, but larger than that is a problem for the bootcode. 
I suggest always using 512K, it's not like using less saves an 
appreciable amount of space.  And bootcode grows sometimes.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: freebsd and utf-8 directory names

[Warren Block]

On Tue, 1 Jul 2014, d...@gmx.com wrote:

In other words, You, the general user, should learn the art of operating 
system development (on your own) for the sole purpose of being able to fix 
the bug yourself.


It's one approach to solving a technical problem, but not the only one. 
You can fix it yourself, possibly involving a lot of learning.  Or you 
can ask, encourage, or even pay others to fix it.


This should all start with a bug report to make sure the problem is 
documented.  If people already know there are bugs in the msdosfs code, 
those same people should be able to supply details to fill out the bug 
report.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gpart(8) man page missing list documentation

[Warren Block]

On Tue, 1 Jul 2014, Chris Ross wrote:



 Looking at the man page for gpart(8) on a recent 10-stable system, I was 
trying to find out what the -a option to list does.  (shown in the output of 
gpart when run with no parameters).  Interestingly, despite ?list? being 
highlighted in paragraph text as an action for the command, it does not appear 
in the summary at the top of the page, nor in the detailed DESCRIPTION section 
that describes each of the actions.

 This appears to still be the case on HEAD, as well.  I assume this is worth 
fixing and MFC?ing?


A PR was just entered for that: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191534


list and status and a couple of others that only apply for some GEOM 
modules (load, unload) are part of the base GEOM command set.  I was 
going to say we should just refer the reader to another page, maybe 
geom(8).


But gmirror(8) does include those commands in the synopsis.  We should 
be consistent with this, and I'd lean toward doing it the way gmirror(8) 
does now.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Turning TESTS on by default

[Warren Block]

On Sun, 8 Jun 2014, Julio Merino wrote:


On Fri, Jun 6, 2014 at 11:33 PM, Konstantin Belousov
kostik...@gmail.com wrote:

It is the same as the debugging kernel. The INVARIANTS, WITNESS, DEBUG
and DIAGNOSTIC options are not enabled for the user consumption.


No; this is not the same at all. All the options you mention introduce
a performance penalty on the system at *run* time and the _only_ way
to get rid of such penalty completely is to disable the options at
*build* time (sysctl doesn't make the cut because the system would
still need to check a boolean value). Because these toggles affect
run-time performance, and because they are intended for developers
only, they are not the default on release builds.

Building the test suite has no impact whatsoever on the system at
run-time. The test suite is just a bunch of files in a self-contained
location. We ought to ship such files as tests.tgz to give users a
very easy way of not installing them though.


How much of an impact does the test suite have in terms of disk space 
(probably not much) and buildworld time (possibly not much, either)?


Users being able to report the results of tests could demystify a lot of 
bug reports.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: diskid documentation

[Warren Block]

On Mon, 2 Jun 2014, Michael W. Lucas wrote:


On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote:

On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote:

It also tends to sometimes hide the gpt label provider on me (not sure
in which cases it does this, but it is annoying)


This happens when something (e.g. zfs) happens to open the diskid
provider instead of the gpt label.  For me this ended up being a bit
more than annoying; my swap was mounted in /etc/fstab via a gpt label
so I silently lost my swap when I did an upgrade.


Wait-- one type of one label can hide another?

I thought a big point of labels was to remove ambiguity...


Can't get more unambiguous than only having one label!

The word to look for here is wither.  When a device label name is 
opened exclusively (like mounting a device), other labels for that 
device are supposed to wither and disappear from view.


(My understanding of this is incomplete.  Garrett Wollman sent me a very 
nice explanation of how this works, which I have read but not enough 
times yet.)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Hello fdclose

[Warren Block]

On Thu, 20 Mar 2014, Dag-Erling Smørgrav wrote:


Warren Block wbl...@wonkity.com writes:

John Baldwin j...@freebsd.org writes:

Warren Block wbl...@wonkity.com writes:

.Fn fdclose
is equivalent to
.Fn fclose ,
but the file descriptor is returned rather than closed.

Yes, but this has the 'no capital letter at the start of a sentence'
problem.

I've heard that mentioned before, but have never seen any actual rule
regarding it.  And we do have actual rules about avoiding redundant
phrases:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines


We always use

The
.Nm foo
utility

or

The
.Fn foo
function

instead of just .Nm or .Fn at the start of a sentence, but never (or
rarely) within a sentence.


By we, do you mean the FreeBSD project or your local organization?  Is 
there a specific reason the redundant wording, or is it just customary?


I suspect that usage is similar to that for an acronym, defining it on 
the first usage but only then.  Both mdoc and DocBook markup should 
accomplish the same thing.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Hello fdclose

[Warren Block]

On Fri, 21 Mar 2014, Dag-Erling Smørgrav wrote:


Warren Block wbl...@wonkity.com writes:

Dag-Erling Smørgrav d...@des.no writes:

We always use [The .Nm foo utility or The .Fn foo function] instead
of just .Nm or .Fn at the start of a sentence, but never (or rarely)
within a sentence.

By we, do you mean the FreeBSD project or your local organization?
Is there a specific reason the redundant wording, or is it just
customary?


I mean the FreeBSD project, and the reason is as John stated: all
sentences must start with a capital letter.  I've gotten so used to this
over the past 15 years that I even do it in email and other non-FreeBSD
written material.

DES


Because it's been that way for 15 years is not always a justification 
(consider BIND in base, for example :).


I'll let this drop for now, but still find it interesting that it is not 
mentioned in the FDP Primer, and those style guide rules date back at 
least 15 years.  It may be that the original doc project members felt 
that capitalizing the first word of a sentence was so obvious that it 
did not need to be stated.  Or possibly, that it was a rule that could 
be usefully broken at times.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Hello fdclose

[Warren Block]

On Wed, 19 Mar 2014, John Baldwin wrote:


On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote:

On Tue, 18 Mar 2014, John Baldwin wrote:


On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote:

Hi,

After our previous discuss  [1] I prepare fdclosedir(3) function which
was committed by Pawel (cc'ed) in commit r254499.

A while ago I also prepare the fdclose function. Unfortunately, this
new function is a little bit more tricky then previous one. Can I ask
you for a review of this patch?


I think the code is fine.  I have a few suggestions on the manpage wording:

The
+.Fn fdclose
+function is equivalent to the
+.Fn fclose
+function except that this function returns file descriptor instead of
+closing it.
+.Pp
+The

I would move fdclose() to its own paragraph and reword this sentence as:

 The fdclose() function is equivalent to fclose() except that it does
  not close the underlying file descriptor.


.Fn fdclose
is equivalent to
.Fn fclose ,
but the file descriptor is returned rather than closed.

Likewise in other sections, the markup is supposed to do the job of
pointing out that something is a function.


Yes, but this has the 'no capital letter at the start of a sentence' problem.


I've heard that mentioned before, but have never seen any actual rule 
regarding it.  And we do have actual rules about avoiding redundant 
phrases: 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines


While normal words should be capitalized as the first word in a 
sentence, special words that are case-sensitive override that (IMO).



Also, I do think reusing the 'underlying file descriptor' language is important
in the context of the earlier description of fclose().


Sorry, a problem with my micro-optimization:

.Fn fdclose
is equivalent to
.Fn fclose ,
but does not close the underlying file descriptor.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Hello fdclose

[Warren Block]

On Tue, 18 Mar 2014, John Baldwin wrote:


On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote:

Hi,

After our previous discuss  [1] I prepare fdclosedir(3) function which
was committed by Pawel (cc'ed) in commit r254499.

A while ago I also prepare the fdclose function. Unfortunately, this
new function is a little bit more tricky then previous one. Can I ask
you for a review of this patch?


I think the code is fine.  I have a few suggestions on the manpage wording:

The
+.Fn fdclose
+function is equivalent to the
+.Fn fclose
+function except that this function returns file descriptor instead of
+closing it.
+.Pp
+The

I would move fdclose() to its own paragraph and reword this sentence as:

 The fdclose() function is equivalent to fclose() except that it does
  not close the underlying file descriptor.


.Fn fdclose
is equivalent to
.Fn fclose ,
but the file descriptor is returned rather than closed.

Likewise in other sections, the markup is supposed to do the job of 
pointing out that something is a function.


textproc/igor can identify some problems with wording.  It also checks 
for rudimentary mdoc(7) requirements.


If desired, I'm willing to edit this man page.  (I've learned far too 
recently that most people do not want to be consulted on wording, they 
just want it fixed.  That's now the approach I take: make all the 
corrections and return it, rather than a back-and-forth with the danger 
of edit fatigue.)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: zfs boot manual pages

[Warren Block]

On Tue, 4 Feb 2014, Scot Hetzel wrote:


On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon a...@freebsd.org wrote:


I've started working on manual pages for the zfs boot chain.

Please [p]review my work in progress here:
https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages

Any additions, corrections, suggestions and other kinds of reviewing are
welcome.  Patches and pull requests are very welcome!

Many thanks to Warren Block for the initial review and many fixes.


One fix for the gptzfsboot man page would be to mention that
gptzfsboot is installed into a GPT partition of type freebsd-boot, and
that the -i 1 refers to the GPT index for this partition.


We are missing that from the gptboot.8 page also.

  gptzfsboot is installed in a freebsd-boot partition, usually the
  first partition on the disk.  A ``protective MBR'' (see gpart(8)) is
  typically used in combination with gptzfsboot.

  To install gptzfsboot on the ada0 drive:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

[Warren Block]

On Thu, 23 Jan 2014, Jakub Lach wrote:


I plan to stay some time on 9.2-STABLE (already pkgng and clangfied) waiting
maybe till next release from 10-STABLE tree, however 10-STABLE will be where
I will be eventually heading, so notes in this spirit are valuable reminders
at least, I appreciate it.


My experiences converting a couple of systems from 9-STABLE to 10-STABLE 
over the last couple of months were really pretty easy.  These were 
source updates for both base and ports.  Despite changing from pkg_* to 
pkg and KMS X drivers at the same time, it was surprisingly smooth.


If you have devel/ccache installed, remove it before starting, though, 
it has problems with clang.  Using -DNOCLEAN with an existing /usr/obj 
can go even faster than ccache: less than two minutes for a buildworld 
on my frequently updated i5/SSD system, sometimes less than one minute.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.

[Warren Block]

On Thu, 23 Jan 2014, Kevin Oberman wrote:


On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann trh...@gmail.com wrote:
  On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wbl...@wonkity.com wrote:
  
  
   Using -DNOCLEAN with an existing /usr/obj can go even faster than 
ccache:
   less than two minutes for a buildworld on my frequently updated i5/SSD
   system, sometimes less than one minute.


Can you elaborate on this, please? I always clear my /usr/obj before
starting a buildworld, which takes 2 hours to run on my system. Are you
saying if I do make -DNOCLEAN buildworld I do not have to clear /usr/obj
first


Yes.  Removing /usr/obj is a faster way of doing 'make clean', mostly.


AND my buildworld will run faster


Yes, because make will see that many/most files have already been built.


(AND with no downside)?


Well... mostly.  :)

I noticed that after 10.0-RELEASE, uname on my system still said 
PRERELEASE.  That code had not been rebuilt because make did not see 
it as needing a rebuild.  You can still delete /usr/obj and run a full 
buildworld from scratch every so often.


I should give credit to bdrewery@ for reminding me about -DNOCLEAN when 
I was whining about ccache not working on 10.0.  It turned out to be a 
better solution.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Intel graphics driver broken on 10-RC5

[Warren Block]

On Thu, 9 Jan 2014, David Chisnall wrote:


Hi Johannes,

Are you using the packaged Xorg in both cases?  Currently, the default for 10 
is the old (pre-KMS) X.org and the default for 11 (HEAD) is the newer 
(post-KMS) one.  If you're using the default one, would you mind trying the new 
one?  You can build it from ports by putting this in your make.conf:

WITH_NEW_XORG=yes
WITH_GALLIUM=yes

I'm currently running it with AMD graphics on 10-RC4 and finding it works a lot 
better than the older version, and we're considering enabling it for the 
10.0-RELEASE.  The down side is that, without newcons, you lose working VTs 
after X has started.


The wiki now has the update procedure:
https://wiki.freebsd.org/Graphics#Installing_KMS_Ports

This will work either to update an already-installed X, or to install it 
from scratch (just install x11/xorg afterwards).  It has been tested on 
9.2 and 10-STABLE.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD 10.0-RC3 Now Available

[Warren Block]

On Fri, 27 Dec 2013, Mathieu Arnold wrote:


+--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann trh...@gmail.com
wrote:
| All the examples I've seen for updating bootcode assume GPT. If one has
| MBR (as I do) and assuming the following basic scheme:
|
| gpart show ada0
| =   63  976773105  ada0  MBR  (466G)
|  63  976773105 1  freebsd  [active]  (466G)
|
| gpart show ada0s1
| =0  976773105  ada0s1  BSD  (466G)
|   0  943218736   1  freebsd-zfs  (450G)
|   943218736   33554369   2  freebsd-swap  (16G)
|
| would the equivalent bootcode statement be:
|
| gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1


No, the PMBR is for GPT partitioning only.


| where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and
| ada0s1 is the slice on which FreeBSD is installed?

Hum, no, if you're using MBR and not GPT, you can't use gpart,


Why not?  gpart is not GPT-specific.  It handles MBR and BSDlabel 
bootcode correctly.



you have to
do something aweful like this :
# dd if=/boot/zfsboot of=/dev/ada0 count=1


That will overwrite the MBR partition table.


# sysctl kern.geom.debugflags=0x10
# dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024


That seems dangerous.  I have not tried with zfsboot, but this should be 
close:


  # gpart bootcode -b /boot/zfsboot ada0
  # gpart bootcode -b /boot/zfsboot ada0s1

Untested!  The first one may need to use /boot/mbr.  A better way to do 
this, provided the system does not have a broken BIOS, would be to 
backup, repartition with GPT, and restore, avoiding the complication of 
multiple partitioning schemes.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: cron(8) improvement

[Warren Block]

On Sun, 10 Nov 2013, Daniel O'Connor wrote:



On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote:


  2) Should ports / packages populate these cron.d directories?

  This is a much more interesting question.  Effectively its asking
  if a port / package should provide some level of automatic
  configuration -- a thing that has previously been a no-no for
  FreeBSD.


I think it would be OK if they installed entries in a disabled state.


That would be my preference also.


ie either the file is named such that it is ignored by cron (preferable IMO) or 
the entries in them are commented out.


Why not just use an additional entry in rc.conf?

rsnapshot_cron=YES

(If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on
start/restart.)

This brings up another problem.  When a port is removed, what is done 
with ports cron entries that have been user modified?  Normally, 
modified files would not be removed, but a cron entry for a removed port 
definitely should not be running any more, even if the admin forgot to 
remove the entry in rc.conf.  But just removing the modified file is bad 
also, because maybe the port was just removed as part of an upgrade.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: cron(8) improvement

[Warren Block]

On Sun, 10 Nov 2013, Philipp Ost wrote:


Warren Block schrieb:
[...]

ie either the file is named such that it is ignored by cron
(preferable IMO) or the entries in them are commented out.


Why not just use an additional entry in rc.conf?

rsnapshot_cron=YES

(If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on
start/restart.)

This brings up another problem.  When a port is removed, what is done
with ports cron entries that have been user modified?  Normally,
modified files would not be removed, but a cron entry for a removed port
definitely should not be running any more, even if the admin forgot to
remove the entry in rc.conf.  But just removing the modified file is bad
also, because maybe the port was just removed as part of an upgrade.


Given the above scenario, would it be acceptable to set the entry in rc.conf, 
$portname_cron=YES, to $portname_cron=NO without touching the modified files 
and inform the user about having done so?


I would not want the system modifying rc.conf for me, but don't have a
better idea at present.  Maybe move customized cronfiles to an old
folder on deinstall, so at least the user could recover them.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Overriding sector size on disks?

[Warren Block]

On Fri, 1 Nov 2013, Adrian Chadd wrote:


Hi!

I have an odd problem. That, honestly, can't be that odd.

I have a bunch of SATA disks that when plugged into the laptop
directly, show up as 512 byte sectors. But if I plug it in via this
iomega USB caddy, they show up as 4k sector devices.


ISTR some Hitachi external USB disk enclosures do that.  Since they are 
not a general-purpose enclosure but came wrapped around specific Hitachi 
disks, it's not really their fault.



Because of this, partitions just plainly don't work.

Has anyone faced this? Is there some trick to do to get these things
to go back to being 512 byte sector devices so one can use them?



Similarly, because they show up as 512 byte sector devices on
macosx/linux, they can read/write NTFS/MSDOS partitions on the thing.
But if I plug it into freebsd, it shows up as a 4k sector device and
things plainly don't work.


Is it out of the question to discard the enclosure as too bugged to use?

Otherwise, there is a small chance that the vendor has a firmware update 
that isn't stupid.  Or maybe even a jumper in the enclosure.


Reference:

http://forum.hddguru.com/viewtopic.php?t=21099start= has some 
information which might help.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: /usr/src/lib/msun errors

[Warren Block]

On Sun, 13 Oct 2013, Joe Nosay wrote:

On Sun, Oct 13, 2013 at 11:57 AM, Joe Nosay superbisq...@gmail.com wrote:



Someone had to tell me what to do.
Steve, are you the only person in the multiverse that is free of making any
mistakes?


Nobody was accusing you of doing it intentionally.  Anyway, that problem 
is now solved--thanks!

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Warren Block]

On Tue, 8 Oct 2013, Freddie Cash wrote:


On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn nwhiteh...@freebsd.orgwrote:


4. What is this gnop stuff for?



Can't comment on the rest, but gnop is required to create 4K-aligned vdevs
where the minimum block size is 4K (aka ashift=12).


Right, but to emphasize: the gnop hack forces ZFS to 4K blocks.  It does 
not, by itself, guarantee alignment with 4K native blocks on the drive, 
that has to be done by making the partitions aligned.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Warren Block]

On Tue, 8 Oct 2013, Teske, Devin wrote:


But shell is nasty; slow; and not as powerful as C (it depends in what
context; the first is rhetoric, the second is only true for poor implement-
ations, and the third may be true in some contexts, but I consider the
answer to how maintainable is it to be a factor in the power of a
language, so don't necessarily consider C to be more powerful than
shell as the latter is as-or-more maintainable with fewer LoC and a
higher return on investment; see previous [above] arguments).


My question would be: why are sh and C the only choices?  If the answer 
is because that's all we have in base, is that a valid concern?


As far as sh, it lacks many high- or even mid-level constructs and has 
real problems with quoting, parsing, and output (21 3, for example). 
These make it harder to do things (aka, more code to accomplish a task, 
more code to be maintained, more difficult to modify) than the higher 
level Perubython languages.


In any case, thanks for working on this.  A functioning program in any 
language is better than a non-existent better one.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: X related ports not finding version strings and hanging

[Warren Block]

On Sun, 6 Oct 2013, Kevin Oberman wrote:


As usual with such upgrades, pkg_libchk is your friend. Assuming you have
updated pixman:
portmaster graphics/libGL graphics/dri
pkg_libchk -o | grep pixman | cut -d: -f1 | sort | uniq  pixman-files.txt
portmaster =D `cat pixman-files.txt`
portmaster -aD
portmaster -y -clean-distfiles


pkg_libchk -q  /tmp/to-be-rebuilt.txt
portmaster `cat /tmp/to-be-rebuilt.txt`

worked for me, although I did it after following the pixman instructions 
in /usr/ports/UPDATING.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Warren Block]

On Mon, 7 Oct 2013, Allan Jude wrote:


Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt to no


Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Warren Block]

On Mon, 7 Oct 2013, Allan Jude wrote:


On 2013-10-07 16:43, Warren Block wrote:

On Mon, 7 Oct 2013, Allan Jude wrote:


Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt
to no


Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .



That is a good idea, I'll add that

I've also hit this:
http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
and plan to throw in a fix for that.
Which makes more sense, blindly 'killall dhclient' before we try to
acquire a new lease, or detect that dhclient is running and try to use
the IP that has already been assigned?


killall seems all right.  In fact, internally, it's going to do that 
check.  If nothing named dhclient is running, it will return 
immediately.


Although on 10.0, dhclient does not want to die sometimes.

Here's another PR for usability:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Moused + HAL + rc.conf + Boot

[Warren Block]

On Mon, 16 Sep 2013, Nilton Jose Rizzo wrote:



 Hi all,

  I'm here again!

  When I start my box, the moused is run.  My mouse is an USB mouse.
  I put in rc.conf this knob: moused_enable=NO, but is ignored by
  start up script and moused is run, this is a problem to the HAL, because
  the HAL try to open /dev/ums0 again and can't do it.  I  need  to change
  to text console and kill the moused process. I have to  logout from
  account X ( via gdm) and I login again to mouse work.  It's started in
  two night ago.

see:
FreeBSD valfenda 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #4 r255503: Fri Sep 13
08:18:27 BRT 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA  amd64


moused is started by devd when a USB mouse is connected.  To disable it, 
add


  moused_nondefault_enable=

to /etc/rc.conf.  But it's generally preferable to disable xorg's use of 
HAL by adding


  Option AutoAddDevices Off

to the ServerLayout section of xorg.conf.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

10-stable does not boot on Dell E1505 any more

[Warren Block]

This is an older Dell E1505, Core 2 but does not have AHCI.

r255569 does not find /dev/ada0s2a and ? at the mountroot prompt 
shows no devices.


r255451 from September 10 boots fine.

Also possibly relevant is that after successfully building and 
installing world and kernel, /boot/kernel.old is not being replaced. 
This is good at present because the old kernel still works, but 
shouldn't kernel.old be replaced on installkernel?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-stable does not boot on Dell E1505 any more

[Warren Block]

On Sat, 14 Sep 2013, Jan Kokemüller wrote:


r255569 does not find /dev/ada0s2a and ? at the mountroot prompt
shows no devices.


I've had the same problem after I updated my kernel today. I tracked it
down to the hyperv drivers that were added in r255524. Without the device
hyperv line in my kernconf the system boots fine again.


Interesting!  Notice this fresh commit:
http://svnweb.freebsd.org/base?view=revisionsortby=daterevision=255574

A custom kernel without the hyperv device works.  Thanks!___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: usb mouse and xorg

[Warren Block]

On Tue, 10 Sep 2013, Sergey V. Dyatko wrote:


I have working touchpad (it is work fine before) and mouse with hacked
devd.conf (doesn't try tip from gjb@ yet)
from my xorg.conf:

Section ServerLayout
   Identifier X.org Configured
   Screen  0  Screen0 0 0
   InputDeviceMouse0 CorePointer
   InputDeviceKeyboard0 CoreKeyboard
EndSection
Section ServerFlags
   Option  DontVTSwitch  off
   Option  AllowEmptyInput off


http://www.wonkity.com/~wblock/docs/html/aei.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gpart: can not add MBR partitions with gpart add -t, mbr

[Warren Block]

On Fri, 21 Jun 2013, Genre Roger wrote:

When I refer to gpart(8) manpage (9.1 release, updated jan 25,2013), I find 
the description of partition types a bit confusing.


Considering the case of a MoBo with old way Bios (non UEFI), the only 
scheme allowed to get a bootable system is MBR. (Note that after booting, 
your OS is able to manage gpt-scheme on different providers.)


Sorry, I don't understand.  GPT boots fine on a BIOS system.  I'm using 
it on several systems.


Then, if you speak bsd-ish, you are able to add on the MBR-scheme 
provider up to 4 freebsd-type slices, each of them containing up to 8 
partitions with a BSD filesystem (or swap space).


Yes.  This is a partitions-inside-a-slice configuration, used for quite 
a while because it provides more partitions than MBR's four, and also 
because it allows a standard PC to multi-boot from any of the four MBR 
slices.  Technically, it's a hack.  It's complex and shows that both 
partitioning schemes (MBR and bsdlabel) have weaknesses.


Or, if you speak msdos-ish, you would be able to add on the MBR provider 
up to 4 msdos-type partitions (or 3 + 1 extended ), each of them containing 
one filesystem.


The manpage does'nt list explicitly the type for this second case; Oliver try 
to use mbr, decribed as A partition that is sub-partitioned by a Master 
Boot Record (MBR). This type is known as 
!024dee41-33e7-11d3-9d69-0008c781f39f  by GPT.. Such definition is'nt very 
explicit.


In general, it's rare to find a FreeBSD system that uses MBR slices 
directly because there are only four.  But it can be done by combining 
one or more of the standard filesystems and not subdividing the slices:


ada0s1: freebsd (/, /var, /tmp, and /usr combined into a single
 / filesystem)
ada0s2: swap

That would leave s3 and s4 available for other uses.


Let me show the example below on my provider ada0 :


$ gpart show
=   63  976773105  ada0  MBR  (465G)
 63  136314864 1  freebsd  [active]  (65G)
  136314927  840458241- free -  (400G)

=0  136314864  ada0s1  BSD  (65G)
  08388608   1  freebsd-ufs  (4.0G)
8388608   16777216   2  freebsd-swap  (8.0G)
   25165824   16777216   4  freebsd-ufs  (8.0G)
   419430408388608   5  freebsd-ufs  (4.0G)
   50331648   85983215   6  freebsd-ufs  (41G)
  136314863  1  - free -  (512B)

$ sudo gpart add -t mbr -i 2 -s 8G ada0
Password:
gpart: Invalid argument


MBR is not a type of partition, it is a partitioning method or scheme 
as the gpart man page calls them.  The partitioning scheme is dictated 
by the type of system.  Standard x86 computers are only going to be able 
to use MBR or GPT.



$ sudo gpart add -t \!12 -i 2 -s 8G ada0
ada0s2 added


\!12 is just an MS-DOS partition (FAT32 with LBA).


$ sudo newfs_msdos ada0s2
/dev/ada0s2: 16773056 sectors in 262079 FAT32 clusters (32768 
bytes/cluster)
BytesPerSec=512 SecPerClust=64 ResSectors=32 FATs=2 Media=0xf0 
SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=16777215 FATsecs=2048 
RootCluster=2 FSInfo=1 Backup=2

$ sudo gpart add -t freebsd -i 3 -s 8G ada0
ada0s3 added
$ gpart show ada0
=   63  976773105  ada0  MBR  (465G)
 63  136314864 1  freebsd  [active]  (65G)
  136314927   16777215 2  !12  (8G)
  153092142   16777215 3  freebsd  (8G)
  169869357  806903811- free -  (384G)
$ sudo newfs_msdos ada0s3
/dev/ada0s3: 16773056 sectors in 262079 FAT32 clusters (32768 
bytes/cluster)
BytesPerSec=512 SecPerClust=64 ResSectors=32 FATs=2 Media=0xf0 
SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=16777215 FATsecs=2048 
RootCluster=2 FSInfo=1 Backup=2
$ 
this example show that, if you want a msdos or fat32 partition, both the 
type \!12 or freebsd allows you  to create a partition where you could 
install a msdos filesystem (but the mbr does not).


It shows that MBR is a partitioning scheme, not a partition type.  It 
also demonstrates that newfs_msdos does not check the partition type of 
the partition on which it is creating a filesystem.  Neither does newfs. 
That is appropriate behavior.  The partition type is so that bootcode 
and other software that deals with partitions does not have to guess 
what is on a particular partition, but has it identified explicitly.


Such behaviour is not surprising, (using freebsd-type to format as msdos 
means you don't use the space allowed for labeling);


I don't understand what you are saying there.  Offhand, I can't think of 
any reason to misidentify a partition intentionally.



but what is really the purpose of the listed mbr-type in the gpart(8) manpage?


MBR is a partitioning scheme, comparable to GPT but more limited.  APM 
is a partitioning scheme for PPC Macs, VTOC8 is a partitioning scheme 
for Sparc.


The partitioning scheme determines which types of partitions are 
allowed.  For MBR, there are lots of partition types for variations for 
MS-DOS (including type 12), one (really) for NTFS, 

Re: gpart: can not add MBR partitions with gpart add -t mbr

[Warren Block]

On Tue, 18 Jun 2013, O. Hartmann wrote:



Having a 1TB disk with a MBR partition layout created successfully with
gpart create -s MBR ada4, which is shown as

Geom name: ada4
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 1953525167
first: 63
entries: 4
scheme: MBR
Consumers:
1. Name: ada4
  Mediasize: 1000204886016 (931G)
  Sectorsize: 512
  Mode: r0w0e0


it is impossible for me to create a partition with

gpart add -t mbr ada4

as it can be read in the manpage of gpart.


I can't find that in 9-stable or -head.  If it's a literal example, 
please point it out and I'll fix it.



Whatever I do, I receive a
useless error from gpart

gpart: Invalid argument

with no further information.

In kernel, I already added GEOM_MBR. geom_part_mbr and geom_part_ldm
kernel modules are then already loaded.

I tried to figure out what's going wrong but this seems highly
enigmatic.

What am I doing wrong?


mbr is partitioning scheme, not a partition type.  Common MBR 
partition types that gpart knows by name are freebsd, freebsd-ufs, 
freebsd-zfs, ntfs, no doubt lots of others but offhand I don't know 
where to get the whole list.


Examples shown here (MBR in the second half):
http://www.wonkity.com/~wblock/docs/html/disksetup.html

Numbers can also be used for partition types by prefixing them with an 
exclamation point, but that must be escaped to keep the shell from 
interpreting it:


  gpart add -t \!12 -s1G ada0

That would add a FAT32X/LBA partition.  There's a list of values here: 
http://en.wikipedia.org/wiki/Partition_type

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 10-CURRENT i386 memstick snapshots broken?

[Warren Block]

On Sat, 8 Jun 2013, Glen Barber wrote:


The problem is creating the gpart(8) partition scheme on the md(4)
device.

Below follows script(1) output of what the make-memstick.sh script does:

 Script started on Sun Jun  9 00:41:08 2013
 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap
 root@snap:/ # cd /usr/obj/usr/src/release
 root@snap:/usr/obj/usr/src/release # echo \
   '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1'  release/etc/fstab
 root@snap:/usr/obj/usr/src/release # makefs -B \
   little -o label=FreeBSD_Install test.img release
 Calculated size of `test.img': 649420800 bytes, 12922 inodes
 Extent size set to 8192
 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024
using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes.
 super-block backups (for fsck -b #) at:
   32,  111440,  222848,  334256,  445664,  557072,  668480,  779888,
   891296, 1002704, 1114112, 1225520,
 Populating `test.img'
 Image `test.img' complete
 root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img
 md0

All fine up until this point.  Now the gpart(8) partition is created:

 root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0
 gpart: Inappropriate ioctl for device
 root@snap:/usr/obj/usr/src/release # gpart list md0
 Segmentation fault (core dumped)


This might be a good time to stop using a bare bsdlabel (aka 
dangerously dedicated).  MBR plus bsdlabel is not great, but more 
widely understood, and other operating systems will at least recognize 
the MBR slice.  I can help with this if needed.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ipfilter(4) needs maintainer

[Warren Block]

On Sun, 14 Apr 2013, Chris Rees wrote:


On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote:

2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??:


Maybe something else, but whatever it is, it should be done.  If you and Gleb 
don't want to do this, I will.


I already started writing a guide. See here for a very incomplete version:

http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html


If you're really serious about deprecating ipf, we absolutely have to
remove instructions for it from the Handbook as soon as possible;
every time a new user comes across instructions you're going to have
yet another annoyed party.

http://www.bayofrum.net/~crees/patches/remove-ipf.diff


This should probably be done like we did for CVS for ports.  Mark it as 
deprecated, then remove the Handbook section once the code is removed.


Is it possible to move ipfilter into a port?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gpart, slice starts at 0

[Warren Block]

On Sun, 17 Feb 2013, Erich Dollansky wrote:


gpart destroy -F da0
diskinfo da0
dd if=/dev/zero of=/dev/da0 bs=512 count=34
dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774


Someone here on the lists (I unfortunately forget who) showed a
sneaky easier way to do this:

gpart destroy -F da0
gpart create -s gpt da0
gpart destroy -F da0


This did not make a difference.


It's an easier way to destroy the backup table at the end of the disk, 
whether one was there before or not, without having to calculate the 
location.



gpart show  -p da0
gpart create -s MBR da0
gpart add -t freebsd da0
gpart show  -p da0
gpart show  -p da0s1
gpart set -a active -i 1 da0
#
# The following line always gives an error:
#
# gpart create -s BSD da0s1


'destroy' is not recursive.  It destroys the geom found on the device
given, but does not write to any geoms inside those geoms.


This is obvious. What surprises me is that create does not write a new
and empty description to the disk.


It does, but not being recursive, it does not destroy the geoms inside 
the one given to the command (da0).  You had:


  da0 (MBR)
   da0s1 (bsdlabel)

After the destroy, it became
  da0 (null)
da0s1 (bsdlabel)

This can happen with any of the setups where there are geoms inside 
other geoms.



The second part of your question, about da0 starting a block zero:


[X220]...Appl/Some Tools (root)  gpart show da0
=   63  312581745  da0  MBR  (149G)
 63  3125817451  freebsd  [active]  (149G)

[X220]...Appl/Some Tools (root)  gpart show da0s1
=0  312581745  da0s1  BSD  (149G)
  0  312581745 - free -  (149G)


That shows slice one starts at block 63, standard for MBR.  The space
inside the slice (da0s1) starts at block 0 *of the slice*.


This is a bit confusing for me but it does not really matter as long as
the programs get it straight.


This is again because of the geom inside a geom setup.  The actual start 
block is the start of the slice (block 63) plus the start of the FreeBSD 
partition inside the slice (currently 0).  When you create FreeBSD 
partitions inside da0s1, they will have nonzero offsets from the start 
of the slice.  There are examples shown here:

http://forums.freebsd.org/showpost.php?p=206204postcount=11
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gpart, slice starts at 0

[Warren Block]

On Sat, 16 Feb 2013, Erich Dollansky wrote:


I did this to get a disk partitioned:

#!/bin/tcsh


Gah!


gpart destroy -F da0
diskinfo da0
dd if=/dev/zero of=/dev/da0 bs=512 count=34
dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774


Someone here on the lists (I unfortunately forget who) showed a sneaky 
easier way to do this:


gpart destroy -F da0
gpart create -s gpt da0
gpart destroy -F da0


gpart show  -p da0
gpart create -s MBR da0
gpart add -t freebsd da0
gpart show  -p da0
gpart show  -p da0s1
gpart set -a active -i 1 da0
#
# The following line always gives an error:
#
# gpart create -s BSD da0s1


'destroy' is not recursive.  It destroys the geom found on the device 
given, but does not write to any geoms inside those geoms.


MBR/bsdlabel puts FreeBSD partitions inside MBR slices.

So da0 has been erased, but the bsdlabel blocks for da0s1 are still 
present.  If you recreate da0, da0s1 will magically reappear.


Destroy the FreeBSD disklabel stuff in the slices first:
  gpart destroy -F da0s1

Or instead, use GPT partitioning to avoid dealing with the problem of 
one type of partitions inside a different type of partitions.  GPT makes 
disk partitioning a lot easier.


The second part of your question, about da0 starting a block zero:


[X220]...Appl/Some Tools (root)  gpart show da0
=   63  312581745  da0  MBR  (149G)
 63  3125817451  freebsd  [active]  (149G)

[X220]...Appl/Some Tools (root)  gpart show da0s1
=0  312581745  da0s1  BSD  (149G)
  0  312581745 - free -  (149G)


That shows slice one starts at block 63, standard for MBR.  The space 
inside the slice (da0s1) starts at block 0 *of the slice*.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 7+ days of dogfood

[Warren Block]

On Mon, 11 Feb 2013, Lars Engels wrote:


I also dislike that src build times increased over the years since I run
CURRENT on my notebooks (starting 7-CURRENT, now 10-CURRENT).
Wouldn't it be possible to add a
DO_NOT_BUILD_CLANG_AND_GCC_IF_NOTHING_CHANGED= yes switch to src.conf?

Building clang takes ages and gcc is also pretty big...


devel/ccache really makes a gcc system buildworld a lot faster.  I don't 
know why more people don't use it; why recompile so many things that 
have not changed?


My recollection of testing it with clang was that it did not make much 
of an improvement.  Could be better now.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Xorg totally unusable with KMS and new Xorg on Sandy Bridge system: how to undo

[Warren Block]

On Fri, 8 Feb 2013, Thomas Mueller wrote:


Thomas Mueller writes:


 I built the newer Xorg and it falls flat: goes to a nongraphic
 screen that is blank except for a rectangular cursor in the upper
 left corner, and now I want to get back to the earlier Xorg.

 System is Intel Sandy Bridge with i7 CPU.


Robert Huff responds:


You don't mention your graphics chip explicitly, but building
libdrm with the KMS option was enough to prevent X from starting on
a Radeon HD 3300.  (Experimental, indeed!  :-)
Other will be able to help more if you could post the contents
of /var/log/Xorg.0.log and your xorg.conf file.


My /var/log/Xorg.0.log has 0 bytes!

To Andrey Fesenko f0and...@gmail.com:

Were you able to start X with

# cat /etc/make.conf
WITH_NEW_XORG=true
WITH_KMS=true

X.Org X Server 1.10.6
Release Date: 2012-02-10
intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+)

(end of quote from Andrey Fesenko)


After adding those, graphics/libdrm must be rebuilt, and 
x11-drivers/xf86-video-intel must have the KMS option enabled and be 
rebuilt.  If you just added WITH_NEW_XORG, there will be other xorg 
components that need to be updated.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: gpart resize vs. cache?

[Warren Block]

On Sun, 3 Feb 2013, Tim Kientzle wrote:


On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote:


On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote:

I'm tinkering with a disk image that automatically
fills whatever media you put it onto.  But I'm having
trouble with gpart resize failing.

Disk layout:
  MBR with two slices  mmcsd0s1 and mmcsd0s2
  bsdlabel with one partition mmcsd0s2a

Before I can use growfs, I have two gpart resize operations:

1)   gpart resize -i 2 mmcsd0

2)  gpart resize -i 1 mmcsd0s2

Step 1 resizes mmcsd0s2 and always succeeds.

Step 2 resizes mmcsd0s2a and always fails
with No space on device.

BUT if I reboot between these steps, step #2
always succeeds.

I suspect that step #1 is updating the partition
information on disk but that step #2 is somehow
reading the old size of mmcsd0s2 and thus finding
that there is no available space to grow the partition.


BTW, I've added some debug messages to gpart
and the second resize is failing because the new
computed size is a little smaller than the old size
(maybe because of a different alignment?).  But
it's certainly not sizing to the new container size.


MBR always forces alignment to imaginary CHS tracks, as if you used -a63 
in gpart.  But it's not gpart, it's the kernel being really strict about 
standards.  As far as I've been able to tell, there is no way around 
that short of possibly dd-ing a preconstructed MBR partition table into 
place.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: problem after installkernel going from 9.0 to CURRENT

[Warren Block]

On Wed, 2 Jan 2013, Robert Huff wrote:

	(While this may not be a strictly CURRENT issue, I asked on 
questions@, but have not found a solution.)


Situation:
	One of my boxes failed, and for various reasons it became easier to 
just scrub and rebuild it. Like its predecessor it will run CURRENT

1) Using BSDinstall, I flushed then created the first disk:

ada2p1  freebsd-boot128k
ada2p2  freebsd-swap4g
ada2p3  freebsd-ufs 25g

(There are non-bootable disks at ada0, -1, and -3.)

	2) Installed off the 9.0 CD, got it up and running, everything was 
good.

3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30.
4a) Built world - OK.
4b) Build kernel - OK.
4c) Ran mergemaster - OK.
4d) Installed kernel - OK.
5) On rebooting, the loader(??) claims to not be able to find a
bootable partition - i.e. I get a screen that ends in mountroot  .
Providing the presumptive value by hand returns error 19.
	6) Boot using installation CD and use gpart show to double check 
device names and partitions; everything looks good.

7) Try normal booting again, no go.

	This is my first time installing to a completely GPT partitioned 
system, and I have (obviously) failed to grok something.  I checked 
src/UPDATING and found nothing which covered this.

What have I bungled, and how do I fix it?


It really does not sound like a GPT problem, because 9.0 booted.  The 
-current kernel can't find/detect the device.  Scrolling back in the 
console buffer might find a problem.  buildworld/kernel/installworld do 
not affect the disk partitioning, but can change the code that looks for 
those partitions.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: problem after installkernel going from 9.0 to CURRENT

[Warren Block]

On Thu, 3 Jan 2013, Kevin Oberman wrote:


One possibility: I believe I labeled each of the partitions during
the gpt creation process.  Can I use those labels to (hopefully) by-pass
this issue?


Yes! This is the current recommended way of doing it.

cat /etc/fstab

# DeviceMountpoint  FStype  Options DumpPass#
/dev/gpt/swap   noneswapsw  0   0
/dev/gpt/root   /   ufs rw  1   1
/dev/gpt/tmp/tmpufs rw  2   2
/dev/gpt/usr/usrufs rw  2   2
/dev/gpt/var/varufs rw  2   2


To avoid collisions, I recommend people use unique labels on each 
system.  I sometimes pick a couple of letters from the system name or 
drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 LiveCD missing features

[Warren Block]

On Fri, 7 Dec 2012, Garrett Cooper wrote:


On Fri, Dec 7, 2012 at 11:06 PM, CeDeROM cede...@tlen.pl wrote:

Hello Ian :-)

This is the problem - / is read only and /etc/resolv.conf already links to
nonexistent file. This way I cannot modify its content nor link other file
(i.e. /var/resolv.conf) to /etc/resolv.conf. Creating /var/resolv.conf does
not help either.

I think /etc/resolv.conf should point to /var/resolv.conf from start so the
resolver is functional :-)


   I generally get around this with mdmfs and unionfs mounts, but
it's a bit annoying... I'll see if I can file a PR with all of the
things that need to be fixed/enhanced and maybe fix some of the items
if I get some time (if the liveCD used rc.initdiskless it would be
considerably simpler and some key filesystems would be writable after
boot).


Martin Matuska's excellent mfsBSD (http://mfsbsd.vx.sk/) could be a 
source for ideas or techniques.  It does things like this well.  (I was 
going to say it does *most* things well, but can't actually think of 
anything it does not do well.)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 LiveCD missing features

[Warren Block]

On Fri, 7 Dec 2012, Chuck Burns wrote:


dd if=/dev/zer of=/dev/ada0

^^^ There's your badblocks program.  Any hard drive made in the last decade 
have been self-remapping..


That should be /dev/zero.  And this will be very slow, going one 
512-byte block at a time.  Using a 64K or 128K buffer (bs=128K) will 
speed it up tremendously.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: sluggish X.org/Xfce behavior

[Warren Block]

On Tue, 20 Nov 2012, René Ladan wrote:


since last weekend (November 17th) I have been noticing a sluggish
behavior of X.org/Xfce. Typical symptoms are:
- Alt-Tab not reacting all of the time
- pulldown/popup menus not allowing selections with mouse (typically in
Terminal/pidgin), or moving the mouse (touchpad) results in an automatic
click
- typing something in a Terminal requires mouse (touchpad) movements for
the text to show up
- sometimes moving the mouse (touchpad) is required for the laptop to
wake up; this is noticeable when Thunderbird downloads all messages
from the period when the laptop was frozen.


This is one of the problems that having Option AllowEmptyInput Off 
in xorg.conf causes.  If you have that, substitute Option 
AutoAddDevices Off in the same place.___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: sluggish X.org/Xfce behavior

[Warren Block]

On Tue, 20 Nov 2012, René Ladan wrote:


On 20-11-2012 15:34, Warren Block wrote:

On Tue, 20 Nov 2012, René Ladan wrote:


since last weekend (November 17th) I have been noticing a sluggish
behavior of X.org/Xfce. Typical symptoms are:
- Alt-Tab not reacting all of the time
- pulldown/popup menus not allowing selections with mouse (typically in
Terminal/pidgin), or moving the mouse (touchpad) results in an automatic
click
- typing something in a Terminal requires mouse (touchpad) movements for
the text to show up
- sometimes moving the mouse (touchpad) is required for the laptop to
wake up; this is noticeable when Thunderbird downloads all messages
from the period when the laptop was frozen.


This is one of the problems that having Option AllowEmptyInput Off
in xorg.conf causes.  If you have that, substitute Option
AutoAddDevices Off in the same place.

Commenting out AllowEmptyInput Off (and not having an AutoAddDevices
entry) works for me.

Must do better homework...


http://www.wonkity.com/~wblock/docs/html/aei.html gives more detail.___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: No ATA disks on 9.1-RC3

[Warren Block]

On Mon, 19 Nov 2012, Alex Keda wrote:


I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3
it cannot boot, because no HDD found
dmesg from 9.0/9.1 and pciconf in attached files


If there is an IDE/AHCI mode setting in the BIOS, switch it to the other 
setting.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Thu, 8 Nov 2012, CeDeROM wrote:


I have tested additional options in xorg runtime :-)

With the patched xorg mouse driver 1.7.1 (or driver version =1.7.2)
situation is following:

1. With hald and dbus no xorg.conf file is needed. However it might bo
option to pass some additional featutes parameters with xorg.conf.
2. With no hald and dbus mouse and keyboard does not work in xorg unless
Option AllowEmptyInput False is added to  Section ServerLayout by
hand in xorg.conf. Without this option input does not work even if
xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced
by Xorg at startup.


No.  AllowEmptyInput is wrong.  It was causing so many problems that it 
has been removed from later xorg-server releases.


Option AutoAddDevices Off is the one that means dont' use Hal to 
detect input devices.



Thank you for this hint! This could be added to the handbook :-)
AllowEmptyInput=False should be a default for Xorg IMO we can report it to
the Xorg project! :-)


Really, the simplest solution is to build xorg-server with the HAL 
option disabled.  I agree that this should be the default.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Thu, 8 Nov 2012, Ian Lepore wrote:


On Thu, 2012-11-08 at 08:45 -0700, Warren Block wrote:

On Thu, 8 Nov 2012, CeDeROM wrote:


I have tested additional options in xorg runtime :-)

With the patched xorg mouse driver 1.7.1 (or driver version =1.7.2)
situation is following:

1. With hald and dbus no xorg.conf file is needed. However it might bo
option to pass some additional featutes parameters with xorg.conf.
2. With no hald and dbus mouse and keyboard does not work in xorg unless
Option AllowEmptyInput False is added to  Section ServerLayout by
hand in xorg.conf. Without this option input does not work even if
xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced
by Xorg at startup.


No.  AllowEmptyInput is wrong.  It was causing so many problems that it
has been removed from later xorg-server releases.


This is disturbing news.  We build embedded systems at work that use X
for presentation and have no input devices.  I understand that
AllowEmptyInput is inappropriate to work around the problem we're
discussing here, but that doesn't mean it's never needed.


The xorg folks should be able to suggest the right replacement.


Option AutoAddDevices Off is the one that means dont' use Hal to
detect input devices.


Thank you for this hint! This could be added to the handbook :-)
AllowEmptyInput=False should be a default for Xorg IMO we can report it to
the Xorg project! :-)


Really, the simplest solution is to build xorg-server with the HAL
option disabled.  I agree that this should be the default.


So if you're using xorg-server that was built with hal included (maybe
because you're more a package than a ports kind of person and have no
control over the build), is AutoAddDevices still the right option to
manipulate?  That is, will it disable the use of hal and fall back to
honoring the xorg.conf input devices even if the server was built with
hal support?


xorg-server with hal support and AutoAddDevices Off in xorg.conf should 
be equivalent to xorg-server built without hal support.


Put another way: if xorg-server is built without hal support, 
AutoAddDevices is irrelevant, it can't use hal for input device 
detection anyway.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Thu, 8 Nov 2012, Tomek CEDRO wrote:


WARNING!!!

When AllowEmptyInput = False AND Hal is running really really bad things
happen to Xorg!! Keys are messed up and screen is refreshed only after
mouse move! Things are slow and the end of the word is near :-)

AllowEmptyInput seems to be exclusive with Hal!!

Please confirm :-)


It's a known problem, in the same class as Doctor, it hurts when I do 
this.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Thu, 8 Nov 2012, Richard Kuhns wrote:


On 11/08/12 10:45, Warren Block wrote:

On Thu, 8 Nov 2012, CeDeROM wrote:


I have tested additional options in xorg runtime :-)

With the patched xorg mouse driver 1.7.1 (or driver version =1.7.2)
situation is following:

1. With hald and dbus no xorg.conf file is needed. However it might bo
option to pass some additional featutes parameters with xorg.conf.
2. With no hald and dbus mouse and keyboard does not work in xorg unless
Option AllowEmptyInput False is added to  Section ServerLayout by
hand in xorg.conf. Without this option input does not work even if
xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced
by Xorg at startup.


No.  AllowEmptyInput is wrong.  It was causing so many problems that it
has been removed from later xorg-server releases.

Option AutoAddDevices Off is the one that means dont' use Hal to
detect input devices.


Thank you for this hint! This could be added to the handbook :-)
AllowEmptyInput=False should be a default for Xorg IMO we can report it to
the Xorg project! :-)


Really, the simplest solution is to build xorg-server with the HAL
option disabled.  I agree that this should be the default.


Just a comment: according to http://wiki.freebsd.org/VirtualBox, Hal is still
required for VirtualBox in order to have host DVD/CD access.


This is probably a permissions thing.  VirtualBox sees the device, but 
can't quite mount it.  So hal may not be actually required for that 
function in VirtualBox, but figuring out just what is needed without hal 
remains to be done.


KDE and Gnome both still need hal, but AFAIK do not require it to be 
used for xorg input device detection.  xfce4 works fine without hal.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Wed, 7 Nov 2012, Julian H. Stacey wrote:


Ian Lepore wrote:


Before you do that, read this:

 http://www.wonkity.com/~wblock/docs/html/aei.html


The page is bad here:
Summary ... just let xorg-server use hald by default.

FreeBSD 8.3-RELEASE  9.0-RELEASE by default do Not run hald.  See:
/usr/local/etc/rc.d/hald
# Add the following line to /etc/rc.conf to enable the HAL daemon:
#
# hald_enable=YES
There is no hald_enable=YES in /etc/defaults/rc.conf (Happily, IMO).


It's not saying that hald is run by default, merely that xorg-server 
will try to use it by default.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: 9.1-RC3 feels okay :-)

[Warren Block]

On Wed, 7 Nov 2012, CeDeROM wrote:


Isn't this a Xorg bug then? When I have no configuration file Hal should
provide the configuration, so sooner or later the mouse should start
moving... but is does not..

Do I get http://www.wonkity.com/~wblock/docs/html/aei.html correct that
when I am using xorg.conf there is no need for Hal and when I am using Hal
there is no need for xorg.conf?


Not quite, no.  xorg.conf is the configuration file for xorg-server.  It 
can do a lot more than just identify input devices.


Option AutoAddDevices Off tells xorg-server: even if hal is present 
and running, don't use it to detect input devices.


AFAIK, hal is not used by xorg-server for anything else.  All other 
autoconfig (video card detection, monitor detection, it even has its own 
built-in input device detection) is done by the xorg server itself.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org