IFLIB: em0/igb0 broken: No buffer space available/TX(0) desc avail = 1024, pidx = 0

[O. Hartmann]

Since the introduction of IFLIB, I have big trouble with especially a certain
type of NIC, namely formerly known igb and em.

The worst device is an Intel NIC known as i217-LM

em0@pci0:0:25:0:class=0x02 card=0x11ed1734 chip=0x153a8086 rev=0x05
hdr=0x00 vendor = 'Intel Corporation'
device = 'Ethernet Connection I217-LM'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 32, base 0xfb30, size 131072, enabled
bar   [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled
bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled

This NIC is widely used by Fujitsu's workstations CELSIUS M740 and the fate
would have it, that I have to use one of these.

When syncing data over the network from the workstation to an older C2D/bce
based server via NFSv4, since introduction of IFLIB the connection to the NFS
get stuck and I receive on the console messages like

em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 42, pidx = 985

Hitting "Ctrl-T" on the terminal doing the sync via "rsync", I see then this
message:

load: 0.01  cmd: rsync 68868 [nfsaio] 395.68r 4.68u 4.64s 0% 3288k (just for
the record)

Server and client(s) are on 12-CURRENT: ~ FreeBSD 12.0-CURRENT #38 r318285: Mon
May 15 12:27:29 CEST 2017 amd64, customised kernels and "netmap" enabled (just
for the record if that matters).

In the past, I was able to revive the connection by simply putting the NIC down
and then up again and while I had running a ping as a trace indication of the
state of the NIC, I got very often

ping: sendto: No buffer space available

Well, today I checked via dmesg the output to gather again those messages and
realised that the dmesg is garbled:

[...]
nfs nfs servnnfs servefs r server19 2.19162n.fs snerver fs1 s9nfs s2er.nfs
server er192.168.0.31:/pool/packages: not responding v
er 192.168.0.31ver :/po1ol/packages9: 2.168.0.31:/pool/packagesn: noot
responding t
<6>n fs serverespondinngf
s
 server 192.168.1rn nfs server 192.168.0.31:/pool/packages: not1 responding
 9
 2.168.1f7s 0.31:/pool/packagenfs sesrver 19serv2er .168.0.31:/poo: not
respolnding /
 packages: not responding
 nfs server 19192.168.0.31:/pool/pa2c.k168.0.31:a/gpserver
ne1s92.168.0.31:/pool/pac: knot respaof1s68 gs.e17rve8r.2
3192.168.0.31:/pool/packa1:/pool/packages: not responding o goes: nl/packages:
not responding o
 t responding
 nfs server 192.168.0.31:/poes: ol/packages: nfns server
192.168.0.31:/pool/paot responding c
 kages: not respondinnfs server n192.1f68.0.31:/pool/packagess: ndi server
 192.168.0.31:/pool/packages: not responding
[...]

Earlier this year after introduction of IFLIB, I checked out servers equipted
with Intels very popular i350T2v2 NIC and I had similar problems when dd'ing
large files over NFSv4 (ZFS backed) from a client (em0, a client/consumer grade
older NIC from 2010, forgot its ID, towards server with i350, but the server
side got stuck with the messages seen similar to those reported with the
i217-LM). Since my department uses lots of those server grade NICs, I will swap
the i217 with a i350T2 and check again.

Nevertheless, the situation is very uncomfortable! 

Kind regards,
Oliver
___
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 2017

[Benjamin Kaduk]

FreeBSD Project Quarterly Status Report - 1st Quarter 2017

   While a few of these projects indicate they are a "plan B" or an
   "attempt III", many are still hewing to their original plans, and all
   have produced impressive results. Please enjoy this vibrant collection
   of reports, covering the first quarter of 2017.

   --Benjamin Kaduk
 __

   The deadline for submissions covering the period from April to June
   2017 is July 7, 2017.
 __

FreeBSD Team Reports

 * The FreeBSD Core Team
 * The FreeBSD Foundation
 * The FreeBSD Ports Collection
 * The FreeBSD Release Engineering Team

Projects

 * Ceph on FreeBSD
 * OpenBSM
 * Porting Software to CloudABI: Sandboxed Bitcoin!
 * Support for eMMC Flash and Faster SD Card Modes
 * TrustedBSD

Kernel

 * FreeBSD on Hyper-V and Azure
 * Intel 10G and 40G Network Driver Updates
 * Linuxulator
 * MMC Stack Using the CAM Framework
 * pNFS Server Plan B

Architectures

 * 64-bit PowerPC Book-E Support
 * FreeBSD on Marvell Armada38x
 * FreeBSD/s390x Attempt III

Ports

 * MySQL
 * Rust

Documentation

 * The FreeBSD Dutch Documentation Project
 __

FreeBSD Team Reports

The FreeBSD Core Team

   Contact: FreeBSD Core Team 

   Core's primary function is to ensure the long-term viability of the
   FreeBSD project. A very large part of that is to ensure that the
   interactions between developers remain cordial, and consequently that
   the project appears welcoming to newcomers.

   Normally, most of Core's activities around this are done in private --
   a quiet word in the right ear, some discrete peacemaking, occasional
   reading of the riot act. Most of the time, this is all that is
   necessary.

   Unfortunately, this quarter we had an instance where such private
   measures failed to achieve the desired result, and we ended up ejecting
   a developer. This developer is an extremely talented programmer and has
   made significant contributions to the Ports Collection. Despite this,
   portmgr found him to be sufficiently disruptive and abrasive that in
   their judgement, the project was better off overall to sever his
   connection to itself, and core backed them up in that. We are sorry
   that events came to this sad conclusion, but we remain convinced that
   this was a necessary step to safeguard the character of our community.

   In a more positive light, Core has been working on a proposal to
   recognise notable contributors to the FreeBSD project who are not (or
   perhaps not yet) suitable to be put forward as new committers. In
   addition to the usual routes of recognising people that write numbers
   of good bug reports or that supply patches or that volunteer to
   maintain ports, this will also allow recognition of people who
   contribute by such things as organising FreeBSD events or who promote
   FreeBSD through social media. A formal announcement of Core's proposal
   is imminent.

   During January, the core secretary held an exercise to contact all
   source committers who had been inactive for more than 18 months and
   persuade them to hand in their commit bits if they were not planning to
   resume working on FreeBSD in the near future. This is meant to be a
   routine function -- the "grim reaper" -- that aims to keep the list of
   people with the ability to commit pretty much in synchrony with the
   list of people that are actively committing. The regular process had
   fallen out of activity several years ago, and we needed to clear the
   decks before restarting. Ultimately, this resulted in some 20
   developers-emeritus handing in their commit bits.

   No new commit bits were awarded during this quarter.

   Core is also taking soundings on producing a 10.4-RELEASE. This is not
   in the current plan, but a number of developers and important FreeBSD
   users would be keen to see it happen, given some of the work that has
   gone into the stable/10 branch since 10.3-RELEASE. On the other hand,
   this would represent an additional support burden for the Security
   Team, including maintaining versions of software that have been
   declared obsolete upstream, in particular OpenSSL. As an even-numbered
   release, 10.4-RELEASE would have a "normal" rather than an "extended"
   lifetime which means it should not result in extending the support
   lifetime of the stable/10 branch.

   In other news, Core arranged for the old and largely inactive
   market...@freebsd.org mailing list to be wound up, and for any
   remaining activities to be transferred to the FreeBSD Foundation.

   Core also asked clusteradm to turn off Internet-wide access to the
   finger server on freefall.freebsd.org. Many developers have included
   

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

On Mon, 15 May 2017 10:51:51 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

> 
> 
> On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
> wrote:
> 
> > Hi.
> > If including its version to nvidia.ko and nvidia-modeset.ko,
> > [hard / symbolic] link to it with current name should be needed
> > not to bother admins every time upgrading.
> > 
> > BTW, I personally using below in rc.conf for safety.
> > This only helps situations that...
> > 
> >  *Insufficient loader memory, but OK after kernel is started.
> > 
> >  *Accidentally backed to older version that doesn't have
> >   nvidia-modeset.ko and only nvidia-modeset.ko is written in
> >   /boot/loader.conf.
> > 
> > ## Temporary settings for nvidia-driver when failed loading via loader.conf
> > kldstat -q -n nvidia.ko
> > if [ 0 -ne $? ] ; then
> >   echo "Loading nvidia-driver modules via rc.conf."
> > #  kldload nvidia
> >   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> > #kldload nvidia-modeset
> > kld_list="${kld_list} nvidia-modeset.ko"
> >   else
> > #kldload nvidia
> > kld_list="${kld_list} nvidia.ko"
> >   fi
> > fi
> > 
> > 
> > On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> > "Jeffrey Bouquet"  wrote:
> > 
> > >  Just had a unique to me, unbootable backup [beside the point,
> > > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > > 
> > >   12.0 - CURRENT
> > > 
> > >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > > for me to peruse as I was in the terminal ]
> > > 
> > > Lessons I learned, maybe
> > > 
> > > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > > nvidia-modeset-37539.ko
> > >   which would make one's diagnosis a fix easier. 
> > > 
> > > [suggestions]
> > > 
> > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if 
> > > you'd thus made it 'unavailable'
> > > ... document better that one can load nvidia[modeset] later than 
> > > /boot/loader.conf [cli, rc.conf...]
> > > 
> > > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > > ] 
> > > ... I had a make.conf in place, 'trapping' a
> > > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > > install in failure
> > > ... I had no clue if Xorg was at fault, and luckily did not have to 
> > > rebuild.
> > > ... I had no access to the forums, as the desktop could not be loaded 
> > > [yet]
> > > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > > usable module numbers,
> > > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > > its 5 digit number
> > > as above.
> > > ... I was taken aback by the less infomative
> > > this client has the .39 but the module has the .26 ... 
> > > specifically stating which file/port/kernel module the 'client' 
> > > refers to
> > >and which specific modules 'this module' was referring to.  Unknown if 
> > > that is
> > >fixable here in a .c, .h , or is closed-source upstream in nvidia 
> > > [corp ] where we can
> > > ask them to be more specific or code in some more verbose error 
> > > messages.
> > > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > > files out of the
> > >   way and do a simple rebuild of the nvidia-driver.
> > > [... Not relieved that the nvidia-driver needed install during the 
> > > mesa-lib reshuffle,  maybe
> > >did not need to be, just a hazy recollection on my part.  So ignore 
> > > this little bit ]
> > > 
> > > ... All in all a learning experience.  Howsoever, I would like this 
> > > nvidia stuff to be put eventuall
> > >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > > yearly will have a more
> > >  authoritative flowchart of sorts to determine the next course of action.
> > >something like
> > >   if ... this thta
> > >if... this that
> > >if ... this that
> > >   OTOH... error message... a... you may need to...
> > >...
> > >error message ... r... you may need to...
> > > 
> > >  ... And it would have maybe saved a bit of time here, and I would almost 
> > > if eventually
> > >  possible be sure to copy /usr/src/UPDATING to 
> > > /usr/ports/x11/nvidia-driver for
> > >  more easy access if the desktop was broken
> > > 
> > > 
> > > Apologies for the hurried post. Indeed, I have tasked myself to write it 
> > > up here
> > > locally [ still in scribbled notations...] so I can forestall/fix more 
> > > quickly this
> > > error the next time.
> > > also...
> > > Running late  in other personal matters, and out of time.
> > > 
> > > Respectfully..
> > > 
> > > J. Bouquet 
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > 

Re: 64-bit inodes (ino64) Status Update and Call for Testing

[Shawn Webb]

On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote:
> On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> > Inodes are data structures corresponding to objects in a file system,
> > such as files and directories. FreeBSD has historically used 32-bit
> > values to identify inodes, which limits file systems to somewhat under
> > 2^32 objects. Many modern file systems internally use 64-bit identifiers
> > and FreeBSD needs to follow suit to properly and fully support these
> > file systems.
> > 
> > The 64-bit inode project, also known as ino64, started life many years
> > ago as a project by Gleb Kurtsou (gleb@).  After that time several
> > people have had a hand in updating it and addressing regressions, after
> > mckusick@ picked up and updated the patch, and acted as a flag-waver.
> > 
> > Sponsored by the FreeBSD Foundation I have spent a significant effort
> > on outstanding issues and integration -- fixing compat32 ABI, NFS and
> > ZFS, addressing ABI compat issues and investigating and fixing ports
> > failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
> > jhb@ provided feedback and review on the ABI transition support. pho@
> > performed extensive testing and identified a number of issues that
> > have now been fixed.  kris@ performed an initial ports investigation
> > followed by an exp-run by antoine@. emaste@ helped with organization
> > of the process.
> > 
> > This note explains how to perform useful testing of the ino64 branch,
> > beyond typical smoke tests.
> > 
> > 1. Overview.
> > 
> > The ino64 branch extends the basic system types ino_t and dev_t from
> > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
> > layout is modified due to the larger size of ino_t, and also gains a
> > d_off (directory offset) member. As ino64 implies an ABI change anyway
> > the struct statfs f_mntfromname[] and f_mntonname[] array length
> > MNAMELEN is increased from 88 to 1024, to allow for longer mount path
> > names.
> > 
> > ABI breakage is mitigated by providing compatibility using versioned
> > symbols, ingenious use of the existing padding in structures, and by
> > employing other tricks.  Unfortunately, not everything can be fixed,
> > especially outside the base system.  For instance, third-party APIs
> > which pass struct stat around are broken in backward and forward-
> > incompatible way.
> > 
> > 2. Motivation.
> > 
> > The main risk of the ino64 change is the uncontrolled ABI breakage.
> > Due to expansion of the basic types dev_t, ino_t and struct dirent,
> > the impact is not limited to one part of the system, but affects:
> > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
> >   and more)
> > - libc interface (mostly related to the readdir(3), FTS(3))
> > - collateral damage in other libraries that happens to use changed types
> >   in the interfaces.  See, for instance, libprocstat, for which compat
> >   was provided using symbol versioning, and libutil, which shlib version
> >   was bumped.
> > 
> > 3. Quirks.
> > 
> > We handled kinfo sysctl MIBs, but other MIBs which report structures
> > depended on the changed type, are not handled in general.  It was
> > considered that the breakage is either in the management interfaces,
> > where we usually allow ABI slip, or is not important.
> > 
> > Struct xvnode changed layout, no compat shims are provided.
> > 
> > For struct xtty, dev_t tty device member was reduced to uint32_t.  It
> > was decided that keeping ABI compat in this case is more useful than
> > reporting 64bit dev_t, for the sake of pstat.
> > 
> > 4. Testing procedure.
> > 
> > The ino64 project can be tested by cloning the project branch from
> > GitHub or by applying the patch  > at URL | attached> to a working tree.  The authorative source is the
> > GitHub, I do not promise to update the review for each update.
> > 
> > To clone from GitHub:
> > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64
> > 
> > To fetch the patch from Phabricator:
> > - Visit https://reviews.freebsd.org/D10439
> > - Click "Download Raw Diff" at the upper right of the page
> > 
> > Or
> > % arc patch D10439
> > 
> > After that, in the checkout directory do
> > % (cd sys/kern && touch syscalls.master && make sysent)
> > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
> > If you use custom kernel configuration, ensure that
> > options COMPAT_FREEBSD11
> > is included into the config.  Then build world and kernel in the
> > usual way, install kernel, reboot, install new world.  Do not make
> > shortcuts in the update procedure.
> 
> Hey Kostik,
> 
> On my HardenedBSD system, world compiled fine with the patch, but the
> kernel didn't compile. I've uploaded the log to:
> 
> https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log
> 
> This was from importing the patch from Phabricator into
> hardened/current/master in HardenedBSD.

Update: I missed a step. Kernel and 

Re: regression suspend/resume on Lenovo T420

[Edward Tomasz Napierała]

On 0515T2140, Konstantin Belousov wrote:
> On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote:
> > Thanks!  The patch fixes resume for me, for both vt(4) and X11.
> 
> Thanks everybody for testing, patch below should be committable, modulo
> bugs.  I did not tested it and ask for the same test as the previous
> debugging patch.

[..]

Works just fine, 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: 64-bit inodes (ino64) Status Update and Call for Testing

[Shawn Webb]

On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> Inodes are data structures corresponding to objects in a file system,
> such as files and directories. FreeBSD has historically used 32-bit
> values to identify inodes, which limits file systems to somewhat under
> 2^32 objects. Many modern file systems internally use 64-bit identifiers
> and FreeBSD needs to follow suit to properly and fully support these
> file systems.
> 
> The 64-bit inode project, also known as ino64, started life many years
> ago as a project by Gleb Kurtsou (gleb@).  After that time several
> people have had a hand in updating it and addressing regressions, after
> mckusick@ picked up and updated the patch, and acted as a flag-waver.
> 
> Sponsored by the FreeBSD Foundation I have spent a significant effort
> on outstanding issues and integration -- fixing compat32 ABI, NFS and
> ZFS, addressing ABI compat issues and investigating and fixing ports
> failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
> jhb@ provided feedback and review on the ABI transition support. pho@
> performed extensive testing and identified a number of issues that
> have now been fixed.  kris@ performed an initial ports investigation
> followed by an exp-run by antoine@. emaste@ helped with organization
> of the process.
> 
> This note explains how to perform useful testing of the ino64 branch,
> beyond typical smoke tests.
> 
> 1. Overview.
> 
> The ino64 branch extends the basic system types ino_t and dev_t from
> 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
> layout is modified due to the larger size of ino_t, and also gains a
> d_off (directory offset) member. As ino64 implies an ABI change anyway
> the struct statfs f_mntfromname[] and f_mntonname[] array length
> MNAMELEN is increased from 88 to 1024, to allow for longer mount path
> names.
> 
> ABI breakage is mitigated by providing compatibility using versioned
> symbols, ingenious use of the existing padding in structures, and by
> employing other tricks.  Unfortunately, not everything can be fixed,
> especially outside the base system.  For instance, third-party APIs
> which pass struct stat around are broken in backward and forward-
> incompatible way.
> 
> 2. Motivation.
> 
> The main risk of the ino64 change is the uncontrolled ABI breakage.
> Due to expansion of the basic types dev_t, ino_t and struct dirent,
> the impact is not limited to one part of the system, but affects:
> - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
>   and more)
> - libc interface (mostly related to the readdir(3), FTS(3))
> - collateral damage in other libraries that happens to use changed types
>   in the interfaces.  See, for instance, libprocstat, for which compat
>   was provided using symbol versioning, and libutil, which shlib version
>   was bumped.
> 
> 3. Quirks.
> 
> We handled kinfo sysctl MIBs, but other MIBs which report structures
> depended on the changed type, are not handled in general.  It was
> considered that the breakage is either in the management interfaces,
> where we usually allow ABI slip, or is not important.
> 
> Struct xvnode changed layout, no compat shims are provided.
> 
> For struct xtty, dev_t tty device member was reduced to uint32_t.  It
> was decided that keeping ABI compat in this case is more useful than
> reporting 64bit dev_t, for the sake of pstat.
> 
> 4. Testing procedure.
> 
> The ino64 project can be tested by cloning the project branch from
> GitHub or by applying the patch  at URL | attached> to a working tree.  The authorative source is the
> GitHub, I do not promise to update the review for each update.
> 
> To clone from GitHub:
> % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64
> 
> To fetch the patch from Phabricator:
> - Visit https://reviews.freebsd.org/D10439
> - Click "Download Raw Diff" at the upper right of the page
> 
> Or
> % arc patch D10439
> 
> After that, in the checkout directory do
> % (cd sys/kern && touch syscalls.master && make sysent)
> % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
> If you use custom kernel configuration, ensure that
>   options COMPAT_FREEBSD11
> is included into the config.  Then build world and kernel in the
> usual way, install kernel, reboot, install new world.  Do not make
> shortcuts in the update procedure.

Hey Kostik,

On my HardenedBSD system, world compiled fine with the patch, but the
kernel didn't compile. I've uploaded the log to:

https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log

This was from importing the patch from Phabricator into
hardened/current/master in HardenedBSD.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

[Bug 218849] Remove rc.conf jail configuration via jail_* variables

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849

Jonathan Anderson  changed:

   What|Removed |Added

 CC||jonat...@freebsd.org

--- Comment #27 from Jonathan Anderson  ---
(In reply to Miroslav Lachman from comment #26)

> ezjail is not the only one tool to manage jails and should not be used
> to take FreeBSD base as hostage. There are many alternatives and migration
> path is very trivial.
>
> It's time to move on.

ezjail may not be the only jail management utility, but it's the only one in
the Handbook. Before we "move on" from ezjail, perhaps the alternatives should
be be documented in the same place?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: regression suspend/resume on Lenovo T420

[Manuel Stühn]

On Mon, 15 May 2017 12:56:47 +0300, Konstantin Belousov wrote

On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:


In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82
a?= writes:


I've tried to verify that, and sadly it wasn't it for me.  The commit
that does break resume for me is r316767.  The current -CURRENT with
this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
correctly, at least in VT; I decided to take X out of the picture for
now.


I can confirm that this also makes resume work on my T430s running:

FreeBSD 12.0-CURRENT #0 r318250M amd64


Try this.  If it works, I will write a proper patch.

diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index 33437ad16e6..9c0cd05ebea 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -369,6 +369,11 @@ END(savectx)
   * Resuming processor state from pcb.
   */
  ENTRY(resumectx)
+   movl$MSR_EFER,%ecx
+   rdmsr
+   orl $EFER_NXE,%eax
+   wrmsr
+
/* Switch to KPML4phys. */
movqKPML4phys,%rax
movq%rax,%cr3



This patch makes resume work on my machine also (at least in VT; X is 
unfortunately still not working).




___
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: regression suspend/resume on Lenovo T420

[Konstantin Belousov]

On Mon, May 15, 2017 at 06:37:58PM +0100, Edward Tomasz Napiera??a wrote:
> Thanks!  The patch fixes resume for me, for both vt(4) and X11.

Thanks everybody for testing, patch below should be committable, modulo
bugs.  I did not tested it and ask for the same test as the previous
debugging patch.

diff --git a/sys/amd64/acpica/acpi_wakecode.S b/sys/amd64/acpica/acpi_wakecode.S
index 6b36d55e7d2..a63b5b8b769 100644
--- a/sys/amd64/acpica/acpi_wakecode.S
+++ b/sys/amd64/acpica/acpi_wakecode.S
@@ -156,11 +156,12 @@ wakeup_32:
/*
 * Enable EFER.LME so that we get long mode when all the prereqs are
 * in place.  In this case, it turns on when CR0_PG is finally enabled.
-* Pick up a few other EFER bits that we'll use need we're here.
+* Also it picks up a few other EFER bits that we'll use need we're
+* here, like SYSCALL and NX enable.
 */
movl$MSR_EFER, %ecx
-   rdmsr
-   orl $EFER_LME | EFER_SCE, %eax
+   movlwakeup_efer - wakeup_start(%ebx), %eax
+   movlwakeup_efer + 4 - wakeup_start(%ebx), %edx
wrmsr
 
/*
@@ -276,6 +277,8 @@ wakeup_pcb:
.quad   0
 wakeup_ret:
.quad   0
+wakeup_efer:
+   .quad   0
 wakeup_gdt:
.word   0
.quad   0
diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index 33437ad16e6..86198ab1a8c 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -396,7 +396,7 @@ ENTRY(resumectx)
movl4 + PCB_KGSBASE(%rdi),%edx
wrmsr
 
-   /* Restore EFER. */
+   /* Restore EFER one more time. */
movl$MSR_EFER,%ecx
movlPCB_EFER(%rdi),%eax
wrmsr
diff --git a/sys/x86/acpica/acpi_wakeup.c b/sys/x86/acpica/acpi_wakeup.c
index 4a10ac7b304..74f4fedc28f 100644
--- a/sys/x86/acpica/acpi_wakeup.c
+++ b/sys/x86/acpica/acpi_wakeup.c
@@ -223,7 +223,9 @@ acpi_sleep_machdep(struct acpi_softc *sc, int state)
WAKECODE_FIXUP(resume_beep, uint8_t, (acpi_resume_beep != 0));
WAKECODE_FIXUP(reset_video, uint8_t, (acpi_reset_video != 0));
 
-#ifndef __amd64__
+#ifdef __amd64__
+   WAKECODE_FIXUP(wakeup_efer, uint64_t, rdmsr(MSR_EFER));
+#else
WAKECODE_FIXUP(wakeup_cr4, register_t, pcb->pcb_cr4);
 #endif
WAKECODE_FIXUP(wakeup_pcb, struct pcb *, pcb);
___
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: Anyone having ccache errors?

[Beeblebrox]

> Would you please execute the following and attach your output?
> $ make -VMAKE_VERSION

make ver: 20170510
uname -U: 1200030

In my original post I also stated:
also getting "cc not found" errors whether ccache is enabled or not.
For example installworld (no ccache) broke with that message so I
decided to re-build.

So there's some strange clang stuff going on...

-- 
FreeBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 11:01, Beeblebrox  wrote:
> 
>> I was looking at the "make: Unknown modifier ‘c’” warnings — which
>> were a symptom of the bug that was fixed late last week. I don’t
>> genuinely know if ccache works or doesn’t work. Thanks, -Ngie
> 
> Thanks,
> I still do see those exact "make: Unknown modifier ‘c’” warnings
> along with the original fail.

More up-to-date information would help someone trying to diagnose your issue. 
Based on the original report, you are currently using sources from April 20th, 
which means that you would be affected by the bmake bug.

Would you please execute the following and attach your output?

$ make -VMAKE_VERSION
20170510

Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Beeblebrox]

> I was looking at the "make: Unknown modifier ‘c’” warnings — which
> were a symptom of the bug that was fixed late last week. I don’t
> genuinely know if ccache works or doesn’t work. Thanks, -Ngie

Thanks,
I still do see those exact "make: Unknown modifier ‘c’” warnings
along with the original fail.

-- 
FreeBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: [RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
wrote:

> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
> 
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
> 
>  *Insufficient loader memory, but OK after kernel is started.
> 
>  *Accidentally backed to older version that doesn't have
>   nvidia-modeset.ko and only nvidia-modeset.ko is written in
>   /boot/loader.conf.
> 
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
>   echo "Loading nvidia-driver modules via rc.conf."
> #  kldload nvidia
>   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
>   else
> #kldload nvidia
> kld_list="${kld_list} nvidia.ko"
>   fi
> fi
> 
> 
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet"  wrote:
> 
> >  Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > 
> >   12.0 - CURRENT
> > 
> >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > for me to peruse as I was in the terminal ]
> > 
> > Lessons I learned, maybe
> > 
> > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > nvidia-modeset-37539.ko
> >   which would make one's diagnosis a fix easier. 
> > 
> > [suggestions]
> > 
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than 
> > /boot/loader.conf [cli, rc.conf...]
> > 
> > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > ] 
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ... 
> > specifically stating which file/port/kernel module the 'client' refers 
> > to
> >and which specific modules 'this module' was referring to.  Unknown if 
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp 
> > ] where we can
> > ask them to be more specific or code in some more verbose error 
> > messages.
> > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > files out of the
> >   way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> > reshuffle,  maybe
> >did not need to be, just a hazy recollection on my part.  So ignore this 
> > little bit ]
> > 
> > ... All in all a learning experience.  Howsoever, I would like this nvidia 
> > stuff to be put eventuall
> >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > yearly will have a more
> >  authoritative flowchart of sorts to determine the next course of action.
> >something like
> >   if ... this thta
> >if... this that
> >if ... this that
> >   OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> > 
> >  ... And it would have maybe saved a bit of time here, and I would almost 
> > if eventually
> >  possible be sure to copy /usr/src/UPDATING to 
> > /usr/ports/x11/nvidia-driver for
> >  more easy access if the desktop was broken
> > 
> > 
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more 
> > quickly this
> > error the next time.
> > also...
> > Running late  in other personal matters, and out of time.
> > 
> > Respectfully..
> > 
> > J. Bouquet 
> > ___
> > 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"
> > 
> 
> 
> -- 
> Tomoaki AOKI


I found just then that one can load it manually
first, though the nvidia.ko  [ one has newly built ] THEN
the nvidia-modeset.ko  

if it has not been loaded via /boot/loader.conf which did not load it
in the 

Re: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 10:46, Beeblebrox  wrote:
> 
>> Upgrade make — it was a bug with it, fixed in the past few days.
>> HTH,
> 
> I just rebuilt and installed a clean world without using ccache
> After reboot I tried buildworld with ccache enabled, but got same error.
> 
> So, did not work unless you meant a particular port?

I was looking at the "make: Unknown modifier ‘c’” warnings — which were a 
symptom of the bug that was fixed late last week. I don’t genuinely know if 
ccache works or doesn’t work.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone having ccache errors?

[Beeblebrox]

> Upgrade make — it was a bug with it, fixed in the past few days.
> HTH,

I just rebuilt and installed a clean world without using ccache
After reboot I tried buildworld with ccache enabled, but got same error.

So, did not work unless you meant a particular port?

-- 
FreeBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: regression suspend/resume on Lenovo T420

[Jonathan Anderson]

On 15 May 2017, at 14:57, Konstantin Belousov wrote:


On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:


Running drm-next (which has -CURRENT last merged somewhere around
r317651), this patch fixes one of the two problems I've been
experiencing with suspend/resume. Definite progress. :)


Could you, please, clarify.  Does the resume work after this  ?  If 
not,
how did you diagnosed that 'one of two problems' is solved with the 
change ?


Sorry, I'll try to clarify. My problems were:

1. since at least late March, I've had visual artifacts on resume that 
make the screen unusable;

2. more recently, the machine didn't resume at all.

Applying your patch, I can successfully suspend to S3 and resume again, 
so problem #2 is resolved. This leaves me in a better position to try 
and test solutions for problem #1 (which might be an issue related to 
the Mar 13 firmware update on drm-next rather than a -CURRENT problem).


Thanks,


Jon
--
Jonathan Anderson
jonat...@freebsd.org
___
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: regression suspend/resume on Lenovo T420

[Edward Tomasz Napiera??a]

On 0515T1256, Konstantin Belousov wrote:
> On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
> > 
> > In message <20170514193006.GA1298@brick>, Edward Tomasz 
> > =?utf-8?Q?Napiera=C5=82
> > a?= writes:
> > 
> > >I've tried to verify that, and sadly it wasn't it for me.  The commit
> > >that does break resume for me is r316767.  The current -CURRENT with
> > >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
> > >correctly, at least in VT; I decided to take X out of the picture for
> > >now.
> > 
> > I can confirm that this also makes resume work on my T430s running:
> > 
> > FreeBSD 12.0-CURRENT #0 r318250M amd64
> 
> Try this.  If it works, I will write a proper patch.
> 
> diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
> index 33437ad16e6..9c0cd05ebea 100644
> --- a/sys/amd64/amd64/cpu_switch.S
> +++ b/sys/amd64/amd64/cpu_switch.S
> @@ -369,6 +369,11 @@ END(savectx)
>   * Resuming processor state from pcb.
>   */ 
>  ENTRY(resumectx)
> + movl$MSR_EFER,%ecx
> + rdmsr
> + orl $EFER_NXE,%eax
> + wrmsr
> +
>   /* Switch to KPML4phys. */
>   movqKPML4phys,%rax
>   movq%rax,%cr3

Thanks!  The patch fixes resume for me, for both vt(4) and X11.

___
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: regression suspend/resume on Lenovo T420

[Pete Wright]

On 05/15/2017 10:27, Konstantin Belousov wrote:

On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:

On 15 May 2017, at 7:26, Konstantin Belousov wrote:

Try this.  If it works, I will write a proper patch.

diff --git a/sys/amd64/amd64/cpu_switch.S
b/sys/amd64/amd64/cpu_switch.S
index 33437ad16e6..9c0cd05ebea 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -369,6 +369,11 @@ END(savectx)
   * Resuming processor state from pcb.
   */
  ENTRY(resumectx)
+   movl$MSR_EFER,%ecx
+   rdmsr
+   orl $EFER_NXE,%eax
+   wrmsr
+
/* Switch to KPML4phys. */
movqKPML4phys,%rax
movq%rax,%cr3

Running drm-next (which has -CURRENT last merged somewhere around
r317651), this patch fixes one of the two problems I've been
experiencing with suspend/resume. Definite progress. :)

Could you, please, clarify.  Does the resume work after this  ?  If not,
how did you diagnosed that 'one of two problems' is solved with the change ?


I can confirm that suspending to a S3 state and resuming now works on 
the drm-next branch as well.


this matches the previous behavior on my systems before recent updates 
which broke suspend/resume - so i believe this patch works from a 
functional POV.


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: regression suspend/resume on Lenovo T420

[Konstantin Belousov]

On Mon, May 15, 2017 at 02:37:16PM -0230, Jonathan Anderson wrote:
> On 15 May 2017, at 7:26, Konstantin Belousov wrote:
> >
> > Try this.  If it works, I will write a proper patch.
> >
> > diff --git a/sys/amd64/amd64/cpu_switch.S 
> > b/sys/amd64/amd64/cpu_switch.S
> > index 33437ad16e6..9c0cd05ebea 100644
> > --- a/sys/amd64/amd64/cpu_switch.S
> > +++ b/sys/amd64/amd64/cpu_switch.S
> > @@ -369,6 +369,11 @@ END(savectx)
> >   * Resuming processor state from pcb.
> >   */
> >  ENTRY(resumectx)
> > +   movl$MSR_EFER,%ecx
> > +   rdmsr
> > +   orl $EFER_NXE,%eax
> > +   wrmsr
> > +
> > /* Switch to KPML4phys. */
> > movqKPML4phys,%rax
> > movq%rax,%cr3
> 
> Running drm-next (which has -CURRENT last merged somewhere around 
> r317651), this patch fixes one of the two problems I've been 
> experiencing with suspend/resume. Definite progress. :)

Could you, please, clarify.  Does the resume work after this  ?  If not,
how did you diagnosed that 'one of two problems' is solved with the change ?
___
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: regression suspend/resume on Lenovo T420

[Jonathan Anderson]

On 15 May 2017, at 7:26, Konstantin Belousov wrote:


Try this.  If it works, I will write a proper patch.

diff --git a/sys/amd64/amd64/cpu_switch.S 
b/sys/amd64/amd64/cpu_switch.S

index 33437ad16e6..9c0cd05ebea 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -369,6 +369,11 @@ END(savectx)
  * Resuming processor state from pcb.
  */
 ENTRY(resumectx)
+   movl$MSR_EFER,%ecx
+   rdmsr
+   orl $EFER_NXE,%eax
+   wrmsr
+
/* Switch to KPML4phys. */
movqKPML4phys,%rax
movq%rax,%cr3


Running drm-next (which has -CURRENT last merged somewhere around 
r317651), this patch fixes one of the two problems I've been 
experiencing with suspend/resume. Definite progress. :)


Thanks!


Jon
--
Jonathan Anderson
jonat...@freebsd.org
___
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: Anyone having ccache errors?

[Ngie Cooper (yaneurabeya)]

> On May 15, 2017, at 01:20, Beeblebrox  wrote:
> 
> I have been getting ccache errors during buildworld. Ports for example does 
> not have this problem. I compleely reset the cache data some 2 months ago and 
> ccache seemed to play with that much more nicely.
> 
> Apart from the error below, I'm also getting some "cc not found" errors when 
> doing src stuff, whether ccache is enabled or not. For example installworld 
> (no ccache) broke with that message so I decided to re-build.
> 
> uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 2017
> 
> /etc/make.conf
> CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
> CXX:=${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1}
> 
> ls /usr/local/libexec/ccache/world/
> c++   CCclang clang++40 g++5
> ccccacheclang++   clang40   gcc5
> 
> # make buildworld =>
> make: Unknown modifier 'c'
> make: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[1]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> --
 World build started
> .
 stage 1.2: bootstrap tools
> --
> cd /asp/git/src; MAKEOBJDIRPREFIX=/asp/obj/asp/git/src/tmp  INSTALL="sh 
> /asp/git/src/tools/install.sh"  TOOLS_PREFIX=/asp/obj/asp/git/src/tmp  
> PATH=/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/legacy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
>   WORLDTMP=/asp/obj/asp/git/src/tmp  MAKEFLAGS="-m 
> /asp/git/src/tools/build/mk  -m /asp/git/src/share/mk" make  -f Makefile.inc1 
>  DESTDIR=  BOOTSTRAPPING=1200030  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes 
> MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no 
> MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no  
> MK_INCLUDES=yes bootstrap-tools
> make[2]: Unknown modifier 'c'
> make[2]: Unknown modifier 'c'
> ===> lib/clang/libllvmminimal (obj,all,install)
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> make[3]: Unknown modifier 'c'
> -O2 -pipe -I/asp/git/src/lib/clang/include 
> -I/asp/git/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
> -DDEFAULT_SYSROOT=\"/asp/obj/asp/git/src/tmp\" -ffunction-sections 
> -fdata-sections -DNDEBUG -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o 
> -Qunused-arguments -I/asp/obj/asp/git/src/tmp/legacy/usr/include -std=c++11 
> -fno-exceptions -fno-rtti  -stdlib=libc++ -Wno-c++11-extensions  -c 
> /asp/git/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
> /bin/sh: -O2: not found
> *** Error code 127

Upgrade make — it was a bug with it, fixed in the past few days.
HTH,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

Hi.
If including its version to nvidia.ko and nvidia-modeset.ko,
[hard / symbolic] link to it with current name should be needed
not to bother admins every time upgrading.

BTW, I personally using below in rc.conf for safety.
This only helps situations that...

 *Insufficient loader memory, but OK after kernel is started.

 *Accidentally backed to older version that doesn't have
  nvidia-modeset.ko and only nvidia-modeset.ko is written in
  /boot/loader.conf.

## Temporary settings for nvidia-driver when failed loading via loader.conf
kldstat -q -n nvidia.ko
if [ 0 -ne $? ] ; then
  echo "Loading nvidia-driver modules via rc.conf."
#  kldload nvidia
  if [ -e /boot/modules/nvidia-modeset.ko ] ; then
#kldload nvidia-modeset
kld_list="${kld_list} nvidia-modeset.ko"
  else
#kldload nvidia
kld_list="${kld_list} nvidia.ko"
  fi
fi


On Mon, 15 May 2017 06:41:33 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

>  Just had a unique to me, unbootable backup [beside the point,
> just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> 
>   12.0 - CURRENT
> 
>   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
> me to peruse as I was in the terminal ]
> 
> Lessons I learned, maybe
> 
> [RFC]  rename nvidia-driver.ko to include its version, for instance 
> nvidia-modeset-37539.ko
>   which would make one's diagnosis a fix easier. 
> 
> [suggestions]
> 
> ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> thus made it 'unavailable'
> ... document better that one can load nvidia[modeset] later than 
> /boot/loader.conf [cli, rc.conf...]
> 
> [ mini 'what fixed it for you '  and/or stalled the same ... 
> ] 
> ... I had a make.conf in place, 'trapping' a
> make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> install in failure
> ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> ... I had no access to the forums, as the desktop could not be loaded [yet]
> ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> usable module numbers,
> THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 
> 5 digit number
> as above.
> ... I was taken aback by the less infomative
> this client has the .39 but the module has the .26 ... 
> specifically stating which file/port/kernel module the 'client' refers to
>and which specific modules 'this module' was referring to.  Unknown if 
> that is
>fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
> where we can
> ask them to be more specific or code in some more verbose error messages.
> ...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
> out of the
>   way and do a simple rebuild of the nvidia-driver.
> [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> reshuffle,  maybe
>did not need to be, just a hazy recollection on my part.  So ignore this 
> little bit ]
> 
> ... All in all a learning experience.  Howsoever, I would like this nvidia 
> stuff to be put eventuall
>  in /usr/src/UPDATING so the half or third of persons who run into this 
> yearly will have a more
>  authoritative flowchart of sorts to determine the next course of action.
>something like
>   if ... this thta
>if... this that
>if ... this that
>   OTOH... error message... a... you may need to...
>...
>error message ... r... you may need to...
> 
>  ... And it would have maybe saved a bit of time here, and I would almost if 
> eventually
>  possible be sure to copy /usr/src/UPDATING to 
> /usr/ports/x11/nvidia-driver for
>  more easy access if the desktop was broken
> 
> 
> Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> here
> locally [ still in scribbled notations...] so I can forestall/fix more 
> quickly this
> error the next time.
> also...
> Running late  in other personal matters, and out of time.
> 
> Respectfully..
> 
> J. Bouquet 
> ___
> 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"
> 


-- 
Tomoaki AOKI
___
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: ports-mgmt/pkg_rmleaves stops working properly on -head after bsdiff became default diff (r317209)

[Tomoaki AOKI]

Revised like Boris did for misc/mc [1].

Now attached raw Makefile and patch (renamed), as patch does not
handle new files on nonexistent files directory. :-(

PORTREVISION bumped, as this port is small enough and NO_BUILD,
and need updating for recent -head.

But at least 2 ports is affected for now, and possibly more.
IMHO, these Gnu diff compatible group-format related options
would be worth implemented by bsdiff.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277


On Sun, 14 May 2017 16:03:55 +0900
Tomoaki AOKI  wrote:

> Hi.
> Posting on freebsd-current as this only affects -head.
> 
> I recently noticed ports-mgmt/pkg_rmleaves failes to process
> new leaf ports after removal of leaf ports on -head with error
> messages below.
> 
> > diff: unrecognized option `--unchanged-line-format='
> > usage: diff [-abdilpTtw] [-c | -e | -f | -n | -q | -u] [--ignore-case]
> > [--no-ignore-case] [--normal] [--strip-trailing-cr]
> > [--tabsize] [-I pattern] [-L label] file1 file2
> >diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case]
> > [--no-ignore-case] [--normal] [--strip-trailing-cr]
> > [--tabsize] -C number file1 file2
> >diff [-abdiltw] [-I pattern] [--ignore-case] [--no-ignore-case]
> > [--normal] [--strip-trailing-cr] [--tabsize] -D string
> > file1 file2 diff [-abdilpTtw] [-I pattern] [-L label] [--ignore-case]
> > [--no-ignore-case] [--normal] [--tabsize]
> > [--strip-trailing-cr] -U number file1 file2
> >diff [-abdilNPprsTtw] [-c | -e | -f | -n | -q | -u]
> > [--ignore-case] [--no-ignore-case] [--normal] [--tabsize] [-I pattern]
> > [-L label] [-S name] [-X file] [-x pattern] dir1 dir2
> 
> stable/11 was OK, and the difference is that stable/11 has gnu diff
> as diff, while -head has bsdiff as diff.
> 
> There's 2 (or possibly 3) options.
> 
>  a) Let pkg_rmleaves use gnu diff via textprocs/diffutils.
> This is easiest (Minimal diff is attached), but doesn't help
> any other ports affected. Just change diff to gdiff and RUN_DEPENDS
> on textproc/diffutils.
> 
>  b) Update bsdiff to support missing options below.
> This is over my hand, but if possible, would help others.
> 
>  c) If the missing options below are implemented as different
> (non-documented) options on bsdiff, use them for bsdiff instead.
> Will need OSVERSION check in ports Makefile.
> 
> Please note that attached diff is really MINIMAL to work on -head.
> No OSVERSION switching is implemented and no bumps so forcibly
> installs textproc/diffutils on revisions with gnu diff is /usr/bin/diff.
> And patch wouldn't work properly as files directory doesn't exist
> in pkg-mgmt/pkg_rmleaves. (At least system patch.)
> 
> I wonder which option should be taken, so not yet filed PR on bugzilla.
> It should be filed differently with which option is taken.
> 
> -- 
> Tomoaki AOKI


-- 
Tomoaki AOKI


Makefile
Description: Binary data


extra-patch-pkg_rmleaves
Description: Binary 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"

[RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

 Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ]  quandry dealing with the nvidia-driver update
that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]

  12.0 - CURRENT

  [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
me to peruse as I was in the terminal ]

Lessons I learned, maybe

[RFC]  rename nvidia-driver.ko to include its version, for instance 
nvidia-modeset-37539.ko
  which would make one's diagnosis a fix easier. 

[suggestions]

... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus 
made it 'unavailable'
... document better that one can load nvidia[modeset] later than 
/boot/loader.conf [cli, rc.conf...]

[ mini 'what fixed it for you '  and/or stalled the same ... 
] 
... I had a make.conf in place, 'trapping' a
make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
install in failure
... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
... I had no access to the forums, as the desktop could not be loaded [yet]
... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable 
module numbers,
THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 
digit number
as above.
... I was taken aback by the less infomative
this client has the .39 but the module has the .26 ... 
specifically stating which file/port/kernel module the 'client' refers to
   and which specific modules 'this module' was referring to.  Unknown if that 
is
   fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
where we can
ask them to be more specific or code in some more verbose error messages.
...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
out of the
  way and do a simple rebuild of the nvidia-driver.
[... Not relieved that the nvidia-driver needed install during the mesa-lib 
reshuffle,  maybe
   did not need to be, just a hazy recollection on my part.  So ignore this 
little bit ]

... All in all a learning experience.  Howsoever, I would like this nvidia 
stuff to be put eventuall
 in /usr/src/UPDATING so the half or third of persons who run into this yearly 
will have a more
 authoritative flowchart of sorts to determine the next course of action.
   something like
  if ... this thta
   if... this that
   if ... this that
  OTOH... error message... a... you may need to...
   ...
   error message ... r... you may need to...

 ... And it would have maybe saved a bit of time here, and I would almost if 
eventually
 possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver 
for
 more easy access if the desktop was broken


Apologies for the hurried post. Indeed, I have tasked myself to write it up here
locally [ still in scribbled notations...] so I can forestall/fix more quickly 
this
error the next time.
also...
Running late  in other personal matters, and out of time.

Respectfully..

J. Bouquet 
___
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: vt(4) odd scrolling behavior

[Aleksandr Rybalko]

Looks like video driver reports double buffer as single frame buffer, so vt
draw it as big screen, but video card draw it as two layers.
___
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"

[Bug 218849] Remove rc.conf jail configuration via jail_* variables

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849

--- Comment #26 from Miroslav Lachman <000.f...@quip.cz> ---
(In reply to Thomas Steen Rasmussen / Tykling from comment #25)
Are you serious? Then why Joe provided the idea how to make ezjail survive this
code removal?
Did you read the comment from Jamie?
Did you compare rc.d/jail with legacy support and without it? The legacy
support is a mess compared to new style and some functionalities are missing.

As I already stated - ezjail is not the only one tool to manage jails and
should not be used to take FreeBSD base as hostage. There are many alternatives
and migration path is very trivial.
It's time to move on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: regression suspend/resume on Lenovo T420

[Konstantin Belousov]

On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
> 
> In message <20170514193006.GA1298@brick>, Edward Tomasz 
> =?utf-8?Q?Napiera=C5=82
> a?= writes:
> 
> >I've tried to verify that, and sadly it wasn't it for me.  The commit
> >that does break resume for me is r316767.  The current -CURRENT with
> >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
> >correctly, at least in VT; I decided to take X out of the picture for
> >now.
> 
> I can confirm that this also makes resume work on my T430s running:
> 
>   FreeBSD 12.0-CURRENT #0 r318250M amd64

Try this.  If it works, I will write a proper patch.

diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index 33437ad16e6..9c0cd05ebea 100644
--- a/sys/amd64/amd64/cpu_switch.S
+++ b/sys/amd64/amd64/cpu_switch.S
@@ -369,6 +369,11 @@ END(savectx)
  * Resuming processor state from pcb.
  */ 
 ENTRY(resumectx)
+   movl$MSR_EFER,%ecx
+   rdmsr
+   orl $EFER_NXE,%eax
+   wrmsr
+
/* Switch to KPML4phys. */
movqKPML4phys,%rax
movq%rax,%cr3
___
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"

Anyone having ccache errors?

[Beeblebrox]

I have been getting ccache errors during buildworld. Ports for example does not 
have this problem. I compleely reset the cache data some 2 months ago and 
ccache seemed to play with that much more nicely.

Apart from the error below, I'm also getting some "cc not found" errors when 
doing src stuff, whether ccache is enabled or not. For example installworld (no 
ccache) broke with that message so I decided to re-build.

uname: 12.0-CURRENT 1200028 bedc15ffb71(drm-next)-dirty: Thu Apr 20 2017

/etc/make.conf
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
CXX:=${cxx:c,^C\+\+,/usr/local/libexec/ccache/world/clang++,1}

ls /usr/local/libexec/ccache/world/
c++   CCclang clang++40 g++5
ccccacheclang++   clang40   gcc5

# make buildworld =>
make: Unknown modifier 'c'
make: Unknown modifier 'c'
make[1]: Unknown modifier 'c'
make[1]: Unknown modifier 'c'
make[2]: Unknown modifier 'c'
make[2]: Unknown modifier 'c'
make[2]: Unknown modifier 'c'
make[2]: Unknown modifier 'c'
--
>>> World build started
.
>>> stage 1.2: bootstrap tools
--
cd /asp/git/src; MAKEOBJDIRPREFIX=/asp/obj/asp/git/src/tmp  INSTALL="sh 
/asp/git/src/tools/install.sh"  TOOLS_PREFIX=/asp/obj/asp/git/src/tmp  
PATH=/asp/obj/asp/git/src/tmp/legacy/usr/sbin:/asp/obj/asp/git/src/tmp/legacy/usr/bin:/asp/obj/asp/git/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/asp/obj/asp/git/src/tmp  MAKEFLAGS="-m /asp/git/src/tools/build/mk  
-m /asp/git/src/share/mk" make  -f Makefile.inc1  DESTDIR=  
BOOTSTRAPPING=1200030  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes MK_MAN=no  -DNO_PIC 
MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  
MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no  MK_INCLUDES=yes 
bootstrap-tools
make[2]: Unknown modifier 'c'
make[2]: Unknown modifier 'c'
===> lib/clang/libllvmminimal (obj,all,install)
make[3]: Unknown modifier 'c'
make[3]: Unknown modifier 'c'
make[3]: Unknown modifier 'c'
make[3]: Unknown modifier 'c'
make[3]: Unknown modifier 'c'
-O2 -pipe -I/asp/git/src/lib/clang/include -I/asp/git/src/contrib/llvm/include 
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/asp/obj/asp/git/src/tmp\" -ffunction-sections 
-fdata-sections -DNDEBUG -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o 
-Qunused-arguments -I/asp/obj/asp/git/src/tmp/legacy/usr/include -std=c++11 
-fno-exceptions -fno-rtti  -stdlib=libc++ -Wno-c++11-extensions  -c 
/asp/git/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
/bin/sh: -O2: not found
*** Error code 127

Stop.
make[3]: stopped in /asp/git/src/lib/clang/libllvmminimal



* I had asked this before, but got no answer. I assume it's not possible then?
> 1. For buildworld, my /etc/src.conf uses default CROSS_COMPILER,
> CLANG_BOOTSTRAP, CLANG_FULL  for amd64, but I would like clang to
> xbuild only for target i386 as I do not need the others (like
> Target/arm). Is there a knob for this?

-- 
FreeBSD_amd64_12-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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"

Problems with re(4) Ethernet driver in 11-STABLE and HEAD

[Thomas Mueller]

I remember having problems with Realtek 8111E Ethernet on this Intel Ivy Bridge 
computer a couple years ago, and now the problem has resurfaced.

I am fresh from updating FreeBSD to 11-STABLE and HEAD on two partitions, and 
in both cases can not connect with onboard Ethernet.

>From NetBSD 7.99.1 /var/run/dmesg.boot :

re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 
0x06)
re0: interrupting at ioapic0 pin 17
re0: Ethernet address d4:3d:7e:97:17:e2
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

NetBSD 7.99.1, an old build, and NetBSD going back to 5.x, worked well with 
this Ethernet, but the bug has come back in FreeBSD.

Before giving up hope on FreeBSD 11-STABLE and HEAD on this computer, I have 
Hiro H50191 USB wi-fi adapter, driver rsu, haven't used it recently but see 
where I will try to bring it back.

"dhclient re0" on HEAD (amd64) gave a couple lines of screen output before 
crashing into debugger (db>), whereupon I simply did "reboot".

On 11-STABLE, also amd64, I got some lines before it gave up , "sleeping".

On an old FreeBSD-current, svn r286653M, Aug 12, 2015, this Ethernet starts 
properly with dhclient.  Now I am afraid to update except by installing onto a 
separate partition.

I have plenty of space on 3 TB hard drive with GPT.

I am not completely sure on which FreeBSD list is most appropriate for this 
issue.

Tom

___
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"